Comment by simonw
1 year ago
This is great. I particularly liked this observation:
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!
Ya, I think this is a great insight. In today's world, code is not released as a versioned artifact sold on a disc or downloaded. The idea of "shipping" is fuzzy. You might be 100% in production with some change and it could still leave edge case, deficiencies, etc. You can decide to address them now or later. And it's all just perception. You can say it's good enough, we shipped, let's forget about this whole thing and move to another. Or you can keep ironing out the quirks.
I've "shipped" things in the past that were turned on to less than 1% of the time, and we left it at that, and moved on to other things. It was considered "shipped". Everyone was worried to increase it to beyond 1%, so we all patted ourselves in the back for the great launch and went to work on other things.
There was always something intensely satisfying about walking into some retail store and seeing boxes on the shelf containing CDs with software I'd written.
(On the flip side, there was that one time we had to destroy 5,000 CDs because they had a Quicktime Autostart virus on them...)
Heh. I can relate to seeing your product on a shelf.
I recall seeing IBM ViaVoice X on shelves a Circuit City. It was rather an ego trip.
4 replies →
This is the reality. And if you happen to be in an environment with less cooperative folks, get your requirements to ship in writing, agreed upon, and as up front as possible. Hold them to it. Otherwise, it just opens you up for nitpicking, and in some cases goalkeeping, by folks whom end up delaying your shipping.
IMO most engineers completely forget or don't appreciate the importance of optics, especially when working with non-technical founders or management.
Yes but otoh that might be more of a “I refuse to accept a culture of optics on principle” kinda situation, rather than not understanding it. I liked the post because it’s honest and doesn’t put a value judgment on things, just explains how it works. It’s up to each and everyone to act accordingly, and one of those actions is to not participate in the lunacy that often arises in the higher echelons. Many people are fine keeping their integrity, mostly left alone to code, avoiding social deception games at the expense of not being promoted out of what they fell in love with in the first place. People are just different.
Refusing to accept a culture of optics is tantamount to not understanding optics though. The reality is that if you work on any kind of product, optics do matter - the perception of something working is often just as important as it actually working.
5 replies →
"Appreciate" is a weird word. At least for me (not an English speaker) it has a positive connotation so with that in mind I sure hope nobody appreciates the importance of optics. The concept is dumb but it is important and we have to play the game to achieve anything.
Appreciate has at least three entirely different meanings that I can think of.
1. To be grateful for something.
2. To fully understand something.
3. To increase in value
I’m sure there are more.
I read this as option 2.
6 replies →
Similar is "enjoy", which is almost always possible but sometimes can be used in a more... detached sense? "Perspectives in nature we rarely enjoy" as seen in The Far Side here, for instance.
https://i.pinimg.com/originals/89/b2/2b/89b22b4b18dd3ed630a0...
Optics are not dumb. Corporates are very noisy. It is difficult to extract the signal from the noise if you're not working on a project full-time (as most people are, except for you, the tech lead), and it will definitely not happen by accident. That's why you need to manage optics.
2 replies →
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…
No organization with more than 1 person is immune from the effects of optics. If you think so, you may be blind to it.
1 reply →
In that case it's the optics with the customers that matter.
Which can be more rewarding to satisfy than the optics of just management. But still needs to be managed appropriately.
Nah, I think optics can matter at startups too.
1 reply →
It's a matter of scale. "Optics" (as a separate concern) don't matter at orgs that are small enough that everyone can see everything (and/or has full trust in the people who do). Visibility and trust don't scale, hence the necessary evil of pageantry
I wear glasses, so I appreciate the importance of optics every day.
What is optics??
It's a term that has been adopted to sound more professional than "keeping up appearances" which is an age-old concept. It is about how things are/will be perceived by others, rather than the truth of the matter.
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.
Perception is reality. (For better or worse.)
There is a tendency here to pattern match the advice in this article with frustrating experiences about office politics. But I dont see this as a post about politics.
Rather, what I got was that the spec is an incomplete description and there needs to be more inquiry into how the software is going to be used. This can require a little bit of 'going up the stack' to see how business need relates to the software requirement(single enterprise customer with a precise requirement, acquisition of new customer, software for some internal vision of CEO etc). Compare with a startup where one doesn't even have a spec and one is trying to find a product-market fit or when developers take sales calls and find new insights on how the software is actually being used.
A completely broken spec is indeed a failure in management process. But, in general, it helps a library developer to think beyond a library spec and see how it is being used.
Yes. Unfortunately, it comes with a side effect, you will see leadership use this to kill projects they don't like by not never mentioning them until people think it's a failure.
If you are working on something the people deciding on the size of your paycheck want to kill, time to find a new project or a new company. Why fight a battle you're sure to lose?
If only you could figure that out ahead of time. I've been on projects that were killed with no notice anyone could see even in hindsight. I've been on important projects that senior leaders decided to out source my job to China and my boss was forced to let me go. I've seen budgets run dry many times and important projects got killed/cut with no notice (sometimes there are signs that but you think your project is important enough to escape the cuts until it isn't). Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I've also seen people make careers out of taking over projects cut for the above reasons as customers still demand support. I've seen many downturns where my project was important enough to not be cut.
I've seen many downturns where my project had massive cuts, but I personally was not the person cut. Most often projects are not killed outright, instead they go through a long down spiral (not always, but typically) and you can make a lot of money being the expert on a product that is making money if you are able to hang on. Someone needs to leave as there isn't the budget to pay everyone, but that someone need not be you. Often these projects pay very nicely for working 9-5 with no pressure to do overtime.
1 reply →
Note that it can get trickier than it sounds. (Well, I don't know about big tech, but at least for medium and smaller.)
You need to figure out who the "important people" are, and somehow make sure that they understand and buy into the product definition, delivery dates, etc.
Even if they're 3 levels up from you, and you can't normally interface directly with them, try to find a way to double-check that all the "important people" are on the same page.
Organizational dysfunction happens, and you have to succeed despite that possibility.
In my experience, most things in large companies are social constructs. Good things are good because they were decided to be good, bad things are bad because they were decided to be bad. Very rarely are they driven by actual metrics.
Same here. What you highlighted makes a lot of sense to me and it’s something that happens at every company size.