I struggled for the right title for this blog post. Primadonnas is not quite the right word, but maybe it is.
What I am talking about is how do you manage groups of sales people, software engineers, or research engineers who are working in a difficult to define environment. This may not be your company, but it is many companies.
What I am addressing is a pool of persons who have a similar talent or assignment, who have differing levels of experience which gives way to different outcomes.
You will recognize this if you make and sell a product; or, if you run a SaaS company which continues to develop its core product while developing a new product; or, if you are a equipment company that has an R & D or product development effort.
Who are these people, Big Red Car?
These folks might look like this:
1. If they are sales persons, you might have a bunch of them (“bunch” means 24) with differing levels of sales training, experience, and success.
You may be “scaling” and in the middle of a growth spurt, so the issue is going to grow with the scale.
You may have teams amongst the sales force. You will have newbies and gray hairs. You may not.
2. If they are software engineers they may be involved in maintaining an existing product, developing a new product, customer feedback modifications to the core product, or customization of the product for specific customers.
Again, you may have internal teams, differing levels of experience, and differing ages.
3. If they are R & D types, you may be making hard goods and adding features to an existing product line, developing new products, addressing field issues, and doing basic research prior to new product development.
The common themes are obvious — smart, technical people who may not have a repetitive work program who are working on specific “projects.”
What are the common pitfalls, Big Red Car?
Some of the common issues are as follows:
1. Weak or no accountability for output. It is very hard to measure productivity on a customer requested feature you have never done before. None of this is easy. Sorry.
2. No budget control. Say you are doing some basic existing product development. How do you allocate resources in such an environment? How do you determine project ROI? Do you employ hurdle rate analysis? Can you?
In the real world, many times you cannot do analysis until you have done some work.
3. Pet projects — this is the common theme amongst bodies of software engineers. Each engineer has some pet project he/she wants to do and they spend an inordinate amount of time on it to the detriment of their actual duties.
This is particularly troublesome when the project is one that a slice of the team likes or a supervisor — who is supposed to be the protection against such a thing — is the big kid in the sandbox.
4. Reporting — this ties in with accountability and budget control. Assume you are doing everything perfect: appointed a supervisor, good accountability, clear budget constraints (might be man hours allocated), and you just don’t keep the C suite informed.
How do we fix things, Big Red Car?
I am reminded of the patient who went to the doctor:
“Doc, I have a terrible headache. Whenever I do ‘this’ my head hurts.”
The Doctor studies the man carefully, walks around him, thoughtfully places his index finger against his lips, and says, “Perhaps, you should stop doing ‘this’?”
The solution to every problem that is self-inflicted is to stop doing ‘this.’
Here are some tips that may work:
1. Approach the entire segment as a business onto itself that must have clear objectives which means keeping a list of what the group is working on. In a sales environment, this would be market segmentation targets — enterprise v B2C, as an example.
In an R & D setting this might be a list of projects.
In a SaaS company, it might be core Version 2.1 versus an entirely new product that will subsume and absorb the former version.
Let me say as an aside that the happenstance that a SaaS company is going to launch a new version and completely abandon the prior revenue generating version is becoming far more common than you might think. This creates the unique problem that the folks working on Version 2.1 may become totally obsolete when the new and improved version is launched.
2. Prioritize things into A, B, C tranches. Stop, take a deep breath — get rid of the C’s. This takes courage.
3. Put someone in charge of each project. Empower this supervisor to run the project, have the team report to him/her, and give them the authority to make decisions.
4. Make a spreadsheet allocating man hours to each project. This is a budgeting process. Manhours = $$$.
5. Keep score on the spreadsheet comparing % complete v % of allocated resources consumed. In this manner, expectations are tempered by performance.
Redo this spreadsheet every three months, but be careful to track the original plan and do not abandon info that shows you are off track. This deviation will be useful for future planning.
6. Report monthly and make a critical assessment every month — is this project still the same project we thought it was when we launched it and does it still make sense?
You will have a substantial percentage of projects — 20-25% — that as you get into them your insights are informed and you say, “Good to learn, but this project no longer makes sense.”
Cut those babies loose. This, too, takes courage, but if you follow the process, it becomes easy.
7. Make this a critical element in the appraisal of performance. If you have someone whose projects seem to wander, they may be a candidate for upping the gene pool by getting rid of them.
I find these slightly out of control amorphous groups to be the primordial sludge that often hides underperformance.
8. Instead of pretending that pet projects do not really exist and letting them bleed you dry — put them on the list, allocate resources (4 hours on Thursday afternoons) and keep track of the dilution they really cost.
If you do this, I believe you will be appalled at how much time is lost on pet projects.
Bottom line it, Big Red Car
OK, the takeaway is this — if you don’t manage these type efforts with some upfront planning, assigned supervision, resource allocation, score keeping, fold the results into performance appraisal, then you will have a significant segment of your company that is simply beyond your direct control and unpredictable.
OTOH, if you do, there will be no panacea. If you have a receding hairline, this will not change that, but you will have data on resource allocation, cost, and progress with which to run the business. This will improve control, inform the leadership, and absorb some tension.
That’s it. Primadonnas.
But, hey, what the Hell do I really know anyway? I’m just a Big Red Car. Great weekend, y’all.
