Own Your Technology, Do Not Build a Tech Team

Owning software requires control of the asset and its direction. Consider a business commissioning its own office building. The business decides what the building needs to accommodate, how much it can invest and whether the proposed design serves its plans. It appoints specialists to carry out the work. Once the building is occupied, it can contract maintenance and cleaning without employing those people itself.

Software can be approached in the same way. Your organisation determines what it needs the software to do and where it wants to take it. A supplier can develop the product and maintain it as those needs change. Neither arrangement removes your responsibility for the asset or requires every person working on it to be an employee.

When we refer to a technology team here, we mean a software development team. This is a position about employing people to build and maintain custom software, rather than a recommendation to remove every technology role in a business.

The business should retain a sponsor with the authority to set priorities and make decisions, with a project manager on the supplier side responsible for coordinating delivery.

The sponsor sets priorities, approves investment and decides whether the product meets the business need. The supplier's project manager coordinates delivery and brings decisions back to that sponsor. The separate role of technical leadership in offshore development covers engineering decisions, coaching and assessment of the work.

Practical control also requires access to the work. Our recommendation is that the codebase lives in your organisation's own Git repository, the system that stores the source code and its history. Documentation should be delivered at every milestone, rather than accumulated as a handover task at the end.

These are practical provisions for continuity. A repository alone does not explain how a system works, and documentation that arrives only when a relationship ends cannot help you assess progress throughout the build. Keeping both current gives another team a better starting point if the delivery arrangement changes.

A failed supplier relationship is a reason to examine how the work was commissioned and managed before choosing the next delivery model.

Changing who employs the team does not, by itself, establish a strategy or a sound delivery process. The business still needs a clear brief, a way to judge proposed work and the discipline to assess progress against the intended outcome.

The same procurement care applied to other substantial investments belongs here. Define the work, invite suppliers to respond, examine their proposals and perform due diligence. A supplier's failure should be examined on its merits. So should the brief, the decisions made during delivery and the way further spending was approved.

Dependency can develop inside a business too. When knowledge sits with a small number of employees, the perceived cost of losing them can make change feel impossible. Retaining the team becomes an obligation driven by uncertainty about what would happen without it. Direct employment has then provided less control than the business expected.

A proof of concept is a small test of whether a proposed approach can work. It should test the highest-risk assumptions within an intended product direction, with the wider investment visible from the beginning.

The attraction of software is that an organisation can explore an idea before committing to the whole product. A small initial build can demonstrate whether something is possible and whether the opportunity deserves further work.

That advantage can also obscure the commitment. A successful demonstration creates enthusiasm. The next increment appears manageable, and attention shifts to what can be added next. The original experiment gradually becomes the product without a deliberate decision about the scope or cost of that transition.

For example, a business approves $50,000, then another $50,000, then another. Repeated approvals can eventually amount to a million-dollar investment. These figures illustrate the funding pattern; they are not a project estimate or a claim about a particular client's spending.

There is also more to consider than the next feature in isolation. If a fourth feature needs to work with the first three, its scope includes those connections and checking that existing behaviour still works. A simple feature description can conceal a larger integration and testing task.

The building analogy is useful again. Start with the intended building, then identify what needs testing before construction proceeds. For software, define the destination and extract a proof of concept that tests the areas of greatest uncertainty. The results should inform the plan, including whether to proceed. The prototype should not quietly become the plan simply because money has already been spent on it.

Our starting recommendation is to avoid establishing an internal software development team below 200 employees, or below 500 in a professional services business.

These are practical thresholds in our advice, rather than research-derived cut-offs. Reaching either number does not automatically justify a team. The question remains whether the organisation has enough reason to operate a software development function and the leadership to manage it.

A company whose core product is software needs a more specific assessment. A small software business with experienced technical leadership can have a reason to build internally well before it reaches those headcounts.

For non-technical founders, our recommendation is to externalise development until there is a chief technology officer (CTO) with a proven track record. Hiring developers does not supply the same capability as having someone who can lead them, assess technical decisions and take responsibility for delivery.

Before hiring, settle five decisions:

• Product Direction
  What you want the software to become.
• Accountability
  Who remains accountable for the product and how the people delivering it will be managed.
• Proof of Concept and Investment
  What the initial test must validate and what evidence will support further investment.
• Code and Documentation
  How both will remain accessible throughout the work.
• Maintenance and Continuity
  How the software will be maintained after launch and how work will continue if people or suppliers change.

An internal team is one way to deliver the work. A managed external team is another. Both need clear direction and capable management. For a business without established software leadership, creating the team can add a second undertaking before the first has delivered anything.

The next decision is whether the business needs to operate a software development function to own the product it wants.