Before you resource a 2027 tech initiative, define the work

Before deciding how to resource a 2027 tech initiative, define the work: the outcome it should reach, the first piece of work that has to move, the skills involved, who leads it and when those skills need to contribute. For a CTO, IT Director or Head of Engineering, those answers show whether the initiative fits the existing team, calls for an internal hire, or points to team augmentation or a dedicated team.

A familiar version of this: an initiative goes into the 2027 plan with a goal and a date, and somewhere in the planning conversation someone says "we'll need more developers". That may turn out to be true. As a brief, though, it can't be acted on yet. It doesn't say what those developers would build first, who they would answer to or when they would need to start, and it skips the possibility that the current team can take the work on with a change in priorities.

WHAT YOU’LL FIND IN THIS ARTICLE:

→ Why "we need more developers" is not yet a brief
→ The questions to answer before any resourcing decision
→ An illustrative example: an enterprise onboarding initiative planned for Q2 2027
→ How the answers point to the existing team, an internal hire, team augmentation or a dedicated team
→ What to decide now, and when to come back to it
→ How KWAN can help once the work is defined
→ Frequently asked questions

In short: a 2027 initiative is ready for a resourcing decision once the work is written down: the outcome, the first piece of work, the skills and how long they're needed, who owns priorities and technical decisions, the date those skills must start contributing, and what still needs internal confirmation. With those answers on paper, the existing team, an internal hire, team augmentation and a dedicated team can be compared on the same terms.

Why is "we need more developers" not yet a brief for a 2027 initiative?

Because it names a possible answer before the work has been described. A headcount is a response to questions nobody has asked yet: what these people would do first, for how long, under whose direction and from which date.

Two initiatives that both "need more developers" can need very different things: one a single identity specialist for a build phase, the other a group that can own a product area for a year. Sometimes the work fits a team already in place, once something else moves.

Defining the work is how you find out which case applies, before anyone assumes the answer in either direction. The brief can stay internal at this stage, and it's just as useful if the initiative ends up running entirely on the current team.

Which questions should come before the resourcing decision?

The questions below turn a 2027 initiative into a brief that can be decided. Each one is there because its answer changes which resourcing route makes sense.

What outcome should the initiative achieve?

Write the result in terms someone outside engineering would recognise: enterprise customers live without manual set-up, a migration finished, a regulatory requirement met.

The outcome sets the boundary of the work. A narrow outcome with a fixed date describes a phase of work. A broad outcome with no end point describes something the organisation will run for a long time, and that is a different staffing question.

Which part of the work has to move first?

Most initiatives don't need every skill on day one. Naming the first piece of work (a discovery phase, an integration, a data model) shows which skill is needed earliest and which decisions have to be made before anyone can build.

It also shows what can wait. Later phases can be resourced later, with better information, so the first resourcing question is often much smaller than the initiative.

Which skills might be needed, and for how long?

Name the skill and leave the job title for later. "Identity and single sign-on (SSO) integration" is more useful than "a senior backend developer", because it can be checked against the people already in the organisation.

Then estimate the duration: one phase, or ongoing work that continues after launch. Duration is one of the clearest signals in the decision. A skill needed continuously, beyond this initiative, is a case for building it in-house. A skill needed for a defined phase can be covered in other ways.

Who sets priorities, makes technical decisions and reviews the work?

This question is easy to leave until later, and it shapes the decision more than the headcount does.

If an existing team lead will direct the work and review every change, any additional person joins that team and its way of working. If no one has room to lead a new area, the initiative needs a lead before it needs more contributors, whether that lead comes from inside the organisation or arrives with a team.

When do those skills need to start contributing?

Start from the date the initiative has to deliver and work backwards to the date each skill must be contributing to the work.

That date is later than a start date. Access, context and a first reviewed piece of work all take time, so the contributing date goes into the plan first and the start date follows from it. Timing also decides which routes are realistic: a close date rules out options with long lead times, while a distant one leaves room to hire or to wait for internal availability.

What still needs to be confirmed internally?

Availability, scope and approval are the usual open items.

• Availability means a named team has said it can take the work, after looking at what it has already committed to for 2027.
• Scope means the boundaries are agreed by the people who own the outcome.
• Approval means the budget holder, in some organisations a CFO or Managing Director, has seen the brief.

Each unconfirmed item can change the answer later, so list them with an owner and a date.

What does a defined brief look like? An illustrative example

Illustrative example: the company and initiative below are fictional, created to show how the questions work in practice.

A B2B SaaS company plans to improve onboarding for its enterprise customers in the second quarter of 2027. In the planning meeting, the initiative arrives as a goal, a quarter and one sentence: "We'll need more developers for this."

Working through the questions gives the team a different starting point.

Question	Answer in the example
What outcome should the initiative achieve?	New enterprise customers set up their accounts, connect their identity provider and invite users without manual work from support.
Which part of the work has to move first?	Defining the SSO scope: which identity providers and protocols to support at launch, and which customers go first.
Which skills might be needed, and for how long?	Identity and SSO integration for the build phase. API work on account provisioning, which may continue after launch.
Who sets priorities, makes technical decisions and reviews the work?	The product manager for onboarding sets priorities. The platform team's tech lead owns identity decisions and reviews the changes.
When do those skills need to start contributing?	Worked backwards from the Q2 target, once the SSO scope is agreed. The exact date depends on that scope.
What still needs to be confirmed internally?	Whether the platform team can take on the identity work, the final scope, and budget approval.

 

The result is a brief specific enough to act on. It doesn't say the company is short of people, and depending on what gets confirmed, it can lead in different directions:

• The platform team confirms it can take the identity work if a lower-priority item moves to the third quarter. The plan changes and the existing team runs the initiative.
• The scope narrows to one identity provider for the first customers. The existing team covers it, and a second phase is planned for later in the year.
• The platform team can lead and review the identity work but doesn't have the specialist skill for this phase. That is the point where reinforcement is worth investigating: a specialist joining the platform team for the build, or an internal hire if identity work will continue well after launch.

Each of these is a reasonable result, and in each one the decision is made on the work, by the people who own it.

Which resourcing routes fit which answers?

Once the brief exists, the routes can be compared against it. A short guide to what each one asks of the brief:

• The existing team, or a change in priorities. Can the scope or the calendar be adjusted? Has the team that would take the work confirmed it has room, after looking at its other 2027 commitments?
• An internal hire. Is the skill needed continuously, beyond this initiative? If the organisation wants the capability in-house for the long term, a hire builds it there.
• IT Staffing & Team Augmentation. Will the client's own team lead the work, and would it benefit from specialists joining that team, working inside its processes and under its technical direction?
• Dedicated Teams & Integrated Squads. Is there a defined scope that justifies several roles working together, with responsibilities agreed from the start?

The difference between the last two is the unit: individuals joining a team, or a team built around an area of work. KWAN's guide to team extension vs dedicated squads compares them in more depth, including what each looks like in the first two weeks.

What should be decided now, and when should you come back to it?

The decision to take now is often smaller than a resourcing decision. It means agreeing what is still open, who decides and when the topic returns. A short note with these answers is enough:

• What still needs to be confirmed?
• Who needs to be part of the decision?
• When do we come back to this?

If the answers do lead to reinforcement, the steps that follow are approval, search, selection and integration. Each takes time, and how much depends on the organisation, the skill and the people involved. A candidate who is currently employed will usually have a notice period to serve, for example. Plan these steps backwards from the contributing date, using the durations your own organisation has seen on similar decisions.

Integration is easy to leave out of a plan. Access, context and a first reviewed piece of work come before anyone contributes fully, however they joined. KWAN's article on when new capacity starts delivering looks at that stretch in detail.

How can KWAN help once the work is defined?

KWAN can help discuss a brief that is already defined: the skills involved, how a person or a team would integrate, who holds which responsibilities, and the timing.

If there is a fit and suitable availability, KWAN can assess IT Staffing & Team Augmentation for specialists who join the client's team, or Dedicated Teams & Integrated Squads for a defined scope that needs several roles working together. With team augmentation, the client keeps ownership of product priorities and technical direction. With a dedicated team, who owns what is agreed with the client from the start.

An internal hire or a change to the plan may still be the better answer, and a useful conversation leaves room for either. KWAN, founded in 2007 and based in Lisbon, works with clients in the UK, DACH, the Nordics and Benelux.

Frequently asked questions

1. When should resourcing for a 2027 initiative be decided?

Once the outcome, the first piece of work, the skills, the ownership and the timing are written down. Then work backwards from the date the skills need to be contributing, because approval, search, selection and integration all sit before it. There is no universal lead time, so use the durations your organisation has seen on similar decisions.

2. Do I need a job description before talking to a staffing partner?

No. A draft brief is enough to start a useful conversation: the outcome, the first piece of work, the skills involved, who will lead and review the work, and when it needs to start. A formal job description can follow once the route is chosen, and it will be sharper for being based on that brief.

3. How do you know whether the existing team can take on the work?

Ask the team that would own it, with a defined scope in hand. Availability is something a team confirms after looking at its existing commitments, so a scoped request gets a more reliable answer than a general question about capacity. If the answer depends on moving other work, that trade-off belongs in the decision as well.

4. When does an internal hire make more sense than team augmentation?

When the skill is needed continuously, beyond the initiative, and the organisation wants that capability in-house for the long term. Team augmentation fits when the client's team leads the work and benefits from specialists joining it, for a defined phase or for longer. The two can also be combined, with a specialist joining for the build while a permanent hire is made.

5. What is the difference between team augmentation and a dedicated team?

The unit. Team augmentation adds individual specialists to a team the client already leads, while a dedicated team is a group built around a defined scope, with several roles and agreed responsibilities. KWAN's guide to team extension vs dedicated squads compares the two in detail.

6. Is "not yet" a valid answer?

Yes. If scope, availability or approval is still open, the right decision may be to wait, with an owner for each open item and a date to return to it. A deferred decision with a date is still a decision. Without a date, the same question tends to come back when the initiative is already under pressure.

---

If a 2027 initiative is already in the plan, the next step can be internal: sit down with the people who own the work and write down the outcome, the first piece of work, the skills, the owners and the date. If the answers point to a specialist or a team you'd like to discuss, send KWAN the brief as it stands, with the skills, setup and timing you're considering, and KWAN will look at whether there's a fit.