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.

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.

I've been trying to figure out what bugs me about this advice. I think it's applicable narrowly to someone with no 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 sills of a senior, because they're in a vacuum with no seniors or technically competent managers. But instead it's the tiniest taste of the management world needed to orient someone towards being a better cog.

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.

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.

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.

    Never attribute to malice what is equally explained by incompetence 

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

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

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

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

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

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

"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

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.

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.

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.

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

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

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.

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.

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

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.

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

A buddy doing sec consulting was once lamenting to me that the company wasn't taking his concerns seriously -- every genuine security risk that was raised during the gig was handwaved away. I googled the company and found their github repo.... and pretty quickly found that they committed some passwords that were never removed from git history. The moment my buddy shared this info with the company, they started taking him seriously.

Sometimes a lever doesn't look like a lever.

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

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

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.

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

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.

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

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