9 ms·

Getting things “done” in large tech companies

315 points by swah 1y ago

dcminter 1y ago
Absolutely true, and absolutely one of the reasons that working in large tech companies can be soul destroying.
- underdeserver 1y ago
  I see it completely differently. 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 1y ago
    Well, that is also why large segments of the big corp work environment check out and do the absolute minimum - or even create chaos to make it less obvious who is doing what for whom. Because the paycheck is indeed useful for them, eh?
    - underdeserver 1y ago
      These people are comfortable collecting a paycheck despite providing little value. I'm not.
      - lazide 1y ago
        Sounds painful!
      - dcminter 1y ago
        Do you like working with those people? That's part of it.
        underdeserver 1y ago
        Some of them I do, some not. They generally believe it's their bosses' responsibility to make sure their work is valuable. I guess that makes sense, but I'd like to own that responsibility myself.
    - ta1243 1y ago
      This is why small companies can compete. What they lose out on economies of scale, they gain on avoiding this.
      - lazide 1y ago
        They can also get completely nuked by market forces a lot easier. Also, pay is usually a lot less.
  - dcminter 1y ago
    You're right, but this assumes that the execs have the insight to see that maintenance tasks save money. If preventing next year's incident isn't understood as being as valuable as doing the hero work to untangle this year's incident then it can be hellish unless you like hero work.
whstl 1y ago
I don't disagree with the article, but after working in big tech, two HN startups, a couple unicorns and others, in two continents, I don't really find this too actionable. 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.
- _fat_santa 1y ago
  > At least the pay is alright. 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).
rileymat2 1y ago
> But they’re not doing their actual job, which is to deliver the most value they can to their company. The article goes on to talk about legibility of value or perception of value which is a subtly different concept.
agentultra 1y ago
> this fact is a trap for competent but unagentic engineers 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.
- jagged-chisel 1y ago
  > Is “unagentic engineer” a euphemism for human/not-AI? I read this as engineers without agency - those who have little to no freedom to make any decisions on their projects.
- Spooky23 1y ago
  “Unagentic” is a terrible made up word to say that employees lack agency. 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.
- stuartjohnson12 1y ago
  It doesn't have to be that way, but that's certainly the default unless executives put in the work to make certain kinds of work legible. 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.
pydry 1y ago
This whole article could be boiled down to "it doesnt matter what you do it only matters what executives perceive you as having done". 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.
eXpl0it3r 1y ago
Is this sentiment the reason why a lot of "engineers" will provide terrible quality in code / tests (lack thereof) / documentation / etc.? 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.
- spicyusername 1y ago
  I don't think anyone purposely writes terrible code. You know the old standard: Never attribute to malice what is equally explained by incompetence But certainly stagnant conditions or burnout can prevent people from really putting in the extra effort. Why go the extra mile when it's consistently not rewarded, and in some cases punished? 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.
- beezlebroxxxxxx 1y ago
  More and more you run into people who simply don't care about craft and quality. 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.
  - pydry 1y ago
    The chorus drones on about you're paid to deliver value and customers dont pay you for docs or tests or refactoring. If anything this is worse.
  - ImPostingOnHN 1y ago
    > More and more you run into people who simply don't care about craft and quality. 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.
Palomides 1y ago
"once software is done, you might be tempted to maintain it, but don't fall into that trap!" seems like a bleak thesis to me
- spicyusername 1y ago
  They are implying that it is up to the decision makers to decide whether maintaining it is valuable. Never maintain it for "free".
  - pphysch 1y ago
    most generally useful software is maintained for free
artyom 1y ago
Your work in a large tech company is done when your manager (or a manager two levels above) gets promoted. Then the cycle starts again.
nyanpasu64 1y ago
> What does it mean to get things done in large companies? Most importantly, it means finishing things. So that's why Google releases a new chat app every two years...
wpietri 1y ago
I fundamentally object to any notion of done-ness that is solely focused on pleasing the few people who happen to be in positions of power. 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."
- virgilp 1y ago
  I don't know. I'm 30 years into those 40 and, while I can list plenty of "achievements" ... that's not what got me promoted. There _is_ value in making bosses & 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.
  - wpietri 1y ago
    We agree: There is value in making the compiler happy. There's value in getting tasks done. There's value in pleasing bosses. They are necessary means to an end. 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.
    - virgilp 1y ago
      Agreed - the better take is "getting promoted in large tech companies requires marketing" (and even that is only true for the senior roles, in the junior roles, being good at your trade is typically enough to get promoted to "less junior"). 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).
unwind 1y ago
I had to look up "skip-level" since my large tech company lingo was lacking. 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-level https://dictionary.cambridge.org/dictionary/english/skip-lev...
- stepanhruda 1y ago
  Skip level is your manager’s manager, presumably 2 is one further step etc
- pitched 1y ago
  You “skip” over your boss to talk directly to your boss’s boss. If the hierarchy is very deep, you can skip even more levels
- deleted 1y ago
  [deleted]
lolinder 1y ago
This piece appears to be a quick summary of a much better and more thorough piece by the same author that was discussed extensively a few months back: How I ship projects at big tech companies (1425 points, 381 comments) https://news.ycombinator.com/item?id=42111031 https://news.ycombinator.com/item?id=42111031
karmakaze 1y ago
The post is apt in getting things 'done'. I prefer to get things done. Of course I can't always just do what I consider important, so I balance them, I meet the requirements of 'done' without much more, and I spend more time than most getting important stuff done, sometimes things that take a longer time--I'll do the gardening so that it eventually gets done. 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.
davidmurdoch 1y ago
> they start delivering a stream of marginal improvements to a particular subsystem1. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most value they can to their company. 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.
hoseja 1y ago
enshittification: perspective of the camp guard
soVeryTired 1y ago
Simultaneously correct and devastating. Where I work, senior leadership don’t have a technical background and so don’t know when something is “good enough“. The result is that most of our products are dogshit and are force fed to users within the company and to its clients.
johngossman 1y ago
While I generally agree with this, I’d add one thing: to understand what your managers want, you really need to understand the business. At the highest level, how does your company make money, or at least think it’s going to make money? What other things does the company value? It’s surprising how often I find developers who don’t know, either because they aren’t curious, are too busy to learn, or (surprisingly common) think it’s somebody else’s job to make money…they’re just doing what they’re told. My advice is to actively try to meet upper managers, sales and support people, marketing people, and ideally customers. You almost always learn something you can apply. In big tech it is way too easy to be insulated from what the output of your job actually is. This applies even if you work on internal systems—-somewhere those systems either add value or protect the company, and understanding that helps get your job done. And if it turns out your group doesn’t add value, or you can’t figure out how it does, then start looking at what groups do add value and whether you can move there. I did a few jobs that were not clearly aligned with the company needs and those always turned out to be a mistake. The valued work not only pays better is (usually) more satisfying.
- hnthrow90348765 1y ago
  I think it's fair to think of yourself as a carpenter. Devs talk a lot about this being a craft. You build to spec but point out problems when the spec is not possible or silly. 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.
  - johngossman 1y ago
    It just happens that two of my good friends are carpenters. And they are highly aware of the business. They have to be in order to ensure they have work as construction and remodeling and other types of work ebb and flow. It’s precisely when the layoffs come that it is valuable to understand the business. You are absolutely right that ideally the business people understand and explain the business, but are you really going to trust your livelihood so completely on that? Sometimes their job is to keep you working, fixing bugs, adding features, until they reach the point they can lay you all off (this pretty much happened to a bunch of my friends at an early job). Furthermore, just building to spec suffers from the Henry Ford problem of the customer asking for faster horses. Unless your business people understand the tech as well or better than you do, it is very likely you can improve the product more if you understand the business than if you just do what you’re told. This does not have to be very time-consuming, and ideally your manager helps, but just paying a little attention, spending some time with people in other disciplines, can have huge payoffs.
cljacoby 1y ago
I have mixed feeling on this. 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.
- nickysielicki 1y ago
  The solution to this is pretty simple: when you find yourself working for idiots, just quit. It’ll suck for a little while, and then it will get better. Which is much better than spending months trying to make stupid and under-qualified people understand things that smarter people would understand intuitively.
- kylereeve 1y ago
  On the flip side, when you have a manager who's genuinely on your side and wants to help you produce value (seems rare, I've been lucky enough to land one or two), "pleasing your manager" can accelerate career advancement and actually delivering working software you're proud of.
WaitWaitWha 1y ago
In my experience, the two most important things to get "things done" is the other part of that sentence, the "things". 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%20Fairy https://www.urbandictionary.com/define.php?term=Good%20Idea%...)
stego-tech 1y ago
While the OP’s post is helpful, I’d argue it glosses over several other, far more critical points that other commenters have touched upon here: * 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.
2d8a875f-39a2-4 1y ago
"Getting things done" means applying torque to one or more of the cogs in the corporate cash flow machine of which you are a part. 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.
cjs_ac 1y ago
> In large tech companies, this fact is a trap for competent but unagentic engineers. They see an infinite queue of tasks that they’re capable of doing, and they start delivering a stream of marginal improvements to a particular subsystem. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most value they can to their company. From the perspective of their manager and skip-level, they’re not getting anything done. 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.
- nickysielicki 1y ago
  > because it's not the responsibility of an individual contributor to attempt to divine the organisation's priorities: that's a core management function 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.
rzz3 1y ago
I don’t want to be negative, but writing a mathematical proof and planting a tree are about the worst metaphors I could possibly think of. Building a house is probably a better example for something that could be infinitely maintained and improved. After the bad metaphors, all the article really says is “do visible work and finish it”. This seems obvious.
jere 1y ago
> The easiest way to do this is to deliver things that they already know about, such as projects that they’ve asked you to do 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.
panny 1y ago
>Declare victory and walk away: go and do something else 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.
gwbas1c 1y ago
Yesterday I pointed out to the founder of the company that I work for, in the context of tech debt: "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.
- cubefox 1y ago
  Yeah. I would phrase it like this: 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.)
  - gwbas1c 1y ago
deleted 1y ago
[deleted]
highfrequency 1y ago
> How can you finish things in a world where you can keep improving systems indefinitely? It means getting them to a point where the decision-makers at the company are happy. 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.
SanjayMehta 1y ago
I feel the author’s telling us to play politics without using the word politics.
pmarreck 1y ago
> If you want to get things done you can’t be a gardener. 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.
al_borland 1y ago
While I understand the point being made, and have experienced this reality first hand, I still object to it. 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.
- antognini 1y ago
  > 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. While I get what you're trying to say, if I can be a bit pedantic this is not more efficient thermodynamically. It is more efficient to let the house heat up and then bring its temperature back down.
  - 1y ago
steele 1y ago
Shallow content slop red flags abound. Might as well keep moving the definition of done goalpost-- nothing is done until it provides utility that a customer exchanges money for. How about until there are enough customers are paying to make the system profitable? How about nothing is done until you hear it referred to as "legacy"?
dogleash 1y ago
I've been trying to figure out what bugs me about this advice. I think it's narrowly tailored to people with zero technical leadership on their project, but also doesn't give them enough groundwork to really succeed either. 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 skills of a senior, because they're in a vacuum with no seniors and their managers are not leaders. But instead it's the tiniest taste of the management world needed to orient someone towards being a better cog.
deleted 1y ago
[deleted]
RainyDayTmrw 1y ago
I strongly dislike "alignment" as a buzzword, and I think its existence is ipso facto an indication of our industry's dysfunction, but it nevertheless represents a legitimately important concept. You, your manager, and (to quote the article) some appropriate number of your skip-levels should ideally agree on what the most important next work items are. And to the extent that you don't, that's a problem for you as the individual contributor. Is this right? Is this fair? Of course not. Not in any moral sense, at least. But those are the cards we're dealt, and we play them as best as we can. The article is right that, on some level, we are paid to do what we are told to do. This is not a great outcome. Some of us are fortunate enough to have some sway in the opposite direction. This is the so-called "managing up" - another buzzword I strongly dislike, but again represents a legitimately important concept.
nspassov 1y ago
I continue to be amazed how the respect for the work of IT professionals gets lower and lower. This article attempts to reduce software development down to "people pleasing". A prostitute is also paid to make the "investors" happy but even people who've never hired one agree that not every demand by the "investor" can be fulfilled and that the prostitute can set boundaries. Yet, when it comes to software development, people such as the author of this article claim that the only true definition of done can be derived solely from the desires and wants of the business people (some of who tend to change opinions depending on what time they'd woken up). Imagine if civil engineers operated in this way.
d_burfoot 1y ago
This is one of a whole genre of HN-boosted blog posts that are basically saying to engineers: "you can't just write code, you actually have to do sales also". People who don't like sales think that they can go to a big company and just do engineering work. Nope, it doesn't work that way: you still have to promote your work, you still have to sell your work, you still have to talk to your customers, you still have to understand business, you still have to make deals, etc etc.
t8sr 1y ago
Would you rather work with (hire for your startup) someone who: 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.)
madmountaingoat 1y ago
I hope this was more of a philosophical musing than career advice. I've not worked at every big company, but I have worked at a few. I agree that in the context of a big companies, "done" is a metric; and career success at that big company depends on moving the metrics those leaders track. But in my experience modern big companies also look at peer review and if you're always committing junk, those reviews are not going to be kind. So like everything, it's a balance. Please your boss by closing tickets. Please your peers by writing good code.
ary 1y ago
> … it means delivering the kind of things that are legible to the decision-makers at the company: i.e. visible to your manager, plus 1-3 skip levels, depending on your title. The easiest way to do this is to deliver things that they already know about, such as projects that they’ve asked you to do, or incidents that are serious enough that they’re involved in them. It’s possible to make other work legible to them as well. If your work produces or saves money, that will make it immediately legible, for instance (or you could just be really convincing). By default, work you do isn’t legible: to the decision-makers, it’s generic technical nonsense. They don’t know whether it’s crucial high-impact work or pointless code reshuffling, and will tend to assume the latter. 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).
- bluefirebrand 1y ago
  I couldn't agree more. It really is important for developers careers to learn at least a bit of business speak, and try to learn how to frame problems in ways that business people understand and care about 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
conductr 1y ago
That’s all great but, how? 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.
Velorivox 1y ago
> The wealth of the mega corps does allow most goals to be accomplished, at great expense, with Just A Job workers, but people that have experienced being embedded with Really Care workers are going to be appalled at the relative effectiveness. —- John Carmack https://news.ycombinator.com/item?id=26170052 https://news.ycombinator.com/item?id=26170052
pphysch 1y ago
tl;dr: "fuel your career with technical debt"
csours 1y ago
I've noticed that people who are good at getting promoted are good at claiming success. Claiming success is not wrong per se, and getting promoted is not wrong per se, but sometimes the claimed success does not accurately represent value delivery. "Definition of Done" is a social exercise, not a technical one.
nine_k 1y ago
> If you want to get things done you can’t be a gardener. I'd say that you can be a gardener, but you have to periodically demonstrate the harvest.
uptownfunk 1y ago
Just ship or push to clarify reqs until you ship. Don’t let anything else hold you back (oh let me ask my manager etc etc). Clarify the reqs, get sign off and ship. It’s that simple.
akomtu 1y ago
Sometimes I think that the big tech corporations are soul extraction factories that only incidentally vacuum money. This article says, in essense, that millions of very bright college grads in the US fly to big tech hoping to make the world a better place, but instead their skill of recognizing truth gets perverted by corporate politics, and the sum of their work simply manufactures and monetizes addiction.
scrubs 1y ago
You want interesting? You want insight? Let's talk to the author here in 20 years, and review this question. In addition to operationally defining "get things done" and our own 20 years we can learn about, - why done means "some manager is happy" is just a silly definition leading to notions of things like customers, SQA/TQA etc.. - impediments to getting things done, which must be solved first - on grit: sometimes you gotta hang tough and do the right thing when the people you're helping are morons and reject what you do - towards defining what "value" is etc.
didgetmaster 1y ago
So, is this why the software world is full of bloated, slow, and buggy applications? Work on something just long enough to get it barely functional so the manager can check some box; then quickly move on to the next thing?? Sure, there is always a point of diminishing returns; but leaving something only half-finished will cause more problems down the road. I have been brought in several times during my career to fix something that initially passed some acceptance criteria; but later became unusable once the load picked up (massive data, more concurrent users, etc.). The world doesn't need just more apps. It needs many of the current ones to work better.
spwa4 1y ago
This article is committing a fallacy. The idea, that "decision makers" everywhere have: that there is anything at all that you can buy. It's not true. Even if you buy a stone, with the expectation that you can keep that stone ... requires constant payments for space to store it. Ownership, in the sense of owning something forever without further cost, doesn't exist. And the more obvious it is, the more people fight it. A car requires constant maintenance, tax, and work, and so does a house. You don't own them, and if you don't pay ongoing costs, eventually in most locations the government will either force you to sell or even pay for the destruction of your own property. But somehow making software must allow any idea to just be built once and then keep working, never to be touched again. Right back to ownership absolutism. I have built software in the beginning of my career that's still running, after 30+ years now. But most often, I find I have trouble convincing managers that they will be needing computers (whether onsite, colo or cloud) to run that solution if they expect it to do anything, never mind the occasional bugfix and/or system administration.
- teeray 1y ago
  The only things I can think of are those that would be unethical or illegal to deprive you of (e.g. a tattoo).
whatever1 1y ago
We need a spinoff system where big companies can easily offload legacy products that do not align anymore with the company’s direction / bottom line. Does it make sense for Google today to be building Wi-Fi routers? No. The entitlement is not there, superstar engineers would not want to work at this project since only marginal contributions are needed. Would I love to be an owner of a smart WiFi router company with excellent UI, integration with Google products, established sales and roadmap? Heck yes. There just seems to be so much red tape around these that companies prefer to simply kill such products.
rk06 1y ago
Honestly, i agree with this article. But i have seen a better article in past Article https://www.seangoedecke.com/how-to-ship/ https://www.seangoedecke.com/how-to-ship/ HN https://news.ycombinator.com/item?id=42111031 https://news.ycombinator.com/item?id=42111031
- gnabgib 1y ago
  You're aware this is the same author, and this copy is just a recycle of that 2024 article?
liampulles 1y ago
The best effort vs. boss happiness work I've seen is CSS tweaking work. Adding "delightful" transitions makes bosses very happy.

315 points by swah 1y ago

dcminter 1y ago

Absolutely true, and absolutely one of the reasons that working in large tech companies can be soul destroying.

underdeserver 1y ago
I see it completely differently. 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 1y ago
  Well, that is also why large segments of the big corp work environment check out and do the absolute minimum - or even create chaos to make it less obvious who is doing what for whom. Because the paycheck is indeed useful for them, eh?
  - underdeserver 1y ago
    These people are comfortable collecting a paycheck despite providing little value. I'm not.
    - lazide 1y ago
      Sounds painful!
    - dcminter 1y ago
      Do you like working with those people? That's part of it.
      - underdeserver 1y ago
        Some of them I do, some not. They generally believe it's their bosses' responsibility to make sure their work is valuable. I guess that makes sense, but I'd like to own that responsibility myself.
  - ta1243 1y ago
    This is why small companies can compete. What they lose out on economies of scale, they gain on avoiding this.
    - lazide 1y ago
      They can also get completely nuked by market forces a lot easier. Also, pay is usually a lot less.
- dcminter 1y ago
  You're right, but this assumes that the execs have the insight to see that maintenance tasks save money. If preventing next year's incident isn't understood as being as valuable as doing the hero work to untangle this year's incident then it can be hellish unless you like hero work.

whstl 1y ago

I don't disagree with the article, but after working in big tech, two HN startups, a couple unicorns and others, in two continents, I don't really find this too actionable. 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.

_fat_santa 1y ago
> At least the pay is alright. 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).

rileymat2 1y ago

> But they’re not doing their actual job, which is to deliver the most value they can to their company. The article goes on to talk about legibility of value or perception of value which is a subtly different concept.

agentultra 1y ago

> this fact is a trap for competent but unagentic engineers 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.

jagged-chisel 1y ago
> Is “unagentic engineer” a euphemism for human/not-AI? I read this as engineers without agency - those who have little to no freedom to make any decisions on their projects.
Spooky23 1y ago
“Unagentic” is a terrible made up word to say that employees lack agency. 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.
stuartjohnson12 1y ago
It doesn't have to be that way, but that's certainly the default unless executives put in the work to make certain kinds of work legible. 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.

pydry 1y ago

This whole article could be boiled down to "it doesnt matter what you do it only matters what executives perceive you as having done". 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.

eXpl0it3r 1y ago

Is this sentiment the reason why a lot of "engineers" will provide terrible quality in code / tests (lack thereof) / documentation / etc.? 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.

spicyusername 1y ago
I don't think anyone purposely writes terrible code. You know the old standard: Never attribute to malice what is equally explained by incompetence But certainly stagnant conditions or burnout can prevent people from really putting in the extra effort. Why go the extra mile when it's consistently not rewarded, and in some cases punished? 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.
beezlebroxxxxxx 1y ago
More and more you run into people who simply don't care about craft and quality. 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.
- pydry 1y ago
  The chorus drones on about you're paid to deliver value and customers dont pay you for docs or tests or refactoring. If anything this is worse.
- ImPostingOnHN 1y ago
  > More and more you run into people who simply don't care about craft and quality. 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.

Palomides 1y ago

"once software is done, you might be tempted to maintain it, but don't fall into that trap!" seems like a bleak thesis to me

spicyusername 1y ago
They are implying that it is up to the decision makers to decide whether maintaining it is valuable. Never maintain it for "free".
- pphysch 1y ago
  most generally useful software is maintained for free

artyom 1y ago

Your work in a large tech company is done when your manager (or a manager two levels above) gets promoted. Then the cycle starts again.

nyanpasu64 1y ago

> What does it mean to get things done in large companies? Most importantly, it means finishing things. So that's why Google releases a new chat app every two years...

wpietri 1y ago

I fundamentally object to any notion of done-ness that is solely focused on pleasing the few people who happen to be in positions of power. 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."

virgilp 1y ago
I don't know. I'm 30 years into those 40 and, while I can list plenty of "achievements" ... that's not what got me promoted. There _is_ value in making bosses & 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.
- wpietri 1y ago
  We agree: There is value in making the compiler happy. There's value in getting tasks done. There's value in pleasing bosses. They are necessary means to an end. 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.
  - virgilp 1y ago
    Agreed - the better take is "getting promoted in large tech companies requires marketing" (and even that is only true for the senior roles, in the junior roles, being good at your trade is typically enough to get promoted to "less junior"). 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).

unwind 1y ago

I had to look up "skip-level" since my large tech company lingo was lacking. 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-level https://dictionary.cambridge.org/dictionary/english/skip-lev...

stepanhruda 1y ago
Skip level is your manager’s manager, presumably 2 is one further step etc
pitched 1y ago
You “skip” over your boss to talk directly to your boss’s boss. If the hierarchy is very deep, you can skip even more levels
deleted 1y ago
[deleted]

lolinder 1y ago

This piece appears to be a quick summary of a much better and more thorough piece by the same author that was discussed extensively a few months back: How I ship projects at big tech companies (1425 points, 381 comments) https://news.ycombinator.com/item?id=42111031 https://news.ycombinator.com/item?id=42111031

karmakaze 1y ago

The post is apt in getting things 'done'. I prefer to get things done. Of course I can't always just do what I consider important, so I balance them, I meet the requirements of 'done' without much more, and I spend more time than most getting important stuff done, sometimes things that take a longer time--I'll do the gardening so that it eventually gets done. 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.

davidmurdoch 1y ago

> they start delivering a stream of marginal improvements to a particular subsystem1. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most value they can to their company. 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.

hoseja 1y ago

enshittification: perspective of the camp guard

soVeryTired 1y ago

Simultaneously correct and devastating. Where I work, senior leadership don’t have a technical background and so don’t know when something is “good enough“. The result is that most of our products are dogshit and are force fed to users within the company and to its clients.

johngossman 1y ago

While I generally agree with this, I’d add one thing: to understand what your managers want, you really need to understand the business. At the highest level, how does your company make money, or at least think it’s going to make money? What other things does the company value? It’s surprising how often I find developers who don’t know, either because they aren’t curious, are too busy to learn, or (surprisingly common) think it’s somebody else’s job to make money…they’re just doing what they’re told. My advice is to actively try to meet upper managers, sales and support people, marketing people, and ideally customers. You almost always learn something you can apply. In big tech it is way too easy to be insulated from what the output of your job actually is. This applies even if you work on internal systems—-somewhere those systems either add value or protect the company, and understanding that helps get your job done. And if it turns out your group doesn’t add value, or you can’t figure out how it does, then start looking at what groups do add value and whether you can move there. I did a few jobs that were not clearly aligned with the company needs and those always turned out to be a mistake. The valued work not only pays better is (usually) more satisfying.

hnthrow90348765 1y ago
I think it's fair to think of yourself as a carpenter. Devs talk a lot about this being a craft. You build to spec but point out problems when the spec is not possible or silly. 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.
- johngossman 1y ago
  It just happens that two of my good friends are carpenters. And they are highly aware of the business. They have to be in order to ensure they have work as construction and remodeling and other types of work ebb and flow. It’s precisely when the layoffs come that it is valuable to understand the business. You are absolutely right that ideally the business people understand and explain the business, but are you really going to trust your livelihood so completely on that? Sometimes their job is to keep you working, fixing bugs, adding features, until they reach the point they can lay you all off (this pretty much happened to a bunch of my friends at an early job). Furthermore, just building to spec suffers from the Henry Ford problem of the customer asking for faster horses. Unless your business people understand the tech as well or better than you do, it is very likely you can improve the product more if you understand the business than if you just do what you’re told. This does not have to be very time-consuming, and ideally your manager helps, but just paying a little attention, spending some time with people in other disciplines, can have huge payoffs.

cljacoby 1y ago

I have mixed feeling on this. 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.

nickysielicki 1y ago
The solution to this is pretty simple: when you find yourself working for idiots, just quit. It’ll suck for a little while, and then it will get better. Which is much better than spending months trying to make stupid and under-qualified people understand things that smarter people would understand intuitively.
kylereeve 1y ago
On the flip side, when you have a manager who's genuinely on your side and wants to help you produce value (seems rare, I've been lucky enough to land one or two), "pleasing your manager" can accelerate career advancement and actually delivering working software you're proud of.

WaitWaitWha 1y ago

In my experience, the two most important things to get "things done" is the other part of that sentence, the "things". 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%20Fairy https://www.urbandictionary.com/define.php?term=Good%20Idea%...)

stego-tech 1y ago

While the OP’s post is helpful, I’d argue it glosses over several other, far more critical points that other commenters have touched upon here: * 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.

2d8a875f-39a2-4 1y ago

"Getting things done" means applying torque to one or more of the cogs in the corporate cash flow machine of which you are a part. 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.

cjs_ac 1y ago

> In large tech companies, this fact is a trap for competent but unagentic engineers. They see an infinite queue of tasks that they’re capable of doing, and they start delivering a stream of marginal improvements to a particular subsystem. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most value they can to their company. From the perspective of their manager and skip-level, they’re not getting anything done. 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.

nickysielicki 1y ago
> because it's not the responsibility of an individual contributor to attempt to divine the organisation's priorities: that's a core management function 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.

rzz3 1y ago

I don’t want to be negative, but writing a mathematical proof and planting a tree are about the worst metaphors I could possibly think of. Building a house is probably a better example for something that could be infinitely maintained and improved. After the bad metaphors, all the article really says is “do visible work and finish it”. This seems obvious.

jere 1y ago

> The easiest way to do this is to deliver things that they already know about, such as projects that they’ve asked you to do 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.

panny 1y ago

>Declare victory and walk away: go and do something else 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.

gwbas1c 1y ago

Yesterday I pointed out to the founder of the company that I work for, in the context of tech debt: "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.

cubefox 1y ago
Yeah. I would phrase it like this: 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.)
- gwbas1c 1y ago

deleted 1y ago

[deleted]

highfrequency 1y ago

> How can you finish things in a world where you can keep improving systems indefinitely? It means getting them to a point where the decision-makers at the company are happy. 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.

SanjayMehta 1y ago

I feel the author’s telling us to play politics without using the word politics.

pmarreck 1y ago

> If you want to get things done you can’t be a gardener. 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.

al_borland 1y ago

While I understand the point being made, and have experienced this reality first hand, I still object to it. 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.

antognini 1y ago
> 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. While I get what you're trying to say, if I can be a bit pedantic this is not more efficient thermodynamically. It is more efficient to let the house heat up and then bring its temperature back down.
- 1y ago

steele 1y ago

Shallow content slop red flags abound. Might as well keep moving the definition of done goalpost-- nothing is done until it provides utility that a customer exchanges money for. How about until there are enough customers are paying to make the system profitable? How about nothing is done until you hear it referred to as "legacy"?

dogleash 1y ago

I've been trying to figure out what bugs me about this advice. I think it's narrowly tailored to people with zero technical leadership on their project, but also doesn't give them enough groundwork to really succeed either. 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 skills of a senior, because they're in a vacuum with no seniors and their managers are not leaders. But instead it's the tiniest taste of the management world needed to orient someone towards being a better cog.

deleted 1y ago

[deleted]

RainyDayTmrw 1y ago

I strongly dislike "alignment" as a buzzword, and I think its existence is ipso facto an indication of our industry's dysfunction, but it nevertheless represents a legitimately important concept. You, your manager, and (to quote the article) some appropriate number of your skip-levels should ideally agree on what the most important next work items are. And to the extent that you don't, that's a problem for you as the individual contributor. Is this right? Is this fair? Of course not. Not in any moral sense, at least. But those are the cards we're dealt, and we play them as best as we can. The article is right that, on some level, we are paid to do what we are told to do. This is not a great outcome. Some of us are fortunate enough to have some sway in the opposite direction. This is the so-called "managing up" - another buzzword I strongly dislike, but again represents a legitimately important concept.

nspassov 1y ago

I continue to be amazed how the respect for the work of IT professionals gets lower and lower. This article attempts to reduce software development down to "people pleasing". A prostitute is also paid to make the "investors" happy but even people who've never hired one agree that not every demand by the "investor" can be fulfilled and that the prostitute can set boundaries. Yet, when it comes to software development, people such as the author of this article claim that the only true definition of done can be derived solely from the desires and wants of the business people (some of who tend to change opinions depending on what time they'd woken up). Imagine if civil engineers operated in this way.

d_burfoot 1y ago

This is one of a whole genre of HN-boosted blog posts that are basically saying to engineers: "you can't just write code, you actually have to do sales also". People who don't like sales think that they can go to a big company and just do engineering work. Nope, it doesn't work that way: you still have to promote your work, you still have to sell your work, you still have to talk to your customers, you still have to understand business, you still have to make deals, etc etc.

t8sr 1y ago

Would you rather work with (hire for your startup) someone who: 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.)

madmountaingoat 1y ago

I hope this was more of a philosophical musing than career advice. I've not worked at every big company, but I have worked at a few. I agree that in the context of a big companies, "done" is a metric; and career success at that big company depends on moving the metrics those leaders track. But in my experience modern big companies also look at peer review and if you're always committing junk, those reviews are not going to be kind. So like everything, it's a balance. Please your boss by closing tickets. Please your peers by writing good code.

ary 1y ago

> … it means delivering the kind of things that are legible to the decision-makers at the company: i.e. visible to your manager, plus 1-3 skip levels, depending on your title. The easiest way to do this is to deliver things that they already know about, such as projects that they’ve asked you to do, or incidents that are serious enough that they’re involved in them. It’s possible to make other work legible to them as well. If your work produces or saves money, that will make it immediately legible, for instance (or you could just be really convincing). By default, work you do isn’t legible: to the decision-makers, it’s generic technical nonsense. They don’t know whether it’s crucial high-impact work or pointless code reshuffling, and will tend to assume the latter. 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).

bluefirebrand 1y ago
I couldn't agree more. It really is important for developers careers to learn at least a bit of business speak, and try to learn how to frame problems in ways that business people understand and care about 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

conductr 1y ago

That’s all great but, how? 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.

Velorivox 1y ago

> The wealth of the mega corps does allow most goals to be accomplished, at great expense, with Just A Job workers, but people that have experienced being embedded with Really Care workers are going to be appalled at the relative effectiveness. —- John Carmack https://news.ycombinator.com/item?id=26170052 https://news.ycombinator.com/item?id=26170052

pphysch 1y ago

tl;dr: "fuel your career with technical debt"

csours 1y ago

I've noticed that people who are good at getting promoted are good at claiming success. Claiming success is not wrong per se, and getting promoted is not wrong per se, but sometimes the claimed success does not accurately represent value delivery. "Definition of Done" is a social exercise, not a technical one.

nine_k 1y ago

> If you want to get things done you can’t be a gardener. I'd say that you can be a gardener, but you have to periodically demonstrate the harvest.

uptownfunk 1y ago

Just ship or push to clarify reqs until you ship. Don’t let anything else hold you back (oh let me ask my manager etc etc). Clarify the reqs, get sign off and ship. It’s that simple.

akomtu 1y ago

Sometimes I think that the big tech corporations are soul extraction factories that only incidentally vacuum money. This article says, in essense, that millions of very bright college grads in the US fly to big tech hoping to make the world a better place, but instead their skill of recognizing truth gets perverted by corporate politics, and the sum of their work simply manufactures and monetizes addiction.

scrubs 1y ago

You want interesting? You want insight? Let's talk to the author here in 20 years, and review this question. In addition to operationally defining "get things done" and our own 20 years we can learn about, - why done means "some manager is happy" is just a silly definition leading to notions of things like customers, SQA/TQA etc.. - impediments to getting things done, which must be solved first - on grit: sometimes you gotta hang tough and do the right thing when the people you're helping are morons and reject what you do - towards defining what "value" is etc.

didgetmaster 1y ago

So, is this why the software world is full of bloated, slow, and buggy applications? Work on something just long enough to get it barely functional so the manager can check some box; then quickly move on to the next thing?? Sure, there is always a point of diminishing returns; but leaving something only half-finished will cause more problems down the road. I have been brought in several times during my career to fix something that initially passed some acceptance criteria; but later became unusable once the load picked up (massive data, more concurrent users, etc.). The world doesn't need just more apps. It needs many of the current ones to work better.

spwa4 1y ago

This article is committing a fallacy. The idea, that "decision makers" everywhere have: that there is anything at all that you can buy. It's not true. Even if you buy a stone, with the expectation that you can keep that stone ... requires constant payments for space to store it. Ownership, in the sense of owning something forever without further cost, doesn't exist. And the more obvious it is, the more people fight it. A car requires constant maintenance, tax, and work, and so does a house. You don't own them, and if you don't pay ongoing costs, eventually in most locations the government will either force you to sell or even pay for the destruction of your own property. But somehow making software must allow any idea to just be built once and then keep working, never to be touched again. Right back to ownership absolutism. I have built software in the beginning of my career that's still running, after 30+ years now. But most often, I find I have trouble convincing managers that they will be needing computers (whether onsite, colo or cloud) to run that solution if they expect it to do anything, never mind the occasional bugfix and/or system administration.

teeray 1y ago
The only things I can think of are those that would be unethical or illegal to deprive you of (e.g. a tattoo).

whatever1 1y ago

We need a spinoff system where big companies can easily offload legacy products that do not align anymore with the company’s direction / bottom line. Does it make sense for Google today to be building Wi-Fi routers? No. The entitlement is not there, superstar engineers would not want to work at this project since only marginal contributions are needed. Would I love to be an owner of a smart WiFi router company with excellent UI, integration with Google products, established sales and roadmap? Heck yes. There just seems to be so much red tape around these that companies prefer to simply kill such products.

rk06 1y ago

Honestly, i agree with this article. But i have seen a better article in past Article https://www.seangoedecke.com/how-to-ship/ https://www.seangoedecke.com/how-to-ship/ HN https://news.ycombinator.com/item?id=42111031 https://news.ycombinator.com/item?id=42111031

gnabgib 1y ago
You're aware this is the same author, and this copy is just a recycle of that 2024 article?

liampulles 1y ago

The best effort vs. boss happiness work I've seen is CSS tweaking work. Adding "delightful" transitions makes bosses very happy.