In the early days of a startup, founders gets used to weighing in on decisions as they’re being made, especially on product features and design. It’s part of what makes the early days of startups go so quickly and efficiently – everyone is in one room collaborating on the one thing that matters: the first product.
As the company matures, someone other than the CEO will (hopefully) end up in charge of making design and feature decisions. The product manager (or someone else in a similar role) will work with mutiple parties to decide on an upcoming feature set, and then work with a design/development team on how it will work and look. There’s a more complex path toward making a decision, and hopefully a well-developed process that goes along with it.
In some cases, this will leave the CEO or other founders feeling adrift and left out of the development process. Software development tends to create one of the more tangible results at a startup, and it’s tempting, especially on a day where other things are frustrating, to roll by a developer’s desk “just to take a peek”. Looking at the latest version will in turn prompt one to ask questions, give feedback, and it can often lead to changes in designs and plans.
The challenge is that if another staff member rolls by a developer’s desk, it’s relatively easy for a developer to refer them to the product manager if they have suggestions. If the CEO does this, it’s not always clear if they’re acting as the CEO (and thus their suggestions trump everyone else’s), or if they’re acting as an interested staff member (and their suggestions should be taken with a grain of salt and run by whoever is in charge).
Almost without fail, if the CEO or founder tries to exert influence without going through the person who is in charge of product decisions, it’s confusing to the developer, and confounding to whatever process is already in place. It’s also a FAIL for the company: you have two people competing to do the same job.
If you find yourself in this situation, what to do? The CEO may be reticent to let go of their influence – it’s fun to talk to developers about what they’re doing, and even more fun to dream up new features. Here are the steps I’ve found useful:
(1) Make Giving Input Predictable and Easy
Make sure you have a process that solicits input on design or features from the CEO and other stakeholders at known, published times. Being able to say “we have a standing design meeting on Tuesdays at 2p”, or “I’ll come by your office every other morning at 10:30 to show you what you’re working on” will help get things moving in the right direction. If you can’t meet directly with the someone, it may be worth it to send them screenshots and explanations, and let them know feedback will be accepted for a limited amount of time.
(2) Explain to the CEO what Impact they’re Creating
The CEO needs to understand what the repercussions are of making decisions on the fly without the product manager – you want to speak from the perspective of the company having great products and a great process for creating them, rather than criticizing the CEO for wanting to give input. Also valuable to stay away from critique of the CEO’s input – it doesn’t matter if it’s great, or terrible; it matters that it’s at the wrong time to be useful. Also pointing out that developers don’t know who’s in charge or who makes decisions also helps in getting the point across.
(3) Train Developers to say “No” or “Maybe”
Half the battle is convincing the developers that it’s OK to say no, and the other half is convincing the CEO that stopping by their desk won’t create instant change. It may take explaining this to both parties, multiple times, to get the point across. You will need to make the point to both parties that the way to get things changed is to talk to the Product Manager, not the developer. If you find the developers are still getting bugged too much, you may need to create “office hours” where they’re willing to answer questions from the rest of the staff, so that the rest of the time, they’re working and off limits.
(4) Extra Credit: Teach the CEO to Act like a Peer when Offering Suggestions
A CEO is used to wielding total influence; it’s an advanced skill to tone down their influence on purpose, and some just won’t go for it. The goal is the for the CEO to sit down and say “right now, I’m going to act as your peer, not the CEO… I might have suggestions, but if I do, we’re running them by the product manager”. If the CEO is willing to take this on, they will be able to collaborate with developers in a new way, and their input will be much easier to absorb. I’ve had limited success with this one, but when it works, it gives the CEO access to what they really want: intimate conversation with the developer(s) about what is possible to create.