This is great. I particularly liked this observation:
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!
Ya, I think this is a great insight. In today's world, code is not released as a versioned artifact sold on a disc or downloaded. The idea of "shipping" is fuzzy. You might be 100% in production with some change and it could still leave edge case, deficiencies, etc. You can decide to address them now or later. And it's all just perception. You can say it's good enough, we shipped, let's forget about this whole thing and move to another. Or you can keep ironing out the quirks.
I've "shipped" things in the past that were turned on to less than 1% of the time, and we left it at that, and moved on to other things. It was considered "shipped". Everyone was worried to increase it to beyond 1%, so we all patted ourselves in the back for the great launch and went to work on other things.
There was always something intensely satisfying about walking into some retail store and seeing boxes on the shelf containing CDs with software I'd written.
(On the flip side, there was that one time we had to destroy 5,000 CDs because they had a Quicktime Autostart virus on them...)
Sometimes it’s odd to realize there’s people that can say this while simultaneously not being my grandfather. There’s a whole period of computer history I skipped.
This is the reality. And if you happen to be in an environment with less cooperative folks, get your requirements to ship in writing, agreed upon, and as up front as possible. Hold them to it. Otherwise, it just opens you up for nitpicking, and in some cases goalkeeping, by folks whom end up delaying your shipping.
Yes but otoh that might be more of a “I refuse to accept a culture of optics on principle” kinda situation, rather than not understanding it. I liked the post because it’s honest and doesn’t put a value judgment on things, just explains how it works. It’s up to each and everyone to act accordingly, and one of those actions is to not participate in the lunacy that often arises in the higher echelons. Many people are fine keeping their integrity, mostly left alone to code, avoiding social deception games at the expense of not being promoted out of what they fell in love with in the first place. People are just different.
Refusing to accept a culture of optics is tantamount to not understanding optics though. The reality is that if you work on any kind of product, optics do matter - the perception of something working is often just as important as it actually working.
It can't possibly be "just as important" - in some cases, I will accept "almost as important", but any situation where the optics are "it works" and the reality is "it doesn't work" is eventually going to come crashing down on someone's head.
If it doesn't need to work, then it doesn't matter and the optics also don't matter. Of course, it might be more important for your promotion that the optics are correct, no matter what the ground reality is, and the crash could come down on someone else's head instead of yours, but in this scenario someone who is against a culture of optics rather has a point.
"Appreciate" is a weird word. At least for me (not an English speaker) it has a positive connotation so with that in mind I sure hope nobody appreciates the importance of optics. The concept is dumb but it is important and we have to play the game to achieve anything.
Why did you read that as 2 though? Is there a context clue I'm missing or is there some grammar rule I don't know of? Honest question, I'm Polish.
For me there's a huge gap between 1 and 2 so it might cause misunderstandings when used in a sentence. I despise a lot of things I fully understand and if I said I "appreciate" them - sounds weird.
It's heuristics, not grammar. You usually appreciate a noun or noun phrase in a transitive sentence (X appreciates Y).
Case 1: If it's something useful (e.g. 'your help', 'what you did') then it's more likely about being thankful.
This use of 'appreciate' is also a social action. You say it to make someone feel good for helping.
Case 2: If it's an abstract thing (e.g. 'the importance of', 'the difficulty of') then it's more likely you're talking about understanding.
Usually when you talk about this usage it's because the _fact_ of understanding is important to the speech act. If someone explains the law of gravity you don't say "I appreciate that", you say "I understand that". But if you fell from a height and hurt yourself you can say "I didn't appreciate the law of gravity".
Case 3: If it's intransitive and it's about money ('the car appreciated in value', 'the house appreciated in value').
It's a pity that heuristics are not mentioned in most language books or dictionaries. At least I wasn't taught any in school (10+ years ago). This should be next to the word definition.
Similar is "enjoy", which is almost always possible but sometimes can be used in a more... detached sense? "Perspectives in nature we rarely enjoy" as seen in The Far Side here, for instance.
Optics are not dumb. Corporates are very noisy. It is difficult to extract the signal from the noise if you're not working on a project full-time (as most people are, except for you, the tech lead), and it will definitely not happen by accident. That's why you need to manage optics.
I agree that they are very important but I still call it dumb in a "it's stupid that we have to do this because we suck as a human species" kind of way.
I think that's what the word "appreciate" is hinting at in the phrase: "most engineers..don't appreciate the importance of optics."
Optics is subjective and often superficial, a performative illusion for the sake of whoever is looking at you. But that doesn't mean it's not valuable or useful in a social context.
Here, I read the word "appreciate" to mean, to recognize the value of a thing even if you disagree with it.
For example, someone could be a pacifist and still appreciate the need for weapons for national defense. They may not agree with the means but still admit it has value and effect.
Weirdly, optics have never mattered at all in small or startup companies. And they manage to do pretty well, ship a lot of product and become large companies.
Maybe the problem isn’t the engineers, but the need for optics…
It's a matter of scale. "Optics" (as a separate concern) don't matter at orgs that are small enough that everyone can see everything (and/or has full trust in the people who do). Visibility and trust don't scale, hence the necessary evil of pageantry
It definitely gets worse as the organisation grows. There isn't much room to hide in a five person company whereas it's hard to be seen in a 5000 person organisation.
The emotional perception of the quality of you, the worker, in the eyes of the leadership who pays you. It is distinct from your true value and contributions. It is maximized by you optimizing the visibility of things that boost reputation and minimizing the visibility of embarrassing things.
It's a term that has been adopted to sound more professional than "keeping up appearances" which is an age-old concept. It is about how things are/will be perceived by others, rather than the truth of the matter.
There is a tendency here to pattern match the advice in this article with frustrating experiences about office politics. But I dont see this as a post about politics.
Rather, what I got was that the spec is an incomplete description and there needs to be more inquiry into how the software is going to be used. This can require a little bit of 'going up the stack' to see how business need relates to the software requirement(single enterprise customer with a precise requirement, acquisition of new customer, software for some internal vision of CEO etc). Compare with a startup where one doesn't even have a spec and one is trying to find a product-market fit or when developers take sales calls and find new insights on how the software is actually being used.
A completely broken spec is indeed a failure in management process. But, in general, it helps a library developer to think beyond a library spec and see how it is being used.
Yes. Unfortunately, it comes with a side effect, you will see leadership use this to kill projects they don't like by not never mentioning them until people think it's a failure.
If you are working on something the people deciding on the size of your paycheck want to kill, time to find a new project or a new company. Why fight a battle you're sure to lose?
If only you could figure that out ahead of time. I've been on projects that were killed with no notice anyone could see even in hindsight. I've been on important projects that senior leaders decided to out source my job to China and my boss was forced to let me go. I've seen budgets run dry many times and important projects got killed/cut with no notice (sometimes there are signs that but you think your project is important enough to escape the cuts until it isn't). Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I've also seen people make careers out of taking over projects cut for the above reasons as customers still demand support. I've seen many downturns where my project was important enough to not be cut.
I've seen many downturns where my project had massive cuts, but I personally was not the person cut. Most often projects are not killed outright, instead they go through a long down spiral (not always, but typically) and you can make a lot of money being the expert on a product that is making money if you are able to hang on. Someone needs to leave as there isn't the budget to pay everyone, but that someone need not be you. Often these projects pay very nicely for working 9-5 with no pressure to do overtime.
Note that it can get trickier than it sounds. (Well, I don't know about big tech, but at least for medium and smaller.)
You need to figure out who the "important people" are, and somehow make sure that they understand and buy into the product definition, delivery dates, etc.
Even if they're 3 levels up from you, and you can't normally interface directly with them, try to find a way to double-check that all the "important people" are on the same page.
Organizational dysfunction happens, and you have to succeed despite that possibility.
In my experience, most things in large companies are social constructs. Good things are good because they were decided to be good, bad things are bad because they were decided to be bad. Very rarely are they driven by actual metrics.
This post is about corporate politics, not "shipping projects." To wit:
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.
When the stated goal is to make leadership happy and not solving customer problems such that customers are "happy", that is pretty much the definition of politics. As subsequently identified therein:
Engineers who think shipping means delivering a spec or
deploying code will repeatedly engineer their way into
failed ships.
I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
Like everything else, writing code doesn't exist in a vacuum.. There will always be interconnected constraints and requirements, and you simply cannot "deliver a spec" and think that's all there is to it.
And that has nothing to do with ethics.. The spec is outdated by the time it makes its way to you, and odds are it was flawed from the start in some way.
And again this isn't because someone is bad at their job, it's because the business reality and conditions are constantly changing.
And so someone needs to be keeping an eye on both of those things and steering the code delivery parts of the work to stay aligned with those changing business conditions.
To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
> If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
Have you ever worked at a big company? The level of dysfunction that can be sustained over years or decades at a place with decent market foothold is staggering.
Sure, take a worse-case interpretation of my words, this is the Internet after all.
We're all posting short messages here, not essays.. There is so much room for choosing to interpret each other in different ways.. So it's inevitable that we'll be misinterpreted sometimes.
And yes, I did try to reframe to better make my point, because I do think I'm right.
Welcome to HN, but a word of advice, this kind of snipey low-value shitpost is typically not welcome here.
> To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
To look at a concrete example, with the quality issues Boeing has been having in the recent years, we can claim "happy leaders" diverged from "happy customers".
Yet Boeing will still be around for a long time, and failures can be catastrophic. Whistle blowers who came out since can be said to have advocated for "happy customers" against "happy leaders" but were suppressed.
When the stated goal is to make leadership happy and not
solving customer problems such that customers are "happy",
that is pretty much the definition of politics.
This has nothing to do with "writing code", "outdated specs", "people being bad at their job", or changing market conditions.
It is a decision each engineer makes when performing their job.
Ethics are not situational. An individual either values and adheres to them or does not. Specifically excluded from this position are mistakes people make and then strive to not repeat, as no one is perfect.
Fair enough! I see your point.. But then I would submit that this is too narrow of a view to take in a complex interconnected enterprise, and that anyone who works this way will end up more behind than ahead.
I'll stand by my first line that nothing exists in a vacuum.
If you only make decisions in isolation or without broader context, whether based on ethics or otherwise, then you will inevitably make the wrong decision, I would argue, more often than not.
Context matters, and the same decision made at different times and in different situations can have completely different outcomes or impacts.
What if "making the customer happy" costs so much money that it puts the company out of business? Do you still focus on only making the customer happy?
What if you have to piss off your customers, for a period of time, to save the business so you can get back to making the customer happy eventually?
Or a less dramatic scenario, what if making the customer happy makes your co-workers' jobs hell, for reasons outside your, or their, control? Is customer happiness then still your singular focus at all cost? Because then you're a shit co-worker in my view.
Is your only responsibility to the customer, or do you feel any responsibility towards your co-workers and/or their jobs & livelihoods?
Life and work are messy and complicated, and everything is a series of trade-offs.
100% agreed.. But I still believe that over a long enough time horizon, enshittification will take those companies down. Value extraction is by nature a limited time strategy.
Most companies who choose to do this are taking advantage of a period of market or segment domination where they know users don't have good alternative options, and will tolerate some level of garbage because they still want the service or product.
Note that highly competitive industries or market segments typically don't see as much enshittification...
It is not always a yes or no. “Executive high leadership” can approve of 60% customer friendly stuff and 40% bs. And if some engineer is pouring his heart and soul to make a x% good thing that would be a benefit then it might still be rejected or worse, if engineer is in bad terms with managers he has pretty much no chance.
> I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
This too harsh. There's nothing unethical about delivering what your manager tells you instead of what you believe the customers need. Going rogue — as opposed to doing what you're told — is not necessarily the ethical choice.
IMO there are enough "not particularly ethical" tech companies are out there that we shouldn't be giving awards for blindly doing whatever your corporate overlords say. You have a choice every day what you contribute to the world.
The problem is if you deliver something and the people it's meant to serve don't know about it, or can't use it, or it doesn't actually solve their real problem, you didn't "ship" in the sense the article is talking about.
I suppose it's possible to pass all those thresholds and management still doesn't like it. But it's important to ask yourself if that's really the case or if you did something wrong and failed to ship something fit for purpose.
Exactly. This is basically "enshittification" [1] in its truest form.
Look at Boeing for example, I bet leadership was very happy with the fat stock bonuses and I also bet a lot of engineers "shipped" products following the author definition of shipping.
So much so that the "if it's not Boeing I'm not going" became "if it's Boeing I'm not going".
Personal take, but if you are only playing politics you are a politician and not an engineer.
you work for the company, not for your abstract imagination of what users want. if you genuinely feel the company isn't aligned with users, then try to change that.
it's not unethical (per se, obviously don't build bombs for them) to please your employer.
In the Military, soldiers have an ethical duty not to follow an order that is illegal. It is called duty to disobey.
In civilian life, you have a duty to disobey if what your employer asks of you will unnecessarily harm people. For example, shipping a broken insecure product that handles PII/PHI/etc is absolutely unethical, and possibly illegal (though often the legal consequences are minor, if not irrelevant). Your bosses will absolutely ask you to do illegal and/or unethical shit, so you always need to be aware of where the line is, both legally and ethically.
It's not always clear where the line is. With AI work, the line has already been crossed several times (things like discrimination in output resulting in innocent people being hurt). Do not do whatever your company asks for. Do push back when you see a problem. Don't ship something that could hurt someone. If you're not sure, ask or find out.
Ethical is not the same as legal. Legal actions can be unethical and ethical actions can be illegal.
The Nuremberg trials established this after WW2: just obeying orders is not sufficient [0]. This is why modern militaries have a duty to disobey.
It's the same in civilian life: you have a personal duty to disobey an instruction that you personally consider to be unethical. You cannot hide behind "I was just obeying the law". You absolutely should break the law if you consider that law to be unethical. It is your personal responsibility to decide this.
So yes, you should do illegal stuff if not doing said illegal stuff would be unethical.
And, putting it that way, a legal duty not to follow an order that is unethical.
My point is that us Software Engineers have the same duty, in my opinion. If some pointy-haired boss tells us to build something that will cause misery for our users, I think we have an ethical duty to refuse to do it.
I've been in a really stressful position for the past 6 months. Things that I would've walked out over a few years ago are now things that, for various reasons, I kinda have to choke down.
My entire concept of "what is ethical?" has undergone a transformation. It's not about my ideals any longer, or about feelings, or about how gentle or aggressive management acts in negotiations. It's about much deeper things-- like when I'm asked to support something I find distasteful, I need to really investigate whether, in context, it's actually something which violates my conscience. You know what? It almost never does.
These are the two questions that matter most in my view: 1) Am I honestly being required to do something that harms someone worse than the status quo, and 2) Is anyone around me having a medical emergency - including certain serious psychological issues - that I can help with? Aside from those two things, there's a lot of ugly crap that you can still keep trucking through.
Many people, particularly (but not only) younger ones, are oversensitive to things they simply don't like but that aren't actually wrong in any major way. You've got to choose your battles.
That seems like a very narrow-minded view of the role of engineers in society. At the end of the day we aspire to solve problems that make the world better—I'm certainly not going to fault individuals for following the money, but to dismiss the ethical dimension completely is unreasonable in my opinion.
The Company is an imaginary construct. The reality is that there is a group of people with common goals who work together towards those goals. Very often those goals are simply making money by any means possible. Working with them doesn't absolve anyone from responsibility.
Oh boy. I've been around these trenches long enough to have seen the dark side of 'shipping' strategies.
Rarely in large enterprise environments are projects greenfields. The new system is often there to replace some existing Line of Business system.
Inthese cases the pervers but common shipping strategy is:
1. freeze all maintainance and evolution of the existing system. Seems reasonable until you realize that these enterprise projects are multi year calendar endeavours and the business will not stop changing during that time. The idea is not realy to halt all development, just to inctease the friction of getting anything done on the now declared 'legacy' system above an administrative pain threshold.
2. Commandeer all the IT staff to serve on the 'new' system's project team and overwhelm them with tasks. Make sure they remember any time spend on the 'legacy' (keep hammering in that term) codebase is basically waisting time assuring you'll end up at the bottom of the corporate dinosaur tar pit at best.
3. Force they 'new' system into production long before it is ready. Use all the leverage you build from point 1 to promise 'going forward'. When essential gaps to support the business are pointed out en mass week1, reverse the tables and intigate a very heavy administrative process demanding proof that the lacking functionality is actually required with a full ROI breakdown coutering your handwoven 3 minute overinflated guestimate for implementation. Again, you know essentials are missing, you are just trying to gain time as the longer you can stay deployed the higher the chance you will.
This process is very destructive to not just the business, but also moral of most involved. Most projects taking this scorched earth shipping strategy fail regardless. This is no small contribution to the cynicism oftem found in veteran battle hardened corporate IT shops.
Eventually someone important gets a call from a more important client on the golf course about how his company fucked up on his watch, the new thing is cancelled, the old one is reinstated (to much rejoicing) and the 15% of the huge new effort that actually worked is distilled in to a plugin feature and bolted on to the old product and everyone moves on.
The original PM responsible for all this gets an L+1 diagonal promotion at a new company and pulls this shit again.
PMO never comes out of these debacles worse off, even if the project burned dozens of millions with 0% result. It is never their fault, there are plenty of scapegoats around, preferably smaller external contracters. The threathened lawsuits with the big contracters get settled and kept hush hush as neither party wants the bad press. Just the cost of doing business for them.
Most of the time project leads can stay with the company in another division as tension with the old IT crowd woul be a bit much, and even get promoted as they 'gained experience'.
*In my experience, projects almost always ship because one single person makes them ship. To be clear, that person doesn’t write all the code or do all the work, and I’m not saying the project could ship without an entire team behind it. But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.*
Yes that is pretty much what I see as well, I see how things go to nothing with wrong people who think they can make bunch of requirements and dump them on dev/qa - then be surprised nothing works - and also how much stuff I try to hand over ends up not happening despite people claiming that they are very motivated to pick up a project. If they are motivated and I see nothing happens in 3 weeks I just take it over again and don't even talk to the guy anymore.
I am also quite often seen as an asshole because I don't ask "everyone" for permission and mostly care about my actual boss.
Whenever an architect leaves a company I work at, it is definitely felt. If your projects aren't silos then you need someone to glue everything together. You wont ship the same, and you will likely make more mistakes and everyone on call stands around confused, because nobody is there to provide technical guidance because everyone's trying to figure out how their own islands talk to yours.
The "one single person", should be qualified with 'is senior enough or with enough authority' which allows them to set aside a lot of squabbling, bureaucracy and bikeshedding.
> I am also quite often seen as an asshole because I don't ask "everyone" for permission and mostly care about my actual boss.
This speaks to me, I have often been told that I'm supposed to get "permission" to launch something from product, from my boss's peers leading other teams, from customer support, from design, from pretty much everyone. When pressed, there's never a realistic justification as to why (for example) a designer who hasn't touched the work in months should be in a position to approve a launch.
> If they are motivated and I see nothing happens in 3 weeks I just take it over again and don't even talk to the guy anymore.
I like this sort of no bullshit attitude but at least tell the guy "I'm taking this back". Hard for your boss to have your back if you don't even say anything.
I actually meant "I am never talking with him about handing anything over" and "I am not going to ask 10x if there was no visible progress after they were swearing to pick it up" but other than that I will update the person that I am picking up tasks on my own and making progress on the thing they were "taking over".
I physically cringe when I think of some of the things I said to my coworkers when I was fresh out school and definitely knew what I was doing and had a much better way of doing things and they just didn't understand.
I do think it's sort of a rite of passage, especially for the dorky socially awkward kids like I was who all of a sudden have a real job and don't really know how to interact with people.
A lot of us were that. And now that we’re senior we have to recognize it in the youth and guide them to maturity instead of firing them, as our seniors did for us.
there's no reason to believe you're now relatively wiser compared to 10 years ago than 10 years ago compared to 20 years ago :/ which is why in another 10 years you'll probably think how stupid it was to believe you can guide a young asshole and should instead have just fired them. just speculating.
If you're not relatively wiser than you were 10 years ago, what the hell have you been doing the last 10 years?
I don't think you should automatically give younger folks a pass for stuff like this (I don't think the GP was suggesting that, either) but it's also probably a good idea to approach working with a 22 year old a bit differently than you would someone in their 30s, and both differently than you would someone in their 60s.
This is a reasonably good if somewhat depressing blog post about how to do well in the performance cycle at a big company. Now part of that is shipping product, but that’s pretty clearly of secondary concern for the author.
It sounds to me like this person is good at getting paid no matter how it goes for the shareholders or the rest of the team.
When I worked at a big company I did a lot of mentoring and the dissonance between what people I mentored thought was the "right thing to do" and what it seemed like the organization wanted them to do (enforced via performance reviews or other mechanisms) was a huge hurdle for new engineers. Especially early in your career you're just one engineer in a huge org and most people eventually decide it's easier to go with the flow than fight against it (or they leave) but it was a struggle for people to get there.
This post seems the logical conclusion of that. Why spend your time and stress doing work that your boss doesn't appreciate? Just give them what they want, it's their job to align that with greater organizational goals.
All this being said I did not love working at a big company, partially for these exact reasons.
Not sure if / who am I quoting, but this thought isn't my for sure: the more layers of management the company has, the more times the incentives are inverted between the planning at the very top and the implementation at the very bottom.
It does often feel like Chinese whispers to the people at the very bottom: the orders make no sense whatsoever due to the distortion coming from the middle management. And, I totally agree with your assessment that OP sounds kind of sarcastic about the whole thing. Also the way they phrase it suggests it: it's not even what your boss wants, it's what's going to make your boss happy (if the boss is an idiot, they might want things that will end up making them feel sad, but that only makes your job harder as now you should also anticipate what would actually make them feel happy rather than dully following their advice.)
> I don’t see how you can achieve any meaningful goal without collaborating with people in power.
Depends on how you define meaningful. Raising happy & healthy kids, helping someone in need etc, can be meaningful to many people, but don't require 'collaborating with people in power'.
But it does. At the very least, you need to keep paying off the people in power and do everything within the framework of their rules, otherwise you’re in trouble
there is no "off grid", and even then those homesteaders aren't building houses themselves with tools they crafted themselves -- they're 100% dependent on tools and skills they learned in society.
even remote and rural they're often still trucking into town weekly for gas and groceries.
source: in laws in rural AB tried homesteading off the grid. all it meant was that their kid was homeschooled and can't do multiplication and they learned how difficult farming is.
Not really. It's just that people don't realize how much they rely on modern society. You could go all Primitive Technology and go live in a mud hut somewhere or whatever, nobody's forcing you to buy toothpaste and electricity and all that stuff.
The problem is that sucks, so people don't actually want to live off grid. They just want to not work but also get the benefits of modern society.
I'm fairly certain statistically you can't, because you need a place to go do that, the skills to pull it off, and have a family that's not only willing but actively supporting it, otherwise when the reality kicks in everything _will_ fall apart. Either that or some of you die. But hey, technically you'd be correct in that case.
Or maybe I just have a gloomy view of what "living off the grid" looks like :] I'll just leave this [1] here, regarding that.
I did not get that from TFA. I interpreted it as "know your customers and communicate with them". This applies to everything in life. It's especially relevant in big companies because it's easy to forget that you are forgettable.
I mean, if by "customers" you mean "the important people at your company".
> Concretely, that means that a project is shipped when the important people at your company believe it is shipped. If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship.
> 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 mean, if by "customers" you mean "the important people at your company".
I think that's exactly OP's (and TFA's) point: If you're working in most medium sized to large sized companies, just look at your org chart. Your manager, their manager, their manager's manager, and so on up to the CEO: Those are your customers. They are the ones that decide your comp, they are the ones that set your priorities and goals, they are the ones who are ultimately accountable when you fail or succeed. Your job is to deliver what they want. It's definitely a hard pill to swallow if you still have that idealistic view that you're working for end users.
You're not wrong. I think the issue people have with the post is that it disguises, to exaggerate a little, bootlicking with shipping. The recommendations are good for the reasons you mentioned, but job security or compensation maximisation are not the same as "how to ship things". If that happens to be the thing you do, it's a means to an end (to demonstrate you do your job well) but that's not the goal of shipping things by itself
But then, definition discrepancies are the origin of at least half the disagreements
I mean, being misaligned with company leadership is a great way to loose your job. I worked at a medium sized company which is known for having a good culture. Everyone was kind & helpful, there was loads of autonomy, never any kind of layoffs.
At some point, a team I worked closely with got unexpectedly fired. The entire team, including manager, just gone one day. Not for financial reasons, but because they were “not performing well.” (There were multiple people on the team who had consistently good performance reviews.)
I spent a fair amount of time trying to figure out why that happened. Obviously if that could happen to them (fired despite good feedback), it could happen to anyone.
As far as I could tell, it’s because the CEO or CTO didn’t think the type of work they were doing was worth doing, and also didn’t think they were making a difference.
It’s good to be a self-starter, to advocate for best practices, and to keep users in mind. But at the end of the day, if that doesn’t fit into what your bosses expect from you, you’re done.
That’s why it’s important to communicate with stakeholders. Your boss needs to understand why spending time on preventative maintenance pays dividends on the long run. You can’t spend 75% of your time on stuff that doesn't look productive (which is subjective) and also not be proactive in being on the same page as your stakeholders about what’s important. At some point, they’ll get confused about what you’re actually doing day to day, and your job’s on the line.
> As far as I could tell, it’s because the CEO or CTO didn’t think the type of work they were doing was worth doing, and also didn’t think they were making a difference.
So the CEO/CTO weren't able to express their concerns and priorities and instead just fired the whole team?
If, as you say, there were no financial reasons, then the team could've been re-purposed to do more meaningful (at least in CEO/CTO eyes) work.
You are coming from a rational position with the focus on optimization. Large organizations are not rational, and rarely optimal.
Executive backlogs are so deep that purposefully re-fitting whole team to another job will never end up on the top list. You might see sometimes organization will rehire a whole new team with exact same skillset, and set them to do similar tasks. It happens because execs know how to setup things from scratch quickly, but running a re-fit is a custom project that requires problem solving and large amount of exec drive, and exec resources are extremely scarce and expensive.
From the outside this will seem totally irrational and suboptimal, not to mention unfair. But that's how large orgs operate.
IME working as a team in large companies is dangerously entrepreneurial. What I mean is that there is loose guidance on what needs solving and then it's up to you to figure out how to solve using what you have. If you stray from the original problem too far, you'd better be good at explaining why. It's dangerous because there's a lot of autonomy with the illusion of security.
Keep the original problem in mind always. Keep your head up looking out for competitor teams who might be solving your problem. Know them, align with them.
If you show up on an exec budget spreadsheet and the exec can't defend your value, then you're toast (or transferred).
Now imagine, the product being 50 % income generator at start, but a liability generator of support cost in the long run. Means, you launch the product and its success kills you over time as a bloated giant. All we ever had todo, to be more succesfull, was sell more of the product... famous last words
do you have an example of this scenario? I mean reading it, sounds true but then support is mostly determined by the company's willingness to support (outside of some legal requirements) and so I find it actually difficult to imagine where selling more of the product is a great income generator but the support actually kills you (destroys company) in the long run.
In software at least support costs can be decreased by fixing bugs or identifying high support low value features.
So - I would like to see a company that actually got killed by support costs but was doing good from product sales.
I think most social media counts as such, with the specific example in my head of Twitter only making a profit two years before Musk bought it, cut it to the bone, and increased its legal troubles.
Income starts off proportional to number of users and how much they use it.
Support depends on how many people are anywhere between unpleasant and unlawful.
"Unpleasant" is like weeds, if you're not keeping up they take over and keeping up becomes harder.
"Unlawful" can suddenly get a lot more complex when other legal jurisdictions notice you and (sometimes with or without changing the law because of you) remind you that anyone operating in their jurisdiction must follow their laws and not whichever one you put in your T&C — constitutionally guaranteed freedom of speech in one country can be constitutionally unlawful speech in another.
> It sounds to me like this person is good at getting paid no matter how it goes for the shareholders or the rest of the team
The trouble is that your personal influence is remarkably small in most workplaces. Ultimately, you can't change much, and what you can change takes a lot of effort. It often requires being bullish, which can introduce risk to your job.
Sometimes, the choices are as follows: either have the big idea in mind and always strive for the best, sacrificing your mental health, making enemies, and potentially losing your job. Or, keeping your head down and following orders, being a perfect little sailor leading your ship towards the iceberg.
He is probably good at getting paid and getting credit for what he does, but he would need to be good at it to do any good for any other stakeholder, even more than he would need it to be a happy parasite inside the company. We don't know from the text if he cares about benefitting other stakeholders; I would bet that he cares more than average or he would not openly admit various unsavory facts about how things actually work - there's nothing in it for him to be open about it and the typical bigco parasite is unlikely to be open about these things and instead will repeat the party line about the place being a perfect meritocracy.
This mirrors my views. In sports, winning fixes all problems; in software, shipping solves all problems. You need wins, and you need to ship. It’s like in Glengarry Glen Ross: instead of “ABC—Always Be Closing,” it’s “ABS—Always Be Shipping.”
You’ll never ship a perfect product; no such thing exists. But if you ship early (and incomplete), users will be delighted—and often change their minds about what they want. That’s great, because you didn’t spend forever on their initial (flawed) requirements.
This is called project management, and in my experience seems to be a practice/discipline that's often overlooked or ignored at startups and scaling tech companies.
Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working.
Doing this in an agile manner generally means smaller projects, one at a time.
The last "agile" shop I worked at instead did 10+ small projects in parallel (1-2 devs per project) and then wondered why we never got to where we wanted to go.
In contrast the last really fast-moving place I worked at has 1-3 devs per project but they were entirely 100% in charge of technical design, building it, shipping it, and maintaining it. If we wanted to wait to ship, we waited. If we wanted to ship early, we did it. I'm in an org 3-4 times the total size now and we move at half the speed.
That sounds great for moving fast, but not so great for sharing and keeping info about these projects. If/when someone quit, how would their projects get split up for other devs to maintain?
It definitely had its downsides especially for the 1-dev projects. In reality it wasn't that bad. Code reviews usually pointed out where documentation was needed or would be helpful, and everyone was just senior enough where you could give them a feature ticket on one of these small projects and reasonably expect they'd be able to just figure it out if they had to.
Outdated or missing critical documentation, or too junior (or too lazy) coworkers would definitely have made this approach fall apart and that's a big risk of it IMO.
Which is precisely the opposite of the entire intent of Agile. Take one small thing, get it done. Done done. Then decide what the next thing is, then the next, based on what you learn from that one thing.
Unfortunately, too many people can't be arsed to actually understand things like the OODA loop, Cynefin, and the other things that describe precisely WHY that is a good idea. But hey, they do standups.
One place I worked at did that + only 1 person per project and all projects got rotated between developers at the start of every week on Monday.
And when we did stand up meeting every morning nobody cared what anybody else had to say cause we all worked in different projects. Go figure.
Maybe not the rotate projects bit but I’ve worked on plenty of teams where everybody is doing something different. Sometimes it is because they are spread too thin other times it is because each project individually can’t really be swarmed on and is really a solo adventure.
Rotating between each project on a weekly basis, however, that seems awful.
I don’t think I’ve ever worked with a project manager who wasn’t a total pseudo jobber. That is to say, I have worked with some wonderful project managers, but they got things done rather than “manage projects”. They’d be hands deep in Active Directory, weird json stuff to help find issues with OCR or working on change management and training when a new system needed to be adopted. But the whole “agile” side of project managers, scrum masters, IT business partners and so one have always just gotten on the way.
Usually what happens is that they become middlemen that can’t actually relay information between developers and the businesses. As a result developers and digitally inclined business people tend to talk to each other directly while they let the pseudo jobbers waste everyone’s time because… because it’s “best practice”.
Hah. Especially rich when you consider that the whole “agile manifesto” was thought up and sold by people who haven’t worked in software engineering since 20 years before Python even existed. Of course it doesn’t work. Not because any part of it is particularly bad, but because every part of it is extremely vague and completely unfit for reality. If you follow any sort of practice which isn’t YAGNI religiously you’re going to fuck up.
Projects ship because one of the people who do actual work gets fed up with all the bullshit and simply does what needs to be done. All the “project managers” and other role players are only there because SWE management is full of people who can’t code anymore. You don’t see all these pseudo jobbers in IT operations, and you don’t because SysAdmins want to be SysAdmins.
This may shock you, but companies actually need people to do things other than code. There's some strong "junior developer" vibes in this last paragraph, not realizing that SWE management and project management are spending their whole day making sure that the code you're writing is actually what the company needs, and they're not just lighting money on fire by employing you.
Just because someone "can't code anymore" (arguable premise though that is) doesn't mean their job is automatically bullshit.
It’s two decades of experience speaking. I didn’t speak about managers though. I was a manager for a couple of years before my undiagnosed ADHD made itself know when I had my first baby. Management has nothing to do with project management. I’m solely speaking about the horde of pseudo jobbers who work as middlemen between developers and whatever it is that developers are supposed to do. I’ve never encountered one which wasn’t a waste of resources except for business process and lean consultants who would actually do change management on the business side before anyone attempted doing any form of digitalisation.
I probably should have said “won’t code anymore” because that is what I meant. It’s the developers who become project managers, architects, agile whatever. Luckily I don’t have to deal with that anymore because I’ve become specialised in helping startups in-fuck their chaos as they transition into enterprise organisations. Many of them never make it because of how their internal processes are hindered by all sorts of “best practices”.
This doesn’t mean that there aren’t excellent project managers out there. As I said, I’ve worked with some myself. Far too often project managers don’t actually do anything. I recently worked a team which has 1 PM, 1 Manager, 3 IT business partners and one architect in front of two developers. Today they have two developers and one IT business partner, who’s really an accountant that got into coding because he liked it. But is now capable of explaining the business to the developers.
It’s obviously not like that everywhere and I’m happy for you if you’ve had a better track record than me. I would argue that it is perhaps you who lack the experience that you seem to think I do. Because it’s not just on SWE you’ll find an abundance of bullshit jobs once an organisation reaches 100-500 employees.
It's usually easier for a technical "tech lead" to pick up project management than for a project manager to pick up "tech lead" (deep technical) skills, but exceptions exist.
The tech lead should have better business understanding than "currently needed" and ideally be supported by a domain expert (business analyst, product owner).
A project manager may support the tech lead to ensure the project's output ships.
This matches my experience - I was intentional about not saying that a project manager was important - just that project management (the practice) is important.
I shipped something users (internal) loved and the users were pushing adoption across the company. My leaders didn't consider it shipped. They never talked to the users. Didn't care. It needed perfect alignment with the org and needed to help the org's plans. Not the company or users across the company.
I'm not sure this demonstrates the issue without more context. If the people meant to use it were happy, what problem did the "leaders" have with it? Was it a huge moneysink whereas it was supposed to be an extra income source or like what kind of issue even
Excellent article. I'm going to pull out one point out of many that made me think:
> Project competence. You want to aim for something like a NASA mission control vibe
Having read a little about early Apollo-era (and earlier) mission control this was a fun comparison. The astronauts and flight controllers had no idea what they were doing! There was no textbook – they were performing a human first. They were generally young and very cocky people hired out of university, but were successful anyway, for some reasons, including:
1. They were further culled through harsh adversarial simulation training. This made sure only those that could cut it came out the other end.
2. They approached each new mission phase with a trial mission, each time extending the envelope in a controlled manner. (The cowboy moon touchdown on Apollo 11? It's often described as the first moon landing, but it really wasn't. It was just a test to see if they could reach the surface and get back up. The real first precision landing came on Apollo 12. Oh, but that was also just a rehearsal for the first scientific mission on Apollo 14, etc.)
3. They were fluid in how they organised themselves, and allowed mission needs to dictate which positions existed, rather than trying to impose a hierarchy onto a mission.
Going back to shipping, we can squint and look at this as:
1. Fake it, either until you make it or get tossed out.
2. Prefer to ship many smaller things than one big thing. This builds confidence in your abilities, gets you experience shipping things, and allows you more feedback to adjust to what the real project is.
3. Build coalitions across department boundaries, and draw on their support to ship.
Analogies are like scissors: more fun when you run with them.
> fact, it’s paradoxically often better for you if there is some kind of problem that forces a delay, for the same reason that the heroic on-call engineer who hotfixes an incident gets more credit than the careful engineer who prevents one.
I could really relate to this. Having been part of incidents, I fucking hate them and try to anticipate them with various safe deployment strategies. To leaders though it apparently seems like Im not doing anything because “nothing ever goes wrong” lol.
Think a lot of comments here (in my humble opinion) have taken the wrong interpretation of this article. Don't think this is a project-manager role, but is, as stated, typically a "tech lead or a DRI role." This means this person is still technical - would like to think this is how I approach my projects at a company and it is super effective.
Specifically then, as a technical person, this means you don't ignore the requirements and just think about the code. Instead, you need to communicate with both your higher-ups and your end-users, in order to make sure the code you're writing matches their needs - in my opinion, requirements is the part that most developers are weakest in, but if they strengthen would make the biggest difference. Get it as close as possible to being right on the first time (it's very rare that this happens but focusing on doing really good requirements increases your chances that you don't create the wrong system).
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.
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.
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 :).
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.
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.
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)
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).
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.
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
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.)
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.
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).
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.
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.
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.
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.
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.
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.
a project is shipped when the important people at your company believe it is shipped
Definitely. This can work very much to your favour.
There have been times when I have happily shipped a product containing issues and bugs that would be catastrophic for any customer using it, because I know that no customer actually ever will. The product is shipped and released, everyone is happy.
The catastrophic issues won't ever come up because that shipped product will never be used by anyone.
Big people are happy because the product is shipped.
Team are happy because big people have stopped causing so much friction in their desire to ship.
When the measurement becomes "have we slapped the label shipped on it", then that's what you get. A label.
It will become the headache of future team members that have to debug it when it inevitably crashes four years in the future, or needs to be rebuilt or the deployment moved.
Now personally I am fine with this, being that person. I will cause friction however. Unfortunately it is the new big people that take the hit from the previous big people. But such is the way of the world, this is what we are paid for.
Sometimes you get lucky and can shut things down. Then you get to celebrate that as well, shutting down the thing nobody ever used but everyone celebrated “shipping”. At least I get my celebratory cake!
this mirrors my experience, but it doesn't give much actionable advice and probably only rings true to those who have experienced the same motions. "You only know your project shipped if your leadership acknowledges it". Yes ok great, how do you get their attention. I think this piece could be more easy to understand and influential if the author included a specific IRL project as a case study instead of having a bit of memoir about the vibes of their experience.
I'll tell you my own personal experience here: Go talk about it!
Depending on the culture and rituals at your company:
- Ask for a spot at an all-hands meeting so your team can showcase what you shipped
- Record a demo video of the team's work and share it in Slack/Teams/Yammer
- Write a post-mortem or internal blog post about the impact that your "ship" had on the business.
- Etc...
I'm a firm believer in the concept of "internal marketing" in big companies. I've had leaders and mentors repeatedly tell me "no one will recognize you in a big company if you just sit around waiting for the recognition"...
You have to put it out there and talk about it and show it off...
And yeah, I know a lot of tech folks hate doing this.. But in my experience that's how you play the game in an honest way... Find the right time and place to be proud of your work and show it off.
Yeah, I agree this post would have been better with a concrete example. It's hard to talk about a specific project though, since it comes down to describing in detail facts about a company's internal workings (often embarrassing facts). I couldn't figure out how to anonymize it sufficiently.
I see so much backlash against Project Managers and they're just Outlook Calendars with legs, but this post is basically a love letter to good Project Managers/Release Train Engineers/Delivery Leads, whatever you want to call it.
I think the problem with those is that they lack understanding author mentions:
> But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.
The reason people hate specialized roles of scrum masters/delivery leads is that they often lack the E2E understanding and therefor are inadequate owners.
I kid you not, I've seen managers claim that v1 is shipped while no software was deployed at all (it was just the production environment). All this just to say the project is on schedule (it wasn't !).
I've also seen in the same company rushed QA (like ignore the guys) in order to ship faster to meet the managers' KPIs and bonuses.
So yeah, shipping a project probably means something different than most developers think.
> Sometimes it’s just an influential VP or CEO’s pet project, and you need to align with their vision.
My biggest career mistake was a project that I had no way to know was the CEO's pet project.
Can't say where (non-disparagement agreement), but oh boy was that a lot of messy fallout — QA awarded me a prize for least bugs on launch, yet at the same time line manger also immediately went from giving me bonuses to putting me on a PIP for having too many bugs in launch.
optics. If the CEO is reporting bugs they find or those bug numbers appear "concerning," the apparent lack of quality calls for corrective action.
Obviously things were not the healthiest there. The CEO should be similarly interested in other projects and their quality. Your manager should be aware of the relative quality and your award and tell his manager that "it has been / will be dealt with" and then to either never file the pip or speed run you through it (while letting you in on why: optics). And then the manager should be working towards producing better reporting metrics that executives can use that expose quality issues at large
I'd like to say I can code perfectly, but I'm a mere mortal not Donald Knuth and I can't get away with saying "Beware of bugs in the above code; I have only proved it correct, not tried it."
We had tracking of launch bugs, the manager ignored the evidence — that didn't make any sense at the time, then I developed a better understanding of office politics and suddenly it became easy to understand.
When I'm shipping on a deadline, one of my favorite things to say is, "there is no future". When someone says they want to do X because they will do Y in the future, I say, "There is no future, there is only shipping. Give me what I need to ship and then we can talk about the future."
Pigs can fly. I know this because if it's got to ship and it's a pig, then sufficient thrust will be brought to bear to achieve flight.
Shipping is some liminal space between sheer will, recklessness, and tautology. It ships because it has to ship, because to not ship is to fall, and failure is not an option.
Learning how to cancel, or quietly bury projects, can be just as important.
You're quite likely to be handed projects that make no sense. Bad ideas are created every day. Even if you ship them, you may be associated with their failure.
Yes! And the most interesting thing here, to me, is how the crowd splits in two groups: one group basically saying "That's how it goes, if you wan to get paid (and you're not intelligent if you don't) you need to play this game, even if you don't like it" and the other saying "This is unacceptable. We need to first recognize that the state of things is not good, so that we can then act and change them. So let's start by stating that this should not be accepted. It's wrong to accept it".
What is the alternative, though? This is an honest question, I really want to know: How would the "this is horrible, how can you deign to work that way?" crowd coordinate thousands of people on a project to create something that is bigger than what 5–20 people can create?
Because most of the answers I see here gloss over that part, or strongly imply that engineers will always decide better than business people what should be released. And I can sympathize, especially if you are in an MBA-led org, but I am also certain that if you think you know perfectly what the enterprise or customer needs, and anyone opposing you is a Pointy-Haired Boss, that you are most probably the idiot in that case: 90% of the time a single dev will NOT have better business intelligence than everyone else.
> What is the alternative, though? This is an honest question, I really want to know: How would the "this is horrible, how can you deign to work that way?" crowd coordinate thousands of people on a project to create something that is bigger than what 5–20 people can create?
Nobody needs to be co-ordinating thousands of people. 5–20 people can create Instagram. The entire problem in these companies is that leadership is so out of touch they cannot differentiate between a checklist and a product, and empire-building is their proxy for value. The solution is to change the leadership, but it is usually too late in large orgs (the new leadership has to be brought in somehow from somewhere, and that will be done the same way the current leadership happened).
So the real solution is for those who care to go elsewhere, out-compete, and out-succeed. Then quit after acquisition, if such a thing happens.
I think the first group is more of “this is how it is” rather than “you’re not intelligent if you don’t play the game”. I personally don’t find this status quo good or healthy either, but I(or anybody) have little control beyond formulating policies at a company at best, and changing their job realistically. (Fortunately my current place seems quite decent in this regard so I’m good/lucky.)
Agreed. What I am a little surprised is that some engineers seem to trying to defend something that is knowingly bad just because it is the status quo.
BTW, I don’t think catering the upper management as described is the only way to get paid. I ignored many upper management’s preferences because they are plainly stupid and in some situations get fired. But I still made good career growth and so do many of my friends. In fact being in a conflict and holding position tends to give me higher rate of returns, even in case not being able to “ship” as defined in the op.
I wonder, given the year is divisible by four so it is on the mind, I wonder if that divide of "acceptance of what is and working with that" vs "we can be better if we make it so" is also the divide that manifests between the two political party system in the US.
They ship because they do project management right:
1. Focus on stakeholder management
2. Know and understand what you build end-to-end
3. Because of 2. you can quickly assess the impact of various options to resolve a problem and communicating this back to stakeholders, generating trust
I like the example of 3. In the blog post.
So many people run projects like they just coast around. Never a moment to pause, reflect and proactively thinking about potential risks and possible mitigations.
Oh my, we never saw this road block coming, how could we have known? Well..
I effectively agree with the "destination", so to speak, of this post, but disagree with the path taken to get there.
In general when I ship projects in the context of the org I with for, I _do_ meet the requirements of higher-ups/stakeholders, but not because that's my goal -- but because we're aligned on those requirements. Shipping to make management happy feels kind of incestuous, you should be shipping because you and management both agree on what the end goals of the project are.
This might seem like a subtle distinction, but it can create issues. If you're using your management as your metre-stick without truly understanding and believing in what they want, you'll likely over-optimize for the project's goals that they've stated, but miss the target of actually making the project successful.
This approach is fine if you're primary goal is to get paid, get promoted, please your managers, etc. But if your goal is to create great things, I think you need set your metre-stick based on the project not on the management. From the outside these approaches look very similar -- which is why I largely agree with the "destination" and a lot of the tips in this post, otherwise.
As any worthwhile piece of advice, this post is not saying "Do good things, don't do bad things" but instead "Prioritize one good thing over another".
Hence lots of comments. I wish there were more submissions like this.
The reality is that it’s just the way life/“the game” is. I think it’s good to know about such things, it’s still very much up to the individual to use it/not get fired etc. Unless someone lives alone on a farm, they’ll likely need to know how to handle such things at some point (or be very lucky, or possibly suffer).
It's a post about getting your software recognized and used. For that, you actually need to get other people on board, yes. If you don't care about that, why are you even working in software development? It sounds tedious to just build things nobody cares about.
Articles like this are off to me… you’re going to need to quantify and qualify your claims of things otherwise I don’t know how much credence to throw ya.
“I ship at big tech” is a broad statement… as a reader, I need elaboration or I tend to question the rest of the article. Is this just a guy bloviating or does he really know his stuff? And bold claims need to be back up.
Looks like: ZenDesk and GitHub are the "big tech".
Projects shipped look like:
* Documentation portal
* Refactor of some monolith into micro-services
* Markdown rendering
* Copilot onboarding flows
* Varied Copilot anti-abuse related things
This hasn’t been my experience at Big Tech (in ~20 years). There’s plenty of projects I’ve shipped that didn’t have upper management support but after the user feedback or metrics were positive they got counted as a win. There’s also many smaller projects that you can ship without anyone paying much attention but they can still be valuable either to some subset of users or in aggregate. For example, +1% on some metric isn’t going to get you a call out from the VP but do that every month and now you’re talking about big aggregate gains.
If you work at a company like this where leadership does not understand the engineering, the value, or the consequences of their reports but only want to talk about it at review-time, you are not in a healthy environment with an actual leadership.
And you will feel the toxicity created by this kind of poor leadership by way of constant blame games, misalignments, and unnecessary stress over garbage.
Feels like my current place. To use OP's language: if you have shipped and leadership knows about it, but also does not care, you have not shipped. Unfortunately it turns out there's no way to make them care, in my case.
That is, however, true of almost all of the big players. If you want the security of the big paycheque every month, you do the deal with the devil, so the speak.
> That is, however, true of almost all of the big players. If you want the security of the big paycheque every month, you do the deal with the devil, so the speak.
And you will pay the cost of it with time, physical and mental health, and career longevity.
Ultimately you are signing up to be servants and servants are not valued within or outside the organization.
Regarding the “realism” proposed here, that leadership defines what shipping means: there’s a good faith and bad faith interpretation.
The bad faith interpretation is that this is corrupt and misaligned.
The good faith interpretation is that each leader has context and motivations that are important.
The right interpretation depends on the exact circumstance.
Getting leaders aligned on the right definition of “shipped” is a separate problem to the one described here, and it’s not the project lead’s direct responsibility. It’s the responsibility of the leadership team, the CEO, and the board.
But the realism proposed in the post is useful for project leads. Meeting leadership’s expectation is not necessarily corrupt, and if it is corrupt, it can be improved by directly discussing and negotiating what it means to ship a project.
> Can we ship right now? Feature flags are the best way I’ve seen to do this, but staging environments also work, and so on.
Feature flags are a super weapon if you are trying to keep the path to production clear, especially if you have a diverse deployment or customer base. They don't have to be a constant binary value either. I've set up "flags" that were SQL queries which produced the actual boolean fact based upon customer-specific data and requirements.
These things do tend to accumulate, but cleaning them up is easy as long as you have a way to report on the current configuration across all deployments. If two or more instances have different settings but their users seem happy with this arrangement, then you go the other way and promote the flag into some kind of official configuration abstraction.
Customer and environment specific branches quickly become a death spiral if you are trying to grow a B2B/SaaS product. I'd much rather fight a spreadsheet of flags & config than rebase branches and resolve conflicts that have silently piled up for the last several months.
The idea of “shipping” as being an emergent state of mind is a great one. A project grows the same way an embryo grows into a full animal: it does so in millions of tiny parts that overlap in discrete ways to produce a continuous spectrum of development. I think some good additional milestones to measure that kind of development might be as follows:
* Your first bug report that you file against yourself which you fix yourself. Your project is stable enough to be usable with a known bug, but you go back and fix that bug when you have time to dedicate to it. Contrast with nothing working until everything works.
* Your first time seeing someone find a flaw that lies so far out of your own mental model of the project that it causes a very jarring feeling, hopefully followed by excitement that the project is now taking on a life of its own outside you / your team as the sole developers and users. An example of this might be someone filing a bug that image rendering is missing from a git visualisation tool where you’d never even considered using it for projects with version controlled image assets.
I feel like there’s an analogy here to a baby’s first detectable heartbeat and a child’s first original that-never-occurred-to-me thought. There must be a lot more in between too, with the social acceptance of a project becoming shipped as the child entering the adult world as its own person.
> no matter the project goal, your leadership team (the people in your reporting chain who care about the project) will always have basically zero technical context about the project compared to you.
This is not universally the case, and I've been much happier when I find teams and orgs where this is not true.
Good leaders understand the details. Find them. Be one.
This reflects my personal experience as "CTO" of a software factory. I put CTO between quotes because my role definitely shifted away from technology itself more to a delivery role. I have to delegate responsibilities to the right people, act fast when a team member is pulling its weight, allocate resources to solve problems a team can't, and even jump in and work along the team if shit hits the fan. Delivery is the hardest thing; something that works for me is trying to have a plan and not only consider features but a checklist to reach Prod. What I mean is adding all those tiny things that add up to the planning (who's in charge of the DNS? who's setting up the Twilio account? etc etc etc)
Yeah, I think TFA gets a lot right about doing software engineering in large orgs.
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)
Great article. It's not "shipping" as in making some feature a reality, but more contextualized within big tech and perhaps larger sized companies. Understandably, some people might call this "unethical", but it's kind of a "game" that you play (or don't) being in a large, hierarchical org.
> But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.
In the before times, we called this an architect. We're too agile for that now, apparently.
No, in the before times, we called this a project manager.
The project manager worked closely with the architect, but the architect focused exclusively on the high-level code/engineering part, not the end-to-end understanding of the whole thing that involved management, partners, corporate processes, approvals, etc.
(And note the distinction between project manager and product manager, two entirely different jobs. Project managers stereotypically use Gantt charts to focus on timelines and contingencies and processes; product managers focus more on user needs and product-market fit.)
Now, that responsibility has been dumped on Tech Leads, who have neither the power of the Project Manager, nor the responsibility of the Product Manager.
And depending on how your company selects Tech Leads, they might not have the technical ability of an Architect, or hell, even a senior engineer.
I'm the living example of this. I'm an engineer who thought he's signing up to be the TL to design the architecture and implement the hard parts, and at some point I realized I'm doing a terrible job because in reality I'm just EM-ing this project 90% of the time, while my manager is busy with something else.
As a Staff Eng, I strongly related to this. At big tech in Silicon Valley, the Tech Lead archetype does tend to do all the Project Management and, depending on whether your team can afford a Product Manager (eg. Infra team), some or all of the Product Management.
IMO, it's a little unfortunate from a productivity perspective that you have a high performing Engineer also running daily/weekly syncs, doing stakeholder management, and doing upwards management for resourcing. From a personal learning perspective, it's great though. You, as Tech Lead, learn and hone a broader set of skills and not only the Architect or Senior Engineer skillset.
Agree on the role distinctions, but the best people in any of those roles will be able to see/do some of the important factors in the other domains and ask questions like "so what does success for this project look like?"
When a company does not want to pay (or empower) a principal engineer, they hire legions of junior engineers to cover up the gap. People who focus on the joy of shipping than on the pesky questions of "shipping what?" and "who will maintain it?"
Many of us here owe our jobs to the deliberate weakening of technical authority and expertise. That debt probably blinds us to those management decisions, and the need for architects to balance them out.
Oh how I wish I had a legion of junior engineers. Or even a squad.
My company has an aversion to hiring. It's so expensive to hire people, you know! There are no young engineers to teach the ropes to. There are very few senior people do everything.
Needless to say nothing happens fast, good, or cheap. And we don't ship projects, they mostly just bob up and down in the harbor.
That's not just an architect. It's an architect, a construction worker, a bricklayer, a plumber. That person might not do everything but needs to be able to dive deep as low as required.
The main requirement is for the person to be on the project and have skin in the game. An architect will often have more of a bird eye view and not be actively working on a specific release. They might also not care about the business side.
IMO depending on the org, the matching role would be either a release manager or a project lead.
This is a great article. Reflects my experience both in big and small companies. Anyone can be the "Project leader", doesn't need to be a TPM, PM or ENG. It isn't an org chart role, it is a role you are fulfilling. I have seen many different org chart roles succeeding or failing at it.
This also allows companies to bake it into a role without commiserate pay increases and even sometimes without modifying responsibility only adding on to them.
Don’t be fooled folks, if you aren’t being paid more for leading and taking visible ownership over things you’re being cheated
This is a very snarky/bitter view of it. In my career I have done fairly well and have been promoted after the fact a couple of times. People who don't take these opportunities rarely move up to bigger responsibilities. At big tech is usually expected that you are already performing at a level above for a certain period of time before being promoted
In my team, this role is covered by the tech lead, who also takes on the responsibilities of project manager, scrum master, and business analyst (team members help with business analysis).
I think this is a change in business climate today - all senior+ engineers in many companies are now expected to have knowledge of business metrics, and that expectation goes up with staff engineers (the new architect name)
I think this expectation has always existed, but engineers have been able to get cover for not understanding or participating. Now it is harder for engineers at any level to cover which means they have to understand the business and participate to a larger degree. This may just mean being more proactive in raising issues affecting metrics through to influencing what those metrics should be.
A constant focus on keeping the architecture,infrastructure and codebase
quick/ease to ship is to "Keep It Simple Stupid".
Be critical about adding new services or complexity.
Ask yourself can this be solved in a way that does not require
changes to the shipping process.
If no, evaluate possible alternate approaches.
A fanatical dedication to monitoring the production system is beneficial.
The faster you can catch that the last deploy screwed something up,
the less stress and down time there will be.
The shipping process should also include the ability a rollback the latest
deployment. Again less stress and possible downtime there will be.
Achieving these goals is the best way to win the trust and influence
on the people up the chain.
Every project has a role of Release Manager. Some teams are small enough that this role is filled by a team lead, project manager, architect, etc. some teams rotate this role to spread the pain and knowledge. Large teams have a defined employed role with title of Release Manager that could even include a team (think shipping large DoD contractual projects)
There’s whole books on this subject. I think this blogpost does a great job of summarizing the goals for large tech company shipping — well written — nicely done
This is why I'm a big fan of MVPs and quick iterations after ward.
Launching a significantly complex product is HARD, even if it is an MVP.
Nobody understands how hard, even if they've done it before. It works in staging, must be ready! Then users start trying to signup and actually use the product and the wheels come off.
I've usually been the person that understands it all and launch week is always hell. Or depressingly boring because you have no users.
this is a reality in organisation: " it’s paradoxically often better for you if there is some kind of problem that forces a delay, for the same reason that the heroic on-call engineer who hotfixes an incident gets more credit than the careful engineer who prevents one." Its ironic in many areas. A leader (Project or Political) who ran projects and shipped smoothly is less valued than a leader who created a mess and got them fixed ...who is more celebrated. :(
Great article. That bit about having 20% free at the start to 90-100% free time towards the end of a project, to address issues, is very insightful. I stumbled a lot in a project recently because I suspect I had it the other way round.
This aligns with what I've seen and the issues I've had shipping high leverage things at an enterprise. Its way more communication, selling and documenting more that it is a technical issue. Nice post.
It's all about the last 10% - it's what makes a project of any size see the light of day. Some thrive on that last 10% (like I do). It's the work of grinding through the final loose ends and the finishes touches, fixing the issues in the live environment vs development, etc.
It's hard and boring, but it's also rewarding.
And then there are most people - who just check out when it's sort of done. I don't like those people.
I think the whole idea of shipping, at least within big tech, should follow slow rollouts starting with 0%. For example: Deploy an empty service in production with 0% rollout. Increment the rollout with each version deployed, including fixes of previous releases.
This may not be great for user experience but great for getting things up and running. Although, upper management will not be happy to see slow rollouts.
The way I've used to describe this to people is, most people's mental model is:
<doing a poor job> --- <doing a average job> --- <doing a good job>
Whereas the more accurate mental model is:
<doing nothing> --------------------------------------- <doing a thing> -- <doing the best thing>
The former mental model is intellectually satisfying because you get to infinitely yak shave over every little tradeoff and doing nothing isn't even on your mental radar.
The latter is deeply humblingly mundane and doesn't get to center us as masters of the universe which is why we all initially resist it. Even for the people who become great at it, they become great against their inclinations, and still have to fight the urge at every step.
This doesn't just apply to tech, look at it in politics. How much time do we spend in politics debating policy? Which of our different political philosophies lead to different tradeoffs that are a deep expression of our values? How much time in politics do we spend debating state capacity? A state that can do none of the things, it's irrelevant which of the things we want the state to do. A state that can do more things, almost always just the sheer option of things they can do means they can find a better policy.
And yet policy arguments are just so fun while state capacity arguments are incredibly wonky and depressing.
But I've drawn that same diagram on 100 different whiteboards in front of 100 different juniors and said the same words of "before we figure out how to do the best thing, let's just see if we can even do a thing first" and it seems to have gotten through to an appreciable number of them enough that it feels like a high converting meme.
I think this train of thought is why I now have to deal with four UI libraries in the same small-feature-set product, including three different ways of styling a React component.
I think that a more accurate mental model would accept that a team sometimes has no idea whether a change will get them 80% of the way there with 20% of the effort, get them 20% of the way there with 80% of the effort, do something somewhere in the middle, have zero impact, or even make the product worse.
most of this makes sense but I think what would make it more useful is more focus on topics that mainly fall under project management: building relationships with key stakeholders, establishing early+clear communication channels, building in timeline slack, how to navigate management politics etc. i dont think shipping in big tech cos is significantly different to shipping a large construction project in terms of project management, but rather there is a tendency for managers in big tech to be significantly less tenured and hence ignorant of basic management priniciples that lead to easily avoidable blunders.
I agree that every project needs one person who has a laser focus on getting the project across the finish line. There are always dozens of slightly annoying and unrelated blockers.
I call it my volleyball theory, after playing on a mid team back in college. If the ball is coming down near a large group, no one gets it. If you're the only one there, you'll get that ball one way or another!
It’s a great post and often what I see folks doing.
Hot take though: why do we need so many people and processes and mysticism around software these days? It seems to me the reason why it’s so difficult to ship anything, let alone anything good and useful, is because there are so many people involved who don’t actually participate in engineering. They manage time lines and meetings and emails and talking to customers. And somehow they’ve made themselves essential to the process so that developers can’t ship code anymore.
Like… I know my users on a first name basis. I know how their business works. We’ve talked about the button and we want to run an experiment.
As a developer I might want to just try it out with them. Maybe the change will be a good fit for the product as a whole, maybe it will be a solution that only works for this one customer, maybe it means we need to be able to configure which workflow is used.
If I can’t just ship that and get the feedback I need without involving a handful of other people and being completely fearful that I could take down our service… what is wrong here? Is it that there aren’t enough “shippers” on the team or is it because the organization has made it difficult to ship anything?
That being said, this is the world we live in, and the article has a lot of great advice. I’m definitely used to/conditioned to think this way.
It sounds like you are part of a pretty small business given that you're an engineer who knows his customers by name. It may very well be completely acceptable to your customers to have extended downtime, or a button that disappears during a deployment leading to a broken feature for a couple of days until you, or they, realize something is wrong.
Many other companies do not work this way. If you're a huge company like Apple that makes $40M per hour, that type of downtime isn't acceptable. If you're in finance, that downtime doesn't work. If you're in healthcare, defense, aerospace, etc... that downtime doesn't cut it. Yes, you'll still have downtime in those industries from a bad deploy, but you put more checks and balances in place to reduce the odds it will happen.
I'm not actually at a company where I know folks by name at this point. I was for a time.
I currently work at a much larger company where I ship platform-related stuff that integrates a bunch of systems (card payment processing... so fintech) for other developers so that they can ship features and products to customers. I've done a lot of the work mentioned in the article.
The hot-take is just a suspicion that we make things more difficult for ourselves by involving more people than is necessary to get work done, not trusting developers, etc.
Update: and is more a reflection about how the industry operates in general than how things operate where i work in particular
> If I can’t just ship that and get the feedback I need
As a user, I detest when I'm treated as a lab rat and the software I rely on to get stuff done has the UI randomly changing because the people making it don't have anyone in charge with enough design sense to make a call on how the product should function.
Google normalized this practice with the obsessive A/B testing and it's one of the biggest things that pushed me away from Android and general Google services. Microsoft is terrible for it too now. Every piece of software feels like a perpetual beta test.
As a person who regularly ships software to folks to solve problems I think this is more of a symptom of marketing and product folks taking over than software developers trying to provide a stable, useful solution.
A system needs to change over time as demands and requirements change… but it shouldn’t be unexpected and without warning. And it should be in concert with knowing the unique demands of the users involved with the system.
When I want to run an experiment, I mean to run a deliberate experiment that the people using the software are aware of and are a part of. Not some random trial A/B test based on telemetry. That stuff is too common these days, I agree.
Articles like these really speak to me. In a lot of ways, developers that claim to take ownership might be a few small cognitive steps from actual ownership aka have shipping in mind. Lots of take aways to prevent headaches and pain points.
Excellent piece. My observation in less technically-oriented but still innovative companies: shipping also occurs when you post about it on LinkedIn and can show with a concrete example (a graph or a small video)
I've also "shipped" projects at big tech companies and this level of bootlicking really doesn't deserve to be called "shipping" it's just delivering for your management. Using the term "shipping" is a great scissor statement because it muddies the water.
The mentality from the article is another symptom of the many issues Software Engineering faces as profession.
Namely that a significant portion of us think of ourselves not as engineers, who need to tell management to get fucked occasionally, but as optimizers for accolades from whatever group can dole out rewards. This starts off in academia and continues into the professional world.
Certain folks just want to build a technical fiefdom for themselves, or get headpats from people who are above them in any given hierarchy.
Yeah this is "how the game is played". Playing this game eventually leads to the death of your organization and is why we have a corporate life cycle in the first place.
Eventually people like this eat an organization from the inside, pushing out anyone with an actual opinion or who optimizing for actually getting things done.
Instead it's just pure mercenary behavior for your managements attention.
> I have shipped a lot of different projects over the last ~10 years in tech. I often get tapped to lead new ones when it’s important to get it right, because I’m good at it.
Why not list some of them that I can actually try out? How should I give this any credence if I cannot evaluate them?
None of that looks like stuff I can try. I guess the GitHub copilot onboarding was pretty good. Gists are pretty good, but I don’t think he made those originally.
Thus the discussion in the article around stakeholders and what constitutes "shipping". A lot of what one will work on at a big company does not directly translate into features that regular users will see.
Is it just me. Or has the term "ship", "shipped", only become a (specific to software production) industry-used term asn of relatively recent times? Specifically as Sam Altman has been using it a lot I have also noticed. Ever since his increased use of the term, I've seen it used more and more. This could be one of those times where I am noticing it because I am thinking about it, but it really doesn't feel like that.
I have always associated new software versions with with my the word "release", "released". While shipped is not an incorrect term to use for software. Release just feels more appropriate.
Has anyone else noticed this?
All of that said, I am not condemning the practice in the least. Just interested in the etymnology of one of my favorite areas of interest. Hopefully draw some more knowledgeable folks on the question.
It's not a new term. Steve Jobs coined (or at least popularized) the saying "real artists ship" in 1983[0], and using the word "ship" this way is probably even older than that.
The practical advice in here resonates very strongly with my experience, I like the analysis a lot.
The philosophy about what "shipping" is... Presupposes that your motivation for working in big tech is to get to L9 and make 7 figures or whatever. Dunno about that. (Also I suspect there's a ceiling on where you can get by being really good at shipping).
I like to think I do this shit on my own terms, I have my own goals. Pleasing leadership and getting good ratings is very often instrumental to those goals (and money is great) but I think I still get to decide what shipping means to me.
Me myself, I joined a project that shipped on time. The lead developer, a contractor, begged for just three more months to make it all actually work properly.
Nope.
We shipped, and then it took two more years to finally get it functional.
And the contractor was banned from ever working there again (a WA state agency).
> Shipping is really hard and you have to make it your main priority if you want to ship
This feels like it’s written by AI by a junior level “prompt engineer”
> Shipping doesn’t mean deploying code, it means making your leadership team happy
Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck. Gotta make sure the font is just barely legible and explain it quickly before they ask follow up questions
> You need your leadership team to trust you in order to ship
yea that’s why I get _paid_ to do work, not glaze c-level executives and appeal to their fragile egos
> Most of the essential technical work is in anticipating problems and creating fallback plans
Falling back is a loser mentality.
> You should asking yourself “can I ship right this second?”
no, I should be asking myself, “why am I still at this dead end job that asks me to constantly ‘ship’ a broken product. Leadership doesn’t want to encourage delivering value to the customer”
> Have courage!
You don’t need courage at a “big TeCh” job. Just be slightly competent and you are already light years ahead of your colleagues
>Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck
Is it wrong, though? This is a pretty much universal phenomenon. It's less about real goal X and more about making sure the boss feels good when you're around.
That usually correlates with being a good worker, but not always.
> why am I still at this dead end job that asks me to constantly ‘ship’ a broken product.
Because the economy is broken right now and my country is gaslighting me into think it's perfectly fine for rent to go up 50% in 2-3 years and groceries to double.
There's definitely a storm coming, I can worry about my passions again when it passes.
Shipping for your leadership instead of users is so very American and explains how serial blunderers fail from one big project to another while the employees get the short end of stick. Happy if you makes you happy that some big wig on the leadership like you, but is that really all you want to achieve in life?
This is great. I particularly liked this observation:
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!
Ya, I think this is a great insight. In today's world, code is not released as a versioned artifact sold on a disc or downloaded. The idea of "shipping" is fuzzy. You might be 100% in production with some change and it could still leave edge case, deficiencies, etc. You can decide to address them now or later. And it's all just perception. You can say it's good enough, we shipped, let's forget about this whole thing and move to another. Or you can keep ironing out the quirks.
I've "shipped" things in the past that were turned on to less than 1% of the time, and we left it at that, and moved on to other things. It was considered "shipped". Everyone was worried to increase it to beyond 1%, so we all patted ourselves in the back for the great launch and went to work on other things.
There was always something intensely satisfying about walking into some retail store and seeing boxes on the shelf containing CDs with software I'd written.
(On the flip side, there was that one time we had to destroy 5,000 CDs because they had a Quicktime Autostart virus on them...)
Heh. I can relate to seeing your product on a shelf.
I recall seeing IBM ViaVoice X on shelves a Circuit City. It was rather an ego trip.
Sometimes it’s odd to realize there’s people that can say this while simultaneously not being my grandfather. There’s a whole period of computer history I skipped.
FWIW, I'm 57 soon. Old enough that I could totally be some random HN poster's grandfather...
I bought it back in 1998 and started using it right away... it truly felt like the future!
:-) I worked in the first OSX version. I did the AppKit UI being one of the few on the planet who had a NeXT background.
It came with a UK language model as the US model didn’t recognise my accent.
This is the reality. And if you happen to be in an environment with less cooperative folks, get your requirements to ship in writing, agreed upon, and as up front as possible. Hold them to it. Otherwise, it just opens you up for nitpicking, and in some cases goalkeeping, by folks whom end up delaying your shipping.
IMO most engineers completely forget or don't appreciate the importance of optics, especially when working with non-technical founders or management.
Yes but otoh that might be more of a “I refuse to accept a culture of optics on principle” kinda situation, rather than not understanding it. I liked the post because it’s honest and doesn’t put a value judgment on things, just explains how it works. It’s up to each and everyone to act accordingly, and one of those actions is to not participate in the lunacy that often arises in the higher echelons. Many people are fine keeping their integrity, mostly left alone to code, avoiding social deception games at the expense of not being promoted out of what they fell in love with in the first place. People are just different.
Refusing to accept a culture of optics is tantamount to not understanding optics though. The reality is that if you work on any kind of product, optics do matter - the perception of something working is often just as important as it actually working.
It can't possibly be "just as important" - in some cases, I will accept "almost as important", but any situation where the optics are "it works" and the reality is "it doesn't work" is eventually going to come crashing down on someone's head.
If it doesn't need to work, then it doesn't matter and the optics also don't matter. Of course, it might be more important for your promotion that the optics are correct, no matter what the ground reality is, and the crash could come down on someone else's head instead of yours, but in this scenario someone who is against a culture of optics rather has a point.
"Appreciate" is a weird word. At least for me (not an English speaker) it has a positive connotation so with that in mind I sure hope nobody appreciates the importance of optics. The concept is dumb but it is important and we have to play the game to achieve anything.
Appreciate has at least three entirely different meanings that I can think of.
1. To be grateful for something.
2. To fully understand something.
3. To increase in value
I’m sure there are more.
I read this as option 2.
Why did you read that as 2 though? Is there a context clue I'm missing or is there some grammar rule I don't know of? Honest question, I'm Polish.
For me there's a huge gap between 1 and 2 so it might cause misunderstandings when used in a sentence. I despise a lot of things I fully understand and if I said I "appreciate" them - sounds weird.
It's heuristics, not grammar. You usually appreciate a noun or noun phrase in a transitive sentence (X appreciates Y).
Case 1: If it's something useful (e.g. 'your help', 'what you did') then it's more likely about being thankful.
This use of 'appreciate' is also a social action. You say it to make someone feel good for helping.
Case 2: If it's an abstract thing (e.g. 'the importance of', 'the difficulty of') then it's more likely you're talking about understanding.
Usually when you talk about this usage it's because the _fact_ of understanding is important to the speech act. If someone explains the law of gravity you don't say "I appreciate that", you say "I understand that". But if you fell from a height and hurt yourself you can say "I didn't appreciate the law of gravity".
Case 3: If it's intransitive and it's about money ('the car appreciated in value', 'the house appreciated in value').
As someone learning a second language as an adult, I appreciate you writing this all out!
Finding people that can explain these types of examples to new language learners can be quite difficult, even on language focused platforms/forums.
It's a pity that heuristics are not mentioned in most language books or dictionaries. At least I wasn't taught any in school (10+ years ago). This should be next to the word definition.
Correct.
Similar is "enjoy", which is almost always possible but sometimes can be used in a more... detached sense? "Perspectives in nature we rarely enjoy" as seen in The Far Side here, for instance.
https://i.pinimg.com/originals/89/b2/2b/89b22b4b18dd3ed630a0...
Optics are not dumb. Corporates are very noisy. It is difficult to extract the signal from the noise if you're not working on a project full-time (as most people are, except for you, the tech lead), and it will definitely not happen by accident. That's why you need to manage optics.
I agree that they are very important but I still call it dumb in a "it's stupid that we have to do this because we suck as a human species" kind of way.
I think that's what the word "appreciate" is hinting at in the phrase: "most engineers..don't appreciate the importance of optics."
Optics is subjective and often superficial, a performative illusion for the sake of whoever is looking at you. But that doesn't mean it's not valuable or useful in a social context.
Here, I read the word "appreciate" to mean, to recognize the value of a thing even if you disagree with it.
For example, someone could be a pacifist and still appreciate the need for weapons for national defense. They may not agree with the means but still admit it has value and effect.
Weirdly, optics have never mattered at all in small or startup companies. And they manage to do pretty well, ship a lot of product and become large companies.
Maybe the problem isn’t the engineers, but the need for optics…
It's a matter of scale. "Optics" (as a separate concern) don't matter at orgs that are small enough that everyone can see everything (and/or has full trust in the people who do). Visibility and trust don't scale, hence the necessary evil of pageantry
In that case it's the optics with the customers that matter.
Which can be more rewarding to satisfy than the optics of just management. But still needs to be managed appropriately.
Nah, I think optics can matter at startups too.
For a lot of the ones that fail, yes.
No organization with more than 1 person is immune from the effects of optics. If you think so, you may be blind to it.
It definitely gets worse as the organisation grows. There isn't much room to hide in a five person company whereas it's hard to be seen in a 5000 person organisation.
I wear glasses, so I appreciate the importance of optics every day.
What is optics??
The emotional perception of the quality of you, the worker, in the eyes of the leadership who pays you. It is distinct from your true value and contributions. It is maximized by you optimizing the visibility of things that boost reputation and minimizing the visibility of embarrassing things.
It's a term that has been adopted to sound more professional than "keeping up appearances" which is an age-old concept. It is about how things are/will be perceived by others, rather than the truth of the matter.
Perception is reality. (For better or worse.)
There is a tendency here to pattern match the advice in this article with frustrating experiences about office politics. But I dont see this as a post about politics.
Rather, what I got was that the spec is an incomplete description and there needs to be more inquiry into how the software is going to be used. This can require a little bit of 'going up the stack' to see how business need relates to the software requirement(single enterprise customer with a precise requirement, acquisition of new customer, software for some internal vision of CEO etc). Compare with a startup where one doesn't even have a spec and one is trying to find a product-market fit or when developers take sales calls and find new insights on how the software is actually being used.
A completely broken spec is indeed a failure in management process. But, in general, it helps a library developer to think beyond a library spec and see how it is being used.
Yes. Unfortunately, it comes with a side effect, you will see leadership use this to kill projects they don't like by not never mentioning them until people think it's a failure.
If you are working on something the people deciding on the size of your paycheck want to kill, time to find a new project or a new company. Why fight a battle you're sure to lose?
If only you could figure that out ahead of time. I've been on projects that were killed with no notice anyone could see even in hindsight. I've been on important projects that senior leaders decided to out source my job to China and my boss was forced to let me go. I've seen budgets run dry many times and important projects got killed/cut with no notice (sometimes there are signs that but you think your project is important enough to escape the cuts until it isn't). Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I've also seen people make careers out of taking over projects cut for the above reasons as customers still demand support. I've seen many downturns where my project was important enough to not be cut.
I've seen many downturns where my project had massive cuts, but I personally was not the person cut. Most often projects are not killed outright, instead they go through a long down spiral (not always, but typically) and you can make a lot of money being the expert on a product that is making money if you are able to hang on. Someone needs to leave as there isn't the budget to pay everyone, but that someone need not be you. Often these projects pay very nicely for working 9-5 with no pressure to do overtime.
Note that it can get trickier than it sounds. (Well, I don't know about big tech, but at least for medium and smaller.)
You need to figure out who the "important people" are, and somehow make sure that they understand and buy into the product definition, delivery dates, etc.
Even if they're 3 levels up from you, and you can't normally interface directly with them, try to find a way to double-check that all the "important people" are on the same page.
Organizational dysfunction happens, and you have to succeed despite that possibility.
In my experience, most things in large companies are social constructs. Good things are good because they were decided to be good, bad things are bad because they were decided to be bad. Very rarely are they driven by actual metrics.
Same here. What you highlighted makes a lot of sense to me and it’s something that happens at every company size.
This post is about corporate politics, not "shipping projects." To wit:
When the stated goal is to make leadership happy and not solving customer problems such that customers are "happy", that is pretty much the definition of politics. As subsequently identified therein: I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.EDIT: clarified the ethical question.
Like everything else, writing code doesn't exist in a vacuum.. There will always be interconnected constraints and requirements, and you simply cannot "deliver a spec" and think that's all there is to it.
And that has nothing to do with ethics.. The spec is outdated by the time it makes its way to you, and odds are it was flawed from the start in some way.
And again this isn't because someone is bad at their job, it's because the business reality and conditions are constantly changing.
And so someone needs to be keeping an eye on both of those things and steering the code delivery parts of the work to stay aligned with those changing business conditions.
To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
> If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
Have you ever worked at a big company? The level of dysfunction that can be sustained over years or decades at a place with decent market foothold is staggering.
I work at a big company now.
Of course there are exceptions to the rule..
Let's reframe as "trending up" and "trending down" based on customer happiness then..
Over a long enough time horizon, and generally speaking, I still believe I am correct.
“Let’s reframe the question to where I’m right”
Sure, take a worse-case interpretation of my words, this is the Internet after all.
We're all posting short messages here, not essays.. There is so much room for choosing to interpret each other in different ways.. So it's inevitable that we'll be misinterpreted sometimes.
And yes, I did try to reframe to better make my point, because I do think I'm right.
Welcome to HN, but a word of advice, this kind of snipey low-value shitpost is typically not welcome here.
> To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
To look at a concrete example, with the quality issues Boeing has been having in the recent years, we can claim "happy leaders" diverged from "happy customers".
Yet Boeing will still be around for a long time, and failures can be catastrophic. Whistle blowers who came out since can be said to have advocated for "happy customers" against "happy leaders" but were suppressed.
At Boeing, ‘happy (wealthy) leaders’ diverged from ‘alive customers’.
Yes of course there are exceptions to the rule, always.
What I asserted was:
This has nothing to do with "writing code", "outdated specs", "people being bad at their job", or changing market conditions.It is a decision each engineer makes when performing their job.
Ethics are not situational. An individual either values and adheres to them or does not. Specifically excluded from this position are mistakes people make and then strive to not repeat, as no one is perfect.
Fair enough! I see your point.. But then I would submit that this is too narrow of a view to take in a complex interconnected enterprise, and that anyone who works this way will end up more behind than ahead.
I'll stand by my first line that nothing exists in a vacuum.
If you only make decisions in isolation or without broader context, whether based on ethics or otherwise, then you will inevitably make the wrong decision, I would argue, more often than not.
Context matters, and the same decision made at different times and in different situations can have completely different outcomes or impacts.
What if "making the customer happy" costs so much money that it puts the company out of business? Do you still focus on only making the customer happy?
What if you have to piss off your customers, for a period of time, to save the business so you can get back to making the customer happy eventually?
Or a less dramatic scenario, what if making the customer happy makes your co-workers' jobs hell, for reasons outside your, or their, control? Is customer happiness then still your singular focus at all cost? Because then you're a shit co-worker in my view.
Is your only responsibility to the customer, or do you feel any responsibility towards your co-workers and/or their jobs & livelihoods?
Life and work are messy and complicated, and everything is a series of trade-offs.
> "happy customers" should converge with "happy leadership"
This is the exact opposite of what we're seeing with Enshittification at the moment.
Customers are locked in to a platform and then made completely miserable by management who have goals utterly unaligned with customer happiness.
100% agreed.. But I still believe that over a long enough time horizon, enshittification will take those companies down. Value extraction is by nature a limited time strategy.
Most companies who choose to do this are taking advantage of a period of market or segment domination where they know users don't have good alternative options, and will tolerate some level of garbage because they still want the service or product.
Note that highly competitive industries or market segments typically don't see as much enshittification...
It is not always a yes or no. “Executive high leadership” can approve of 60% customer friendly stuff and 40% bs. And if some engineer is pouring his heart and soul to make a x% good thing that would be a benefit then it might still be rejected or worse, if engineer is in bad terms with managers he has pretty much no chance.
> I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
This too harsh. There's nothing unethical about delivering what your manager tells you instead of what you believe the customers need. Going rogue — as opposed to doing what you're told — is not necessarily the ethical choice.
IMO there are enough "not particularly ethical" tech companies are out there that we shouldn't be giving awards for blindly doing whatever your corporate overlords say. You have a choice every day what you contribute to the world.
The problem is if you deliver something and the people it's meant to serve don't know about it, or can't use it, or it doesn't actually solve their real problem, you didn't "ship" in the sense the article is talking about.
I suppose it's possible to pass all those thresholds and management still doesn't like it. But it's important to ask yourself if that's really the case or if you did something wrong and failed to ship something fit for purpose.
Some people care about the goals of the company, some people care about the company. Who cares about the company, gets promoted.
Exactly. This is basically "enshittification" [1] in its truest form.
Look at Boeing for example, I bet leadership was very happy with the fat stock bonuses and I also bet a lot of engineers "shipped" products following the author definition of shipping.
So much so that the "if it's not Boeing I'm not going" became "if it's Boeing I'm not going".
Personal take, but if you are only playing politics you are a politician and not an engineer.
[1] https://en.wikipedia.org/wiki/Enshittification
I feel that you don't trust leadership teams very much.
this is a bizarre take.
you work for the company, not for your abstract imagination of what users want. if you genuinely feel the company isn't aligned with users, then try to change that.
it's not unethical (per se, obviously don't build bombs for them) to please your employer.
In the Military, soldiers have an ethical duty not to follow an order that is illegal. It is called duty to disobey.
In civilian life, you have a duty to disobey if what your employer asks of you will unnecessarily harm people. For example, shipping a broken insecure product that handles PII/PHI/etc is absolutely unethical, and possibly illegal (though often the legal consequences are minor, if not irrelevant). Your bosses will absolutely ask you to do illegal and/or unethical shit, so you always need to be aware of where the line is, both legally and ethically.
It's not always clear where the line is. With AI work, the line has already been crossed several times (things like discrimination in output resulting in innocent people being hurt). Do not do whatever your company asks for. Do push back when you see a problem. Don't ship something that could hurt someone. If you're not sure, ask or find out.
> an ethical duty not to follow an order that is illegal
I'm not sure that has to be said, but yes, don't do illegal stuff.
You then push this question further outside the legal/illegal bounds.
Ethical is not the same as legal. Legal actions can be unethical and ethical actions can be illegal.
The Nuremberg trials established this after WW2: just obeying orders is not sufficient [0]. This is why modern militaries have a duty to disobey.
It's the same in civilian life: you have a personal duty to disobey an instruction that you personally consider to be unethical. You cannot hide behind "I was just obeying the law". You absolutely should break the law if you consider that law to be unethical. It is your personal responsibility to decide this.
So yes, you should do illegal stuff if not doing said illegal stuff would be unethical.
[0] https://en.wikipedia.org/wiki/Nuremberg_principles
That's a separate point, sure.
"soldiers have an ethical duty not to follow an order that is illegal"
And, putting it that way, a legal duty not to follow an order that is unethical.
My point is that us Software Engineers have the same duty, in my opinion. If some pointy-haired boss tells us to build something that will cause misery for our users, I think we have an ethical duty to refuse to do it.
I've been in a really stressful position for the past 6 months. Things that I would've walked out over a few years ago are now things that, for various reasons, I kinda have to choke down.
My entire concept of "what is ethical?" has undergone a transformation. It's not about my ideals any longer, or about feelings, or about how gentle or aggressive management acts in negotiations. It's about much deeper things-- like when I'm asked to support something I find distasteful, I need to really investigate whether, in context, it's actually something which violates my conscience. You know what? It almost never does.
These are the two questions that matter most in my view: 1) Am I honestly being required to do something that harms someone worse than the status quo, and 2) Is anyone around me having a medical emergency - including certain serious psychological issues - that I can help with? Aside from those two things, there's a lot of ugly crap that you can still keep trucking through.
Many people, particularly (but not only) younger ones, are oversensitive to things they simply don't like but that aren't actually wrong in any major way. You've got to choose your battles.
That seems like a very narrow-minded view of the role of engineers in society. At the end of the day we aspire to solve problems that make the world better—I'm certainly not going to fault individuals for following the money, but to dismiss the ethical dimension completely is unreasonable in my opinion.
> it's not unethical (per se, obviously don't build bombs for them) to please your employer.
What are the ethics of pleasing your managers and/or executives at the expense of your employer?
The Company is an imaginary construct. The reality is that there is a group of people with common goals who work together towards those goals. Very often those goals are simply making money by any means possible. Working with them doesn't absolve anyone from responsibility.
> I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
Hopefully there is not misalignment between satisfying leadership goals and delivering end-user solutions.
But if there is, I hardly classify that as an "ethical" dilemma for the team members.
>> I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
> Hopefully there is not misalignment between satisfying leadership goals and delivering end-user solutions.
This is precisely the situation I identified. Reproducing a quote from the article:
> But if there is, I hardly classify that as an "ethical" dilemma for the team members.If not having to choose between corporate politics and delivering solutions, then what would qualify as an ethical dilemma for an engineer?
There should be a hardware product version of this, you software people have no idea.
- Have endless arguments about what to name the product
- Have industrial design team enforce the latest design language
- Create product variant SKU numbers, get them loaded into ordering system. Get buy-in from sales on these variants.
- Create part numbers for the FRUs and CRUs.
- Create multi-level BOM for all the variants.
- Buy replacement parts and push them into parts depots
- Calculate reliability so that warranty department knows how much to charge you
- Get agency approvals
- Create packaging
- Test packaging
- Translate any words on the package into french (for Canada)
- Get vendors to sign your big company environmental requirements document
- Write legal notices and get it translated into many languages
- Work with documentation team to get printed (usually short) manual translated into many languages
- Get safety engineer to sign off on products, usually means you need to make a bunch of stickers and include them in the BoM.
- Figure out the part numbers for the power cords needed for each country
- Figure out the part numbers for the rack mount rail kits for various types of racks that you support
- Write announcement letter
- Create videos and documents for sales team training
- Write troubleshooting guide
- Train repair center
etc..
Oh boy. I've been around these trenches long enough to have seen the dark side of 'shipping' strategies.
Rarely in large enterprise environments are projects greenfields. The new system is often there to replace some existing Line of Business system.
Inthese cases the pervers but common shipping strategy is:
1. freeze all maintainance and evolution of the existing system. Seems reasonable until you realize that these enterprise projects are multi year calendar endeavours and the business will not stop changing during that time. The idea is not realy to halt all development, just to inctease the friction of getting anything done on the now declared 'legacy' system above an administrative pain threshold.
2. Commandeer all the IT staff to serve on the 'new' system's project team and overwhelm them with tasks. Make sure they remember any time spend on the 'legacy' (keep hammering in that term) codebase is basically waisting time assuring you'll end up at the bottom of the corporate dinosaur tar pit at best.
3. Force they 'new' system into production long before it is ready. Use all the leverage you build from point 1 to promise 'going forward'. When essential gaps to support the business are pointed out en mass week1, reverse the tables and intigate a very heavy administrative process demanding proof that the lacking functionality is actually required with a full ROI breakdown coutering your handwoven 3 minute overinflated guestimate for implementation. Again, you know essentials are missing, you are just trying to gain time as the longer you can stay deployed the higher the chance you will.
This process is very destructive to not just the business, but also moral of most involved. Most projects taking this scorched earth shipping strategy fail regardless. This is no small contribution to the cynicism oftem found in veteran battle hardened corporate IT shops.
Eventually someone important gets a call from a more important client on the golf course about how his company fucked up on his watch, the new thing is cancelled, the old one is reinstated (to much rejoicing) and the 15% of the huge new effort that actually worked is distilled in to a plugin feature and bolted on to the old product and everyone moves on.
The original PM responsible for all this gets an L+1 diagonal promotion at a new company and pulls this shit again.
PMO never comes out of these debacles worse off, even if the project burned dozens of millions with 0% result. It is never their fault, there are plenty of scapegoats around, preferably smaller external contracters. The threathened lawsuits with the big contracters get settled and kept hush hush as neither party wants the bad press. Just the cost of doing business for them.
Most of the time project leads can stay with the company in another division as tension with the old IT crowd woul be a bit much, and even get promoted as they 'gained experience'.
*In my experience, projects almost always ship because one single person makes them ship. To be clear, that person doesn’t write all the code or do all the work, and I’m not saying the project could ship without an entire team behind it. But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.*
Yes that is pretty much what I see as well, I see how things go to nothing with wrong people who think they can make bunch of requirements and dump them on dev/qa - then be surprised nothing works - and also how much stuff I try to hand over ends up not happening despite people claiming that they are very motivated to pick up a project. If they are motivated and I see nothing happens in 3 weeks I just take it over again and don't even talk to the guy anymore.
I am also quite often seen as an asshole because I don't ask "everyone" for permission and mostly care about my actual boss.
Whenever an architect leaves a company I work at, it is definitely felt. If your projects aren't silos then you need someone to glue everything together. You wont ship the same, and you will likely make more mistakes and everyone on call stands around confused, because nobody is there to provide technical guidance because everyone's trying to figure out how their own islands talk to yours.
The "one single person", should be qualified with 'is senior enough or with enough authority' which allows them to set aside a lot of squabbling, bureaucracy and bikeshedding.
> I am also quite often seen as an asshole because I don't ask "everyone" for permission and mostly care about my actual boss.
This speaks to me, I have often been told that I'm supposed to get "permission" to launch something from product, from my boss's peers leading other teams, from customer support, from design, from pretty much everyone. When pressed, there's never a realistic justification as to why (for example) a designer who hasn't touched the work in months should be in a position to approve a launch.
At Google, this months later permission step from everyone is a built in step in the launch process and mandatory. Takes forever.
> If they are motivated and I see nothing happens in 3 weeks I just take it over again and don't even talk to the guy anymore.
I like this sort of no bullshit attitude but at least tell the guy "I'm taking this back". Hard for your boss to have your back if you don't even say anything.
I actually meant "I am never talking with him about handing anything over" and "I am not going to ask 10x if there was no visible progress after they were swearing to pick it up" but other than that I will update the person that I am picking up tasks on my own and making progress on the thing they were "taking over".
> I am also quite often seen as an asshole because ...
or ... you really are in fact (acting like) an asshole. speaking from own experience.
I physically cringe when I think of some of the things I said to my coworkers when I was fresh out school and definitely knew what I was doing and had a much better way of doing things and they just didn't understand.
I do think it's sort of a rite of passage, especially for the dorky socially awkward kids like I was who all of a sudden have a real job and don't really know how to interact with people.
A lot of us were that. And now that we’re senior we have to recognize it in the youth and guide them to maturity instead of firing them, as our seniors did for us.
there's no reason to believe you're now relatively wiser compared to 10 years ago than 10 years ago compared to 20 years ago :/ which is why in another 10 years you'll probably think how stupid it was to believe you can guide a young asshole and should instead have just fired them. just speculating.
If you're not relatively wiser than you were 10 years ago, what the hell have you been doing the last 10 years?
I don't think you should automatically give younger folks a pass for stuff like this (I don't think the GP was suggesting that, either) but it's also probably a good idea to approach working with a 22 year old a bit differently than you would someone in their 30s, and both differently than you would someone in their 60s.
Oh the irony
#remindus 10y
This sentence is a good one for those who often are that person and wonder if there might be others like them out there.
This is a reasonably good if somewhat depressing blog post about how to do well in the performance cycle at a big company. Now part of that is shipping product, but that’s pretty clearly of secondary concern for the author.
It sounds to me like this person is good at getting paid no matter how it goes for the shareholders or the rest of the team.
When I worked at a big company I did a lot of mentoring and the dissonance between what people I mentored thought was the "right thing to do" and what it seemed like the organization wanted them to do (enforced via performance reviews or other mechanisms) was a huge hurdle for new engineers. Especially early in your career you're just one engineer in a huge org and most people eventually decide it's easier to go with the flow than fight against it (or they leave) but it was a struggle for people to get there.
This post seems the logical conclusion of that. Why spend your time and stress doing work that your boss doesn't appreciate? Just give them what they want, it's their job to align that with greater organizational goals.
All this being said I did not love working at a big company, partially for these exact reasons.
Not sure if / who am I quoting, but this thought isn't my for sure: the more layers of management the company has, the more times the incentives are inverted between the planning at the very top and the implementation at the very bottom.
It does often feel like Chinese whispers to the people at the very bottom: the orders make no sense whatsoever due to the distortion coming from the middle management. And, I totally agree with your assessment that OP sounds kind of sarcastic about the whole thing. Also the way they phrase it suggests it: it's not even what your boss wants, it's what's going to make your boss happy (if the boss is an idiot, they might want things that will end up making them feel sad, but that only makes your job harder as now you should also anticipate what would actually make them feel happy rather than dully following their advice.)
I think you’re describing any person’s life within a larger social construct.
I don’t see how you can achieve any meaningful goal without collaborating with people in power.
> I don’t see how you can achieve any meaningful goal without collaborating with people in power.
Depends on how you define meaningful. Raising happy & healthy kids, helping someone in need etc, can be meaningful to many people, but don't require 'collaborating with people in power'.
But it does. At the very least, you need to keep paying off the people in power and do everything within the framework of their rules, otherwise you’re in trouble
I’m fairly certain you can go live somewhere off-grid and do everything however you want.
It’s only a tradeoff if you also want all the convenience of modern society.
there is no "off grid", and even then those homesteaders aren't building houses themselves with tools they crafted themselves -- they're 100% dependent on tools and skills they learned in society.
even remote and rural they're often still trucking into town weekly for gas and groceries.
source: in laws in rural AB tried homesteading off the grid. all it meant was that their kid was homeschooled and can't do multiplication and they learned how difficult farming is.
> live somewhere off-grid
That's the thing, the grid covers everyone everywhere now. There is no escape from the planet of the apes.
Not really. It's just that people don't realize how much they rely on modern society. You could go all Primitive Technology and go live in a mud hut somewhere or whatever, nobody's forcing you to buy toothpaste and electricity and all that stuff.
The problem is that sucks, so people don't actually want to live off grid. They just want to not work but also get the benefits of modern society.
I'm fairly certain statistically you can't, because you need a place to go do that, the skills to pull it off, and have a family that's not only willing but actively supporting it, otherwise when the reality kicks in everything _will_ fall apart. Either that or some of you die. But hey, technically you'd be correct in that case.
Or maybe I just have a gloomy view of what "living off the grid" looks like :] I'll just leave this [1] here, regarding that.
[1] https://www.smithsonianmag.com/history/this-russian-family-l...
> but don't require 'collaborating with people in power'.
You missed this qualifier: "person’s life within a larger social construct."
I did not get that from TFA. I interpreted it as "know your customers and communicate with them". This applies to everything in life. It's especially relevant in big companies because it's easy to forget that you are forgettable.
I mean, if by "customers" you mean "the important people at your company".
> Concretely, that means that a project is shipped when the important people at your company believe it is shipped. If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship.
> 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 mean, if by "customers" you mean "the important people at your company".
I think that's exactly OP's (and TFA's) point: If you're working in most medium sized to large sized companies, just look at your org chart. Your manager, their manager, their manager's manager, and so on up to the CEO: Those are your customers. They are the ones that decide your comp, they are the ones that set your priorities and goals, they are the ones who are ultimately accountable when you fail or succeed. Your job is to deliver what they want. It's definitely a hard pill to swallow if you still have that idealistic view that you're working for end users.
You're not wrong. I think the issue people have with the post is that it disguises, to exaggerate a little, bootlicking with shipping. The recommendations are good for the reasons you mentioned, but job security or compensation maximisation are not the same as "how to ship things". If that happens to be the thing you do, it's a means to an end (to demonstrate you do your job well) but that's not the goal of shipping things by itself
But then, definition discrepancies are the origin of at least half the disagreements
I mean, being misaligned with company leadership is a great way to loose your job. I worked at a medium sized company which is known for having a good culture. Everyone was kind & helpful, there was loads of autonomy, never any kind of layoffs.
At some point, a team I worked closely with got unexpectedly fired. The entire team, including manager, just gone one day. Not for financial reasons, but because they were “not performing well.” (There were multiple people on the team who had consistently good performance reviews.)
I spent a fair amount of time trying to figure out why that happened. Obviously if that could happen to them (fired despite good feedback), it could happen to anyone.
As far as I could tell, it’s because the CEO or CTO didn’t think the type of work they were doing was worth doing, and also didn’t think they were making a difference.
It’s good to be a self-starter, to advocate for best practices, and to keep users in mind. But at the end of the day, if that doesn’t fit into what your bosses expect from you, you’re done.
That’s why it’s important to communicate with stakeholders. Your boss needs to understand why spending time on preventative maintenance pays dividends on the long run. You can’t spend 75% of your time on stuff that doesn't look productive (which is subjective) and also not be proactive in being on the same page as your stakeholders about what’s important. At some point, they’ll get confused about what you’re actually doing day to day, and your job’s on the line.
> As far as I could tell, it’s because the CEO or CTO didn’t think the type of work they were doing was worth doing, and also didn’t think they were making a difference.
So the CEO/CTO weren't able to express their concerns and priorities and instead just fired the whole team?
If, as you say, there were no financial reasons, then the team could've been re-purposed to do more meaningful (at least in CEO/CTO eyes) work.
You are coming from a rational position with the focus on optimization. Large organizations are not rational, and rarely optimal.
Executive backlogs are so deep that purposefully re-fitting whole team to another job will never end up on the top list. You might see sometimes organization will rehire a whole new team with exact same skillset, and set them to do similar tasks. It happens because execs know how to setup things from scratch quickly, but running a re-fit is a custom project that requires problem solving and large amount of exec drive, and exec resources are extremely scarce and expensive.
From the outside this will seem totally irrational and suboptimal, not to mention unfair. But that's how large orgs operate.
IME working as a team in large companies is dangerously entrepreneurial. What I mean is that there is loose guidance on what needs solving and then it's up to you to figure out how to solve using what you have. If you stray from the original problem too far, you'd better be good at explaining why. It's dangerous because there's a lot of autonomy with the illusion of security.
Keep the original problem in mind always. Keep your head up looking out for competitor teams who might be solving your problem. Know them, align with them.
If you show up on an exec budget spreadsheet and the exec can't defend your value, then you're toast (or transferred).
Now imagine, the product being 50 % income generator at start, but a liability generator of support cost in the long run. Means, you launch the product and its success kills you over time as a bloated giant. All we ever had todo, to be more succesfull, was sell more of the product... famous last words
do you have an example of this scenario? I mean reading it, sounds true but then support is mostly determined by the company's willingness to support (outside of some legal requirements) and so I find it actually difficult to imagine where selling more of the product is a great income generator but the support actually kills you (destroys company) in the long run.
In software at least support costs can be decreased by fixing bugs or identifying high support low value features.
So - I would like to see a company that actually got killed by support costs but was doing good from product sales.
I think most social media counts as such, with the specific example in my head of Twitter only making a profit two years before Musk bought it, cut it to the bone, and increased its legal troubles.
Income starts off proportional to number of users and how much they use it.
Support depends on how many people are anywhere between unpleasant and unlawful.
"Unpleasant" is like weeds, if you're not keeping up they take over and keeping up becomes harder.
"Unlawful" can suddenly get a lot more complex when other legal jurisdictions notice you and (sometimes with or without changing the law because of you) remind you that anyone operating in their jurisdiction must follow their laws and not whichever one you put in your T&C — constitutionally guaranteed freedom of speech in one country can be constitutionally unlawful speech in another.
> It sounds to me like this person is good at getting paid no matter how it goes for the shareholders or the rest of the team
The trouble is that your personal influence is remarkably small in most workplaces. Ultimately, you can't change much, and what you can change takes a lot of effort. It often requires being bullish, which can introduce risk to your job.
Sometimes, the choices are as follows: either have the big idea in mind and always strive for the best, sacrificing your mental health, making enemies, and potentially losing your job. Or, keeping your head down and following orders, being a perfect little sailor leading your ship towards the iceberg.
He is probably good at getting paid and getting credit for what he does, but he would need to be good at it to do any good for any other stakeholder, even more than he would need it to be a happy parasite inside the company. We don't know from the text if he cares about benefitting other stakeholders; I would bet that he cares more than average or he would not openly admit various unsavory facts about how things actually work - there's nothing in it for him to be open about it and the typical bigco parasite is unlikely to be open about these things and instead will repeat the party line about the place being a perfect meritocracy.
This mirrors my views. In sports, winning fixes all problems; in software, shipping solves all problems. You need wins, and you need to ship. It’s like in Glengarry Glen Ross: instead of “ABC—Always Be Closing,” it’s “ABS—Always Be Shipping.”
You’ll never ship a perfect product; no such thing exists. But if you ship early (and incomplete), users will be delighted—and often change their minds about what they want. That’s great, because you didn’t spend forever on their initial (flawed) requirements.
This is called project management, and in my experience seems to be a practice/discipline that's often overlooked or ignored at startups and scaling tech companies.
Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working.
Doing this in an agile manner generally means smaller projects, one at a time.
The last "agile" shop I worked at instead did 10+ small projects in parallel (1-2 devs per project) and then wondered why we never got to where we wanted to go.
In contrast the last really fast-moving place I worked at has 1-3 devs per project but they were entirely 100% in charge of technical design, building it, shipping it, and maintaining it. If we wanted to wait to ship, we waited. If we wanted to ship early, we did it. I'm in an org 3-4 times the total size now and we move at half the speed.
That sounds great for moving fast, but not so great for sharing and keeping info about these projects. If/when someone quit, how would their projects get split up for other devs to maintain?
It definitely had its downsides especially for the 1-dev projects. In reality it wasn't that bad. Code reviews usually pointed out where documentation was needed or would be helpful, and everyone was just senior enough where you could give them a feature ticket on one of these small projects and reasonably expect they'd be able to just figure it out if they had to.
Outdated or missing critical documentation, or too junior (or too lazy) coworkers would definitely have made this approach fall apart and that's a big risk of it IMO.
Which is precisely the opposite of the entire intent of Agile. Take one small thing, get it done. Done done. Then decide what the next thing is, then the next, based on what you learn from that one thing.
Unfortunately, too many people can't be arsed to actually understand things like the OODA loop, Cynefin, and the other things that describe precisely WHY that is a good idea. But hey, they do standups.
One place I worked at did that + only 1 person per project and all projects got rotated between developers at the start of every week on Monday. And when we did stand up meeting every morning nobody cared what anybody else had to say cause we all worked in different projects. Go figure.
Yes, exactly the same with the rotation.
It was almost like they were optimizing for bus factor.
It was completely brain scrambling and unsatisfactory work as it was constant musical chairs.
If I were you I would have left immediately.
Maybe not the rotate projects bit but I’ve worked on plenty of teams where everybody is doing something different. Sometimes it is because they are spread too thin other times it is because each project individually can’t really be swarmed on and is really a solo adventure.
Rotating between each project on a weekly basis, however, that seems awful.
I don’t think I’ve ever worked with a project manager who wasn’t a total pseudo jobber. That is to say, I have worked with some wonderful project managers, but they got things done rather than “manage projects”. They’d be hands deep in Active Directory, weird json stuff to help find issues with OCR or working on change management and training when a new system needed to be adopted. But the whole “agile” side of project managers, scrum masters, IT business partners and so one have always just gotten on the way.
Usually what happens is that they become middlemen that can’t actually relay information between developers and the businesses. As a result developers and digitally inclined business people tend to talk to each other directly while they let the pseudo jobbers waste everyone’s time because… because it’s “best practice”.
Hah. Especially rich when you consider that the whole “agile manifesto” was thought up and sold by people who haven’t worked in software engineering since 20 years before Python even existed. Of course it doesn’t work. Not because any part of it is particularly bad, but because every part of it is extremely vague and completely unfit for reality. If you follow any sort of practice which isn’t YAGNI religiously you’re going to fuck up.
Projects ship because one of the people who do actual work gets fed up with all the bullshit and simply does what needs to be done. All the “project managers” and other role players are only there because SWE management is full of people who can’t code anymore. You don’t see all these pseudo jobbers in IT operations, and you don’t because SysAdmins want to be SysAdmins.
This may shock you, but companies actually need people to do things other than code. There's some strong "junior developer" vibes in this last paragraph, not realizing that SWE management and project management are spending their whole day making sure that the code you're writing is actually what the company needs, and they're not just lighting money on fire by employing you.
Just because someone "can't code anymore" (arguable premise though that is) doesn't mean their job is automatically bullshit.
It’s two decades of experience speaking. I didn’t speak about managers though. I was a manager for a couple of years before my undiagnosed ADHD made itself know when I had my first baby. Management has nothing to do with project management. I’m solely speaking about the horde of pseudo jobbers who work as middlemen between developers and whatever it is that developers are supposed to do. I’ve never encountered one which wasn’t a waste of resources except for business process and lean consultants who would actually do change management on the business side before anyone attempted doing any form of digitalisation.
I probably should have said “won’t code anymore” because that is what I meant. It’s the developers who become project managers, architects, agile whatever. Luckily I don’t have to deal with that anymore because I’ve become specialised in helping startups in-fuck their chaos as they transition into enterprise organisations. Many of them never make it because of how their internal processes are hindered by all sorts of “best practices”.
This doesn’t mean that there aren’t excellent project managers out there. As I said, I’ve worked with some myself. Far too often project managers don’t actually do anything. I recently worked a team which has 1 PM, 1 Manager, 3 IT business partners and one architect in front of two developers. Today they have two developers and one IT business partner, who’s really an accountant that got into coding because he liked it. But is now capable of explaining the business to the developers.
It’s obviously not like that everywhere and I’m happy for you if you’ve had a better track record than me. I would argue that it is perhaps you who lack the experience that you seem to think I do. Because it’s not just on SWE you’ll find an abundance of bullshit jobs once an organisation reaches 100-500 employees.
It's usually easier for a technical "tech lead" to pick up project management than for a project manager to pick up "tech lead" (deep technical) skills, but exceptions exist.
The tech lead should have better business understanding than "currently needed" and ideally be supported by a domain expert (business analyst, product owner).
A project manager may support the tech lead to ensure the project's output ships.
This matches my experience - I was intentional about not saying that a project manager was important - just that project management (the practice) is important.
>Generally in my book projects should only be assigned to teams
User stories are assigned to teams.
> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped.
Well now, hold on a second. You didn't tell me this was about consulting.
If we're being paid like pirates and fightin' like pirates thats one thing.
I shipped something users (internal) loved and the users were pushing adoption across the company. My leaders didn't consider it shipped. They never talked to the users. Didn't care. It needed perfect alignment with the org and needed to help the org's plans. Not the company or users across the company.
I'm not sure this demonstrates the issue without more context. If the people meant to use it were happy, what problem did the "leaders" have with it? Was it a huge moneysink whereas it was supposed to be an extra income source or like what kind of issue even
The users were happy, but you didn't get paid, or got fired for using company time out of assigned scope.
Excellent article. I'm going to pull out one point out of many that made me think:
> Project competence. You want to aim for something like a NASA mission control vibe
Having read a little about early Apollo-era (and earlier) mission control this was a fun comparison. The astronauts and flight controllers had no idea what they were doing! There was no textbook – they were performing a human first. They were generally young and very cocky people hired out of university, but were successful anyway, for some reasons, including:
1. They were further culled through harsh adversarial simulation training. This made sure only those that could cut it came out the other end.
2. They approached each new mission phase with a trial mission, each time extending the envelope in a controlled manner. (The cowboy moon touchdown on Apollo 11? It's often described as the first moon landing, but it really wasn't. It was just a test to see if they could reach the surface and get back up. The real first precision landing came on Apollo 12. Oh, but that was also just a rehearsal for the first scientific mission on Apollo 14, etc.)
3. They were fluid in how they organised themselves, and allowed mission needs to dictate which positions existed, rather than trying to impose a hierarchy onto a mission.
Going back to shipping, we can squint and look at this as:
1. Fake it, either until you make it or get tossed out.
2. Prefer to ship many smaller things than one big thing. This builds confidence in your abilities, gets you experience shipping things, and allows you more feedback to adjust to what the real project is.
3. Build coalitions across department boundaries, and draw on their support to ship.
Analogies are like scissors: more fun when you run with them.
Agree strongly with your entire comment, but am _definitely_ stealing that last sentence, it was quite a sharp take.
> fact, it’s paradoxically often better for you if there is some kind of problem that forces a delay, for the same reason that the heroic on-call engineer who hotfixes an incident gets more credit than the careful engineer who prevents one.
I could really relate to this. Having been part of incidents, I fucking hate them and try to anticipate them with various safe deployment strategies. To leaders though it apparently seems like Im not doing anything because “nothing ever goes wrong” lol.
> To leaders though it apparently seems like Im not doing anything because “nothing ever goes wrong” lol.
They are not leaders. They are managers more akin to administration or HR.
Think a lot of comments here (in my humble opinion) have taken the wrong interpretation of this article. Don't think this is a project-manager role, but is, as stated, typically a "tech lead or a DRI role." This means this person is still technical - would like to think this is how I approach my projects at a company and it is super effective.
Specifically then, as a technical person, this means you don't ignore the requirements and just think about the code. Instead, you need to communicate with both your higher-ups and your end-users, in order to make sure the code you're writing matches their needs - in my opinion, requirements is the part that most developers are weakest in, but if they strengthen would make the biggest difference. Get it as close as possible to being right on the first time (it's very rare that this happens but focusing on doing really good requirements increases your chances that you don't create the wrong system).
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
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.
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.
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.
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)
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).
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.
>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.
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.
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.
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.
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.
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.
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.
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.
The article does not claim to be about shipping software but about sipping software in Big Companies.
> 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.
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.
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).
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.
> 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.
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.
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.
Shipping is ... milestone hit on program management.
... At a big company.
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.
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.
> 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.
This article is an expert-level primer on office politics in big tech masquerading as a primer on delivering software.
Yes, and because of it alone, I consider it one of the best articles of this year read by me.
Agreed, as a green/still inexperienced employee it was quite a good read.
a project is shipped when the important people at your company believe it is shipped
Definitely. This can work very much to your favour.
There have been times when I have happily shipped a product containing issues and bugs that would be catastrophic for any customer using it, because I know that no customer actually ever will. The product is shipped and released, everyone is happy.
The catastrophic issues won't ever come up because that shipped product will never be used by anyone.
Big people are happy because the product is shipped.
Team are happy because big people have stopped causing so much friction in their desire to ship.
When the measurement becomes "have we slapped the label shipped on it", then that's what you get. A label.
It will become the headache of future team members that have to debug it when it inevitably crashes four years in the future, or needs to be rebuilt or the deployment moved.
Now personally I am fine with this, being that person. I will cause friction however. Unfortunately it is the new big people that take the hit from the previous big people. But such is the way of the world, this is what we are paid for.
Sometimes you get lucky and can shut things down. Then you get to celebrate that as well, shutting down the thing nobody ever used but everyone celebrated “shipping”. At least I get my celebratory cake!
this mirrors my experience, but it doesn't give much actionable advice and probably only rings true to those who have experienced the same motions. "You only know your project shipped if your leadership acknowledges it". Yes ok great, how do you get their attention. I think this piece could be more easy to understand and influential if the author included a specific IRL project as a case study instead of having a bit of memoir about the vibes of their experience.
Internal Marketing is the primary role of the Product Manager at a lot of big companies.
And this is why it sucks so much to work as an engineer on big companies.
You're not even able to do your politics effectively without a middleman that can easily undermine you.
The only path to career advancement to this is to job hop as much as possible.
The author just shipped the post
We can't be sure of that -- what did their boss say? That's all that matters.
If they aren't paying attention then move to a project they /do/ signal interest in with their attention, and ship that.
> Yes ok great, how do you get their attention
I'll tell you my own personal experience here: Go talk about it!
Depending on the culture and rituals at your company:
- Ask for a spot at an all-hands meeting so your team can showcase what you shipped
- Record a demo video of the team's work and share it in Slack/Teams/Yammer
- Write a post-mortem or internal blog post about the impact that your "ship" had on the business.
- Etc...
I'm a firm believer in the concept of "internal marketing" in big companies. I've had leaders and mentors repeatedly tell me "no one will recognize you in a big company if you just sit around waiting for the recognition"...
You have to put it out there and talk about it and show it off...
And yeah, I know a lot of tech folks hate doing this.. But in my experience that's how you play the game in an honest way... Find the right time and place to be proud of your work and show it off.
Yeah, I agree this post would have been better with a concrete example. It's hard to talk about a specific project though, since it comes down to describing in detail facts about a company's internal workings (often embarrassing facts). I couldn't figure out how to anonymize it sufficiently.
I see so much backlash against Project Managers and they're just Outlook Calendars with legs, but this post is basically a love letter to good Project Managers/Release Train Engineers/Delivery Leads, whatever you want to call it.
I think the problem with those is that they lack understanding author mentions:
> But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.
The reason people hate specialized roles of scrum masters/delivery leads is that they often lack the E2E understanding and therefor are inadequate owners.
Yeah but a good technical PM / whatever will have that understanding. Not a role that just checks milestones and statuses.
I remember a manager that we worked with, once stating that "Shipping is the #1 feature of this software."
I have been shipping (as opposed to "writing") software, for pretty much my entire adult life.
A lot of it has involved holding my nose, and gingerly handing it off, dangling between my thumb and index finger, while wearing rubber gloves.
This chap has a point. "Ship" is in the eye of the managers.
Which is why good management is so important.
I kid you not, I've seen managers claim that v1 is shipped while no software was deployed at all (it was just the production environment). All this just to say the project is on schedule (it wasn't !).
I've also seen in the same company rushed QA (like ignore the guys) in order to ship faster to meet the managers' KPIs and bonuses.
So yeah, shipping a project probably means something different than most developers think.
> Sometimes it’s just an influential VP or CEO’s pet project, and you need to align with their vision.
My biggest career mistake was a project that I had no way to know was the CEO's pet project.
Can't say where (non-disparagement agreement), but oh boy was that a lot of messy fallout — QA awarded me a prize for least bugs on launch, yet at the same time line manger also immediately went from giving me bonuses to putting me on a PIP for having too many bugs in launch.
optics. If the CEO is reporting bugs they find or those bug numbers appear "concerning," the apparent lack of quality calls for corrective action.
Obviously things were not the healthiest there. The CEO should be similarly interested in other projects and their quality. Your manager should be aware of the relative quality and your award and tell his manager that "it has been / will be dealt with" and then to either never file the pip or speed run you through it (while letting you in on why: optics). And then the manager should be working towards producing better reporting metrics that executives can use that expose quality issues at large
> went from giving me bonuses to putting me on a PIP for having too many bugs in launch.
Dont you have some kind of tracking to show the bugs were not in your code?
Least bugs, not no bugs.
I'd like to say I can code perfectly, but I'm a mere mortal not Donald Knuth and I can't get away with saying "Beware of bugs in the above code; I have only proved it correct, not tried it."
We had tracking of launch bugs, the manager ignored the evidence — that didn't make any sense at the time, then I developed a better understanding of office politics and suddenly it became easy to understand.
When I'm shipping on a deadline, one of my favorite things to say is, "there is no future". When someone says they want to do X because they will do Y in the future, I say, "There is no future, there is only shipping. Give me what I need to ship and then we can talk about the future."
Pigs can fly. I know this because if it's got to ship and it's a pig, then sufficient thrust will be brought to bear to achieve flight.
Shipping is some liminal space between sheer will, recklessness, and tautology. It ships because it has to ship, because to not ship is to fall, and failure is not an option.
I love the example with pigs haha!
This is amazing satire. It's like the CEO of Hooli had a Senior-Senior-Senior-Senior-Engineer blog.
(more amazing: 54 ships, but not a single leader-ship joke. that takes nerve.)
I don't think it was meant as satire. I didn't like to read it, but it resonates with my experience working at big companies, like many others here.
Learning how to cancel, or quietly bury projects, can be just as important.
You're quite likely to be handed projects that make no sense. Bad ideas are created every day. Even if you ship them, you may be associated with their failure.
Even what he said is valid for most big tech today, it is still a reflection of how messed up today’s tech jobs are.
Yes! And the most interesting thing here, to me, is how the crowd splits in two groups: one group basically saying "That's how it goes, if you wan to get paid (and you're not intelligent if you don't) you need to play this game, even if you don't like it" and the other saying "This is unacceptable. We need to first recognize that the state of things is not good, so that we can then act and change them. So let's start by stating that this should not be accepted. It's wrong to accept it".
I belong to the latter group.
What is the alternative, though? This is an honest question, I really want to know: How would the "this is horrible, how can you deign to work that way?" crowd coordinate thousands of people on a project to create something that is bigger than what 5–20 people can create?
Because most of the answers I see here gloss over that part, or strongly imply that engineers will always decide better than business people what should be released. And I can sympathize, especially if you are in an MBA-led org, but I am also certain that if you think you know perfectly what the enterprise or customer needs, and anyone opposing you is a Pointy-Haired Boss, that you are most probably the idiot in that case: 90% of the time a single dev will NOT have better business intelligence than everyone else.
> What is the alternative, though? This is an honest question, I really want to know: How would the "this is horrible, how can you deign to work that way?" crowd coordinate thousands of people on a project to create something that is bigger than what 5–20 people can create?
Nobody needs to be co-ordinating thousands of people. 5–20 people can create Instagram. The entire problem in these companies is that leadership is so out of touch they cannot differentiate between a checklist and a product, and empire-building is their proxy for value. The solution is to change the leadership, but it is usually too late in large orgs (the new leadership has to be brought in somehow from somewhere, and that will be done the same way the current leadership happened).
So the real solution is for those who care to go elsewhere, out-compete, and out-succeed. Then quit after acquisition, if such a thing happens.
I think the first group is more of “this is how it is” rather than “you’re not intelligent if you don’t play the game”. I personally don’t find this status quo good or healthy either, but I(or anybody) have little control beyond formulating policies at a company at best, and changing their job realistically. (Fortunately my current place seems quite decent in this regard so I’m good/lucky.)
Agreed. What I am a little surprised is that some engineers seem to trying to defend something that is knowingly bad just because it is the status quo.
BTW, I don’t think catering the upper management as described is the only way to get paid. I ignored many upper management’s preferences because they are plainly stupid and in some situations get fired. But I still made good career growth and so do many of my friends. In fact being in a conflict and holding position tends to give me higher rate of returns, even in case not being able to “ship” as defined in the op.
I wonder, given the year is divisible by four so it is on the mind, I wonder if that divide of "acceptance of what is and working with that" vs "we can be better if we make it so" is also the divide that manifests between the two political party system in the US.
They ship because they do project management right:
1. Focus on stakeholder management
2. Know and understand what you build end-to-end
3. Because of 2. you can quickly assess the impact of various options to resolve a problem and communicating this back to stakeholders, generating trust
I like the example of 3. In the blog post.
So many people run projects like they just coast around. Never a moment to pause, reflect and proactively thinking about potential risks and possible mitigations.
Oh my, we never saw this road block coming, how could we have known? Well..
100% relate to this!
Some of my observations:
- Often it is about taking a leadership & ownership of fixing if it fails in the production
- Often it is about, guiding team not to overengineer for the future scenarios
This becomes 500% difficult when you are building for someone else:
In our current scenario, we are working with a semi-government organisation who goes by the RFP fine print then an actual project needs.
I effectively agree with the "destination", so to speak, of this post, but disagree with the path taken to get there.
In general when I ship projects in the context of the org I with for, I _do_ meet the requirements of higher-ups/stakeholders, but not because that's my goal -- but because we're aligned on those requirements. Shipping to make management happy feels kind of incestuous, you should be shipping because you and management both agree on what the end goals of the project are.
This might seem like a subtle distinction, but it can create issues. If you're using your management as your metre-stick without truly understanding and believing in what they want, you'll likely over-optimize for the project's goals that they've stated, but miss the target of actually making the project successful.
This approach is fine if you're primary goal is to get paid, get promoted, please your managers, etc. But if your goal is to create great things, I think you need set your metre-stick based on the project not on the management. From the outside these approaches look very similar -- which is why I largely agree with the "destination" and a lot of the tips in this post, otherwise.
As any worthwhile piece of advice, this post is not saying "Do good things, don't do bad things" but instead "Prioritize one good thing over another". Hence lots of comments. I wish there were more submissions like this.
The post is not about engineering, hacking or programming, but pleasing management.
I wish there were less submissions like this.
The reality is that it’s just the way life/“the game” is. I think it’s good to know about such things, it’s still very much up to the individual to use it/not get fired etc. Unless someone lives alone on a farm, they’ll likely need to know how to handle such things at some point (or be very lucky, or possibly suffer).
It's a post about getting your software recognized and used. For that, you actually need to get other people on board, yes. If you don't care about that, why are you even working in software development? It sounds tedious to just build things nobody cares about.
Articles like this are off to me… you’re going to need to quantify and qualify your claims of things otherwise I don’t know how much credence to throw ya.
“I ship at big tech” is a broad statement… as a reader, I need elaboration or I tend to question the rest of the article. Is this just a guy bloviating or does he really know his stuff? And bold claims need to be back up.
Resume is here: https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaA...
Looks like: ZenDesk and GitHub are the "big tech".
Projects shipped look like:
Thank you for looking that up, I was on mobile and being lazy. So it looks like he’s done some decent sized stuff.
Or claims to have done so ...
This hasn’t been my experience at Big Tech (in ~20 years). There’s plenty of projects I’ve shipped that didn’t have upper management support but after the user feedback or metrics were positive they got counted as a win. There’s also many smaller projects that you can ship without anyone paying much attention but they can still be valuable either to some subset of users or in aggregate. For example, +1% on some metric isn’t going to get you a call out from the VP but do that every month and now you’re talking about big aggregate gains.
This is what purgatory looks like for software engineers.
If you work at a company like this where leadership does not understand the engineering, the value, or the consequences of their reports but only want to talk about it at review-time, you are not in a healthy environment with an actual leadership.
And you will feel the toxicity created by this kind of poor leadership by way of constant blame games, misalignments, and unnecessary stress over garbage.
Feels like my current place. To use OP's language: if you have shipped and leadership knows about it, but also does not care, you have not shipped. Unfortunately it turns out there's no way to make them care, in my case.
That is, however, true of almost all of the big players. If you want the security of the big paycheque every month, you do the deal with the devil, so the speak.
> That is, however, true of almost all of the big players. If you want the security of the big paycheque every month, you do the deal with the devil, so the speak.
And you will pay the cost of it with time, physical and mental health, and career longevity.
Ultimately you are signing up to be servants and servants are not valued within or outside the organization.
Regarding the “realism” proposed here, that leadership defines what shipping means: there’s a good faith and bad faith interpretation.
The bad faith interpretation is that this is corrupt and misaligned.
The good faith interpretation is that each leader has context and motivations that are important.
The right interpretation depends on the exact circumstance.
Getting leaders aligned on the right definition of “shipped” is a separate problem to the one described here, and it’s not the project lead’s direct responsibility. It’s the responsibility of the leadership team, the CEO, and the board.
But the realism proposed in the post is useful for project leads. Meeting leadership’s expectation is not necessarily corrupt, and if it is corrupt, it can be improved by directly discussing and negotiating what it means to ship a project.
A key point of this post is here:
> you have to get clear on what the company is looking to get out of the project.
Regardless of politics, starting with why we are doing this project at the first place is often overlooked.
> Can we ship right now? Feature flags are the best way I’ve seen to do this, but staging environments also work, and so on.
Feature flags are a super weapon if you are trying to keep the path to production clear, especially if you have a diverse deployment or customer base. They don't have to be a constant binary value either. I've set up "flags" that were SQL queries which produced the actual boolean fact based upon customer-specific data and requirements.
These things do tend to accumulate, but cleaning them up is easy as long as you have a way to report on the current configuration across all deployments. If two or more instances have different settings but their users seem happy with this arrangement, then you go the other way and promote the flag into some kind of official configuration abstraction.
Customer and environment specific branches quickly become a death spiral if you are trying to grow a B2B/SaaS product. I'd much rather fight a spreadsheet of flags & config than rebase branches and resolve conflicts that have silently piled up for the last several months.
> as long as you have a way to report on the current configuration across all deployments
This seems to be the hard part. Some of our deployments are not generally accessible to us.
The idea of “shipping” as being an emergent state of mind is a great one. A project grows the same way an embryo grows into a full animal: it does so in millions of tiny parts that overlap in discrete ways to produce a continuous spectrum of development. I think some good additional milestones to measure that kind of development might be as follows:
* Your first bug report that you file against yourself which you fix yourself. Your project is stable enough to be usable with a known bug, but you go back and fix that bug when you have time to dedicate to it. Contrast with nothing working until everything works.
* Your first time seeing someone find a flaw that lies so far out of your own mental model of the project that it causes a very jarring feeling, hopefully followed by excitement that the project is now taking on a life of its own outside you / your team as the sole developers and users. An example of this might be someone filing a bug that image rendering is missing from a git visualisation tool where you’d never even considered using it for projects with version controlled image assets.
I feel like there’s an analogy here to a baby’s first detectable heartbeat and a child’s first original that-never-occurred-to-me thought. There must be a lot more in between too, with the social acceptance of a project becoming shipped as the child entering the adult world as its own person.
If you want a different but equally opinionated perspective of how to ship at scale, I really like Herb Sutter's FAQ on why the C++ standard ships every 3 years (from 2019): https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...
> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped.
True, but that doesn't mean you have a good leader. They are hard to find, but not impossible.
> no matter the project goal, your leadership team (the people in your reporting chain who care about the project) will always have basically zero technical context about the project compared to you.
This is not universally the case, and I've been much happier when I find teams and orgs where this is not true.
Good leaders understand the details. Find them. Be one.
This reflects my personal experience as "CTO" of a software factory. I put CTO between quotes because my role definitely shifted away from technology itself more to a delivery role. I have to delegate responsibilities to the right people, act fast when a team member is pulling its weight, allocate resources to solve problems a team can't, and even jump in and work along the team if shit hits the fan. Delivery is the hardest thing; something that works for me is trying to have a plan and not only consider features but a checklist to reach Prod. What I mean is adding all those tiny things that add up to the planning (who's in charge of the DNS? who's setting up the Twilio account? etc etc etc)
Yeah, I think TFA gets a lot right about doing software engineering in large orgs.
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)
Great article. It's not "shipping" as in making some feature a reality, but more contextualized within big tech and perhaps larger sized companies. Understandably, some people might call this "unethical", but it's kind of a "game" that you play (or don't) being in a large, hierarchical org.
It's a self promotional advert blogspam.
> But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.
In the before times, we called this an architect. We're too agile for that now, apparently.
No, in the before times, we called this a project manager.
The project manager worked closely with the architect, but the architect focused exclusively on the high-level code/engineering part, not the end-to-end understanding of the whole thing that involved management, partners, corporate processes, approvals, etc.
(And note the distinction between project manager and product manager, two entirely different jobs. Project managers stereotypically use Gantt charts to focus on timelines and contingencies and processes; product managers focus more on user needs and product-market fit.)
Now, that responsibility has been dumped on Tech Leads, who have neither the power of the Project Manager, nor the responsibility of the Product Manager.
And depending on how your company selects Tech Leads, they might not have the technical ability of an Architect, or hell, even a senior engineer.
That's because they're an engineering manager in tech lead clothing.
It's so the company can say they have more engineers and less management, but still fill all of the roles that they need managers to do.
(I've written elsewhere how you can run without engineering managers - see https://www.ebiester.com/agile/2024/03/31/a-world-without-en... - but the roles that need to be filled don't stop.)
I'm the living example of this. I'm an engineer who thought he's signing up to be the TL to design the architecture and implement the hard parts, and at some point I realized I'm doing a terrible job because in reality I'm just EM-ing this project 90% of the time, while my manager is busy with something else.
I've learned the lesson the hard way.
As a Staff Eng, I strongly related to this. At big tech in Silicon Valley, the Tech Lead archetype does tend to do all the Project Management and, depending on whether your team can afford a Product Manager (eg. Infra team), some or all of the Product Management.
IMO, it's a little unfortunate from a productivity perspective that you have a high performing Engineer also running daily/weekly syncs, doing stakeholder management, and doing upwards management for resourcing. From a personal learning perspective, it's great though. You, as Tech Lead, learn and hone a broader set of skills and not only the Architect or Senior Engineer skillset.
I thought this was only happening in academia
>And note the distinction between project manager and product manager
And then there's the product owner.
Agree on the role distinctions, but the best people in any of those roles will be able to see/do some of the important factors in the other domains and ask questions like "so what does success for this project look like?"
> Project managers stereotypically use Gantt charts to focus on timelines and contingencies and processes
...and dependencies between teams/stakeholders. :)
Ok, the before-before times then.
When a company does not want to pay (or empower) a principal engineer, they hire legions of junior engineers to cover up the gap. People who focus on the joy of shipping than on the pesky questions of "shipping what?" and "who will maintain it?"
Many of us here owe our jobs to the deliberate weakening of technical authority and expertise. That debt probably blinds us to those management decisions, and the need for architects to balance them out.
Oh how I wish I had a legion of junior engineers. Or even a squad.
My company has an aversion to hiring. It's so expensive to hire people, you know! There are no young engineers to teach the ropes to. There are very few senior people do everything.
Needless to say nothing happens fast, good, or cheap. And we don't ship projects, they mostly just bob up and down in the harbor.
oh how i wish I had a single junior engineer.
my company hires like crazy for new things, but the maintenance of critical things are just the same humans who always take care of it.
and then we get asked to work on the new things too, and it's like, uhhhh...
That's not just an architect. It's an architect, a construction worker, a bricklayer, a plumber. That person might not do everything but needs to be able to dive deep as low as required.
who says an architect doesn't build things?
Most architects.
who'd thunk im lucky at my workplace...
I've got the opposite problem... Too much implementing not enough architecting
The main requirement is for the person to be on the project and have skin in the game. An architect will often have more of a bird eye view and not be actively working on a specific release. They might also not care about the business side.
IMO depending on the org, the matching role would be either a release manager or a project lead.
Architects these days have only a very narrow view of how the actual product works. But that’s also because we outsource so much shit.
Rather systems have become bigger and more complex to the extent that most cannot be understood fully in both dimensions of breadth and depth.
Architect? That sounds like a lot of money. We're just gonna stick some rando as the product owner and call it a day.
Let's one up by getting a rando on board as "business analyst" but expect him to do product owner stuff.
Learn on the job, sink or swim, YOLO! (you only learn on-the-job)
You look like a straight shooter with upper management written all over you.
I like the cut of your jib. Let’s let the sails loose on this venture and see if we can’t move the needle.
Can we circle back on this in 6 months to validate our strategy with leadership?
This is a great article. Reflects my experience both in big and small companies. Anyone can be the "Project leader", doesn't need to be a TPM, PM or ENG. It isn't an org chart role, it is a role you are fulfilling. I have seen many different org chart roles succeeding or failing at it.
This also allows companies to bake it into a role without commiserate pay increases and even sometimes without modifying responsibility only adding on to them.
Don’t be fooled folks, if you aren’t being paid more for leading and taking visible ownership over things you’re being cheated
This is a very snarky/bitter view of it. In my career I have done fairly well and have been promoted after the fact a couple of times. People who don't take these opportunities rarely move up to bigger responsibilities. At big tech is usually expected that you are already performing at a level above for a certain period of time before being promoted
In my team, this role is covered by the tech lead, who also takes on the responsibilities of project manager, scrum master, and business analyst (team members help with business analysis).
don’t remember architects had a truely intricate knowledge of the business metrics. It was more of a technical role.
I think this is a change in business climate today - all senior+ engineers in many companies are now expected to have knowledge of business metrics, and that expectation goes up with staff engineers (the new architect name)
I think this expectation has always existed, but engineers have been able to get cover for not understanding or participating. Now it is harder for engineers at any level to cover which means they have to understand the business and participate to a larger degree. This may just mean being more proactive in raising issues affecting metrics through to influencing what those metrics should be.
> In the before times, we called this an architect
agile and ITIL both
> I often get tapped to lead new ones when it’s important to get it right, because I’m good at it.
The ego is just bleeding out of this sentence.
He's a SSE at GitHub.
A constant focus on keeping the architecture,infrastructure and codebase quick/ease to ship is to "Keep It Simple Stupid".
Be critical about adding new services or complexity.
Ask yourself can this be solved in a way that does not require changes to the shipping process. If no, evaluate possible alternate approaches.
A fanatical dedication to monitoring the production system is beneficial. The faster you can catch that the last deploy screwed something up, the less stress and down time there will be.
The shipping process should also include the ability a rollback the latest deployment. Again less stress and possible downtime there will be.
Achieving these goals is the best way to win the trust and influence on the people up the chain.
Every project has a role of Release Manager. Some teams are small enough that this role is filled by a team lead, project manager, architect, etc. some teams rotate this role to spread the pain and knowledge. Large teams have a defined employed role with title of Release Manager that could even include a team (think shipping large DoD contractual projects)
There’s whole books on this subject. I think this blogpost does a great job of summarizing the goals for large tech company shipping — well written — nicely done
This is why I'm a big fan of MVPs and quick iterations after ward.
Launching a significantly complex product is HARD, even if it is an MVP.
Nobody understands how hard, even if they've done it before. It works in staging, must be ready! Then users start trying to signup and actually use the product and the wheels come off.
I've usually been the person that understands it all and launch week is always hell. Or depressingly boring because you have no users.
this is a reality in organisation: " it’s paradoxically often better for you if there is some kind of problem that forces a delay, for the same reason that the heroic on-call engineer who hotfixes an incident gets more credit than the careful engineer who prevents one." Its ironic in many areas. A leader (Project or Political) who ran projects and shipped smoothly is less valued than a leader who created a mess and got them fixed ...who is more celebrated. :(
Great article. That bit about having 20% free at the start to 90-100% free time towards the end of a project, to address issues, is very insightful. I stumbled a lot in a project recently because I suspect I had it the other way round.
This aligns with what I've seen and the issues I've had shipping high leverage things at an enterprise. Its way more communication, selling and documenting more that it is a technical issue. Nice post.
It's all about the last 10% - it's what makes a project of any size see the light of day. Some thrive on that last 10% (like I do). It's the work of grinding through the final loose ends and the finishes touches, fixing the issues in the live environment vs development, etc.
It's hard and boring, but it's also rewarding.
And then there are most people - who just check out when it's sort of done. I don't like those people.
It sucks that this is what life is all about.
I think the whole idea of shipping, at least within big tech, should follow slow rollouts starting with 0%. For example: Deploy an empty service in production with 0% rollout. Increment the rollout with each version deployed, including fixes of previous releases.
This may not be great for user experience but great for getting things up and running. Although, upper management will not be happy to see slow rollouts.
The way I've used to describe this to people is, most people's mental model is:
<doing a poor job> --- <doing a average job> --- <doing a good job>
Whereas the more accurate mental model is:
<doing nothing> --------------------------------------- <doing a thing> -- <doing the best thing>
The former mental model is intellectually satisfying because you get to infinitely yak shave over every little tradeoff and doing nothing isn't even on your mental radar.
The latter is deeply humblingly mundane and doesn't get to center us as masters of the universe which is why we all initially resist it. Even for the people who become great at it, they become great against their inclinations, and still have to fight the urge at every step.
This doesn't just apply to tech, look at it in politics. How much time do we spend in politics debating policy? Which of our different political philosophies lead to different tradeoffs that are a deep expression of our values? How much time in politics do we spend debating state capacity? A state that can do none of the things, it's irrelevant which of the things we want the state to do. A state that can do more things, almost always just the sheer option of things they can do means they can find a better policy.
And yet policy arguments are just so fun while state capacity arguments are incredibly wonky and depressing.
But I've drawn that same diagram on 100 different whiteboards in front of 100 different juniors and said the same words of "before we figure out how to do the best thing, let's just see if we can even do a thing first" and it seems to have gotten through to an appreciable number of them enough that it feels like a high converting meme.
I think this train of thought is why I now have to deal with four UI libraries in the same small-feature-set product, including three different ways of styling a React component.
I think that a more accurate mental model would accept that a team sometimes has no idea whether a change will get them 80% of the way there with 20% of the effort, get them 20% of the way there with 80% of the effort, do something somewhere in the middle, have zero impact, or even make the product worse.
Why don't you fix it?
Same reason everybody can't fix "it", whatever "it" is for them. I have other shit to deal with that's even worse.
In corporations, sure, nobody is concerned about the end goal. That is by design.
Design by managers who simplistify everything into a manufacturing process in their "factory"
Those same simplistifiers managers would love "facilitators" who are now concerned with a function of shipping in their "factory".
most of this makes sense but I think what would make it more useful is more focus on topics that mainly fall under project management: building relationships with key stakeholders, establishing early+clear communication channels, building in timeline slack, how to navigate management politics etc. i dont think shipping in big tech cos is significantly different to shipping a large construction project in terms of project management, but rather there is a tendency for managers in big tech to be significantly less tenured and hence ignorant of basic management priniciples that lead to easily avoidable blunders.
A piece of text written by someone with actual experience, how nice :)
I agree that every project needs one person who has a laser focus on getting the project across the finish line. There are always dozens of slightly annoying and unrelated blockers.
I call it my volleyball theory, after playing on a mid team back in college. If the ball is coming down near a large group, no one gets it. If you're the only one there, you'll get that ball one way or another!
Shipping is a social construct, not a technical milestone
It’s a great post and often what I see folks doing.
Hot take though: why do we need so many people and processes and mysticism around software these days? It seems to me the reason why it’s so difficult to ship anything, let alone anything good and useful, is because there are so many people involved who don’t actually participate in engineering. They manage time lines and meetings and emails and talking to customers. And somehow they’ve made themselves essential to the process so that developers can’t ship code anymore.
Like… I know my users on a first name basis. I know how their business works. We’ve talked about the button and we want to run an experiment.
As a developer I might want to just try it out with them. Maybe the change will be a good fit for the product as a whole, maybe it will be a solution that only works for this one customer, maybe it means we need to be able to configure which workflow is used.
If I can’t just ship that and get the feedback I need without involving a handful of other people and being completely fearful that I could take down our service… what is wrong here? Is it that there aren’t enough “shippers” on the team or is it because the organization has made it difficult to ship anything?
That being said, this is the world we live in, and the article has a lot of great advice. I’m definitely used to/conditioned to think this way.
It sounds like you are part of a pretty small business given that you're an engineer who knows his customers by name. It may very well be completely acceptable to your customers to have extended downtime, or a button that disappears during a deployment leading to a broken feature for a couple of days until you, or they, realize something is wrong.
Many other companies do not work this way. If you're a huge company like Apple that makes $40M per hour, that type of downtime isn't acceptable. If you're in finance, that downtime doesn't work. If you're in healthcare, defense, aerospace, etc... that downtime doesn't cut it. Yes, you'll still have downtime in those industries from a bad deploy, but you put more checks and balances in place to reduce the odds it will happen.
I'm not actually at a company where I know folks by name at this point. I was for a time.
I currently work at a much larger company where I ship platform-related stuff that integrates a bunch of systems (card payment processing... so fintech) for other developers so that they can ship features and products to customers. I've done a lot of the work mentioned in the article.
The hot-take is just a suspicion that we make things more difficult for ourselves by involving more people than is necessary to get work done, not trusting developers, etc.
Update: and is more a reflection about how the industry operates in general than how things operate where i work in particular
> If I can’t just ship that and get the feedback I need
As a user, I detest when I'm treated as a lab rat and the software I rely on to get stuff done has the UI randomly changing because the people making it don't have anyone in charge with enough design sense to make a call on how the product should function.
Google normalized this practice with the obsessive A/B testing and it's one of the biggest things that pushed me away from Android and general Google services. Microsoft is terrible for it too now. Every piece of software feels like a perpetual beta test.
I get annoyed by these same things.
As a person who regularly ships software to folks to solve problems I think this is more of a symptom of marketing and product folks taking over than software developers trying to provide a stable, useful solution.
A system needs to change over time as demands and requirements change… but it shouldn’t be unexpected and without warning. And it should be in concert with knowing the unique demands of the users involved with the system.
When I want to run an experiment, I mean to run a deliberate experiment that the people using the software are aware of and are a part of. Not some random trial A/B test based on telemetry. That stuff is too common these days, I agree.
Articles like these really speak to me. In a lot of ways, developers that claim to take ownership might be a few small cognitive steps from actual ownership aka have shipping in mind. Lots of take aways to prevent headaches and pain points.
Excellent piece. My observation in less technically-oriented but still innovative companies: shipping also occurs when you post about it on LinkedIn and can show with a concrete example (a graph or a small video)
The CEO is addicted to the product and fires people who are not aligned. This is the best strategy to ship the product: Elon's strategy
This is a great and insightful article. Very helpful. Thanks a lot, author.
I've also "shipped" projects at big tech companies and this level of bootlicking really doesn't deserve to be called "shipping" it's just delivering for your management. Using the term "shipping" is a great scissor statement because it muddies the water.
The mentality from the article is another symptom of the many issues Software Engineering faces as profession.
Namely that a significant portion of us think of ourselves not as engineers, who need to tell management to get fucked occasionally, but as optimizers for accolades from whatever group can dole out rewards. This starts off in academia and continues into the professional world.
Certain folks just want to build a technical fiefdom for themselves, or get headpats from people who are above them in any given hierarchy.
Yeah this is "how the game is played". Playing this game eventually leads to the death of your organization and is why we have a corporate life cycle in the first place.
Eventually people like this eat an organization from the inside, pushing out anyone with an actual opinion or who optimizing for actually getting things done.
Instead it's just pure mercenary behavior for your managements attention.
This is so true. Now I know how to describe the work I'm doing!
> I have shipped a lot of different projects over the last ~10 years in tech. I often get tapped to lead new ones when it’s important to get it right, because I’m good at it.
Why not list some of them that I can actually try out? How should I give this any credence if I cannot evaluate them?
It's more work, NDAs, and probably not particularly relevant to the article. Why list some of them?
Go to their resume from the home page, https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaA...
None of that looks like stuff I can try. I guess the GitHub copilot onboarding was pretty good. Gists are pretty good, but I don’t think he made those originally.
Thus the discussion in the article around stakeholders and what constitutes "shipping". A lot of what one will work on at a big company does not directly translate into features that regular users will see.
I figured the web page would just say, "I don't".
Hear hear, I share these observations almost as-is.
Is it just me. Or has the term "ship", "shipped", only become a (specific to software production) industry-used term asn of relatively recent times? Specifically as Sam Altman has been using it a lot I have also noticed. Ever since his increased use of the term, I've seen it used more and more. This could be one of those times where I am noticing it because I am thinking about it, but it really doesn't feel like that.
I have always associated new software versions with with my the word "release", "released". While shipped is not an incorrect term to use for software. Release just feels more appropriate.
Has anyone else noticed this?
All of that said, I am not condemning the practice in the least. Just interested in the etymnology of one of my favorite areas of interest. Hopefully draw some more knowledgeable folks on the question.
It's not a new term. Steve Jobs coined (or at least popularized) the saying "real artists ship" in 1983[0], and using the word "ship" this way is probably even older than that.
[0] https://quoteinvestigator.com/2018/10/13/ship/
In large orgs, I've often felt the most important skill is convincing your boss's boss that your opinion / course of action / etc is the right one.
The practical advice in here resonates very strongly with my experience, I like the analysis a lot.
The philosophy about what "shipping" is... Presupposes that your motivation for working in big tech is to get to L9 and make 7 figures or whatever. Dunno about that. (Also I suspect there's a ceiling on where you can get by being really good at shipping).
I like to think I do this shit on my own terms, I have my own goals. Pleasing leadership and getting good ratings is very often instrumental to those goals (and money is great) but I think I still get to decide what shipping means to me.
Just leaving a comment so I can find and read this thread later…
Several more items along these lines. Two books and one recent blog post...
> "Ship It! A Practical Guide to Successful Software Projects", by Jared Richardson, Will Gwaltney, Jr
> "The Pragmatic Programmer, 20th Anniversary Edition, your journey to mastery", by David Thomas, Andrew Hunt
> "The Libertarian Coder", by Adam Ard, at https://rethinkingsoftware.substack.com/p/the-libertarian-co...
Me myself, I joined a project that shipped on time. The lead developer, a contractor, begged for just three more months to make it all actually work properly.
Nope.
We shipped, and then it took two more years to finally get it functional.
And the contractor was banned from ever working there again (a WA state agency).
Yippee!
Reality: the ops team and crusty BOFH sysadmin do their magick regardless of the dumb politics of articles like this = shipping
My Indie Hacker version of this:
Deploy often. Every day. Keep momentum. Ensure you have a chat box to talk with users so they can complain. Profit.
Great to hear somebody on the internet actually gets it.
> Shipping is really hard and you have to make it your main priority if you want to ship
This feels like it’s written by AI by a junior level “prompt engineer”
> Shipping doesn’t mean deploying code, it means making your leadership team happy
Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck. Gotta make sure the font is just barely legible and explain it quickly before they ask follow up questions
> You need your leadership team to trust you in order to ship
yea that’s why I get _paid_ to do work, not glaze c-level executives and appeal to their fragile egos
> Most of the essential technical work is in anticipating problems and creating fallback plans
Falling back is a loser mentality.
> You should asking yourself “can I ship right this second?”
no, I should be asking myself, “why am I still at this dead end job that asks me to constantly ‘ship’ a broken product. Leadership doesn’t want to encourage delivering value to the customer”
> Have courage!
You don’t need courage at a “big TeCh” job. Just be slightly competent and you are already light years ahead of your colleagues
>Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck
Is it wrong, though? This is a pretty much universal phenomenon. It's less about real goal X and more about making sure the boss feels good when you're around.
That usually correlates with being a good worker, but not always.
> why am I still at this dead end job that asks me to constantly ‘ship’ a broken product.
Because the economy is broken right now and my country is gaslighting me into think it's perfectly fine for rent to go up 50% in 2-3 years and groceries to double.
There's definitely a storm coming, I can worry about my passions again when it passes.
Shipping for your leadership instead of users is so very American and explains how serial blunderers fail from one big project to another while the employees get the short end of stick. Happy if you makes you happy that some big wig on the leadership like you, but is that really all you want to achieve in life?