We’ve almost doubled our Engineering team at Tyro Payments over the last financial year and we’ll be adding that many again this year.

Most people who’ve worked in or with software teams would imagine that within this surge of hiring we’ve been filling all kinds of different roles – Graduate Developers, Junior Developers, Seniors, a couple of Tech Leads, maybe an Architect. But the truth is we’ve only been hiring for one role: Software Engineer. In fact, it’s the only development role on our team, and it’s the title we give to everyone on the tools, whether they have 20 years’ experience or none. This isn’t just some convenience we came up with to save ourselves HR work. It’s an incredibly important part of the culture at Tyro. Why?

The Mental Model of Roles

The biggest problem with bestowing upon staff a cornucopia of role titles is the mental model that it suggests. Different titles communicate different skill sets. Yes, different people do have different skill sets – that’s a fact – but one’s title can change overnight, while one’s skill set obviously does not.

So here’s my interesting question for you to ponder:

What would the mental model of software development roles look like if we illustrated it?

The answer is that it would look something a lot like this:

However, anyone who has ever used their brain to develop skills can instantly see what is wrong here, because skills actually work like this:

And those sliders don’t all just jump up a notch on the day someone gets promoted. They’re going up little by little, hopefully every day that they show up for work, and even some nights at home.

Don’t get caught up here on which skills are turned on or off or where the sliders are set for each role. The differences between the roles are not the point of the illustration. The point is that skills do not switch on or off at discrete points during one’s career. Skills increase, and sometimes even decrease, along a continuum; they do so with the passing of each month, day and hour; and they change at different speeds and with different emphases for each individual.

Assigning roles that can change overnight to your staff communicates a mental model that’s a really dodgy abstraction of what life is actually like. Beyond just being a poor abstraction, though, allocating a variety of roles can have ill effects that I think make it worth re-evaluating their usefulness. Alternatively, running a team where there are fewer distinct roles has some very nice advantages.

Roles Considered Harmful

An array of titles within a team works like an atlas of skills – a semantic map by which people can determine the boundaries of their responsibilities and the boundaries of those around them.

You may now be thinking, “Hey, hey, hey! No one has boundaries to their responsibilities in our company! Everyone is encouraged and expected to contribute wherever they’re able.” This is the culture many want, and you may even have it to some extent. However, segregating your staff using a deep hierarchy of roles can have the opposite effect.

By assigning different titles to people that do similar functions, a clear expectation is set that the senior developer is responsible for things which the junior developer is not expected to do. A clear message is broadcast that they are not expected to get involved in some things. In most progressive companies, we’d really like everyone to be trying to emulate what the most experienced and most skilled people are doing, but handing out specific titles tells people, “You don’t need to do that; someone else has that job.” Roles often tell people what not to do.

On the flip side some roles – ‘Architect’ for example – imply individual people are responsible for things which really should be owned by the team, not by one person. I’m sure there are architects that are fantastic at guiding their team through the collaborative research and discussion that’s required to bring about a great technical solution which also provides a productive ecosystem for developers. I’ve heard many war stories, though, of ivory tower architects who just hand down technology edicts from on high with no one else’s input, sometimes even ignoring feedback from those that are already going through hell using the same stack. Can they be blamed, though? Their title tells them they’re responsible for architecting stuff; they’re just doing what’s expected!

And so the atlas of role titles discourages some people from trying the things that we’d actually like everyone to be trying, while also assigning responsibility to individuals for some tasks that actually should be collaborative.

Roles are a Great Motivator, Right?

I suppose an argument might be made that roles play a major part in motivating people, and I’m sure that is true for some. Do most software developers see that next promotion as a major goal, though? Do they apply themselves to it, stretching their skills until they reach it? Discussing this issue on Twitter, someone wrote “Smart guys don’t care about titles”, and I have to agree. The guys and girls I’ve seen that make the best software engineers are the best at what they do because they are intrinsically motivated by the fun and challenges of writing great software that does something useful. They don’t work hard because they want to prove something to everybody else, move up a ladder and get a new business card. They just do it because they love it and want to keep getting better at it.

On teams where collaboration is crucial, as it is in most software teams, using titular promotions to motivate staff could be not just ineffective but actually damaging. The purpose of any motivational tool is to encourage one type of behaviour over another. What kind of behaviour does the use of promotions as rewards encourage? It encourages individual efforts. It sends out the message that, to achieve the next reward, to be seen as more important, staff must first put in more effort than their coworkers and then make sure the guy in charge of the promotions knows that they are the star, more than other people. This is a culture of competition, and people in competition with each other are not working together as a team, at least not to the extent that they could be.

The Benefits of Less Hierarchy

Having a variety of roles conveys an inaccurate mental model of people’s capabilities, places boundaries on people’s responsibilities, and can be divisive if used as a motivational tool. What can happen if you greatly reduce the number of different titles in a team?

Benefit 1: Full-Throttle Team

The first benefit of loosening the boundaries of people’s responsibilities is that, instead of having one person’s opinion dictating the design of systems, we have a team of people all contributing as much as they’re able. Maybe the guy with only one year’s experience saw this exact same design problem solved at his first job and can guide the team toward an immediate success which, without him in the room, would have taken months to re-discover. In this way, a company can turn the knowledge, experience and viewpoint of the whole team into an unfair advantage. They are leaps and bounds ahead of those companies that are still trusting one or two people to make guesses about what is the best direction for the company’s technology and process.

Benefit 2: Engagement

The second benefit of loosening the boundaries of people’s responsibilities is that everyone gets involved. The developers who, in another workplace, would have a junior-sounding title that suggests “you’re not expected to do that”, instead get the message: “everyone’s expected to do that (to the extent that their skills enable them)”. Instead of being excluded, they’re invited. Even if they can contribute nothing, they’re still in a position where they can observe those who have mountains of experience and learn how more “senior” tasks are achieved. This means they get to absorb skills by osmosis and can start contributing incrementally, but with confidence, as they learn. Isn’t that a far more engaging way for people to develop than having them plug away on trivial stuff until someone realises they’ve been around five years, slaps a ‘Senior’ badge on them and throws them in the deep end?

Benefit 3: Clearer Growth Path

A team that has a deep hierarchy of roles has growth goals that are more obvious but, at the same time, the path to the goals is not as clear. Huh? Well, they’re more obvious because the goal is simply, “advance to the next position”, but often what is required of the next position is not explicitly defined for those trying to get there – it’s just a title. Many times we’ve asked job candidates what a Senior Developer is and their responses is simply “someone with about 5 years experience”.

An additional problem with career paths is that some roles are limited in number. A company that has Tech Leads and Architects only needs so many of them, so if those roles are already filled but that’s your “next step”, what are you goals supposed to be? Wait around until one of the people above you quits? Look around for another company that will give you a promotion?

With no hierarchy, the goals are not as definite, because they don’t have titles, but the path is clearer: you are a software engineer, and you need to grow into… a better software engineer! Leaving the metaphor behind, the reality is there is not one path but many paths along which engineers must walk in order for this to occur. The good news is that, in a team with no competition over promotions, we find others are extremely keen to share advice on how to grow, because each person’s improvement enhances the whole team. In a team with a culture of titles and promotion, anyone who has their sights on that next promotion will put a lot of work into their own development, but they may think twice about helping the guy sitting next to them to get better, lest he takes their advice and uses it against them.

What About Career Prospects?

One downside for developers on a team with fixed role titles is what happens if they choose to move on. Does it looks bad on a resume? You stay at this awesome company for seven years and learn a bucket load, but your CV says you came in as Software Engineer and you left as a Software Engineer.

I think there’s three elements to smoothing this bump. Firstly, the title given to everyone must be a title that represents the full gamut of skills that they may be employing, and I think “Software Engineer” fills this space nicely. It would be disingenuous to call everyone on our team “Java Programmer” when part of their job involves architecting a 24/7, distributed, real-time payment system. Secondly, people who move on need to have the wherewithall to know what level they are at and to own it on their resume with a statement like “I was involved in the following tasks that would typically be part of a Tech Lead role: …” Thirdly, team leaders need to back up their previous employees in reference checks and confirm, “Yes, her title was software engineer, but she was a natural leader here in tasks that would be owned by an architect elsewhere.”

Does It Work?

That’s the million dollar question isn’t it? We’ve been doing this at Tyro Payments for 10 years now, and what are the results? We have an engaged team of highly-skilled and constantly-growing software engineers who’ve architected and developed what is probably Australia’s most reliable EFTPOS system. We have extremely low turnover and long tenures compared to most of Sydney’s software development scene. Above all, the team acts as an efficient, collaborative machine that has no concept of the competition that exists between peers in other firms.

The flat hierarchy approach plays together particularly well with agile principles and especially the Extreme Programming values at the core of Tyro’s culture. Communication, Feedback and Respect all become easier when the team treat each other as peers with different skill sets rather than as masters and apprentices; Simplicity is more likely to emerge when you utilise the collective intelligence of a team with a variety of experience; Courage is fostered when challenging expectations are given to less experienced developers and also by removing the risk that a brave decision that doesn’t pan out might cost someone a promotion. Extending into agile practices, shared code ownership (Martin Fowler’s preference!), relies on developers subduing their ego, something they’ll find far easier if we don’t go giving them titles that are intended to puff up their ego! And this list could probably be extended to the length of a whole separate blog.

Think About It

This idea is a bit radical, but it’s in no way unique to Tyro or even niche. Earlier this week I was coincidentally reading about culture at Netflix and found that they’ve used the very same policy in their software team. These are teams of very smart people who have achieved great things, and the flat hierarchy has paid dividends both for the companies and for their (very happy) staff.

So have a think about the roles and titles on your team and what effect they’re having. Are they communicating an accurate picture of skills and goals, motivating people in the right direction, and encouraging the team to get better at collaborating and sharing knowledge? Or are they having the opposite effect?

Come and Join Us

By the way, did I mention that we’re currently hiring great developers who want to join this team of awesome Software Engineers in Sydney?

Image credits:
Queue for Steve Jobs keynote at 6 ‘o clock by Jean-Michel Reghem
Lego Marvel Avengers by Do-Hyun Kim
Time to re-org the org by Dave Gray
Success by Alosh Bennett