Four Fuck-Ups in Four Years of Leading Engineers
Where I expected too much, assumed too much, and saw too little
This article has one purpose:
To help you see the assumptions distorting your leadership before they cost you.
These are the mistakes that taught me where mine were hiding.
I’ve been managing for four years now. Long enough to have made some real mistakes and see the pattern in them.
When you’re new to management, you think the hard part is making decisions—strategy, priorities, trade-offs. But for me, the hard part is seeing people clearly. Not as you expect them to be, but as they actually are.
I learned this by fucking up. Four times in particular stand out. Moments where I missed something crucial about how people actually operate, and it cost me, cost them, cost the work.
I’m sharing these because I think new managers need to know: you’re going to get this wrong. A lot.
Management is a slow, humbling education in seeing past your own lens.
This is what that looked like for me.
Names have been changed for anonymity.
#1 - The First Resignation
My first real failure as a manager came with an engineer I’ll call Cooper. Someone with solid experience and credentials that looked great on paper.
For the first year, things seemed fine. But around his one-year mark, the project he was leading started to show cracks. By then, he’d built up so much context and history around it that only he understood. And he was struggling to navigate it.
I did what I thought was right: I coached him. Encouraged him to solve it himself, guided him with questions, and trusted him to find the answer. That’s what you do with senior engineers, right? You don’t solve their problems for them. You help them develop their own problem-solving muscle.
But I was wrong about what he needed. Or more accurately, I was right about the coaching part, but I was too late.
By the time I realised he needed more direct support and help navigating the specific context he’d created, he’d already hit a wall. The pressure became too much and he resigned.
I remember the sting of that. I felt like I’d let him down. Even now, I’ll never know if he resented me for it. He stayed in touch after leaving, even asked me for feedback as he reflected on his next move. But there’s still that question mark.
This is what I’ve come to understand: I was operating from a belief that “senior engineer” had a fixed definition. That if someone had the title, they could handle complexity independently.
But senior is contextual.
An engineer can be senior in one domain and completely lost in another. They can be technically brilliant and still need support navigating unfamiliar territory or a difficult project.
But back then, I couldn’t have done better. I was too new, too busy, too inexperienced to see it coming.
But I can do better now.
Now I know to watch for early signs of struggle. That coaching without support is just abandonment dressed up as development. And that every engineer has things that will especially challenge them—and that’s where they need support most.
The mistake I made was that I expected him to be something he wasn’t yet, and I didn’t see the difference between where I thought he should be, and where he actually was.
#2 - The Second Resignation
Hunter arrived about four years into my leadership. He was hired as a mid-level engineer, but within the first few months it was clear he was operating at an entirely different level. Technically brilliant, fast, and eager to solve hard problems.
We collaborated on an intense project which had CEO attention. We were on the same wavelength, pace, and energy. It felt great, euphoric even.
Then I fucked up.
I looked at Hunter’s performance and thought: this is a high performer who can elevate others. So I paired him with another engineer—let’s call him Oscar—on a different project.
Oscar was switched-on and the same engineer grade as Hunter nominally was. But not at Hunter’s pace or depth. I figured proximity would help. That working with Hunter would push Oscar forward and that some of Hunter’s excellence would rub off.
It didn’t work.
Hunter had no interest in mentoring. He wasn’t wired that way. And Oscar, at a different pace and working style, just felt slow and frustrating to him. The friction was palpable. I could sense it in our one-on-ones and see it in their interactions.
So I did what I thought was right: I tried to fix the relationship. One-on-ones with each of them. Meetings with both together. Brought in Felix, our senior mentor, to help them find a working rhythm. I was treating the problem like it was a communication issue, a compatibility issue—something that better collaboration could solve.
But I was wrong.
The problem was structural. I’d put two engineers with vastly different capabilities and working styles together and expected them to mesh.
That’s a pairing problem. Not a people problem.
When my boss asked “what could we have done differently?”—that’s when it clicked. I’d been so focused on managing the relationship that I never stepped back and said: maybe Hunter needs a different assignment altogether. Maybe he should be repositioned somewhere his talents are fully used, not diluted trying to mentor someone he’s not interested in mentoring.
Hunter resigned.
I brought in Aaron, a junior engineer who matched Oscar’s level better. Things improved immediately.
Here’s what stuck with me: I was assessing Hunter through my own lens. I love coaching. I love developing people. So I assumed Hunter would too, or should. I never asked him what he actually wanted. I just projected my values onto him and expected compliance.
My mistake was that I never saw Hunter. I saw my expectation of what a talented engineer should be—a mentor, an elevator of others. And I missed the actual person in front of me and what he could’ve uniquely become.
#3 - Over-Ambitious Planning
This one repeats every year, despite knowing better.
At the start of each year, I sit down with my team and we set ambitious goals. Exciting projects focused on innovation, research, core competencies, layered on top of the customer projects that keep the business running. I have nine engineers and I always seem to have eighteen things I want them to do.
Competition moves fast and we need to stay ahead. So I plan for all of it, hoping that somehow it’ll fit, that this year will be different, that my team will surprise me.
It never does.
Mid-year, reality hits. A customer project runs into a critical issue and priorities shift. What seemed possible in January isn’t anymore. The exciting research and innovation projects are first to get cut or scaled back.
Then I have to recalibrate—communicate up to my boss and down to my team about why something we committed to isn’t happening.
What that took me years to understand is that I expected my engineers to notice when things weren’t working and speak up about it. Most of them didn’t. They just tried harder and felt guilty about not meeting expectations. And then I had to step in and tell them it was okay, that the goal was changing.
I see my bad pattern was “over promise, under deliver, then manage up.” And that’s exhausting for everyone.
The alternative: under promise, over deliver. Know your capacity, build in buffer, add goals if workload dips.
Ironically, underneath these mistakes is actually high drive and ambition—mine—but projected onto a team with different capabilities and personalities. I’ve had to learn that leading a team isn’t just about my ambition. It’s about matching goals to reality and not underestimating how much real business demands can derail the plan.
I didn’t see what was actually needed: a realistic roadmap, not just an aspirational one.
#4 - Assuming Others Think Like Me
This one’s less dramatic. Just a realisation I’d been projecting my operating system onto people who think differently.
I was reviewing acoustic reports from Hamish and Angus. Same project, same measurements required. But the two reports looked like they came from two different companies.
Hamish delivered something clean, organised, logical. Every slide was purposeful. Images sized correctly, text placed where it should be. All the information was there, clearly presented.
Angus delivered something functional but messy. Same data, same measurements, but scattered. Poorly formatted. Hard to parse.
My first instinct was frustration. Why would Angus deliver that to me? I would never give something like that to my boss. What was he thinking?
And Hamish is more junior than Angus. Yet Angus delivered the worse report!
So I had to ask: what’s actually going on here?
Hamish is detail-oriented and meticulous. His desk is spotless every single day and looks like he’s not even coming in tomorrow. He’s also been with us longer, grown up in our systems, and knows what “good” looks like in our context.
Angus is clever, but his natural working style is looser. His desk is a mess with stuff everywhere. He’s an external hire from a different company, with different culture and standards. For him, if the data is complete, the presentation matters less.
I could’ve forced Angus to match Hamish’s standard, but that’s treating the symptom, not the cause. The real problem was that my template was incomplete. It told engineers what to measure, but not how to present it. So they could interpret “present the data” in completely different ways.
So instead, I refined the template. Added specifics: which font to use, what size, where images should go, how to structure the slides. I created layout examples for the repetitive sections.
Each time the template gets used, I review how engineers applied it, then refine it further. It’s gradually becoming more explicit. It sounds like micro-managing fine details, but with highly routine tasks, it’s actually efficient.
Now people follow the template with minor acceptable variations.
Here’s what that taught me: I was expecting people to think like me. To naturally care about presentation, to intuitively know what “professional” looks like, to take pride in polish. But not everyone does.
The bigger lesson underneath: as a team grows, I can’t coach every individual on every standard. I need clear processes that meet explicit expectations. Templates that work for different thinking styles, not just my thinking style.
I didn’t see what they actually needed: clarity, not a mystic ability to read my mind.
The Pattern
Four different mistakes. Four different contexts. But they all point to the same blind spot: I kept seeing people as I expected them to be, not as they actually were.
In every case, I was filtering the world through my own lens.
But the thing is, I don’t think this is unique to me. We all do this. Filtering everything we see and hear and interact with through our own experience. It’s how humans work and we can’t help it.
But I’ve learnt that the work of management—maybe the work of being around people at all—is noticing that lens exists. And then, consciously, trying to see past it.
It’s recognising that the way you learned to succeed, the standards you hold yourself to, the way you think through problems—none of that is universal. It’s particular to you. Your personality, training, experience, and ambitions.
Everyone else has their own particular combination. And if you want to lead them, you have to see them, not your projection of them.
I’m still learning this. I still catch myself expecting things without saying them out loud. I still get frustrated when people don’t think the way I do. But now I pause and ask: is this about them, or about my assumptions?
Most of the time, it’s my assumptions.
If you enjoyed this article or found it helpful, you can also check out my other related articles: