Get Rid of Title Hierarchy. By All Means!
When founders coming out of big tech companies like Microsoft or Google are setting up their own engineering team, they often end up creating a miniature version of the teams they were previously in. Therefore, for a team of 4 engineers including the founders, you will see the titles ranging from CTO to VP Eng to Architect to Junior Engineer.
Well, this example is a bit extreme. But you got the point.
Some founders and tech leaders have the intuition that title hierarchy in engineering team is a bad idea. But they can’t articulate why this is the case. After all, shouldn’t an engineer with 10 years of experience and/or capable of accomplishing difficuilt tasks have higher title and more authority than the one on the other side of the spectrum?
To understand why you should get rid of title hierarchy for your engineering team, I’ll describe a scenario that’s probably familiar to most of us who have worked in such organizations.
There is a small project P that Junior Developer J will work on. He calls a meeting to consult with Architect A and Senior Developer S. After J describes her design, S points out a few flaws in the design. Then A comments that the design doesn’t fit all the architectural guidelines.
J pushes back by pointing out a few flaws in the design proposed by S. J also counters A by saying that because of some technical debt that accumulated over the years, making the design to conform to those architectural guidelines will either increase the amount of work by having to refactor some legacy code, or risk breaking existing systems.
They go back and forth until 15 minutes passed the scheduled 1 hour. At that point A and S have had enough and say “we can’t go in circles like this. You can implement it however you want, but we feel strongly that your design is sub-optimal”.
No, neither A nor S have mentioned anything about their titles during this lengthy conversation. But guess what — in organizations with title hierarchy, the titles are clearly written on everyone’s foreheads. Like most other people with enough self consciousness and professionalism, J at this point would just give in, even if just to “be a good team player”.
But here is the catch — J is the one who will eventually code up the whole project, not A or S.
How motivated do you think J will be to implement a design by A or S, a design J didn’t agree to begin with? We can safely assume that J, just like 99% of other developers, would not intentionally screw it up in implementing the design. But software designs on the white boards usually leave many questions to answer, and many details to flesh out before they are converted to an machine-executable binary. When problems inevitably crop up along the way, J probably would not be 100% motivated to put in extra effort, to confront the problems heads-on to come up with an optimal solution. Instead, he will probably just settle with a short-cut that will eventually hurt project’s long-term maintainability, performance, or security. And he is probably more likely to simply throw up the hands. He would probably even have a little “I told you so” moment. Developers are human beings, not machines. We can’t assume that being outranked into implementing someone else’s design will have no effects on their motivation level.
When there is no title hierarchy
Now let’s how the same scenario will play out differently in an organization with no title hierarchy. A and S, who are known for their technical capabilities and experience level (we all know who are the rock-star engineers on the team), have the same title as “Software Engineer” as J. Now they are in the same design meeting for project P, and A and S disagree with the design J proposes. They go back and forth for a while, and J still doesn’t see the merits in the design that A and S advocate. At this moment, simply because A and J don’t have a different title written on their foreheads, J will feel more empowered to say “I still can’t understand why your design will work better than mine. Since I’ll be the one to code it up, and I have a better understanding on my design than yours, I’ll go ahead to implement my design. I will keep your design in mind, and I will switch to it when I come to the realization why it’s more optimal”. A and S, not having the titles to back them up, won’t feel entitled to push back on this reasonable argument. The meeting comes to a swift ending and J moves into action.
But the real miracle is what happens afterward. Again, there will be plenty of problems and crossroads when a project travels from ideas to executable binary form. But this time it is different. When problems crop up, rather than just settling with J will be 200% motivated to find a good solution, even just to “prove that my own design will work”.
“What about the waste of time that J spends to pursue the WRONG design?” You would ask.
The reality is, most engineers, no matter how junior they are, are self-aware enough that, when their designs are obviously wrong, and when the fellow engineer show them why the design is wrong, they will take the advice and revise the design. In a team without title hierarchy, the problem with a wrong design are usually obvious enough that the engineers are convinced, not outranked, to change the design.
Getting rid of title hierarchy is your first step to giving engineers true autonomy. When all engineers, regardless of their experience level, are empowered to make a decision without having to convince everyone above him/her in the hierarchy, their motivation will sky rocket. Yes engineers with little experience will make wrong decisions (and so do engineers with a lot of experience), but they will learn quickly, stay motivated, and on their fast track to becoming next 10x engineers. And the whole engineering team will be jell better and be more productive.
I have tried it. It worked!
Other articles in The Soft Side of Software Engineering Series:
