Getting things “done” in large tech companies

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.

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."

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.

> … 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).

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.

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.

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.

> 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.

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.

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.

> 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.

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.

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.

"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

> 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...

> 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.

> 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

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-lev...

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

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.

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.

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.

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.

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.

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.

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.

> 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.

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.

"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.

> 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.

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.

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.

> 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.

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

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.

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.)

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.

> 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.

>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.

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%...)

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.

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

> 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.

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.

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.

Honestly, i agree with this article. But i have seen a better article in past

Article https://www.seangoedecke.com/how-to-ship/

HN https://news.ycombinator.com/item?id=42111031

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.

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

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"?

enshittification: perspective of the camp guard

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