Skip to content

Hit Squads

Hit Squads

A hit squad is a cross-team group of individuals focussed on solving high priority, well-defined ways of working problems.

A ways of working problem could be anything that affects the department’s practices and capabilities.

Priority of problems is relative, but should consider the impact of the problem (and its solution), as well as the urgency, where compared to other known problems that need solving. Priorities will change continuously, and therefore a hit squad must readily review priorities, and pause or cancel their programme of work.

Commencing Hit Squads

Anyone can create a hit squad, at any time. However, the following principles must be followed:

  • The problem must be well defined, meaning it is:
    1. Clear – it is described using plain and simple language, and is unambiguous. It describes a problems that needs solving, not a solution.
    2. Specific – it is a single and discrete problem, not a general theme or idea.
    3. Aligned – the group are aligned that this is the problem that the group must solve.
  • Priority is determined:
    • Key stakeholders, typically including members of the department leadership, agree that this problem needs solving and should take priority over other problems
    • There are enough team members interested, able, and committed solving this problem as a priority, taking into consideration their other work commitments.
  • Membership and sponsorship must be identified (see Ownership)
  • Documentation must be maintained: the purpose, plan, and status of the hit squads activities must be kept updated.

Creating Solutions

The fundamental goal of a hit squad is to solve a problem, however, it likely to be necessary to perform experiments in order to determine the best solution/s to the problem.

Experiments

Experiments

Following the conclusion of an experiment, the hit squad will determine whether further experimentation is required, or whether an acceptable solution has been found.

The outcomes of this may include:

  1. Creation and/or cessation of mechanisms for the Ways of Working toolkit, which may be determined to be “Defaults”
  2. Training, knowledge sharing, and/or the creation of a Community of Practice.
  3. The adoption and/or retiring of software tools.

Concluding Hit Squads

A Hit Squad may conclude (come to an end) for several reasons, such as:

  1. A solution has been found and agreed upon
  2. No viable solution has been found, and the problem is determined to be unsolved.
  3. The problem has gone away or is no longer a priority

The members of a hit squad are responsible for reaching a conclusion and ending their activities. They are also responsible for documenting the hit squad activities and outcomes, and communicating the conclusion to the department.

The sponsor can support the team in reaching a conclusion, and may request that the hit squad concludes if they become aware of concerns or issues with or surrounding the hit squad's activities.

Ownership

Owner Responsibility
Hit Squad Owner One specific hit squad member. Responsible for ensuring that the hit squad perform their activities, particularly communication and consultation with stakeholders.
Hit Squad Responsible for scoping, planning, conducting the hit squad, and documenting and communicating all plans and outcomes.
Hit Squad Sponsor A DMT or LG member who acts as primary stakeholder and consultant to the hit squad and supports the team with decision making.

Suggested Flow

The members of a hit squad can conduct their actions as they see fit, this suggested flow aims to provide a starting point if you are not sure what to do. You may well need to adapt this as your situation requires.

Before kick-off, two of more team members will have decided that a problem may benefit from a hit squad. They will have a simple understanding of what the problem is, but may not have defined it fully. They may already have a sponsor and

Between each stage, consult with stakeholders and evaluate priority and viability, and whether the hit squad should continue, change course, or conclude. In this suggested flow, stakeholders includes the hit squad sponsor.

  1. Define and align

    1. Produce a well-defined problem, and ensure everyone is aligned. Determine:
    2. Document and seek feedback from stakeholders.

  2. Determine an objective and simple success measures

    1. Identify what success means for solving this problem, and how it can be measured. Keep it simple and achievable. Consider qualitative and quantitative measures.
    2. Document and seek feedback from stakeholders.

  3. Ideate

    1. Ensure sufficient research and knowledge acquisition is performed. Identify SMEs in the department. Identify resources.
    2. Identify possible solutions to the problem. Use structured workshops where possible.
    3. Present proposals to stakeholders and seek feedback.
    4. Iterate the above until you have converged on a small number of proposed solutions.

  4. Experiment

    Perform structured experiments to validate (or disprove) proposed solutions. This may be a single experiment, a series of experiments, or experiments run in parallel.

  5. Review

    Share the outcome of the experiments with stakeholders.

    Has this experiment successfully solved the problem? Have your success criteria been satisfactorily met? Do they need to be modified based on what you have learnt.

  6. Iterate

    Iterate through the ideation and experimentation as appropriate.

  7. Conclude

    Wrap up the hit squad once a conclusion has been made, ensuring that a plan is in place for communicating the conclusion, and implementation, including knowledge sharing, or training.

Tips

Be quick. Hit squads should aim to be as short lived as possible. This can be enabled by:

  1. Focus and simplicity: make sure the problem and objective is clear and small. Larger problems are more complex and harder to solve, require a larger time commitment.
  2. A bias towards action: avoid decision paralysis and over preparation: find the smallest, simplest action that can be taken rapidly, then iterate fast.
  3. Short, quick experiments create learnings faster. Avoid long running experiments that produce no insights or outcomes for long periods.

Avoid waste. Your time is limited and valuable, use it carefully:

  • A little research goes a long way. Don’t rely on assumptions or past experiences alone.
  • Measuring success and performing experiments is time consuming, keep them simple and achievable, and prioritise carefully.

Failure is good, iteration is great.

  • Experiments may fail, and that is OK. It is perfectly valid to disprove a solution.
  • Create success metrics before defining the experiments, to avoid creating biases.
  • The objective may well aim for a first iteration of a solution, upon which there will be continuous improvement.

Objective Examples

Simple Objective

Problem: It isn’t clear who has read RFCs

Objective: Create a mechanism for identifying when RFCs have been by relevant stakeholders.

Success Measures:

  1. RFC creators can find out who has read the document, regardless of whether they provided feedback, without having to ask around
  2. Business stakeholders identify an improvement in RFC visibility

Using OKRs

In this example, the same discrete problem links to other problems, and so a higher level objective could be determined. Which may have numerous key results. This Hit Squad identify the first key result, and this becomes the focussed goal of the hit squad. Later or concurrent hit squads could tackle other key results for the same objective.

Problem: It isn’t clear who has read RFCs

Objective: Improve RFC engagement

Key Result: Create a mechanism for identifying when RFCs have been by relevant stakeholders.

Success Measures:

  1. RFC creators can find out who has read the document, regardless of whether they provided feedback, without having to ask around
  2. Business stakeholders identify an improvement in RFC visibility