s11e20: Oh No, We Didn't Have A Decision Maker, Now We Have A Decision Maker
0.0 Context setting
It's Monday, March 21 2022 and a grey, listlessly rainy day here in Portland, OR.
Today: admin (turns out you need to send invoices for your typing-for-coins to result in actual coins, or the digital representation of coins); checkins; an exciting working group; and Thinking, which is what happens before Output.
One quick note: I will be on vacation next week! Things That Caught My Attention will be taking a mid-season break and as is customary and for me to follow through on the seasons/episodes metaphor, I will be doing re-runs. I'm going to be looking for good previous episodes to run, but if you've got any topics or favorites you'd like to request, drop me a line.
Things That Caught My Attention, Volume 1
Good news! If you're a paid subscriber or supporter you should have received a link to download your free copy of Things That Caught My Attention, Volume 1. If you haven't, drop me a line and I'll get you sorted out.
If you're not a paid subscriber or supporter (you can always become one!), subscribers can buy a copy at 20% off.
1.0 Some things that caught my attention
This one happened to be at the top of my attention stack as I'm looking at the text window:
Software At Scale
Via... somewhere, Moishe Lettvin wrote about their experience at Microsoft working on Windows Vista (née Longhorn) on the "off menu"1, which through his rough estimate, involved 24 people people at the immediate level:
8 on Lettvin's immediate team (the Windows Mobile PC User Experience) team, and the shell team (the Start menu) and the kernel team (actually executing on "off"), both of which were roughly the same size as Moishe's team.
But those were just the implementing teams. Each of them had "6 layers of management from the leads", which nets you out to 43 total people "with a voice in this feature".
The important point that Lettvin makes is that 24 people were closely connected to the code, and none of them really had any ("exactly zero") final say in how what they implemented worked. Because that person lay in the remaining 19 layers worth of management. And it's not clear that Lettvin ever found out who that exact person with final say was, because even when he'd left the team after spending a year, "there was still no decision about exactly how this feature would work".
Okay, so... what might we learn from this? Dumb, obvious stuff first:
- Windows is really big. Like, really, really, really big;
- Lots of people work on it;
- Microsoft is committed to backwards compatibility;
- Any sufficiently large software projects like this end up being as much people/organization/management problems;
Double-dumb stuff with absolutely no knowledge of the specifics of the situation or environment, such specifics might include: the personalities of each of those 19 individuals in the layers of management; incentive structures both personal and organization; what "doing a good job and thus looking good to your boss" both looks like and actually is; Microsoft's whole obsession with stack ranking (which was in place at the time, but ended in 20132 and then continued to haunt the company); whether it's even possible to pull a piece of string to find out who the "real decision makers" are in a company of (in 2022, at least) 182,268 employees...
Well when you put it that way, you're kind of screwed. Best you could do, I expect, assuming an environment that isn't actively out to get you (and remember: most aren't, and if they are, then out-to-get-you is more likely to be the norm, than not, so maybe get out as quick as you can?), is probably something like take a bunch of time to find out who that person is through soft influence and by being as non-confrontational as possible. There's going to be the person who should be the decision maker, and the person who's actually the decision maker. There'll be the person who doesn't make the decision but is their boss, so one route is to figure out a way to make the decision maker's boss (once you find her) signal in the right way to make it easier for the decision maker to a) commit to a decision, and hopefully, b) a good one.
But that's the easy way of putting it. Because then you might end up with the flip problem, which is sort of orthogonal to the original problem you had.
Original problem: 24 people on implementation teams, 19 people in management, nobody on the 19 people side appears to be the decision-maker
New, improved problem: you do finally have a decision maker who's empowered, but... you're not sure if they're going to make a good decision or not.
Or: Oh No, We Didn't Have A Decision Maker, Now We Have A Decision Maker.
So how do you deal with that? Is it just turtles all the way down? If you're sucked into the kind of place where Managers From Beyond have colonized and don't have the experience to check/validate/know what good decisions are, and what makes them good, then do you trust that they're going to support movement in the right direction for you and your peer teams?
Which is why in about 20 minutes I'm going back to picking at a Confluence page called, roughly, The Top Ten Eight Signs You Need To Look For When Managing {X} because look, you're a manager. You're busy managing things. Writing reports. Reading other peoples' PowerPoint decks. You're Responsible for things and Accountable to people and damnit if you don't also want to be Consulted about everything, because who wants to only be Informed?
Okay, that's it today! I got distracted. It took about 20 minutes and I kept drifting here and there looking at other windows. Not a great start to the morning.
How was your weekend?
Best,
Dan
-
The Windows Shutdown crapfest, Moishe Lettvin, 24 November 2006 ↩
-
Microsoft does away with stack ranking, ZDNet, Mary Jo Foley, 12 November 2013 ↩