The real issue is that middle management has a ton of politics that muddle up everything. I can say to my team that I messed something up and that we have to fix it; but I've seen people higher up who will bend over backwards just to not have to roll back a decision (and sometimes not even a very important decision).
So maybe someone had already sold to the boss that the equipment was good for another 10 years.
The answer to “why are we planning to spend so much time on this non customer-facing project” isn’t to just dive in and start talking about Kubernetes node pools and pod affinity rules, it’s to talk about how we’ll be able to cut cloud spend by 20% right off the bat while improving site speed, which is important because churn is up 25% YoY and a majority of recently churned clients have complained to support about slowness before cancelling.
So frequently I’ve seen former, then the engineers go off in a huff that management won’t support their project, and management goes off wondering why engineering is screwing around while customers are churning.
companies get so fixated on having their engineers do "engineering work" that they don't communicate what's actually going on at the business level.
Shouldn't management communicate? Shouldn't management manage?
In all my career, I can think of maybe a handful of non-techs whose communication was measurably better than grunts, that could manage better than chimps throwing darts.
I will concede that most tech's, such as myself, fail miserably on other social niceties crucial for royal politics (and the money chase). Such as deception, stealing valour, skulduggery, sucking up, ambiquitiy, enthusiasm, and fashion.
At some point, you've got to think about whose role it is to manage who.
If your management needs to be spoon-fed the decisions they must sign off, and reacts poorly to signal that is not perfectly worded or inadequate because the relevant information was not transmited down, what use are they?
Information needs to flow both ways, and in so many situation, the reason information pushed up is not relevant is that context wasn't pushed down.
Them lacking context or not is a separate problem. But you should be able to make a case for your proposal without that much context. What are values, risks, known, unknowns, costs, etc.
The original claim was that engineers tend to have poor upwards communication skills, fueled by low understanding of management goals. My claim is that that situation is to be expected when so much information doesn't flow down.
> But you should be able to make a case for your proposal without that much context. What are values, risks, known, unknowns, costs, etc.
...And that case will often be deemed irrelevant to the company's goals, or incompatible with the company's challenges (lack of funding, staffing, etc).
Then you also pointed out that many managers can't spare the attention for some decisions they are asked to do. Maybe this kind of decision shouldn't have been pushed up in the first place? Stories of engineers ranting about having to climb 2 ranks to approve a $100 expense are pretty common, for instance.
Was that a made up example? If not, is there a successful case study somewhere you can cite?
After we moved to k8s, the release model went to "every dev can use kubectl to deploy" and it took a minute or ten to release something to prod. Needless to say, we all loved it much more than the previous setup. Even more so after someone whipped up a script to automate all the kubectl invocations.
One of my former colleagues wrote an article about it here: https://wetransfer.com/engineering/migrating-frontend-to-kub...
There's existing tooling for that : Skaffold, ArgoCD ...
When we were first releasing this Helm charts were considered pretty unproven and AWS didn't have a managed k8s offering yet. It was very early days.
However that's not the problem described in TFA. It was clear what the user-facing implications of not upgrading the line were, and management didn't care. Sometimes people aren't rational.
Regardless, who knows whether this was the case in the story being discussed, but it’s not unthinkable that this genre of communication breakdown was involved to some extent.
Example:
Why do we want to spend money on Jetbrains licenses for developers? Because we want them to be happy, comfortable, and productive. And why do we want them to be happy, comfortable, and productive? Because they build stuff that customers want.
o Talking to HR: "We need to do X to reduce/increase headcount needs".
o Talking to legal: "We need to do X to comply with Y regulation or decrease our exposure"
o Talking to other teams: "We need to do X because our current system can't scale to take your load".
o Talking to other teams that don't want to work with you: "We need to do X because your system can't scale and we're going to drop our dependency on you".
o Talking to the business: "We need to do X to save $$$ this year"
But if you simply say "We need to do X because of [highly technical reason]" then no one outside of your team is going to care or help you.
They shouldn't have asked management for money, they should have presented management with two alternatives: pay $x now to upgrade network infrastructure, or pay $y later in rush fees, IT overtime, and customer loss due to degraded UX. Then you let them make the decision.
It's absolutely possible the business was in a temporary cash crunch or needed the money to get a more important revenue-generating initiative past the finish line, and eating the higher costs later might make more sense to the business.
It comes from a difference in motivation, in what the different "tribes" believe to be important. Bridging this gap is more about translation and seeing the others' perspective than anything else. This is the reason project managers exist, and why their existence is mostly miserable.
We need to acknowledge that every layer of this cake thinks they're the most important, but in a de-facto dictatorship fuelled by customer spending, the lines of power are closely aligned with the flow of money.
Tech decisions are approximately irrelevant to the people closer to the money stream, and they're primarily evaluated in terms of potential profits and actual costs. In other words, tech only becomes important when it facilitates more profits or incurs unexpected expenses.
However, and that’s the big gripe, each and every one IT proposal I see costs money. It not just costs money, everything costs money, but it raises the long term average cost per unit. Even when we are dismantling ancient and totally non functional systems, the TCO of the modern solution is higher than the previous. Look I’m here on HN, can program a bit, understand quite large parts of the tech stack. But not why even highly capable IT-staff and management whom I have confidence in can’t seem to explain their contribution to the basic underpinning of business: average cost should go down over time and with scale.
(Advice about how to talk about this with IT people is more than welcome! A lot of organizational distrust and poison sadly follows from this.)
One of the more current examples is that IT-staff forgets that they are 2-3x more expensive per FTE than general workers. So when I see a plan and calculate how much middle management should save in reduced workload thanks to plan X both sides don’t like the outcome. The end of the day picture that companies exist by grace of customers willing to pay for your product (and cost loading!) is lost at that moment.
But sometimes, management is: https://www.youtube.com/watch?v=r8miwsWtzRw
When was the last time a manager asked you what you needed to do your job better?
If someone told the boss the equipment is good for 10 years, maybe you can work with them to come up with new requirements the old equipment can’t meet, and let them present those requirements to the boss, so they have a reason to support instead of opposing you.
The alternative to this sort of political shenanigans is to be ineffective, or to work in a small enough company that you don’t need to.
What happens more often than not is that the C-suites and their underling managers just don't give a shit. They've got their "grand plan" that works in their minds, and no amount of annoying devs that tell them that their fantasies can in fact, not, be made into reality can sway them otherwise. Doesn't matter how well you explain it, they want it done, so it'll get done, regardless of any other problems.
Hell, they perfectly understand what we're talking about most of the time, it's not like we're hitting them with obscure jargon known only to the highest caste of the nerds, it's really just that they don't care. I do get where they're coming from as well, as we can be extremely annoying oftentimes (at least, I know I can be extremely annoying), but the feeling is often mutual when I'm given a ticket I've argued vehemently against, more often than not with good reasoning.
I just wish more companies weren't being run by brainless, heartless MBA types and there was more of us engineers in charge, but c'est la vie.
also from the perspective of the aforementioned suits, they can hire IT guys easily, who cares if one of them gets very uppity and quits if we blame them for everything/anything.
Corporate IT grew from office clerks. Obviously you don't need strategic planing to see that fax machines and PC's work, so corporate IT started as being nobody important.
“The current growth trajectory means we’ll be out of capacity in a month, and it takes 3 weeks to install more capacity, so you’ve got a week to find the budget. If we don’t do this, customers will experience a slower service which may lead to complaints and reputational damage.”
It’s also possible that the execs understood perfectly and were happy to accept the risk of the service being slower for a short period of time. Maybe the Internet-using customer base was tiny, or the service in question wasn’t critical, or the execs were handling general financial pressures leading them to want to sweat every asset until it was impossible to ignore, or maybe they just understood that “the internet being slow” was normal for the 90s and it would be unlikely to hit their reputation in the long term.
The suits are cheap or dumb or it’s their fault they can’t speak tech. But often there’s just a lack of communication skills.
Business execs want everything broken down in "how much will this make me" and "how much will this cost me". The problem IT faces is that sort of impact isn't easy (or is impossible) to articulate. We can easily speak to how much the fix will cost, but not to how much it will save or bring in.
This is why orgs are terrible at security. How much will fixing the log4j issue save? Who knows, maybe nothing, maybe the entire business.
The budgetary control management system that companies like this use isn't primarily designed to limit spending to the minimum necessary. Its primary purpose is to prevent any political power being built away from the management office, by constraining access to the critical resource.
I mean this literally and historically. Budgets being used for management control dates from when the CEO of General Motors couldn't control the sprawling divisions they'd bought, so he (well, his CFO) brought in budgetary controls invented by McKinsey (the man, not the company) so they couldn't move without his say-so. And of course because it worked for GM, it must be good for everyone.
Maybe it is hard to communicate with people who lack a fundamental understanding of the critical tools they use.
If you don't understand how to write software it's like not understanding how to run a newsroom for a newspaper - you simply won't make the right decision often enough no matter how clever you are
It may seem like a ridiculous idea for a floral delivery service. But if you know your people enough to trust them or not trust them, you don't have to be an expert in everything to make the right decisions.
Which brings us a full circle to the nerds hating the suits because they want to quantify the unquantifiable.
OR, you could just go with what the experts say and be tagged a pushover.
If we think of management as "coach / therapist" (ie the eight rules of google management" then yeah, the goal of management is to take a team of high performers and help them not to implode. But I don't see that as "management"
I think there are better definitions
And posts like this where you act so smug and callous do nothing to change this.
That doesn't sound like a failure to communicate.