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?
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
Great post! If you’d like to dig more in the topic of intrisic motivation and open source, I’ve talked about it in a research conference:
I agree that roles can be harmful for the reasons which you gave in this blog post. However, I have one question:
How do you deal with disagreements? I mean a situation where the development team cannot agree on something. For example, what happens if part of the team want to use technology X and the other part prefers Y?
The reason why I am asking this is that sometimes developers base their opinions on their preferences and they cannot really justify them. This is, of course, a huge RED sign but since developers are people too, this can happen.
I think that the side who can justify their technology selection should “win”. The problem is that the “losers” might not take this very well. Do you have got any tips for minimizing the damage?
Hi Petri. Good question.
At Tyro, we’ve flattened out the development roles, but we still have team leaders (including myself) who are technical people with a role that chiefly comprises non-development tasks.
When it comes to disagreements, our people generally sort things out themselves. Engineers at Tyro pair on all production code, so they get pretty good at negotiating for win-win.
In the rare case where they can’t find a way forward, they’ll usually seek the advice of a team lead. When these conversations happen, I try to avoid the arbiter role and instead try to lead the discussion towards useful criteria that we can use as common ground – usually some Agile principle applicable to the decision at hand – and then hope that, with the authority of the principle established, the engineers can easily find agreement on the issue.
The long game here is to coach people to resolve points of difference by employing Agile principles and agreed best practices, rather than basing their opinions on mere preferences, so that disagreements happen less often, or are more easily resolved, because we’re all on the same page.
Thank you for your answer. I like the fact that instead of making the final decision, the team lead will help the team members to resolve their disagreements. Like you said, this approach will help you to build “better” teams and to share knowledge to all team members.
Pingback: Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects | Paul Herwarth von Bittenfeld - Newsline
Pingback: 10 Reasons You Shouldn’t Have Senior Developers, Tech Leads or Architects | Evolvable Me
Great post!!!!! this article is was I looking for a while. I don’t know if you can share more information, for example, can you tell me how your organization chart is? and how many people do you have in each organization unit? I’m trying to draw in my mind how it would work adapting this concept to a small software company that doesn’t need a large hierarchy.
Thanks a lot.
While I was writing specifically about software teams above, I think there’s lots of benefits that could benefit any team. It may be harder in other teams, though. I think in software teams the work is typically fairly homogenous, requiring a wide and adaptive skill set, so treating everyone as having the same role is fairly easy. In other teams, roles may be more specialised, so it might be harder to have a homogenous role, although I still think there would be benefits to allowing people to organically develop new skills.
Thanks Graham, I found many interesting thoughts that support some of my thinking.
What I’ve met however is that quite often the titles (junior, senior, etc.) mean certain pay level inside companies. And it just easier to work with, especially when the team gets bigger, I guess: you get rid of the “junior”, you get a payrise. How you do it without titles?
Thanks a lot!
Hi Eugene. I’m glad you found the article useful.
I’ve observed the same thing you have: some companies choose to tie salary levels fairly closely to the variety of roles that they’ve allocated to staff.
I’ve described above why I believe that allocating discrete, restrictive titles to software engineers doesn’t make a lot of sense when their skills improve daily and weekly. I think it follows that increasing salaries based on those titles has the same problem; skills increase with each month and each year, so delaying the rewarding of those improvements until they reach some arbitrary threshold level that results in a title change seems unfair.
Without titles, you need to take lots of things into consideration when reviewing salaries, primarily: skills, responsibility, execution, industry experience, company experience, domain knowledge, leadership. Each of these affects the employees’ contribution to the company and so it’s only fair to take all of them into consideration when reviewing salaries.
As for making salary reviews easier, I think most employees would say that reviewing salaries is one of the most important jobs that their boss does, and would consequently be expecting them to spend as much time as necessary on it to make sure it is fair. There are ways to make this complex process less time consuming, but I think trying to change it into a simple process will always end up short-changing some people.
tl;dr – Setting salaries is complex; using role titles as the main input is easier but is a short cut that probably always leaves some good people ripped off.
Excellent post! I recently posted arguing the same point but from a different angle http://adamralph.com/2014/03/15/no-tech-lead/
Thanks for this post. I found it interesting and useful for sorting out my own thinking on this issue. I do find some of what you say to be overly idealistic. In my organization we have a real team working a real software product and on a daily basis a lack of leadership leads to a lot of time being wasted. Decisions that should have been made a long time ago fester on and on and discussions go round and round in meetings. We are in the process of making someone a ____ lead in order to facilitate productive discussions and make key decisions. This is what i was thinking about as I read your blog – i must tell you that i was a little amused when I saw your comment admitting that you do have “team leads” that handle these sorts of situations. I fail to see why a tech lead is bad but a team lead is okay?! Thanks for the post.
Thanks for the comment. To answer your question: at Tyro, Software Team Leads have a number of roles. They act chiefly as an agile coach, and as a delegate for the team in organisational meetings, the point person for HR issues within the team, and they have the responsibility for ensuring the team has enough upcoming work.
The role that a Team Lead doesn’t have, which is important in the context of this blog, is one of a technical authority. They are expected not to tell the rest of the team how something should be designed or implemented. As seasoned developers with valuable experience, they (I guess I should say “we”) participate in design discussions, and bring new ideas to the team and ask whether people want to try them, just like all developers are expected to. But we don’t say to people “it will be done this way”, because once you start doing that you’re slowly killing people’s autonomy and they’ll start the slow progression towards “code monkeys” instead of software engineers. We’ve hired a lot of smart people because we want them to think for themselves and come up with the best ways – new and novel ways – of creating the best experience for our customers. Installing technical authorities over people – command and control style – has the threat of crushing that creativity.
1,25 leveÃƒÂ¤llÃƒÂ¤ pyÃƒÂ¶rÃƒÂ¤tiellÃƒÂ¤ mahtuu hyvin ohittamaan, tosin se vaatii suomalaisesta tuppisuisuudesta luopumista, koska ohitettava pitÃƒÂ¤ÃƒÂ¤ komentaa pysymÃƒÂ¤ÃƒÂ¤n tiukasti reunassa. Kolmenkymmenen vuoden harjoittelun jÃƒÂ¤lkeen uskon ettÃƒÂ¤ tuo alkaa suomalaisiltakin sujua.Vasemmalle kÃƒÂ¤ÃƒÂ¤ntyminen pyÃƒÂ¶rÃƒÂ¤tieltÃƒÂ¤kin onnistuu ryhmittyen ihan hyvin. KyllÃƒÂ¤hÃƒÂ¤n reunakiven aina alas ajaa. YlÃƒÂ¶s tuleminen on sitten hankalampaa.NordenskiÃƒÂ¶ldin aukio on kyllÃƒÂ¤ suunniteltu ihan pÃƒÂ¤in seiniÃƒÂ¤, mutta niin se on kyllÃƒÂ¤ sellaisenakin kuin se on nyt.
Graham, thank you for sharing your insight. I have seen the architect role used effectively as a cross team expert. Those people who are the most knowledgeable about the system, of whom there are only a handful, are used as the experts but there are less of them than there are teams so each team gets part of an architects time as they float between teams. This approach does have its difficulties however it does have the advantage of the architect being able to see what is going on in the whole product and make connections that are difficult for others to see.
Do you have roles like this across your teams? Is that job done by the team leaders, a product owner, a Product Line Manager etc.?
Another comment mentions about linking pay to roles and I think your reply is very sensible. You do mention that keeping people at appropriate pay is a key role of managers, have you considered the ‘Google way’ of peer reviews feeding into a pay committee? I ask because the pay committees at Google apparently consist of people of more senior bands and so would be incompatible with everyone being at the same level.
“Agile mindset”…still hawking that snake oil I see. 10x-100x productivity improvements…PT Barnum w/be proud.
I’ve never heard anyone claim agile development produces massive productivity gains, and I doubt anyone who understands agile well would make that claim, because that’s not what it’s about.
The first principle in the agile manifesto says: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The focus is on satisfying customers, not moving quickly. This is in contrast to waterfall-based methods which focus instead on attempting to create a plan before developing anything, getting a sign-off, and then executing the plan. The focus is on the plan rather than the customer. Agile recognises that plans often change once the customer starts seeing what’s developed and builds that feedback into the development process.
In short, it’s not about delivering the product quicker, it’s about delivering the right product. If you understand this, maybe you’d like to reevaluate agile methods against their actual claimed benefits and see how they stack up. I think you’ll find they’re much more effective than snake oil.
Pingback: Design Kata: Learn software architecture while having fun - Evolvable Me
Pingback: 4 – 10 Reasons You Shouldn't Have Senior Developers, Tech Leads or Architects | Traffic.Ventures Social
Pingback: Software Design Towards Simplicity With Value Objects | Haefele Software
Pingback: Career Growth Framework — Haefele Software — High-Performance Dev Teams