Life Without Leadership

Don’t follow leaders, sang Bob Dylan, a view that would be heartily endorsed by many people, given the antics of politicians across the globe. But when it comes to business, how important is it to have a guiding hand present? There are companies with an entirely flat management structure, but these are few and far between: There usually needs to be someone to set a direction—or to carry the can when things go wrong.
However, when it comes to development teams, it’s a different story. There are companies out there who are surviving, indeed thriving, without a recognized technical leader. That shouldn’t be taken to mean there’s no need for any leadership, though, as there does need to be some guidance to ensure projects can be delivered.

The Agile approach

Used by the vast majority of development teams, the Agile approach provides a pragmatic way of working, one that can obviate the need for any technical managers. Being a method that requires a collaborative approach, where teams can react quickly to change, it’s based on constant iteration and flexible thinking, rather than a rigid hierarchy.

Peter Measey, founder of Agile consultancy Radtac, has experience of working with teams with no technical leader and knows all about such an approach. He believes an actual manager isn’t always necessary for a team to meet technical demands: “Do you need technical skills in the team? Unquestionably. Do you need technical leadership in the team? Absolutely. Do you need a technical manager in the team? Not always.”
The key to the Agile methodology, Measey advises, is to have a team of “specialist generalists,” where a scrum master sets out the requirements for a particular project—a specialist generalist being someone who has expertise in one discipline but is interested in other areas, too.

Measey points out this way of working does require a high degree of self-assessment in the absence of being rated from the management level above. “You get the team to score themselves [on each requirement of the project]—with a zero if they can’t do it and are not interested in learning about it, and with a one if they don’t know the skill but wouldn’t mind learning about it. Then, with a 2 if they know it a bit, with a 3 if they know it well, and with a 4 if they know it well and would be happy to transfer the skill to someone else.”

Having gathered that information, the scrum master can then work out whether the team is well balanced or whether there are obvious pinch points. With this approach, while there’s no technical leader, there is a need for some sort of overseer—in this case, the scrum master—who must assess all the requirements. This is particularly important if additional personnel need to be recruited to fill any gaps. And the development staff should also possess a degree of self-awareness.

David Carboni, CTO at software firm Notbinary, follows his own recipe for making a system with a non-technical lead work: “There is a model that works without someone directing others, but you do need people with experience who can guide and mentor the team.” This could also ensure that all skill requirements are met, as leaders with one skill can teach the others. In other words, in this kind of scenario, there’s not just one leader but a host of leaders.

Widespread acceptance

As with the Agile methodology, one of the issues with this type of approach is that there needs to be some element of self-management. Every individual connected to the team not only has to make the correct technical decisions but also needs to be aware of the wider ramifications. “Each individual is empowered to make decisions, but there needs to be interaction with all stakeholders. Seek the advice of everyone you’re about to affect,” says Carboni. The intention behind this way of working is that the development teams don’t work in isolation and are aware of what’s going on within the organization: A delay in a project may not matter to one department but may affect another, so there has to be a good deal of transparency.

This means that everyone within the organization needs to be aware of the way of working. The development team can’t work within a flat hierarchy if the other departments don’t know what the situation is. “It is absolutely clear that for a flat hierarchy to work effectively, there needs to be total buy-in from the whole organization,” says Carboni, speaking from bitter experience. “I have discovered the hard way. If the top of the pyramid is not onboard with self-management, this can lead to dissonance.”

Heat shield

One approach that works, continues Carboni, is to have someone between the technical team and the rest of the management, a position that doesn’t have a set job title. “They call it a heat shield,” he says, though he warns it’s often a thankless task, as the person protecting a self-organizing team has to do a lot of defending and can end up being continuously questioned about how the team is working.

“I’ve been on that borderline between two cultures myself and it’s a demanding place at best—at worst, it’s emotionally toxic. For self-protection and self-care, you have to know you can leave, but the hope is to have some positive effect on the wider culture.” says Carboni. “Typically it gets increasingly uncomfortable and, at some point, trust breaks down. I think this is because, from the perspective of each culture, the other’s attempts to ‘do the right thing’ are destructive. It’s almost impossible for that to be sustainable, so it’s a gradual ‘burn down.’”

The underlying problem is that there are two types of cultures at play. There’s the divide between IT and the other lines of business, one that’s generally accepted within enterprises. But there’s also a divide between a team of developers trying to operate in a non-hierarchical way and a business practice that isn’t. Carboni thinks of this separation in graphic terms: “I like the analogy of the ‘salt-/freshwater boundary,’ or oil and water. Even where both are genuinely trying to do right, it takes a lot of unquestioning support and trust to sustain this, and they’re not going to be able to mix.”

One of the big disadvantages of a non-hierarchical approach is the lack of speed when it comes to decision-making. “When you have someone there, you can make decisions more rapidly,” says the independent software coach Jean-Pierre Lambert. “When you have no hierarchy, you replace people by processes.” And that’s a way of working that can be very time-consuming, although it echoes Carboni’s point about all parts of the organization needing to be fully onboard.

But that’s not to say that having a manager in place always speeds up the process. One of the problems with appointing such a person, says Lambert, is the promotion process itself. “Companies look to promote the best people, but those with the best technical skills aren’t automatically the best managers.”

No easy answer

So, is it better to work in a non-hierarchical structure or not? It’s not an easy question to answer, as there are so many factors to consider. What development methodology are you employing? Agile is not the answer to everything. What are your team members like? Are they self-aware and good at managing themselves, or do they need guidance? Is the whole company geared to this way of working? If you’re looking for a development team with some degree of people skills, then you may need involvement from the HR department. As Lambert says, “Sometimes, technical skills are the only things that are rated. It can be better to have average technical skills if these are complemented by other abilities.”

But a non-hierarchical approach can be deployed in a wide variety of industries and company sizes. Carboni cites a tomato-processing company with a worldwide workforce of 20,000 that uses this approach, so it’s certainly not something that has to be reserved solely for smaller businesses. And as he says, look at the world economy: “It’s huge, there’s no one in charge or running it from the center, but it all works. There’s nothing stopping any organization going down this path—all it needs are the right people and the right company structure in place.”

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustrations by WTTJ