I enjoyed listening to Erik Torenberg interview entrepreneur Zack Kanter. I had a hard time following the software jargon, and I would welcome explanation, because it sounds as if there were some important ideas there. I was interested in the speculation that software applications that are easy to build have been built, and what remains are more challenging applications. I found that hypothesis difficult to evaluate.
But what struck me most is that Kanter thinks he has discovered some great insight that he can run his company without meetings, product plans, or other formalities, and that a few great engineers is better than a lot of good engineers. But he is running a company with a number of workers way under the Dunbar number of 150. If you can build a functioning business with that small a team, then good for you. But some businesses require getting large organizations to cooperate or buy, and that means you need a sales force. Some businesses operate in or near highly regulated industries, so that means you need many lawyers and lobbyists.
Once your business requires more than about 150 people to operate, tell me how well your informal management methods are working.
What apps remain to be built are not “challenging” as much as they require “domain expertise”. This was the point Kanter was trying to get across in the references to Reid Hoffman’s book “Blitzscaling”. At the beginning of the Web/Mobile/Cloud revolution, no domain expertise was required to build the first wave of apps and services. You needed technical knowledge and you needed the team-building techniques covered by Blitzscaling but Kanter claims that Blitzscaling no longer holds; at least not in his business Stedi built around automating EDI (Electronic Data Interchange). I’ve never heard of the company before but I think a fair summary is “Stripe for EDI”.
I think the best way to understand Kanter’s perspective to tear down this key point that comes at 1:12:07 of the podcast during the discussion of Amazon AWS and Lambda serverless functions:
The “interesting parts” are necessary to keep the six to eight core engineers focused on only the aspects of your software that represent the differentiated comparative advantage of your business (the business logic). It goes with his comment that “software is a liability” since it requires a Red Queen sprint just to stay in place against competitors and security threats. The “stack” refers to the sum total of all the software that you use to run your business. Within the context of the AWS discussion, Kanter is arguing that Cloud computing, like Amazon AWS, is offering all the “undifferentiated heavy lifting” software as-a-service, literally.
That is true and, ironically, Stedi is focused on a vertical that always required an enterprise sales force. Understanding how Kanter has solved enterprise sales without Blitzscaling is probably key to understanding how to build new digital business models with only six to eight exceptional polymath engineers with specific domain expertise. I certainly don’t know how. Everything else he discussed is in my wheelhouse.
Ending where Kling started:
As I listened to the podcast I was struck by how enormous this request is. I understand all the jargon but what I heard was a “Meme Stream”; a steady reference to big and important memes. The was a parallel to what Eric Weinstein was doing in his podcast with Tom Bilyeu. In recorded converstations, it seems both men, either consciously or unconsciously, try to provide the Google search terms required to look up each meme referenced. What is required is a transcript that has been annotated with links to the Wikipedia page describing each meme. If you came up with an algorithm to calculate “Meme Density”, this conversation surpassed Eric Weinstein’s but only because the podcast host in Weinstein’s case was oblivious to the Meme Stream and kept tripping over every reference which was meant to be followed out-of-band.
The domain knowledge theory has been around longer than Zack has been alive and each time the theory is defeated by Moore’s law.
Moore’s Law… which has been dead for a few years: https://www.technologyreview.com/s/601441/moores-law-is-dead-now-what/
Except we are still working off the new 64 bit addressing which is entirely incomplete. We need another few years to completely exhaust that possibility. Even now we still have old 32 bit systems which are holding the industry back.
To RAD:
Thank you for your explanation. Somewhat like Arnold, I was wondering whether there is “anything new under the Sun” with Kantor’s product/business model. And like Arnold, I was largely blocked from divining that from this conversation, largely due to the “jargon”. Your explanation helped (at least me), in both regards.
To Arnold (and RAD):
With regards to your “Dunbar’s number” question/constraint in this context, perhaps I can help. The “solution” is for Kantor to apply a Matrix management type of organizational structure. He may well already know that. Find a good Organizational Theory and Design textbook – an old, cheap one will do – for a full explanation. The Matrix organizational structure is particularly well suited for, and was in fact designed specifically for (back in the 1940’s), this type of field-of-endeavor. At least that is how I would deal with the “Dunbar’s number” constraint in this context.
On the “only six to eight exceptional polymath engineers with specific domain expertise”, don’t be too intimidated by that either. In the olden days (of my experience), we used to call those folks “Tiger Teams” – see Wikipedia Tiger Teams for both a history of that term/jargon, and an in-context explanation. And and they’re not required to be super-humans or mutants. (I’ve been a member of “Tiger Teams” many times in my past, and I can assure you I’m quite human.)
In short, it looks and sounds like Kantor, et.al., is/are planning to apply some fairly mature and proven concepts/techniques from disciplines quite outside the Software Engineering discipline – namely Systems Theory/Design, Project Management, and Organizational Theory/Design (all within MY “wheelhouse”) – to create (hopefully) an improved software product AND a better mechanism/methodology for improving it and its market. I’ll be looking forward to seeing if he can actually pull it off.
I think the most important point is that my wheelhouse and your (Shayne Cook’s) wheelhouse are no longer differentiators. Kantor is not re-inventing your wheelhouse, it has emerged as part of the Web/mobile/cloud revolution and is manifested in three mainstream techniques: 1. Git source control, 2. Agile/Scrum teams, and 3. Cloud DevOps. Every meme Kantor mentioned is part of the generalized shared knowledge embedded in the Hacker News community. If you tried to explain the foundations of your wheelhouse to them they would respond “yeah yeah, we use Scrum” or an equivalent process. It is a solved problem in their minds although each Agile/Scrum implementation seems to be unique.
An important point is that these techniques don’t only apply to software, they apply to any digital artifact that is built from a text based description. Blog posts, research papers, R statistical models/charts, podcasts, books, etc. Kling’s WordPress site is roughly Cloud DevOps. These techniques also apply to digital business models that can be thought of as digital products and a digital marketing mix, the 4Ps product, price, place, and promotion where the place and promotion are all web/mobile.
Keeping with Kantor’s point, EDI is the domain knowledge that differentiates Stedi from any other equally skilled team from the Hacker News community. I don’t understand how they do “No-Touch” enterprise sales but I suspect this is not the secret sauce either.s
I think the Dunbar discussion misses the mark, both Kantor’s de-emphasis and Kling’s re-emphasis. Cloud DevOps provides several orders of magnitude productivity boost. It is like going from muscle power to steam power. A single two-pizza team can create something that reaches the majority of the global population though you still need the right product idea to do so.
I like to think of the Dunbar number, as it applies to institutions, as Phil Libin’s The Rule of 3 and 10. Every time your head count grows by a factor of 3.33, your processes need to be re-engineered to accommodate the new dynamics.
RAD:
Well, again, thanks for your explanations (sort of). I’m going to flatter myself here and state that I think I understood most of what I think you’ve said. (Pretty lame, huh?) Actually, I do “get” the vast majority of it – in concept, if not in explicit terms.
Just as an aside, my early background (circa, 1975) was electrical engineering – some of that in associated software development – and later, overall systems engineering. But that, in very unique and specific applications – suffice to say, NOT business. My business education and business information systems interest came later (mid-1995 to present). I suspect you recognize that as a not uncommon career path progression.
In any event, I’m still of a mind that what I suggested would be eminently applicable to both Kantor’s product and as an organizational structure for him to keep his product both viable and unique. And again, I may very well just be flattering myself in that.
I’d be interested in your comments on Arnold’s comment on Matrix organizations, and my response to him though.
Shayne Cook said:
I don’t think Arnold was being charitable with his dismissal of Matrix management. As I read through the Wikipedia article I was having flashback after flashback of the multidimensional aspects of the various team/lab/division/corporate re-organizations I have lived through. Late in my career I came to realize I had two somewhat ironic regrets: 1. not saving the press releases of every product/concept/consortium I was involved with, and 2. not saving the names of the divisions I worked for. The 2nd regret applies to your emphasis on Matrix management. The names changed to reflect the multiple dimensions that we re-oriented around and I can remember each dimension but I couldn’t remember the division names (not now and not then). It wasn’t just me, I heard many veterans ask “what is the name of our division again?” The “matrix” aspect makes it sound like there are only two but my wonderful/comical real-world experience at the division level involved at least four: 1. functional, 2. product, 3. market, and 4. location.
I think Phil Libin’s Rule of 3 and 10 and the insights from Matrix management complement one another, especially when combined with Reid Hoffman’s concept of Blitzscaling. There are no hard and fast rules, however. Everytime head count growth starts to break existing processes caked in to the existing organizational structure, every Matrix management permutation should be considered to the next 3.33x equilibrium. The Blitzscaling lesson is similar to Moore’s Law: think about exponential growth up front otherwise your growth will stall. When it comes to Corporations, the Dunbar number is just the 100-333 reorg required in the 1,3,10,33,100,333,1K,3.33K… series.
It doesn’t surprise me that you have an electrical engineering background. I have a background in both traditional engineering and computer science but my career was exclusively in the software industry. Very few developers in the software industry understand the principles underlying Kantor’s business model(s). Those that do understand it mostly come from the startup community best represented by Paul Graham’s Y-Combinator, his essays, and the topics of interest that come up in his Hacker News brainchild whose core is made up of Y-Combinator alumni/partners. I’m not preaching a consensus view to you. I’m drilling down on a phenomena that is in its early phases and nowhere near being mainstream.
Rather than thinking about Kantor as describing a hard rule about corporation size, I think its best to describe his strategy as restricting the problem space to solutions that are within the wheelhouse of a two-pizza team. Some problem spaces require growth beyond a single team.
Ooops, I only re-read my first sentence and its WRONG. Arnold was NOT, being charitable. Sigh. There is something about these little comment boxes that break my brain.
RAD:
Got a chuckle out of you relating your experiences with a “Matrix”, RAD. Still, what you related basically confirms my suspicions – the “Matrix” organizations you and Arnold have been exposed to (or more correctly, had inflicted upon you), weren’t Matrix at all. They were just some pin-headed management RCG’s caricature of a Matrix structure.
But I’ve probably beaten this “horse” to death already. Even I think I’m starting to sound like a “marketing puke” peddling the Matrix at this point. And my grad management degrees notwithstanding, I’d never let myself sink to that level. So I’ll drop it here.
Again, thanks for your clarifications RAD. Good stuff. I learned quite a bit from you.
Shayne, I had no previous exposure to the term “matrix management”. I related by first impressions that came to mind while reading the Wikipedia article (probably after only looking at the diagram and the intro).
Some of the “matrix” experiments were highly valuable and I don’t think of them as being inflicted on me and I’m not shy about ranting about bad ideas being inflicted upon me. The same organizational structure issues come up at every level of software engineering starting with the code base. These choices are also really hard. I can relate to Kantor’s self-imposed two-pizza team limit. The hard question, in my mind, is when to go from a one-person solopreneur to a two-pizzapreneur.
I’ve also had first-hand experience with four two-pizza Scrum teams spread across three continents, four timezones, and three languages. It was an amazing experience and the reporting structure aspects were unresolved and way down on the priority list as far as I was aware.
I’d pick your brain about Matrix management if and when I had to; Kantor’s Just-in-Time vs. Just-in-Case refrain. Gifted software engineers have incredible influence through the levers of Voice and Exit. It is very hard to sustain any policy against their will. Where Kantor’s approach falls apart involves Business Continuity and Succession. He is not building a durable nor resilient institution. His business model cannot survive him being hit by a bus. I think he is aware of that.
If you take the initial remarks on team size “10 great engineers work harder than 10 great engineers plus 5 good engineers” and “talent density matters more” in the context of a startup company it is a restatement of https://en.wikipedia.org/wiki/Brooks's_law
Likewise his later remarks on not producing documentation, not having a meeting or product plan, and on hiring great engineers are all valid for a tiny startup trying to make it. (Current organization size 13, 9 engineers, so basically one team)
Kanter sounds grounded enough to realize that the gung-ho attitude of an early startup will have to give way – if successful – to a larger organization with rules, documentation and support teams. They are incurring some https://en.wikipedia.org/wiki/Technical_debt now in order to keep momentum high.
But even as the organization grows, it makes sense to keep the star project teams limited in size (and often at distant from the support).
Shayne,
Matrix management = mismanagement. I coined that phrase about 30 years ago. As a company becomes larger than the Dunbar number, it can try many approaches for dealing with organizational challenges, with “seeing like a state,” as it were. All are imperfect. Matrix management is particularly imperfect.
Yes Arnold, I’ve heard that “Matrix management = mismanagement” and/or the functional equivalent of it before. Even in many Org Theory/Design texts it’s described as “inefficient and ineffective”.
But I’m afraid you (and those authors) are wrong.
I’m not being “snippy” here. But I’d strongly suggest you “suspend your priors” for a bit and re-visit/reconsider the Matrix. And I mean even “suspend your priors” concerning what you think you know about other types of organizational and management structures.
The key concept that makes the Matrix organization both effective AND efficient in this sort of application, that you and others are missing, is that Power (and I mean true, complete, absolute organizational Power) in a properly implemented Matrix ISN’T where you and others might suppose it should be.
I’ll give you a hint: It isn’t anywhere in the “C-Suite”. As a matter of fact, it’s critical that real Power in a properly implemented Matrix organization has to be far outside the C-Suite.
If you’re still not convinced, well, you’ve got my number.
I didn’t form my opinion of matrix management based on theory. I formed it based on experience. Maybe other people have different experiences. But I don’t think that there are many people who have experienced it as a magic bullet.
I have.
Although I wouldn’t characterize it as a “magic bullet” (Seems rather pejorative, probably owning to your bad experience. Gotta suspend your priors for a bit Arnold.)
I rather suspect your (and others’) negative experience is based on being subject to an organization that called itself a Matrix, but really wasn’t. Again, the critical component of a real Matrix management structure is that power is centered outside the C-suite.
On Dunbar… I have seen a few companies operate with business units at the Dunbar number size, where each business unit is operating largely independently, but there can be many business units. The challenge is in keeping the central team small. I also saw some of these business units competing against each other for work (although that might not always be a problem) and sometimes teaming with each to chase larger projects. I don’t know that it works well in wide variety of industries. I saw a new grocery store was looking to hire 500 employees. I can imagine some ways to break that up, but they wouldn’t necessarily add efficiency.
BBUs!!! Scott Adams had a series of Dilbert cartoon with a BBU: Battlin’ Business Units theme.
Yeah, functional business units (janitorial BBU) make no sense. Each one of these business units was basically self-sufficient, and most of non-core business was outsourced.
I work in the printing industry. Our biggest customer is a Quick Service Restaurant franchisor, and we print lots of menus. Now that is under threat from electronic menus. We thought, can’t beat ’em join ’em, and looked at a couple of electronic menu packages that we could distribute and support. Very, very expensive. Fortunately, before we could invest serious money and resources, one of the QSR chains found an app that links up with their existing POS software. We would have lost plenty.
In business, all the big software is there already. It’s mature and bulletproof. New advances will come from interfacing it through cheap, easy-to-write apps. Software people understand this and won’t make expensive mistakes, as we were about to. Without even having to think too hard, they’ll reach to the bin for the appropriate component. Interconnectability is getting better and better.
That is a great example, Michael.
POS (Point-of-Sale) systems, i.e. modern cash registers, are important fixtures within any restaurant business. Electronic menus are trivial from a software development perspective but your domain expertise is a sustainable advantage. “No-Touch” restaurant POS integration is the “secret sauce”.
Zack Kanter inadvertently stumbled upon the EDI standard and its 300 or so use cases with his auto parts business. His next business, Stedi, pivots around EDI for all businesses, not just auto parts. You have stumbled upon the importance of restaurant POS systems in a menu printing context. Following Kanter’s strategy, I can see you creating a business that displaces an established web leader like Yelp. The technology behind Yelp (and Uber or Lyft for that matter) is trivial. What is hard is building the customer base and brand recognition. Offering true value directly to restaurant owners/operators creates the core infrastructure and relationships required to eventually expand into Yelp territory. Yelp’s business model, built around Venture Capital and an advertising revenue model is an exploitable flaw that is open to disruption.