The thing I eventually learned is that avoiding a conflict doesn’t make anything smaller. It does the exact opposite. The things you don’t say will sit there and grow and it can and has led to me burning out in the past. Silent resentment becomes silent disagreements, silent disagreements becomes a distorted sense of belonging, which then becomes imposter syndrome and eventually rolls up into burn out. This means you need to be careful about what emotional tax you pay vs what you decide to bank in.

For example, a small interaction with how a colleague works can become genuine resentment over time. A disagreement about direction that would have been a twenty minute conversation becomes a months-long silence where two people are building different things to each other. By the time the conversation finally happens (and it will always eventually happen), it multiplies bigger than it needed to be and twice as personal. It is more than likely that some of the big conflicts you’ve seen weren’t big when they started. They grew whilst waiting to be solved.

This transition for me didn’t magically happen over night, it didn’t even happen while I was an engineer. As an engineer (at-least before AI) it was easier to hide behind coding all day, you just route around the person, keep your head down, complain privately to someone you could trust.

The transition happened when I became a manager, because conflict becomes the de-facto path to success for you and your team(s). Feedback conversations, performance reviews, disagreements between engineers that need mediating, pushing back on stakeholders and also being pushed back on. There’s no moving around it, the uncomfortable conversation IS the work. I didn’t get better at confrontation because I grew as a person (albeit I did grow a lot as a result), I got better because the role gave me no choice and then somewhere along the way I noticed the conversations I’d been dreading were almost never as bad as what they were in my head.

Get comfortable with being uncomfortable

Over time It gets easier the more you build the confidence to expose yourself. Conflict is a vulnerable thing. Am I over-reacting? Will this change the dynamic of our relationship? Am I not reacting enough? Will they care? Our brains naturally hate conflict because it triggers our fight or flight response, our cortisol levels rise and we may not be able to manage the situation the same way if we felt calmer. But, exposing yourself, naturally, will reinforce that part of your brain and it will say “hey, this went well last time, what if it goes well this time?”

Exposure to these conversations and building a repertoire of good outcomes from conflict can make it feel less daunting each time. So, If there’s a conversation you’ve been putting off at work, it’s probably smaller today than it will be next month. Have the conversation, do the hard thing. Because, growth doesn’t happen being comfortable.

What I do with my team now

Nowadays, I try to build psychological safety in my teams by actively encouraging my them to be open and transparent about what they’re feeling, including with me and even more so including when it is about me. If something is bothering someone, I want it said while it’s small. This creates that safety in the team, holding things in doesn’t. It sounds backwards, but, I wouldn’t mistake you for assuming safety means nobody ever says anything hard but a team where nothing hard gets said is usually a team where everyone is holding something in (which could eventually break).

What actually happens when this works is that things get solved early. The interaction gets called out in a 1:1 or retrospective while it’s still small. That disagreement about direction? It now gets had in the open, in front of the team, while it’s still about the work and not yet about the people. And, there’s a side effect once that openness is developed, it builds a kind of camaraderie. The team is comfortable speaking up.
Teams that can disagree openly trust each other more. You know where you stand with people who tell you where you stand. It also keeps the team pointed at the same goal, because the energy that would have gone into managing the people aspects goes into the work instead.

I should end this by being honest that I still don’t enjoy any of it. My first instinct when I sense a hard conversation coming is still to look for the route around it - the fight-or-flight response still kicks in. But over time it has less impact on me, because I now have evidence that conflict works. I’ve learned how not to obey the instinct and to treat the dread as information that the conversation is probably overdue rather than a reason to wait another week.

Subscribe now

If you need support with a conversation at work, feel free to drop me a message - I’m happy to help you get through it if the result is better conflict management and healthier teams.

I ended up thinking about it after because I’ve watched a few of these communities die over the years. It’s usually less dramatic and more of a slow burner, attendance dwells and eventually the organiser is presenting to nobody. Which is a shame, because when one actually works the returns tend to compound. Engineers stop solving the same problem five times in five different teams, feedback starts reaching people who can actually act on it and there’s a feeling of being part of something beyond the day to day grind.

cough People who feel part of something tend to stay longer too. cough

So when they asked me what I thought, most of what I said was about what I apply myself. There are three guiding principles I use to start and build communities:

Belonging

The mistake I see people make is going too structured too early, an agenda, a rota of presentations, a proper format etc... none of that really gets people to show up though. People show up when it feels like they can connect and that bit doesn’t come from the sessions, it comes from everything around them.

So just find the moments of shared interest that aren’t work. Go for lunch, get a drink after a session, don’t kick the Slack channel off with a roadmap. You’re not really trying to run something yet, you’re just trying to get people to know each other a bit, and mostly that means not filling every minute with content.

Easiest way to see if you’re getting it right is what happens when someone new joins. Do they get thought about, or do they get left to lurk in the channel and quietly decide it’s not for them. A quick DM, an intro, a come to lunch on thursday, costs you nothing and it’s usually the whole difference. It sounds soft and people write it off because it doesn’t look like work, but I really do think this is most of it.

Trust

Google ran a big internal study a few years back (Project Aristotle) trying to work out what separated their effective teams from the rest and the thing that became a clear winning idea was psychological safety (whether people feel safe to speak up and be themselves in the group).

A community is no different, people only really engage with it once they trust it’s for them. The fastest way I know to build that is to speak to people, listen to them, understand their pain/frustration and try to remove it. When something that’s been annoying people for months just goes away, they start believing the thing can actually change things. I had a version of this with my own engineers, they’d been complaining about painfully long build times on their machines (we’re dealing with large monorepo codebases), so I got every MacBook in the team upgraded. I’ll be honest that I had the advantage of a manager’s budget there, most community builders don’t. But, the idea works without money. It might be fixing the bit of tooling everyone hates, or taking the feedback from the first session and actually shipping something from it before the second one happens. Small and fast is fine, probably better actually, people seem to notice a quick turnaround more than anything you promise for later (and may not deliver on before momentum dies).

Consistency

This is the boring one and probably the most important. Community takes a pack, if a single person started, entertained and is carries all of the energy, when that person gets busy (or leaves, or just gets tired of it), there won’t really be anyone else holding it up. So set up the ceremonies and keep them regular, even when a session is a bit thin.

The bit between the sessions matter too. A community that only exists for an hour a month isn’t really a community, it’s a recurring meeting. The Slack channel is where it actually lives day to day, so put energy into it, share things in there, ask questions, make sure the things people raise get responses. And when you do run a session, end it with something. Actions, follow ups, a thing somebody agreed to try in their team and report back on. Sessions that end with everyone aligned and follow ups give people a reason to come to the next one and the good ones sometimes break out into their own thing entirely, a working group forming around a problem a few people care about, or a couple of engineers aligning on a best practice that ends up being adopted across teams. That’s the community doing what it’s actually for.

The other part of consistency is giving ownership away early. There will (hopefully) be people who show up energised, asking questions. Give those people something to own as soon as you can, a session, the channel, one of those working groups, whatever fits. If the community only exists because of you, it’s alot more fragile than it looks.

Getting started

The practical advice I gave them was to start with a lunch. Not a session, not a kickoff, just get the engineers together and let them get to know each other. Alot of what makes everything work comes from that first bit of familiarity and it also means you’re not deciding the how to move the thing forward on your own, you can work out together how you want to progress. Then look for the most engaged people, the ones asking when the next thing is happening and if they want to be part of it, give them something to do.

There’s a version of this for the org side too. If you’re a manager and someone comes to you wanting to build a community, the honest advice is mostly to get out of their way and take the small blockers off them. The hour in people’s calendars, a bit of budget for lunch here and there. That kind of energy is rare enough that when someone actually has it, the last thing you want to do is wrap it in process, that’s usually how a light gets dimmed.

I don’t know yet how theirs will go, it’s early. But, the reasons behind it are genuine, and if you’ve been sitting on the idea of starting one where you work, I’d say go for it. Just know the meetings are the easy bit, the rest of it takes longer to build.

Note: theres probably a lesson in here somewhere for new managers but i’ll tap into that a later time

I want to write about that because I don’t think all engineers really understand what’s happening on the other side of the table. I didn’t and I was an engineer for a long time.

How I used to see it

When I was an IC, I had a kind of unspoken belief that my manager should know what I was doing. Not in detail necessarily, but in shape. I assumed they had a picture of my work, that they were paying attention and that come review time they’d be drawing from that picture to assess me. Anything else felt a bit like cheating, like why should I have to tell my manager what I’d been up to, hadn’t they been there for it?

I also found the idea of selling myself a bit gross to be honest. Self-promotion was for other people, the politically savvy ones who cared more about their personal brand than the work. I cared about the work and I was going to let it speak for itself.

When reviews didn’t go the way I expected, I’d react in fairly predictable ways. I’d assume something political had happened, maybe my manager didn’t like me as much as I thought or the system was just rigged in some way I couldn’t see. The actual explanation, which I think is correct most of the time was alot more boring. My manager genuinely didn’t have a complete picture of my work and I hadn’t really helped them put one together.

What I see now

What I now know, sitting on the other side is that a manager sees a fraction of what their reports do. A small fraction. They see the meetings you’re both in and the work you talk about in your one-on-ones, plus whatever ends up in writing somewhere they happen to read. The rest of your week is mostly invisible to them. The conversations you had with another team to unblock something, the bug you fixed before it hit production, the mentoring you did in DMs, most of that just doesn’t reach them.

This isn’t really a flaw in the manager, it’s a property of the job. A manager with a dozen or more reports can’t watch all of them work all of the time, they’re also doing their own job. The picture they have of any one engineer is a small set of observations stitched together with whatever the engineer tells them. (A manager who only ever rewards the work they happen to see is doing the job badly, to be clear and part of my job is actively going looking for the work that isn’t reaching me. But even done well, the picture is partial.)

The invisibility problem is worse now than it used to be, too. On a distributed team there are no hallway moments, nobody overhears you helping someone through a problem and the work that used to be ambiently visible in an office just isn’t anymore. Everything your manager knows about your week is whatever made it into writing or into a call they were on. Remote work has alot of upsides but this is one of the costs, the surface area through which your work gets noticed shrinks.

When review time comes, that picture is what gets reviewed. The engineers who’ve helped their manager build a clear, accurate picture get reviewed on something close to reality. The engineers who haven’t get reviewed on whatever the manager could piece together. The difference between those two reviews can be significant and the engineer is rarely aware that the difference exists.

The other thing I see now is what actually happens in calibration meetings. Most companies do some version of this, managers in a room agreeing on a distribution of ratings or promotions across the org. As an IC I had no real visibility into this and assumed it was just managers making decisions about us. What it actually is, in practice is managers advocating for their reports, and the quality of that advocacy depends entirely on what the manager has to work with. An engineer whose work is visible has a manager who can speak about them specifically. An engineer whose work isn’t has a manager who’s working from a vaguer sense.

This is the bit I wish I’d understood as an IC. When I was upset about a review outcome, the conversation that had actually decided it happened weeks earlier in a room I wasn’t in. My manager hadn’t been able to make a strong case for me because I hadn’t given them the material to make one. That wasn’t a political failure on their part, it was just how the system works, and I hadn’t really engaged with it.

What to actually do about it

The thing I’d tell my past self is that the engineers who grow faster aren’t really the ones who are better at their jobs. They’re the ones who have understood that making their work visible is part of the job, and have built habits around it without making a big deal of it.

I want to be careful here because there’s an obvious way to read that wrong. I’m not saying the loudest person wins. The engineer who posts constantly about mediocre work isn’t the model and most managers can tell the difference between noise and substance pretty quickly (it’s one of the easier parts of the job actually). Visibility amplifies real work, it doesn’t substitute for it. If the work isn’t there, making it visible just makes that visible too.

That doesn’t mean self-promotion in the gross sense. What it actually means is just writing things down. Talking about what you’re working on, sharing the things you’ve learned or shipped, not because you want performance review credit but as a default mode of operating. If something is worth doing it’s usually worth a sentence about it somewhere your manager can see. The engineers who do this without thinking about it have a quiet advantage that compounds over years.

The difference between useful visibility and noise is a blurred line if you’re not used to it. “Worked on the payments migration this week” is noisy, it tells nobody anything. “Payments migration is unblocked, the issue was on the provider side and their fix ships Thursday, we’re back on track for the release” is useful, it carries the outcome, what you actually did and what it means for anyone downstream. One reads like a status update written because you had to, the other reads like someone who understands why their work matters.

One thing I’d recommend also is keeping a brag sheet. It’s exactly what it sounds like, a running doc where you note what you’ve been working on, what shipped, what you learned, what you’re proud of. It doesn’t have to be elaborate, a few bullets a week is enough. The point isn’t to use it as marketing material, it’s just good documentation. When review time comes you have an actual record to draw from instead of trying to remember six months of work in one sitting. When you’re updating your CV or talking to a recruiter you have something to pull from. When you’re not sure how you’ve been spending your time, you can look back and find out. It’s genuinely low effort and it pays back disproportionately.

For what it’s worth, this is something I now do with my own engineers from the other side. In the run-up to any review cycle, I’ll go through their brag sheets with them on a weekly basis to make sure everything is covered. I do it because I want to be as objective as I can when the review actually happens and the only way I know how to do that is to make sure I’m not assessing someone unfairly. If your manager doesn’t already do something like this, it’s a reasonable thing to ask for.

It also means having actual conversations with your manager about your work and where you want to grow, separate from the one-on-ones that should be about the bigger picture. Status updates belong in writing, in standups, in places your manager can find them later when they need to remember what you did. The one-on-one is for everything that isn’t easily written down.

That took me longest to understand is that this isn’t really politics, it’s translation. You’re translating your work into a form that other people can see and remember when you’re not in the room. That’s not gross, it’s just part of the job.

The wider frame

There’s something worth saying about the system itself before I wrap up. Performance reviews are an imperfect mechanism designed to do an awkward job, which is assigning differential value to people doing different things in different contexts. Stack ranking and forced distributions are one way to do that. They make sense from a business standpoint, especially if you’re trying to keep raising the bar over time. From a culture standpoint they can be tough, particularly if there isn’t enough high-impact work to absorb everyone who wants to make it. When that’s the case, ranking turns into a zero-sum thing and people start optimising for visibility instead of for work that matters.

I don’t think performance reviews are broken in the way alot of engineers think they are. I think they’re a trade-off and the experience of being in them is heavily shaped by whether your environment has enough impact to go around. Both things can be true at once, visibility is worth building as a habit and it’s worth noticing when your environment has tipped into rewarding the appearance of work over the work, because that says something about the environment rather than about you. The deeper version of that is probably a separate post.

The point of this one is closer to home. Your career is yours, your manager isn’t going to grow it for you and the system isn’t going to creating visibility for your work without your help. The engineers I see growing fastest aren’t necessarily the strongest engineers, they’re the ones who have figured out that their work needs to be findable by the people making decisions about them. Past-me hadn’t really figured that out.

Subscribe now

I knew the archetype well, earlier in my career I looked up to those people, they seemed free in a way the rest of us weren’t, they didn’t really care what anyone thought because they could back it up. They could be short in code reviews, dismissive in meetings, impatient with people who weren’t keeping up and the work would still flow through them because the work needed them. That looked like freedom from where I was standing… and I wanted a piece of it.

It took me a while to see what it actually cost them and longer to see that it wasn’t really freedom. It was a tradeoff that worked in a specific environment, an environment where technical excellence was scarce enough that companies would put up with almost anything to keep it. That environment is quietly going away.

The trade that used to work

The amazing jerk was a real working strategy. Trade the human side of the job for technical brilliance and you could have a long career. Hiring processes were built around it, mostly technical, sometimes a half-hearted culture interview at the end. Performance reviews tolerated it, because the outcomes were real and the alternative was losing someone hard to replace. Whole teams quietly built workarounds for these people, a colleague who handled the stakeholder conversations, a manager who softened the feedback and a PM who would pass messages through to the team on their behalf.

The tradeoff was rational from the engineer’s side too. The human side of the job is harder than the technical side for many engineers. It doesn’t have clean feedback loops, it doesn’t have right answers, it can’t be debugged and generally feels alot more abstract than a majority of the job. If you could just not do it and still keep your seat in the chair, why would you? So they didn’t and the system absorbed the cost.

The other side of it

The amazing jerk is one version of the pattern. The dinosaur as I like to call them is the other. Same underlying characteristics, different outcome. Senior engineers with enough tenure and authority to decide things have to be a certain way and enough fear of being obsolete to make sure nothing really changes. They’ll defend a process that doesn’t work anymore. They’ll resist a tool that would help. They’ll cite experience as a reason not to learn anything new.

It’s tempting to write about them as if they’re cynical, but most of them aren’t. They’re scared. They built careers in one era and they can see the next one coming and they don’t have a clear sense of whether their skills travel. The way the fear shows up is by clamping down on what they can still control, which is the way the work gets done in their immediate domain.

The amazing jerk and the dinosaur look different but they’re doing the same thing. They’re protecting a position by opting out of the human side of the job. One does it through technical brilliance and arrogance, the other does it through tenure and authority. Both got away with it for a long time.

What’s changing

The thing that’s changing isn’t the work, it’s what’s distinctive about doing it well. When the technical side of engineering was scarce and hard to verify, technical excellence was the thing companies paid for and protected. That’s been shifting for a while now and the shift is accelerating in a tech world dominated by AI. The technical side isn’t going away, but it’s increasingly the floor rather than the differentiator. Agents will handle more of it. The bar for “can you code” will become “can you direct what’s getting built and why.”

That changes what companies pay for. Increasingly it’s the work the amazing jerk opted out of. Framing problems clearly. Working across functions. Pushing back diplomatically. Translating between people who hold different parts of the context. Building trust across a team that’s spread thin. None of these are technical skills and all of them are getting more valuable.

I ask a question in every culture-fit interview at work. If you could wave a magic wand to make a team great, what characteristic would you give it. I’ve asked dozens of engineers this. Almost all of them say collaboration. Not technical excellence. Not autonomy. Not speed. Collaboration.

Engineers themselves know what they want to work with and it isn’t the amazing jerk. It never really was, but the work environment used to make their preferences irrelevant.

What I see now

The thing I find interesting is that the people inside the pattern often don’t see it changing. The amazing jerk still believes that the work is the work and the rest is noise. The dinosaur still believes that experience and authority are protection. Both are true and less true than they used to be. The environment they relied on is being remodelled around them, slowly enough that they can ignore it for a while.

I don’t admire the archetype anymore but I get the appeal. The work was hard, recognition was uneven and the people who seemed to opt out of the social cost of all of it looked like they had it figured out. They hadn’t. They’d just found a tradeoff that worked in a specific market. The market is changing and the tradeoff is changing with it.

If you’re an engineer reading this and you recognise either pattern in someone you work with, the more interesting question is whether you’ve been quietly modelling after them. I did, for a while. It looked like the path. It wasn’t

Share

There’s another side of it though and I think it’s the more important one right now. Engineers I coach across different companies are starting to describe a kind of weariness that doesn’t really come across as burnout or exhaustion. They can still do the work, they’re not in crisis but something has shifted in how the job feels to them (especially the ones who centre their purpose around the quality of code). I’m hearing it from people who don’t know each other and work in completely different companies, so it’s probably not just a them thing.

What they’re describing is something like this: AI agents are producing alot more code than anyone was a year or two ago and that code goes through pull requests like all other code, but the PRs are larger, more frequent and the people sending them haven’t always read them carefully before pressing the button. The reviewers on the other end are spending more time reviewing than they used to and the time feels.heavier because they can’t really extend the usual trust to a colleague’s code when the colleague might not have written it. So they read more carefully, find things, send it back, read again, find more things, send it back again. Each time it costs them attention they used to spend on their own work.

The companies they work for are measuring AI adoption in different ways. Sometimes it’s token spend, sometimes it’s PRs shipped with AI assistance, sometimes it’s a dashboard nobody really knows how to read but everyone knows is being looked at by someone higher up. The message that comes through though is basically the same. AI is supposed to make things faster and faster is supposed to be visible.

That message is obviously hard to push back on, AI is bringing a value to our daily lives we didn't have before. Slowing things down to review properly is the right thing to do, but it makes you the bottleneck on a dashboard somebody is watching or a new expectation a team may have. Holding the quality bar where it used to be is the right thing to do but it doesn’t really show up anywhere that anyone is measuring (and why should you care eventually?).

So the quality bar continues to lower, not because anyone decided it should, just because the system has quietly stopped accounting for it. The engineers who care about quality keep doing the work of caring, mostly alone. The ones who’ve adjusted to the new pace approve faster. Things ship, KPIs look right and the reviewers absorb the difference between what the dashboard says is happening and what’s actually going on.

This is what the tiredness is created from, as far as I can tell. Not exhaustion from the work itself, more the exhaustion of holding a standard the system has stopped appreciating. Of doing more reviewing than building, of catching things that shouldn’t have needed catching because the person who creates the code didn’t read their own change and of watching that bar move while you try to to still hold it to certain standard like before.

The thing that makes it apparent for me is that the usual response doesn’t really work. When a job stops feeling meaningful in the way it used to, the move people make is to look for a better one. That option isn’t really available right now. Hiring is tighter than it has been in years, layoffs are in the background of every conversation and the engineers I coach mostly know that walking is a bigger risk than staying. So they stay and something inside their day to day changes.

This is the human side of engineering that the AI conversation has barely touched. Most of the discussion treats engineers as productivity units that should now be more productive. The actual people doing the work are a more complicated story. They’re now owning a shift in what their job is, with less time to do their own work, less trust in what they’re approving and less ability to push back on either without paying for it. The dashboards don’t really catch any of this, but it is there in the conversations.

A few things that seem to help

I don’t think there’s a systemic fix any individual engineer can apply. The conditions producing this are above the level of one person’s choices. That said, the engineers I've noticed handling it best tend to share a few small habits and they’re worth sharing as things you can do at the level you actually control.

The first is reviewing your own AI-generated code before you push it. This sounds almost too obvious to say but it’s the discipline that’s quietly going missing in alot of teams. It could be to delivery pressure, a lack or care or something else. But, If you’re using an agent to write code, treat the output the way you’d treat a junior engineer’s PR. Read through it properly and push back on the bits that aren’t quite right (or fix them yourself) before sending it on. The amount of reviewer attention you cost when you skip this is significant and you’ll feel some of it coming back at you in worse code from other people doing the same thing.

The second is finding one person you can relate to this with. Not a manager necessarily, just a peer who’s seeing what you’re seeing. The thing that makes it corrosive is feeling like you’re the only one experiencing it, like maybe it’s a you problem. Saying it out loud to someone else is most of the relief. The work conditions don’t change but the experience of being in them does because most of what you lose when something is happening quietly is just the ability to identify what you’re feeling.

The third is being honest with yourself about what you’re trading. If you’re approving things you’d have pushed back on a year ago, just notice that. You don’t have to fix it overnight, you don’t have to be the hero who slows everything down, you just need to see what’s actually happening. The bit that hurts most is when the quality bar drops without you noticing and one day you realise you’ve stopped caring about something you used to care about and you don’t really know when that happened. Keeping it in front of you, even quietly, is what protects you from drifting further than you meant to. You don’t have to act on it, you just have to see it.

Subscribe now

None of these fix the industry condition and they’re not really meant to. The metrics aren’t going away. But, the engineers who are handling this best aren’t doing it with better techniques. They’re the ones who can name what’s happening without making it about them (and have the confidence to tell me in private). They know they’re not the problem and they know they’re not failing at their jobs. That knowledge is most of what keeps the tiredness from turning into something worse.

When I was an engineer, I used to end days that I’d describe as busy but not productive. I’d been in meetings, I’d answered Slack, I’d reviewed PRs, I’d unblocked people, I’d done all the visible stuff I thought I needed to do.

But, the thing I wanted to actually sit down to do, the refactor or the bit of design work was still sitting there, half-started. By the time my calendar said the day was over my brain felt fried.

I used to think that was just what a senior engineering job felt like. Looking back, it was the cost of context switching, and I was paying it almost every day without really clocking it.

The maker’s schedule problem

There’s an idea created by tech investor Paul Graham, that there’s a maker’s schedule and a manager’s schedule and they don’t really mix. On a manager’s schedule a day is a series of 30-minute slots and the work is mostly conversations, so a meeting in the middle of the afternoon doesn’t really cost you anything, it’s just another slot. On a maker’s schedule a day is one or two long stretches of focus and a meeting in the middle of the afternoon doesn’t cost you the meeting, it costs you the whole afternoon because you can’t really get back into the thing you were doing before it.

I now sit on a manager’s schedule, mostly. My day is meant to be conversations. So when something fragments it, it’s not the same problem. But when I was an engineer I was on a maker’s schedule and I didn’t really know that’s what I was on. I just kept agreeing to things, the way I’d always agreed to things and wondering why none of my own work was getting done.

The yes problem underneath it

The honest thing is that context switching wasn’t really the root cause for me. The root cause was that I said yes too much. To meetings, to favours, to “quick” questions, to anything that came in. Context switching was the visible symptom, fragmentation was the experience of it but the actual mechanism was a calendar I’d let other people fill because I didn’t want to be difficult.

I’ve written about this before in the context of burnout, which is where this story eventually goes. I burned out a few years into being a senior engineer. Not in a dramatic way, just in the slow grinding way where you stop being able to care about the work, and then you stop being able to do the work, and then you have to take time off to figure out what happened.

Although, when I look back at what got me there, the calendar I’d let other people fill is one of the biggest things on the list. Every yes was another context to hold. Every context cost me something to load and unload. And once you’re tired enough that you can’t load and unload cleanly, the work starts coming out worse, which makes you doubt yourself, which makes you say yes to more stuff to compensate. It loops.

What I’d tell that version of me

If I could go back and tell my engineer self one thing, it wouldn’t be a productivity framework. It would be that the calendar isn’t a neutral surface. Every meeting on it has a cost beyond the time it takes. Every “quick chat” that interrupts a focus block has a cost beyond the chat. And, the only person who can defend the calendar is you, because nobody else can see what’s on it the way you can.

The specific things I wish I’d done are mostly small. Blocking actual deep work time in the morning and treating it as immovable, the way I’d treat a meeting with my skip. Batching Slack into a couple of windows instead of leaving it on all day. Saying no to recurring meetings I was in out of habit rather than need. Leaving myself a two-line note at the end of any focus session about where I was and what I was about to do next, so that when something pulled me away I could come back without burning twenty minutes remembering.

None of these are new ideas. The reason I didn’t do them when I was an engineer wasn’t that I didn’t know about them. It was that doing them felt like I was being precious about my time and being precious about my time felt like a status move I hadn’t earned yet. I thought senior engineers said yes to things and were available. So I was available and I burned out.

What I see now

The bit I really wish I’d understood is that being protective of your focus isn’t a status thing. It’s just how the work gets done. The engineers I now see shipping the most aren’t the ones who are always around in Slack. They’re the ones who are around in bursts and otherwise quiet because they’re doing the thing they came here to do. From the manager seat, I appreciate those engineers more, not less, because their work compounds because they create the time and energy to focus on the problems they are solving, rather than the output they provide.

I also see the other side of it now, which is that some of the meetings I attend as a manager are the ones fragmenting somebody else’s day, and I try to be more careful with that than I was when I was on the other end of it. Not always successfully. But more carefully.

The post I wanted to write a few years ago was a productivity framework with a checklist at the end. I’m glad I didn’t publish that one. The actual post, the one I needed to read, is that context switching is real and it costs you, and the cost compounds quietly until one day it isn’t quiet anymore. If you’re an engineer and you’re feeling the version of this I felt, it’s worth taking seriously now rather than later. Saying no is the work. Defending the calendar is the work. Most of the things on it that you’re saying yes to without thinking aren’t actually requests, they’re defaults, and defaults can be questioned.

Subscribe now

I’ve spoken about this before

I’ve spoken about the mental debt you pay when you say yes too much, or how you communicate with others. You can read it below:

It isn’t isolated either. Block cut nearly half its workforce earlier this year on similar reasoning. Pinterest, CrowdStrike, Chegg have all done versions of the same. Almost half of all tech layoffs in Q1 were attributed to AI.

I read about it and the vision of where the industry is going gave me almost aha moment. They’re describing at scale the skills I had to learn through a restructuring at Trade Republic two years ago, except theirs is happening a lot faster and with less room to figure it out as you go for engineers feeling the impact.

The TPO part

I joined TR over three years ago originally as an Engineering Manager. A year or so in, the company restructured how engineering and product worked together, which meant EMs transitioned into either tech lead roles (as ICs) or into TPOs (Technical Product Owners). I ended up on the TPO path. I didn’t really choose it, it just became the next thing.

When I was first told, I wasn’t happy about it. I’d just got my feet under me as an EM and now I was being moved into something that on paper looked like a product job, not something that was part of my three year vision.

I will say though, the setup at TR is a bit unusual: POs here are people managers and the technical part of TPO means I’m also working as tech lead. So I run engineering teams, own the product side and lead the technical direction. All at once.

What I had to learn was the part of the job most engineers, including me at the time, kind of treat as somebody else’s problem. Roadmapping, prioritising, working out what was actually worth doing in six months when there’s a long list of reasonable things you could spend the team’s time on instead. None of that was code, but it was doing more for the team's outcomes than my code ever had.

I was in a position where I had no real choice but to learn it and once I did I couldn’t really go back to thinking the engineering job was just the engineering job. With reflection, it was probably the most useful thing that’s happened to my career.

The shift

I’m not the best engineer on the teams I manage. I’m not even close and that’s fine by me. The job isn’t really being the best engineer, it’s making the engineers around me ship better than they would have alone.

What that means in practice is reading where the business is heading, understanding what makes the engineers in the team effective and happy and trying to keep the two facing the same direction. My output isn’t code anymore, it’s their code shipping in service of something that’s actually going to matter in six months when we look back at it.

I came up in my career through mobile over a decade ago (back when it was trendy), but with this shift I stopped thinking of myself in respect to a tech stack. I was thinking more about what the users needed and what the engineers needed to be able to ship for them. That’s it.

One of the harder parts of the job has been deciding when not to do something. Engineers would ask for things that were genuinely good ideas, useful and well-argued, the kind of request where saying no really makes you feel like you’re holding things back. Better internal tooling, an overdue refactor etc... Some of those I held off on, mostly due to timing. Six months later we were shipping faster because we hadn’t taken on that load when we couldn’t afford to carry it. I didn’t always know whether it was the right call at the time of making it, I just had to know what we could absorb without slowing down the things that mattered most.

You spend a lot of time weighing what’s coming against what your team can actually carry, and the saying no isn’t really the hard part. The hard part is living with the call for the next six months while you wait to see whether you got it right.

The same job, with agents

The bit I don’t think gets said enough is that none of this is only about engineering leaders managing other engineers. The same skills are what you’ll need in the near future, if you’re an engineer working alone with a fleet of agents instead of a team of humans.

Deciding what’s worth building. Course-correcting when something’s going off track. Saying no to things that look reasonable in isolation, but, are wrong in context. That’s manager work either way. Even moreso with agents, because they don’t tire and they will produce a lot of confidently wrong things if you point them at the wrong problem.

The point of failure with a team of humans is people pushing back, work slowing down and team alignment is off track. These are things you can easily identify. The point of failure with agents is more ambigious, they’ll happily ship a hundred PRs against the wrong objective and never tell you it was wrong. That’s not less management, that’s more. The skill of holding the whole problem in your head and saying “we’re not doing that” becomes paramount to your role.

So when I say these skills matter more now, I don’t just mean for people who want to be EMs. I mean for any engineer whose day to day is starting to look like managing outputs with agentic development more than writing them, which will be a lot of us, whether we wanted it or not.

What to invest in

If you’re trying to figure out what to put your time into from where you are now, my view is there are two areas worth pointing yourself at and neither of them is really technical.

The first is product judgement. Not the way a PM thinks about product, but the way an engineer with context thinks about it. The ability to look at a list of reasonable things to build and pick the ones that are going to matter in 1, 3, 6 months. To read where the business is heading and translate that into what the team should and shouldn’t pick up. To push back on a good idea with “not now, here’s when” instead of just yes or no. The engineers who can do this are the ones who shape what gets built rather than just building what they’re told. Same goes if your team is mostly agents. They’ll happily build what you point them at, so what you point them at becomes the entire job.

You build this by watching the people who’ve been doing it longer and paying attention to what they say no to, and why. Small calls help too, you make them and stay honest with yourself about the ones you got wrong. The other thing is paying attention to the company outside your own function. If the company has a focus, a roadmap, all-hands, you can read those for what’s actually being prioritised and then ask yourself how your work contributes to it. Most engineers don’t really do this, they just look at the work in front of them, but the ones who do start to see what’s worth picking up before they’re told.

The second is stakeholder management, which sounds more corporate than it really is. What it actually means is working with people whose job is different from yours, figuring out what they actually need (which is almost never what they say they need) and building enough trust that your decisions get backed rather than second-guessed every time. As more of what used to be split across PM, design, and engineering folds into one role, this becomes a lot more of the day to day. And it doesn’t go away when half your team is non-human. If anything it concentrates, because you become the one human point of contact for everything your “pod” ships.

In practice this looks like people coming to you before they make a decision, not after. Surfacing a risk to your boss before it becomes a problem, not while you’re explaining one. Knowing the difference between what someone is asking for and what they’re actually trying to solve and addressing the second one. None of this is in a framework. You learn it by getting it wrong a few times. Someone tells you what they need, you build it, they come back disappointed because what they needed was actually something else. Do that enough times and you start asking different questions up front.

These aren’t soft skills. They’re the skills the job is becoming.

Closing thought

The role I didn’t really want taught me both of these things (and more) and I’m grateful for it now even though I wasn’t at the time. If you’re trying to figure out where to focus, my honest answer is it’s not the next framework or the next language. It’s the bit further up from the code, the work of reading what’s coming and trying to shape what gets built in service of that.

Mine got chosen for me. Yours probably won’t. But, the skills are worth picking up before the choice gets made for you.

Subscribe now

I was there because Trade Republic has recently opened an office in Paris, and are hiring engineering talent there to keep up with their growth. I invited a few engineers from the team to come along to help me and the recruiters run a booth across the two days. Between the booth and a talk we ended up speaking to alot of impressive people.

The booth itself was compact, placed in the corner between Maestro and Stripe. We ran an Android quiz and a virtual prize wheel for swag and a few mirror cards.

What I was actually nervous about was the talk.

The Talk

I was partnered with Matthias Baccino. Matthias is a Senior Advisor at Trade Republic, a best-selling author, and well known in financial circles in France. He’s done alot of TV. Polished, well rehearsed, at home on a stage. I’m not so much. The most I have really done is internal talks and some low-key meetups in the past.

The format was a two-voice talk. Matthias was there to tell the story from the business and community side. I was there for the product and engineering side. The whole thing was designed as a back and forth, where each of us would set up the next bit of the story for the other to pick up. It meant the audience got both perspectives on the same events, which is a hard thing to do in a single-speaker talk.

The talk itself was about how the Trade Republic app went from doing one thing well to doing many things at once from the perspective of Android.

One account, one portfolio, one currency in Germany, to multi-account, multi-portfolio, multi-currency across eighteen European markets. The arc of the story? We had a public backlash in the middle: a huge rewrite of the app that, when we launched it, produced 90,000 one-star reviews in two weeks. We then ran a war room to address the biggest issues users were reporting and came up with solutions that scaled. The story was about why we had to do the rewrite, what went wrong, and what it eventually allowed us to do to get to where we are now. We opened the talk with that number. One slide. Just “90,000.” Those were my first words on stage, before any of us introduced ourselves.

The preparation

Leading up to it with Matthias is where I really learned something.

He gave me a kind of crash course in public speaking. The first thing he said was:

It sounds harsh out of context, but it was exactly what I needed to hear. People new to public speaking make the talk about themselves. They’re thinking about how they look, how their voice sounds, whether they’re going to forget their lines. All of that energy is wasted, because the audience doesn’t really care about you. They care about whether you’re giving them something worth their time. Once you flip the focus from yourself to them, alot of the fear goes away.

That was just the beginning of our conversation, Matthias was full of gems and that's why I'm imparting that knowledge onto you. He mentioned more tips:

The first was about getting on stage. Anyone who walks on stage afraid of public speaking will lose half their IQ in the first few minutes, so you need a way to ground yourself before you go up. Don’t check Slack, don’t scroll, don’t take any inputs. Find a moment to breathe. Learn the first sentence and the last sentence by heart, with clear notes for everything in between.

The second was about finding a place to perform from. Acting, but not in a fake way. More like, find a context where you already feel confident and clear, and bring that energy with you. For me that’s job interviews. I do alot of them at work, probably a couple of hundred a year, and I’m always there to provide value to the candidate. I speak clearly, I think clearly, I have well rehearsed lines about what we’re building and where we’re going. Realising I already had a “good speaking” mode I could pull from gave me something real to work with, I hadn't really connected the two before this.

And finally, he mentioned finding one person in the audience to focus on, someone you keep coming back to when your eyes start drifting around the room. Someone to come back to when your attention scatters.

On the day, the talk was a relief I didn’t really see coming. I felt good on stage. No IQ drop. I think it was because my last public speaking experience was a positive one (internal in the company), so this time I had something recent to go into the room with. The interview mode thing worked alot better than I expected. I spoke clearly, slowed myself down on purpose, and pushed it almost to the point of feeling uncomfortably slow because the audience was heavily French speaking. Slowing down when you already feel fine is harder than it sounds, but I think it made the talk easier to follow than it would have been otherwise.

Having Matthias on stage with me also took some of the pressure off in a way, but I expected that having spoke with him a few times prior. I wasn’t the only voice in the room. Between my sections I could listen, breathe and find myself again before coming back in.

Overall, I’m proud of how it went. We told a story most engineers in the room hadn’t heard before, the back and forth with Matthias worked, and I walked off stage feeling like I’d actually done the thing I’d been nervous about. The feedback we got afterwards was that people who already used the product appreciated finally hearing the story behind it, because to many it was dramatic. That mattered to me.

A few things I’d do differently next time. We went over on time, which caught me off guard at the end. I had a five-takeaways slide I was meant to walk through cleanly, and instead I rushed it and gave my own high-level summary while the slide sat behind me. There were also a couple of moments mid-talk where I said things I cringed at later. And honestly, the talk wasn’t as technical as I’d have liked. It went more into storytelling than into the kind of detail engineers could take back to their own work. I was an EM during the rewrite, shaping the work and jumping into code now and then, but not doing the heavy lifting day to day. That’s why this version had to stay where it did. The next one I’d love to give with an engineer who actually lived in the code, told from a purely technical angle.

If you want the full story behind the 90,000, AndroidMakers will be publishing the video in the near future. I’ll be sure to share the link via my profile when it’s out.

I came home from Paris feeling like I had accomplished something. The fear didn’t go away, but it became something I knew how to handle. Matthias’s advice actually works.

If you like what you read, feel free to subscribe to stay up to date. I post stories on my journey as an engineering leader to help you become a better Human and Engineer in the world dominated by AI.

Subscribe now

The pieces were taking me forever. Each one would end up being 2000+ words of synthesized advice on productivity, communication or leadership. The systems were fabricated to help polish the newsletter (I was still following the advice, but not in such a regimented way). Which meant they weren't truly representative of the day to day issues I faced, it was mostly about what reads the best or coached the best. They were good and I'm proud of them, but writing them took alot out of me.

Then in June last year, I got an ADHD diagnosis at 32 and that kind of consumed most of the mental energy I had outside of work. The newsletter just sort of faded. I didn’t really decide to stop writing, I just stopped showing up to do it.

Alot has happened since though. I got promoted, so now I lead both the mobile and web platform teams at work instead of just mobile. I’ve grown alot as a leader and I think as a person. I feel alot more authentic, generally.

The original Human Engineer was about engineers learning the soft skills, but honestly the way I was writing about it wasn’t really working for me. I was kind of writing like I had things figured out, when I was just in the middle of stuff, same as everyone.

So here’s what The Human Engineer is now.

It’s a working journal of being human while being an engineering leader. If you’re earlier on the path than I am, hopefully some of what I’m working through can save you some time. It’s not going to be the big synthesized takes anymore. Smaller pieces, more in-progress stuff. The diagnosis changes how regimented I’ll be about it, not what I’ll write about. So shorter, less polished, more about what’s actually going on for me at the time.

What I want to write about is just whatever’s coming up day to day. Like the first time I led a project and didn’t really know what I was doing, doing public speaking when it’s not really what you signed up for, starting and pivoting a tech company and what building one taught me, the meetings where I realise I’m the bottleneck and the clear red flags I ignored. Plus alot of Claude Code stuff because I’ve been deep in that lately.

Some of these will be 500 words. Some will just be one specific moment unpacked a bit. The point is I write them and you read them and we both come away knowing something true about engineering as a thing you actually live, not just a craft.

I want this to feel like a colleague writing to other colleagues, not me trying to coach anyone. I’m figuring stuff out. You probably are too. Hopefully some of what I share is useful and hopefully it goes the other way too.

If that sounds like the version you want to read, glad you’re still here. If not, no hard feelings, you're welcome to unsubscribe.

Subscribe now

Next post

About a talk I gave at AndroidMakers by Droidcon in Paris recently, and how I prepared for it.

You want to speak up but you tell yourself it’s not worth it. Not now? Not in front of everyone.

So you let it slide.

Weeks later, that same concern reappears. Except now it’s a full-blown issue. Deadlines are at risk. People are frustrated. And the solution everyone is scrambling toward? It’s the one you were quietly worried about from the start.

This is a follow-up to a previous piece I wrote on engineering conflict, there I spoke about how technical tension often masks deeper misalignment. That focuses on recognising the root causes. This one’s about delivery.

What to do in the moment when something feels off. How to verbalise early and turn discomfort into collaboration, without starting a fight.

The Pattern You Know Too Well

Engineers aren't conflict-avoidant by nature. We're debugging machines. We are builders and we spot the broken patterns, the edge cases, the technical debt everyone else ignores. Although, we've learned through painful experience that pointing out what's wrong gets you "rewarded" with fixing it, endless meetings that solve nothing, or the dreaded "not a team player" label.

So we adapt. We get strategic. We try to share the problem without fully stepping into it and owning it. But, here’s a reminder, that silence is louder than you think.

Every time you swallow a concern, you’re making a bet that someone else will catch it, that it’ll sort itself out or that misalignment is easier than keeping the status quo.

The truth? Healthy conflict isn’t dysfunction. It’s maintenance. It’s the unit testing for teams. It’s how teams catch misalignment early before it becomes expensive and let's be honest, the real engineering threat isn't having the tough conversation now, it's everyone becoming misaligned later.

So, how does this type of avoidance take shape? If you’ve been in engineering long enough, you’ve likely seen them. Maybe you’ve even been one of them:

• The Overexplainer: dives deep into technical detail, hoping others connect the dots

• The Diplomatic Nudger: nods in meetings, then follows up with a carefully worded message asking if anyone else felt “uncertain”

• The Steamroller: doubles down on their position with extra confidence to avoid debate

• The Passive Reviewer: leaves vague comments like “Could this be clearer?” when they’re worried the approach has a fundamental flaw

Each one is trying to surface a concern without taking ownership of the disagreement itself and here’s where that gets expensive: buried conflict doesn’t disappear. It metastasizes.

You’ll feel it in:

• The long pauses when a project gets pitched

• The DMs that ask, “Did that feel off to you too?”

• The teammate who checks out, not because they don’t care, but because they stopped feeling heard

And when it finally surfaces? It comes with a bang.

The Language of Healthy Conflict

The shift happens when you stop avoiding discomfort and start turning it into collaboration.

That moment in the meeting where your stomach tightens? That’s not random. That’s a sign. When your gut says, “This isn’t sitting right”, it’s not always because you have the answer. It’s often because you’re seeing something others aren’t saying out loud.

The skill isn’t just speaking up it’s learning how to disagree in a way that deepens alignment, rather than disrupting it.

💬 “I might be missing something, but, I’m seeing a potential gap between X and Y. Can we spend two minutes on that?”

💬 “It sounds like you have a specific concern. What would need to change for you to feel confident about this?”

💬 “Before we move forward, what questions aren’t we asking?”

These aren’t arguments. They’re invitations. They turn disagreement into curiosity and they shift the energy from dancing around the issue to having the real conversation.

But, words alone aren’t enough. When you use them matters just as much as the how:

In a group meeting

You want to reduce the perceived cost of disagreement. Don’t fake it. Don’t lecture. Just add a small pause:

💬 “Can I play devil’s advocate for 60 seconds?”

💬 “I’m wondering what we’d miss if [assumption] turns out false.”

💬 “Is there a tradeoff here we’re not naming yet?”

Framing the question as time-boxed or exploratory lowers the risk. It tells the room: this isn’t derailment, it’s due diligence.

In 1:1s or small rooms

Here, trust carries more weight. You can be a little more candid:

💬 “I’ve been sitting on a worry about that approach. Would you mind walking through it with me?”

💬 “What’s the thing we’re both seeing but haven’t said yet?”

Sometimes the best move isn’t a statement, it’s an honest question.

In code review

This is where avoidance thrives. “Could this be clearer?” often means, “I think this might break.” Instead:

💬 “What happens if input X violates assumption Y? That’s the part I’d worry about.”

💬 “This makes sense, but I wonder if it hides the risk around Z. Worth being more explicit?”

When you're not sure if you're overthinking

You don’t need a 100% formed opinion to speak up. Try:

💬 “This might be nothing, but I had a weird feeling about…”

💬 “I’m not confident I’m right, but I think it’s worth pressure-testing.”

These phrases give you a way to participate without faking. They show you care enough to say something, even if you might be wrong. Over time, the way you speak shapes what your team believes is speakable.

If people can challenge each other without fear, alignment becomes a choice, not a compromise.

What Great Engineers Practice Early

Most engineers don’t wake up ready to handle high-stakes conflict. They build that skill in small, forgettable moments. The ones that don’t even feel like conflict.

You catch it in standup, when someone says they’re blocked and you ask one more question before moving on. In code review, when you choose to name what’s really bothering you instead of masking. In a kick-off, when you pause before the group moves on and ask, “What are we actually trying to achieve here?”

These choices aren’t flashy, but, they compound over time. They train the muscle that separates engineers who just execute from engineers who help their teams think better together.

And when you stop practicing them, the signs show up fast:

• You feel friction, but no one names it

• A decision feels rushed and you’re unsure why

• People start defending positions instead of exploring options

These aren’t signs of alignment. They’re red flags dressed up as harmony.

Most conflict in engineering doesn’t start with raised voices. It starts with a moment someone avoids. A project without clear ownership. A teammate whose concern gets brushed past. A tradeoff no one bothers to question.

And when those moments go unaddressed, they don’t disappear. They fester. Then they explode.

What separates the dependable from the impactful isn’t how smoothly they avoid conflict. It’s how skillfully they engage with it.

Subscribe now

Try this in your week ahead:

• Name a tension, even if it’s subtle

• Ask one more question than you normally would

• Say the quiet thing out loud

Share

What’s one conversation you’ve been avoiding that could prevent a bigger problem later?

Hit reply and let me know.

Leave a comment

You tell yourself it's temporary. That once things calm down, you'll get back to the real work.

But eventually, you realize:

If you work in tech, change isn't the exception. It's the environment. And the real work isn't avoiding it, it's learning how to move through it.

One of the bigs ones In my career was when Trade Republic removed the Engineering Manager role and replaced them with Technical Product Owners (as managers) and Tech Leads (as ICs). I found myself doing a complete shift from Engineering to Product, a shift I never planned for. At first, I resisted - why would I want to work in Product? I was worried I'd lose technical credibility. That I'd drift too far from the work that mattered to me.

But, stepping back gave me something I hadn't expected: perspective. I started working closely with product and business. I zoomed out enough to help shape the mobile organization as a whole and shifting away from the execution mindset to the product mindset, focusing more on the why instead of the how.

I then realized the skills I was learning around influence, strategy, and team design weren't a step away from engineering. They were part of growing into the kind of engineering leader I actually want to be.

That's when it clicked: You don't fix the chaos. You help people move through it.

When calm becomes a trap

Stability is a badge of honour. Something you've earned. You've built trust and it feels calm, you’re finally able to sit down and do the work you want, right?

So you start hoping for a quarter without churn. Some room to breathe. Something steady and predictable.

But senior roles don't come with stillness. They come with exposure. The more senior you are, the more you see. The more you see, the more you carry.

And the more you try to wait it out, the more disconnected you feel. You're not shaping the system. You're reacting to it.

Calm feels good. But over time, it quietly slows you down.

Stable teams stop asking hard questions. Processes drift from reality. Engineers prioritize familiarity over impact.

You don't notice it right away. You're still getting things done. You're still delivering. But over time, cracks spread. And by the time you see them, they've been there a while.

💡Try this: Quietly ask yourself, “What’s one thing my team’s still doing just because it’s familiar?”
You don’t need to call it out. Just noticing it is the first step toward change.

What resisting change really looks like

You've seen this. Someone checks out after a re-org. Another engineer clings to an old way of working. Teams keep asking when things will "go back to normal."

But the truth is: when you resist change, your influence shrinks. And when that happens, it doesn’t just slow you down, it slows your team down too. You go narrower. You get left out of decisions. You stop being part of shaping what comes next.

💡 Try this: Before you check out of the next change, pause and ask:
“What do I actually know about what’s happening?”
Most people disengage from stories they haven’t tried to understand.

The skill nobody taught you

Change doesn't just test your patience. It reveals how you show up.

• Do you wait for clarity or help shape it?

• Do you stick to what you know or spot what's shifted?

• Do you tighten your grip or adjust your posture?

The engineers who thrive don't have more answers. They're just more honest about what's real. They sense what's changed. They read the room and they act from awareness, not anxiety.

That's not a soft skill. That's leadership.

It's not about staying calm. It's about learning to read what's actually happening.

• Pattern recognition: What kind of change is this? A shift in leadership? Market pressure? Org politics? What's underneath it?

• Influence mapping: Who's making decisions now? What do they care about? How can you help them succeed?

• Communication: How do you turn ambiguity into clarity, not just for yourself, but for others?

These aren't soft skills. They're survival skills and every engineer can learn them.

Four ways engineers respond to change

When things start shifting, most engineers default to one of these:

1. The Fixer
Heads down. Keep shipping. "I'll just focus on what I can control."
What this looks like: Stops attending planning meetings. Avoids Slack channels with "too much noise." Ships features but loses context on why they matter.

2. The Cynic
Checks out emotionally. "I've seen this before, it'll change again in six months."
What this looks like: Eye rolls in meetings. "This too shall pass" comments. Technically present but mentally elsewhere.

3. The Frustrated Optimist
Wants to contribute but feels blocked. "I'd love to help, but nobody tells me anything."
What this looks like: Asks great questions that go unanswered. Offers solutions that get lost in bureaucracy. Gradually stops trying.

4. The Calibrator
Stays present through the uncertainty. Helps others find their footing.
What this looks like: Names what's changed and what hasn't. Asks clarifying questions in public. Translates confusion into actionable next steps.

You don't try to fix the chaos. You help people move through it.

That's the difference. Do it consistently, and people start turning to you not because you have all the answers, but because you help them keep going when things get murky. Not for certainty, but, because you make things feel possible again.

💡 Try this: Think back to the last messy change your team went through.
Which of the four roles did you slip into?
Would you handle it the same way next time?

This is the job

You didn't get here by waiting for clarity. You got here by making progress without it.

You weren't hired to work in ideal conditions. You were hired because you can keep the work moving, even when it gets hazy.

That means:

• Working without all the answers

• Collaborating through discomfort

• Letting go of systems that no longer fit

• Staying present through the reshuffle

It's not just about building the right thing. It's about helping people keep building when everything around them shifts.

Change isn't a detour. It's the road.

Know someone stuck in the storm? Forward this their way.

You might be the clarity they’ve been waiting for.

Subscribe now

The takeaway

The next time something shifts: priorities, structure, leadership, ask yourself:

What's true now?
Forget the last quarter. What's changed today? What's still solid?

What's missing?
Is it clarity? A shared plan? A calm voice in the room?

What can I shift?
It might be a question in retro. A rewrite of a confusing spec. A check-in with someone spinning in uncertainty.

You don't need to fix the chaos. You just need to give people something real to move toward.

If you're supporting others through it:

• Say what's changed

• Say what hasn't

• Help people move from confusion to choice

Change isn't a detour. It's the road.

And how you walk it, that's what makes you a leader.

Subscribe now

You built your reputation on depth. You fixed the hardest bugs, tackled the riskiest features and made the team faster just by being there. Your hands were always in the code.

But, then the shift began.

People started looping you into earlier conversations.
You were expected to weigh in on architecture, roadmaps, cross-team tradeoffs.
You weren’t just solving problems, you were now shaping what problems got solved.

At first, it felt like a compliment. Then it felt like a stretch and somewhere along the way, it started to feel like a threat.

Because, when you're used to solving what’s right in front of you, zooming out can feel risky. You start worrying you’ll lose track of what really matters.

Like you’re being asked to see the forest but all you know is trees.

The Silent Tradeoff

Zoom out too much, and you feel disconnected. Like you’re commenting on tickets you no longer understand. Stay too deep and you start blocking scale. Decisions stall until you weigh in. Reviews pile up behind your name.

When I first stepped into a lead role, I didn’t stop coding. I just added more.

I kept picking up bugs, doing the quick fixes, trying to keep things moving. But I never got back to the reviews. PRs sat idle and by the time I circled back, they were stale.

That’s when I realised the bottleneck wasn’t the team. It was me.

I wasn’t scaling. I was overcompensating. It wasn’t until I stepped back that the team started moving faster without me.

No one gives you a guide for how to navigate both. No one tells you how to think bigger without losing focus. That balance is exactly what makes a great senior engineer: you're technical enough to earn trust, and broad enough to apply it where it matters most.

The engineers who do it well don’t rely on vague instincts. They make deliberate shifts.

Three Shifts to See Above the Trees

From Quick Fixes to Root Causes

Don’t just solve it. Ask why the problem exists in the first place.

When you’re deep in the weeds, the fix is the focus. When you’re zoomed out, the fix is just the symptom.

That flaky test? It might be a symptom of unclear ownership. That customer bug? It might expose a deeper architectural fragility. That deadline you just missed? It might reflect a broken planning rhythm.

Look for patterns across sprint boards, post-mortems or even Slack threads. What keeps resurfacing? What are the tasks no one really wants to own?

This isn’t about turning every task into an investigation. It’s about noticing when repetition points to rot.

💡 Try this:
After solving a recurring issue, ask: Why did this exist in the first place?
Take five minutes to document what made it possible. Share it in your team channel or retro.
If the same theme shows up twice? You’ve found a potential roadmap spike

From Doing the Work to Unblocking the Work

Your job isn’t to take on the work. It’s to make the work smoother for everyone else.

When you’re the go-to person, it’s tempting to stay in that seat, but, zooming out means shifting from execution to enablement.

You’re not stepping back. You’re setting the direction.

Start noticing the blockers before they show up. A half-written ticket. A PR that gets bounced between reviewers. A story that stalls because no one asked the right team for estimates.

Anticipate the questions before they’re asked. Spot the missing spike before the spec gets written. Unblock your team by reducing ambiguity, not by taking over the task.

💡 Try this:
Step back and look at your team’s scope. What are the three biggest opportunities and three biggest problems you’re facing right now? Write them down. Don’t overthink it.
Then work backwards. What projects would solve those problems or unlock those opportunities? Bish bash bosh, you’ve got roadmap candidates ready to take in.

Doing this will make you a force multiplier. Read more here:

From Being the Answer to Scaling Better Questions

You don’t scale by doing more. You scale by making better work happen without you.

Zooming out means shifting from being the one who finishes the task to being the one who makes the task easier to finish for everyone.

That doesn’t mean walking away from the code. It means finding the places where your input has the most leverage: extracting a reusable component, writing a clear RFC/ADR or posting a short design rationale that unblocks discussion.

Don’t just fix the thing in front of you. Teach the thinking behind the fix. That’s what scales.

💡 Try this:
The next time someone asks for help, don’t jump straight to the answer. Start with, What have you tried so far? What’s tripping you up? Talk through how you’d approach it, not just what you’d do. If it comes up again, write it down somewhere others can find it.

Once is help. Twice means it needs a process.

Thinking Bigger Without Losing the Thread

Zooming out isn’t about seeing more. It’s about asking better questions.

Not just:

“What’s broken and how do I fix it?”

But:

“Why did this break now?”
“What would stop this from happening again?”
“If I fix it this way, what does that change later?”

You don’t need a blank page or a whiteboard to think strategically. Just start with what’s already in front of you.

What are the three biggest problems your team’s dealing with right now? What are three opportunities you haven’t touched yet?

List them. Then work backwards. What projects would move or some or all of those?

That’s your roadmap. Not just more work, smarter work.

Subscribe now

Bottom Line

There’s always going to be a voice that says: If I’m not shipping code every day, am I even pulling my weight?

But code was never the only product. Your thinking is the product too.

Zooming out isn’t about drifting away from impact. It’s about directing it.

You still care about quality. Now you define what quality looks like at scale. You still care about shipping. Now you help choose what’s worth shipping. You still care about craft. But now you build systems that protect it, even when you’re not around.

You’re not just zooming out. You’re stepping up.

Subscribe now

Found this useful?

Chances are you know another engineer navigating the same shift - someone moving from execution to strategy.

Send this their way. Better yet, forward it to your team because zooming out shouldn’t mean going it alone.

Share

Say yes, stay kind and keep the peace.

👉 Even when the deadline made no sense
👉 Even when someone’s work was blocking the team
👉 Even when the system itself was working against us

I told myself silence was strategic. It wasn’t. I was really just afraid of conflict.

The real shift for me didn’t come from building confidence. It came from learning how to engage with tension instead of avoiding it.

Unfortunately I didn’t learn that coming up as an engineer, I missed the early signs. It was only when I co-founded a startup, when I had to be part of every hard decision that I started to build that muscle.

Eventually, I learned how to say the hard thing without making it harder.

But, what took even longer to see? Most of those early conversations failed not because I was wrong, but because I was solving the wrong problem.

I was treating symptoms: the missed deadline, the blocking work, the broken process instead of surfacing the real tension underneath.

Think About The Problem, Not Just The Symptoms

When you're frustrated about a sprint deadline, you think the problem is timeline pressure.

It's not.

The actual conflict is between two engineering values: craftsmanship versus delivery speed.

When your code review gets pushback, you think it's about code quality. But the real tension is between individual autonomy and team standards.

It is easy to walk into these conversations focused on the surface problem.

"This deadline is unrealistic."
"The code quality is slipping."
"We need more time for testing."

All true. All symptoms.

The real conflicts can be happening at a system level. Between competing priorities that nobody said out loud. Between values that everyone assumed but no one had made explicit.

Different conflicts require different strategies. Not all tension is the same and it shouldn't be handled the same way.

• Process problems often need structural fixes

• Technical disagreements need clarity on impact and tradeoffs

• Human tension needs psychological safety and alignment

Tough conversations can fail if we treat every conflict the same. Using a hammer when the problem needs a screwdriver and when we misdiagnose the tension, the cost isn’t just inefficiency. It’s silence. Because it feels easier to say nothing than to challenge what seems already decided.

Why Silence Reshapes What Is Normal

Burnout. Misalignment. Quiet resentment.

These don't show up overnight.

They accumulate because no one names the tradeoffs, explains the impact, or challenges the norm. Not because they’re unaware but because translating engineering concerns into business impact can feel too hard or too risky.

But, silence doesn’t keep things stable. It reshapes the system.

When you work through the weekend without raising concerns or giving it visibility, you’re not just helping the team hit a deadline you’re helping redefine what’s normal.

When integration testing gets skipped and no one raises the long-term cost, that tradeoff becomes precedent, and precedent then becomes process.

Whether you speak up or not, you’re influencing how decisions get made in the future. The only question is whether you're shaping those systems intentionally or not.

The sooner you name the tension, the easier it is to course correct. The longer you wait, the more the system solidifies.

📌 Note: Speaking of system problems also means recognising that not all systems can be changed. However, resolving issues and flagging conflict can still be changed within your sphere of influence, whether this is your colleagues, your team, or the whole organisation.

Before Having The Conversation, Understand The Impact

Engineers can easily get stuck explaining the technical problem. But, stakeholders make decisions based on business impact.

The issue usually isn’t your technical analysis. It’s that you’re speaking at the wrong level of abstraction.

Here’s the credibility stack in engineering conversations:

Level 1: Complaint or opinion

“This codebase is a mess.”

Level 2: Technical problem explanation

“Our current architecture isn’t modular enough.”

Level 3: Risk quantification with data

“Because of our current setup, we’re 30% slower in delivering features.”

Level 4: Business impact translation

“If we restructure this now, we avoid six weeks of delays in the next two quarters and can reduce production bugs by 30%.”

Most engineers stop at Level 2. But influence happens at Level 4.

That’s the level where decisions shift.

Because the conversation isn’t about the code. It’s about strategy.

Now To Have The Conversation

Now you understand you need to have the hard conversations. You know that removing tension means translating technical concerns into business impact. But how do you actually raise this with someone?

Start with the right frame. Here’s one to try:

1. Start with the shared goal

“I want to make sure we’re building this the right way, and that the team isn’t quietly burning out doing it.”

2. Name the tension, not the person

“Right now, it feels like we’re choosing speed by default, but I’m noticing signs that quality is suffering.”

3. Invite alignment, not approval

“Can we talk about what tradeoffs we’re actually willing to make, and whether we need to reset expectations?”

You’re not attacking, you’re aligning. You’re not calling someone out, you’re calling the problem in.

💡 Try This: Pick one conversation you’ve been putting off, whether it’s with a peer, your manager, or even your team. Block 30 minutes on your calendar. Write out the shared goal, the tension, and the invitation to align. Then say it.

Subscribe now

What Happens When You Get This Right

When you raise the right conversation at the right level, here’s what starts to shift:

✅ You surface tension early, before delivery becomes impacted
✅ Roadmaps then become collaboration, not just approved by engineering
✅ Trust builds because the real tradeoffs are visible
✅ Tech debt can get addressed with the business backing

The best technical outcomes i’ve seen haven’t come from agreement. They came from having tough conversations and high performing teams don’t avoid disagreement. They use it to discover solutions neither side had considered.

Your job isn’t to convince everyone. It’s to surface what matters, test assumptions, and guide the team toward the best bet not the safest one.

Subscribe now

Final Thought

This isn't just about speaking up.

It's about showing your team and your leadership that you're someone who thinks in systems. Someone who can translate technical complexity into business clarity. Someone who can turn conflict into better architecture.

Not to be difficult. But because the work, and the people doing it, deserve systems that actually work.

Share

So why does it feel like no one really sees you anymore?

As engineers grow into senior+ roles, the day-to-day texture of work changes in subtle ways. You have meetings before the meetings. Code gets reviewed quicker, sometimes not at all. You’re given space not just to build, but to think, to guide and to architect.

Yet, something feels off.

You’re no longer embedded in the rhythm of the team in the same way. You still belong, but it’s a different kind of belonging. The late night debugging sessions, the back-and-forth code reviews, the short-term dopamine hits of shipping quick fixes eventually fades. In their place: slower, more abstract and lonelier problems. System thinking over ticket execution. High trust, but low feedback. High autonomy, but less collaboration.

This is the experience many senior+ ICs never talk about because admitting to feeling disconnected can feel like betraying the very success you worked so hard to earn.

The truth is this: this quiet distance is more common than it seems. Left unaddressed, It chips away at confidence. It can trigger imposter syndrome, erode trust in your impact or worst of all, make you stop caring how your work is seen.

Why Does It Impact Engineering?

It is fair to say that engineers didn’t choose this career because they love meetings and small talk. They chose it because they like building things, solving problems and making systems better. The very things that make engineering fulfilling: deep focus, long solo stretches of work and abstract problem solving. Things that also make it isolating.

You can go a whole day talking only in tickets, tools, and text. Even in collaborative teams you might go weeks without someone really asking how you’re thinking about a tough problem, or challenging your assumptions, and, as you get more senior, that isolation only expands.

• You’re solving higher-leverage problems but fewer people fully understand them.

• You’re making decisions that shape entire systems, but, no one’s in the room is always double-checking your call.

• You’re holding more context than ever, but there’s rarely anyone to reflect it back or pressure-test your thinking.

That kind of silence isn’t just lonely. Without regular pushback, your decisions become harder to trust even for yourself. Doubt creeps in. Or worse, you start assuming your thinking is fine because no one says otherwise. That’s how technical confidence starts to erode. Not all at once, but slowly with the absence of reflection, or calibration.

Rebuilding Your Sense of Belonging

Belonging isn’t about being invited to meetings. It’s about being seen. Feeling part of something that extends beyond your tickets or your title.

And that’s what disappears fastest when you step into senior roles.

The feedback loops shrink. The friction fades. And before you realise it, no one’s really asking how you think anymore, only just whether your plan is done.

If you’re not careful, that kind of silence starts to shape how you work. You can drift or stagnate. That’s not just lonely, it can turn into a slow erosion of the connection that made the work meaningful in the first place.

So what do you do? You build it back. Like anything else: deliberately, bit by bit.

Start Inside Work

Share your thinking earlier

Don’t share too late when the doc is finished, the decisions are made and the only thing left is approval. But if you want real input, you have to invite it before you’re sure.

That means sharing a rough draft. Being clear that it’s early thinking. And naming the parts you’re still unsure about. That’s not weakness. That’s how you make better calls and build trust at the same time.

💡 Try This: Start a “Working Draft” this week. Label it clearly as early-stage thinking. Add 2–3 specific questions you’re still exploring. Share it with people you trustespecially the ones you don’t usually loop in early. See what shows up.

Join a community

Find the smallest, most consistent group you can commit to. One hour, every other week. Whether it's six engineers discussing system design papers or a chapter meeting tackling domain specific topics. The rhythm matters more than the size.

💡 Try This: Look for existing groups first before creating something new. Send an message today asking if you can join an established book club, lunch group, or technical discussion. If nothing exists, invite 3-4 people to a recurring 45-minute session with a clear focus and rotate ownership to make it collaborative.

Write down the decisions that matter

After your next major decision, take 15 minutes to document three things: what options you considered, why you chose this path, and what would make you reconsider. Then share it with someone who disagreed with you and ask for their perspective. This isn't about validation it's about keeping you sharp and shows you’re willing to listen to other opinions.

💡 Try This: Create a simple decision log template with just three sections: Context, Options Considered, and Decision Rationale. Commit to filling it out for your next significant technical or team decision, then schedule a 15-minute conversation with someone who might see it differently.

Talk to people outside engineering

Ask a PM how your work shows up in their roadmap. Ask a designer what slows them down. You’ll see your systems from a different lens (Read Network Like a Leader, Not Just an Engineer to a deeper dive further on this.)

Then Look Beyond Work

Anchor yourself outside of engineering

The engineers I know who feel the most grounded don’t just write good code. They have something outside of work that keeps them anchored. A weekly run club. A local climbing gym. A group of people who couldn’t care less what framework they’re using.

A friend of mine told me he was spending every night alone, doom-scrolling. So he joined a boxing class. Two minutes from his apartment. A month later, he knew everyone. A year later, he had a community.

It wasn’t about boxing. It was about proximity.

💡 Try This: Pick something close to home. Physical location matters more than shared interests. Try a recurring activity with a fixed group of people: a class, a club, or a routine and commit to showing up for 4 weeks. Don’t overthink it. Let consistency do the work.

Design for local connection

We’ve figured out how to stay connected across tools, time zones, and teams. But it’s the ordinary, unscheduled moments that build real belonging. The ones that happen without an agenda, invite, or calendar slot.

Not a forced social. Not another meeting. Just something steady. Familiar. A regular coffee. A casual walk. A check-in that happens because you made it a habit.

💡 Try This: Choose one person you trust and set up a recurring 20-minute catch-up. Make it low-friction. Same time, same place. No agenda. Just presence. If you’re remote, pick someone in your city or timezone and make it offline if you can.

If you're remote, create your own rhythm

Working remotely makes this even more important. You have to design your own rhythm. Something offline. Something human. So you don’t end every week wondering if anyone really saw you.

You don’t need to become an extrovert. Or say yes to everything. You just need something that brings you back into rhythm with people, regularly enough to feel seen.

💡 Try This: Choose one offline, community based activity to try this month. Something where the same people show up each time. Don’t optimize for interest. Optimize for consistency.

The Real Work

Great engineers I know don’t just build great systems. They make sure they’re not doing it in isolation.

They stay open. They ask for pushback even when it's easier to move on. They keep showing up to the things that make the work feel real, not just visible.

Connection doesn't happen on its own. It takes intention.

You can't wait for it. You have to design it into your rhythm before the silence becomes too familiar.

The work is still yours. Just don’t carry it alone.

Subscribe now

If this hit close to home, send it to someone quietly carrying more than they let on.
Or better yet, ask them how they’re really doing.

Share

Here’s the truth:
You’ll rarely get handed perfect clarity.
You’ll get just enough to start and be expected to figure out the rest.

That’s not dysfunction. That’s the job and as teams ship faster, the cost of misalignment rises. Ambiguity isn’t just annoying, it’s expensive.

The real difference between good and great engineers?
It’s not how fast they code, it’s how well they move through ambiguity and make it easier for others to move, too.

The Real Work of Senior Engineers

Most engineers think clarity is someone else’s job.

They wait for better specs. A final design. A product call.

But the engineers who grow to get trusted with big bets and earn influence without a title don’t wait for clarity. They create it.

👉 They turn loose direction into real decisions

👉 They spot risks while everyone else is still heads down

👉 They don’t just unblock themselves. They unblock the team

This is the hidden work that makes the visible work possible. Let me show you how it played out for me.

The Gift That Kept on Giving

At Trade Republic, I got pulled into a project called Gifting: a way for users to send stocks/ETFs as presents, complete with a lottery mechanic. Nine milestones. Four platforms. Six weeks.

The PRD was already excellent. The team was doing great. But, the project had already kicked off, and something was off.

Product was still shaping requirements. Engineers were shipping. Testing hadn’t started yet, no one owned the big picture and no one had time to ask the most important question:

Are we still building the same thing?

So I was asked to step in.

I started by pulling context: PRD, Slack, designs, DMs.
Then I wrote out what I thought we were actually building: edge cases, failure paths, inconsistencies. I used a simple Given–When–Then structure:

Given [state]
When [event]
Then [expected result]

Example:

Given a user opens an expired gift link
When they try to redeem it
Then they should see an error and a CTA to send a new gift

I didn’t write these for anyone else at first. I wrote them so I could think straight,
but, they spread. Engineers started validating their work with them. Product used them to check intent and when priorities shifted, I updated the cases.

I wasn’t the project owner. That didn’t matter. Someone saw what was missing and brought me in to help the team move with confidence.

That’s what clarity looks like in practice.

How to Create Clarity at Any Stage

If you’re working on a project right now, beginning, middle, or end this is how you can bring clarity starting today. These are the same tools I’ve used across complex, multi-platform builds where timelines were tight and alignment mattered most.

1. Document the Gaps

Most specs only cover the happy path. You cover the rest.

In every complex project I’ve worked on, the real risks hid in the gaps: network failures, edge cases, undefined states.

Take your current feature and write:

Given: [a real edge case]
When: [an action occurs]
Then: [what should happen]

Do this for 10 real scenarios. Share them with your team.

In most cases, at least 2 or 3 will surface different assumptions across functions, saving you days of rework down the line.

💡 Quick Tip:
To write high-quality Given–When–Then statements, start by thinking like a tester, not just a developer.
Focus on observable behavior, not implementation. If it can’t be validated from the outside, it doesn’t belong in the statement.

(This approach comes from Behavior-Driven Development practices: Dan North’s original BDD work is a great source if you want to go deeper.)

2. Create a Source of Truth

In fast moving projects, information lives everywhere. If you don’t centralize it, your team wastes time asking the same questions.

I’ve used this on high pressure builds where scope shifted weekly. A single shared doc kept the team aligned across mobile, backend, product, and design.

Create a simple doc with three sections:

What We’re Building

A 3 sentence summary in plain English

Open Questions

Checkboxes for unresolved logic or decisions

Key Decisions

List what’s been agreed, with a date

Keep it updated weekly (or daily if you're moving fast). No process. Just facts. When it starts getting referenced in standups or Slack threads, you’ll know it’s working.

3. Check Across Platforms

The most common source of bugs I’ve seen? Two platforms solving the same problem in different ways.

Talk to someone outside your lane. Backend if you’re frontend. Mobile/Web if you’re backend.

Ask:
“How are you approaching this feature?”

Compare what you hear to your own mental model. Then document the differences and clear them up before they turn into blockers.

It takes 15 minutes. It avoids weeks of confusion. You can usually get this done during a technical kick-off, or technical planning session after the initial product kick-off has happened.

4. Challenge the Plan

Most teams avoid these questions because they sound negative. But, in every team I’ve led, asking early has saved us hassle later down the line.

Try these:

• What are we assuming that hasn’t been validated?

• What breaks if this fails?

• Who owns the outcome when something goes wrong?

You’re not second guessing the plan. You’re strengthening it before it gets expensive by creating alignment across everyone and accountability to whomever is leading.

💡 Quick Tip: Use a RACI matrix early in a project to clarify roles and avoid misalignment. Assign who is Responsible (does the work), Accountable (owns the outcome), Consulted (offers input), and Informed (kept in the loop).

This simple grid helps prevent duplicated effort, missed responsibilities, and vague ownership.

5. Run a Pre-Mortem

When timelines are tight, most teams focus on best case execution. But, great teams try to flag risks as early as possible. You may have heard of a post-mortem during an incident call, or incident reporting. But, what is a pre-mortem? Instead of looking at the past, we look into the future.

“It’s three months from now. The feature failed. What happened?”

You can then use the 5 whys principle to answer your question. Here’s a real world example:

Feature: Scheduled job that generates monthly invoices and emails them to customers

1. Why did it fail?
   The job didn’t retry failed invoice generations due to transient API errors.

2. Why wasn’t there a retry?
   The invoice generation function was fire-and-forget and wrapped in a try/catch, with errors logged but not rethrown.

3. Why was failure treated as non-blocking?
   The job was designed as “best effort” to avoid alert fatigue during initial rollout.

4. Why wasn’t this flagged as risky?
   Engineering assumed failed invoices would be retried next month.

5. Why did that assumption hold?
   The system didn’t track failed generations or persist state, it operated statelessly, by calendar date.

Root cause: The team had different mental models of failure tolerance. Product saw invoices as critical. Engineering treated it like a batch process that could tolerate loss. No shared definition of what “done” meant for the job.

What we should’ve done:
Define success criteria upfront:

“The job must guarantee delivery of all invoices within a 24 hour window or raise a critical alert.”

This is one isolated example, but a pre-mortem is used to identify every risk. Organise your document by identifying risks, root causes and action items before go-live. Assign owners and timelines to make sure the risks are mitigated accordingly.

What This All Buys You

When you reduce ambiguity, you reduce the cost of speed. You prevent the kind of misalignment that turns into bugs, rework, or missed deadlines.

It’s not extra work. It’s leverage.

You become the person who helps everyone else move with more confidence and less waste.

Subscribe now

✅ Your Move This Week

Option 1: Edge Case Audit
Write 10 Given–When–Then cases for your current feature. Share them with your team. See how many prompt discussion.

Option 2: Platform Sync
Have a 15 minute sync with someone on another platform. Compare what you each think the feature does. Document the gaps.

Option 3: Living Doc Test
Create a one-pager: “What We’re Actually Building.” Capture what’s known, what’s still fuzzy, and what’s been agreed. Update it for one week. See who starts referencing it.

Share

Not because your team is lying to you, but, because the cost of honesty feels too high.

One misworded comment or tense moment can be enough to remove trust. So we say less than we should. We soften things or we avoid the conversation altogether.

Feedback is one of the most powerful tools in any engineering culture (or any working culture for that matter). It’s also one of the most misunderstood.

Some teams ritualise it until it loses meaning. Others ignore it entirely and hope clarity will sort itself out. But, if you want to grow, lead or shape a strong team, you need both sides of the equation: giving and receiving.

Common Myths That Hold Teams Back

If feedback feels hard, start here. These misconceptions quietly sabotage well meaning managers and ICs alike.

Myth 1: Feedback is always negative

Truth: The best feedback system highlights what’s working just as much as what’s not. Praise is data too.

Myth 2: Feedback must be immediate

Truth: Feedback should be timely but also thoughtful. A delayed insight is better than a rushed critique.

Myth 3: Feedback is personal

Truth: Focus on the behavior, not the person. “When X happened, the impact was Y.” Stay specific.

Myth 4: Feedback should be rare

Truth: Normalizing feedback lowers the stakes. If you only give feedback when something goes wrong, it becomes feared, not welcomed.

Myth 5: You have to give good feedback to also share negative feedback

Truth: Using the “sandwich” feedback technique (where you also soften negative feedback with good feedback before and after sharing it, like a sandwich) can be seen right through and will only come across disingenuous

Why Feedback Often Fails

Even great engineers struggle with feedback not because they’re bad at their jobs, but because the way feedback is delivered often makes it hard to use.

Here’s where it usually breaks down:

• It feels personal. Someone points something out and it lands hard. You know it’s about the work, but it still feels like it’s about you.

• It’s too vague. “Be more proactive” or “Communicate better” doesn’t tell you what to actually change.

• It comes too late. If feedback shows up a week or two after the moment, it’s already lost its edge and its usefulness.

When feedback feels like a judgment, people shut down. When it’s unclear or delayed, it doesn’t land at all.

Giving Feedback That Lands

The best feedback has a purpose. Not to vent. Not to impress. But to help someone get better, while still respecting them.

One well-established model comes from Anna Carroll’s The Feedback Imperative. It’s also called the 4C model, and it helps keep feedback clear, relevant, and grounded in intent.

1. Context: Explain the situation or behaviour factually. No assumptions, no judgment. “In yesterday’s sprint review, I noticed...”

2. Challenge: What needs to change? Be honest and respectful. “This caused some confusion during prioritisation.”

3. Choices: Offer suggestions or alternatives. “You could summarise the priorities at the end to clarify next steps.”

4. Consequences: Share the potential impact positive or negative. “That would make it easier for the team to align and move faster.”

Examples:

❌ Poor: “You need to be more technical.”

✅ Better: “In the last design review, it felt like you leaned more on the PM’s framing than your own. I’d love to see you take more ownership of the architecture choices.”

❌ Poor: “Stop being so reactive.”

✅ Better: “When you responded to the bug report, it sounded defensive. I know you care about quality. How can we make that clearer under pressure?”

How to Receive Feedback Without Spiraling

Giving feedback well is important. But how you receive it often matters more.

Most people say they’re open to feedback. But once they hear it:

“That’s not what I meant.”
“You misunderstood.”
“You’re one to talk.”

Those are all versions of, “You’re wrong.”. Resilience means hearing feedback without spiralling.

Here’s a way to build that resilience muscle:

1. Pause: Take a 6-second breath. This gives your nervous system a moment to settle. Don’t react yet. Let the feedback land without rushing to defend.

2. Clarify: Ask for examples. Feedback that feels vague or broad becomes more useful when it’s grounded in specifics. Try, “Could you tell me when you noticed that happening?”

3. Reflect: Not every piece of feedback will be spot on. That’s okay. Ask yourself, “What might be true here?” and “What’s worth acting on?” You don’t have to agree with everything to grow from it.

4. Circle Back: Let the person know you’ve thought about it. This doesn’t need to be a grand gesture. A simple, “I’ve been thinking about what you said and I’m going to try X,” shows maturity.

5. Act: Pick one change you can actually make. Something small, visible, and aligned with your growth. This helps others see your intent and builds momentum over time.

The engineers who do this regularly build trust faster. Their teams share more with them. And over time, they become easier to coach, easier to collaborate with, and harder to overlook.

How to Ask for Feedback Without Making It Awkward

Most people want feedback but don’t know how to ask for it in a way that gets real answers.

Here’s a lightweight prompt that lowers the stakes:

“I’m trying to get better at [specific area]. Is there anything you’ve noticed that I might be missing?”

It works because:

• It’s focused - people respond better to clear topics.

• It’s self-aware - you’re naming your intent upfront.

• It gives them permission to be honest.

If you want feedback that’s useful and doesn’t feel like a performance review, you can also try the SBI model. It helps you frame your ask clearly and invites a thoughtful response.

SBI stands for:

• Situation: Describe the specific context.

• Behavior: Highlight what you did or said.

• Impact: Explain why you’re asking

For example:

“In the last retro (Situation), I shared my thoughts on the pre-mortem plan (Behavior). I’d love to know how that landed with the team (Impact)."

This approach makes your request more grounded and collaborative. It shifts the dynamic from being evaluated to co-reflecting. You’re not just asking, “Was I good?” You’re asking, “What did you notice, and how did it affect things?”

This Week’s Practice

Pick one of these to try immediately:

• Structured Ask: In your next 1:1 or coffee chat request feedback using the SBI model (Situation, Behavior, Impact).

• 4C Feedback: Give one piece of feedback using the 4Cs framework

• 5-Minute Ritual: Add a micro feedback loop to your team check-ins.

Do one consistently for two weeks. Research says that’s the minimum to start rewiring your feedback reflexes.

Subscribe now

The One Conversation You’re Avoiding

What’s the piece of feedback you’ve been avoiding for weeks?

Delaying hard conversations triples the emotional energy required to resolve them later. Better to step into the discomfort now.

👉 Share this with a teammate who’s serious about getting better at feedback.

Share

👇 Comment with the hardest part of feedback for you, giving it or receiving it?

Leave a comment

✅ Try one of the techniques above this week and tell me how it changed your next interaction.

Subscribe now

Three years from today, what do you genuinely want your professional life to look like?

This isn't a trick question. It’s not about chasing promotions or titles or what someone else expects from your career. It’s about clearly understanding what would truly make your day-to-day fulfilling and engaging.

Many engineers haven't thought deeply about this. Not because they lack ambition or drive, but because the industry constantly pushes us toward short-term goals. The next sprint. The next quarter. The next performance review. But, true satisfaction and real growth come from having a clear, long-term vision.

Take a moment now. Imagine your professional life three years from now. Picture it vividly. Let your mind explore what genuinely motivates you. The clearer your image, the more powerful your vision becomes.

Why This Reflection Matters

Having a clear, personal vision for your future actively shapes your decisions and daily habits. A well-defined vision makes it easier to say no to distractions, protect your time and focus your energy on actions that align with your real goals.

Without this clarity, even very talented engineers often find themselves busy but unfulfilled, putting effort into impressive-looking projects that don't match their deeper aspirations.

I've seen it countless times. Strong, capable engineers feeling stuck because they never paused to define their true goals clearly. Your vision helps prevent this. It gives your actions purpose and keeps your growth intentional rather than reactive.

A Framework That Works

I coach engineers using a simple framework:

• Craft a vivid, personal 3-Year vision

• Set clear 12-Month milestones that show real progress

• Break them into focused 3-Month goals that create momentum

Let's walk through how you can build this for yourself.

Step 1: Craft Your 3-Year Vision

Set aside time. Answer these questions honestly:

• What kind of work excites and energizes you most?

• What type of environment brings out your best work?

• How do you genuinely want your typical workday to look?

• What boundaries are non-negotiable for your well-being and happiness?

When you write your vision, aim for 3 to 4 sentences that paint a clear picture. Focus on the work you are doing, the environment you are part of, and the skills and qualities you embody. Keep it personal, tangible, and real. Avoid jargon. Avoid aspirational slogans. Describe a day you would wake up excited to live.

Be specific. Avoid vague statements. Avoid building visions around titles alone. Focus on the experiences you want to have.

Your vision should reflect what you actually want, not what sounds impressive. Make it real.

Step 2: Set Meaningful 12-Month Milestones

With your vision clear, ask yourself.

How can I get 33% of the way to my vision in the next 12 months?

Choose one or two milestones. They should be measurable, meaningful, and personal. Examples:

• Ship a feature that meaningfully improves a key product metric by n%

• Lead a cross-team project that simplifies processes

• Establish clear expertise by speaking at n industry events

Avoid setting milestones for external validation alone. Milestones should matter to you first. Once you define them, seek feedback. Ask trusted colleagues or mentors:

• What might block me from hitting this milestone?

• What habits or skills do I need to sharpen?

Feedback at this stage makes your plan more realistic

Step 3: Break It Down Into 3-Month Goals

Now pick two or three clear goals for the next three months.

Good goals are achievable, measurable, and directly connected to your milestones. Examples:

• Create and share a detailed roadmap for a project

• Publish a technical post sharing a real solution for a cross-team project

• Submit n proposals to speak at upcoming events

The point is to build quick momentum. Create early wins. Build visible progress you can point to.

Common mistake. Setting too many goals. Or picking goals that sound important but don't create impact. Focus your effort.

Why This Matters

Without a clear structure, you risk spending energy on things that don't take you where you want to go. You stay busy but feel stuck.

With a vision and milestones, you:

• Make better career decisions

• Protect your time and focus

• Grow in a way that feels real and fulfilling

Common Doubts and Why They Don't Hold

"Tech changes too fast."

Your vision isn't about predicting tech trends. It’s about defining the type of work you want to do and the environment you want to thrive in.

"This feels too abstract."

Think of it like designing a system. Your vision is the architecture. Your milestones are the core components. Your goals are the first features you ship.

"My company should be guiding my career."

No. Your company manages their interests first. This is about taking ownership of yours.

What To Do Next

• Block uninterrupted time this week to write your 3-year vision

• Define one or two real 12-month milestones

• Set two or three concrete 3-month goals

• Ask one or two people for honest feedback

• Track your progress visibly

Ready to put this into action?

I created a practical, copyable Google Doc you can use to build your 3-year vision and start setting real milestones
→ Click here to access the Vision Goal Framework

Final Reflection

This is not a one time exercise. Growth happens through regular check-ins, honest reflection, and course correction.

Block regular time to revisit your vision. Adjust your milestones. Set fresh goals every quarter.

You are building your future deliberately. Not drifting. Not reacting.

Subscribe now

Want me to review your 3 year vision?

If this helped you, feel free to drop a comment or share this newsletter and I'll review the 3-Year Vision of the first few people who need it

Share

As seductive of an idea it is, it is also a damaging one.

While speed can solve certain classes of problems, the hardest challenges in engineering today are no longer technical. They’re about alignment, coordination, scale, and trust. They’re human.

And the truth is this: no one ships great work alone, not even the sharpest engineer. Behind every success are systems, teams, and feedback loops. So why not strengthen those, too?

What Is a Force Multiplier?

The term comes from military doctrine: a factor that dramatically increases the effectiveness of a unit without increasing its size. In software, it has evolved into a way to describe engineers who make everyone around them better without needing to do everything themselves.

Force multipliers don’t just write great code. They:

• Improve the way decisions get made

• Surface misalignment early

• Grow others’ judgment through feedback and example

• Enable the team to operate more effectively even in their absence

They reduce the bus factor by ensuring context is shared, ownership is distributed, and systems don’t rely on one person to keep them going.

Why the 10x Mindset Fails at Scale

Many engineers build their early careers by being fast, autonomous, and hyper-reliable. These traits earn trust, responsibility, and visibility. But once you enter senior territory, what got you here won’t get you there.

At scale, problems look different:

• Work spans multiple teams

• Ambiguity is the default state

• Decisions have cascading impact

• You don’t always have full context

• You’re expected to align without direct authority

The 10x model relies on individual throughput, but the problems we face now demand coordination, influence, and clarity.

The Force Multiplier Mindset

Force multiplication is not about doing more. It's about making more possible. That starts with a shift in how you define value.

• "What did I deliver?" → "What did I help the team deliver without me being the bottleneck?"

• "How much am I responsible for?" → "How broadly is responsibility shared because of the systems I put in place?"

• "How sharp are my technical skills?" → "How clear is our shared thinking?"

This isn't just mindset, it's muscle. And building it starts with rewiring your instincts.

Engineers who've risen through individual execution often feel uneasy stepping back. But becoming a force multiplier doesn't mean stepping away from impact. It means changing where you apply your effort:

• Instead of solving the hardest bug, you're helping the team avoid it next time.

• Instead of reviewing every line, you're setting the bar for what "good" looks like.

• Instead of owning every decision, you're ensuring decisions happen without you.

You move from heroics to infrastructure. From being the center of execution to the architect of team flow.

Force multipliers operate at a different altitude. They trade immediacy for longevity. Their real output is durable: better judgment, better systems, better teams.

What It Looks Like in Practice

Force multiplication isn't a big gesture, it's a discipline. It's visible in how you show up in the small, repeatable moments of teamwork:

• In standups: You don't just update, you clarify. You unblock quietly. You remind people what matters.

• In planning: You refocus discussion on outcomes. You bring the right voices in early so the right problems are solved.

• In code reviews: You coach. You praise the thinking, not just the implementation. You make the rationale visible.

• In handovers: You leave behind context that travels. You document decisions so others can pick up where you left off, weeks later.

• In syncs: You name the thing no one else is surfacing. Misalignment, friction, assumptions, all get airtime.

• In retros: You ask better questions. You steer the team toward fixing systems, not just patching symptoms.

And if you're not sure where to begin? Zoom in on one moment this week:

• Instead of jumping in to fix something, ask: "What would make this easier for someone else next time?"

• Instead of just reacting in a thread, ask: "Does everyone have what they need to move forward?"

• Instead of rushing through a meeting, pause to name the decision we're actually here to make.

These are not flashy moves. But they compound.

Force multipliers build a culture that outlasts their presence. They leave behind clarity, capability, and confidence. Which leaves fewer messes. And more momentum.

The Real Cost of Staying in 10x Mode

You might move fast. You might be respected. But if you’re constantly needed to unblock others, the work doesn’t scale.

This is the bus factor in action. The more essential you are to daily execution, the more fragile your team becomes.

Force multipliers design themselves out of that equation. They build teams that can operate independently, where they can zoom in strategically and zoom out without everything stalling.

How It Feels to Be a Force Multiplier

The pace is calmer, but the impact is higher.

You start thinking longer-term. You invest in documentation, reusable patterns, or coaching moments even when busy.

You notice how often miscommunication, not misexecution, causes the delay. You begin asking better questions:

• Why are we always late in this phase of the project?

• Who is unclear on their role, and why?

• What conversations haven’t happened but should?

• What dependencies keep catching us off guard?

Force multipliers reduce latency in decision-making. They increase clarity per message. They build trust in ways that aren’t loud, but are felt.

This Isn’t About Title. It’s About Intent.

This mindset isn’t reserved for Staff engineers. It applies to anyone willing to zoom out.

Force multipliers are everywhere:

• Mid-level engineers who quietly redesign flaky delivery processes

• New joiners who improve onboarding for the next person

• Senior ICs who raise the quality of every decision simply by how they show up

You don’t need permission to multiply. You just need to care about more than your own speed.

The Idea Ends When We Stop Glorifying Output

We’ve celebrated fast movers for decades. And yes execution matters. But when all your success is measured by speed or visibility, we incentivize short-term wins over durable progress.

Force multipliers shift the reward structure:

• They measure impact by what got better permanently

• They optimize for lower friction, not higher pace

• They think in terms of team throughput, not personal velocity

The irony? The best force multipliers are usually fast too. But they’ve chosen to invest that speed in building systems that benefit others.

They know how to speed up. They just choose when to do it.

Subscribe now

Start Multiplying What Matters

You’ve probably already felt it, output alone won’t take you further.

You’ve seen how hard it is to work fast when the people around you are blocked, confused, or misaligned.

So pick one place to start:

• In your next thread, make the goal clearer

• In your next sync, invite someone else to lead

• In your next doc, explain a decision for someone who wasn’t there

• In your next code review, praise the thinking, not just the outcome

Then do it again and again.

The 10x myth was always too small for what engineers are capable of. It’s time to build something bigger.

You’ve built trust. Delivered under pressure. Navigated complexity that others wouldn’t touch.

But I want you to pause here quietly and honestly ask yourself:
Am I still solving the right problems?

Because at your level, technical work is no longer the bottleneck. If you’re still measuring your impact by what you personally ship, you’re likely missing the larger opportunity and the reason your week feels heavier than it should.

What’s holding you back isn’t your output.
It’s friction. Misalignment. Decision gaps. Expectations that live in people’s heads and never get named out loud.

This is the moment most high-performing engineers hit without much training for.
Learning to manage up, down, and across. Deliberately and skillfully.

Let’s work through it together:

Managing Up

Your manager isn’t an obstacle; they’re a crucial part of your interface with the company.

Ever thought, "I shouldn't have to manage my manager?" You're not alone. But the reality is, if you don't actively manage upward, your priorities might drift, your valuable contributions could go unnoticed, and your support may become inconsistent. Managing up isn’t about politics. It’s about clarity, alignment, and helping your manager support you effectively.

Why Managing Up Matters

Think of managing up as helping your manager perform better so that you can excel in your own role. It’s not extra work; it’s your path to greater impact, clearer goals, and smoother progress. By proactively giving your manager the right information and support, you align your efforts with organizational priorities.

Here's how you can effectively manage upward:

1. Clarify Priorities Before Diving In

Always make sure you’re aligned with your manager about what's the most important. Rather than guessing or assuming, simply ask:

"What are your top three priorities this month, and where should I focus to best support them?"

Explicitly asking removes uncertainty, ensuring your daily tasks and strategic efforts directly connect with your manager’s top goals and the organization's priorities.

2. Bring Solutions, Not Just Problems

Managers prefer to make decisions rather than solve every issue that arises. Simplify their job by clearly outlining available options and recommending a preferred solution.

Avoid escalating vague problems like:

"The rollout failed. What do we do?"

Instead, provide clear, actionable options:

"The rollout failed due to an environment mismatch. We can either rollback or implement a hotfix. I recommend a rollback to ensure stability. Do you agree?"

This positions you as a reliable team member who understands the broader implications and can handle responsibilities independently.

3. Use Structured Updates, Not Information Dumps

Managers don't need every detail of your day. They need targeted, relevant updates. Clearly structured updates help your manager quickly grasp what matters most and identify where they need to intervene.

Use a straightforward format:

✅ Progress: Highlight clearly what's advancing or successfully completed.
⚠️ Risks: Clearly state potential issues or delays to prevent surprises.
🔄 Decisions Needed: Clearly communicate any blockers or where you need their input

This approach ensures clarity, prevents overwhelming them and keeps conversations productive.

Regularly Check Your Approach

Periodically evaluate how well you’re managing upward by asking yourself:

1. Am I addressing issues that genuinely matter to my manager?

2. Does my manager clearly understand my priorities and work progress?

3. Does my manager trust me to proactively identify critical issues?

If you answer "no" to any of these, it’s time to adjust your approach. Aligning with your manager's expectations isn’t about extra tasks; it’s about ensuring you're focused on the right tasks.

Managing Up is Empowering

Managing up turns your relationship with your manager from one of dependency into a strong partnership. It helps both you and your manager work smarter, faster, and more confidently. Instead of seeing your manager as an obstacle, view them as your ally and advocate. When you provide them with what they need, they'll become more effective at supporting you in return.

Remember, managing up isn't extra work; it’s essential. It's how you secure the right priorities, visibility, and ultimately, the right outcomes.

Managing Down

You’re not your teammates' safety net; you’re their amplifier.

If your peers frequently rely on you to double-check their work, answer every question, or resolve last-minute issues, you're unknowingly slowing them down rather than enabling them to excel.

Managing down isn't about asserting control. It's about providing clarity, coaching, and creating an environment that empowers your teammates to succeed independently, even without the title.

Why Managing Down Matters

Effectively managing down empowers everyone around you. It transforms your role from a bottleneck into a catalyst, allowing teammates to reach their full potential. Done well, your colleagues become more confident, capable, and productive.

Here's how you can practice effective managing down:

1. Clearly Define Ownership

Before collaborating or delegating responsibilities, always clarify the context, outcomes, and autonomy.

Clearly explain:

• Why: Provide context behind tasks.

• What: Define the expected outcome clearly.

• How Much: Specify the level of independence your teammate has.

Example:

"You’ll take the lead on optimizing the API for faster response times. The goal is to cut latency by at least 20%. You own all implementation decisions, I’ll be happy to review the RFC, code and then the final solution."

Defined ownership builds accountability and confidence

2. Coach Instead of Jumping In

When a teammate hits an obstacle, resist immediately stepping in. Instead, encourage independent problem-solving through questions:

• "What approaches have you already tried?"

• "What’s currently blocking you?"

• "What's your next step?"

This approach strengthens your teammates' abilities and confidence without creating reliance on your direct intervention.

3. Establish Clear Feedback Loops

Avoid relying solely on casual conversations or unclear checkpoints. Set structured, consistent reviews to monitor:

• Progress

• Quality

• Alignment with project goals

Give prompt and clear feedback. Recognize strong contributions quickly and clearly communicate when adjustments are necessary. Quick feedback ensures alignment and prevents misunderstandings.

I usually encourage the more senior engineers in my team to setup 1:1s or weekly syncs for the projects they lead.

Regularly Check Your Approach

Ask yourself:

• Do you redo your teammates’ work after they finish?

• Are you frequently pulled into minor details?

• Do your teammates need your input to define what success looks like?

If you answered yes to any of these, it’s time to adjust your approach.
Shift from being a fallback to becoming a force multiplier.

Become a Force Multiplier

Effectively managing down transforms your role from a safety net into an amplifier. Instead of continuous intervention, your focus becomes facilitating growth, clarity, and autonomy. Aim to create a team environment built on clear expectations, meaningful independence, and proactive coaching.

Being a force multiplier means your impact goes beyond your individual output. You help elevate the performance of everyone around you. Companies value force multipliers because they create leverage: one strong engineer can raise the bar for a whole team.

Remember, your goal isn't controlling every detail. It's empowering your team to excel independently and confidently (and this also sometimes means letting them fail to learn)

Managing Across

Most friction between teams isn't personal. It usually comes from unclear expectations or misaligned communication styles.

Alignment rarely breaks down because someone is intentionally difficult. More often, it's because ownership wasn't clearly defined or communicated effectively. Without clarity, teams rely on assumptions, deadlines then slip, and everyone just ends up frustrated.

Effective management across teams requires adapting your communication style, clearly defining roles, and proactively removing blockers for your teammates.

Communicate technical topics clearly

When managing across teams, technical details can easily become barriers instead of bridges. Whether you're speaking to product managers, marketing, executives, or designers your ability to simplify complex ideas is essential. Don't shy away from non-technical stakeholders. Embrace the opportunity to explain technical concepts clearly.

Remember:

• Adapt your language to fit the audience.

• Avoid jargon unless you're certain everyone understands it.

• Keep explanations straightforward and outcome-focused.

I've seen engineers become frustrated by repeated explanations or misunderstandings. Clear, non-technical communication ultimately empowers everyone, enabling better decisions and smoother collaboration.

Clearly Define Roles and Responsibilities

Frameworks like RACI (stands for Responsible, Accountable, Consulted & Informed) helps clarify responsibilities upfront, but they shouldn't dominate your conversations. Use them when helpful, focusing primarily on clarity and alignment.

When defining roles at the start of a project, be specific about:

• Who is doing the work: Clearly name who is executing tasks.

• Who owns decisions: Explicitly identify the individual or group accountable for final outcomes.

• Who provides valuable input: Identify stakeholders who should weigh in before decisions are finalized.

• Who needs regular updates: Clarify who should be kept informed but doesn't directly influence decisions.

For example, a more realistic scenario might look like this:

• Alex (Engineer) → Leads technical implementation → Responsible

• Jamie (Product Manager) → Owns conversion goals and project outcomes → Accountable

• Priya (Designer) → Provides input on UX and design decisions → Consulted

• Riley (Marketing) → Stays informed to coordinate launch campaigns → Informed

Defining this upfront helps prevent confusion and ensures everyone knows their responsibilities clearly

Regularly Revisit Alignment

Communication and alignment aren't one-time events. Regularly confirm:

• Is everyone still clear about their roles?

• Are explanations effective and audience-appropriate?

• Are new blockers or misunderstandings emerging?

Consistent check-ins allow quick adjustments and sustained clarity.

Actively Unblock Your Teammates

Proactively removing blockers is crucial for effective cross-team collaboration. Regularly ask:

• "What's slowing you down right now?"

• "How can I help you move forward?"

• "Do you need more clarity or resources to progress?"

Getting updates and being aligned will enable you to have a birds eye view of the project you're working on and you may flesh out requirements you didn't have before through these sessions, sync with your product manager or manager to understand where you fit into these as an engineer.

Regularly Check Your Approach

Frequently reflect on your effectiveness:

• Am I clearly communicating roles and expectations?

• Am I successfully adapting my communication style to each audience?

• Am I actively removing blockers for my teammates?

If you're unsure about these points, it’s time to refine your approach.

Bringing It Together: Round Up

Managing up, down, and across isn’t about more meetings, more process, or more overhead. It’s about reducing friction, unlocking clarity, and amplifying the impact of everyone around you. Which will enable you to do more with less and eventually you become easier to work with because you become consistent and reliable.

Think of it like this:

• Managing Up ensures you're solving the right problems.

• Managing Down ensures your team can move without you.

• Managing Across ensures your projects don’t stall in silence.

Most engineers hit a point where personal output alone isn't enough. If your week feels heavy, it's probably not a technical challenge. It's a coordination one. This is your opportunity to level up, not just as a builder, but as a force multiplier.

Subscribe now

✅ What to Do Next (Pick One, Today)

Choose one direction: up, down, or across and commit to one clear shift this week:

• Up: Ask your manager: “What’s your top priority for me this month, and where do you need me most?”

• Down: Choose one teammate. Define clear ownership. Stop doing the work for them.

• Across: Pick one project. Create a RACI matrix. Clarify goals, owners, and dependencies for your own sanity.

This is how your real leverage builds.
Not through code. Through clarity.

You care about doing great work, and it shows. That’s why people keep coming to you. Not just your manager, but teammates, other engineers and even people from entirely different teams. A quick favour here, a review there, a little coordination work that somehow turns into a whole side project.

And you say yes. Because it feels right. Because you don’t want to be the person who says no. Because part of you believes that saying yes is how you become indispensable.

But, here’s the uncomfortable truth:

If you keep saying yes to everything, people will trust you with anything except the things that really matter.

Not because they don’t value you. But because you haven’t shown them how you value your time.

It happens quietly.

One week you’re wrapping up a key piece of work you care about. The next, you’re bouncing between requests that don’t seem connected to anything you committed to.

It’s not the work itself that’s the problem. It’s how much of it you didn’t choose. And how easy it’s become for others to choose for you.

The hard part isn’t doing the work. It’s the mental friction. The context-switching. The feeling that you’re making progress on nothing. The quiet resentment that builds when you realize your week got filled before you even had a chance to plan it.

And the worst part? On the surface, you still look like a team player. No one notices the cost but you.

Every yes carries weight.

It’s a signal about what you care about. It’s a bet on how you want to spend your time. And it shapes what people think they can ask of you next time.

But most people say yes without thinking about any of that. They treat it like a reflex. Like the polite thing to do.

So here's the shift.

The goal isn’t to say no more often. It’s to say yes more deliberately.

That’s the difference between being helpful and being strategic. Between getting asked to contribute and getting asked to lead.

But, what if I don’t have that choice?

Not everyone gets to control what lands on their plate. Sometimes you’re filling a team gap. Sometimes you’re the only one with the context. Sometimes your org just doesn’t reward pushback.

This isn’t about pretending you have perfect autonomy. It’s about reclaiming whatever agency you do have and using it intentionally.

You might not be able to turn something down. But you can:

• Clarify expectations before you commit

• Offer smaller, more sustainable versions of support

• Name tradeoffs when they exist, even if they don’t change the outcome

• Track how much of your week is filled by asks you didn’t choose

This isn’t about becoming a gatekeeper. It’s about becoming conscious of your yes and teaching others to do the same.

How to Say Yes Without Losing Control

1. Slow the reflex

Before saying yes, pause. That’s it.

A quick check-in with yourself is enough. You don’t owe an immediate answer.

Buying yourself five minutes of thought can change the shape of your week.

❌ Bad:

“Yeah, I can do that.”

✅ Better:

“Let me check what I have on and get back to you.”

That one sentence gives you space to make a decision, not a reflex.

2. Understand the real ask

People rarely present requests cleanly.

“Can you help with this?” might mean several things:
- “I’m stuck and need your input.”
- “I don’t want to do this alone.”
- “No one knows who owns this, and I trust you to figure it out.”

If you’re going to say yes, say yes to the right thing. Ask a follow-up. Clarify what they actually need before you offer what you think they want.

❌ Bad:

“Sure, leave it with me.”

✅ Better:

“What kind of help are you looking for — input or ownership?”

A small question that protects you from overcommitting to the wrong thing.

💡 Try this:
When someone asks for help, ask yourself. Do I understand what they're asking of me? How much time it'll take and the effort of responding to this right now?

3. Weigh the cost

It’s not just about time. It’s about context-switching, energy, and the cost of being interrupted

Is this the kind of task you can pick up between things? Or does it fracture the focus you need to get meaningful work done?

Engineers often overestimate how “quick” things will be and underestimate how much they interrupt flow.

❌ Bad:

“It’s just a quick thing, I’ll squeeze it in.”

✅ Better:

“This looks small, but it might cost focus. Let me check if that’s realistic.”

Even quick asks can punch holes in your day if they hit at the wrong moment.

💡 Try this:
Before saying yes, ask yourself:
“Can I do this without derailing what I already planned to finish for today?”

4. Make the tradeoff visible

This is what separates dependable engineers from influential ones.

You’re not dodging responsibility. You’re inviting a conversation. You’re treating your time as something to coordinate, not just absorb

❌ Bad:

“Sure, I’ll make it happen.”

✅ Better:

“I can jump in, but that’ll push back the piece I’m working on. Are we okay with that?”

“Happy to support, though I might need to drop X to do it properly.”

“If it’s urgent, I’m not the best person right now. Want me to loop someone else in?”

Surfacing the cost builds trust before things get messy.

5. Decide on your terms

Sometimes, the answer is yes. But it doesn’t have to be right now. Or in full. Or without guardrails.

Can you help without owning the whole thing?
Can you contribute asynchronously?
Can you set boundaries that keep your priorities intact?

Saying yes doesn’t mean giving your time away.
It means offering it intentionally.

❌ Bad:

“Yep, I’ll take it from here.”

✅ Better:

“I can help with review or input, but I can’t drive this one right now.”

You’re still saying yes, just in a way that protects your focus.

💡 Try this: Offer two ways you can support: one light, one deeper.
Let the other person pick what they actually need.

Subscribe now

Final thought: Your yes is your leverage

Every yes teaches people something about how to work with you. It tells them what you care about. What you protect. What you’ll drop at a moment’s notice.

The question is: are you proud of what your yes is teaching them?

When engineers start being intentional about their yes, everything changes. Their priorities become clearer. Their reputation sharpens and people start asking them for the right kind of work, not just the closest kind.

So don’t become the person who says no to everything.
Become the person who says yes like it matters.

Because it does.

Subscribe now