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.
hermitShell 2 hours 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 15 hours ago [-]
But this is for skunkworks. You have to move fast. "Breaking things" (leaving behind ugly tech debt) is to be expected.
hoistbypetard 15 hours ago [-]
> One VP argued – pedantically but accurately – that Fred Brooks only said this about projects that are running late; though in my experience, every software project is already late on day one.
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.
freedomben 15 hours ago [-]
This is a very interesting post, but I'm not sure I agree with this one:
> 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!
antman 10 hours ago [-]
Its great if one assumes a small team, small external dependencies, team's authority surpasses management's authority, specs don't change, team doesn't change and the project is a todo app.Then ofcourse people will wait for personal promotions afterwards while assuming collective responsibility beforehand. Sounds like a dream scenario that will attract "Pigs' with experience in large projects. Especially if by design there is no process to trace what happened in the project.
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.
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.
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.
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.