Those are my definitions, and not meant to be universal; but they have served me well in my past years navigating and advising tech companies of various stages. I hope they’re useful to you with regard to your own definitions.
This is part 2 of a 3-parter. Check out Part 1 here: “Opinion: What is a tech company? — What is technical innovation?”. Part 3 coming soon.
How to generate technical innovation? — Ownership
Since technical innovation is the current Far West gold, there are many models out there attempting to reliably generate it. And the only ones I’ve seen work rely on giving opportunity for technical serendipity (and I believe this is aligned with research, but don’t quote me on this).
It’s counter-intuitive: you don’t find innovation by setting up an innovation process, but by creating and sustaining the right environment for people to stumble upon it, and surprise themselves. And then you wait.
To enable serendipity, the hardest part is giving the builders the opportunity to try things out that could fail, and if they do, to learn from those failures iteratively (and therefore maybe fail again). It means the builders need quite some ownership. And since no one can know that something will be an innovation before it’s out there and actual real-world value can be measured, it also means that an innovation needs to be able to start as just a technical intuition; and not a direction that was decided from the top because its odd to succeed was measurable.
That’s the Toyota model: you give intense control to the manufacture employee to adapt their process the way they want, stop the line if needed to ensure eventual success and optimization of their goal, so that they stumble on unexpectedly better ways to do things. Obviously, in software, it means technical innovation happens when innovative features are sufficiently owned by software engineers.
Of course, that’s the point of “company hackdays”, of “Google’s 20%” programs, etc… But I don’t personally believe that approach is sufficient to sustain an innovative business model comprehensively. Those types of program make serendipity happen in products that no one else claims ownership of, not the core business; and innovative businesses should always strive to innovate on their core business as well, rather than expect innovation in side-projects.
Yes, that means engineers being full owners of the product’s core features. Was it a chill down your spine?
How to mitigate the risk of ownership towards technical innovation? — Checks and balances
I understand why that thought could be worrisome. And it should be, because I was involved with early startups giving 100% ownership without any reservation to their engineers to boost innovation, and that often doesn’t quite work either.
It’s not just the chaos from lack of cross-team communication (which there are ways to manage, even at scale), it’s just that most engineers probably enjoy creating things in a new way; but most junior/intermediate engineers don’t come naturally with a solid understanding of how to measure and optimize the business value of what they build. And remember that you need both “new” and “valuable” when you’re reaching for innovation.
In my experience, most junior/intermediate engineers, when explained the critical importance of focusing on the business value of what they’re building, are more than willing to optimize for that, just need help figuring out how to. That’s suddenly a much easier problem to solve. All you need is a system of checks and balances that ensures that all engineers have the help they need with it, and that they use it at scale.
So, here’s the golden question.
How do you build that “checks and balances” system, that ensures you trust your engineers with enough individual ownership to get invaluable technical innovation that will make your company thrive; while not trusting them too much, and ensuring that they have the resources to ensure they are indeed constantly working on things that they fully understand can become innovations for the company; all the while allowing as many failures as needed, but keeping productive R&D costs decent, with people not just constantly failing to turn up any value?
I know you may be at the edge of your seat for the answer, but I’m afraid I believe there are as many answers as there are tech companies.
Literally, all successful technically innovative companies I’ve met are aware of that problem in some way, and trying to solve it, but there aren’t two that are solving it the same way. The best way to do it for you depends on the people you have on board (and not just the engineers), your cash flow and runway, your existing assets, your competitive advantage, the vertical you’re in, etc.
What is a tech company?
A tech company, to me, is a company that is trying to optimize for technical innovation in order to build intense growth from it, and therefore whose ultimate mission is to find how they should solve that checks and balances problem at scale for their specific case.
And I don’t know about you, but it so happens that I’m fascinated by that problem, and therefore by the act of growing tech companies, along with their technical innovation and engineering culture. I’ve spent the last few years sitting down with people in tech companies at various stages, and have made it my personal pursuit to help them find the possibilities for themselves.
This was part 2 of my “What is a tech company?” series. Check out:
- Part 1: “What is a tech company? — What is technical innovation?”
- Part 3: “What is a tech company? — From early-stage startups to high-scale tech companies, how do others do it?” (coming soon)