Drawing the Line Between the Roles of a CTO and an EM

Problem

We were a small company back then, with less than 20 engineers total. The CTO, who was also a co-founder, was one and the only manager of engineers. However, as the CTO was exceedingly busy working with external stakeholders and partnerships, I started taking charge of day-to-day operations. I was still not a manager but merely a developer who started to informally take on more and more responsibilities because there was a gap someone had to fill.

At some point, it was decided that my de facto manager position will be formalized, and I will become an EM. That made me officially responsible for daily operations, one-on-ones, performance review, hiring, onboarding, etc. But, in practice, my role often overlapped with one of the CTO, and the team was unsure about what issues they should raise with whom.

Actions taken

Before we formalized my role, we had a couple of meetings where we discussed where the boundaries of our roles should be drawn. The general agreement was that the CTO would handle anything that had to do with external partners and stakeholders, and I would be responsible for all internal matters. Everything was clear and reasonable in theory, but there were too many exceptions that would end at both sides of the fence in practice.

For example, though hiring would fall under my scope since it was an internal matter, it would have a far-fetching impact outside the organization, and hence, it would be decided upon by the CTO. But, again, in practice, I would typically come up with a proposal, and though the CTO could veto me, that seldom happened. I was a bit reluctant at the beginning because I felt they were not trusting me enough, but then I realized how having one extra pair of eyes vetting a candidate could be helpful. Sometimes, they would catch some red flags I might have missed, and I felt their involvement was beneficial beyond what I expected.

When it came to firing people, which was theoretically my scope, I explicitly asked the CTO to become more involved. I didn’t feel comfortable deciding on my own who should go and who should stay as I needed guidance and counsel from someone more experienced than I was. On the other hand, working by external recruiters would fall, following our agreement, under the responsibilities of the CTO, while in fact, I was in charge of it. So, in practice, the line we drew was rather fluid. No matter how hard we tried to draw the line more precisely, reality would bite back, and sometimes we had to decide ad hoc.

I don’t think that our situation was in any way unique. Any startup that will, for the first time, introduce any new role will have to cope with the same kind of problems. The transition lasted for three to four months, after which the boundaries became much less permeable. It took some time for people on the team to get used to reporting to me and have their one-on-ones and performance reviews with me as their manager. On the other hand, I didn’t need more than three months to become confident about where my responsibilities would start and where they would end. In ninety percent of cases, I was comfortable about what was falling under my scope.

Lessons learned

• Large companies have formalized career ladders, and team processes are all neat and seamless, while for many startups, chaos is modus operandi. Most startups have no clearly defined roles and responsibilities, and a transition to a new role is often a transition to the unknown. But with each of those transitions, one learns a great deal about how to structure the team and organization. My experience helped us understand where we want boundaries to be between EMs and the CTO.
• If you are the first person to be in a new role, be prepared for a lot of ambiguity and uncertainty. You will have to make a lot of ad hoc decisions, and too often, you will end up in a no man’s land.
• It was difficult at moments to understand the rationale behind my scope. Even when I was a lead developer, I was deciding on architecture, but not on people’s salaries. That made me look like a peer, not a manager to the people on the team. Being a peer also meant I had support from other peers. But, when my role was formalized, I became responsible for decisions where I could not ask my team members for help. Naturally, in larger organizations, other managers would be my “new” peers, but I was pretty much on my own as the first to be promoted. However, I was lucky enough to develop some other relationships from within and outside the organization that were enormously valuable. Having relationships with peers from different departments also helped; while their experience was different than mine, it was also indeed useful. As someone said, being a manager can be a lonely job. Suddenly one is not part of the group anymore, and that can indeed be a lonely place.
• Where people will draw boundaries between different roles is a matter of convenience. Different companies have different needs along with titles that include different responsibilities. Though there is no universal rule that would fall under a CTO’s responsibility and what of an EM, whatever is decided should be written down. That should be a precedent situation, and all further decisions should be based on that initial agreement.