One of the kindest things anyone ever did for me as a student (in the 1990s) was introduce me to Fred Brooks after having "encouraged" (maybe a bit coercively) me to read his book. When I had the chance to talk to him for a few seconds, I asked a poorly phrased version of "aren't they all running late?" and got back an amused response that I understood to mean that of course they are.
> K. Progressively overload the team: Pick goals for the team that are ambitious and just a little bit impossible. This has two effects: one, it forces the team to prioritize ruthlessly, where you cut out anything inessential for success; and two, it pushes the team to somehow find leverage through system design, where you find new ways to deliver the same result without as much code / complexity because you literally don’t have cycles to write the code / manage the complexity.
This can be effective, but so often (especially with skunkworks and greenfield development in general) you pay a price for this in the form of tech debt. In some cases the tech debt can be iterated out of later, but in the vast majority of the cases I've seen that does not happen. IMHO the biggest disservice that most managers do to the company and the future engineers of the team is oversubscribe the team and push them to cut corners or make bad assumptions in order to get something shipped. It can easily 10x the cost of developing/maintaining the product down the road, whereas with a project that is well managed/developed can eventually go into a pseudo maintenance mode with a fraction of the manpower required to keep it alive.
It's more an art than a science and you'll never get the balance perfect, but I would strongly suggest you go for "balance" rather than following the almost universal approach in our industry now of, "ship it now, fix it later."
By the way, if you want to know why so much modern software sucks and is buggy as hell, I would humbly suggest that this is the reason!
it is bemusing to read such a cogent and persuasive summation of accomplished engineering, blessed with admirable clarity of though, explicitness of reasoning, and concision in expression,
and wonder WTF the author would put their obvious talents at the service of a company whose behavior has now for far over a decade has been so irredeemable, so indefensible, and so destructive, as to make this choice itself indefensible.
Yes, I know it's a "great culture" and let's not forget, the pay is off the hook,
but FFS look around, looks what the consequences—social, political, cultural, psychic—are of a firm which has amassed such profound reach infludence and capital both figurative and literal,
in a fashion utterly untroubled by the common or individual good, utterly at the service of surveillance hence profit at every cost.
Oh I know, in polite company in this industry we don't call out the shit on someone's shoe.
Sorry. This politiness has led us to a profoundly fucked state of civilization and things are getting rapidly worse.
PaulRobinson•9mo ago
This is mostly good advice, with a caveat:
You want to focus on strengths when executing, but you also need people to grow, so this needs to be hot/cold - for every 8 weeks of strength playing, give people a couple of weeks of growth time, or thereabouts. You need to give people the time and space to develop in new ways for them to be effective, but also so they can sense that they're growing.
"No individual ownership", is tricky too. We live and die by each other's successes, but experience and aptitude is uneven: you can go fast if you agree on ownership of work streams with regular discussion so there's good visibility on everything within the team.
I'm planning to go do my own thing in the next year or two, and it'll be very skunk-oriented because that's what sings to me. This is not a bad starting handbook, I think.
cryptonector•9mo ago
PaulRobinson•9mo ago
Do you think the engineers at the "original" Lockheed skunkworks would allow tech debt to creep in on the SR-71? They took measured and balanced shortcuts (that thing leaks fuel like a sieve when on the ground, they optimised it for supersonic flight), but they didn't take less care about the technology they were building.
Rather than accepting tech debt, the way to think about it to my mind is "we're going to leave out some functional and non-functional stuff we don't need", but those things are rarely tests or maintainable code. They're more like actual user functionality. What's there is tight, sleek and focused, but it's finished.
cryptonector•8mo ago
Would that be acceptable if building something like the SR-71? I want to say "no, no way", but then look at SpaceX's approach with Starship. You wouldn't put humans on such a thing until it's done, but if there's bugs to shake out, so be it.
And in fact the SR-71 did have bugs that needed shaking out, and one pilot died because of those.
hermitShell•9mo ago
Years later the gains and performance plateau. These things are now mostly understood, and problem solving in the familiar domain yields less growth.
This is when hot cold is IMO a good approach. . Let people explore different problems, different technology. Try things out at work, crazy stinky skunk ideas.