The junior consultant debate - my two cents/penn'orth

Profile picture for user gonzodaddy By Den Howlett July 2, 2019
Summary:
Are we still seeing too many juniors on projects? It's a time-worn accusation that gets resurrected from time to time. Here's Den's 2019 take.

Eight years ago, good buddy and all around nice guy Vijay Vijayasankar penned a piece titled The curious case of Junior Consultants. Earlier today Vijay resurrected it with this Tweet:

...suggesting it's time to refresh. Here's my take on parts of his points an din the context of commodity software:

1. Every one needs to start somewhere. The senior consultants of today were all junior when they started. And considering the fact that rates where much higher in late nineties than today, it is not fair now for the current seniors to say the juniors are not worth it. 

Rates were higher at a time when projects were novel in many ways and where customization was the name of the game. Ten to 15 years on, there really is no excuse for making the same argument about most back office (and arguably much front office) software. These are commodities and should be priced accordingly. As I have said on numerous occasions: debits are on the left and credits are on the right. It's been that way for 700 years and ain't changing in my lifetime. The same goes for admin processes across the departmental board. 

To the question of 'starting somewhere' - true but then in any profession, there is always a period of learning required before you become productive. Why should the client pay for that? Who benefits? It sure ain't the client. 

2. Know the type of contract before you make a big deal out of this. In a Time and Materials contract, the customer carries the risk. Customer needs people with the right experience, and there is no excuse for a consulting company to send some one with less experience without disclosing it upfront. However, not all contracts are time and materials based. Several are fixed price based. In Fixed price – typically, the consulting company takes the most risk. They are held to an outcome, and it should not matter if that company does the job with 2 senior consultants or 1 senior consultant and 2 junior consultants.  What I have seen is that irrespective of type of contract – the expectation is always that consultants have to abide by the Time and Materials mode. Again – there is no excuse for trying to do a project with only junior consultants without experienced folks to oversee their work.

This one really annoys me because it fundamentally misunderstands the problem. The power relationship in any professional engagement is always skewed in favor of the expert/consultant. They undertake projects day in and day out while the client might see one or two in their staff careers. It is all too often the case that competitive tenders are low balled and for the consulting organization that wins to immediately look for change orders at wildly inflated prices. But then I'd put the responsibility on accepting those deals with the client.

In the alternative, the consulting organization runs its dog and pony shows claiming that the senior team on show is what the client will get, only to ship those guys and gals out to the next dog and pony while staffing up with juniors who are early stage trainees. I exaggerate a bit but it's not unknown. 

Again, and because we are largely talking commodity, there is no reason why a consulting organization cannot offer fixed price/fixed term because the risks of which Vijay alludes are illusory. As to expectation - well, this is an eight-year-old story - much has changed but for my part, I never enter into time and materials deals because I have no clue what my costs will be. Does that mean I forego change orders? Absolutely not. But each gets priced. The upside for the smart consultant is they make more money this way and I'm perfectly fine with that. 

Now - there's always a problem with this in the sense that when we're talking fixed price for specific deliverables, the deliverable is often the start of a much longer journey where the desired outcome needs to be iterated. This is awkward because what the client thought they wanted often turns out to be different from what they really need and in my experience, it's only after the specified deliverable is in play that the wrinkles emerge. Even so, it's not a reason to revert back to time and materials as the default method of reward. 

More generally, I have never really understood the time and materials argument in the same way that I never understood the fiction of standard costing. My reasoning is simple - there are only so many hours in a day and therefore at any given price, there is a fixed amount of revenue that can be earned. Why, as a consultant would I limit my earning ability in this way? Is that what happens in the real world? No. 

3. Not every task in a project needs the most experienced consultant. If I were to ever work in the role of a client – I will never ask for a senior consultant to type up documentation, do routine configuration or development, or do routine testing. 

No argument here but again, these vital and oft-missed steps are, in my view, part of the training discipline. Yes, I'll pay something for it but not the element that adds value to the consultant's learning. 

4. Finally- junior consultants bring fresh perspectives to projects. They usually know things no one else in the team knows, and I know first hand the opportunity cost of not using their ideas in projects just because they are junior.  Junior consultants are not dumb – they are incredibly smart, if only their managers and seniors in the team take the time to nurture them and give them a fair chance to express their opinions. I have been guilty of this in past myself, and I have suffered this from my prior teams when I was the junior guy. So this is very close to my heart now.

I'm struggling with this one because the definition of 'junior' in this scenario is unclear to me. I have no issue with fresh ideas but I would assume there is enough prior knowledge from which to bring those fresh perspectives. 

5. Actually, there is one more reason juniors should be preferred in some long term projects. You need continuity in domain and industry knowledge to be retained in the team, although the type of expert level technical skills might change in future phases of project. It is much more practical ( less cost, less chance to leave because of boredom and so on) to let a junior grow into this role than keep a senior tied to it long term.

I'm not sure about the point being made here as it relates to project staffing/costs. In a long run project, I'd expect consultants to accumulate knowledge that increases in value for both sides of the relationship, but equally, I'd expect the consulting organization to factor that into their project team planning. 

There is one caveat to all of this. There are occasions where the client needs something that is entirely novel. In those situations, the client should really be asking itself whether it is better to develop in-house. There are good reasons for doing so and hiring in accordingly. Otherwise, the client ends up paying for IP it may not end up owning. This is as much a contractual issue as it is anything else and is the one occasion where I'd insist on getting the best and likely most expensive brains on the job. Why? If the cost/benefit analysis has been done correctly then there will be a clear ROI. 

And with that, I'll leave it to my consulting colleagues to punt the ball back.