4 ms·

I'm a SWE turned product manager, and now one of the cartoon movie villains in the boardroom as mentioned in the article. To me this article sums up the most f

by z3ugma 1y ago

I'm a SWE turned product manager, and now one of the cartoon movie villains in the boardroom as mentioned in the article. To me this article sums up the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work. "Most non-technical leaders have never really engaged with the real work of software and systems management. They don’t know what it’s like to update a major dependency, complete a refactor, or learn a new language." _Every_ function in a tech business has hidden complexity. Most parts of the business have to deal with human, interpersonal complexity (like sales and customer support) far more than do engineers. By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic. As a result, lots of engineers never learn how to present to the business the risk of the kinds of complexity they deal with. They would prefer to ignore the human realities of working on a team with other people and grumble that the salesperson turned CEO just doesn't get them, man.

RankingMember 1y ago
[flagged]
- deleted 1y ago
  [deleted]
DavidPiper 1y ago
While I agree with some of your points, this comment is actually doing the thing you're criticising, just in the other direction. You're claiming that your work is complex and unknowable to outsiders (SWEs in this case). As a SWE-turned-product-manager, you're in an ideal place to teach SWEs about: - how to present to the business the risk of the kinds of complexity they deal with - the human realities of working on a team with other people - why the salesperson turned CEO just doesn't get them, man _Every_ function in a tech business has hidden complexity.
- disgruntledphd2 1y ago
  Every function in human society has hidden complexity. Like, reality is very very detailed. Everytime I learn something new I discover oceans of complexity and nuance. That's just the way the world is. Now, software is hard because the complexity isn't as visible to most of the org, but also because software people tend to be less than good at explaining that complexity to the rest of the org.
  - Raidion 1y ago
    I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Tech debt is real, but so is the downside of building a system that has constraints that do not actually align with the realities of the business: optimizing for too much scale, too much performance, or too much modularity. Those things are needed, but only sometimes. Walking that line well (which takes some luck!) is what separates good engineering leadership from great engineering leadership.
    - disgruntledphd2 1y ago
      > I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Hey, I resemble that remark! Yeah, I get where you're coming from but i do really feel that it's more of a communication issue, along with the abstract nature of software. I mostly do data related stuff, and have often had the experience of finding "wrong" data that doesn't have a large impact, and every time I need to remind myself that it might not matter. You can also see this in the over-valuation of dashboards vs data engineering. Stakeholders lurve dashboards but value the engineering of pipelines much less highly, even though you can't have dashboards without data.
    - hjeepn 1y ago
      To be fair, this bias for "correctness" is both logical and necessary, and not something that stems from inability or unwillingness to understand business goals. That tech debt you took on to meet the latest oh-so-important deadline? Prepare to live with it forever, because the next hare-brained initiative is right around the corner. Frankly, the business's goals are not my goals, and unless I own the place, I'm not sacrificing good work for it.
FpUser 1y ago
>"By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic." This statement is on big pile of BS. From a practical standpoint there is nothing deterministic about software systems and their interactions in enterprise.
- consp 1y ago
  There are so many hidden variables in these kind of systems that I agree with your statement. You cannot account for the unknown unknowns. One of the hidden variables being the same machine which is supposed to bring order to chaos: product managers and their interaction with sales teams and upper management.
McScrooge 1y ago
I think a major part of the frustration is more the _assumptions_ around the work complexity. Like decision-makers more easily make invalid assumptions regarding the complexity of the software portion. A good PM will listen to the SWEs when forming these assumptions and good SWEs must be able to communicate about them. This could be bias talking, though. Is it common for sales or support teams to be given milestones that are off by 50%?
helpfulContrib 1y ago
> .. the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work. .. >_Every_ function in a tech business has hidden complexity. In my opinion, the conflict is in the distinction. Stereotypes abound, but I have always found in this battle between worlds, there is a simple bridging maneuver: never work for someone, or accept management guidance, from someone who cannot also comfortably do your work. corollary: never manage someone unless you're prepared to do their job for them comfortably. Yes, this is cold and hard, but so are those stereotypes, kids. There are Manager Engineers and there are Engineer Managers. But there's also just managers and engineers with both skills, simply focusing their work as needed for the specific project. The ultimately fun organization to work in is where different people have different roles in multiple projects, comfortably. Key word. Getting this mix comfortable is the job of a good CEO, fwiw. And guess what, it doesn't matter whether the salesperson can do any job but understand just how great this particular hierarchys' products are, and why the end result of this configuration is worth the spend.
ebiester 1y ago
This is a rather human failing - complexity is fractal: you only notice it when you get close enough to it. However, I disagree that engineers only have to deal with the complexity of the computer; instead, I argue they have to translate the messiness of the organization and of every customer of the program and make it coherent to an inflexible computer. And every exception and case added is a permutation that echoes through the system. (And, quite often, outside the system due to shadow processes that people use unintended consequences of the system to encode.) That said, it's why I have so many of my senior engineers start learning the terms of business so that they can deliver those messages without me. It's part of my toolkit I expect them to learn.
alganet 1y ago
> engineering only has to deal with the complexity of the computer which is at least deterministic Engineers outside business structures can scramble themselves and produce value. It's messy and inefficient, but doable. Sometimes, it's a lot of value. This requires human communication. Engineer-to-engineer brawls. It's nothing like the well oiled JIRA machine. It's a mess, but it is undeniably human. I think that deserves a little more respect. The article talks about JIRA metrics. Teams the measure productivity, time spent, code produced, deadlines. Ins't that a poor attempt at making human team work _deterministic_? Don't get me wrong, I don't think that's completely useless, but it certainly can be detrimental to both engineering and business. I'm not saying you do those things or preach that pure metric-based system. However, you are making a comment on an article about it, and I think that in the middle of your rant, you reversed the roles a little bit.
tootie 1y ago
I'd also argue most engineers don't think very hard about what's actually valuable to a company. A smooth build pipeline and ample test coverage are only worth whatever fraction of risk reduction of the product they are delivering. I have told teams to not do basic maintenance on software because nobody is going to care if it crashes because it has too few users. In the same vein I've asked them to fixate on making a tiny feature absolutely perfect because we know it's the thing 90% of users focus on.
- aleph_minus_one 1y ago
  > I'd also argue most engineers don't think very hard about what's actually valuable to a company. My experience differs: many software developers think deeply about what is valuable to the company, but don't play the ferocious political games that managers do play (the only winning move is not to play). Relatedly and because of their logic thinking, they thus often come to the conclusion that these scumbags of managers are clearly not what is valuable to the company.
deleted 1y ago
[deleted]
dgb23 1y ago
I don't think the article claims that there isn't any hidden complexity in other functions, but that ignoring the hidden complexity of engineering/programming cause all sorts of issues and pain. The language is quite aggressive though.
foxyv 1y ago
This reminds me of a story my dad always told. One time the organs of body had an argument. The brain said "I am the most important. I allow the body to think and avoid danger. If I die the whole body will die with me." The heart screamed "I am the most important! If I stop even for a few minutes the entire body will die." So the argument continued. The kidneys, the liver, the skin, and the spine joined in. No one could agree who was the most important. Then the butthole closed up!

by z3ugma 1y ago

RankingMember 1y ago

[flagged]

deleted 1y ago
[deleted]

DavidPiper 1y ago

While I agree with some of your points, this comment is actually doing the thing you're criticising, just in the other direction. You're claiming that your work is complex and unknowable to outsiders (SWEs in this case). As a SWE-turned-product-manager, you're in an ideal place to teach SWEs about: - how to present to the business the risk of the kinds of complexity they deal with - the human realities of working on a team with other people - why the salesperson turned CEO just doesn't get them, man _Every_ function in a tech business has hidden complexity.

disgruntledphd2 1y ago
Every function in human society has hidden complexity. Like, reality is very very detailed. Everytime I learn something new I discover oceans of complexity and nuance. That's just the way the world is. Now, software is hard because the complexity isn't as visible to most of the org, but also because software people tend to be less than good at explaining that complexity to the rest of the org.
- Raidion 1y ago
  I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Tech debt is real, but so is the downside of building a system that has constraints that do not actually align with the realities of the business: optimizing for too much scale, too much performance, or too much modularity. Those things are needed, but only sometimes. Walking that line well (which takes some luck!) is what separates good engineering leadership from great engineering leadership.
  - disgruntledphd2 1y ago
    > I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Hey, I resemble that remark! Yeah, I get where you're coming from but i do really feel that it's more of a communication issue, along with the abstract nature of software. I mostly do data related stuff, and have often had the experience of finding "wrong" data that doesn't have a large impact, and every time I need to remind myself that it might not matter. You can also see this in the over-valuation of dashboards vs data engineering. Stakeholders lurve dashboards but value the engineering of pipelines much less highly, even though you can't have dashboards without data.
  - hjeepn 1y ago
    To be fair, this bias for "correctness" is both logical and necessary, and not something that stems from inability or unwillingness to understand business goals. That tech debt you took on to meet the latest oh-so-important deadline? Prepare to live with it forever, because the next hare-brained initiative is right around the corner. Frankly, the business's goals are not my goals, and unless I own the place, I'm not sacrificing good work for it.

FpUser 1y ago

>"By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic." This statement is on big pile of BS. From a practical standpoint there is nothing deterministic about software systems and their interactions in enterprise.

consp 1y ago
There are so many hidden variables in these kind of systems that I agree with your statement. You cannot account for the unknown unknowns. One of the hidden variables being the same machine which is supposed to bring order to chaos: product managers and their interaction with sales teams and upper management.

McScrooge 1y ago

I think a major part of the frustration is more the _assumptions_ around the work complexity. Like decision-makers more easily make invalid assumptions regarding the complexity of the software portion. A good PM will listen to the SWEs when forming these assumptions and good SWEs must be able to communicate about them. This could be bias talking, though. Is it common for sales or support teams to be given milestones that are off by 50%?

helpfulContrib 1y ago

> .. the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work. .. >_Every_ function in a tech business has hidden complexity. In my opinion, the conflict is in the distinction. Stereotypes abound, but I have always found in this battle between worlds, there is a simple bridging maneuver: never work for someone, or accept management guidance, from someone who cannot also comfortably do your work. corollary: never manage someone unless you're prepared to do their job for them comfortably. Yes, this is cold and hard, but so are those stereotypes, kids. There are Manager Engineers and there are Engineer Managers. But there's also just managers and engineers with both skills, simply focusing their work as needed for the specific project. The ultimately fun organization to work in is where different people have different roles in multiple projects, comfortably. Key word. Getting this mix comfortable is the job of a good CEO, fwiw. And guess what, it doesn't matter whether the salesperson can do any job but understand just how great this particular hierarchys' products are, and why the end result of this configuration is worth the spend.

ebiester 1y ago

This is a rather human failing - complexity is fractal: you only notice it when you get close enough to it. However, I disagree that engineers only have to deal with the complexity of the computer; instead, I argue they have to translate the messiness of the organization and of every customer of the program and make it coherent to an inflexible computer. And every exception and case added is a permutation that echoes through the system. (And, quite often, outside the system due to shadow processes that people use unintended consequences of the system to encode.) That said, it's why I have so many of my senior engineers start learning the terms of business so that they can deliver those messages without me. It's part of my toolkit I expect them to learn.

alganet 1y ago

> engineering only has to deal with the complexity of the computer which is at least deterministic Engineers outside business structures can scramble themselves and produce value. It's messy and inefficient, but doable. Sometimes, it's a lot of value. This requires human communication. Engineer-to-engineer brawls. It's nothing like the well oiled JIRA machine. It's a mess, but it is undeniably human. I think that deserves a little more respect. The article talks about JIRA metrics. Teams the measure productivity, time spent, code produced, deadlines. Ins't that a poor attempt at making human team work _deterministic_? Don't get me wrong, I don't think that's completely useless, but it certainly can be detrimental to both engineering and business. I'm not saying you do those things or preach that pure metric-based system. However, you are making a comment on an article about it, and I think that in the middle of your rant, you reversed the roles a little bit.

tootie 1y ago

I'd also argue most engineers don't think very hard about what's actually valuable to a company. A smooth build pipeline and ample test coverage are only worth whatever fraction of risk reduction of the product they are delivering. I have told teams to not do basic maintenance on software because nobody is going to care if it crashes because it has too few users. In the same vein I've asked them to fixate on making a tiny feature absolutely perfect because we know it's the thing 90% of users focus on.

aleph_minus_one 1y ago
> I'd also argue most engineers don't think very hard about what's actually valuable to a company. My experience differs: many software developers think deeply about what is valuable to the company, but don't play the ferocious political games that managers do play (the only winning move is not to play). Relatedly and because of their logic thinking, they thus often come to the conclusion that these scumbags of managers are clearly not what is valuable to the company.

deleted 1y ago

[deleted]

dgb23 1y ago

I don't think the article claims that there isn't any hidden complexity in other functions, but that ignoring the hidden complexity of engineering/programming cause all sorts of issues and pain. The language is quite aggressive though.

foxyv 1y ago

This reminds me of a story my dad always told. One time the organs of body had an argument. The brain said "I am the most important. I allow the body to think and avoid danger. If I die the whole body will die with me." The heart screamed "I am the most important! If I stop even for a few minutes the entire body will die." So the argument continued. The kidneys, the liver, the skin, and the spine joined in. No one could agree who was the most important. Then the butthole closed up!