Where should your CTO be located?

At a First Friday for Startups1 mentoring session, I was asked the following:

Given that I have a team of software developers in a remote location, should my CTO be co-located with me or the team?

Good question! After all, your CTO will be the bridge between you (the one with the vision for a software product) and the development team (the executors of that vision), and collaborate closely with both every single day.

My take: Your CTO should be located with you and manage the dev team remotely.

Why do I consider this the more productive arrangement? Well, let’s take a look at all the things you probably want your CTO2 to help you with or do for you (click to stop squinting):

  • Product Planning: Taking your vision and drilling down into the detailed requirements to come up with a prioritised roadmap to implement features
  • Product Design: Creating a detailed vision of your product in the form of UI/UX wireframes, mockups & prototypes
  • System Design: Planning and documenting all those parts of the system not captured by the user interface: data flow and storage, infrastructure, integrations with third party services
  • Technology Selection: Consider and make recommendations for options on programming languages, frameworks, platforms and providers and their tradeoff
  • Project Management: Planning and overseeing tasks, deliverables and schedules with the development team
  • Quality Control: Ensure code quality and security, set and enforce standards and conventions
  • Acceptance Testing: Review development results with you to ensure deliverables match expectations before they go live
  • Operations: Create tools and processes to manage your infrastructure and minimise risks of data loss, system outages or security breaches.

The first four of these responsibilities can be lumped together under “planning” and are arguably the most important, requiring the highest levels of expertise and experience. They have two traits in common:

  1. Planning requires close and often ad-hoc collaboration between you and the CTO. You’ll spend hours at a time around a whiteboard, hunched over spreadsheets and sketches, and having unscheduled meetings and discussions to review documents, incorporate feedback, and share additional information.
  2. Planning’s starting point is language, which is by nature synchronous, imprecise and ambiguous. That’s the whole point of the various stages of the planning phase: To translate ideas expressed in ambiguous language into concrete, explicit and unambiguous specifications that developers can ultimately express in code which a computer can understand and execute.

Contrast these two traits of planning with how your CTO will interact with the development team: Their starting point will be the outcome of your collaboration - detailed plans with drawings and data. Their communication will be in large parts asynchronous, involving documents, code reviews and working software, run on and supported by cloud-based services. And their necessary “face-to-face” meetings will revolve a lot more around a schedule, from sprint planning sessions to daily stand-ups.

Another way to think about it: The secret superweapons of the planning phase are whiteboards, felt pens and sticky notes. For the implementation phase, it’ll be tools like Trello, Github, Slack & Co. The latter would be true even if CTO and developers were co-located.

In other words, the later stages of the software development cycle are much more suited to, and well supported by tools for, remote collaboration than the earlier ones, which are also the most important and require your intimate involvement and constant availability for feedback.

So if you have to make the choice, I’d recommend to try and find a CTO locally and let him or her manage your team remotely.

  1. https://dogpatchlabs.com/first-fridays-for-startups/ 

  2. A.k.a. your tech guy (or gal). The term “CTO” means different things to different people and organisations and is not necessarily the right one for your business. It might alternatively be referred to as Software Architect (the analogy with building a house is a good way of thinking about this job), Lead Developer (if this person ends up writing code, too), Principal Engineer, or Technical Co-Founder (if you’re lucky). It can be a part-time or full-time job. I’ll keep using CTO as an easy shorthand. They key is that it’s not primarily a people management job but the most critical technical role in your startup. 

Back to home page