Or – why you don’t need to hire heroes
Before I start, please understand that I am not trying to belittle anyone here, or infer that they are a second- or third-rate developer. I personally could not make it through the Google interview process, so include me in the category of “developers that Google rejects”. (Though I’m pretty sure I could have gotten through the interviews when fresh out of college, when all the math and computer science algorithms were fresh in my head. With that in mind, I find it no surprise that 98% of the company are under 30!)
The Software Giants have hired all of the top-shelf developers
“We can only hire middle- to low-end developers here at our company. Google, Microsoft, and Amazon pay more than we can, leaving the market with only second- and third-rate developers. Even if we had the money, there aren’t any first-rate developers around, because these software giants have sucked them up from the development pool.” This is a rough quote I heard from someone working at a software firm in the Pacific Northwest. His perception was that the quality of developers and development has been steadily falling at his company during his tenure. The firm used to be able to attract high-level talent, but found that it now was unable to match the salaries and packages of its very wealthy software giant neighbors. I assured him that all was not lost and, in fact, the firm is in a better position than he thinks! Read on.
Teams can do things that geniuses can’t
The collective capability of a team is larger than that of a genius. Agile development is based on self-organized and self-managed teams. The synergy of a team’s collective mind and skills will give you the same, if not better, results than the genius approach, along with some other added benefits. These include:
- You don’t have the “win the lottery” or “hit by a bus” scenarios to worry about
- Knowledge is spread among the team, so vacation time doesn’t affect your project plan
- It is cheaper (as you are able to hire juniors and the middle-shelf developers)
- You’re less likely to have to deal with large egos (that you often find with elite devs)
- Working with a team is fun
- Recruitment is easier (as you have a larger pool to pick from)
- Teams come up with more options when problem-solving, since there are many points of view
Creating a team
Are you sold? If so, you will need more than just lumping a group of devs under one project and calling them a team. That is a group, not a team. The real magic happens when this group of devs have had time to gel together and go through the forming, storming, and norming phases to become a team. To foster this, I recommend co-locating the team in a collaborative (open space) environment, preferably near the customer they will be working for. This team will come up with creative solutions above and beyond what a single genius developer could. OK, now we have the start of a team. Next is a process to ensure that the same results (complex algorithms) can be achieved.
A software process that will get you to the same point as the genius
Enter Extreme Programming (XP). The processes of simple design, TDD, and merciless refactoring will return the matching results that a genius would. These practices are a repeatable and reliable way of producing code of high quality and complexity.
The genius interview process usually entails complex questions or scenarios that require a very clever algorithm to solve, and the test is to see if you can come up with the correct algorithms and approaches that they have in mind. If you were to create a set of acceptance criteria and tests that would determine whether the result met your requirements, I can pretty much guarantee you that I can solve the problem — particularly once I understand what you are trying to achieve, so I can iterate from simple through complex and get feedback throughout. And that, my friends, is XP in a nutshell.
The Extra Perks
There are more perks that come with XP and with an Agile team approach:
- Individuals can come and go from the team throughout the process, and progress carries on regardless (though you want to minimize team changes — team persistence, pair programming, collective code ownership)
- The code is easy to read/maintain and quick to debug (collective code ownership, coding standards)
- You will not be accruing technical debt, which would ultimately result in a legacy system (merciless refactoring, sustainable pace, automated testing)
- Minimal to no documentation is required (code as documentation, tests as documentation, refactoring tests)
- New and junior developers have a very short lead time to reach full productivity when joining an XP team (simple design, pair programming)
A persistent cross-functional Agile team practicing XP will deliver high-quality results more quickly and at a lower cost than relying only on top-shelf developers.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.