4 ms·

I TPM in a team dedicated to skunkworks prototyping for our customers. It's like the most expensive tech pre-sales you can imagine. This is mostly good advice,

I TPM in a team dedicated to skunkworks prototyping for our customers. It's like the most expensive tech pre-sales you can imagine. 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 1y ago
But this is for skunkworks. You have to move fast. "Breaking things" (leaving behind ugly tech debt) is to be expected.
- PaulRobinson 1y ago
  Sort of. 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 1y ago
    I took the context to be software skunk works. To give some examples, when SMF and ZFS integrated into Solaris' OS/Net core there were many unfinished things and bugs and many devs outside those teams had to jump in and help. I'm not sure if that's tech debt or what, but definitely they moved fast and broke things, yet they also delivered incredible value. 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 1y ago
Regarding growth, there are different career phases. For a new entrant to the industry (new grad) or to the company, just executing on any project is growth. How do you do things around here? What technology do you use? 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.

cryptonector 1y ago

But this is for skunkworks. You have to move fast. "Breaking things" (leaving behind ugly tech debt) is to be expected.

PaulRobinson 1y ago
Sort of. 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 1y ago
  I took the context to be software skunk works. To give some examples, when SMF and ZFS integrated into Solaris' OS/Net core there were many unfinished things and bugs and many devs outside those teams had to jump in and help. I'm not sure if that's tech debt or what, but definitely they moved fast and broke things, yet they also delivered incredible value. 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 1y ago

Regarding growth, there are different career phases. For a new entrant to the industry (new grad) or to the company, just executing on any project is growth. How do you do things around here? What technology do you use? 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.