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?

  • 1
    How you seen any particular drawbacks? Commented Nov 30, 2020 at 10:18
  • 4
    Changed the title as "Hiring seniors" could easily be misconstrued as age-related rather than experience-related.
    – Kaz
    Commented Nov 30, 2020 at 10:21
  • I didn't seen any particular drawbacks, but speaking with some friends they suggested that on the long run, this business model has some problems: increasing difficulties in hiring people, increasing costs, not be able to use new technologies that usually are more easy to young people, etc. I want to know if these can be true or not
    – ThomasJC
    Commented Nov 30, 2020 at 10:36

11 Answers 11


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.

  • I think you can similarly say lawyers are actually the "product" of a law firm, yet those firms often hire people straight out of law school. If television is to be believed, even the top firms do this, although they tend to hire from the top schools. Like lawyers, some companies may just prefer to use a firm instead of going through the effort of setting up their own internal developer team. Commented Nov 30, 2020 at 19:01
  • Is this "normal" though? You presented an argument that it makes sense, but not that firms commonly do this. Something can be both logical and abnormal. Commented Nov 30, 2020 at 19:07
  • 1
    The more cynical sort of company will reel in a customer, based on the immense skills of their senior developers. Then, once the customer has signed the contract, then they will send the new graduates to do the work.
    – Simon B
    Commented Nov 30, 2020 at 23:08
  • I dare say this is wrong. Like lawfirms do not only have top end lawyers - there is a TON of grund work. I would agree that top line consultancies hire MORE experienced developers than normal companies (as percentage), but there still is room for 10% or 20% inexperienced developers to do "helper position" style work.
    – TomTom
    Commented Dec 1, 2020 at 12:44
  • 1
    @BernhardBarker: my point is that it depends upon the type of business. Although the companies might both be called consultants, a company that specializes in outsourcing and a company that specializes in troubleshooting are going to have different markets and need different employees. So different it is entirely possibly that they have no overlap outside of accounting.
    – jmoreno
    Commented Dec 2, 2020 at 3:05

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.

  • 5
    I think the problem with this answer is that it doesn't address that OP works for an IT consulting firm. IT for them isn't internal - it's collective knowledge is the product the company sells.
    – Kevin
    Commented Nov 30, 2020 at 18:08
  • 5
    I am a senior and I always enjoy writing an entire app even if I do it for the 20th time. Having a skillset has nothing to do what a person enjoys to do.
    – Sulthan
    Commented Nov 30, 2020 at 18:55
  • 1
    @Sulthan I would say your attitude is probably fairly rare. My experience with senior, and worse yet "senior-but-really-intermediate" people, is that ditch digging isn't what they want to do. If there is a challenging problem that pops up during the more rote work, they're on it like a fly on shit. The second the interesting/novel stuff is solved, they want to hand it off the more junior people. It's worse if they need to do it, and they can browbeat their manager in to believing that they're blocked on something trivial for them to resolve.
    – Malisbad
    Commented Dec 1, 2020 at 0:43
  • They're always some grunt works to do. For instance if the seniors guys produces reports to delivers to the client. You can have a technical validation (the content) but also a validation in the form (typo, respect of company style if there is any, rephrasing some stuff,...).
    – Walfrat
    Commented Dec 11, 2020 at 13:14

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.
  • "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." Huh? I know plenty of seniors well under 35. Got a source for it?
    – Aida Paul
    Commented Nov 30, 2020 at 12:54
  • 4
    (I’m 37 and I’m in the youngest among the company) Commented Nov 30, 2020 at 12:56
  • 1
    @TymoteuszPaul exactly. In my company there are coworkers in their 50s (or more) that are in the simple developer role. And top managers in my department over 75 years old. In the legal consultancy division I think nobody is less than 50
    – ThomasJC
    Commented Nov 30, 2020 at 13:00
  • 1
    @TymoteuszPaul In my understanding, thieupepijn is speaking for my company only, is not generalizing this fact
    – ThomasJC
    Commented Nov 30, 2020 at 13:06
  • 2
    @ThomasJC exactly Commented Nov 30, 2020 at 13:10

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.

  • Good point years of experience != capability
    – ThomasJC
    Commented Nov 30, 2020 at 15:20

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.

  • 3
    Cost != value. An experienced developer's output far exceeds his cost Commented Nov 30, 2020 at 12:56
  • Steve Jobs' quote on the matter is the usual go-to quote on the matter.
    – Fattie
    Commented Nov 30, 2020 at 13:30
  • 4
    @Old_Lamplighter Doesn't that depend on what the experienced dev is doing? There are often grunt work tasks that don't go three times faster when you put someone on the task who's making three times as much.
    – Kathy
    Commented Nov 30, 2020 at 15:06
  • @Kathy I've made over 20 million dollars for my company in the last 5 years. Do you think they mind the times when I'm doing grunt work? Commented Nov 30, 2020 at 15:16
  • @Old_Lamplighter They would if you could be using that time to make another 5 mil for them. ;-)
    – Kathy
    Commented Nov 30, 2020 at 18:16

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.


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

I'll try to answer these specifically.


  • 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.


  • 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.

  • 2
    Cost is mitigated by value. Seriously. I fixed something done by a junior that was taking 10 hours to run. Now it takes 6 minutes. This is run multiple times daily. Another project I did brings in more than 3 million per year. Commented Nov 30, 2020 at 14:47
  • On the other hand, telling who actually is a senior is very hard. I have many college students who were significantly better programmers than some senior. programmers with 10 years of experience
    – Sulthan
    Commented Nov 30, 2020 at 18:57

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.

  • I think point 3 is certainly valid for all developers. Commented Nov 30, 2020 at 11:38
  • 1
    @JustanotherJavaprogrammer Not at all, many developers struggle with unemployment, though usually when you make it to the senior levels it is a lot less likely due to just how hungry the market is. And when you worry about employment, and that you may struggle to find new one, you are more likely to hang to a job longer.
    – Aida Paul
    Commented Nov 30, 2020 at 11:39

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.

  • 1
    I find the opposite is true. Experienced programmers tend to be more elegant, especially those of us who grew up in times where memory was discussed in terms of KILOBYTES Commented Nov 30, 2020 at 15:53
  • 1
    @Old_Lamplighter Those are the people who come up with weird optimization hacks of questionable benefit and horrible consequences for readability. Like using bitmasks instead of a bunch of boolean variables and substituting multiplication with bit-shifts. Clever, but often too clever.
    – Philipp
    Commented Nov 30, 2020 at 15:59
  • 1
    @Old_Lamplighter This is exactly the kind of comment I expected to this answer. "It's not pointless overengineering when I do it".
    – Philipp
    Commented Nov 30, 2020 at 16:09
  • 1
    @Old_Lamplighter I understand that you are very proud of this achievement. But the problem is that a lot of senior developers overdo it with clever tricks like that and use them even though they are not necessary. Because from their perspective they seem like perfectly normal code. But from the perspective of a junior developer they look obscure. Which leads to code which might be perfectly readable to the senior developer, but not to the junior who has to maintain it.
    – Philipp
    Commented Nov 30, 2020 at 16:19
  • 1
    Elegant code is readable, and maintainable, and that is something you learn with experience. A senior who is acting like you say was never good to begin with. Commented Nov 30, 2020 at 16:38

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).


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .