Commenting on aggressive timelines for complicated projects, an engineer recently mentioned that Kelly Johnson is his engineering hero. Johnson lead the design of aircraft such as the F80 Shooting Star (first jet fighter in the US air force), the SR-71, and other notable planes. He did so on tight timelines with small teams. He is the originator of the Lockheed Skunkworks.
I enjoyed reading the book Skunk Works years ago. I think it illustrates some of the timeless principles of effective engineering culture. As one book reviewer put it:
(1) Eliminate bureaucracy
(2) Prefer having a small with high average talent to a larger less talented team
(3) Make sure different functions are physically next to each and communicate incessantly
(4) Shield the team from external pressure
(5) Challenge the team with “impossible” problems that get talented people excited.
These are all things that can help a small talented team far outperform a larger team with a much bigger budget.
I think you see some of the same dynamics at Bell Labs.
It’s interesting how this applies now with remote work being more common. I definitely have felt much more productive when working in a small colocated team than in a larger team or on a remote team. All have their tradeoffs.
I think we see some of the same Skunkworks/Bell Labs dynamics in some OSS projects. But, I’ve rarely been able to replicate the OSS culture in company/customer teams – not exactly sure why, but probably comes down to the people involved – they are often motivated, interested, open, generous, collaborative, humble (in their own way), etc. But, I keep trying …
I’ve had good success replicating OSS-type culture within very small teams if all the participants also have this same goal. It can work very very well, but the motivation to work like that cannot come from outside a person, it has to be an internal motivation and I think simply lots of engineers don’t have that.
I’ve worked with some engineers who are remarkably efficient, simply solving problems at a very rapid pace. Many of these engineers are extremely focused on exactly the problem at hand, sometimes this causes problems in the future. But it’s how they work and often a business places very high value on short term results, so these types of engineers are valuable in the right context.
I’ve also worked with perfectionists who never complete anything. Sometimes OSS is like this, refusing to merge changes unless everything is perfect.
And I’ve worked with engineers who fear that if someone else can do what they do that then they’ll be laid off. Sometimes this is a completely justified consideration as they’ve observed it happen to past peers.
To get the OSS-like development culture, you have to find a sensible balance between my first two points and not be afraid to work with others who can do what you do (and often are significantly better at it than you are). This can be daunting and scary. But good engineers have impostor syndrome and admit it all while striving to become better.
Good points and I think you hit right chord on one of the reasons. This is a finite game mindset and tries to integrate vertically, which could end up increasing cost of maintaining that S/W overtime and management might look to replace it completely or redo it to avoid these higher costs. So you end us losing as a developer. Opensource and OSS mindset infact does few unique things which perhaps aren’t notices. Engineers would work on a OpenSource code and if they contribute the contributions will earn them credits that will last beyond their current job. So even if you were to be laid off, it will help you find new job. You can build relationships with other like minded engineers and enlarge your technical community presence.
I guess we should start teaching these points more to the teams and inform them about the infinite nature of opensource game, in the end if you last in the game, you are winner, there are no explicit winners and losers in here.