Below are the possible outcomes to the hypothetical situation I posed in my previous blog post, “Founder Re-org”.
When I arrived as the CEO of XenSource in February 2006, I faced a similar (though not exact) situation to what SpiderNet is facing. At XenSource, we had an incredibly talented founding team, located in Cambridge, UK. There was another group of talented engineers in Palo Alto. The problem was that the Cambridge and Palo Alto groups pretty much hated each other. There was a lack of cohesive leadership and there was risk that either side (or both) would implode, leaving the company with no founders and few engineers. Not an optimal outcome for a new CEO.
There was no question in my mind that allowing any of the founding team to leave would be a disaster for the company. There was also no question in my mind that scaling the organization was going to require hiring a VP engineering. Before the XenSource plane could take off, I needed to switch around a few parts. In hindsight, it all seems so simple.
SpiderNet (like XenSource) needs to keep its founder and hire a VP of engineering. In both cases, a change of this sort needs to be done thoughtfully. Before I made any changes at XenSource, I needed to know more about the organization I was running. To help better make decisions, I did the following and would recommend this to SpiderNet:
1. I engaged myself in the cadence of the business: product, sales, strategy, finance. I met with all our employees, asked questions, and tried to identify areas of weakness. But instead of stopping after I met with all our employees for the first time, I kept going, every day and every month afterwards, such that I “felt” what was happening in the organization. I understood our “DNA” and as a result I could make changes that were credible and respected.
2. I held everyone accountable to measurable quarterly objectives. While this may sound bureaucratic, I had each member of the team come up with 3-5 quarterly objectives. It became one of the easiest and most effective ways of managing and reporting on our business. The result was that I could objectively determine areas of strength and weakness and make necessary changes.
In the case of SpiderNet (and to some extent at XenSource), there are several possible organizational outcomes. They are:
1. The co-founder moves to an individual contributor role (CTO, Architect, Evangelist). He may find this role more acceptable and will appreciate the suggestion that he move to a different position. This change augments and leverages his strengths as an architect or CTO. It is important for the co-founder to understand that he will continue to have a key role in shaping the company on a go-forward basis. This moves allows the company to hire a VP of Engineering, reporting to the CEO.
2. Keep in the current role and hire an operational engineering VP under the co-founder. This organizational structure might work, though you need to be certain that the company can recruit a senior enough VP of Engineering or whether the co-founder is capable of continuing to manage the entire engineering organization (even with the help). I would have the conversation with the co-founder about how together, you will manage this structure and determine if in the future this situation is right for the company. The new engineering VP will need to feel comfortable working under the co-founder. I would have the engineering VP sit on the executive team, in any case.
3. Hire a VP of Engineering above the co-founder. Probably not a great outcome since the co-founder should have a place at the executive table and continue to have a direct reporting line to the CEO. I would consider this structure if the co-founder suggested it, though I could not imagine this situation working in the long term.
4. Leave things as they are. Bad outcome. This is the short-term easy way out and not a long-term solution. It simply moves the problem into the future. Product quality and scale in the engineering organization continue to suffer.
5. Co-founder leaves company. Really bad outcome. This is the least desirable outcome, given that the company was created by the vision and team dynamics of the founding team. Sometimes it is necessary to replace a co-founder, but only as an absolute last resort and only if the co-founder is disruptive to the growth of the company or has become a negative influence on the organization. The SpiderNet facts do not warrant co-founder replacement.
Once you have determined the optimal structure, having an open dialogue with the co-founder will be more helpful than not. Ideally, you want the co-founder to be excited about the change and your leadership is key in making this transition seamless. Many times, a person who is struggling in a role may actually feel relieved that you’ve identified a new and better position.
Regardless of the new organizational structure, it would be advisable to ask your co-founder to help hire the new VP and stay in the current role until the new person is onboard. You also want to make sure that you’ve established the right communication to the company. My advice is once the decision is made, you need to quickly communicate it to the company. Best that the information comes from you, rather than through the rumor mill.
Some might suggest “two-in-the-box management” as an option. I have found this structure easy to implement and something that never works. It is a nightmare to manage and is a weak organizational structure. Make the decision upfront, put in a simple line of management and don’t take the easy way out.
Remember also that your board can be helpful in a situation like this. In many cases, early board members and investors will know the founding team and you may be able to use a specific board member to help with the transition and coaching required to effectively re-position the co-founder. Never feel bad about using your board to discuss key issues. In this specific example, your investors already highlighted the possibility of the change when they funded the company, so bringing it up with them is a relatively straightforward discussion.
As for XenSource, we went with an org structure that mapped most closely to option #1 and the rest was history…
