Knowing what, knowing how
“Knowing what” is not the same as “knowing how”. Some are good only in one and not the other. Lucky ones know a bit of both. Game changers have a great deal of both.
With “knowing what” I'm not referring to the simple retention and retrieval of information. Names, dates, places, events, and the like. Facts like Ulan Bator is the capital of Mongolia. This ability used to be more valuable back in the day when there was more friction in accessing information. To look up something meant knowing which hefty volume of the dead tree encyclopedia or almanac to thumb through. To dive deeper meant looking through a paper card catalogue of index cards whose entries pointed to books or microfiche of periodicals on the topic.
These methods of information retrieval have now largely been replaced by Wikipedia, SSRN, WorldLII and other online information providers who are a google, Google Scholar, or a social media link away—sometimes literally at the palm of our hand via our smart portable device.
What I meant was not knowing the dots but rather the ability to connect the dots. “Knowing what” is knowing what is important, what needs to be done—given the context, limitations, risk, opportunities, and trade-offs. It is big picture thinking. It is about making decisions. Strategy, if you will. Big ideas territory.
I have a friend who—apart from two months as a bus conductor—has never worked in his life. He never went to university. Yet he is one of the smartest (and wealthiest) people I personally know. In his words “I never had a CV. I made myself unemployable”. He learned how to be an entrepreneur early on in life. He knows deep in his bones that there's always a deal that can be made. He told me: somewhere in the world, there will always be assets that are underpriced. The trick is to find these assets, buy them at a low price using borrowed money, transform them (bunch, slice or spruce them up), then sell them for a much higher price. If I was smart about it, the only money I would put at risk would be the deposit for the loan to buy the asset. The very same asset that would secure the loan in the first place. The deposit itself could be mezzanine financed. There, in a nutshell, is a formula on how to create money out of thin air.
There is a flow of money. I just have to position myself at a point of flow where I can participate in it. It is not quantum physics, but not everyone can do it.
My friend did not know how to draft mezzanine agreements or how to create a Dutch Antilles special purpose vehicle. He paid bankers and lawyers to do it for him. He may not know all the details but he knew enough to check the details that mattered. As he kept saying “I've never put money into something that I do not fully understand. I just don't do it”.
Of course knowing what to do is not enough. I actually have to do it. I must have the apetite for risk. Entrepreneurship by its very nature is risk taking. It is not for those who expect the safety of wages that are deposited like clockwork into their bank accounts each month. This apetite for risk is what separates entrepreneurs from employees.
Game changers are game on with both their “know what” and “know how”. Mark Zuckerberg did not merely see the potential of social networks and hired off the rack programmers to code his idea. He coded the first version of Facebook. Larry Page and Sergey Brin of Google did not merely see the potential for a better search engine, they actually invented a real breakthrough in computer science with PageRank—their Phd dissertation. Bill Gates together with his partners coded Altair BASIC. As with anything, there are exceptions. There are people who are so strong in their “know what” that they can squeeze to the max the “know how” out of everyone around them. Think Steve Jobs and Jeff Bezos.
However, in the lean start-up world we now live in, it is simply much better if I myself can code. I don't have to be the best coder. I just have to be good enough. When I have an idea, I can try it out. I can bash out a minimum viable product (MVP) to test if my idea has legs. If it turned out it has then I can bring in the kick ass “know what” implementors to add the belts and braces, bells and whistles over my MVP.
The industrial revolution gave us the world we live in now by harnessing economies of scale in transforming atoms by first exploiting the power of steam, then petroleum, and now electricity. Think factories where hard goods are made; industrial farming; massive transport; supply chain and distribution infrastructure. To enable these economies of scale infrastructure, we built massive enterprises that have human resources, marketing, accounting, sales and management departments sitting on top of the people who actually do make the stuff.
The software start-up world is a bit different. The bulk of work in this domain is in bits not atoms. The massive overhead of the industrial era is not a necessary ingredient, at least at the start. A start-up can be small as a guy and a gal in a garage writing code that piggy backs on the massive cloud infrastructure already built by the likes of Amazon web services. In a small, lean, fluid team, there simply no room for super specialists. Everyone has to do a bit of everything that needs to be done. Of course, there could still be a division of labor along functional productive units like front end vs back end development. But everyone has to pitch in to do marketing, customer service, and other business building tasks.
David Heinemeier Hansson sums it up nicely at 49:50 to 51:14 of his badass “Unlearn your MBA” talk at Stanford Ecorner:
[…] it requires that you actually do stuff, like it doesn't work if you're the idea guy. So, I think with starting a company, being the idea guy is… doesn't work. There's no room in a new small company for an idea guy. You have to do stuff. You have to have utility, value. Ah… You have to be able to build stuff, design stuff, market stuff. Something that has direct value to the business, not just an idea, and that's where I see a lot of these actually go wrong, because people would think they can get along just being the idea guy, just being management. There's no management when you're three people. There's no management when we're 15 people. We still don't have any managers hired at 37 Signals. Every single one of us are producers. I'm still a producer. I still write code. Jason still designs. We still do all the stuff and management is sort of the off-shoot of, oh, yeah sometimes we have to deal with issues as they come up. The problem is when you have actual managers whose sole job it is to just manage. They make up bullshit to manage. Because you have to fill an 8 hour day. And in the beginning there's like 40 minutes of management every 3 days. That's what you need in terms of management. You do not need 8 hours of management. Which is how policies and all these other bullshit that crops up when people don't have anything to do. Idle managers are absolutely the worst.