Here’s something I don’t understand:
Software engineering is an art snd a science.
But so is sales. So is marketing.
Except sales can break its art down into numbers. It’s made itself *legible* to the business. Marketing is the same.
Software engineering is an art snd a science.
But so is sales. So is marketing.
Except sales can break its art down into numbers. It’s made itself *legible* to the business. Marketing is the same.
Reposted from
Marco Rogers
This is one of my favorite spicy topics. I am one of those people who says that engineers don't actually want to be held to any evaluation criteria. They definitely want *other* people to be held accountable. But not themselves. And if given a choice, they'll choose nobody being held accountable.
Comments
They can break those numbers down and show you where the money goes and how and why.
It’s right there. Tabulated and broken down in 74 different ways
Can a CTO tell you the top sources of productivity in the org, or the top sources of waste? Have they down headcount into revenue effectively. Do they have evidence behind any of their metrics?
Is this knowledge transferable to any other company?
Is that strategy intelligible to the rest of the industry? Using common layers of understanding?
No?
Same is true for software.
But only one of those three seems to believe a fantasy that “art” is incompatible with “being understood by the business”
He’s got a great knack for asking questions people *should* be asking, but don’t want to.
Thanks for the food for thought :)
But very much agree on need to solidify practice around getting the numbers we *do*.
You can get that message through!, it just takes thoughtfulness and repetition (and not hiring jerks to begin with)
All the criteria you see in the discourse around good engineers matter, but the most important thing is that for roles where you code a lot, the more code produced, the better the engineer
But, y'know, I'm biased (and can back it up with not-microsoft research)
Now the fact that monied interests seek to exploit this is another matter entirely
Given you mention ‘legibility’ have you read Seeing Like A State? I think the challenge here is not how to build better mechanistic models of work, but changing the management mindset
I've seen so many organizations run into the ground because they developed a data driven strategy that turned into "{palatable} quantitative metrics at all cost" strategy
Which, of course, gets you nowhere useful
I've never seen the like in product/eng.
Engineers need to be seeing that sales and marketing tracking and need to be making their observability legible to the business as well
That’s sweet, can you track error rates per customer bracket and prioritize fixing the issues of the largest clients first? No?
Hmm, that makes it real hard to justify working on long tail work when the larger clients have surface issues, doesn’t it?
I've never seen dashboards like that from an eng team.
But wow -- the fidelity of the data that our CRO got from the sales tools was amazing.
Most directors have no idea what any kind of technical specialist does, and none know all.
These sorts of leaderboards can be utterly toxic for technical specialists.
You can use mortality rate as a KPI, right? The best doctors save more people...
I need the neurosurgeons and acute oncologists on my team. I also need the knee specialists and cosmetic surgeons.
I don't want them to compete, it's counterproductive.
I'm not saying we're bad at stats; I'm saying we're very good at lying to ourselves with data.
Because if we're good at stats and good at software engineering, why does this happen???
It's "safer" to handwave.
I don't agree with this conclusion, but I do get it. It's fear based.
I’d imagine that would result in missed expectations to the point that the theater comes in, perhaps?
Metrics should be lagging indicators of behaviors, and it's the function of leadership to encourage and promote those behaviors without using metrics as the end goal.
( @grimalkina.bsky.social I’d be curious of your thoughts on this too 👀 )
Lots of interesting stuff here (more than I can do justice to in a post!!). I would venture this is essentially the same struggle we're having about representing human needs plus achievements in all realms
I have opinions.
"How much delight did we deliver?"
"What % increase did we have on time to ship over last quarter?"
"Do our customers AI the AI things???"
The bare bones metrics are not comparable.
I feel like when there's a push for metrics when it comes to product delivery, it's always metrics on productivity, as if engineering is an assembly line.
It’s easy to do, given how new and poorly understood software is, but it doesn’t go well :)
One key is sales and marketing have activity metrics that can be tied back to probabilistic revenue outcomes, which (afaik) software doesn’t have.
I think you could get closer with product in the mix.
So it depends on the business context.
Products are generally the harder case.
Internal IT development is similar.