Are there any obvious drawbacks to hiring only very experienced developers for a consulting firm?

Question

I have been a developer for about 12 years, and for about 4 in my current company. This company is specialized in IT consultancy, but also in legal advice consultancy, financial and economic consultancy and management consulting, for big, international companies. We are about 500 people (about 80% in my country and the rest in a dozen branch offices around the world).

The great peculiarity of my company is that we hire only seniors and very seniors. Simple developers must have at least 3 years of experience, but I’ve never seen anybody with less than 5 years being hired (I’m 37 and I’m in the youngest among the company). Team leaders must have at least 7-8 years of experience. IT managers must have at least 12-13 years of experience and top managers not less than 16-18 years. For the other divisions this is even worse, in fact nobody with less than 15 or 20 years is hired in legal or management consulting.

Among customers and competitors we are recognized as very professional, with great experience and great knowledge, but also for having an above average cost (sometimes very much above the average). I’ve recently started to feel that this business organization must have some drawbacks, but, being a part of the company, I have a hard time finding. So, what are these drawbacks? How can they be mitigated?

Answer 1

Actually, this is perfectly normal (for your line of work.)

Keep in mind, you're a consultancy firm. Those 'seniors' are actually your product. For a regular business - an insurance company, a bank, a music studio, whatever - the IT staff is there to develop/maintain the software the company uses. In your company, the IT staff is the product: you're selling their expertise to other companies. So it makes sense they wouldn't want a lot of junior web devs; if it was something a junior web dev could do, why would your client hire an outside consultant firm?

Or to translate it to a non-IT analogy:

You work at Dirk's, a firm specializes in advanced blacksmithing that non-expert smiths can't perform. And you notice that Dirk's doesn't hire any amateur blacksmiths.

... which makes an awful lot of sense. If the work you need done can be performed by an amateur, why hire an outside expert? And if the work requires an expert, you don't want an apprentice doing it.

Answer 2

Terminology note: In this answer, I use "senior" to mean "has been given more responsibility", not "older". It is perfectly possible to have staff who are older but do not have responsibility, either because they don't want it or because that isn't their skill-set.

The main problem I see is that senior staff (whether in IT or otherwise) want to do "senior staff things". They don't want to do the more tedious grunt work (e.g. wiring up the ORM for yet another CRUD web service, they've all done that 10s or 100s of times before, it's not fulfilling work), they want to be taking responsibility for the overall design of the service, working on the performance of that tricky algorithm, or whatever "interesting" bits of work float their boat. If all you have is senior staff, then you've got nobody to do the grunt work, and that's potentially a problem because no matter how good you think your framework is, there's still lots of grunt work to do.

Long term, if you are hiring only actual seniors (in terms of responsibility rather than years sitting in a chair), I would be surprised if you didn't end up with a staff retention issue, but if it works for your employer then it works.

Answer 3

As others stated before, who am I to criticise the decision of your company to hire only senior developers when they seem to be quite successful with this decision? However since you asked.

• A senior developer might sometimes/often just simply be overkill. A lot of work can probably perfectly be done by a more (cheaper) junior developer.
• When hiring only senior developers has the effect of nobody getting hired under the age of 35, it might mean you are missing out of some of the interesting new stuff they are teaching in the universities nowadays.
• Only senior developers might cause a "too many chiefs not enough indians"-situation. Meaning too many people wanting to be decision-makers and not enough people just doing what they are told.
• It might breed arrogance and complacency when your all your developers get too smug about working in a senior-developers-only company.

Answer 4

One drawback to recruiting based on years of experience is that this doesn't necessarily translate into actual experience/capability. Developer A could have spent 10 years being fed predefined tasks by a tech lead, whereas Developer B could have spent 2 years getting involved with the design and architecture, meeting with clients, and understanding when to prioritise what, alongside actually implementing the work. Developer B actually ends up with more experience due to the broader range of activities they're involved in.

For example, my company tends to mainly hire "senior" developers, but this rarely has any correlation to the length of their career (past a couple of years), but rather their skills and attitude towards the role. They'd all be able to individually work directly with stakeholders to carry out a complex project, if they had to.

Answer 5

The most obvious drawback is that the most experienced developers expect to be paid more than junior ones.

If everybody in your organisation is on a senior pay grade, then you may have difficulty competing with other companies that have a few seniors, and a large number of junior developers. Potential customers may be put off by your higher prices, even if you develop faster and/or have better quality code at the end.

Answer 6

The problem with only hiring senior developers is that you never train anyone. If everyone comes in as a Senior Developer, then you're never doing mentorship of junior developers to build them up and contribute to the developer ecosystem. On a macro level, if every company hired the way your company hires, then software development as a field would die, because no junior could ever get a job; you'd need 3 years expertise for a job, but no way to actually get that expertise.

On a micro level, basically your company is trusting other companies to train their employees, and then take employees that have been trained elsewhere. That means your company basically has no standards for hiring; at the absolute most, your hiring standards are loosely-defined, as they basically amount to "whatever other companies consider to be senior developers, that's who we hire".

Another problem is that your company will never get "first pick" of developers. You'll never get that promising kid fresh out of school who is a rockstar developer but simply needs their first job to prove it. You'll always only hire the second-stringers from other companies, people who are disgruntled with their current jobs, or were underperforming at their previous jobs. Of course, a second-stringer from a company like Google may be good enough, but top talent will never gravitate towards you; better companies will make them offers they can't refuse, especially at a young age when your company wouldn't even look at their resume.

Of course, for your company, all of this might be OK. As a consultancy, you have no code base of your own to maintain, and it provides a better customer experience when a developer who can learn the code base faster joins a client company, than a consultant who takes more time to learn because they're more junior. If your consultant teams are small, then mentorship may not be an issue either, because your people will be working mostly with client developers and not with each other. If you bill your clients more, then the financial issue is lessened because you can pay higher salaries that better talent demands. None of these are really deal-breaker issues, but they are things to consider.

Answer 7

So, what are these drawbacks? How can they be mitigated?

I'll try to answer these specifically.

Drawbacks:

• Cost - Developers with more experience will require more money
• Improvement - Sometimes teaching someone the tech you use can be a valuable lesson in that you are more likely to see the opportunity to do something different or improve something
• Recruitment - It's harder to attract more experienced developers as they already have jobs
• Freshness - New grad are fresh out the factory and are more likely to want to use new technology rather than existing or older tech
• Replicability - New grads are more easily replaceable if you recruit one that isn't up for the job then I can almost always guarantee there will be some other grad that is ready to replace them
• Baggage - New grad almost always have no baggage so they come in with a fresh attitude wanting to jump in and get working straight away. More experience developers have been bitten by something in their old company you'll often have to work around the quirks this has caused the developer to have.

Mitigation:

• Cost - I see no way to mitigate this
• Improvement - You can do this yourself by constantly reviewing you processes / procedure / tools ...etc. Most companies I've been in don't formally do this but it's possible to setup some recurring review process where you look at all the things that can be improved and make actions for individuals to improve these
• Recruitment - You'll need to cast your net much wider so that might be accepting devs who are willing to relocate, work remotely, work on a Visa
• Baggage - Difficult not sure on a way to mitigate this as it's personal to each developer. In terms of attitude towards coding and such then I thing a tool that enforces a specific style that you wish developers to use would be a good mitigation here

Hopefully this helps somewhat.

Answer 8

Disclaimer: The current team I am running is composed entirely of senior (in terms of experience, not age) developers (with one exception of a grandfathered mid-level developer who is well on his way towards seniority).

I’ve recently started to feel that this business organization must have some drawbacks, but, being a part of the company, I have a hard time finding. So, what are these drawbacks? How can they be mitigated?

There are few key issues I've found, either directly or via talking with other people who ran senior-only setup:

1. The price and supply. Those two are linked together, and supply of seniors is usually smaller than the demand, which results in quite high salaries and/or struggle to fill in open positions. It's a balancing factor, either accept that you will have to pay more than market rate and fill your positions quickly, or try to hold to around the rate and try to attract the talent via other means. As it tends is employer led market due to demand, you are the one who has to do a show and dance to get them onboard.

2. Management overhead. As everyone is senior, everyone wants to be heard and usually provide valid perspective on an issue, which if not managed carefully can lead to endless second guessing. While this is a great thing for the project and the company (unless you get into the second guessing nightmare), it will take more time to manage compared to a more junior employees who will often enough take you at your word and run with what you suggest.

3. Retention. This is going to be brutal and maybe a bit cynical, but senior developers can pick and choose and change in jobs at whim (usually). This means you have to keep them happy, engaged and well paid, otherwise they will have little problem with finding a happier, more engaging and better paid employment elsewhere. You will either have to keep them happy on all the fronts or prepare to be able to start looking for replacement, while with more junior employees they will often stay enough longer due to not being pulled away by recruiters every week.

As with everything there are upsides and downsides, and the downsides can be overcome if understood and handled correctly. For example "grunt work" - if the devs feel empowered to drive the product/service/client work forward, and that every bit of work they create is meaningful and it's impact clear (impossible every time, but aim for most of the time) then there is no issue with "grunt work" as there isn't such a thing as "grunt work", just more code to write and problems to solve, but that's more of a general note.

Answer 9

One problem with hiring only highly experienced developers is that some of them tend to come up with very complex and over-engineered solutions when nobody stops them. They might pick programming languages few people in your industry have ever heard of (Bet we can make an ERP solution in Haskell?), make deliberate use of the most obscure language features (Did you know templates in C++ are turing-complete?) and use them to implement elegant yet hard to grasp patterns (Look what cool things we can do with this AbstractDataProviderServiceClientManagerFactoryBuilder).

It might all be obvious to them, but the end-result is a system which can't be maintained by anyone without the same level of experience.

For that reason it can be useful to add a couple junior developers to the team. This forces the senior developers to "dumb down" their design to a level which "mere mortals" can understand and ensures that the system stays maintainable by people who are in less demand on the job market.

Answer 10

A big potential problem I see is that your company seems to equate 'years' with 'experience'.

There are people who spend a year learning to do a job, then keep performing it for the next 20 and never learn anything new. And there are people who start/join a startup at 16 and are running Billion-Dollar divisions by 20.

Having a minimum of 3-5 years is probably alright as long as you're cool not employing any Juniors. Having a minimum of 20 years seems incredibly excessive.

It also means you're only going to end up hiring a certain kind of person. If you're good, 7-8 years experience is quite often enough to be at or above a Team Lead level in other companies. Which means you're probably hiring people who took 7-8 years to get there, IE good-but-not-great developers.

Then knowing that you have to stick around another 5 years just to be eligible for the next promotion? Again, that's going to weed out a lot of talented, ambitious people.

Putting it all together, unless your company pays exceptionally above market for their positions (which, being consultants, they may well be doing), it's a company that's probably only interesting to good-but-not-great or maybe great-but-not-brilliant developers, that only keeps people long term if they aren't capable of progressing too fast in their careers (or don't want to).

Answer 11

One potential drawback is that the firm does not reproduce itself - it only draws senior staff parasitically from other firms.

That might seem fine whilst other firms are willing to be the hosts, but the isolation of experienced staff from new entrants, and the depletion of the experience pool in firms which do recruit and develop the new entrants, will eventually cause a general collapse in skill levels across the industry - at least so far as those skills depend on (or are greatly assisted by) intergenerational transfers of knowledge.

Another potential drawback is the loss of innovation and fresh perspectives. Experienced people have often grown up incrementally with the increasing complexity of their work, and it's not until they attempt to reproduce knowledge of that complexity that it becomes apparent just how overwhelmingly difficult, expensive, or long-winded it will be to do so, how irrational and disordered things have become after a long period of steady accretion, or how too many shared tacit understandings amongst a fixed personnel have caused communication skills and explicit understandings within the organisation to become atrophied.