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.

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

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

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.

The negative side of this (rational) mindset is where 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.

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

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