Hacker News Reader

Comment by forinti | Hacker News Reader

There's this myth that IT people can't communicate. Maybe it's because I'm in IT that I think it's quite the opposite: we communicate very well and precisely.

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.

View on HN

I’ve seen too much bad communication between software teams and nontechnical management firsthand to agree it’s a myth–I do think technical folks often communicate well and precisely amongst themselves, but often there’s just a fundamental lack of understanding as to what management cares about and needs to know about.

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.

it's not that uncommon to work at a company where the engineers have no idea that churn is up 25%, much less that customers are complaining about slowness.

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.

Nothing at a company is "non-user-facing", otherwise you wouldn't do it. If you're communicating the importance of some project or plan to people outside of your domain, it's important to keep the focus on how this actually benefits the company.

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.

What I was getting at was the idea of time spent on things that aren’t directly and immediately able to be, say, put into a sales demo, but instead impact the customer a but more tangentially, which is also when communicating clearly about business impact is particularly important. I would also argue that companies do tons of genuinely non customer facing stuff with varying levels of justification, for better or worse.

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.

My point is that just about any justification for any business activity ends up being customer-related at some level.

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.

I’ve never heard an example of kubernetes making a deployment faster.

Was that a made up example? If not, is there a successful case study somewhere you can cite?

It was a contrived example given k8s is a ripe source of jargon and engineering rabbitholes/boondoggles, though I guess I could envision a real situation where some bad choices about which workloads run on which nodes wind up impacting application performance, which then results in over-provisioning of resources as a bandaid fix.

Not GP, but one of my previous jobs used to have a deploy method of "ping one of the ops team on Slack to release a certain commit SHA to prod/staging/etc", which might easily take an hour or more if they were busy and/or you asked around lunchtime. Even if they were available immediately it would still take 20 minutes.

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...

"every dev can use kubectl to deploy" may be less horrific than the previous situation but it's still pretty bad practice tbh. So is "a script to automate all the kubectl invocations".

There's existing tooling for that : Skaffold, ArgoCD ...

Of course, but those were not yet available in 2017. Skaffold v0.1.0 was released in february 2018, v1.0 (first version number which we would've seriously considered) not until november 2019. ArgoCD v1.0 was released in may 2019.

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.

Why are techs the only one's with agency? Communication. Manage upwards. Dance, monkey, dance.

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.

> but often there’s just a fundamental lack of understanding as to what management cares about and needs to know about.

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?

They need to be spoon fed in the sense that you’re their eyes and ears. However they are human, so to win the war of attention, you have to communicate well and maybe be persuasive because there’s 10 other reports or peers doing the same thing. Their job is not to merely sign off but to triage too many problems to find at once.

If they don't have the attention for a problem, then maybe they should let me handle it? Once again, if they want a say in my problems and they don't give me the necessary information to frame that problem for their specific context, I can't help.

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.

I think you’re changing subjects. Isn’t the context of this thread the need for engineers to be able to communicate with their managers/leaders?

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.

> I think you’re changing subjects. Isn’t the context of this thread the need for engineers to be able to communicate with their managers/leaders?

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.

Exactly, use the politics to your advantage! Depending on who you're talking to, you have to have a different raison d'etre.

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.

People in upper management only speak in dollars. If you can't speak in dollars you literally can't speak their language.

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.

A response to that would be that translating different work scenarios into $ is management.

Assuming the story is accurate, it was not money that ultimately swayed them, but directly experiencing the problem.

That sounds like the job of management to do..

I'd agree that tech folks in an org can communicate very well and precisely -- among themselves. But there's a gaping chasm in communication between the technical and non-technical people.

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.

In my opinion IT people are often great at communicating clearly and with what in other parts of business would be called vision. They think ahead and see connections between processes and systems that non-technical management (even the process owners) miss. They can see the dot on the wall and deliver a program brining you there.

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.

Management is absolutely necessary. A good manager is worth their weight in gold.

But sometimes, management is: https://www.youtube.com/watch?v=r8miwsWtzRw

IT people are terrible communicators if they have to speak to someone outside their domain. I’ve seen plenty of miscommunications because people don’t try to grasp whether the other person gets what they’re saying. You can have network, storage, os, and developers talking and using the same words and not conveying anything useful to each other because the words mean something specific to each party, but not the same thing. I don’t know if they’re to deep in their own bubble or if it’s just arrogance and they do not want anyone knowing what they’re doing.

I find it’s more that people suck at listening, not communicating. IT people will happily explain if you ask and listen, but frankly most people dont like to feel dumb for asking questions.

When was the last time a manager asked you what you needed to do your job better?

This leads to the obvious conclusion that effective engineering in large organisations is about being able to talk to the political caste and identify who needs to be brought on-side.

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.

So somehow everyone believes that IT people don't communicate well, but the IT people know that they actually communicate well. Erm, okay. I feel like there could be another explanation, but it escapes me.

Unfortunately, playing politics is part of communicating.

Reply on news.ycombinator.com