Comment by macNchz | Hacker News Reader

Comment by macNchz | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

Reply on news.ycombinator.com