Core vs Context
So you have had a conversation with the CEO, set your strategic objectives, and defined your investment buckets. Great. What should you have your teams work on, and where should you rely on others (consultants, contractors etc?). A CTO must always have a clear picture of what is core and what is context.
Core is defined as being part of the secret sauce of the company. Anything that is a competitive advantage or the key value add in the company is core. Anything that allows us to delight customers or move faster is core.
Contextual work is work that is necessary, but not necessarily done by your engineering team. It may be a competitive advantage: A CI/CD pipeline that allows rapid deployment of software is certainly a competitive advantage (necessity, actually). However, that does not mean that the work needs to be done in house. It might be advantageous to have domain experts design it for you, and for your team to carry forward and maintain the implementation. In today’s age, think about Infrastructure and Platform services that are offered by cloud providers: It is appropriate to not try to replicate what is already being offered, in most cases (there might be specific reasons to deviate, particularly if the attributes of a platform service do not meet the needs of your specific niche). But for the most part, horizontal capabilities (messaging: Compute instances: hosted databases: telephony, for example) should be treated as context.
However, Core and Context is not sufficient framing for investments. There are times when something context may be done in house. Often, the technology itself is context: however, current implementations available do not meet required characteristics. In this case, something contextual must be done in house.
I model it using the 2x2 matrix shown below:
Context-Lease
For most companies, it makes sense to be in public cloud and to use managed services. All of this is context, and it is functionality you lease.
Context-Build
Other things can be trickier. Should a company build its own subscription/billing software? Solutions in the market may not be able to address the nuanced use cases you have. Other times, you need to control the roadmap because there are time critical features that a vendor may be unwilling to address. These decisions are decisions and can result be considered context, yet a build decision.
Core-Build
This is your secret sauce . This is why customers come to you and what you have to do better than anyone else. Focus on this bucket.
Core-Lease
We may at times ask from help from contractors for specific tasks. Often this is because a spike in work comes along (e.g. refactoring a large piece of code). Even though in the big picture the work is Core-Build, we ask for help from outside parties to do part of the work. Manage the quality of the work, and then bring it in house once the spike in work subsides.
It is essential for CTO’s and technology leaders to carry this picture in their head, and ensure that the right work is being done in the right place. This, combined with the Investment strategy described previously allow investments to be correctly made and tracked.
