One meme that has been making the rounds recently is Joy’s Law, supposedly named after Bill Joy, one of the founders of Sun Microsystems: “No matter who you are, most of the smartest people work for someone else.”
It’s a cute aphorism, one that I hadn’t heard six months ago (although the Wikipedia page linked above was created in late 2009). Now it’s everywhere.
Joy’s Law is obviously true. It’s also a perfect marketing tag line for today’s connected, crowd-sourced culture.
Looking just at hardware and software engineering, answers to a broad range of factual technical questions used to be hard to get. I can remember combing through the tantalizing hints provided in the (printed) documentation from a popular SDK, experimenting with various combinations of API calls until I either figured out how to do something that seemed like it should be easy, or gave up and decided it wasn’t possible.
Today that same answer is often one Google search away — and even if your question is more specialized and you can’t find it with a search, often all you need to do is post the question to Stack Overflow or one of the numerous other technical forums, and you’ll often get an expert answer within a couple of days.
It’s also much more common to be able to grab a well-implemented open source library or license some portable IP than it used to be — and those are both forms of tapping into external knowledge.
Now, it’s great that we can tap into all this ephemeral cloud intelligence. The problem is that crowdsourcing breaks down when the question isn’t one that can be easily reduced to an Internet search or a forum question. As an example, once I’ve decided to base a network protocol around XML, there are plenty of resources to understand how best to use the numerous XML parsing libraries that are available. It’s a bit harder to find the Internet source that would guide me away from using XML in the first place and instead suggest using Google Protocol Buffers.
So the danger is that the Internet can make me very effective at quickly arriving at an inefficient answer. Another way to state the problem is that it’s hard to crowd-source engineering design: The problems are basically impossible to phrase in a search-compatible way, and anyway, you usually can’t share your requirements publicly. The question becomes, given these constraints, how best to apply Joy’s Law.
One thing I’ve observed is that there are different kinds of experience. In five years of doing engineering consulting, I’ve realized that we have an advantage over engineers who work in a “normal” products company because in that time we get to see many more approaches to different problems. I don’t think I’m any smarter now than before I started consulting — but I do have a lot more breadth. (Yes, possibly at the expense of depth.)
Meanwhile, I’ve seen that there can be a type of herd mentality that takes hold of individual engineering cultures, regardless of talent level. You can sometimes have a group of very smart people who spend all their time thinking about the same set of requirements and who settle on the same range of approaches.
As a result, my application of Joy’s Law to engineering design would be to try to assemble a small group of thinkers from heterogeneous environments. The group has to be close enough that they can all understand the requirements of the project, and yet you want as much diversity in engineering experience as you can get. Selfishly, one way to tap into breadth is to hire a consulting firm like Cardinal Peak to help advise on or review your design. There are other approaches, as well: If your firm is large enough, bring in a principal engineer from a different geographic division, or enlist (under NDA) a faculty member from a local university. The key, I think, is to get smart people from different backgrounds actively engaged.
