How CEOs and CTOs should structure technology teams in 2026

How CEOs and CTOs should structure technology teams in 2026

In September 2026 our news desk logged 28 changes that software vendors made to their products or terms where both a notice date and an effective date were published. The median notice was 31 days. Six gave a week or less, and three took effect the day they were announced. Eight gave more than 90 days. Four of the 28 switched a feature on by default for existing customers, so the customer had to act to opt out.

In the same month our launch board recorded 60 launches: 28 new AI models and 32 products. When we reviewed the products, many turned out to be relaunches, some had no named company behind them, and several published no price. Put the two counts together and you have the working conditions of any technology team in 2026: the tools you rely on change under you at a month's notice, sometimes less, and the stream of new tools is fast and hard to judge. This guide is about how a chief executive and a chief technology officer should organise people so that someone owns each of those problems, and so that delivery does not slow down while they do.

What our own data says about the job

The vendor count is small, one month and 28 changes, and it only covers changes that published both dates. Even so it points at a gap that is easy to miss. Engineering teams own the code they write. Finance owns the contract. Nobody owns the moment a supplier changes what the contract means in practice: a price rise, a retired feature, an AI feature turned on for all your users, a new data processing term.

A median of 31 days is enough time to act only if the notice reaches someone who reads it, understands what it affects and has the authority to decide. A zero-day change needs a decision the same week. A default switched on for existing customers can move your customers' data somewhere new before anyone in your company has read the email.

So the first structural point is not about engineers at all. Every supplier your product or your operations depends on needs a named owner inside the company, with a short list of what they watch: price, terms, data processing, deprecations and default settings. The rest of this guide builds the teams around that.

Start from the flow of work

The most useful model we have found for organising technology teams is the one set out by Matthew Skelton and Manuel Pais in Team Topologies. Their own site defines four team types:

• Stream-aligned team: aligned to a flow of work from a segment of the business, such as a product, a customer journey or a market. Most of your teams should be this type. They build, run and change their part of the product from start to finish.
• Platform team: provides "a compelling internal product to accelerate delivery by stream-aligned teams". In practice this is the shared build pipeline, hosting, observability, identity and the approved AI tools, offered as a service the other teams choose to use.
• Enabling team: helps a stream-aligned team get past an obstacle, and spots missing capabilities. Security specialists, test automation coaches and people who help teams adopt AI tools safely often work this way, for a period, then move on.
• Complicated-subsystem team: used only where "significant mathematics/calculation/technical expertise is needed", such as a pricing engine, a search ranking system or a model you train yourselves.

They also name three ways teams interact: collaboration for a defined period to discover something new, "X-as-a-Service" where one team provides and another consumes, and facilitation where one team helps and mentors another. The principle underneath all of it is to respect cognitive load: a team can only hold so much in its head before quality and speed suffer.

Why this matters more with AI tools than before: the DORA research programme at Google Cloud surveyed nearly 5,000 technology professionals for its 2025 report and concluded that AI works as an amplifier, magnifying an organisation's existing strengths and weaknesses. It found that 90% of organisations had adopted at least one internal platform, and a direct link between high-quality internal platforms and the ability to get value from AI. A clean team structure with a good platform gets faster with AI. A tangled one gets more tangled, faster.

Who owns what: CTO, CIO, CISO and the board

Titles vary, and small companies combine them. What matters is that each of these jobs has one owner.

Role	Owns	Typical question they answer
Chief technology officer	The product's technology: architecture, engineering teams, delivery, technical hiring	Can we build and run what the business needs, safely and on time?
Chief information officer or head of IT	The company's own systems: laptops, identity, office software, finance and HR systems, supplier management for internal tools	Do our people have working, secure tools, and do we know what we pay for?
Chief information security officer or security lead	Security risk across both: policy, testing, incident response, supplier security checks	What could hurt us, how likely is it, and what are we doing about it?
Data protection lead	Personal data: lawful basis, processors, retention, subject requests	Are we allowed to do this with this data, and can we prove it?
The board	Accepting risk, setting appetite, checking assurance	Are the right people answering the questions above, and are we told the truth?

The security lead should not report to the person whose delivery dates they might need to stop. In a small company that is hard; the practical answer is a direct line to the chief executive or the board for security matters, even if day-to-day line management sits with the CTO.

The UK government's Cyber Governance Code of Practice, published in April 2025, sets out what boards and directors are expected to do, under five principles: risk management; strategy; people; incident planning, response and recovery; and assurance and oversight. The National Cyber Security Centre's Cyber Security Toolkit for Boards explains how to put the code into practice. Its introduction says board members have a critical role in making sure their organisations are "not just resilient and secure", but also ready to use what technology offers.

The government's own survey shows how far most companies are from that. The Cyber Security Breaches Survey 2025/2026, published on 30 April 2026, found that 43% of UK businesses identified a breach or attack in the previous 12 months, rising to 65% of medium and 69% of large businesses. Only 31% of businesses had a board member with explicit responsibility for cyber security. Only 15% had reviewed the cyber risks posed by their immediate suppliers, and 6% their wider supply chain. A quarter had a formal incident response plan.

Those supplier figures are the same gap as our vendor-change count. If only one business in seven checks its immediate suppliers, the named vendor owner we argued for above is not a formality. It is the missing job.

Build, buy or augment

Every technology leader faces the same three options for each capability. A simple rule of thumb:

• Build what makes you different and what you must change often. If customers choose you because of it, you need people who understand it deeply and can change it this week.
• Buy what is the same for everyone: payroll, accounting, email, identity, monitoring, most internal tools. Buying moves the work from building to owning a supplier, which is where the vendor owner comes in. Check notice periods and default-setting changes in the contract before you sign.
• Augment when you need more hands on work you direct yourself, for a period, faster than you can hire. Staff augmentation keeps the work and the decisions in your teams while an outside firm employs the people. Our guide to offshore development and changing IT delivery covers when that works, and our offshore staff augmentation rankings list firms that show evidence of the service on their own websites. We found 770 such firms in September 2026; almost none published founding year, team size or rates, so you will need to ask.

For single, well-defined jobs, independent freelancers are another option. The evidence on that market is mixed: short, simple jobs are disappearing from the platforms while larger, specialised work holds up. We looked at it in detail in is freelancing dying?.

Whatever you choose, keep ownership inside. An augmented developer can write the code; a stream-aligned team of your own must own the service, its on-call rota and its decisions.

An AI tooling policy people can follow

AI coding and writing tools are now in daily use. DORA's 2025 survey found 90% of respondents using AI at work, a median of two hours a day. More than 80% said it had made them more productive. But trust is thin: 30% said they trusted AI-generated output only "a little" or "not at all". DORA's central finding was that AI adoption now goes with higher throughput, and also with lower delivery stability unless there are strong controls such as automated testing and fast feedback.

DORA's AI Capabilities Model, published in September 2025, names seven conditions that make AI-assisted development work: a clear and communicated AI stance; healthy data ecosystems; AI-accessible internal data; strong version control practices; working in small batches; a user-centric focus; and quality internal platforms. The first of those is a policy, and it is the CEO's and CTO's job to write it.

A usable AI tooling policy fits on one page and answers these questions:

1. Which tools are approved, for which kinds of data, and on which contract terms. The platform team provides them; nobody signs up with a personal card.
2. Which data may never go into a tool: customer personal data, credentials, unreleased financial results, anything under a confidentiality agreement, unless the tool is approved for it.
3. Who is accountable for output. The person who merges code or publishes text is responsible for it, whoever or whatever drafted it. Code review rules do not relax because a tool wrote the first draft.
4. What must be tested. Because AI tools raise throughput and can lower stability, the policy should require automated tests and small changes. DORA's own capability list says the same.
5. How new tools are evaluated. Given how many launches are relaunches or have no named company behind them, the evaluation must include who operates the product, where data is processed, the published price and the notice period for changes.
6. Who reviews the policy and when. Quarterly is realistic given how fast vendors change terms.

Keep hiring junior people

When tools can produce first drafts of code, it is tempting to stop hiring juniors. We think that is a mistake, for two practical reasons. Senior engineers come from junior engineers; a company that stops hiring at the bottom has to buy all its experience later, at market price. And the job that grows when tools write more code is reviewing, testing and understanding it, which is exactly the skill a well-run junior programme teaches.

What changes is the programme. Pair juniors with a named senior. Make them own small services end to end, including on-call with support. Assess them on how well they explain and test code, not just how much they produce. Budget the senior time honestly: a junior programme costs mentor hours, and if nobody has those hours, the programme will fail quietly.

Measuring delivery without gaming it

DORA's software delivery metrics remain the most widely used measures, and its current guide, updated in January 2026, groups five of them into two sets:

• Throughput: change lead time (from commit to production), deployment frequency, and failed deployment recovery time.
• Instability: change fail rate (the share of deployments needing immediate intervention) and deployment rework rate (unplanned deployments caused by a production incident).

Use them per team, as a trend, and never as a target for individuals. Add two measures of your own that reflect the problems above: the number of supplier changes that reached their owner before the effective date, and the time from a security finding to its fix. Report all of it to the board quarterly, alongside the incident log.

Org shapes at 10, 50 and 250 people

These are starting points, not rules. Adjust for how much of your product is software and how regulated you are.

About 10 people

Who	What they own
CTO or technical co-founder	Architecture, delivery, security lead, AI policy, product suppliers
2 to 4 engineers in one stream-aligned team	The whole product, including on-call
Chief executive or operations lead	Internal IT, finance and HR systems, data protection lead
Outside help as needed	A security review once a year, augmented developers for peaks

One team, one backlog. The CTO holds the vendor list personally and reviews it monthly.

About 50 people

Who	What they own
CTO	Engineering, architecture, delivery metrics
3 to 4 stream-aligned teams of 5 to 8	A product area or customer journey each
1 small platform team	Pipeline, hosting, observability, identity, approved AI tools
Head of IT (can be part-time or outsourced)	Internal systems and supplier management
Security lead, reporting on security to the CEO or board	Policy, testing, supplier checks, incident plan
Data protection lead (often combined with legal or operations)	Personal data and processors

Each stream-aligned team names an owner for every supplier it depends on. A board member takes explicit responsibility for cyber risk.

About 250 people

Who	What they own
CTO	Product technology and engineering organisation
CIO	Internal technology and a supplier management function
CISO	Security across both, with a direct line to the board
12 to 20 stream-aligned teams, grouped by business area	Their services end to end
2 to 3 platform teams	Developer platform, data platform, identity and access
1 or 2 enabling teams	Security engineering, test automation, AI adoption
Complicated-subsystem teams only where justified	Search, pricing, in-house models
Data protection officer	Personal data, reporting to the board

At this size a supplier register with owners, renewal dates and notice periods is a system, not a spreadsheet.

A checklist for the next 90 days

1. List every supplier the product and the company depend on, and name one owner for each.
2. Ask each owner to subscribe to that supplier's change notices and to check default-setting changes within a week of each notice.
3. Draw your current teams as Team Topologies types. Count how many services each team owns and ask whether it is too many.
4. Decide who owns security and data protection, and make sure one board member holds explicit responsibility for cyber risk.
5. Write a one-page AI tooling policy using the six questions above, and publish it internally.
6. Start measuring the five DORA delivery metrics per team, plus supplier changes caught in time.
7. Keep at least one junior hire in the plan, with a named mentor and real mentor hours.
8. Write or update the incident response plan and run one practice exercise.

If you also run a content or marketing function, the same principle of named human accountability applies there; we set it out in how to structure a content team.

Sources

• Key concepts: definitions of the four team types, three interaction modes and cognitive load. Team Topologies (read 25 September 2026).
• How are developers using AI? Inside Google's 2025 DORA report: nearly 5,000 respondents, 90% using AI, median two hours a day, over 80% reporting productivity gains, trust figures. Google, 23 September 2025.
• Announcing the 2025 DORA report: AI as amplifier, throughput and stability findings, 90% of organisations with an internal platform. Google Cloud (read 25 September 2026).
• DORA State of AI-assisted Software Development 2025: report landing page and the amplifier finding. DORA (read 25 September 2026).
• Introducing DORA's inaugural AI Capabilities Model: the seven capabilities. Google Cloud, 24 September 2025.
• DORA's software delivery performance metrics: the five metrics and their definitions. DORA, 5 January 2026.
• Cyber Governance Code of Practice: the five principles for boards. National Cyber Security Centre and Department for Science, Innovation and Technology, published 8 April 2025.
• Cyber Security Toolkit for Boards: board role in cyber resilience and link to the Code. National Cyber Security Centre, published 30 March 2023, reviewed 8 April 2025.
• Cyber security breaches survey 2025/2026: breach rates by size, board responsibility, supplier reviews, incident response plans. Department for Science, Innovation and Technology and Home Office, 30 April 2026.
• TrustList news desk: 28 vendor changes with notice and effective dates, September 2026. TrustList launch board: 60 launches dated September 2026. TrustList offshore research: 770 firms with staff augmentation evidence, 16 September 2026.