It's a bit cynical, but that doesn't mean it's not true.

If you want to ship software without worrying about upper management opinions, go work somewhere smaller.

You can still please end-users AND upper management at the same time. That's what I would aspire to do in that situation.

If you're a smallco you don't have that tolerance on margin of error, small fuckups directly reflect on your pnl.

Job advancement rather. Career advancement is possible by making users happy and telling executives at other companies "I did that". It's a better story if you had to fight for it.

Really your option is to work for yourself. There is no company of any size > 1 where you don't have to worry about owner/manager/executive opinions.

Or education, where it's possibly a politician or a government beancounter and a student.

I agree with you: It totally sucks that this is the way the business world works.

But if you want to work within the confines of this flawed system, you need to know how to navigate it well, and I think this post does a good job of giving you the guided tour.

There is a failsafe, however. The post points out that if the project launches and users love it and it makes the company a ton of money, then upper management is going to find out about it even if you don't tell them, and they will be pleased that you have made the company a ton of money.

The game wouldn't be happening without players.

I think it's fair to let them vent that.

The reality is, most of the time when you “ship” your software, executive management neither notices nor cares. Even if you get the “attaboy” from a manager, they will forget it 10 minutes later.

You ship your software because you care about work, and maybe because you care about your users. In a big software company, shipping is not going to get you noticed unless you are literally the guy delivering gmail or google maps.

your reality might be different than mine, but things that got shipped definitely get noticed because they are used as a bargaining chip for promotions, funding and for visibility of the entire team, that's one of the main concerns of a manager (unless they've checked out and are searching for another job)

To be clear, the pathway to management noticing is not you going around the building loudly blaring that you did a thing, it's that churn went down, or ARPU went up or CAC went down or uptime went up or something management cares about.

But the essential thing to also understand is that this doesn't just happen for free. Figure out what metric your ship is meant to affect, put monitoring in place and proactively notify those above you about how your ship impacted that metric. If you don't do this last step, you didn't ship.

You will not get a product thats not search off the ground at google.

You will not launch something else then windows / now cloud at microsoft.

Even if it makes money. The old chieftains domain has to wither and be in retreat first, before something new can be started with all the resources available.

Its really exotic, if cross domain success is achieved. Amazon logistics and then AWS is such a example. If you look under the hood, the companies that allowed for that- are often more conglomerates, basically smallerish independent companies within a brand-trenchcoat pretending to be one large company. Youtube is also such a thing.

My pet theory is, that its company internal value chains, the chieftains depend upon that allow for such things to form. Like search is advertising and needs data. And data comes from the engagement guys down the hall in the other building.

Now corporate-y things like playing office politics is order of the day in medium to large tech companies.

My (maybe uninformed) hypothesis is that tech made so much money that it brought in the MBA and HR types who brought their corporate culture with them.

Even the smaller tech companies are now mimicking big tech culture as the standard.

This is some strange engineer's fantasy, that every company was ruined by "MBA types". Meanwhile, as evidenced in places in this thread, "software types" don't even understand basic business principles. They like to believe that if they were just left alone they'd churn out brilliant product, as if a large business isn't far more complex than that. Someone needs to count the beans (MBAs) and someone needs to deal with the people (HR).

That's when all the people like the article's author crawl out of the woodwork and start claiming responsibility for your work.

Big companies are like government bureaucracies now.

Large organizations are, by definition, bureaucracies regardless of being public or private. Big companies were bureaucracies 100 years, and they will be bureaucracies in 100 years. I never understand why people expect private enterprises to be free from the inefficiencies inherent to coordinating lots of people and things

There's no way to engineer it such that you don't get to live in this reality. Be it tech companies, marketplaces, politics, revolutionary movements; once you reach a critical mass of people, all meaningful change looks like this.

It's about the customer recognizing the product as something they are ready to buy, which is associated with the dictionary definition for shipped "(of a product) be made available for purchase."

It falls apart slightly in that the customer technically starts buying the product on day one, while it is still just a glimmer in someone's eye, but "shipping" referring to the point where the customer says "Yes, that is what I wanted" is close enough to stay within the intent of recognizing something available for purchase methinks.

> If you’ve given users the best software ever

Of course, in context, the users aren't your customer. They may be someone else's customer, but that wouldn't be shipped by your hand. Your delivery is limited to your customer.

Almost all of us here has worked on a ticket that made us say "The fuck is this shit im working on, who will use this? Who the fuck came up with this?"

And we just work on it, take the paycheck, and move on to the next one lol.

That's not the reality with any software that actually matters, no matter how hard M.B.A.s try to abstract the human factor out of it.

Good software isn't manufactured. It's created. It takes thinking, and planning, and crafting, and all those things that are the opposite of a plastic widget factory that "ships" products to its customers.

Don't let then dehumanize the profession any more than it already is.

MBA practices cannot deal with uncontrollable production. But software engineering is utter chaos. So they try to come up with bullshit units that can be easily managed in their opinion. But it never works - aka, a nimble competitor always eats the giant in software.

The MBA style practice does work in factories and warehouses. But in software, a nimble startup with own the incumbent just be providing higher quality value.

(Even art, of course, is in practice pretty close to this. MBAs are paying you to sublimate your creative energies into a snappy video on how to sign up for Robinhood or whatever, and there are substantial business constraints on both its content and delivery date.)

Little comprehension about cost engineering, maintenance, safety, durability and resilience. Half-baked bodies of knowledge. CV driven development. Fads and critical production systems held together with spit, tape and hope. It’s like Aristotle’s Cave in our field.

You'd be in good company.

In my experience, there are plenty of people at BigCos who are more interested in covering their ass to ship nothing or the wrong things.

There also used to be alpha testers, i.e. your own staff. There's another subset of users and one that probably still can tell you if they hate your software today.

Also lots of "hackers" who measure success by how much money has been made, be it by a company or person.

I mean it may not be impossible to be a hacker and believe those things, but it should at least be a rare thing.

As an engineer, you can try to explain your perspective once or twice, but then you just go with what will please executives.

  > First, you have to get clear on what the company is looking to get out of the project. 

You need to be able to sense the company direction, communicate clearly, manage the risk, build the trust. This is not an easy task in a big company.

Such an awesome article IMO that explains the art of shipping in a big firm. I believe if any engs can master the skills described in the article, you will get promoted to a leadership role very fast. Of course, this might not be the path everyone loves.

Focusing on the tech and even product UX minutiae doesn’t typically get the headspace you need from senior management for rolling down tech debt, the headcountb you need to really ship useful and market leading software.

To go and call that "shipping" is a stretch in my opinion, it is only correct as far as your cynicism, semantic tolerance, or resignation to mediocrity can stretch. But with reduced perspective and a slight ego, it's hard to tell that things can be different.

If you dont want this, you'd need to become your own boss - in which case, you ship when you feel you've shipped! You can argue that this makes you more aligned with your customers. And i'd agree - you've made the customers your boss directly. So now, they determine if you've shipped or not.

So the only situation in which this is different (or still the same tbh), is if you're your own customer.

The good situation is when you get paid to do the thing, because you're getting paid by someone who cares about whether the thing is done. The bad situation is where you get paid to make a Potemkin version of the thing because the person paying with you cares more about the appearance than the reality, consciously or otherwise. You can redefine words and say well obviously when they told you to do X they were just doing an elaborate LARP and there's no deception in doing Y and telling them it's X, but that's just sophistry.

Working for arms-length counterparties helps, as that naturally forces communication to be more explicit and honest. Working in small businesses where reality tends to intrude more quickly helps. Of course neither approach is perfect.

> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. You can feel any way you like about that, but it’s true. If you don’t like it, you should probably go work for companies that really care how happy their users are.

It could be as well called “doing your job”. “Shipping” your job/work doesn’t seem like a stretch - especially that definition is clearly stated in the article. It’s also nice play of words that emphasises the fact that many people seem to get the rules of this game wrong.

Title would've been better fit "How I climb the ladder at big tech companies"

If the customer isn't using the software, it hasn't been shipped to them.

Enable someone to hit a revenue target, compliance measure, etc. if leadership doesn't care about that or can't work to that kind of framework; they deserve to go the fuck out of business.

Treating it as "please management" is incredibly self serving. You please management by often making them money; sometimes despite themselves.

The article also made it abundantly clear that if you find yourself in that situation, and you don't like it, you should find another job.

The article isn't about the ethics of the situation, career choices, ect. The rest of the article focuses on more important details about shipping software.

Give the article another chance. I skimmed it twice yesterday and now that I'm not reading my phone on the throne, I gave it the attention it deserved.

---

I should also point out that I've had a lot of career success in situations like this by disagreeing and committing. Turns out that a mild degree of patience in situations like this often means I get to focus on very clear customer pain points and build industry-leading software. (I just don't get to focus on them the exact moment I want to.)

It's not about "pleasing upper management" is about understanding that a product isn't "shipping" just because you can launch it the software. The entire company needs to be on board.

I think a better definition of shipping is ensuring your project meets the definition of done. At big companies, for many projects, I think there's an implicit requirement in the definition of done that management is aware of and somewhat happy with what you shipped. The resources used to ship a project (the time, money, and people) are, after all, their resources.

I feel like you're getting at the fact that you can build a crappy product that management loves and build something customers love that management hates. I don't disagree with that at all, but to me that's kind of tangential to whether you've shipped a project or not. To me at least, shipping isn't about it being good or bad, it's just about it being done. I think what the article is getting at is that if management doesn't agree that it's done, then it's not really done.

you think you've given users the best software...

people overestimate their ability to know what's best, and everyone thinks they are the exception.