Hacker News Reader

Thank you for articulating something sane.

The article is pure "Management/Leadership Speak" nonsense complete with contrived/farfetched analogies and blaming of Engineering/Engineers for actually delivering something but which may have been "Strategically Wrong" because somebody else made that decision. Engineers are told to "Execute" and not "Strategize" (which means everything and nothing).

Given the responsibility, most Engineers are fully capable of Strategizing/Prioritizing/Executing on an Idea/Customer requirements so this insidious idea that Engineers are incapable of "Higher Managerial Functions" needs to die.

It might be the article struggling to find the perfect frame, but what also stands out is the reason a lot of excellent executors get locked out of strategy decisions is that they don't want to be involved. It isn't a source of regrets.

People don't generally sign up for an engineering role because they want to provide strategic direction to others. Such people exist, but are rare. There is a clear bias in Engineering disciplines towards people who really enjoy executing and don't particularly care what they execute.

And seconding the manager-speak angle. This article will be nearly useless to someone who doesn't already know how to identify and balance conflicting needs to make a decision. This is a rehash of the usual advice - take a step back, breath deeply and ask if what you are doing is leading to outcomes you value.

Your points are valid and i agree with you.

The problem with the article is that it tars the "Engineering Discipline" and practicing Engineers with the brush of implicit incompetence as if they are incapable of "looking at the big picture" and burying their Head in the sand. Nothing could be further from the Truth. The Complexity of the Problem/Solution demands that each of us focus only on our area of Specialized Expertise thus allowing the "Whole System" to be built from "Components". Analyze/Design Top-Down but Build Bottom-Up. Our "Modern World" is dependent on Technology all built by Scientists and Engineers.

PS: Take a look at the works of Jacques Ellul for a fascinating study of the relationship between Technology and Modern Society.

> Engineers are told to "Execute" and not "Strategize"

Complete these questionably specified tickets and when you are done, come back for more tickets.

If this is what your job is encouraging then just wow. The engineers that I've seen be most productive are the ones pushing the design approaches and identifying gaps in the approach and tasks etc.

No, the authors of the article seem to be writing from personal experience and have used an interesting analogy to describe the solution in somewhat geometric terms (a “watershed”). If there were some mathematical way to describe the wiring of the neurons of someone making good decisions maybe they would have used that instead. Absent such a concept they resorted to metaphor instead. Such is the burden of philosophers.

More generally I would cast the skill of decision making—while being creative—as this: it’s the ability to navigate a many dimensional design space.

Normal engineering has been reduced to a series of unidimensional logical decisions. This is my constraint…these are my material properties (or whatever) and I shall optimize for cost. Easy peasy. A computer could do it. This is the realm of building codes and strict industry standards.

But to be creative, you need to navigate a large search space of ideas. Every decision you take opens up new pathways and poses new challenges to solve. What is the best path through such a space? Copy someone else’s design and call yourself an innovator? Stick to first principles? Develop your intuition and then use it to guide your choices? Iterate often and fast? Being creative involves a completely different mindset for working a decision making…and I think it’s different because navigating a large dimensional idea space requires more than mere logic. This is what distinguishes creative people from mere mortals. And decision making in such a space has to be different too.

That was why the article was so interesting. One day there might be a mathematical way to define this problem and solution properly. Until then, like philosophers of old, they will have to resort to metaphor to explain what they have grasped with their minds. Some people will get it and some will not. But it’s not nonsense business-speak.

>No, the authors of the article seem to be writing from personal experience and have used an interesting analogy to describe the solution in somewhat geometric terms (a “watershed”). If there were some mathematical way to describe the wiring of the neurons of someone making good decisions maybe they would have used that instead. Absent such a concept they resorted to metaphor instead. Such is the burden of philosophers.

The "Watershed Metaphor" doesn't make any sense at all. You can contrive anything and call it "Creativity"/"Philosophizing" etc. but that doesn't make it correct.

>the skill of decision making—while being creative—as this: it’s the ability to navigate a many dimensional design space

This is just a platitude and can mean anything and everything.

>Normal engineering has been reduced to a series of unidimensional logical decisions. This is my constraint…these are my material properties (or whatever) and I shall optimize for cost. Easy peasy. A computer could do it. This is the realm of building codes and strict industry standards.

WHAT ??? Nobody who knows the "Scientific Method" and has trained as an "Engineer" will ever agree with you. You are taking "one facet" of a specific Engineering Discipline and generalizing it to the whole Domain of "Engineering". This is a fundamental logical fallacy.

>But to be creative, you need to navigate a large search space of ideas. Every decision you take opens up new pathways and poses new challenges to solve. What is the best path through such a space? Copy someone else’s design and call yourself an innovator? Stick to first principles? Develop your intuition and then use it to guide your choices? Iterate often and fast? Being creative involves a completely different mindset for working a decision making…and I think it’s different because navigating a large dimensional idea space requires more than mere logic. This is what distinguishes creative people from mere mortals. And decision making in such a space has to be different too.

This is mere verbiage. See Baron's Thinking and Deciding for a detailed study of the relevant subjects.

>That was why the article was so interesting. One day there might be a mathematical way to define this problem and solution properly. Until then, like philosophers of old, they will have to resort to metaphor to explain what they have grasped with their minds. Some people will get it and some will not. But it’s not nonsense business-speak

You setup your own points and traced a path through it; means Nothing.

Please be more constructive in your criticism.

As an example

> WHAT ??? Nobody who knows the "Scientific Method" and has trained as an "Engineer" will ever agree with you. You are taking "one facet" of a specific Engineering Discipline and generalizing it to the whole Domain of "Engineering". This is a fundamental logical fallacy.

How is it a fundamental logical fallacy? Why are we making broad statements for the whole industry?

Please do not quote my comments out of context.

My above-quoted comment was in response to;

>> Normal engineering has been reduced to a series of unidimensional logical decisions. This is my constraint…these are my material properties (or whatever) and I shall optimize for cost. Easy peasy. A computer could do it. This is the realm of building codes and strict industry standards.

The fact that this is ludicrous should be self-evident to any "Scientifically Minded" person.

Trying to explain the "Why" would have to start at the Basics and would be too long. Instead i will list the relevant resources for further study;

- https://en.wikipedia.org/wiki/Fallacy_of_composition from https://en.wikipedia.org/wiki/List_of_fallacies

- https://en.wikipedia.org/wiki/Engineering#Methodology from https://en.wikipedia.org/wiki/Engineering

- https://en.wikipedia.org/wiki/Scientific_method#Elements_of_... from https://en.wikipedia.org/wiki/Scientific_method#Models_of_sc...

BTw I think Rudyard Kipling wrote a poem in which he bemoaned the fact that engineers were different from the people who made decisions.

He called them the Sons of Martha and the sons of Mary.

https://www.kiplingsociety.co.uk/poem/poems_martha.htm

However, most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like, or perhaps unless someone gives the engineers time to think about it.

>However, most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like

Absolutely Wrong!

Just look at the user-friendliness of FOSS where there are no managers, versus commercial software.

(I still prefer FOSS, but user-friendliness is not where it shines.)

Maybe the audience of FOSS is "self" and therefore I will obviously write something that matches my need.

Can you provide one example ?

because gnome is FOSS and I have heard complaint it's 'too simple'

and https://birchtree.me/blog/screwing-up-the-simplicity-of-it-a... : "Most people get maybe 2% of the potential of their Macs and Windows PCs today. Have you watched most people use a computer laterly? Most people I see have all apps in full screen all the time, no matter how big their screen is. Most people I see use keyboard shortcuts for copy and paste, opening new tabs, but basically nothing else. I've seen numer ous Mac users download apps, open the DMG, and run the app from the DMG forever because they don't know you should move it to the Applications folder. Many people have a desktop full of files because the desktop is the file system."

(and SAP and any Oracle Enterprise products...)

see this sub-discussion on UX of b2b products: https://news.ycombinator.com/item?id=29731828

There are also no deeply invested customers for most FOSS development. It's not really surprising that most FOSS design feels aimless when the developers only need to meet (or aren't funded beyond) their own needs -- the bar is way lower. I don't think the mere existence of "managers" or "designers" is the critical factor.

Also, your original statement didn't say anything about FOSS:

> [...] most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like, [...]

The software engineers I've worked with want to make user-friendly software that meets needs. You know what usually gets in their way? They're not able to work with the end users to understand what the destination should be. They're fed streams (tides!) of loose feature requests with no apparent cohesion. What kind of software do you expect to get out of this process?

Garbage in, garbage out.

I think most software engineers are (in a way) glad that they don't have to talk to customers, and that there is someone in the middle. Managers and such are tolerated by developers for this reason.

The biggest problem with this stance is that far too often those middle-managers or other customer interfaces understand neither the customer's actual needs nor the programmer's needs.

Every successful project I've been part of has required me to meet directly with the customer and understand what isn't working. Asking someone else to ask the customer for a specification just leads to the wrong solutions being solved or an endless stream of feature requests that make no sense in isolation.

No, it's not. Nearly all Open Source software has terrible UX/UI with really questionable decisions regarding almost everything besides the technical aspects.

I actually liked the "Downward Strategy Spiral" diagram, which I think is the one you are referring to. It's one of the few things I liked about the article.

I've seen a lot of engineers and SREs (especially SREs!) get stuck in the execution mindset: get the job done, no matter what it takes.

Ultimately this leads to a situation where, instead of questioning why tools and platforms and processes suck, people apply shortcuts and workarounds without thinking about how they fit into the big picture. These workarounds accrete, eventually causing serious problems.

One example: a CD system has a very rigid definition of what an "environment" is, and it's not possible to run more than one version of a given software package simultaneously in an "environment" in order to do performance tests or canarying or things like that.

The "execution mindset" approach to that situation is to create new "environments" in order to just get the code deployed and close your ticket. Pretty soon the org ends up with dozens of these, some of which are only used by a single team, e.g. "prod" and "teamA-prod-sandbox" and "teamB-prod-perf-test." The "strategy mindset" approach is to say, hey, wait a minute, this "environment" design is not working well, people are hacking around it by creating new "environments," so let's fix that design so people don't need to do that anymore.

Is that them not thinking of it or just realizing that anything that requires greater time investment will be a fight?

As much as many of us (myself included) are socially clueless, we do notice when people are annoyed with us and that is often when there is a problem (something SREs would need to deal with a lot if prod goes down).

I have binned a lot of improvement proposals simply to keep management happy and not having the desire to fight for the required time/resources. Half the time I might share it with a fellow rank and file dev for interest sake, but it dies there.

People like fire fighters. The fire inspector is broadly considered annoying.

> People like fire fighters. The fire inspector is broadly considered annoying.

I don't think it's a binary. I've also shelved a lot of proposals that I believed in, not because I didn't want to fight for them, but because a smart strategist picks and chooses their battles. Fight fires by all means, but use some of the capital you accumulate that way to point out and resolve the causes of future fires.

> People like fire fighters. The fire inspector is broadly considered annoying.

Good engineering orgs don't think that way. However it's also true that you need to build credibility and trust, and have some communication skills and an understanding of the larger picture, in order to act as a successful fire inspector.

Improvement work always has to be balanced against feature development, but if you can show that developer productivity and the reliability of the product are being impacted, good managers will tend to listen. (Conversely, if those things aren't impacted, then why is your suggestion important?) If they don't care, it's time to move on. Seriously: there has never been a better job market in software and if you aren't happy you should be looking for other jobs.

Yeah, the ultimate fix to that are prototype (or sandbox, or whatever you want to call them) environments.

Every branch has its own full stack of services and dependencies dedicated to it; and it all gets torn down the moment the branch disappears.

The strategy mindset is impossible in large corporations because you don't have the power to change those things, and even if you did, it would become a project involving everyone and taking years.

There is a reason why people go for the workaround mindset and that is because they are just tiny cogs in a machine.

I think you are missing the point of the article, as an ex-engineer shifting to business and strategy, one key mental model change comes from focusing on the "hows" to the "whats and whys" - mentioned at the start of the article.

Even if you master data analysis skills (ie. as an analyst), which is completely different than what engineers are trained to do, this is only the "hard skills", which are the least important when it comes to management. Don't underestimate "soft skills" seen in many non-technical PMs. Keep yourself humble, keep learning - if you conquer both hard and soft skills, you are better guaranteed to succeed - evidenced by many ex-engineer CEOs in tech.

Advice: https://www.youtube.com/watch?v=xlmzMbbKHgQ

Strategic thinking isn’t just the generative idea creation of a “strategy”. It’s also about savvy execution within a strategic context.

In every project a thousand decisions are made by “drooling labor” and the better each of those decisions ladders up to the strategy the more meaningful the impact of the work.

Watching people proclaim no impact on strategy but thinking they deserve tons of credit for their code is a failure mode I’ve seen with engineers. Watching people get frustrated not being promoted when “idiot peers” get credit was often more about their own idiocy.

Don’t dismiss the impact you have in every role, it’ll hurt your career and the actual impact you have.

Oh, absolutely. On both counts: strategic decisions that have been delegated to you are important to get right, and relentless self-promotion is the single most important skill inside and outside of any workplace. It's also important to recognize it for what it is, though, and TFA, well, is what it is.

> the key to getting anything done is to delegate the decisions to a single person per team, give them time to cultivate big picture knowledge and political connections, and then to respect those decisions even if you privately disagree.

I don't agree with this in general. I've been forced into too many projects that were obviously bad from my perspective, but the Fearless Leader didn't care about anyone's input. I wasn't held accountable when those projects failed, but it was still depressing to have to do them.

I get the impression that corporate drones hate having to debate a decision, and they structure their organizations to absolutely minimize the need for it. But personally I enjoy a spirited debate -- one focused on the merits, and with rational, civil people.

I wish there was more deliberation in the workplace and less "do stupid things as fast as possible in the hopes that one of them will not be stupid". But there aren't enough people like me to sustain an organization, and that's why most orgs are top-down command-and-control hierarchies.

i liked the water shedding idea because it is new to me. But otherwise, the blog makes me ask the question, so if engineers get trained early to focus on executing solutions who is training? Are you just blaming them on the degrees? But don't we know lots of graduates are not job-ready? The point here being there are systemic problems here. Just like there is with so many other issues and that's getting ignored.

you clearly were not swayed by the watershed metaphor