Great Developers Are Free
For many reasons. But mostly because they are key to efficiently growing a software organization.
A tale of 2 teams
Let’s have a look at 2 software teams in the world of corporate finance.
The junior in-house team
One is an in-house software development team in a large bank. The project already has a bad reputation among developers.The bank has difficulties to hire so the team is constituted of 10 rather junior developers. Unfortunately, without guidance and long term vision, the quality of the code suffers. It looks like an ad-hoc composition of various technologies, glue code, and reinvented frameworks. The overall result is a barely good enough product that costs a small fortune in maintenance and support. The user experience is awful, which make it difficult to the team leaders and the users to collaborate effectively. As a result of all this, the project is suffering from high turnover. Managing this project is really challenging … and kind of depressing.
The experienced software team
Now let’s imagine the same product developed at a software house. It’s been on the market for a while now, but new features are regularly added to it at a good pace. The product is solid and the users are happy using it. The structure of the team is completely different : 5 developers, mainly experienced, coming from various backgrounds. As a result, the team builds on all their different expertises to build real competitive advantages. They tend to get into healthy debates about a lot of things, such as :
- Should we re-use or re-write ?
- Is this gold plating or plain technical debt ?
- Which technology should we use to build this ?
In the end, that makes the product even better. The human side of the team is also completely different. These experienced developers have all been exposed to the big picture during their careers, and they know things like :
- ‘Business talk’ and so they can discuss product topics with the product managers
- The best way to go through chores at work is to do them right now
- Enough management, testing, ops to make the team self organized
The single junior developer in the team tends to mimic this model, and has ease finding mentors, to teach him their trade and to give him career counsels.
As a result, the product and the team remain healthy, and keep providing benefits to all stakeholders.
Benefits of experienced teams
First, from a purely short term financial point of view, it’s a no brainer ! Even if you pay experienced developers twice as much as juniors, the costs will still be on par. But the difference in created value is huge !
Let’s then have a look at the longer term, organizational aspect of things. Obviously, managing such teams requires a lot less work ! Both because of their size and because experienced developers tends to manage themselves very well … Promoting self-organized & cross-functionnal teams is a great opportunity to reduce the management cost and friction, making the organization more reactive and cost efficient in the long run.
What is an experienced developer ?
Obviously, I’ve worked with people that were experienced on paper, but not in practice. I read that repeating 10 times the same year of work only amounts to 1 year of experience.
If I was asked to give a definition, I’d say that experienced developers have worked on different kind of systems (embedded, web, client, server …) using different technologies (Java, Ruby, C, Spring, Rails, Javascript …). Their experiences need not be professional, I’ve seen a physics teacher that hacked himself into a great hacker through side projects and open source. Speaking of the subject, good developers always spent a lot of time learning, reading, doing side projects and contributing to open source. Some can be found in local user groups and online programming communities.
So How do you get them ?
I can only think of 3 obvious ways :
- train them
- keep them
- hire them
I’m pretty sure training them will not be an issue if you already have enough of them. So that brings us to the 2 other points.
Lot’s of articles have been written about attracting and keeping the best developers. Some companies even made it their differentiating point. Here are a few links :
- In his post “The Management Team” Joel Splosky details the inverted pyramid model
- Joel Spolsky’s (again) Development Abstraction Layer explains all the physical environment that makes programmers happy at work
- After disclosing employee salaries, Buffer was inundated with resumes when buffer.com publicly disclosed their salary formula, the number of applications the company received doubled
- Spotify organizes Hack Weeks where the company stops for a while to invent new things
- Google summarizes it “Do Cool Things That Matters” in their long advertises Life At Google
These are just a few examples and are by no way the only things that motivate developers. To summarize, provide the best working conditions (careful, that not money), and communicate a lot about it.
Hiring is too important to be left to HR
Jurgen Appelo said
Management is too important to be left to managers.
I guess the same thing can be said about hiring.
Engineers are absolutely required to take the main role when hiring other engineers. Companies that seriously want to have the best developers on board are spending substantial engineering time on hiring. Here are some well known examples :
- Google is known to conduct around 9 interviews before hiring someone
- In its Handbook for New Employee Valve explicitly states that hiring is your most important role
Endword
As Tom DeMarco said about quality, in Peopleware :
Great developers are free, but only for those who are willing to pay for them
Leave a comment