Decision-Making Pitfalls for Technical Leaders
Tech’s favorite party trick is promoting programmers into leadership roles with zero coaching on how to make the transition, or even a briefing on what the role entails. The programmer accepts the promotion because…I mean, of course you’d accept a promotion. Then, they quickly find themselves in over their heads.
In my experience, it is at least the case that when programmers become trial-by-fire managers, they realize they don’t know how to do their jobs. Technical leadership—tech lead roles, principal eng roles, and even the dreaded “player-coach” role—those sneak up on people. A lot of times there’s still programming involved, so folks feel prepared. Their experience has exposed them to technical decisions and it got them promoted, so the way they do it is probably fine. Right?
The thing is, certain decision-making pitfalls have limited negative impact at the “line programmer” level. They even appear in discussions of tech culture as lovable idiosyncrasies common among the gearheads. They become less lovable as the gearheads get more power, though, and those pitfalls produce a larger impact crater. Three in particular come up repeatedly and cause projects to falter or fail. Let’s go over them.
