[HN Gopher] The Art of Managing Skunks
___________________________________________________________________
The Art of Managing Skunks
Author : sebg
Score : 27 points
Date : 2025-05-01 20:08 UTC (2 hours ago)
(HTM) web link (maheshba.bitbucket.io)
(TXT) w3m dump (maheshba.bitbucket.io)
| PaulRobinson wrote:
| 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 wrote:
| But this is for skunkworks. You have to move fast. "Breaking
| things" (leaving behind ugly tech debt) is to be expected.
| Kikawala wrote:
| https://web.archive.org/web/20250409175424/https://maheshba....
| hoistbypetard wrote:
| > 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 wrote:
| 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!
___________________________________________________________________
(page generated 2025-05-01 23:00 UTC)