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!
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?
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.
Politics is the set of activities that are associated with making decisions in groups.
All the bad connotations we get from the word are because humans are humans. There is no better model that works in any kind of society/ organization/ group other than "politics".
Somebody "ethics" may not be the same as others. (Is it ethic to spend a lot of money and deliver something that does not fit the expectations of the ones that provided the money? It may be easy to make users happy - just give them free movies, etc.)
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.
> 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.
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.
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.
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 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.
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, 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.
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
> 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.
*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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
People get hung up on this stuff. Getting things done in different environments is about understanding the constraints. The objective isn't to religiously follow some "ship" cult. The objective is to get things done. Or at least that's my cult. I have a friend in Amazon's logistics department. One day he told me how he was planning something that involved buying up the entire capacity of a local airfield. The thing with a long enough lever and a fulcrum is that these guys are moving the world.
Love it or not (mostly not), shipping software in large organizations requires navigating what the business and its leaders demand. You can try while ignoring leaders, but you'd be unlikely to ship anything.
You'd be in good company.
In my experience, there are plenty of people at BigCos who are more interested in covering their ass to ship nothing or the wrong things.
The article actually presents strategies for shipping, not changing the hearts and minds of management, or making great products. Shipping implies neither of those things.
> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. You can feel any way you like about that, but it’s true. If you don’t like it, you should probably go work for companies that really care how happy their users are.
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).
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.
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.
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 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.
> 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.
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.
[+] [-] simonw|1 year ago|reply
> 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!
[+] [-] AdieuToLogic|1 year ago|reply
EDIT: clarified the ethical question.
[+] [-] sbarre|1 year ago|reply
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?
[+] [-] bananapub|1 year ago|reply
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.
[+] [-] realaleris149|1 year ago|reply
All the bad connotations we get from the word are because humans are humans. There is no better model that works in any kind of society/ organization/ group other than "politics".
Somebody "ethics" may not be the same as others. (Is it ethic to spend a lot of money and deliver something that does not fit the expectations of the ones that provided the money? It may be easy to make users happy - just give them free movies, etc.)
[+] [-] jimbokun|1 year ago|reply
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.
[+] [-] runeks|1 year ago|reply
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.
[+] [-] marcyb5st|1 year ago|reply
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
[+] [-] paulddraper|1 year ago|reply
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.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] HipstaJules|1 year ago|reply
[+] [-] navane|1 year ago|reply
[+] [-] PeterStuer|1 year ago|reply
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.
[+] [-] kridsdale1|1 year ago|reply
The original PM responsible for all this gets an L+1 diagonal promotion at a new company and pulls this shit again.
[+] [-] jhallenworld|1 year ago|reply
- 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..
[+] [-] thefourthchime|1 year ago|reply
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.
[+] [-] benreesman|1 year ago|reply
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.
[+] [-] tdb7893|1 year ago|reply
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.
[+] [-] baxtr|1 year ago|reply
I don’t see how you can achieve any meaningful goal without collaborating with people in power.
[+] [-] d0gsg0w00f|1 year ago|reply
[+] [-] anon7000|1 year ago|reply
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.
[+] [-] InDubioProRubio|1 year ago|reply
[+] [-] consteval|1 year ago|reply
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.
[+] [-] yosefk|1 year ago|reply
[+] [-] ozim|1 year ago|reply
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.
[+] [-] glenjamin|1 year ago|reply
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.
[+] [-] devjab|1 year ago|reply
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.
[+] [-] steveBK123|1 year ago|reply
[+] [-] jll29|1 year ago|reply
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.
[+] [-] DeathArrow|1 year ago|reply
User stories are assigned to teams.
[+] [-] aorloff|1 year ago|reply
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.
[+] [-] kqr|1 year ago|reply
> 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.
[+] [-] pm90|1 year ago|reply
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.
[+] [-] Scubabear68|1 year ago|reply
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.
[+] [-] simonw|1 year ago|reply
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.
[+] [-] jawns|1 year ago|reply
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.
[+] [-] charles_f|1 year ago|reply
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.
[+] [-] shalmanese|1 year ago|reply
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.
[+] [-] renewiltord|1 year ago|reply
[+] [-] taveras|1 year ago|reply
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.
[+] [-] h0l0cube|1 year ago|reply
> 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.
[+] [-] fergie|1 year ago|reply
[+] [-] computerdork|1 year ago|reply
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).
[+] [-] EliRivers|1 year ago|reply
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.
[+] [-] jeffrallen|1 year ago|reply
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.
[+] [-] 0xB31B1B|1 year ago|reply
[+] [-] jhwhite|1 year ago|reply
[+] [-] ben_w|1 year ago|reply
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.
[+] [-] ChrisMarshallNY|1 year ago|reply
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.
[+] [-] remify|1 year ago|reply
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.