Core and Context

How do you invest your engineering dollars?

So you have had a conversation with the CEO, set your strategic objectives, and defined your investment buckets, as explained in the first post. 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, Inflection considers these capabilities (messaging: Compute instances: hosted databases: telephony are a few examples) as context.

However, Core and Context is not sufficient framing for investments. There are times when something context may be done in house. Usually, the reason is the technology itself is context: however, current implementations available do not meet the required characteristics. In this case, something contextual must be done in house.

At inflection, this is modeled using the 2x2 matrix shown below:

A distinction is made between what we choose to develop in house vs what we ask external partners to be doing. Some of this is easy: Inflection is in public cloud, and there is no intention of building our own data center or be in a colo (lol, how 2005). In addition, we do not intend to manage our own databases: We prefer use cloud hosted version. Similar conclusions are reached for messaging, elasticity in cloud etc.. we prefer to have our cloud provider take care of it. (Context- lease).

Other things can be trickier. Should we build our own subscription/billing software? Solutions in the market may not be able to address the nuanced use cases we have. Other times, we need to control the roadmap because there are time critical features that a vendor may be unwilling to address. These decisions need collaboration with the executives in making hard decisions. Sometimes these fall in the (Context-Build) bucket

What is clear at Inflection is the secret sauce (Core-Build) . There are certain parts of Inflection - the data pipeline for example, given that we are a big data company - that we must control. There are parts that are open sourced or vendor acquired, but the overall pipeline must be controlled by us. This is part of our secret sauce, and Inflection will never consider asking someone else to build it.

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) and even though the big picture is Core-Build, we ask for help from outside parties to do part of the work. The intent always is to tightly manage the quality of the work, and then bring it in house once the spike in work subsides. (Core-Lease)

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.