|
Hello Reader, There is a point most engineers hit where progress quietly stalls. You are doing solid work, you are reliable, easy to collaborate with and technically competent. From the outside, nothing looks wrong. But the interesting projects start going to the same few people, promotions feel harder to reach, and your ideas land in the room but do not travel beyond it. What is uncomfortable is that you are not failing. You are just indistinguishable. Most engineers respond to this by trying to get better at what everyone else is already doing: more polished documentation, more careful estimates, more aligned with the team’s existing direction. It feels logical but It is also how you disappear. I learned this the hard way, spending the better part of a year optimising for reliability when what the organisation actually needed was a different perspective. How engineers learn to stay in their lane Early in your career, blending in is rewarded. You follow the team norms, match the communication style of your tech lead, and use the same framing everyone else uses in design docs. You learn what is acceptable by watching what gets praised in reviews and what gets quietly ignored in architecture discussions. Over time, this becomes automatic and your brain starts optimising for safety not memorability. So when it is time to stand out, your instincts work against you. Raising a different architectural concern feels risky, reframing the problem in a design review feels presumptuous, and owning a gap no one else is touching feels like unnecessary exposure. The safest option always seems to be validating what has already been proposed, and that is how entire engineering teams end up sounding the same. I’ve watched this happen both to people I’ve mentored and to myself, and the pattern is almost always invisible until someone points it out. The part most engineers miss Difference does not start with creativity, it starts with observation. The engineers who stand out usually begin by studying the environment closely: noticing the patterns everyone else takes for granted, the tone that dominates design reviews, the type of contributions that get referenced in promotion packets, and the questions that never get asked in cross-functional meetings. Once you see the pattern, you also see the gaps. What is not being said, what no one is willing to own, and what value is missing because it feels uncomfortable or unnecessary. That gap is where attention lives. I remember sitting in a design review early in my career where the entire team was aligned on a solution. Everyone was nodding. I had a concern about the failure mode under load, but it felt too late to raise it and too risky to push back so I stayed quiet. Few weeks later, that exact failure mode surfaced in production. I had seen the gap and chosen safety over contribution. That was the moment I understood what blending in actually costs. This is not a new phenomenon. Psychologists call it the Von Restorff effect, the brain’s tendency to remember items that stand out from their surroundings. In a 1933 study, Hedwig von Restorff demonstrated that isolated, distinctive items are significantly more likely to be recalled than items that blend into a uniform group. Your brain is not wired to remember everything. It is wired to flag contrast. Why difference actually works in engineering environments When everything in a meeting sounds the same, the same framing, the same risk tolerance, the same deference to the loudest voice, novelty gets flagged immediately. Not because it is better, but because it is different. Attention follows contrast, and memory follows attention. This is why the engineer who reframes a problem in a design review rather than just validating the existing approach gets remembered, even if their framing is not perfect. It stands out against the background noise. Where engineers go wrong Many engineers mistake difference for disruption. They push back on everything, optimise for being contrarian and perform independence without grounding it in value. That approach rarely lasts because it erodes the trust of the people whose sponsorship actually matters. I used to think the same way early on, confusing visibility with volume, until I realised that the engineers people actually sponsor are the ones who make the room better. Real difference is quieter than that. It shows up in how you frame problems before the solution is locked in, in the clarifying question you ask when everyone else is nodding along and in the gap you choose to own when everyone else is waiting for someone else to step up. The signal is not volume, it is contrast. A practical framework for standing out without burning trust
Blending in is rarely a conscious decision. It is a habit reinforced by comfort and the engineers who become memorable are not always the most technically gifted. They are the ones who learn where the pattern is and choose deliberately to break it in a way that still serves the room. Difference is not about being loud. It is about being legible when everything else fades together. Bottom line Before your next high-stakes meeting, identify one gap no one else is owning, prepare one reframe, and deliver it once and see what happens. That is all for this week. |
Join 1k+ other forward-thinking professionals who receive the weekly newsletter, where I provide actionable strategies, insights and tools to escape the grind and build influential, future-proof careers. Sign up to get a FREE copy of my 5-Stage playbook to multiply your impact and build a career that AI can't replace.
Hello Reader, It's Kayode Three years ago, I watched a senior engineer named Priya present a migration plan that should have been a career-defining moment. She had benchmarks from three cloud providers. She had architecture diagrams showing the current state and the proposed state, layered with annotations. She had a detailed rollback procedure for every phase of the transition. The savings were real: $2.3 million annually, backed by six weeks of analysis. Any questions? she asked the room....
Hello Reader, It's Kayode A few years ago, I sat in a planning meeting that had been running for 45 minutes without a single decision made. Everyone had an opinion and nobody had ownership, and the same three options kept cycling through the conversation like luggage on a carousel that nobody wanted to claim. Then one engineer said: “We’ve been here long enough. Based on what we’ve heard, we’re going with option two. Here’s who owns what next.” The room went quiet in the way rooms do when...
Hello Reader, Three years ago, I watched a senior engineer named Sarah coordinate a critical infrastructure migration. Network automation, data platform, and application services were moving to a new orchestration layer simultaneously. In week one, Sarah noticed something: The network team was designing their API for synchronous responses. The data platform team was building for eventual consistency. By week three, these systems would be incompatible. She spent two weeks facilitating...