Lessons from the engineering management trenches - real experiments, honest outcomes
14 posts
I vented to my CTO on Monday and left feeling defeated. By Wednesday that frustration turned into action items. A week later he thanked me for it. Turns out ranting isn't negative - it's caring enough to say something's off.
High performers don't make high-performing teams. Communication and autonomy do. Here's why giving your team freedom to make decisions matters more than you think.
Time is my currency. Experience is my compound interest. Most people consume information like it expires tomorrow, but I treat learning like investing - building assets in my brain that pay dividends for years.
I've always thrived on high workload, making things happen fast, multiple projects I believe in. That's when I'm at my best. But there's a pattern: the calmer work is, the calmer I am at home. The more stressed work is, the more irritable I am at home. It's a seesaw. My family is always on the losing end. I have endless professional bandwidth for revenue-generating problems and zero emotional bandwidth for the people I love. Apparently it's called "high sensation seeking" - linked to dopamine. Work under pressure gives me a hit. Playing blocks with my toddler doesn't. I need to design a system that captures the work reward without exporting the stress cost. Still figuring that part out.
I spent 15 minutes getting AI approval for a three-sentence Slack message. My manager called me out: "This is clearly AI generated." The shame isn't about using AI - it's about needing the validation loop at all. Management has no test suite. No passing green bar. So I ask AI. And AI is never uncertain. I validate with AI, then rewrite in my voice, then question if it's good enough. The impostor syndrome was already there. AI just became a second validator that's always available. Still using it as a high-tech rubber duck. Still catching when it strips out my voice. Just naming it now.
My wife says "you're here, but you're not actually here." She's right. The phone is always in my hand. My toddler wants connection and I'm checking Slack. I worked at a company I didn't care about - had perfect boundaries. Now I work for daily.dev and believe in what we're building - and it's taking over my life. The irony: caring about the work makes it harder to be present at home. I give my best attention to the codebase. My family gets what's left. I'm still failing at this. Writing it down to maybe actually change it.
I ask why once, get a surface answer, and stop. Then I either accept it or just tell them what to do. Neither helps my team think deeper. So I researched how to ask questions that guide people to discover solutions themselves. Five Whys for root causes, Five Whats for less blame, GROW for coaching. Plus the "when NOT to use this" guidance - because sometimes you should just give the answer. Not prescriptive, just learning out loud and want to hear what works for you.
Why I quit being an EM the first time (and what changed when I tried again 10 years later). I had training, support, resources - and I was still miserable. I couldn't name what was wrong, so I assumed I wasn't cut out for it. Turns out, I just couldn't identify what I was actually struggling with. This is about the trap most new EMs fall into, and why naming the problem changes everything.
The weight nobody warns you about when you become an engineering manager. You don't just carry your own load anymore—you carry your team's issues, your peers' struggles, and eight projects in your head at once. Your brain never stops. The emotional toll is real. And you can't turn it off even if you wanted to. This is the part they don't tell you about becoming an EM. Both things are true: the work is worth it, and it's exhausting.
The realization that changed how I see my leadership style (and why trying to be calm was making me worse). I send messages then solve them myself. I prototype instead of spec'ing. I jump on problems before thinking them through. Everyone else seems so measured and I felt like I was failing. Then a friend asked: "Isn't that just a superpower?" This is about finding your own management style instead of trying to be someone you're not.
The phrase that changed how I manage (and why asking twice costs nothing). Nobody ever said a project failed because we asked the same question twice. But I've seen dozens fail because we didn't ask at all. This is about why clarity is free, assumptions are expensive, and the real barrier you're building when you over-communicate.
Why engineering managers only get noticed when something breaks (and why that's actually the job). Your team crushes it, and it looks like they're just naturally great. Your team struggles, and everyone wonders what you do all day. This is about the invisible work that makes teams perform, the imposter syndrome that comes with it, and why there's no test suite for management.RetryClaude does not have the ability to run the code it generates yet.
The bizarre reason you can't give honest feedback (and why your team is suffering). The 'Food Was Great' lie doesn't just happen to waitresses. It's happening in every code review. This is about the social friction that makes us choose comfort over continuous improvement, and the simple framework I use to break the cycle.
I spent six months trying to make it work. Six months of coaching conversations, adjusted expectations, and "one more chance" discussions. Six months of convincing myself that if I just found the right approach, the right project, the right motivation - it would click.