One paragraph from a great piece by Ben Horowitz on why founding CEOs fail, or, turned around, what is the new role of the leader?
Make people consider the data they don’t have
In today’s world, product teams have access to an unprecedented set of data on the products that they’ve built. Left to themselves, they will optimize the product around the data they have. But what of the data they don’t have? What about the products and features that need to be built that the customers can’t imagine? Who will make that a priority? The CEO.
But how do you do that and only that if you have been involved in the product at a much deeper level the whole way? How do you back off gracefully in general without backing off at all in some areas? At some point, you must formally structure your product involvement. You must transition from your intimately involved motion to a process that enables you to make your contribution without disempowering your team or driving them bananas. The exact process depends on you, your strengths, your work style and your personality, but will usually benefit from these elements:
Write it; don’t say it. If there is something that you want in the products, then write it out completely. Not as a quick email, but as a formal document. This will maximize clarity while serving to limit your involvement to those things that you have thought all the way through.
Formalize and attend product reviews. If teams know that they should expect a regular review where you will check the consistency with the vision, the quality of the design, the progress against their integration goals, etc., it will feel much less disempowering than if you change their direction in the hallway.
Don’t communicate direction outside of your formal mechanisms. It’s fine and necessary to continue to talk to individual engineers and product managers in an ad hoc fashion, because you need to continually update your understanding of what’s going on. But resist the attempt to jump in and give direction in these scenarios. Only give direction via a formal communication channel like the ones described above.
Another way to characterize this: don’t continue to act like a product manager does with a team of four developers when you are running a company of 40 or 400.
