Why the corporate ladder doesn’t work in the software industry

I never fully understood the corporate ladder in the software industry.

The typical corporate ladder generally follow this pattern: Moving up the ladder usually means you write less code. It means you involve yourself more with business objectives than with technical nuances. It demands you think more about some overall vision and less about the intimate details of code. Architect more, develop less.

The corporate ladder creates a false perception that once you’ve reached a certain level, programming is no longer where you’re most valuable. Leave the dirty work for the junior developers. At the same time, it suggests that lower level programmers shouldn’t concern themselves with the overall goals and direction of the application at-hand.

Great developers should be both “in the trenches” and “high level” at the same time. For software to really succeed, I’d rather have a group of developers that can think about why something’s important, how to best implement something, and then implement it – all at the same time.

When you split up roles into the somewhat arbitrary hierarchy of those that think about the “big picture” and those that only think in if statements and for loops, you lose accountability. Pure architects can make a guess at the best architecture, the best design pattern or the best practice. But, it’s only when you’re in the trenches that you really discover where the problems lie (and don’t lie). And frankly, if you’re not in the trenches, you won’t care all that much about the trenches – let the developers worry about it. The corporate ladder flies in the face of accountability.

Perhaps, we’ve taken the architect-developer analogy too far. Maybe, the corporate ladder in the software industry needs a better analogy.

To build a building, architects architect and developers develop. Architects have a general knowledge of building things – enough to create elaborate plans and specs in fine detail. But, they don’t develop. It’s not reasonable. The separation between those that think high-level and those that work in the trenches is largely for practical reasons. Ask an architect if they could practically design and then build, and I bet many would say yes.