Way back I worked in a PPT factory at an investment bank. Our job was to assemble “decks” for investment bankers. The operation ran 24hrs a day with dozens of “operators”.
Young bankers would work CRAZY hours.
Reflecting (1/n)
...though it involved tons of specialized work, (the bankers) work was primarily research, models, content, etc. Their job was to deliver the M&A doc, the roadshow, etc. Our/my job was to assemble.
Some slides too up to an hour (2pt font, 200 logos, 20 footnotes, charts) ..(2/n)
...other slides took 5 minutes. And with some experience you could — as an operator or a manager, which I did both of — estimate how long a deck would take. 120 slides? 60hrs.
Why? How? Repetition. Repetition. Repetition. And low complexity.
Importantly...(3/n)
Each deck was relatively atomic and had few dependencies. You didn’t go back to old decks and revamp one from an M&A document to something different altogether.
IOW, you weren’t beholden to old decisions (4/n)
Even for the bankers, this was primarily assembly. You had a vast body of reference work for all of your reports. Old charts. Old tables. Old slides from MDs
Almost all efforts to freestyle of be creative failed “um, Walter, this John from presentations...we have to talk” (5/n)
...now I realize most of them were using drugs, but they’d work 22hr days, walk home, shower, and be back at it. We’d go through 3 shifts w/the same sweaty banker, eyes bugging, giving us minor edits & asking why the charts couldn’t go more “up and to the right” (6/n)
...so while highly specialized, this wasn’t “deep work” in any way. It was assembly for them as well.
None of this work was collaborative. We didn’t pair. They didn’t pair. Their director would critique their work, but it was all them and their decks (7/n)
Anyway. It occurred to me how different software product development is from most forms of “work” ... the forms of work that a CEO, CFO, etc. w/o actual experience on the front lines would relate to... assembly, where hours in —> work(8/n)
Software development is gardening, screenwriting, movie production, crafting, constructing, songwriting, yes...some assembling, game theory, math, [a bunch of things] all in one.
You can sit around all day, type nothing, and type one line of code and have a good day...(9/n)
A designer can throw away 80 treatments/designs ... go to sleep...and then wake up and crank out THE ONE.
It is also highly collaborative. In a sense, the team is “the product”. A hive mind. What we learn (and can apply) > what we build on any particular day (10/n)
All to say that is unreasonable to expect those who haven’t done it to understand it. There’s no reasoning or theoretical construct they’ll relate to.
Their model is assembly (for most things), and sw prod dev is not assembly (11/end)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The “messy middle” problems is one of the biggest impediments to product success. Here’s what it looks like:
The strategy and vision is somewhat clear.
Teams have specific features they’re working on.
But there’s nothing in between.
Why does it matter? 1/n
High level visions and strategies are helpful, but they lack the specificity to guide teams.
Specific project-based roadmaps feel “actionable” but they are very fragile—they don’t inspire aligned autonomy.
You need a linking mechanism 2/n
Some teams use goal cascades
The problem is the classic MBO problem: goals get more specific & prescriptive as you move down the stack. And by definition they should be “time bound”.
They too are fragile and foster “figure out what you want to build AND THEN tack on goals” 3/n
I was reading the transcript of a work presentation. Then I watched the presentation.
The transcript was filled with issues / logical fallacies / open questions.
While watching I noticed very few.
I think this is the root issue with presentation culture.
I noticed different parts of my brain firing in each context. When slides had lots of “stuff” it felt like a sense of “oh they’ve figured this out” even when the words did not match.
If you pay attention you can feel this happening.
The confident voice of the presenter made the “three focus areas” feel certain, clear, and logical.
In writing it felt incoherent.
I guess this is a point for “a compelling visual” but still it’s interesting.
Your team is burnt out. They are not getting anything done. Work is "low quality". You can see and feel those things.
But what you are seeing is an output of something—the downstream effects of other things happening.
In some companies this is a black box
1/n
…they don’t have visibility into what’s happening.
But it is not that simple (of course).
The outputs are inputs into the black box. And the outputs input into the inputs.
2/n
Say the team reactively addresses quality issues.
This creates more “work” (the output inputs into the input), but it also leaves the team more burnt out and they make less-good decisions on whatever is going on in the box.
3/n