Organic leadership is the key to success for software developers at enterprise translation platform Smartling, according to the company's CTO, Andrey Akselrod. In an interview with The Enterprisers Project, Akselrod explains how organic leadership differs from holacracy, and why it's a powerful approach.
The Enterprisers Project (TEP): Holacracy is growing in popularity as a way to organize companies. Is that similar to the organic leadership you practice?
Akselrod: Organic leadership, as I define and practice it, is not the same thing as a holacracy, which we're seeing more of lately. While there are similarities between the two, there are also a number of marked differences, the most crucial one being that in a holacracy the hierarchy of control is removed. When I speak of organic leadership, the hierarchy is still in place for management reasons; it is the individual roles within teams that are allowed to organically develop among that team's members.
TEP: So you create teams but don't assign team leaders? How big are these teams? How well has this been working?
Akselrod: The teams tend to work better when smaller — three or four people, generally. It's worked very well so far, and we've been doing it for over four years. It's something we consciously implemented, since this is how we wanted to run things. Our belief — and our results back this up — is that it leads to happier developers. And a happy employee is a more productive employee.
TEP: Every team needs leadership, so the goal here is for a leader to emerge naturally within the team. But what if that doesn't happen? Or two leaders emerge in competition with each other?
Akselrod: Occasionally, a natural leader will fail to emerge, but this is very rare. We don't assign people to teams randomly; we set them up with others where we think they'll succeed without forcing people into roles within those teams. Often they'll self-select the role configuration within the group that we had assumed, but we're regularly (and pleasantly) surprised when a different setup emerges than we expected, yet still works just fine.
There are occasional situations where two leaders emerge and are in competition with each other, which could lead to problems if left unchecked. When this happens we reshuffle the teams, assigning out developers to a different project. Once we have a team in place that is humming along nicely, we like to keep that team in that configuration when possible, since ownership of projects in the long term is very important.
TEP: Have you seen any measurable improvement to the development cycle?
Akselrod: I'd certainly say our development has benefited from organic management. As I said, happy employees are productive employees, but they're also ones who will stick around and invest themselves in the company and their work. We had three years recently where there was no turnover in the department at all. Since then, turnover is still rare and when it happens it's usually because someone wants to go and start a new initiative or company. It's always sad to see them go, but it's something that should be celebrated.
TEP: Beyond the question of who leads a team, other roles within your teams are also allowed to form organically with people with different skills and interests taking on roles that fit them best. How do you and your teams cope if two team members want the same tasks? And are there ever tasks that no one wants?
Akselrod: Any project out there is going to contain both sexy things to work on and other things that are less so (think maintenance, etc.). Any good developer knows that both of these types of things need to be taken care of — someone has to get it done.
We cope with this reality in three main ways. First, we try to nip any issues in the bud during hiring. During an interview, it's made clear to the prospective employee that while there are opportunities to work on very interesting assignments with us, there will be some less interesting work that needs to be done. That's just the nature of the beast. Most people understand this, and appreciate knowing it up front — especially the senior developers who we aim to hire the most. When you are staffing a startup, you need people who know what they're doing — things move fast as the stakes are high. These people also know what to expect from a workload diversity standpoint as they've done all this before.
Second, we try to keep a balance of interesting work to less interesting for each person. Everyone will work both sides of the spectrum at some point. We sometimes do it like a round robin, and people have no problem with this — it's expected in this kind of environment, and is as equitable as possible. And finally, when it's someone's turn to dig into the not-so-sexy tasks, we tie those whenever possible to the business side of things. Understanding how the day-to-day tasks fit into and affect the business on a broader scale helps to make the work more interesting and enjoyable.
TEP: When I've talked to people about self-managed groups or flat organizations in the past, I've often been told that this arrangement isn't a good fit for everyone — you have to make sure to hire people who work well in this sort of culture. Do you find that's true?
Akselrod: In a way, this is true. There are notable examples of a holacracy being implemented that forced some people to walk out of the company because it simply wasn't for them. But those tend to be some of the more extreme cases of implementation, and with organic leadership we're governed by common sense. Also, flat isn't really accurate for organic leadership; there's still a hierarchy of management in place around the self-selecting roles.
We look for a cultural fit in the interview process to avoid the kind of issue that some holacracies face, though we've found our style to be less of a challenge and more of a strength when it comes to hiring, frankly. Most people like to work for a startup that has a no-nonsense approach to developer culture but remains flexible and open to improving the processes as employees or common sense requires. This helps us attract talent.
Another thing that helps is our commitment to transparency in the department. From prospective employees on, our developers are able to see how we do things, and people can always have a hand in improving processes. One example of making sure that we have a cultural fit in the interview is Test-Driven-Development (TDD). It's not everyone's cup of tea, we know this. Some developers won't work this way, but it's how we do things, so we mention this up front in the interview process, and ask how the prospect feels about TDD. Some will say they prefer it — no problem there. Others will say they don't, but what's key is the next part. Those who do not prefer TDD are asked why they don't like it, and pretty soon you get a clear picture of their commitment one way or the other: Either they are willing to try it and are flexible, or they're not a fit for us.
This is just one example, of course, but it's emblematic of how we aim to be straightforward and upfront with future team members. Our leadership style and culture are not something we need to work around when hiring, they're actually one of our biggest strengths.
