Hacker News new | past | comments | ask | show | jobs | submit login

Ugh.

This article is not about “shipping”software.

It’s about pleasing upper management. Those are not the same things. The article even says it explicitly - if your users hate it and the market laughs, but executives like it, you’ve shipped. If you’ve given users the best software ever but your executive management doesn’t know, or even actively hates it, you haven’t shipped.

Blech.




I think the article does a very good job of defining the term "shipping" in the context of large organizations, where it you genuinely do need to please upper management - if you want further career advancement, in any case.

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 want to ship software without worrying about upper management opinions, go work somewhere smaller.

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.


It's much easier when 'upper management' is 3 individuals you can have a normal conversation with, than a hierarchical hivemind above you that does inexplicable things for random reasons.


People are also usually suddenly much more reasonable and cooperative when you're discussing something face to face with them and not through third parties :).


Even with a company of size=1, you have to worry about customers.


but those are hopefully much closer aligned to endusers than your upper management. Unless you make some ad spyware


Or anything for corporate use where the customer is a beancounter and the user is an employee, stereotypically.

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


It's also like this in small companies, like the one I work for, and I think rightfully so. One of the mobile app projects I was involved in got bogged down for months due to the lead engineer's need to refine and polish the perfect UX and architecture which kept breaking features we'd already completed. This cost us a lot of money and the product didn't look or function to an end user that much different. Management had enough and pulled the guy off the project because it just wasn't getting shipped and what he was doing didn't align to their goals. After he left i was able to tie up the loose ends and ship it live within two weeks. The only way i was able to do that is I knew every component of that system, our deployment infrastructure, our support staff, the real goals of our management team, etc.


> if you want further career advancement

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.


If end-users do like it upper managment notices it but it will take time, generally you iterate faster against upper managnent. Same kinda applies when end users dont like that stuff so you cannot lean too heavily to opticks game.


Yes this. Large orgs can just keep throwing mud on the wall until something sticks.

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


I think this falls under the category of "Don't hate the player, hate the game."

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.


There’s a hero element here that so think is what irks me.

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.


If a ship happens in the forest and nobody at company notices, did the ship really happen?

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.


> The reality is, most of the time when you “ship” your software, executive management neither notices nor cares

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)


Not necessarily. You can have upper management chieftains, who view the rise of a "new" one- as a threat and will actively try to prevent "upstart" new sources of income, to protect the dependency on "whoever" pays the bills for decision making.

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.


Search is not Google's golden goose. It's Ads.


There was a time, upto 10-15 years ago when tech company culture was largely anti-corporate.

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.


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

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


>The post points out that if the project launches and users love it and it makes the company a ton of money

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


I do hate the game. I hate it so very much.


I have seen the opposite happen a lot though, even if a project is successful you will get numerous people coming to you asking “who approved this? Why was I not involved in the decision?” And the ballooning aftereffects are why it takes months to push a simple button.

Big companies are like government bureaucracies now.


> 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


The only winning move is not to play :)


>I think this falls under the category of "Don't hate the player, hate the game."

The game wouldn't be happening without players.


Generally the game is created by external forces, not the players. If you’re an independently wealthy individual you can afford to work for pleasure. The rest of us? We like to eat and live in comfortable dwellings and take care of our families, so we play the game of pleasing our superiors in return for the money to live a comfortable existence.


Then you would expect to see inversion of behavior at the higher levels, especially at big tech, when one does become independently wealthy, but that's pretty obviously not the case.


So the players are just following orders and totally blameless for any actions?


I see your reply as strawman levels of uncharitable. They never said any such thing for either of your claims and the only reason I see for your statement is that you are playing.


The lack of accountability and introspection is frustrating, which is what I read from GP comment.

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


It's funny because this is the absolutely tell of someone who spent their entire careers in large organizations. I alternated between large and small, and it's incredible how resigned and compliant people who have been in larger orgs can be. At some point the absence of actual survival pressure creates a dichotomy between internal and external success, and only the former is important, as this article relates. It's so hard to fight the flow, that either you go with it, or you get jaded and desperate, and just leave for better pastures.

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.


how can it be any different? Someone else is paying you to do something; you either do it (aka, you please them), or you don't (aka, don't ship, and you stop getting paid).

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.


> how can it be any different? Someone else is paying you to do something; you either do it (aka, you please them), or you don't (aka, don't ship, and you stop getting paid).

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.


You can love it or hate it all you want, the important thing to internalize is that this is a feature, not a bug of doing things at scale.

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.


That is before a smaller and nimbler movement, company or entity surpasses the now large, slow-moving and fossilized incumbent, which then starts the gradual process into irrelevance.


And then the smaller, nimbler company itself scales to the point that it resembles the former incumbent, and the cycle begins anew.


People get hung up on this stuff. Getting things done in different environments is about understanding the constraints. The objective isn't to religiously follow some "ship" cult. The objective is to get things done. Or at least that's my cult. I have a friend in Amazon's logistics department. One day he told me how he was planning something that involved buying up the entire capacity of a local airfield. The thing with a long enough lever and a fulcrum is that these guys are moving the world.


Love it or not (mostly not), shipping software in large organizations requires navigating what the business and its leaders demand. You can try while ignoring leaders, but you'd be unlikely to ship anything.

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.


The article actually presents strategies for shipping, not changing the hearts and minds of management, or making great products. Shipping implies neither of those things.

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


I once tried to ship a product and nobody else was ready. Marketing assumed the product would be late and wasn't geared up to market it. The CEO couldn't point to a marketing campaign so didn't want to mention it at the conference. Support hadn't bothered to ramp up on it since marketing had told them it wasn't actually going to ship until next quarter.

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.


Executives are the ones who'll sign the cheques.

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


I think this article is much more than this.

  > First, you have to get clear on what the company is looking to get out of the project. 
You are not just pleasing the executives. Assuming the company described in the article is a good company. Executives are not idiot that making impulsive decisions.

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.


There’s a really interesting article that I’d like to read about the “first” - ongoing stakeholder management through the lifecycle of the project, the product and your time there all allow you to ship effectively (as far as the org sees it at least).

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.


Yet, that's how you sustain your job, get promoted and have more responsibility over time – large number of people don't seem to get this simple fact that your customer is whoever pays your salary and it's your job to make them happy.

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.


> It’s about pleasing upper management.

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


I'm unsure what your definition of 'shipping' is? If the users hate it then you didn't actually ship? How did users hate it if you never shipped?


It helps to have telepathic users who can hate software that you haven't released.


There used to be something called beta testers. You could actually see if users hated your software before releasing. For a small subset of users, of course.

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.


Just the use of the word "shipped" implies that software is an interchangeable commodity that rolls off a conveyor belt in a factory.

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.


Most commercially written software is closer to manufacturing than art. That doesn't satisfy everyone, I know, and I'm not here to judge people who don't want to work on integration #5 for widget #3 in order to unblock a million dollar contract from Foobar Inc. But that's where a substantial majority of the market demand for software development lies. The MBAs are paid precisely for their ability to channel the creative process of software development into the manufacturing slots where it's needed.

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


It's closer to engineering than either art or working on an assembly line. Software tasks just aren't fungible in most companies, and neither are they open-ended interpretable works designed to please or strike fear into the human soul. The average codebase is pleasing to me in the way an engine block or an oil refinery is pleasing. Q_rsqrt is pleasing in the way a mathematical proof is pleasing.


I’ve worked in engineering businesses, and SaaS scale ups and the “engineering” that gets done by SWEs had little to nothing in common with any of the engineering disciplines I’ve worked in apart from the E in the title.

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.


And yet building software is still closer to engineering than it is to charcoal figure drawing or to driving a forklift at a door factory.


When you ship it is arts and crafts which usually leans heavily to a small group of people Then if you want it to be commercial succesfully it needs some manufacturing practices because otherwise, you end up with legacy software.


I don't know why this post is getting down voted but the MBAization is truly it.

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.


The article does not claim to be about shipping software but about sipping software in Big Companies.


Maybe the author didn't feel the need to state the obvious - that once the executives like and understand what's being shipped, then they can confidently pull the trigger on expensive processes like marketing. Otherwise the feature or product could sit hidden and forgotten.

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


I'm not sure I agree with you.

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.


Well, of course. Because you can only ship the software your management wants. If you want to ship a software users like, go to a company that cares about it's users. (Or turn your company into one, but you cannot do that by shipping software your management doesn't like).


> If you’ve given users the best software ever but your executive management doesn’t know, or even actively hates it, you haven’t shipped.

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.


Shipping is ... milestone hit on program management.


Known as brown-nosing and prevalent where I work


It says so in the title: it's about shipping projects. This is about project management.


Exactly

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


Even worse, it misses the point. Shipping means you realize benefits for a target audience.

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.


... At a big company.


It's accurate though.

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.


Yeah, if you spent your life like this you kind of wasted it. I’ve noticed that HN has fewer and fewer hackers day after day. Not sure when they will change the name.


The number of "hackers" who think it's better for devices to be locked down by Apple because that keeps them secure (and freedom to install unvetted software is dangerous), and who think AI will replace us because we are all "statistical parrots" and just regurgitate what we read somewhere anyway is really astounding.

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.


I mean, it's basically been Startup News for People Who Like To Pretend They're Actually Hackers from day one.


Yeah, it's such a cynical take. I'm astonished that anyone here would believe this, much less write it up as a blog post and submit it to Hacker News.


> It’s about pleasing upper management.

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: