In the last ten years (and even in the 20-people HN startups), the day to day work of engineers has become so incredibly specialised and divorced from the needs of decision-makers and the customers that there is almost nothing I can do to influence whether someone views me as doing my job or not. Mainly because of the presence of Product Managers that insert themselves between engineers and the rest of the company.
I'm always interested in delivering value, but the fight necessary to actually do so has become stressful. It's no longer a collaboration, all my contributions must be filtered through the ego of the person speaking to decision-makers.
In fact, the only time I was actually satisfied with my work in the last 5 years (as opposed to my paycheck) was when I was acting as interim Product Manager for 9 months. Unsurprisingly, me and my team managed to deliver three projects that other teams tried and failed several times.
Most of that was accomplished by communicating with stakeholders and actually figuring out what they needed, rather than endlessly "trying to put my own spin" on it.
So yeah, I'm gonna keep delivering whatever is asked, getting the blame for bugs and not getting the credit for features. At least the pay is alright. I'm constantly searching for the place where I can actually fully contribute, though.
I don't know why but this part of your comment really stuck out to me. I have a whole different take on getting stuff done specifically at big tech companies, mainly that being "stagnant" is not such a bad thing at a place like Google or MS.
Say you're like an L-whatever at one of these big tech companies and you bring home say $300k/yr. You don't live in a HCOL so the pay is astronomical compared to anywhere else and even if you work on the same boring project for 10 years there, you can still say you spent 10 years working at MS or Google and that would get you red carpet treatment just about anywhere. I'm sure this would bug a go-getter and would certainty bug a younger version of me, but if you're that kind of person you're most likely trying to work at a smaller company where you get more say and sway.
And to add a bit more to this it's not like I don't care, it's just what I care about has changed over the years. When I was younger I was concerned with climbing the ladder and getting prompted. Now that I'm older I care way more about my family and friends than I do my company. If I was at one of these big tech companies and someone told me I was stagnant and would never get prompted I would just tell them so what. I bring home $300k for my family and I have a good work life balance (most likely). And do I really give a damn about the initiatives of some corporate behemoth, no and to be totally blunt the only thing I like about them is the paycheck and what it does for the rest of my life (all the free shit at the office is just a bonus).
I would never do this, and if you would do this I wouldn't want to work with you. Maybe I'm a sucker, but I sleep alright.
GP was achieving what their bosses asked of them. It's just that it didn't align with their own professional goals of improving the product they work on.
I still use it as a job board, personally.
You'll get hired, if you pass the technical interviews, but if you cannot contribute at the level they hired you, you'll be exited and that will be suspicious for your next application.
But this is the case for anyone anywhere, it doesn't effect the OPs position one way or another.
Sounds like an unlikely problem and by then you can pull a reverse end run around your manager to their manager who doesn't know what they are doing and will believe anything the guy who worked at google says.
Most people here actually work for that guy.
Oh, I didn't know we were fantasizing about 2022.
> you can still say you spent 10 years working at MS or Google and that would get you red carpet treatment just about anywhere.
well, not in 2025. Market is rough and it's all topsy tuvrvy out there, with lots of companies pretending to hire but not.
>If I was at one of these big tech companies and someone told me I was stagnant and would never get prompted I would just tell them so what. I bring home $300k for my family and I have a good work life balance
Even tech isn't immune to "move up or move out". Google's had plenty of layoffs these past few years and that's an easy way for the gravy train to end. Hope you got plenty of savings.
In previous companies, as an engineering manager, I had to burn a huge amount of political capital to steer my team in the right direction, several times.
My people (engineers) want to achieve their goals and create value, and the higher-ups want working software making money. I don't see why this has become so hard to achieve.
To give an example of when I had to burn political capital:
I had to "skip rank" a few times and go directly to CEOs. They are appreciative when you provide concrete facts, such as "I worked for two weeks on the redesign of this page that zero people use and I'm frankly tired of this bullshit".
But you're 100% right. You have to know when to use the nuclear button. And sometimes you can't press it, which means you take a backseat and watch the company burn money for no reason. This is the point where I start agreeing with _fat_santa's post [1].
DARVO, leverage, etc. etc.
In my startup experience, it seems to me the best PMs are the CTO and the early engineers who has near infinite business and user context.
Not OP, but I can answer:
They're ok with ideas coming from someone else, check the ego at the door and listen to both engineers and customers. They make engineers work less and produce more value. Most important, they don't have a "vision", they help organize the team so the team has a shared vision built by the team.
EDIT: Also: They're not competing with the engineering manager or lead developer for some sort of leadership. They're talking with customers instead of asking sales to do it. They're working on the product aspect of tasks instead of offloading them to engineers.
Example: good PM will build a mock up of a UI, go over it in detail with engineers, then let them break up their own work. They are focused on the actual product. Bad PM will write 10 Jira tickets without any real context, assign them without discussion, then add 20 different tracking fields that nobody will use.
My definition of a good PM is someone who can champion both customers/users and developers concurrently, while sticking to the company's value prop and competitive edge.
In some cases, it's boiling down the needs of the customer into something achievable before sales gets in the way with over-promising and under-delivering. In other cases, it's telling the executives to stop wasting engineering's time with excessive meetings and scope-creep. It could be simply going and getting the engineers coffee. It could also be telling engineering to stop over-engineering the MVP and to simply get what needs to be done, done.
In simple terms, someone who can go to bat for any facet of the company at any time externally or internally, in order to make sure right product is being built in a timely manner that aligns with both business needs and most importantly, customer needs.
* Do the developers know what the customers want?
* Do the customers have realistic expectations?
If yes to both, then the PM in between is doing a good job. Bonus points if higher management is aware of that.
That's basically the role of the PM: to have all the business and user context and to use that to harmonise vision between the various "stakeholders" (parts of the business, users/clients, etc). But one doesn't have to be the CTO or an early engineer to have this context/skillset.
It's exactly the same for designers.
Good ones can shave days off complex tasks, and even help the code be more beautiful.
Bad ones can turn a 5-min feature into a week's worth of work. For absolutely no gain, and possibly creating a few bugs along the way.
Unfortunately the only way designers and PMs can learn this is by working together with engineers. Everyone needs to check the ego at the door. Which is borderline impossible with some personalities (from all sides).
My company, being more than a little bit toxic, he got transferred to a new manager who took an instant dislike to him and he was pulled off all his projects and then fired for not delivering anything. (bit of an exaggeration, he got put onto one of those "all responsibility, no authority" type projects where he was responsible for making sure everyone at the company stopped using the VPN, but he had no authority to force teams to build or migrate services to be available outside the VPN, and there were 2+ decades of services to migrate, and he couldn't direct people to stop connecting to VPN if they needed something that was inside the VPN)
The PM that came along to replace him described himself to all the engineers as "the next Elon", wouldn't let engineers talk to customers, personally decided what features to build with no input from the dev team, even when making technically difficult decisions. He asked for estimates from devs but never used them. Often giving us both half the time asked for, and half the engineers asked for to deliver a project. He never deflected chaos from customers, just added a translation layer that made it impossible to make the customers happy. Everything was an emergency, every feature necessary for an MVP. He'd constantly harass people for status updates, forget what they were working on and harass them again. He constantly asked for documents to be written for himself that he never bothered to open the links too.
He was actively toxic, wrong and an impediment.
He'd send out launch announcements to the org celebrating the projects that were completed and it was customary to list key people who delivered the project. He'd forget whole teams of people that worked on the project. One time he left me off of a project that I lead, got everyone in our sibling team that was helping out though. One person he never forgot to list as being a key person involved in the project was himself. Even in projects he had never heard of before having to write the launch announcement.
That behavior was rewarded, for whatever reason. Although he finally left the company when one of the many rounds of "you must work from the same office as your manager" bullshit caught him up and he wouldn't relocate from canada to the US.
Sounds like you're describing someone with narcissistic personality disorder. Such people are often extraordinarily good at convincing the people above them they walk on water while shitting on everyone below them.
My greatest wish is for managers to be trained to recognize people with NPD and other disorders and to remove them from the company quickly. They can cause tremendous damage to the organization in a very short time.
- Have no understanding of the technology they're "building."
- Don't understand who is responsible for what.
- Would have NO idea if things were set up incorrectly.
- Are solely working through a checklist of items and asking "is this done, or do you have dependencies?"
- The checklist itself was just built by interviewing different stakeholders, but it's the PM who puts it together and of course the PM who doesn't really understand the detailed or high level view of the project.
It's pretty maddening, and self-evidently stupid. I really cannot fathom why my company and other companies fail to understand what a waste of time and money this is. And worse, than the PMs are often leading to worse outcomes. Please keep this in mind anytime someone tells you that we need to "run government like a business," or suggests that businesses are wildly efficient whereas government is never efficient. If we had EVER had a useless PM like this back in government I would have forced them off the project as part of our criteria for success. In the corporate world, there's really no such option, because project success is always secondary to the businesses wants.
Yea, that sounds pretty satisfying…
Not sure how important delivery was to the company, but it's nice when your personal goals match those of the company.
Keep in mind that:
- I didn't step in between engineers and the company. I am an engineer.
- I didn't step in between my team and the decision makers. It wasn't me who "invented" the requirements, nor it was me who said the projects were complete.
- It was the only time in the last few years where I could actually follow the advice in this article and ship things people need. Because I could TALK with people.
- My entire team got salary increases all across the board.
- Everyone has an ego, and everyone has a personality. But nobody in a team should get to put "more" of their personality over the others. We had brand guidelines and accessibility requirements, but other than that we decided things together.
I did this myself and ended up with a really satisfying 4ish years as a PM.
That being said while I was perhaps fairly cynical about why PMs needed to exist before trying the role myself, after being in the role for an extended period of time, fully understand why the role exists now.
Of course there can be bad PMs, a good/great one is super worth it.
I'm not really cynical, and even before I wasn't!
I just think it's a role that's way too critical, and a bad PM can do a lot of damage.
Mostly politics, I guess?
The CTO was about to be fired, so I had nobody to fight for me. The Chief of Product didn't like the optics of a non-PM being more successful than a PM in delivering work.
(EDIT: As I said, I delivered from start-to-finish 3 projects that other teams had considered "impossible", mostly because of bad specifications and overengineering, often caused by PM miscommunication. The PMs of other teams REALLY took the blame here: one was fired and sued by the company before I joined, and the other confessed to me he was "asked to leave")
As for why I don't change careers, I'm an Engineering Manager and I made twice as much money than a senior PM at my previous organization.
I still long for a position where I can be both technical, product and business minded. But I guess the only job where I can do that is as a founder.
Its crabs all the way down: https://en.wikipedia.org/wiki/Crab_mentality
That is one big reason I want to remain an IC for my career. There's slightly less ego to deal with and usually more passion among people compared to management. That passion is pretty much the main thing keeping me in this career.
so this reads like any other salty engineer who thinks he's smarter than everyone in the org, business people are useless and if only he would yield decision power, all issues would be solved immediately.
but guess what, it's usually not true and that mindset is usually not good to collaborate with either.
The article goes on to talk about legibility of value or perception of value which is a subtly different concept.
Is “unagentic engineer” a euphemism for human/not-AI?
Unfortunately for companies whose engineers work this way, they’re on a one-way trip to expensive cloud bills, data breaches, and frustrated customers.
A good amount of that “never done,” work is:
- Patching security vulnerabilities
- Fixing mistakes made due to lack of planning/testing
- reducing costs due to lack of planning (ship it now, make it better later)
- responding to customer feedback
If the business you’re working in doesn’t see the value in the work you do then, when you can, find a new place to work. They’ll sink their ship well enough on their own.
I read this as engineers without agency - those who have little to no freedom to make any decisions on their projects.
Basically, people like when employees show initiative, operate independently and influence their surroundings independently. At least they like to say that.
It’s a common trap for engineers, many of whom like to burrow in and crank out stuff. You’re toiling away slaying tickets and doing your thing, but become invisible or don’t realize managements attention elsewhere.
A great example that is less cynical is interface design - I greatly enjoy building user interfaces that are correct for lots of little interactivity details. It pains me to release an interface that breaks on tablets, or where the container doesn't have padding so the button awkwardly juts up against it.
This kind of attention to design detail is not automatically rewarded except for at companies and startups for whom that's something that is valued, and design intuition is praised. I've had people come to me for work in the past specifically because they love that I pay extra attention to this stuff.
That said, in many places this is not appreciated at all and none of this would be a value add.
No, it refers to people that are not "high agency", i.e. they might be smart and competent but need guidance on what to work on, as opposed to taking initiative themselves.
Pretty sure it means someone who plods along in life, going with the flow, working but with no self-conceived roadmap of ambition, low extroversion, low desire to make decisions, etc
Companies, departments and teams operate on a spectrum from reality-centred to status-centred.
In a reality-centred culture all the things you mentioned matter. Reality-centred management understands this, manages it, and rewards it.
Reality-centred cultures are better at medium/long-term planning and at handling issues rationally.
In a status-centred culture the most important product is status in the hierarchy. A "competent" engineer delivers status to superiors. That's their only job. The quality of the product, codebase, and the customer relationships is secondary - sometimes irrelevant.
Status-centred cultures tend to be reactive, not innovative, and the orientation is emotional, not rational. Hierarchies are strict, communication is poor, and low-status people are treated badly. (Because how else is everyone else supposed to know they're low-status?)
No one cares when things work smoothly, but if there's a problem that causes a loss of status, someone has to be blamed for it.
Status cultures don't necessarily implode. If they have an effective monopoly, they can survive for decades.
They're more likely to seem like huge players until suddenly one day they aren't any more, and everyone wonders what happened.
> Status cultures don't necessarily implode.
True! And they're often not a great place for developers to work (unless you want to join in and become a manager and leave development behind).
Sometimes they do, though. And while it’s spectacular to see it up close, it won’t make you feel any better.
The thing is, if in order to be successful in a big company you need to be a great salesperson and technically adept as well as organized then basically you're already a great entrepreneur. You're just a pet entrepreneur being kept on a leash.
And yes, lots of companies want pet entrepreneurs. That way all they need to bring to the table is capital.
If all that matters that someone at the top sees it and is happy about it at this specific moment in time, why bother writing code that can last and doesn't leave behind an absolute unmaintainable ball of mud?
We don't need gold plating and yet billions could be saved by having invested more than the bare minimum.
You know the old standard:
Never attribute to malice what is equally explained by incompetence
Also many software engineers are just not very good, frankly. It's extremely difficult to become an actuary without a strong mathematics background. It is very easy to become a software engineer with any kind of background, even if being a good one is just as difficult.
I can already hear the chorus of people that will scream "I'm not paid enough to care" or "it's just a job for some people", and those things are often true; but, nonetheless, people used to take much greater care in their craft even when they were paid less. There was a sense that, even if it was just a job, it should be done well. A certain sensibility of care and craftsmanship has faded away.
If anything this is worse.
Many talented and conscientious craftspeople, to pay the bills, work jobs which don't afford them full creative freedom, or even appreciate it.
> people used to take much greater care in their craft even when they were paid less
Did they? Maybe this is the golden tint cast when we reminisce about "the good ol' days". I currently know some people who take much greater care in their craft, than some other people I used to know.
The attitude of "I'm not paid enough to do that" feels, to me, to be closely correlated with a company asking the employees to do more for/with the same or less, giving less freedom to choose what to do, micromanaging/policing how they do it, and all the while showing a decreasing amount of loyalty and humanity towards them. It'd be unreasonable to expect the employees to then suck it up, grin, and bear it -- They are equal partners in an employment relationship in which one party is attempting to unilaterally change the status quo.
It got replaced with professionalism, as in "being a professional", which nowadays seems to mean prioritizing business needs above all.
Caring about quality and craftsmanship is not professional - it's just not being economical with company time and money. It's better for the business for dev teams to tick features off a list as quickly as they can, because marketing can polish a turd and shove it down customers' throats much more cost-effectively than devs can make a half-decent piece of software that provides genuine value.
No surprise more and more people don't care. They keep hearing everywhere - including here - they should abandon childish pursuits, stop reinventing the wheel, writing too clever code, shaving yaks, going down rabbit holes, etc. - they should be professional. Well, that's what we're getting now.
I disagree, but only partially. The real question is when is the project done as in you would shred the source code and nobody would ever care. Some projects are done when they ship version one - you wouldn't fix any bugs or add new features, so code quality doesn't matter. Some projects are never done - someone will be touching this code in 50 years (after you are dead), so quality matters.
If the code is done then craftsmanship doesn't matter and putting effort into it is an unprofessional waste of time. However if the code will be maintained for years in the future then not putting effort into craftsmanship is unprofessional. You need to know where you are. Sometimes writing ugly code is a good use of your time, sometimes writing good clean code is well worth it.
The important thing is to know where you really are. The wrong choice will hurt you.
I think people used to care more when there were less BS involved in the software development process. Nowadays you get: scrum masters, product managers, product owners, engineering managers, daily standups, refinements, "getting things done", "shipping impact", "10x engineer", "red-carpet engineers from FAANG", and CEOs that want X or Y for yesterday. So, yeah, in that kind of environment, I couldn't care less about anything. I just do it for the money.
All my craftsmanship goes into my personal projects.
Now if you don't let engineers live out their passion, you made the choice to select for the ones who just do it for the money. That can be a legit choice, but comes with risks.
Never maintain it for "free".
Then the cycle starts again.
So that's why Google releases a new chat app every two years...
Are we all embedded in absurd structures of primate dominance? Sure. Primates gonna prime. But that is no more the root of what's going on than being able to mark something done in Jira, or getting a compiler to stop complaining. Proximate hurdles are not ultimate goals.
Nobody gets to the end of a technical career and says, "Welp, that was 40 years well spent making a rotating series of bosses and grandbosses happy."
I don't think it's good for you to be a cynic(because there's more to life than "promotion!"), but I think it's good to know/be well aware of the cynical viewpoint, because there's often a lot of truth in it.
However, my point is that one's analysis of the purpose can't stop with any of those. That focusing only on any one of those is ultimately shallow.
And in particular, my critique of this article is that he's just shifting focus from one proximate goal to another. Is pleasing the bosses necessary? Under our current dominant theories of work, yes. Is it the point? No. Always and forever: no.
But people have different ways of expressing this same idea, because it gets tiring to see/read it in only one form.... so I guess one has to get a bit provocative in order to draw attention :)
(and to be fair, given how distasteful many programmers find the "marketing" part, it's somewhat useful to have many different ways to tell them that it's needed).
Isn't that the definition of being employed? pleasing the persons who pay you to do what they ask?
It is defined as:
used to describe someone who works for a company at two levels higher than another person, or a meeting or relationship that involves an employee and a manager at two levels higher
by Cambridge's dictionary[1]. That makes it really complicated when the article talks about 1-3 skip levels, I'm not sure how to interpret that ... is it (my level + 1 + n) or (my level + 2 * n)?
Edit: the mathyness.
[1]: https://dictionary.cambridge.org/dictionary/english/skip-lev...
How I ship projects at big tech companies (1425 points, 381 comments) https://news.ycombinator.com/item?id=42111031
People won't notice this extra effort for a long time, but from time to time, some problem/issue will arise and one of those things in my garden will be instrumental in solving or mitigating it. Over time, you get recognized as someone who gets things done well.
Basically get stuff 'done' in 80% of your time and make your own 20% time. What's funny is that I've often been given explicit 20% time, but I've found that I can't schedule/manage that time explicitly like that, so I went back to taking approximately 20% time if/when I thought it's appropriate.
These people are often force multipliers, or "developer velocity engineers". They do work that doesn't deliver direct customer value, like updating old dependencies, swapping out deprecated APIs for new ones, always fixing warnings in CI pipelines and lint tools, etc. They free up others to deliver the "value" at higher speeds.
But yes, they are the first to go when layoffs happen. But I think these types are absolutely necessary for an efficient org, and no matter how many times this type is fired for it, someone will end up falling into the same work again eventually - because this "no-value" work needs to get done.
The result is that most of our products are dogshit and are force fed to users within the company and to its clients.
It's the business's jobs to know how to explain the business and their needs. If they can't explain it, they probably don't understand it. If they do understand it but can't explain it, they probably need to work on their soft skills. You're also going to learn the business implicitly if they're explaining it well.
You could be a developer that also knows the business, but where's the compensation for going the extra mile? Especially when the layoffs come around. Another perspective is if you have time to work the business side, what could you have been working on technically to improve things? So there's potentially an opportunity cost too unless everything is currently as optimal as it can be.
Some parts of this are probably good advise, at least with respect to clocking titular promotions. No disagreement around visibility of delivered "big wins" being key.
However, I feel like this article is subliminally pro-management, with the thesis statement essentially being just make your manager (and their manager) happy. But what happens when there's no clear direction from management on what the team's goals are? Or when priorities shift on a weekly, or even daily basis? It seems pretty hard to deliver anything meaningful, if by the time you're finished they've already moved on to the next shiny thing.
Additionally, in my experience this "make your manager happy" approach goes hand-in-hand with a "yes boss" manager-subordinate relationship. Managers are empowered to flurry out executive dispatches on what, when, and how things ought to be done, and engineers are encouraged to follow orders. Results are normally not great.
Without well defined scope and deliverables, you cannot get "things done".
Never-ending projects means the scope was not well defined, there is a constant scope creep, or the deliverables were not well defined. Or, worse there are good idea fairies in the organization.
(https://www.urbandictionary.com/define.php?term=Good%20Idea%...)
* Doing work on the right team is more important than doing the right work
* Good PMs and managers are more critical than good work
* Good reporting structures are more important to visibility than a high-quality result
* Doing work that aligns with leadership goals is infinitely more valuable than work that supports the functioning of the business
* Always be ready to do the whole thing yourself, because politics in big tech will always disincentivize cooperation across silos.
Unfortunately that doesn't always correspond with "build a better product". If it doesn't but it is what you personally want to "get done" then you're going to need to circumvent the people whose job it is to keep you turning those cogs.
I strenuously disagree with this premise, not because I don't think this ever happens (it definitely does!), but because it's not the responsibility of an individual contributor to attempt to divine the organisation's priorities: that's a core management function.
My employer buys forty hours of my time each week. It's my employer's responsibility to allocate tasks to me in order to best suit the organisation's needs and goals. Recently, I spent an entire week waiting for a specific person to review my code. It's my responsibility to (tactfully) inform my managers of this problem, but it's not my responsibility to solve this problem on my own initiative. The person might have a temporary backlog of tasks, they might be dealing with personal issues, they might have some workflow problems: in some of these cases, the root cause is something I shouldn't know about.
This isn't to say that I'm just the monkey at the bottom of the tree being shat on by those further up: I do pass my (frequently misinformed) opinions and observations up to my managers, but it's up to them to decide whether and how to act upon them. They have more information - feedback from more people for a start - and consequently can make better decisions than me.
If you feel that you have to fight your organisation to serve its needs, something has gone seriously wrong - possibly with you, but more likely with the organisation itself. Organisational pathologies are themselves Chesterton's fences - they exist for some reason, even if the reason is stupid - and are consequently difficult to fix. Perhaps making things difficult for you makes things easier for everyone else. Perhaps fixing the issue will involve so much change to the way the organisation is managed that it's actually better to leave things as they are.
The trope that ICs are incapable of understanding and balancing business interests against their wishlist of work items is just a cope that incompetent management chains tell themselves, because they need to believe that there’s something that they’re providing to the team that it won’t get elsewhere. The fact of the matter is that understanding your project in depth does not cause myopia. Big tech is fat with managers who provide absolutely nothing to their teams, other than filling a management req which was conjured up out of thin air. The best teams have technical leadership and work relatively autonomously.
I don't disagree that your personal employment relationship is like that, but keep in mind that you are describing only you here.
Contrast with another example: It is my employer's responsibility to describe the organization's needs and goals, and to give me the freedom and leeway to figure out how to best accomplish them according to agreed-upon measures.
After the bad metaphors, all the article really says is “do visible work and finish it”. This seems obvious.
I've struggled with this recently. I feel like advancement requires getting credit for the idea itself, otherwise you're just implementing other people's designs. But ideating (will actually good ideas) is pretty tough.
That works really well if you're a contractor/job-hopper and can actually walk away. Otherwise, someone who doesn't understand the code will be asked to make modifications and you, the original author, will be called back in to rescue the thing when it has turned into a dilapidated mess.
The problem the OP is having is not failing to please his boss, but working for a boss that isn't technical and has no idea what is happening. Those bosses are generally terrible for your career and if you have one, you should just quit.
"Well, since we moved the goalposts on that project, now we're out of 'credit card' tech debt and now in 'Adjustable Rate Mortgage' tech debt. Our goal should be to get to 'Fixed Rate Mortgage' debt."
The problem is that too much tech debt can hold back feature development, or even materially impact hosting costs. In our case, we're a 10-year-old startup, and many parts of our stack were built in a way that makes them very hard to maintain, or on end-of-life technologies that are impractical to hire for. To be quite blunt: The tech debt got to a point where we spent more time on the debt than feature development.
The problem with this article is that it glosses over the impact of tech debt, and how it needs to be handled. An umpteeth refactor for a 3% performance improvement is very different than a 3000x performance improvement that reigns in hosting costs. Backfilling unit tests needed to prevent regressions when building a new feature is also different than rewriting a major UI component because it depends on a UI toolkit that was end-of-life 7 years ago. All have a very different impact to the business and product.
There is two things to avoid: "overengineering" and "underengineering". The first case has happened when it later turns out that the developer did put in too much work into a feature than was necessary in retrospect, in the second case that they did put in too little work.
At the time of engineering it is usually not clear how much work would constitute over- or underengineering, as this depends on how much the feature gets to be used and evolved in the future.
But usually it makes sense to "err on the side of overengineering". Because (limited) overengineering merely means some development effort was wasted, while underengineering can easily mean years of painful tech debt that is an order of magnitude or two more expensive than the wasted effort from overengineering.
(It's similar to building a house. You usually want to make doubly sure you really do everything right or more than right, because if there are any flaws that turn up later, this often gets very expensive to rectify, sometimes so expensive that it isn't even worth fixing at all.)
In our case there was a lot of overengineering by novices, so a lot of the tech debt involves unwinding overengineering to make a simple change. Some of the "credit card" debt was simply using too many 3rd party libraries.
> (It's similar to building a house. You usually want to make doubly sure you really do everything right or more than right, because if there are any flaws that turn up later, this often gets very expensive to rectify, sometimes so expensive that it isn't even worth fixing at all.)
My fish tank guy told me how he once went to install in a new home, and the general contractor put a structural beam every 3-4 inches under the fish tank. It make it impossible to put in the filters. (In contrast, I only have one structural beam in the middle of my 180 gallon, through-the-wall, tank.)
Rational mindset for an employee, but the problem (for the company) is that upper management is usually unqualified to distinguish good vs. bad technical work. So under this advice, engineers do the minimal work to “deliver” lots of features in order to check off the OKR for upper management, but the engineering is done poorly. Upper management has no insight into the quality of the work, but over time the bugs and performance degradation pile up, while engineering managers get promoted and OKRs completed.
The only real resolution is to push technical expertise as high up into the org as possible, so that even if engineers are only appeasing upper management, upper management will demand good quality work. Apple is the notable example of this org structure: there are no general managers except Tim Cook; everyone who reports to Cook is a technical expert.
Unless you are selling your own product or service that you yourself are working on (possibly indefinitely).
Which is surely an enjoyable position, as long as you don't mind having no like-minded coworkers.
I have seen countless projects spun up, the company declares the problem solved (done), and then the team is disbanded to go work on new problems.
What happens next? The product they built has issues, new features are needed, the rest of the company keeps evolving… all the while, there is no one to actually maintain that “done” project and it becomes technical debt.
Eventually a new manager comes in, sees this mess of an old project and builds a new team to solve this problem all over again from scratch. They have to learn everything all over again and repeat a lot of the same mistakes of the first implementation, and the cycle continues.
This doesn’t seem like an effective way to run anything. If I can use an air conditioning metaphor, it is more efficient to set the house at a temp and keep it there, than to keep turning the AC off, letting the house heat up, and trying to bring it back down from 90.
I had a little side project at work that upper management didn’t care about, but was immensely useful to various support teams. At one point it had over 500 unique users internally, through word of mouth, as it was only designed for one team of about 50. The initial build took some effort, but once it was running it still needed care and feeding to keep it relevant. I managed it personally for over 10 years, and my priority was always responding to organizational change to keep it relevant and as a trusted source. The second it fell out of date, people would lose trust in it and start looking elsewhere, which is when tooling starts to fracture. It didn’t take much time. Sometimes I’d go months without touching it. Most updates took 5 minutes, some more involved changes might take a day here or there. But that was important work to prevent needing to re-invent the wheel down the road once it became too painful to use due to lack of maintenance.
Someone fresh enough to think anyone cares about the backlog deserves a manager that knows to meet them where they are, not expect the employee to meet them in the arena of management games. In practice, this often doesn't exist. Rather than the lowest rung of management bridging the gap into the tech, it's usually on seniors to "manage up" and shadow manage the team. Seniors good at this are more common, but time strapped with the rest of their dayjob.
The target audience of this article needs a powerleveling guide to all the management sills of a senior, because they're in a vacuum with no seniors or technically competent managers. But instead it's the tiniest taste of the management world needed to orient someone towards being a better cog.
1) Always pleased middle management in a large bureaucracy by moving metrics, then bailed out just before the project collapsed
2) Ignored the noise, fixed real problems and left the project better than they found it?
After 20 years of tech career and 3 FAANGs, I know my answer. This article is decent enough advice for the first 5 years of your career, so you get some seniority and money.
Once you have those two things, what they give you is the agency and the safety to walk away from bullshit.
After that the game changes: it's about credibility and being sought after by your peers, who, at this point, should also hold senior IC positions at companies whose help you need, sit on standards committees, have maintainer rights in the Kernel, etc.
Your long-term professional success will come from being an excellent technical peer, rather than pleasing random middle managers you will never work with again. Your personal job satisfaction will come from honing your craft and solving real problems for real customers, not from hitting some arbitrary business milestones. (Obviously those two things sometimes align, but if you're forced to make a choice.)
This person understands the “business” side of the tech business. I couldn’t agree more. Where many struggle is that they can’t communicate legibly about the indirect benefits their work has for the business. The classic “refactoring” (which he mentions) is a great example.
Refactoring code has a context dependent benefit to a business. When you’re searching for product/market fit is has essentially no benefit, and then you’re Microsoft and the code is deep within Windows and affects the performance of every Win32 app it can have extreme benefits. In the end it’s all about how you relate your work to either making or saving the organization money, and doing so indirectly can be legible if you take the time to figure out how to best communicate it to the target audience (and how it can be conveyed to customers).
At the end of the day, most decisions at a business come down to a cost versus benefit, assuming that the business is behaving more or less rationally
Most business people in my experience also view the software itself as an expense, not an asset. I find that software devs do not understand that. "What do you mean the software is a cost center. This whole business sells software, how can we make money without software?"
This isn't how many business types view it. The software doesn't matter to them at all. They would love if they could just sell nothing, so their costs would be zero and their profit margin would be infinite. That is the actual dream
It's not rational but you gotta understand that sales doesn't sell on rational, they sell on vibes, good relationships, bribes, whatever they can get away with.
Trying to be rational when selling puts you on too level of a playing field with other sellers, so they pursue other angles
First, recognize that if you’re in the situation at the beginning of the article. A dev, banging out tasks that don’t quite move the needle or seem important towards actually achieving any milestones. It’s possible thats by design, your the random job site broom sweeper cleaning up at the end of the day (construction metaphor). It’s also likely your management/leadership is failing you. They’re failing by not prioritizing your work. You need to know what larger goals exist and are politically important to the organization and then what tasks you can do to accelerate that goal achievement. This is what your manager should be doing. If they’re not, and you just work on a random list or todos, start pushing them for prioritization in every 1 on 1 and every checkin or whatever touchpoint you have. Make sure you understand what other higher level goals the prioritized work supports so you know where to fill in gaps and can be proactive and mention when you think something is off track (eg “hey boss, I’m working on X but it seems somewhat redundant to Y, can we merge these as a cohesive solution?”)
Once you get this part down, you start learning the decision makers in the company (or the highest ones you have some access to) and you start getting their opinions on what projects are higher priority or more crucial to the business. If you can build rapport with a few of these people and make sure you’re contributions are known and appreciated towards things they find valuable and important, your career will start to progress fast(er) in almost every aspect.
When these people eventually leave for a new gig, you want to be the ones they try to poach. If they stay and get promoted, you want to be the ones they think of for their new initiatives.
dcminter•4h ago
underdeserver•3h ago
If the execs don't see the value, customers don't see the value, and you can't prove money is being made (or saved), where is the value of your work, really? You're not paid to make art.
lazide•3h ago
Because the paycheck is indeed useful for them, eh?
underdeserver•3h ago
lazide•3h ago
dcminter•3h ago
ta1243•3h ago
lazide•2h ago
Also, pay is usually a lot less.
dcminter•3h ago