Paul Graham, the founder and once long-time leader of the famous startup incubator Y Combinator, has noted how difficult to go it alone as a single-founder. Hell it’s even super difficult to do it WITH a technical co-founder.
Taking the plunge to start a company as a solo founder / CEO of your business presents a number of challenges, not the least of which is having strong technical leadership in place. That technical leadership, or lack thereof, can make or break your product and business. For example if engineering teams do not possess enough rigor in their process and quality, onboarding your first or marquee customers can go sour quickly.
Below is a sample but not exhaustive list of my approach to working with your organization through a Fractional CTO engagement.
Do you have an in-house team, or remote? Do you work with contractors or employees? Maybe the answer is YES to all of the above.
While this type of engagement does focus a lot on the engineering org and it’s efficacy, the buck does not stop there. Identifying what is working and what is not in an engineering organization must include all of the research and development (R&D) processes, including product and design functions as well.
A SWOT analysis focused on how to improve engineering efficacy will inevitably lead to changes in how the product and design functions operate on a daily basis as well.
The outcome of this SWOT analysis will serve as a lighthouse to help implement the changes and guide the team through a series of changes.
Agile methodologies can work well in a lot of ways. This may seem like a bit of a surprise and perhaps even controversial to some, since many technology leaders take the agile manifesto extremely literally and want to implement it “by the book.” While I think there are wrong ways to do agile, I don’t think this is inherantly wrong. It is, however, not how I approach agile.
I like to stay agile when implementing agile. Meaning, what works for one organization does not always work for the other. It depends a lot on the culture of the company, determining what matters most to the org and what is less critical.
Many engineers may not like to have too many metrics to track success and progress on a team. After all, it can incentivize gaming the numbers for the sake of looking successful. I have seen this first hand and it invalidates the metrics and quickly kills engineering culture.
But building in some trackable metrics at a high level is important to make sure the team can be and stay a well-oiled machine. I’m talking about things like deploy frequency, active bug count, mean time to resolve P0 issues.
Once we get you up and humming with a more effective process and improved metrics, you’ll hopefully see that translate into less churn, happier customers and ultimately a healthier business. But it cannot end there.
I can work with business leaders to identify the time and proper role for your engineering leader. Hopefully you’ve got strong candidates internally on your teamalready who may be well positioned to step into this role. If not, we’ll draft a JD for a technical leader, discuss timing and level of the position.
And surely by now you will know that the process we’ve collaborated on and installed into your org will not and cannot stay forever. Organizations change and grow and new leaders bring new ideas. It’ll be critical to keep the eng team and business leaders open to change and expect that the process and tools and metrics will evolve over time.