Is hierarchy bad for software development?

I attended a talk today by the phenomenally successful Estonian startup transferwise on how they built autonomous engineering teams. The case they argued simply and effectively was that the people who focus on a problem all day every day are the best equipped to make decisions around that problem. Extrapolating from here, they framed their tiny management team as an advisory board and devolved decision making power to the people. It’s pretty hard to argue against this as a decision making approach, but it led me to thinking about what management and hierarchy are actually for in a company.

Escalating and devolving responsibility for decision making is certainly one responsibility of management, but if I look to my own expectations of management the primary interaction I aim to have is around professional development. On making me better at my jobs and helping me to learn new skills.

I quizzed transferwise on how they develop their staff and their first reaction was to discuss how effective their peer review was for improving engineers and how they ensure a minimum of 3 engineers per team so they could help each other out.

‘What about product managers development?’ I asked. Nothing. No development for product managers. The hire only senior product managers so they don’t need to develop them (as there’s no one to develop them). The only development around product managers was for senior product engineers wanting a career change.

For me, it is here that their ideas around dissembling the decision making hierarchies within teams and across the company comes into conflict. If you only hire PMs that are so senior they don’t need development, by virtue of superior experience alone they will take command of their teams. The minimal support they receive could act to distinguish them in their own and their teams minds. As a result of this, despite stressing the idea product managers have no authority over their teams, I’d predict they are bestowed with it by the fact they are different. Furthermore, were all companies to treat product management like this, the only way to become a product manager would become to transition from being a senior product engineer. This is totally unnecessary. I know from experience product management is a very learnable trait and it’s bad economics to deploy precious development resource to a domain they don’t necessarily have experience in.

That’s enough criticism, my position by now is pretty clear — I think seniority and hierarchy is important to the survival of the profession of product management. While the paradigm is maintained that 1 pm per team of engineers is the best way to build software, there needs to be a way of cultivating and developing pms. Otherwise, ironically, teams can never be devoid of hierarchy. What’s important is that the management structures that do exist position themselves as advisors rather than dictators. I’m reminded of a position that existed in schools when I was a teacher - lead practitioner — not positioned to tell anyone what to do, but there to advise on how best they could do what they are doing.

To conclude: autonomy is awesome; but so’s hierarchy. It helps develop people, makes them feel valued and improves the return on the investment a company made in hiring them. Let’s stop thinking of these things as mutually exclusive…