Two weeks ago I published a post titled ‘Why Smart Software Teams Don’t Need Senior Developers, Tech Leads or Architects‘. I received a lot of good feedback, but I also know it was a long read. So, if you’re interested by the title but are looking for a quick brain dump rather than an enjoyable read, here’s the abridged version:
At Tyro Payments, we’ve doubled our Engineering team over the last year.
We don’t hire for, or use, titles like Graduate Developer, Junior Developer, Senior Developer, Tech Lead or Architect. Everyone has the title ‘Software Engineer’.
This is an important part of Tyro’s Engineering team culture. Here are the reasons…
Reason #1: Assigning a wide variety of roles across your development team suggests a mental model that skills can change overnight, but the reality is that they grow and shrink slowly but constantly over time. (See the funky faux apps comparing binary skills and real skills in the original post.)
Reason #2: A deep hierarchy of roles provides people with a semantic map of their team by which they determine what they’re not responsible for. This is in contrast to what most organisations want: they’re happy for people to develop as much responsibility as they like.
Reason #3: Some role titles make an individual responsible for something that should be collaborated on by the team, e.g. Architect owning system architecture.
Reason #4: Using roles to motivate developers is flawed because they are typically intrinsically motivated individuals. Promotions as rewards also motivate individuals towards competitive behaviour, whereas most companies want to encourage collaboration.
Reasons #5, #6 and #7: A flat hierarchy has three key benefits:
1. The team collaborates better as peers and can more easily harness its collective intelligence.
2. Staff are more engaged as they are encouraged to develop and practice skills organically rather than waiting for a new role to give them permission.
3. The paths for growth are clearer because they are not disguised by an amorphous title.
One downside of less hierarchy is that employees end up with a resume that appears stagnant. This can be combated with honest, broad-reaching titles, sound explanation in resumes and detailed referee statements.
Reason #8: As a case study of whether flat hierarchy works in Dev teams, Tyro Payments has been doing it for 10 years, where the team is engaged, efficient, collaborative, has a high average tenure and has built what is probably Australia’s most reliable EFTPOS system.
Reason #9: The flat hierarchy approach plays together particularly well with agile principles and especially the Extreme Programming values and practices at the core of Tyro’s culture.
Reason #10: Our approach isn’t original or unique. Others call it Flat Organisation and it’s in use at other renowned technology companies, e.g. Netflix.
I think every management team should take the time to consider whether the roles their company dispenses aid their people to do a great job and keep improving, or are instead holding them back.
P.S. Tyro is still hiring great software engineers to join our fantastic team!
…signed Graham Lea, Development Lead. Ahem…
Admittedly, “Development Lead” is neither Graduate Developer, Junior Developer, Senior Developer, Tech Lead or Architect. Nice hack 😉
Fairly questioned. 🙂 My title is technically “Software Engineer & Development Lead”, with the latter mostly involving administrative stuff: recruitment, reporting up, being a poo umbrella, keeping Devs happy, maintaining alignment with other teams, and helping other engineers make decisions about technical and agile stuff (something I did a lot of before the Development Lead title anyway). The Dev team has a flat hierarchy, as described, but it’s not a “zero hierarchy” org.
Excellent observations! I simply couldn’t agree more with what you say here.
I agree with your article about the downsides of title inflation. Also you have rightly admitted that it could make you look stagnant. Titles are a way for you to tell outsiders where you stand in the company and how you have progressed in your career. Plus executives probably have full access to your detailed performance reviews. So, insiders of the company will know your abilities fully well after a few months of working with you. A stagnant title however makes it just a bit harder for an experienced person to be visible in a job market where recruiters would rather simply search by an elevated title, than go through every Software Developer’s LinkedIn page / resume in detail to see where to peg them for the next round. Agreed this sounds like a terrible thing to do, but can a recruiter chime in with their thoughts?
Socialist software development?? Terrible idea. Just as Socialism causes economic rot for any country who adopted it; so will this model of “Socialist Software Engineering”. People need to be driven to excel and have the ability to fly if they are able. There also needs to be a balance of capability on each team…. or you might end up with all the juniors working on one project and the seniors on another… The skill needs to be spread out and people need to have responsibility. Or else just like Socialist states – nobody really tries hard or cares enough.
The only reference to socialism on this page is in your comment. I don’t think any thing I’ve said here prevents employees from being driven to excel, or management from composing teams out of people with varied amounts of capability. If the only information management use when creating a team is names and titles, then the org probably has much bigger problems that assigning titles won’t solve.
Unfortunately, it sounds as if you’ve never had the pleasure of working with a really good architect. I understand that they are few and far between, but really good ones can drive code conformity, set estimation standards, mentor developers and significantly drive up the level of software development across the organization. However, even if you have one in your midst under your organizational ideas, they can’t do that unless they have the authority, which usually comes along with the title.
Thanks for the comment. It’s a good point. Here’s a question: Do you think it’s possible, rather than making it someone’s role to achieve those things, instead to take it to the team and say, “Here’s some things we want to achieve. Can we get a volunteer to drive each one?” Then people from within the team can step up to drive those outcomes through collaboration, rather than relying on one person and a notion of authority?
food for thought – to add: most and from experience i mean ‘most’ companies use titles as grounds to promote up the software career ladder and that is essential to keeping hold of your devs who need to keep moving and progressing in terms of responsibility, value and remuneration. How would you replace titles in this light?
If “moving up the software career ladder” means getting a new title, then absolutely it prevents that. If it instead means taking on more responsibility, providing more value and being paid more for doing those two things, I don’t think any of those need to be tied to titles. If people are typically only getting a remuneration bump when their title changes, I would say that’s an anti-pattern.
In fact, I think titles can get in the way of allowing people to grow. In most orgs, if a team has a Tech Lead, that person will almost always represent the team in extra-team technical meetings. However if there’s no title of Tech Lead, then the team or the team’s management can nominate whoever they want to go to such extra-team occasions, and can share it around or change it over time to give more people increasing responsibility.
Does that mean that you pay someone who produces twice as much code at a much higher quality the same amount as the other guy? If so, that’s idiotic, and if not, you still have seniors regardless of what you call them.
Yeah, that would be idiotic. People should be paid relative to the value they’re providing, which we do.
Do you always pay everyone with the Senior Developer title the same amount as everyone else with the Senior Developer title, even if they produce twice as much code at a much higher quality as other Senior Developers?
Dividing people into buckets just kicks the remuneration can down the road – you still need to evaluate them individually in comparison to each other to provide fair compensation.
I’m pretty sure by definition you only have “seniors” if you have a title called “senior”. Giving more pay to the more valuable people recognises that people’s skills and contribution exist along several continuous axes, rather than being in one of two arbitrary buckets.
This type of conversation is counterproductive to anything. If you have a case study which shows how the removal of titles turned a dysfunctional team into an effective one, then great. Just saying, ‘we don’t have titles and rainbows and kittens’ doesn’t prove anything about titles.
I’ve worked in dysfunctional heirachical, effective heirachical, dysfunctional flat and effective flat. It’s not about the titles, it’s about the people. Some people feel lost without titles, some people feel suffocated.
There are absolutely 0 reasons you shouldn’t have titles, but that doesn’t get clicks right?