Onboard a team with one workflow.

Watch a team get onboarded.

Wayfinder is an internal developer platform that turns onboarding into one workflow. This is the flow in the product. A request arrives, a workflow runs and the new team gets an AWS account and a workspace with its environments. Then the team deploys its first application.

What you will see in the video

1. Setting up your integrations in your tenant.
2. Using Wayfinder to onboard a team with workflows.
3. Creating an application.
4. Deploying an application.

What onboarding a team involves

When a new team starts, someone has to create their cloud account, set up their workspace and environments, give the team lead the access they need without handing over more than they should and connect the tools the team works in. None of it is hard on its own. It just takes time and it usually waits in the queue of whoever on the platform team is free that week, so a team that is ready to build ends up waiting.

Think of a new starter arriving on their first morning. They are keen and ready to work, but the laptop has not been ordered, nobody has set up their login and nobody is sure who signs off their access. That is what a new engineering team feels like when it waits on the platform team.

By the time a team is properly set up there are five things in place: a cloud account, a workspace with environments, access for the right people, their tools connected and monitoring so they can see what they have built. Most organisations do this by hand from a runbook and each step waits on a different person or a different ticket. That is a big part of why 78% of engineering teams wait a day or more for help from the platform team.i

Why it takes so long by hand

The steps themselves are simple but the waiting is not, because the account request sits in one queue, the access request sits in another and the monitoring set-up sits in a third.

Nobody sees the whole sequence, so nobody can tell you afterwards exactly what was done and in what order. If an auditor asked who has access to what and since when, how long would it take you to find out?

It is a bit like building a house where the electrician, the plumber and the plasterer each take their own bookings and nobody holds the plan. Every one of them does a good job but the house still takes months.

What one workflow does

Triggered by the platform team for a new team called payments. Every task runs as a service account called team-onboard, so the run can never do more than it was given.

What the team finds on day one

When the run finishes the team opens Wayfinder and finds everything waiting. The cloud account sits in the right organisational unit with guardrails already applied. The workspace has its environments, with networking and DNS attached. The team signs in through your identity provider with roles for each environment and no standing admin access. Their GitHub team, repository, Jira project and Slack channel are connected and a monitoring dashboard is ready. The catalogue shows only the plans the team may use, pinned to versions, so the first deployment starts from building blocks you have already approved.

Nothing is deployed yet so the workspace starts empty, which is exactly what you want, because the team’s first job is to create an application and not to wait for somebody to set up the place to put it.

How a workflow turns it into self-service team onboarding

A workflow is a trigger, a graph of tasks and a record. The trigger is whatever starts the work, such as a webhook, a resource event, a schedule or a person. The tasks are the steps and they can call a web API, run an agent, wait for an approval, raise a pull request or check a condition, with the output of one task feeding the next. From the command line it is one command: wf invoke team-onboard.

For onboarding, the trigger is a request from a form, a wiki page or a service desk tool and the six tasks above do the rest.

Start it from anywhere

A workflow does not mind how it starts. It can also run on a schedule or by hand from the command line. In the video a webhook receives the request and starts the run, so nobody on the platform team has to be there for it to begin.

Why it is safe to automate

The obvious worry with anything this fast is control and it is a fair one. The workflow runs as its own service account rather than as a person and Wayfinder checks permissions when the workflow is defined, so it can never be given more than the person who wrote it has. Where you want a human in the loop you can put an approval gate anywhere in the graph and the run waits until the named people say yes.

Every action is logged and every run can be replayed, so when somebody asks who has access to what you can open the record and show them. It is the difference between telling an auditor you think it is fine and handing them the evidence.

This gives a new team least-privilege access and the workflow itself runs with least privilege too.

What you get for the next team

Run the same workflow again with a different team name and the set-up is identical every time, with the record to prove it. The workflow is versioned, so when the platform team improves a step, such as a tighter access role or a better monitoring template, the next team onboarded gets the improvement. Every run is kept, so you can open any past onboarding, read what each task returned and replay it.

The speed gets the attention but the consistency matters more. A team that used to wait a day or more is ready to build in minutes and team one and team twenty are set up the same way because a versioned workflow does the work and not somebody working from memory. Because any connected tool can be a task, the workflow also grows with the way you work, so if you add a security scan or a cost tag the next team gets it automatically.

Questions