Starting at a New Client as fCTO
Key priorities in the first month or two
Congratulations! You’ve got a new fractional CTO client, and you’re their new CTO. Now it’s time for real work, and adding real value, but where and how to start?
Why Companies Hire Fractional CTOs
Fractional CTOs (fCTOs) like me usually work with small and early-stage tech startups, typically those without strong CTO-level founders (which frankly is most startups).
Sometimes smart founders bring them in before doing much engineering, so everything gets going in the right direction, with good architecture, processes, etc. from the beginning. Sadly, this is rather rare.
More often, Fractional CTOs are brought in by founders (and even investors) when things are not going that well. For example, I often see clients who have outsourced their MVP offshore and are struggling with some combination of cost, quality, and delivery (or all three).
Thus fCTOs often arrive amid a budding or even full-blown crisis and need to hit the ground running, i.e. finding & fixing the leaks in the boat, while also making sure the boat is pointed in the right direction, getting the right parts added to it in the right order, all while not running out of fuel ($$$$),
Getting up to Speed
Ideally, you and the CEO have already agreed on key priorities, deliverables, and challenges, given the often immediate concerns with dates, features, and personnel. Get an org chart, too.
Now that you are here, the first two parallel tasks are to get your arms around things and to connect with your team. Only with BOTH of these completed can you ponder where to go next, what needs doing, triage issues, and so on.
Ideally, getting your arms around things starts before the engagement, as presumably, you had several good conversations with the CEO and perhaps others before you mutually decided to bring you on board. So you’ll know something about the systems, people, tech stack, and challenges. If not, collect all those things as soon as you can.
Digging Deeper
Now you get to dig deeper, ideally by killing two birds with one stone: getting tours of the systems, code, processes, issues, etc. by the actual folks involved — this lets you both understand the systems and get to know your team.
Importantly, this also lets you get a feel for their biases, where they’re coming from, and perhaps who they blame for the current challenges. And you’ll get a good sense of the people & politics right quick.
However, all this is harder if the whole engineering team is offshore and working for another company. If you are very lucky, they will have some senior-ish leaders there and be candid about what they see. More often, however, they will have neither info nor opinions, which will complicate your life in general, and this initial investigation in particular.
Regardless of the team’s responsiveness and helpfulness, you have to dig in with them and others to figure out the status of things: the code, infrastructure, build & deployment, security, 3rd parties, docs, etc.
Then you have to assess the state of each of those along with the state of things over all, i.e. how is the team and product doing, where the major and minor issues lie, and some ideas on how to fix it.
Peers & Others
You’ll also want to formally and informally chat with folks outside of engineering — start with your CxO peers (and their most useful direct reports as they are most impacted by, or complaining about engineering. This will be especially true for the Sales organization.)
As you meet folks, be there to listen, ask how things going and what they do, how it all fits together. This is your time to play clueless newcomer, asking the same questions to various people to see how the answers align, or not.
Throughout this process, keep notes on the issues and challenges, as you’re not likely to be able to address even all the major things at once, to having good lists, triaging, and sorting things out over time are the most likely routes to success.
Your Team
By far your most important task is to get to know your engineering team, its personalities, challenges, and problems. Much depends on your ‘role’, how it was sold or communicated by CEO, and if folks are glad you are there (or not, which I’ve also seen).
Meet 1:1 with every team member, starting informally and open-ended, all while building up your mental model of all the people, processes, and parts.
Depending on the team’s size and complexity, participate in, or lead, the meetings that are, or should be, happening. Your goal is, of course, to understand what’s going on, but also team member personalities, style, communications, and especially who may be left out of the process (usually the women and folks of color).
This is, of course, highly variable, as are how you shape or make the decisions coming out of these meetings, what’s missing or superfluous, etc. Remember that folks will often see you as an outsider, and perhaps only there for a short time (which causes all sorts of complications).
Don’t forget the non-developers on your team, too, e.g. QA, project managers, operations, or other folks. They often have good insights on what’s going right, and wrong.
The Product
Dive into what the product is, and especially how, when, and where it’s built. What is the tech stack, the tooling, the 3rd party and SaaS tools it and the team relies on, and how it all comes together (or not). Expect a mess.
Find and read the documentation, which may not even exist or be up to date, especially for system architecture, standards, security, and how new developers get up to speed. If none of this exists, consider how and when to get it started.
Use and get to know the product, regardless of what it does, and make sure you know the terminology — nothing makes you look foolish faster than not knowing or pronouncing all the industry and product items correctly very early on. In fact, using the right words and the magic word ‘we’ from day one goes a long way to making people feel you are on the team.
Review the product feature set, features in progress, and the roadmap (even if it barely exists), and the product management process (even if it barely exists), for if there are no product managers, it’s likely you will end up owning this. Plus you need to know what’s there, in progress, and coming down the road, usually soon.
Review the challenges & issues, both the ones you know about and especially those surfaced by the team. This includes issues the customers (and thus Sales) are facing, common support tickets, security worries, etc.
The Customers
Depending on the industry and customer relationships, talk to the customers (or key users if in B2C) early on and periodically. This can take various forms, and also depends on the sales process, how needy the customers are, the product price tag, etc.
You should also sit in on key customer or sales meetings, as these are always informative.
Review, also, the competitors and industry, so you have a sense of what others are doing, future features you’ll likely have to build, etc.
Fixing Things
Once you have your arms around things, you’ll likely have problems around off-shoring houses and their management, code and infrastructure issues, missing & broken features, people problems, bad habits, and so on.
Spend time formulating a plan to meet your goals. This includes lists, triage, other’s input, and just sorting out what you and the team can do, and in what time period, and in what sequence.
Fixing & Improving Things
As you get your arms around things and have an initial plan, it’s time to be fixing things and ideally also making longer-term improvements. The form this takes greatly depends on the industry, company, tech stack, people you have, and of course, what the problems, timelines, and budgets are.
The best way is good triage and prioritization, though there is always way too much to fix in the near term. People, politics, and process will also get in the way, and/or help make clear what and who to improve first, second, and so on.
While you are fixing things, focusing on what’s broken, also ponder how and where to “improve” things, which focuses on the future. It especially focuses on how to move towards best practices, using the right tools, the right security posture, etc., and will, of course, vary greatly based on your findings, the product and technology, the team’s capabilities, etc.
Summary
Coming in as a new fCTO, often in difficult circumstances, can be very challenging. Agreeing on your goals and getting your arms around the product, people, and processes are the most critical things you can do early on. Then both fix stuff and improve things while looking at and for the future.
I’m Steve Mushero, a fractional CTO for early-stage startups. I help CEOs and CTOs build confidence in their product, processes, and people. Learn more at SteveMushero.com and view my profile on LinkedIn.
