I did say I was going on holiday, so naturally the next thing I have done is write another post.

If you have not read Rebuilding Momentum already, I would start there. This appendix assumes the direction set out in that post, so quite a lot of what follows will make considerably less sense without it.

I have had some really good comments off the back of it, and I'm glad people have taken the time to read it properly and think about what it would mean in practice. Nobody has told me they hate it yet. If you do, please tell me.

In the original post I deliberately stopped short of prescribing the finished structure. Most of the questions I have had since, though, have been practical ones: what would a Team look like, who leads what, how would permissions work, where does rank fit?

So this is the working model I broadly have in my head. It is here to make the direction concrete enough to discuss and test, not to settle the finished structure. The Team names, positions and mappings below are examples. The new CO/XO and the people carrying the work should be free to keep, combine, rename, split or discard them as they turn these principles into an operating model. It is not a final organisation chart or a set of appointments.

The strategy is ultimately about making UNITAF exciting and growing. Anything in this appendix therefore has to work for the Unit we have now, but it also has to keep working if we grow, add new platforms, play new games or find entirely new things that need organising. The structure should be able to expand, split, combine and create temporary Teams without us needing another wholesale redesign every time UNITAF changes.

Our current structure can make that harder to see than it needs to be. Generic staff positions often bundle several responsibilities together, which creates three fairly predictable problems.

This should not read as a plan to give everybody a second job. Most members can simply deploy and enjoy UNITAF. For people who do want to help, the aim is to make that help easier to understand and easier to fit around real life.

If this works, this is what members should feel

Start with what UNITAF needs

Before deciding which Teams or positions should exist, it helps to separate the levels. Start with the outcome UNITAF needs, then work down only as far as the structure required to keep it covered.

The order matters. We should not start with an organisation chart and find things to put inside it. Start with the need, identify the responsibilities, then choose the lightest structure that makes those responsibilities clear.

The bullets in that table are the important part. They are not a list of jobs for one person. They are the responsibilities UNITAF needs covered. Some will become positions, some belong together in a Team, and some only need a temporary Project when a larger change is required.

Positions should describe the responsibility

Recruitment is a useful example because several very different things have historically sat inside the same team.

One person might only want to be an Intake Instructor. Another might enjoy talking to applicants but have no interest in running an intake. Somebody else might happily do all three.

All of those are useful contributions. The system should allow all of them.

That means somebody can hold several positions within the same Team, and positions can have several holders where the responsibility needs more capacity or continuity.

These positions would be visible through Get Involved, the part of the UNITAF website where members can see contribution opportunities and vacancies, put themselves forward, and see who currently holds the positions.

The titles should tell members something useful. If somebody sees Mod Tester, they should immediately understand roughly what they are volunteering to take on.

Clear positions make gaps and inactivity visible

This is one of the biggest advantages of the model because it lets us judge the outcome instead of the org chart.

If Recruitment needs three Intake Instructors, and three people are assigned but intakes consistently are not happening, we know there is a problem. We can speak to the people involved, establish whether they still have the time and interest, end appointments where necessary and reopen the vacancy.

If there are plenty of people welcoming applicants but nobody advertising externally, we know exactly what help to ask for.

That is considerably clearer than asking whether somebody is still an active enough generic J1 NCO.

The 30-day activity review set out in Rebuilding Momentum applies to these positions too. It is not an automatic removal rule: the question is whether the responsibility is actually being serviced. The XO remains responsible for ensuring the review happens, normally with the relevant Lead or owner.

That clarity is fairer to the person too. If somebody volunteered to be an Intake Instructor, UNITAF can hold them accountable for helping to run intakes. We should not quietly expect them to pick up unrelated recruitment responsibilities they never agreed to own.

Access should follow the position automatically

This is one of the practical failures the new model needs to remove. Today a person can own a responsibility while the permission to act sits further up. When that person is unavailable, progress waits.

A few simple building blocks

The model only needs a small number of structural types.

Not every useful contribution needs a formal position. Create one where UNITAF benefits from a visible recurring owner, clear accountability or attached access; otherwise people should simply be able to help without turning it into structure.

There are two kinds of Team

And four useful kinds of position

Continuity without another layer

For a small Team, continuity may simply mean a named experienced contributor can cover the essentials and has the access to do so. A larger Team may genuinely need a Deputy or second Lead. If that responsibility is real, create the position. If it is not, do not create a title just to make the chart look complete.

Most recurring positions should sit inside a Team

Some recurring technical responsibilities are currently carried by particular people without existing as formal positions. If we make responsibilities such as Discord, TeamSpeak or server administration visible, they should sit together in a logical Team rather than appear as unrelated items around UNITAF.

A Technical Team is a sensible starting point. It groups related technical responsibilities, gives the people involved a shared place to coordinate, and gives UNITAF one obvious place to see whether the technical environment is covered.

That does not mean Technical has to remain one Team forever. If Development becomes large enough to need its own Team and Lead, split it. If a technical responsibility remains small, keep it inside Technical. The size of the structure should follow the size of the need.

A standalone position should therefore be unusual. It makes sense where a genuine cross-Team responsibility has no natural standing Team, which is where Coordinators become useful.

What a Coordinator actually does

A Coordinator is useful where several Teams or people remain independently responsible for their own areas, but somebody still needs to maintain the shared picture, spot gaps and get the right people together.

The clearest example is Training. Each combat-area Training Team already has its own Chief Instructor and Instructors. Those Teams do not need another Team Lead sitting above them. With a large number of Training Teams, however, somebody still needs to notice when an area has no active instructors, when several Teams are facing the same issue, or when a Unit-wide training problem is being missed.

The Training Coordinator can own that shared picture. They can bring Chief Instructors together, keep vacancies and activity visible, identify cross-Team issues, and help start a Project where a major Training-wide change needs focused effort.

They do not appoint or remove Medical Training instructors, approve routine changes to Medical Training, or become the route every Chief Instructor must go through before acting.

A Coordinator can also sit inside a Team. A Schedule Coordinator can sit inside the Missions Team and keep the forward schedule visible without becoming the boss of every Mission Maker, GM, Field Leader or Campaign Project.

Policy is another likely cross-Team use. Most policy and guidance should stay with the Team that actually uses and maintains it. A Policy Coordinator could keep the Unit-wide picture, spot conflicts or gaps between areas, bring the right owners together, and coordinate larger changes that cross several Teams. They would not become the person who approves every policy edit.

Project Teams make temporary commitments visible

A Project Team is useful where several people need to come together around a specific outcome without creating another permanent part of the organisation.

Campaigns are a good example. UNITAF used to do this quite naturally: a small group could come together around a connected run of missions, with a Lead, Mission Makers and GMs working together to produce and deliver it. The new model can support that directly.

The Project can advertise positions through Get Involved just like a standing Team. The people appointed receive the channels, tools and permissions they need. When the campaign finishes, the Project closes and the contribution remains in their history.

The same model works for a practical short-term mission gap:

That Project has an easy test: did we actually have a Sunday mission every Sunday? At the end of the period, close it, extend it, reshape it or turn part of it into a standing responsibility if there is a good reason.

Projects can also be used for major changes rather than routine activity. Recruitment might create a Project to redesign the joining and intake system. Member Support might create one for a major change to the way membership cases or returns are handled. Community might create one for UNILYMPICS, a UNITAF Birthday event or another major initiative. Technical might create one for a site migration. The common feature is a defined outcome and an end point.

Projects can come from members too. If somebody has a sensible idea and is willing to lead it, the structure should make it easy to define the Project, advertise the positions and try it.

Authority to change the structure should sit as close to the work as the decision itself. A Team should normally be able to create, change or close positions and Projects inside its own area. If a change crosses several Teams, the people responsible should coordinate it directly. Changes to UNITAF-wide structure sit with CO/XO.

Periodic reviews can still be useful, but they should ask whether Teams, Projects and positions remain healthy rather than reappointing the entire organisation on a six-month clock.

There is no command layer

I have deliberately avoided using Function as a formal structural name. It is too easy to read something like “Operations Function” or “Training Function” and rebuild the old Commands with different labels.

We still need the organisation to be readable. Get Involved can group related Teams and Projects under simple headings such as Missions, Members, Training, Community and Technical & Systems. These headings are navigation and explanation. They have no Lead, no inherited permissions and no place in the chain.

The monthly functional leadership meeting described in the strategy can work the same way: CO/XO bring together the people who need the shared picture. It does not require another permanent layer of managers, and it does not mean every routine decision waits for that meeting.

A possible structure

The structure could therefore look something like this:

UNITAF
|-- CO
|-- XO
|
|-- MISSIONS [heading only]
|   |-- Missions Team
|   |   |-- Missions Lead
|   |   `-- Schedule Coordinator
|   |-- Loadouts Team
|   |   |-- Loadouts Lead
|   |   `-- Loadout Maintainers
|   `-- Project Teams as required
|       |-- Campaign Team
|       `-- Sunday Operations
|
|-- MEMBERS [heading only]
|   |-- Recruitment Team
|   |   |-- Recruitment Lead
|   |   |-- Recruiters
|   |   |-- Applicant Guides
|   |   `-- Intake Instructors
|   `-- Member Support Team
|       |-- Member Support Lead
|       |-- Member Administrators
|       `-- Case Handlers
|
|-- COMMUNITY [heading only]
|   |-- Community Team
|   |   |-- Community Lead
|   |   |-- Community Event Hosts
|   |   `-- Game Night Hosts
|   `-- Project Teams as required
|       |-- UNILYMPICS
|       `-- UNITAF Birthday
|
|-- TRAINING [heading only]
|   |-- Training Coordinator [cross-Team position]
|   `-- Combat-area Training Teams
|       |-- Chief Instructor
|       `-- Instructors
|
|-- TECHNICAL & SYSTEMS [heading only]
|   `-- Technical Team
|       |-- Technical Lead
|       |-- Developers
|       |-- Mod Testers
|       |-- Server Administrators
|       |-- Discord Administrators
|       `-- TeamSpeak Administrators
|
|-- POLICY & GUIDANCE [heading only]
|   `-- Policy Coordinator [cross-Team position]
|
`-- UNIT-WIDE PROJECTS as required (e.g. Reforger)
    |-- Project Lead
    `-- Project-specific positions as required

The headings such as Missions, Members, Training, Community and Technical & Systems are there to keep the structure readable. They are not another management layer and do not have their own Lead, permissions or approval role.

The headings keep the map readable without creating another rank above the Teams. Technical gives related technical responsibilities a sensible shared home. Training remains deliberately different because the combat-area Teams are already the standing Teams, so the Coordinator links them without becoming their commander.

From the current structure to one possible new one

The table below shows one way the current organisation could map into this model. Its purpose is to demonstrate that the principles can cover the work UNITAF needs, not to prescribe the structure the new leadership must adopt. Any of these Teams, names, positions or groupings can be kept, combined, renamed, split or replaced if there is a better way to meet the underlying need.

The whole structure at a glance

Contributors are not junior staff

In this model a contributor is simply a member who has taken on one or more defined responsibilities. They may hold one narrow position or several positions across several Teams.

A member could be an Intake Instructor, Medical Instructor and Loadout Maintainer at the same time without becoming a manager of any of those areas. Another member might hold Recruitment Lead and also remain an Applicant Guide because they still enjoy doing that part.

Project positions work the same way for temporary commitments. Somebody could be a standing Loadout Maintainer and also spend two months as a Campaign Mission Maker. When the campaign ends, that Project position ends without affecting the other responsibilities they still hold.

Leads carry extra accountability for the health of their Team. Coordinators carry a defined connection or shared-picture responsibility. Contributors own the positions they volunteered to perform. Project Leads own a temporary outcome.

Who is accountable to whom?

The practical point is that CO and XO need enough authority to run UNITAF without routine reference elsewhere. The Chairman remains outside the normal operating model described in this appendix.

This is also what stops Training becoming J7 and TC again under different names. The Training Coordinator has a defined responsibility across the Training Teams; the Chief Instructors still own their own Training Teams.

Coordinate first; escalate when there is a reason

Pushing decisions down does not mean somebody has to handle every difficult issue alone. The normal expectation is that people coordinate with the people around them first, and use escalation when the consequence or sensitivity genuinely calls for it.

Member Support is a good example. A straightforward membership case can be owned by the Case Handler. A difficult conduct case might be worked by two people together, or by the person in the Team who is generally regarded as the most experienced pair of hands for that kind of issue. That does not need a formal seniority score.

There will still be cases where somebody needs a clear point of senior escalation. Conduct, safeguarding, serious disputes, exceptional removals or anything carrying wider Unit consequences may need the Member Support Lead, XO or CO. The difference is that this senior route is available when it is useful, rather than sitting in front of every ordinary decision.

Where CO and XO fit

Removing PC, OC, TC and the old Central Command structure does not remove leadership. CO and XO remain responsible for whether UNITAF as a whole is healthy and moving.

They should be looking across the Unit for gaps, inactivity, duplication, difficult cross-Team issues and things which have quietly stopped working. They also provide the senior escalation route described above where an issue genuinely needs authority outside the Team.

The Chairman remains outside this day-to-day model. The CO and XO are expected to run UNITAF in their own right.

A note on rank

I have deliberately not tried to redesign rank or progression in this appendix. I do have ideas about how it might fit better, but that is a separate discussion and probably deserves a post of its own.

Nothing in this working model depends on changing it: Teams, Projects and positions should be designed around the responsibility UNITAF needs, not around the rank somebody might hold or receive.

What actually changes

At first glance, some of the Teams in this model may look very similar to the groups we already have. That is fair. In some cases, the same people may even end up doing much the same things.

The important difference is what somebody has to sign up for in order to contribute, and what we mean by a position in the first place.

Recruitment is probably the easiest example. Somebody might look at a Recruitment Team containing a Recruiter, Applicant Contact and Intake Instructor and reasonably say, "That just sounds like J1."

For some people, it might work almost exactly like J1 does today. They may enjoy the whole area, be happy to recruit people, deal with applicants and run intakes, and choose to hold all three positions. There is nothing in this model that stops them doing that.

Another member might be happy talking to applicants and helping them through the joining process, but have no interest in running an intake. Somebody else might enjoy instructing and happily run intakes without wanting to deal with applications. Both should be able to contribute properly to Recruitment without first agreeing to take responsibility for everything the Team covers.

That distinction matters more in some areas than others. A broad group works reasonably well where most of the people involved are interested in most of what it does. It works much less well when the responsibilities grouped together require different interests, skills, levels of access or amounts of time.

Technical shows the same principle from a slightly different angle. Today, related technical responsibilities are split across several groups. In this model they could sit together in one Technical Team while still remaining separate positions. Somebody might administer permissions across Discord and TeamSpeak, somebody else might manage servers, somebody might develop the website, and somebody else might test mods. They can collaborate as one Team without each of them becoming responsible for the whole technical area. Equally, somebody who wants to contribute across several of those things can hold several positions.

This is also where I think it is important to get away from the idea that every position is a new staff slot.

A Recruiter, Intake Instructor, Loadout Maintainer, Mod Tester, Permissions Administrator or Campaign Mission Maker does not need to become "staff" in the way we currently think about it. They are a member of UNITAF who has volunteered to take responsibility for something useful.

One member might hold one small position. Another might hold several. Somebody who enjoys an entire area may effectively do what a member of one of today's J groups does and hold most of the positions in that Team. Many members may choose to hold none at all.

The people closest to what we currently think of as staff would generally be the Leads, Chief Instructors, Coordinators and Project Leads. They carry the wider responsibility for the health of a Team, coordination between areas, or delivery of a particular outcome. Even then, their authority comes from the responsibility they are carrying rather than simply belonging to a staff group.

Some positions will obviously need requirements. A position involving sensitive member information may require greater trust or experience. A technical position may require particular skills. Opening contribution more widely does not mean opening every position to everybody.

It should feel much closer to a mission sign-up page: here are the things UNITAF currently needs, here are the vacancies, here is what each one involves, and here are the ones you can put yourself forward for.