Hacker News Reader

Comment by imglorp | Hacker News Reader

> Wiggins and Brantingham specified and designed the chip entirely by themselves and without any approvals from anyone, according to Frantz. TI management had neglected to fit the project into any particular reporting structure, and that suited the four team members just fine. In Frantz’s estimation, the lack of “help” from management gave Wiggins and Brantingham the freedom they needed to figure out a successful design.

I am dying to know what was learned internally at TI after this regarding project oversight. I think we all KNOW that the way get things done is hand out the tools and get the hell out of the way. This seems to be the message at Skunk Works, Bell labs, Xerox PARC etc.

But when the pressure is on, your Big Corp is GOING to lay on the product, tech, marketing, etc etc governance, replete with timelines, KPIs, budgeting, accounts, timesheets, yada yada. This kills the project.

View on HN

I really wish my experience were that cut and dry. This strategy seems to me to depend super strongly on the quality of the developers/engineers, and their commitment to getting work done (c.f. your examples: Skunk Works, Bell Labs, PARC, etc -- I really wish I worked in such an environment!).

There are people who are good at seeming busy, but who wildly overestimate, take every opportunity to get bogged down on some trivial obstacle, chronically misunderstand objectives/values, can't consistently put three words in a row correctly, and just seem in general to be the weak link; those people need to be managed.

Do they?

Managed within or managed out, but I think yes.

It's also really interesting the effect of management to drive timelines and innovation. If you look at the Apollo program, there was a ton of innovation driven by a incredibly fast design/launch cycle. Well managed timelines and goals can have a focusing effect (point the innovators in the most effective direction and give them the tools). The issue is when meeting the timelines and goals BECOMES the measure, rather than measuring effect. At that point it's just teaching the test and micromanaging.

That's an extreme and useful counterexample. Did anyone distill Apollo project management lessons learned into something we can apply now?

Of course. Here are couple interesting papers by NASA leadership from the Apollo era (PDF warning):

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/197200...

https://www.nasa.gov/pdf/293253main_62682main_jerry_madden_f...

Yes. I think you're seeing something of a survivor bias here. For every one of an example of a true and successful skunkworks project--and this one is obviously much different in scope than skunkworks aviation projects--there are tons of counterexamples.

A lot of times there's a group of engineers who don't agree with whatever decision and go off and do what they want to do instead. I'm guessing when that happens, most of the time it never amounts to anything and never sees the light of day.

Reply on news.ycombinator.com