Hacker News Reader

> If you're engaging in C-suite politics as described in this article, what on earth would be the motivation for writing all this in public? I doubt the situation will evolve favourably to Mr Shore if the leadership team starts reading this.

I didn't get that impression at all from this blog post. I didn't see any "C-suite politics" really at all in this article:

1. At the end of the day, the C-suite is responsible for making the business successful. So it's reasonable to ask for some level of productivity measure, no matter how much engineering objects.

2. I thought the author was extremely insightful about (a) trying to get at the root of what execs really wanted, (b) acknowledging that calculating engineering productivity is notoriously difficult, but then (c) coming up with a best, honest estimate, while still highlighting the potential future pitfalls and the dangers of Goodhart's Law.

In short, I read this article as exactly the kind of engineering leadership a good C-suite would want to keep around and promote.

> exactly the kind of engineering leadership a good C-suite would want to keep around and promote

... or, failing that, a different good C-suite might want to hire away from a less good C-suite.

If I was a CEO with a VP who wrote something this realistic and honest, my response would be to pressure the rest of my execs to give me that same level of quality information. Breath of fresh air!

One of my long standing beefs with C-suites and their MBAs and whatever meat factory grinds them out is the continued lack of comprehension of basic software and IT management.

Back in the early 2000s, this could be saliently characterized by the exuberance many CEOs of companies bragged about how IT-ignorant they were. I saw the "my secretary prints out my emails" written proudly in print many a time in the CEO worship magazines like Fortune and the like.

Every decade of continued IT penetration and performance benefits in business are continuing the principle: the health of your business is strongly tied to its IT health.

BUT MY COMPANIES JUST STAMPS WIDGETS. Ok, look. MBAs long ago accepted that every business, regardless of what it does, needs two things: accounting and finance. So every MBA gets a decent education on those.

Well, hate to tell you, MBAs need to know the fundamentals of IT.

Basically, C-suites not understanding productivity measures in IT are hard is stupid not only because it is a basic aspect of IT management, but its a bit more disturbing than that:

YOU CAN'T MEASURE MANAGER PRODUCTIVITY EITHER. How does traditional MBA measure middle managers and those types of orgs? That is rife with all the problems of measuring developers, not the least of it being the "juke the stats" universal phenomenon. That's why the most important single indicator of manager ability is: headcount. Headcount headcount headcount. The second is size of budget: bigger bigger bigger.

Of course everyone that has working in companies knows the hilarity of what that produces: bloated orgs, pointless spending to use up a budget otherwise it gets cut, building empires, etc.

The essence of developer that C-suites need to understand is that they are not factory workers: they are in fact MANAGERs. They just don't manage people, they manage virtual employees/subordinates (software). Go ahead, ask any software dev in an org what they do. Generally, somewhere in there is a bunch of acronyms and the fact that they ... wait for it ... MANAGE those acronyms. Krazam's microservices is a perfect example of this. What is that long diatribe essentially about? MANAGING all those services.

That gets to another major undercurrent of IT. Managers want to place IT employees in the "worker bee" category. They don't want IT workers to be managers, and entitled to the great benefits according the management class. The long running IT salary advantage in the US, and the constant ebb and flow between management and IT "working" to push that down is a major social undercurrent here.

I like to compare it to illiteracy.

Yeah, that's quite common? 'computer literate' etc.? It's even quite dated as a term because it's so uncontroversial and accepted.

Right but I think that use to refer to using applications. Developing them is much more like real illiteracy. You can look at a bug tracker but the todo list might as well be in Chinese.

> YOU CAN'T MEASURE MANAGER PRODUCTIVITY EITHER.

This is so much the case that on a Freakonomics episode I caught on NPR the other day about economists attempting to prove whether the Peter Principle is true (TL;DR probably yes, and likely more so than you’d even guess—but also this is all very hard so maybe don’t take it too seriously) it seemed that this is something so difficult that they barely even try to do it and when they do the measurements are so narrowly-focused and come with so many caveats that one hesitates to call them useful.

Like best case you manage to find that you can measure one of several plausible performance indicators and if you’ve picked the exact right kind of job where worker productivity can kinda-meaningfully be measured (it often cannot) then maybe you can conclude some things with a large enough dataset, but then connecting that to any particular behavior on the part of the managers is another big hurdle to overcome before you can try to, say, develop effective scientifically-sound training, and at that point you’ve likely wandered into “just give up, this is too messy” territory.

[edit] and this:

> That gets to another major undercurrent of IT. Managers want to place IT employees in the "worker bee" category. They don't want IT workers to be managers, and entitled to the great benefits according the management class. The long running IT salary advantage in the US, and the constant ebb and flow between management and IT "working" to push that down is a major social undercurrent here.

Nail. Head.

Managers of developers act piss-pants afraid of us properly joining the (socially speaking) upper-middle (cf Fussell) or professional class, which the MBA set are busy trying to eliminate everywhere else (lawyers, doctors, college professors) so they’re the last ones standing.

This shit is why micromanagement PM frameworks and packing us into loud visually-messy sardine can open offices is so popular. Dropping that stuff would be table-stakes for our moving up the social status ladder. Adopting it pushes us way down the pecking order.

> Well, hate to tell you

Why?

They'll definitely hate to hear it. I agree, why am I empathizing with the sociopath class?

Wondering where the real problem lives I cant help but get back to the disconnect between education and employment. Isn't it that most curriculi have a bunch of borderline nonsense and a bunch of things you end up applying every day?

Companies pay taxes, those go towards education even if it is indirect by organizing life sufficiently to make training possible. What formula can be had by which companies may rate chunks of education or nudge it towards more useful knowledge? Do they even know what they need?

Oddly schools measure productivity all the time. It seems a hilarious puzzle.

For a MBA level, I'd say the education probably needs to involve:

- visualizing the types and size of data collected and maintained by IT systems. Data size will generally scale with the amount and complexity of systems, I think there can be good high-level measurements for MBA types about data sizes and complexity. Of course they won't measure producivity in systems dev, but from a systems maintenance perspective it could help.

- a lot of apocryphal stories about systems development and implementation

- and of course, as I alluded to, a model of the employees and their responsibilities and necessary competency in IT, and how the business relies on them. How a competent IT org isn't just maintenance on the bottom line, how Amazon leveraged good Silicon Valley talent to be a lethal marketplace weapon, and probably lots of stories of big box stores relying on good IT orgs to scale their logistics and operations beyond what was thought possible in the 80s and 90s.

That's from two minutes of me thinking about it. What modern MBA student doesn't want to know how Amazon does things? They run both a high-margin software/hardware operation and a low-margin retail operation with "good" IT (I mean, don't get me started on the workplace practices, but they scaled with good IT talent, ditto for Google).

Good IT + Good Finance should power any decent business plan to success. Really, in the modern age of cartels, the only way to disrupt the big players in a traditional market will likely be through well-applied IT that has superior scaling, cost, integration, and adaptation to the old guard players.

It feels like 'management' here means something like 'take responsibility and ownership'. And that is the thing that demands the rewards. Is it also the difference between a 'worker bee' and a 'manager'? The former is 'do the thing', the latter is 'figure out what thing to do.' But many software people are actually both, of course... so it seems these are not useful dichotomous categories...

This is where the agile grift falls apart, all those proj. management types don't really have a role in tech teams.

Turns out all those car manufacturing truisms don't fit so good when the wheels are weird binary blobs that nobody understands.

Blog posts, like long showers, are often for arguments you've already lost.

I was also cynical at first but it ended up as a triumph over C-suite politics.

This person took a nonsense buzzword "productivity" and turned it into actual measurable numbers which make sure the company is moving forward, and linked those numbers to enjoyable developer activities.

This seems like a good outcome to me. The C-suite actively don't want the developers spending time fixing bugs and doing drudge work. Developers are incentivised to avoid bugs with good code and testing. They can knock back bad implementations because those will lead to more bugs which the C-suite have said they don't want.

Seems like a win to me?