Comment by hansmayer
12 days ago
I get your point at the basic level, but as engineers and managers, we need to stop this nonsense. Think deeper about why do you need to "sell" your work inside (some) companies ? Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. What's the value such busywork managers are adding, besides the anti-value of layers of explanatory communication and wasted time? The busywork folks should be working to understand where their salaries are coming from, not the engineers. Note that I am not saying all managers are useless (its also a part of my job), it's the people-and-ideas-managers who are useless in the technical setting. The point about technical debt should be a non-issue, why the hell would you have to explain that the technical debt is a bad thing? Did we not clear this issue many times over and establish zero technical debt as an engineering ideal a long time ago? Well it is because some person with 1/4 of your experience and competence somehow got lucky and talked themselves into one or two hierarchical positions above you. We need to start a pushback across the industry and stop allowing former accountants and humanist science graduates into "leadership" roles in IT.
Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work.
Every company I've ever worked at has more work that they would like to do than they have engineers to do it. The problem often isn't that they don't understand why fixing technical debt is important, it's to decide if fixing that particular technical debt right now is the best use of these resources right now. Also they might also know things that I might not know, like long term plans for and the relative profitability of different projects, which will affect how they make decisions. No point in spending effort fixing technical debt if that project/department is already slated for closure.
Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
Sometimes they're looking for the next big product that will make millions but IMO they never really stack the odds of that working against the chance of losing current business through not updating, improving their current offering to make it e.g. more sticky.
Hence you work on "huge priorities" and then they turn out to attract 2-3 tiny customers....Meanwhile you have horrendous problems with things that do sell that make them inconvenient for your customers such that they will be delighted to go elsewhere the moment they find out that your competition does it better.
> Every company I've ever worked at has more work that they would like to do than they have engineers to do it
I've worked at a couple of BigTechs, where there were between 5-20x more engineers than actual work. The trade-offs are... strange in that world.
> Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
I haven't found that to be common in the US. I've had a number of front-line managers who were (somewhat) recent engineer conversions, rarely had anyone above that level who was.
> I've worked at a couple of BigTechs, where there were between 5-20x more engineers than actual work. The trade-offs are... strange in that world.
Never seen that in my life, and I've worked at small, medium, and huge companies. Sounds wild. So they actually have zero bugs in their bug tracker, and no feature on deck waiting to be built? What do they do all day?
Typical case I've seen at many companies is: Team has N engineers, with a rough capacity to fix N x 2 bugs per week. Bugs come in at a rate of N x 3, and the bug backlog is N x 80 and constantly growing until the team does periodic "bankruptcy" ritual where they mass-close N x 50 bugs that they admit they'll never get to fixing. Repeat forever.
1 reply →
There’s a difference between management knowing that it’s worth paying off tech debt in general, and management knowing that now is the right time to pay off this piece of tech debt in particular.
Why pay off tech debt A and not tech debt B? Is this really more urgent than implementing feature C?
I have some financial debts, but I prioritise paying off some over others, and even allow myself to buy myself nice things instead of paying off the mortgage early. The same principle applies with tech debt, except I have to justify my choices to my bosses instead of to my girlfriend.
Fortunately I don't work in such an organization, and I have extremely competent in my chain of command.
The reason I explain the value of what I am doing (to both technical and non-technical managers) is because it helps them understand the bigger picture.
Or perhaps it helps them understand that I see the big picture, so that they know (and I know) our goals are aligned.
I am aware that not everyone is as fortunate as I am. I'd equally suggest that not many managers are fortunate enough to have engineers that can articulate what they are doing in terms they can understand.
There are plenty of managers out there who are not team players. And probably more engineers who are equally unable to see the bigger picture. Which is unfortunate because when you learn to work together towards a common goal, it really improves everything.
Please don´t take it as trolling - but if your higher ups are as competent as you say: why do you need to help them with the big picture ? Shouldn´t they be the ones setting it or at least directing? I am saying this because topics like improvement of performance and reduction technical debt were established as drivers of revenue a long time ago. That is why Amazon optimised the sh*t out of their checkout process and Google (before they were took over by the business types) obsessed about page loading times. Oh coincidentally - that was also the time when major tech companies were run mainly by engineers. Is that why their products used to be so much better? Too many "busyworkers" are now wasting everyone's time by having engineers explain "the big picture" so that they can present it at some meeting and take credit for. And in the process, the products get more entshittified every damn day.
> Think deeper about why do you need to "sell" your work inside (some) companies
Mainly to prove you can sell, not that they can buy. Selling involves understanding the customer's needs, their tradeoff preferences, your value prop and being able to reflect that back to them. The minimum bar for successful selling requires you to demonstrate a certain degree of competence and due diligence that provides assurance that you're able to operate autonomously with trust.
No, actually. He said it was a part of his job because they did not understand his work? So we are back at square one here, why do people not understanding engineering work, end up managing engineering work?
>> So we are back at square one here, why do people not understanding engineering work, end up managing engineering work?
Because engineers are typically (although not always) terrible at business. Or marketing. Or Sales. Or whatever.
In other words, a successful business needs many skills. One of those skills is management. It's inevitable that top management (who's core skill is hopefully, well, business) needs to people to do the other skills. Marketing, Sales, Engineering, and so on.
Hence those skilled people need to communicate with management in ways in which management can understand. They can then make sure everyone has aligned goals. It's no good if engineers are doing one thing, marketing is doing something else, sales is targeting the wrong demographic, and so on.
It seems to be a unique conceit of software engineers that "management just gets in the way". When, more realistically, management is trying to communicate the business requirements, and we feel we know better.
Most engineers (again, not all) are terrible at the actual business part. The list of failed companies, multi-year solo projects that never sell a single copy, and so on are evidence of this. Joel made his name writing (literally) "The business of software".
So back to your question;
>> why do people not understanding engineering work, end up managing engineering work?
because how else will engineers know what to do?
> It's up to me to "sell" that benefit to upper management. There's no point in assuming they'll figure it out by accident. Part of my job is enumerating the value I add.
Nowhere is that said.
The benefit of them selling is not for the management to understand, it's for the worker to understand and be able to articulate as it will flow downstream to strategy.
Maybe the management doesn't understand but my point is it's irrelevant. I've been in management situations where I've understood perfectly well and ones where I have zero clue, my requirements for you selling to me remain exactly the same which is I'm using it as a gauge of how much you understand.
2 replies →
That's an excellent summary!
Man, you are making too much sense, somebody is going to have his feelings hurt by your words. Management is now trying to have even more control on the people that actually do things, and AI is being used as scapegoat to entrench their position. The reason is fear, because most managers couldn't do even 1/10 of the work people under them can do.
"zero technical debt" is a pipe dream. Not all tech debt is equal; think "low-interest student loan or mortgage" vs "high-interest credit cards or payday loans".
Well, that is why I said it was an ideal, something to strive for. Since we are in lecture-mode here, ever heard of objectives and key results? Think that would be a more fitting alternative to your black-and-white metaphor of low-interest vs. payday loan ...
It's not an ideal. There is an optimal level of technical debt to maximize shareholder value. Eliminating all technical debt makes no more sense than eliminating all financial debt. Used effectively, debt is a powerful lever. The trick lies in finding the optimal level based on incomplete information, and many corporate managers aren't very good at this.
3 replies →