One of the most strategic decisions a technology leader can make is: Should we build an in-house team, partner with an outsourced development team (“borrow”) or buy off-the-shelf products?

The most likely answer: Create a leverage mix of all three that increases optionality in the short term and maximizes adaptability over time.

In this guide, I’ll share best practices for

1. anchoring the build, borrow or buy decision around key financial metrics,
2. identifying the leverage mix that is best for your team’s needs today, and
3. building in flexibility so you can adapt the leverage mix as your needs change.

Build, borrow and buy your way to your goals

Whether you are chasing product/market fit, scaling a team, merging multiple teams post-M&A, or increasing efficiency of an established team, the job of a technology leader is to get high quality products and services into the hands of real users as quickly as possible. To achieve this, you can build, borrow and/or buy your way to your goals:

• Build your own team - hire and grow your team organically
• Borrow - partner with third party software development consultancies
• Buy - buy a whole company, a software platform, or licenses 

Given that the needs of your team will change over time, it’s important to have a process in place for quick triage of the build, borrow, buy decision. This process will give you a jumping off point from which to do deeper due diligence.

Deeper due diligence is necessary, because the answer to “Build, borrow or buy?” is never black and white. This is because internal priorities and external influences are ebbing and flowing constantly. Therefore, you will likely benefit from a healthy blend of build, borrow and buy. For example, many CTOs actively hire full time employees and build up their in-house team in parallel with partnering with a software consultancy for some work streams.

Anchor your key financial metrics

The first step in the process is creating a ballpark sense of four key financial metrics:

• Cost vs profit center
• Return on investment (ROI) 
• Cost of rework
• Cost of delay

If you’re reading this and thinking, “I’m a CTO, not a CFO. Why do I need to understand these metrics?” I encourage you to think about it this way - It’s rare for a CEO, CFO, board or other stakeholder outside of the tech team to have the time, knowledge AND data to calculate these numbers without you. 

For example, does your CFO have the time, knowledge and data to dive into the weeds enough to determine how much money and time you are spending on creating new features vs reworking mistakes? If not, you can be a valuable resource here.

Cost center or profit center?

Is your team viewed as a cost center or profit center? 

Historically, organizations treated tech teams as ‘cost centers’, aiming to get software built as cheaply as possible. However, many organizations today realize that they are technology-first companies, and that their software products and platforms are true revenue drivers and value creators.  As a result, many tech teams are treated as profit centers, with companies viewing the time and money the company spends on building its products as investments from which there is a ton of potential upside. 

Call Center as Profit Center

In the ’90s, I was running a global call center for a SaaS company. When I took over the team, it was being run as a cost center by the executives. Every time we asked for money to hire more people, invest in our employees, or build out features that would help us do our jobs more efficiently, we were rejected, since we were a cost center. 

I started pouring through the data. The call center charged for customer support. We had a premium level of support, but it wasn’t productized and it was barely used. Further, the sales team was heavily discounting the customer support fees because these fees weren’t commissionable. The sales folks were giving new customers deep discounts on customer service, in order to keep their license fees high, which drove up sales commissions. 

My team and I created a four-tiered support level, with each tier commanding higher price points for various service add-ons. We also collaborated with the sales team to enable them to earn commission on the customer support licenses they sold. We then marketed the new service tiers. Within a year, we were the most profitable department in the entire company.

We were then viewed as a profit center, and were able to get funding to invest in our future.

Do you know if your team is viewed as a cost center or profit center?

If you are viewed as a cost center, then stakeholders are likely viewing your expenses as pure costs, which is going to limit investment opportunities you make in your software and your team. On the other hand, if you are viewed as a profit center, you will likely have ample opportunity to have rich discussions around which investments the company can make to get the biggest return and to drive value.

Return on investment (ROI)

Ideally, your team is viewed as a profit center, and your organization wants to support you in achieving the highest return for your investment in building your software, and therefore the highest value for both the business and your customers. If this is the case, then calculating your team’s ROI is a valuable tool to have in your conversations with stakeholders to help you with your “Build, borrow or buy?” question.

To calculate your team’s ROI, first identify which deliverables have revenue generating goals, and which have cost savings goals (which will then create additional profits). For each major deliverable your team is responsible for, calculate the ballpark revenue and/or profit you’re likely to directly or indirectly create, and the rough cost associated, assuming no major costs due to  rework or delay (see next section for how to add these in).

Retail Tech Team ROI

Stride built and deployed performance improvement features for a retail client that improved the speed of their e-commerce website. For an investment of $750k, the performance improvements brought in $55M in revenue that wasn’t otherwise being captured. So, for every one dollar the company spent, they got a return of $73. And, they captured this revenue within a four-4 month period, which would not have been possible if they waited until their in-house built up the bandwidth and skill set to do this work.

Not only was ROI exceptional, time to market was improved by using the “Build, borrow, buy?” framework to identify that this work was done most effectively by a third party.

Don’t worry about being exactly accurate right up front. Instead, do the best you can, and refine over time. The key here is to track progress towards your increased revenue or profit goals, so that you can continue to justify your spend to your CFO, CEO and other stakeholders.

Cost of rework

The cost of rework is defined as: Time or money spent redoing something because of it being done incorrectly.

Note: I do not categorize refactoring as rework, because refactoring is an intentional decision to change your product to increase efficiency, quality, or robustness in the future.

Regardless of where your team is in the software development life cycle journey, it’s a good idea to have a handle on your potential cost of rework.

As with ROI, aim to track your costs of rework as they are incurred. Be lean about it. There’s no need for fancy tracking, but do capture ballpark costs in a Google sheet. By tracking these costs, which are often hidden and not explicitly called out, you can track them against your ROI to get a true picture of your spend and your profits.

Because the costs of rework are only known after they occur, I find it helpful to try and predict the ones that are either the most likely to happen, most costly if they were to occur and highest risk.

Have a brainstorming session with your team to draw out potential costs of rework. If your team gets stuck try thinking about potential root causes of rework to start thinking about where these costs may be greatest and most likely.

Root causes can include:

• The individuals working on the product are not skilled enough in the areas required to produce high quality code.
• Requirements are unclear or change too often.
• Communication within or among teams is poor.

There are many, these are but a few to illustrate.

For each potential area of rework identified, what is the ballpark in terms of how much it would cost (time and money) to redo/fix? That is, if your team fails to deliver, how costly is it to fix this failure?

Even if you can’t peg a true dollar cost to the major possible rework items, it’s a good idea to capture the estimated order of magnitude for each, so that you can identify which to keep an eye on.

Cost of delay

Next, ballpark your cost of delay. Specifically put estimated dollar amounts against these questions:

• How much will it cost you in lost revenue and/or market share for each week your feature/product is delayed getting to market? 
• Will another competitor beat you to market and is that ok? 
• Will you miss an important deadline and what are the ramifications?
• Will a big potential customer go to a competitor?

In order to ballpark potential costs of delay, consider the reasons for possible delay, which can include:

• Slower than anticipated hiring
• Higher than anticipated turnover
• Hiring more junior folks than planned
• Onboarding delays
• Rework (as detailed above)
• Too much Work In Progress (WIP) leads to lots of stuff in flight, with little getting “Done”

As with ROI and cost of rework, estimating your cost of delay is an iterative process. It’s more important to have a rough, quick estimate that you can go back to and refine over time than to waste time diving deep into the weeds here.

The “Build, borrow or buy?” decision tree

Armed with your ROI, cost of rework, and cost of delay, you can now run through the “Build, borrow or buy?” decision tree below to get a rough starting point for how to approach balancing hiring, outsourcing, and buying off-the-shelf.

I created this decision tree to help add optionality and flexibility to the “Build, borrow or buy?” decision process. Too often, I speak with CTOs who are juggling multiple high priority projects simultaneously.

The CTOs who get into trouble are the ones that fail to consider all of their options early and often. Having optionality at your fingertips is critical.You do not want to be in a position where you are unable to achieve your goals, only to find out you have no alternatives to the path you are already on.

The decision tree is going to give you a quick, initial assessment of how to approach building your products and achieving your goals in a way that is bias towards action and at the same time is fluid and iterative.

To start, for each product or major deliverable, run through the decision tree:

As you go through the decision tree, capture the ‘answer’ for whether you should ideally build, borrow or buy your way to each major deliverable on your roadmap. You may wind up with something like:

Fine tune your ideal “Build, borrow, buy?” leverage mix

As you can see, the decision tree is the starting point, but we need to drill down into more details to get a richer, more accurate answer to “Build, borrow or buy?” Once you have an initial assessment using the Decision Tree, layer on priority and cost to help you fine tune your leverage mix options.

Here’s how:

Using the matrix created above, add in priority, and due dates for each deliverable, as in the following example:

For purposes of determining “Build, borrow or buy?” options, how deep you want to go into prioritization best practices is up to you.

* Two notes on prioritization best practices

Michael Kellman, Partner at Stride

Priorities should come from goal setting and agreed upon outcomes. At the Chief Technology officer (CTO) and Chief Product Officer (CPO) level, there needs be general alignment on the goals of the organization, division or team for a given time frame (next month, quarter or half). Prioritization on the micro-level comes from aligning the question in front of you with those higher level goals. If we all agree on where we are trying to go, then what we should do first should be relatively easy to agree on.

Step 1: Agree on desired outcomes (high level, C-suite, leadership)

Step 2: Break down  those high-level outcomes into concrete feature ideas or enhancements and use them to drive prioritization of work (PMs, Tech Leads)

Step 3: Complete the work and track how it helps you get closer to achieving the goals

Rob O’Brien, Partner at Stride

A simplified way to think about the Chief Technology officer (CTO) and Chief Product Officer (CPO) goal setting dynamic is replicating the pattern of ownership, goals and focus areas of a Product Owner (PO) versus a Tech Lead on a delivery team.

The CPO owns the WHY and WHAT (i.e. business and user goals).

The CTO owns the HOW and Quality (i.e. Technical goals).

The CPO should prioritize based on business and users goals and the CTO should prioritize technical goals in the service of the CPO’s business and user goals.

Ultimately they should have separate but aligned goals and the conversations to get those priorities and goals aligned is extremely important to do upfront because they can lead to necessary adjustments to priorities and goal definition.

E.g. CPO has #1 priority business goal of getting from 100,000 to 1,000,000 daily active users (DAU) by the end of the year and #2 priority user goal of standardizing the design across all parts of the product. With that context, the CTO might make his team’s  #1 priority to move their technology to the cloud to be able to handle that 10x increase in DAU scale and his #2 priority to implement the technology necessary for a design system to ensure simple standardization of designs across the product. 

Now, you’ve got a matrix that serves as a starting point for a conversation with your stakeholders. And, the matrix will serve as a high-level ideal that you can base your actual plans off of.

Build in flexibility to enable change over time

As I mentioned at the very beginning, building in flexibility and optionality to your goals is key. What your team needs today will not be what it needs tomorrow.

So, build in flexibility across all three levers in your build, borrow, buy model:

• Build: Always have a pipeline of active and passive candidates that you can hire full time. Have your recruiting team do this by engaging with passive candidates regularly through events and touch points. In addition, keep up networking within your peer group so that you have a highly engaged group of individuals you can reach out to for referrals as needed,  and have a network of freelancers that you can call on for temporary and special projects.
• Borrow: For all of your third-party engagements, build in flexibility into the contracts and engagements. For example, try to incorporate ramp up and down clauses so that you can modify the team size over time.
• Buy: For all software licenses you buy, always know when the renewal dates are so that you can evaluate your needs without getting unwittingly roped into a renewal. 

Conclusion

You are now armed with a framework for guiding you through the critical question of “Should we build an in-house team, partner with an outsourced development team (“borrow") or buy off-the-shelf products?”

Yet, this guidebook is only the tip of the iceberg.

As you work through this framework and have questions, I’m here to help. The devil is in the details and I want to be there to support you as you go through this journey.

That’s why I’m offering two free consultation sessions for anyone with access to this guidebook. To arrange your sessions, email me and mention this guidebook.

Onward!