He Wasn't Analytical. He Was Slow.
A story about being paired with a senior engineer who spent a refactor sprint building a spreadsheet, a manager who wouldn't name a lead, and the five leadership lessons that came out of being told I was too junior to see what he saw.
Early in my career I got put on a rough software-transition project with another senior engineer, no assigned lead, and a manager whose plan was "you two will work it out." He spent the sprint measuring C# import delays and building a spreadsheet that proved something any C# dev already knows. I escalated. My manager's answer was that I'd appreciate how he worked once I'd been in the field longer. Years later, now a manager myself, I still hesitate when an engineer reminds me of him, and that hesitation is what this piece is actually about.
Key takeaways
- "It'll be good for you" is often a manager dodging a decision: no named lead isn't trust, it's avoiding a hard conversation; ask why
- Analysis isn't output and can be a hiding place: busy isn't productive, and rigor and stalling look identical from a distance; good analysis changes a decision
- Tenure isn't expertise: years can mean judgment or years at a desk; evaluate the work in front of you, don't defer to the longest-tenured
- Bad management outlives the project: defending the wrong person plants self-doubt in the person who was right
- What I do now: name the skill gap plainly ("clear is kind"), always assign a lead, attach a decision to every analysis
Who this is for
Engineers who've worked with someone they couldn't get to move, and managers who've been tempted to let two people "figure it out" instead of making a call. It's an engineering-culture essay, not a technical one, and I hold the payoff until the end on purpose.
The full story, including the trip to New York that kicked it off, is on Substack.