Engineering, Ops and Business on the same side

At BMAT, three groups want each product to work. Engineering builds it, Operations runs it for customers every day, and Business sells it and answers for it. They're meant to be one team, but it's easy for each to start seeing the others as the problem.

Engineering hears a constant stream of requests that seem to change every week. Operations sees bugs that sit for months while the team builds something new. Business sees deadlines slip and can't tell why.

In my experience they want the same thing, and each of them sees a different part of it.

Where the friction comes from

The friction comes from a few ordinary things:

• Different calendars. Engineering plans in sprints, Operations in daily and monthly deadlines, Business in quarters, so a request that's urgent on one calendar can be invisible on another.
• Different words. Every domain has its own vocabulary, and music rights has more acronyms than most. When Operations describes a problem in its terms and Engineering hears it in theirs, both leave the conversation sure they agreed, and later find they didn't.
• Too many channels. Requests arrive by Slack, by email and in the corridor. Nobody sees all of them, so the most recent one feels the most important.

None of these need a reorganisation to fix. These are the habits that have helped my teams.

One way to ask for work

The first habit is the same one that helps a firefighting team, a single way in. With the Reportal & CUED team, which I managed before Rights & Royalties, I wrote a short page on how to open a ticket to the team, and made it the only way work came in. Every request became a ticket from the same template. It asked for several things, but two of them added the most value:

• Why is it needed? Knowing the reason lets Engineering suggest a simpler way to get the same result, and lets everyone weigh the request against the rest of the backlog. A request with no clear why is usually not ready to be worked on.
• Acceptance criteria. Writing down what "done" looks like means the person asking and the engineer building it agree on the result before work starts.

Alongside it, we agreed which channel is for what. Jira holds the work and every decision about it. Slack is for quick questions, and anything that turns into work moves to a ticket. Email is for people outside the company. It sounds small, but it means anyone can see every open request in one place, and nothing important lives only in someone's inbox.

Set priorities together

Once every request is in one place, the next step is deciding together what goes first. Engineering shouldn't guess what matters most to customers, and Operations and Business shouldn't guess what's cheap or expensive to build.

One of the first things I introduced when I started with Rights & Royalties was a shared prioritisation meeting before each sprint, with Engineering, Operations and Business all on the call. In that one meeting we decide together what goes into the next sprint and what can wait. When the estimates don't fit, scope gets cut there, with everyone who cares about it present.

It also means nobody hears second-hand that their request was cut. They were there when it happened, and they heard what it was cut for.

Plan the quarter together

A sprint is too short a horizon for some work. A new report format, a change a customer has to prepare for, or a feature that needs research first can't simply appear in next sprint's candidate list.

So we also build a quarterly plan together. It helps Operations and Business plan ahead, and it gives everyone time to organise the discovery and decisions that have to be finished before the tickets go into a sprint. By the time a piece of work reaches the prioritisation meeting, the open questions have been answered, and the sprint isn't where they get discovered.

Writing down the domain

A lot of friction between teams is simply translation. A few things make it smaller:

• Write down the acronyms. Newcomers use the list most, but it also settles arguments about what a term actually means.
• Write down the business rules. Which programmes go into a report, which metadata a work needs before it counts as complete, what happens when two sources disagree. When those rules live only in Operations' heads, Engineering builds the wrong thing in good faith.
• Invite each other in. Engineers learn a lot from watching Operations work through a real case. Operations and Business learn a lot from a short demo of why a change that looks small can take a whole sprint.

Let the people who asked check the work

Operations and Business should see what was built for them before it ships.

On Reportal & CUED, we worked in two-week sprints with a fixed release rhythm. Changes went to staging on Monday, Operations and Business validated them on Tuesday, and they went to production on Wednesday. We added a "Ready to deploy" status in Jira, so everyone could see what had passed validation and was waiting to go out.

We also agreed that a ticket is only done once the person who asked for it has checked it on staging, so Operations and Business sign off the work they asked for.

Retrospectives with everyone in the room

Many teams run retrospectives for engineers only. I prefer to have Operations and QA in the room too, because they feel the friction between teams first.

With the Reportal & CUED team, I ran a retrospective every two weeks for about two and a half years, for a group of 15 to 20 people across Engineering, Operations and QA. We used the 4Ls format: what we Loved, Longed for, Loathed and Learned, and every retro ended with action points and owners. Some of the most useful changes came straight from those sessions: the "Ready to deploy" status, the rule for when a blocker can enter a running sprint, and the guidelines for which channel to use for what. They came from people in Operations, QA and Engineering saying what was getting in their way.

In a recent retrospective with the DSP teams, two notes came in that could have been written by the same person. One, from Operations, said they couldn't get to any tickets other than emergency deliveries. The other, from Engineering, said there was no capacity for tickets that weren't blocking a delivery. Other notes in the same retro said automation work kept getting pushed back behind urgent deliveries. Read side by side, they described the same problem: urgent work was taking up the whole sprint, including the time for the improvements that would make that work less urgent. We discussed it as one problem, with both teams in the room.

Where to start

You don't need all of this at once. Pick the one that hurts most. If requests get lost, start with one way to ask for work. If people feel ignored, start with deciding priorities together.