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.

One response to “Why the corporate ladder doesn’t work in the software industry

  1. One important thing to realize though, is that trying to balance too long on the fence becomes detrimental to both sides of the fence. I can't remember the last time any of you guys patted me on the back and said, thanks for the great code. You have, however, acknowledged the benefit of having someone who mingles 'outside the code trench' … prepping an application to best utilize the programmers time.

    Should I involve myself with low-level programming decisions? I think not. And I think within a 'programmers hierarchy' it's the same thing. Some make decisions, some implement them.

    Now. As for corporate ladders. I always hated being dictated to by someone who had no programming background, no design chops, and little respect for either.

    I think your 'architect' needs to have a respect and comprehension of the 'engineers realm', and it needs to be complimented by the engineers occasionally sacrificing one of their own to make a more efficient build cycle.

Comments are closed.