I dont like the idea of ruthless efficiency by tracking metrics similar to a sales funnel. It gives me the mental image of everyone competing and inflating numbers or gaming the system.
The big difference is the lack of accountability. AFAIK if a developer misses shipping during a sprint, they’ll just add it to the next sprint. If a salesperson does this, after 2 quarters of missing your quota, you’re fired. Doesn’t matter if you had monster quarters before that, if you’re not hitting your numbers, GTFO.
I think this is because sales have very clear metrics that everyone can agree upon: revenue, number of demos, cold outreach, etc. We’ve been tracking these types of metrics in cuneiform. Comp sci wasn’t a thing until the 1960s. It’s still too new and everyone has an opinion on what metrics to focus on without angering a developer for micromanaging them. This is where the friction lies; until that’s fixed, you will not have a cohesive team. I hope that AI takes over and we don’t need devs or salespeople anymore.
context: I’m a sales guy that sold software that tracks “engineering performance” to VPs of Eng and CTOs depending on the size of your company. It was shocking to see the level of variance in measuring performance metrics for eng teams.
As it is such a meat grinder I can only hope it gets replaced with AI as I’ve seen many in sales not feeling well.
Trying to imprint sales principles on engineering or any other knowledge profession is what leads to horrible organizations filled with unhealthy practices and people.
Can we identify a good meeting and "turn up the good"? Much harder, and requires actual leadership.
The push for Lean (by way of Agile) has been more pronounced within IT/tech than any other non-manufacturing industry that I know. We’ve been collecting metrics for as long as I can remember, and reported them.
What is interesting here is that studies out there on knowledge work indicate that most of it is wasteful.
What you need to have for a team to perform is clarity, relevant competency and freedom to do the work - all of which are managements real job to put in place. This can be hard to grasp coming from sales; the value of flow, the detrimental effect deadlines and hard estimates have on team performance.
The individual team need to identify what they can do to become better and they should measure this. But not in any way should we put this relative to other teams metrics.
For example: one team might frequently end up in wait state due to a stakeholder or customer, when touching specific parts of the code/system. This usually leads to the team picking up new work while waiting, increasing WIP and context switching.
Another team have to deal with a lot of legacy code within their domain, that doesn’t build or test well. This have to be prioritized if this is important software or else this team will be a hog for eternity.
Measuring these things is important, and most definitely possible - you just have to understand the profession.
They need to be treated differently as your driver probably differs by miles from what drives my team of system developers. For someone in sales, maybe with compensation in the form of commission you have clear metrics every month. I can have guys sit around and think for a couple of months with the benefit of us staying agile and malleable two years from now. This is where the disciplines differ by a lot and must be treated and measured differently.
What?
For an Opportunity, it's usually pretty clear and very very easy to measure, how much the company gains from that and when.
How do you measure the gains from a PR? If you can't than literally everything else is completely meaningless. Don't forget that PRs can also be net negative to the company.
One of the big problems in most sales organisations I've seen is that they think that the base revenue is all that matters.
Did I get it right that you think this is the right approach for dealing with your salespeople, that it improves long-term productivity of the organisation?
There are two major issues with "missing shipping"
1. More often than not the feature or the dev that holds thing back. It's the unknown, or didn't think of side effects. Like walking the coast of California in 2 weeks. If you don't hit a river or bit of beach that's been eroded away, or a cliff, you're good.
2. As you said metric take a while to figure out. Lets say we give Comp Sci a 10th of the time to figure out metrics as we've had at sales. So.. we should be all set in say 500 years :)
First question should be: what does your data say about how much it cost to have an agile / data driven process compared to not having one? :)
Unless, of course, the measure was good to begin with - such as cash or bars of gold. The problem with most measurable measures in software is they are gameable proxy-non-grata.
The whole thing depends on being able to compute the net present value of a patch on a given code base. Then pay the developer/team some percentage of this. What a beautiful reality that would be for developers and businesses alike. To bad there is no conceivable way to do it. I'd guess computing this is 1E12X harder than protein folding.
IMHO this is a bad measure, its how you end up poluting oand poisoning etc. fro profit no?
It highlights missing rules/regulations
Unfortunately, this often leads to corporate shortsightedness (e.g. "This will destroy our customer goodwill and eliminate our competitiveness in the coming decade, but it will make our quarterly revenue targets and our jobs depend on that, so we're doing it.")
Any metric you set for comparing contributions, no matter how good you think it is, WILL produce a cobra effect.
This is because metrics are a model, which by definition can't capture the entirety of reality, and so any attempt to enforce based on that model is doomed to failure.
How much would you value a maintenance task? Or a process change? A better air conditioning system? Game night to let off steam and improve morale? How do you calculate what its long term worth is from the productivity change in order to assign a present value to that contributor? How can you even know what kind of an effect it will have long term? You'd need a pretty damn sophisticated model, and even then it would still only be a model, missing many points of the reality hurtling towards you at the speed of light.
And meanwhile, the little things that improve long term prospects simply aren't done, because the metric doesn't value them. Thus, metrics, even NPV, cash, bars of gold, are bad policy enforcement vehicles.
I completely agree with you that it is probably impossible to compute (per my original comment). But at least understanding what the target is helps imo.
It was really frustrating because more time was spent about how work should be coded than the work itself.
Quality didn't end up mattering because there was no accountability for actually delivering good software because following iconiq's standards was considered good enough.
It was weird because management would routinely be surprised that our metrics were good but reality was not. As a grunt, it was frustrating because there was no room for productivity improvements because those were to only come from the top.
It's probably quite helpful if you do it yourself. But yeah - definitely something that has historically been easy to game.