The Dual Residency.
Well, here we are again. We’re still in the minimal viable dual residency phase while we get to the nitty gritty of what having business and technical founders (Behold, the CTO in Residence) as residents in a studio means to the end result.
Most of us agree that most tech companies that get beyond the seed phase will have a mix of business, technical, and operational founders or an early team with that exact match. Sure, there are studies supporting both single and multiple founding teams. The thing is, whilst most software products are easier to craft and deploy, true value is getting harder and harder to create and getting this to market even more so. For that reason alone, we wholeheartedly believe as a studio we should always partner with a business and technical co-founder. That doesn’t make it easy, but it does make for great foundations and a very low urgency to start hiring and focus on the task at hand.
Baseline
First, let me get you up to speed with all we’re talking about here. Builders empower entrepreneurs to build stellar companies. Those are software companies which kind of have similar motions to go to market. Not the substance but quite logical steps to solve an urgent problem in a magical way can be put into different phases and broken down to jobs to be done. In studio speak: a stage-gated process with playbooks for success.
The empowerment for the entrepreneurs comes from that data-driven way of working. The creativity still prospers, but there’s just enough check-ins to make sure we’re working on things that actually matter and combat shiny object syndrome as much as needed. I mean, we all like shiny objects, so we do indulge at times, of course, and make sure we’re still on track.
History
Historically, we’ve fine-tuned our stage gate model to get more confidence about what we’re doing earlier and earlier in the partnership with founders. That means if we bump our head very hard somewhere years down the line, we eventually incorporate some of the learnings in the validation stages before we ever incorporate a new company. This way, there’s also some battle-hardened advice to look back at when convincing others around you this is needed ;).
Our confidence levels can be drilled down to a few things, but for argument’s sake, I’ll go into just two. First and foremost, we exist to build software companies that define the future of work. So we tend to be attracted to founders with an urge to solve a painful and most of the time hard problem which they encountered many times in their professional life. That connection to the problem guides not only the founder but the company to be. The founder story, or in studio speak, the founder opportunity fit will always lurk in the background as a magnet. Looking back, success obviously comes when that connection has been there. There are some scars, some battles fought, and this is where the story potentially can be played out as a superhero movie. What’s not to like? This is also a connection the market feels without knowing it. Throughout validation, there are over 100 conversations and when the story adds up, the results are pure, raw, and validated, making our confidence levels go up.
“Whoa! Build MVP, right!? Eh. No.”
Solution Validation Mode
After the initial problem validation weeks, somewhere around 4 to 6 weeks, we go into solution validation mode. Whoa! Build MVP, right!? Eh. No. Actually, the last thing we want to do is build a product right now. Together with the business founder, we diligently package found problems and aim to create several hero features together with potential customers who later might become design partners. Those solutions are easier described as value propositions. We’re not debating which software screen to build; we’re diligently and structurally crafting the best possible outcome to the problem at hand, a hero (feature) outcome so to say. “What would this look like if you had unlimited compute power (AI) and you’re just the controller behind the screen?” “Why would this be valuable to the org and to you?”
Deep into the Rabbit Hole
Yes, I know, we haven’t talked about the technical founder yet, have we? And in the dual residency, it takes two to tango, I know. Our learnings are grandest here. At Builders, we’ve been iterating our CTO residency for quite some time now and every iteration seems to involve the technical founder earlier in the process, and for good reason. As a CTO in residency at Builders, the aim is to get to know other founders and ultimately co-found a validated company so that you’re building something that is actually going to be used and have an impact. What good is crafting something that is never used at scale? Well, worth nothing, biggest nightmare for an engineer.
“not by building MVPs but to shatter assumptions”
Involvement of the CTO
So if the ultimate goal is co-founding, when does a CTO get involved with the hard problem the CEO is achieving to tackle? Like we said, earlier and earlier every iteration. Where we started at incorporation of the company, today we’re involving CTOs in shaping the minimal viable company. In that so-called shape phase, the resident CTO builds prototypes together to prove that certain hero features can actually be built, not by building MVPs but to shatter assumptions on technical abilities and models to make the dream come to life. Something interesting kept happening here: while overall confidence level grew for the business founder and the studio, the CTO tended to have a lower level than one would expect. Hard problem, large potential usage and impact, AI usage all over the place, what’s not to like? Let me explain…
Two to Tango
What’s not to like is the fact that the hero features can be seen as product responsibility and when this sword is not handled skillfully it can lead to feature projecting toward customers but definitely also to the CTO. In the worst form, it can be portrayed as, build this because that’s what the customer said they need. It’s as old as the Stone Age. This is, of course, not the wording of a true partnership and never leads to anything other than giggles and annoyance from engineers.
Dual Residency
So in our latest iteration, we involve the technical founders right after validation of the hard problem. Yeah, I know it makes the most sense, but it’s not easy because in the end you want to have solid confidence levels. Involving technical knowledge earlier also means that everyone expects more results in that crucial validation phase. The way we combat this today is to take the technical insights and knowledge and go sci-fi on the solutions. How can this be extraordinary, magical, out of this world awesome? If a resident CTO is not adding any value there, it’s fair to say that there might not be a match between the CEO and CTO anytime soon ;). But when the sparks do fly, this is where the two create a value proposition based on advanced technical abilities that will get the customers onboard, become design partners, and when a fit, launching customers, boya!
“Does that mean the two become co-founders early in the game?”
Hold up. Does that mean the two become co-founders early in the game? Actually no, all resident CTOs work on the challenges at hand and the partnering happens in the 3 months following that interaction. Not just based on who likes who, but also on a quantifiable manner. Steadily we’re building up more knowledge on what works and creating more and more studio intelligence around that. As you can imagine, this will become a software platform on its own just to quantify the founders and their personalities.
The Path Forward
Seems like it won’t take many more iterations before our residency is agnostic of the type of founder (tech or business). Today, one could argue that having a studio without having the right mix of founders in residency is doomed to fulfill one of the critical founding roles themselves for the long run. It could be a strategy, but to me, the dual residency is the only way to grow confidence each step of the way and to empower entrepreneurs to build those stellar companies, no matter tech or business founder.
For now, let’s keep solving those hard problems in a magical way.
Cheers, your friends at Builders 🖖🏻
