[HN Gopher] How I ship projects at big tech companies
___________________________________________________________________
How I ship projects at big tech companies
Author : gfysfm
Score : 1176 points
Date : 2024-11-11 22:30 UTC (1 days ago)
(HTM) web link (www.seangoedecke.com)
(TXT) w3m dump (www.seangoedecke.com)
| 0xB31B1B wrote:
| 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.
| abhpro wrote:
| The author just shipped the post
| dpkirchner wrote:
| We can't be sure of that -- what did their boss say? That's
| all that matters.
| dpe82 wrote:
| If they aren't paying attention then move to a project they
| /do/ signal interest in with their attention, and ship that.
| sbarre wrote:
| > 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.
| gfysfm wrote:
| 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.
| drc500free wrote:
| Internal Marketing is the primary role of the Product Manager
| at a lot of big companies.
| whstl wrote:
| 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.
| thefourthchime wrote:
| 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.
| jeffrallen wrote:
| 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.
| dr_kiszonka wrote:
| I love the example with pigs haha!
| simonw wrote:
| 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!
| NBJack wrote:
| 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.
| didibus wrote:
| 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.
| bigiain wrote:
| 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...)
| OnlyMortal wrote:
| 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.
| Aeolun wrote:
| 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.
| anshulbhide wrote:
| IMO most engineers completely forget or don't appreciate the
| importance of optics, especially when working with non-
| technical founders or management.
| klabb3 wrote:
| 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.
| amonith wrote:
| "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.
| afandian wrote:
| 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.
| anshulbhide wrote:
| Correct.
| amonith wrote:
| 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.
| afandian wrote:
| 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').
| mmcnl wrote:
| 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.
| amonith wrote:
| 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.
| CalRobert wrote:
| 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/89b22b4b18dd3ed630a
| 0...
| dclowd9901 wrote:
| 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...
| tightbookkeeper wrote:
| No organization with more than 1 person is immune from the
| effects of optics. If you think so, you may be blind to it.
| tonyedgecombe wrote:
| 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.
| conjectures wrote:
| Nah, I think optics can matter at startups too.
| tonyedgecombe wrote:
| For a lot of the ones that fail, yes.
| jimbokun wrote:
| 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.
| amiljkovic wrote:
| What is optics??
| kridsdale1 wrote:
| 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.
| neilv wrote:
| 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.
| scott_w wrote:
| Same here. What you highlighted makes a lot of sense to me and
| it's something that happens at every company size.
| h1fra wrote:
| 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.
| jimbokun wrote:
| 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?
| iknownthing wrote:
| 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.
| enugu wrote:
| 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.
| louwrentius wrote:
| 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..
| Scubabear68 wrote:
| 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.
| jawns wrote:
| 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.
| Scubabear68 wrote:
| 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.
| shalmanese wrote:
| 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.
| twelve40 wrote:
| > 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)
| trentnix wrote:
| I do hate the game. I hate it so very much.
| thfuran wrote:
| >I think this falls under the category of "Don't hate the
| player, hate the game."
|
| The game wouldn't be happening without players.
| atty wrote:
| 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.
| thfuran wrote:
| So the players are just following orders and totally
| blameless for any actions?
| _carbyau_ wrote:
| 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_.
| hackable_sand wrote:
| 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.
| mupuff1234 wrote:
| 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.
| InDubioProRubio wrote:
| 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.
| digitallis42 wrote:
| Search is not Google's golden goose. It's Ads.
| 0xpgm wrote:
| 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.
| itsoktocry wrote:
| > _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).
| solidninja wrote:
| The only winning move is not to play :)
| tonyedgecombe wrote:
| >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.
| faizshah wrote:
| 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.
| tech_ken wrote:
| > 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
| simonw wrote:
| 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.
| yamumsaho9292 wrote:
| 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.
| willcipriano wrote:
| > 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.
| antupis wrote:
| 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.
| SoftTalker wrote:
| > 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.
| edanm wrote:
| Even with a company of size=1, you have to worry about
| customers.
| yread wrote:
| but those are hopefully much closer aligned to endusers
| than your upper management. Unless you make some ad
| spyware
| 0xpgm wrote:
| 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.
| nasretdinov wrote:
| 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 :).
| smdyc1 wrote:
| 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.
| yamumsaho9292 wrote:
| 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.
| reaperducer wrote:
| 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.
| nine_zeros wrote:
| 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.
| SpicyLemonZest wrote:
| 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.)
| strken wrote:
| 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.
| com wrote:
| 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.
| strken wrote:
| 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.
| antupis wrote:
| 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.
| shalmanese wrote:
| 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.
| 0xpgm wrote:
| 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.
| hiatus wrote:
| And then the smaller, nimbler company itself scales to the
| point that it resembles the former incumbent, and the cycle
| begins anew.
| randomdata wrote:
| _> 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.
| renewiltord wrote:
| 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.
| taveras wrote:
| 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.
| madeofpalk wrote:
| 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?
| antonvs wrote:
| It helps to have telepathic users who can hate software that
| you haven't released.
| dmafreezone wrote:
| 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.
| lucianbr wrote:
| 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.
| antonvs wrote:
| I mean, it's basically been Startup News for People Who Like
| To Pretend They're Actually Hackers from day one.
| csomar wrote:
| The article does not claim to be about shipping software but
| about sipping software in Big Companies.
| jonas21 wrote:
| 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.
| kapitanjakc wrote:
| 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.
| misstercool wrote:
| I think this article is much more than this.
| > First, you have to get clear on what the company is looking
| to get out of the project.
|
| You are not just pleasing the executives. Assuming the
| company described in the article is a good company.
| Executives are not idiot that making impulsive decisions.
|
| You need to be able to sense the company direction,
| communicate clearly, manage the risk, build the trust. This
| is not an easy task in a big company.
|
| Such an awesome article IMO that explains the art of shipping
| in a big firm. I believe if any engs can master the skills
| described in the article, you will get promoted to a
| leadership role very fast. Of course, this might not be the
| path everyone loves.
| com wrote:
| 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.
| purple-leafy wrote:
| Known as brown-nosing and prevalent where I work
| vdvsvwvwvwvwv wrote:
| Shipping is ... milestone hit on program management.
| charles_f wrote:
| 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.
| chii wrote:
| 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.
| lmm wrote:
| > 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.
| h0l0cube wrote:
| 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.
| mirekrusin wrote:
| 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.
| jameson wrote:
| Exactly
|
| Title would've been better fit "How I climb the ladder at big
| tech companies"
| willtemperley wrote:
| 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.
| throwaway346434 wrote:
| 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.
| _def wrote:
| It says so in the title: it's about shipping projects. This is
| about project management.
| anonu wrote:
| ... At a big company.
| gwbas1c wrote:
| > 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.)
| Ensorceled wrote:
| 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.
| superfrank wrote:
| 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.
| kobalsky wrote:
| > 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.
| trueismywork wrote:
| 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).
| mtnGoat wrote:
| 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.
| didibus wrote:
| Resume is here:
| https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaA...
|
| 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
| mtnGoat wrote:
| Thank you for looking that up, I was on mobile and being
| lazy. So it looks like he's done some decent sized stuff.
| tonyedgecombe wrote:
| Or claims to have done so ...
| shalmanese wrote:
| 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.
| strken wrote:
| 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.
| 392 wrote:
| Why don't you fix it?
| strken wrote:
| Same reason everybody can't fix "it", whatever "it" is for
| them. I have other shit to deal with that's even worse.
| decasia wrote:
| 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.)
| pm90 wrote:
| > 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.
| nine_zeros wrote:
| > 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.
| efortis wrote:
| > 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.
| GPerson wrote:
| It sucks that this is what life is all about.
| xyst wrote:
| > 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
| johnnyanmac wrote:
| >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.
| cynicalpeace wrote:
| 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.
| AdieuToLogic wrote:
| 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.
|
| EDIT: clarified the ethical question.
| sbarre wrote:
| 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?
| ozgrakkurt wrote:
| 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.
| jonahx wrote:
| > 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.
| sbarre wrote:
| 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.
| 0xpgm wrote:
| > 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.
| sbarre wrote:
| Yes of course there are exceptions to the rule, always.
| kridsdale1 wrote:
| At Boeing, 'happy (wealthy) leaders' diverged from 'alive
| customers'.
| bananapub wrote:
| 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.
| lmm wrote:
| > 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?
| slfnflctd wrote:
| 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.
| km144 wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
| akomtu wrote:
| _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.
| HipstaJules wrote:
| I feel that you don't trust leadership teams very much.
| marcyb5st wrote:
| 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
| jimbokun wrote:
| 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.
| nine_zeros wrote:
| 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.
| a_bonobo wrote:
| 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.
| swiftcoder wrote:
| 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.
| nine_zeros wrote:
| > 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.
| roland35 wrote:
| 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!
| zeroonetwothree wrote:
| 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.
| TwoNineFive wrote:
| It's a self promotional advert blogspam.
| abc-1 wrote:
| > 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?
| lytedev wrote:
| It's more work, NDAs, and probably not particularly relevant to
| the article. Why list some of them?
| rovr138 wrote:
| Go to their resume from the home page,
| https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaA...
| abc-1 wrote:
| 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.
| swiftcoder wrote:
| 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.
| oneturkmen wrote:
| 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.
| gjs4786 wrote:
| 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.
| eurleif wrote:
| 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/
| blinded wrote:
| 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.
| aorloff wrote:
| > 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.
| mihaichiorean wrote:
| 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.
| high_priest wrote:
| The users were happy, but you didn't get paid, or got fired
| for using company time out of assigned scope.
| gorgoiler wrote:
| 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.
| bjackman wrote:
| 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.
| nitwit005 wrote:
| 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.
| mirekrusin wrote:
| Great to hear somebody on the internet actually gets it.
| benreesman wrote:
| 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.
| baxtr wrote:
| 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.
| 0xpgm wrote:
| > 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'.
| idra wrote:
| 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
| Aeolun wrote:
| 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.
| xenocratus wrote:
| 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...
| lioeters wrote:
| > live somewhere off-grid
|
| That's the thing, the grid covers everyone everywhere
| now. There is no escape from the planet of the apes.
| red-iron-pine wrote:
| 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.
| mbesto wrote:
| > but don't require 'collaborating with people in power'.
|
| You missed this qualifier: "person's life within a larger
| social construct."
| tdb7893 wrote:
| 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.
| crabbone wrote:
| 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.)
| anon7000 wrote:
| 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.
| rytis wrote:
| > 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.
| smugglerFlynn wrote:
| 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.
| d0gsg0w00f wrote:
| 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).
| InDubioProRubio wrote:
| 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
| bryanrasmussen wrote:
| 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.
| ben_w wrote:
| 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.
| yosefk wrote:
| 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.
| d0gsg0w00f wrote:
| 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.
| jrochkind1 wrote:
| 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.
| ryandrake wrote:
| > 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.
| consteval wrote:
| > 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.
| jedberg wrote:
| I figured the web page would just say, "I don't".
| 0xbadcafebee wrote:
| This is _amazing_ satire. It 's like the CEO of Hooli had a
| Senior-Senior-Senior-Senior-Engineer blog.
|
| (more amazing: 54 _ship_ s, but not a single leader- _ship_ joke.
| that takes nerve.)
| ctenb wrote:
| 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.
| kqr wrote:
| 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.
| cadamsau wrote:
| Agree strongly with your entire comment, but am _definitely_
| stealing that last sentence, it was quite a sharp take.
| dkga wrote:
| 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)
| bluSCALE4 wrote:
| 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.
| kookamamie wrote:
| Hear hear, I share these observations almost as-is.
| desaiguddu wrote:
| 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.
| meditativeape wrote:
| This is so true. Now I know how to describe the work I'm doing!
| shalmanese wrote:
| 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...
| fergie wrote:
| This article is an expert-level primer on office politics in big
| tech masquerading as a primer on delivering software.
| rk06 wrote:
| Yes, and because of it alone, I consider it one of the best
| articles of this year read by me.
| user_7832 wrote:
| Agreed, as a green/still inexperienced employee it was quite
| a good read.
| ThinkBeat wrote:
| 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.
| PeterStuer wrote:
| 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.
| kridsdale1 wrote:
| 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.
| tmarice wrote:
| This is what purgatory looks like for software engineers.
| ben_w wrote:
| > 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.
| sethammons wrote:
| 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
| sumedh wrote:
| > 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?
| ben_w wrote:
| 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.
| up2isomorphism wrote:
| 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.
| salviati wrote:
| 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.
| up2isomorphism wrote:
| 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.
| sethammons wrote:
| 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.
| user_7832 wrote:
| 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.)
| Attrecomet wrote:
| 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.
| dmafreezone wrote:
| > 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.
| ozim wrote:
| * _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.
| DrBazza wrote:
| 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.
| vasco wrote:
| > 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.
| ozim wrote:
| 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".
| 2-3-7-43-1807 wrote:
| > I am also quite often seen as an asshole because ...
|
| or ... you really are in fact (acting like) an asshole.
| speaking from own experience.
| pc86 wrote:
| 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.
| kridsdale1 wrote:
| 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.
| 2-3-7-43-1807 wrote:
| 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.
| pc86 wrote:
| > 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.
| kridsdale1 wrote:
| At Google, this months later permission step from everyone is
| a built in step in the launch process and mandatory. Takes
| forever.
| giancarlostoro wrote:
| 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.
| j45 wrote:
| This sentence is a good one for those who often are that person
| and wonder if there might be others like them out there.
| antonvs wrote:
| > 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.
| moffkalast wrote:
| Architect? That sounds like a lot of money. We're just gonna
| stick some rando as the product owner and call it a day.
| ozim wrote:
| Let's one up by getting a rando on board as "business
| analyst" but expect him to do product owner stuff.
| moffkalast wrote:
| You look like a straight shooter with upper management
| written all over you.
| shnock wrote:
| 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.
| nshunter wrote:
| Can we circle back on this in 6 months to validate our
| strategy with leadership?
| HPsquared wrote:
| Learn on the job, sink or swim, YOLO! (you only learn on-
| the-job)
| Lucasoato wrote:
| 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.
| froh wrote:
| who says an architect doesn't build things?
| lazide wrote:
| Most architects.
| froh wrote:
| who'd thunk im lucky at my workplace...
| Carp wrote:
| I've got the opposite problem... Too much implementing
| not enough architecting
| Aeolun wrote:
| 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.
| CharlieDigital wrote:
| Rather systems have become bigger and more complex to the
| extent that most cannot be understood fully in both
| dimensions of breadth and depth.
| makeitdouble wrote:
| 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.
| bsaul wrote:
| don't remember architects had a truely intricate knowledge of
| the business metrics. It was more of a technical role.
| ebiester wrote:
| 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)
| zerkten wrote:
| 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.
| crazygringo wrote:
| 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.)
| datadrivenangel wrote:
| 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?"
| pavel_lishin wrote:
| 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.
| ebiester wrote:
| 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.)
| optymizer wrote:
| 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.
| jigneshdarji91 wrote:
| 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.
| trueismywork wrote:
| I thought this was only happening in academia
| mazswojejzony wrote:
| > Project managers stereotypically use Gantt charts to focus
| on timelines and contingencies and processes
|
| ...and dependencies between teams/stakeholders. :)
| DeathArrow wrote:
| >And note the distinction between project manager and product
| manager
|
| And then there's the product owner.
| jollyllama wrote:
| Ok, the before-before times then.
| olpquest22 wrote:
| 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).
| chambers wrote:
| 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.
| 8xeh wrote:
| 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.
| AndyNemmity wrote:
| 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...
| red-iron-pine wrote:
| > In the before times, we called this an architect
|
| agile and ITIL both
| aprdm wrote:
| 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.
| no_wizard wrote:
| 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
| aprdm wrote:
| 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
| glenjamin wrote:
| 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.
| steveBK123 wrote:
| 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.
| beretguy wrote:
| 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.
| steveBK123 wrote:
| 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.
| linhns wrote:
| If I were you I would have left immediately.
| cruffle_duffle wrote:
| 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.
| pc86 wrote:
| 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.
| philote wrote:
| 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?
| pc86 wrote:
| 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.
| psunavy03 wrote:
| 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.
| jll29 wrote:
| 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.
| glenjamin wrote:
| This matches my experience - I was intentional about not
| saying that a project manager was important - just that
| project _management_ (the practice) is important.
| DeathArrow wrote:
| >Generally in my book projects should only be assigned to teams
|
| User stories are assigned to teams.
| devjab wrote:
| 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.
| psunavy03 wrote:
| 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.
| mrowland wrote:
| > 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.
| renegade-otter wrote:
| 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.
| EliRivers wrote:
| _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.
| fmbb wrote:
| 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!
| sharas- wrote:
| 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".
| praveen9920 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| remify wrote:
| 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.
| Sandworm5639 wrote:
| 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.
| ivanjermakov wrote:
| The post is not about engineering, hacking or programming, but
| pleasing management.
|
| I wish there were less submissions like this.
| user_7832 wrote:
| 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).
| Attrecomet wrote:
| 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.
| whiplash451 wrote:
| 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.
| krony wrote:
| 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
| cdrini wrote:
| 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.
| jgalt212 wrote:
| 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.
| jcmontx wrote:
| 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)
| eichi wrote:
| 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
| jhwhite wrote:
| 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.
| econnors wrote:
| 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.
| jhwhite wrote:
| Yeah but a good technical PM / whatever will have that
| understanding. Not a role that just checks milestones and
| statuses.
| agentultra wrote:
| 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.
| kingnothing wrote:
| 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.
| agentultra wrote:
| 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
| hbn wrote:
| > 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.
| agentultra wrote:
| 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.
| Ensorceled wrote:
| 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.
| yhoots wrote:
| 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.
| bob1029 wrote:
| > 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.
| recursive wrote:
| > 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.
| hemloc_io wrote:
| 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.
| arminiusreturns wrote:
| Reality: the ops team and crusty BOFH sysadmin do their magick
| regardless of the dumb politics of articles like this = shipping
| computerdork wrote:
| 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).
| mmcnl wrote:
| This is a great and insightful article. Very helpful. Thanks a
| lot, author.
| jhallenworld wrote:
| 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..
| dxs wrote:
| 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!
___________________________________________________________________
(page generated 2024-11-12 23:01 UTC)