How To Create Ownership Within Your Team
In this article, I want to ram home the importance of ownership and responsibility for highly-performing development teams.
We’ve talked about trust as the foundation of accelerated digital delivery, but trust is a byproduct of a consistent, team-wide pattern: Doing what we say we’ll do.
Why it’s always our fault responsibility
Delivering on our promises shouldn’t be a controversial idea, and yet our industry suffers from an epidemic of missed deadlines, stalled projects, and ballooning budgets. Of course, none of these things are ever our fault. It’s other people that are the problem, or poor processes, or constantly changing requirements.
Sounds familiar, doesn’t it?
I missed many deadlines in my early career. Some were genuinely unavoidable, but many gave me that “bad curry” feeling deep in my belly. Could I have done something differently?
In my later role as a consultant, I’ve worked with numerous struggling development teams. Many are watching helplessly as deadlines whizz by, and often teams stall, often descending into blame and name-calling. “I did my best,” people say, “but I’m not responsible for what happened before/after it left my hands.”
We’ve all heard and we’ve all done it, but here’s the thing: I never hear that from highly-functioning teams or people. They think about the work in a different way.
This entire series is about accelerating delivery, but none of the principles and tactical advice matter unless people take real ownership of the work.
So let’s take five minutes and talk about how you and I can take responsibility to help them do it.
There is no “I” in accelerated digital delivery (uh, what?)
Let’s start with the obvious. In digital development, we are generally paid to do something specific. We’re a team leader, a product owner, a designer, a developer, a UX writer, or whatever. We are valued because of our specialism, our experience, and our ability to execute in that field.
But wait. Our specialism is really only valued in relation to the wider team. In the long run, no one is paid for a specific skill, they are paid because they were part of a group—a team—that delivered something valuable.
No delivery. No jobs.
Common sense? Of course, but then again, I’ve met plenty of otherwise talented people who seem happy to wash their hands of everything outside their area. “I’m not a designer,” they say, “how can I be responsible for good design?”
To be clear, I don’t believe that developers should “do” design any more than designers should “do” development, but 20 years of experience have shown me that caring about the work beyond your silo is highly correlated with excellence.
So how does that “caring” manifest in the real world?
Who’s the real client?
As I’ve said before, the handover is a critical focus of accelerated digital delivery. When we do it well, work flows smoothly through the system, when we don’t, projects stall or go backwards.
To illustrate this, let’s imagine that a “siloed” designer “throws” some wireframes over the wall to development without proper support or documentation. A good developer may be able to do the work, but it won’t be an efficient, accelerated workflow. At best there will be bitty back-and-forth conversations, at worst there will be misunderstandings, rework, and stress.
By contrast, imagine a designer who sees the developer as their client. This designer isn’t just doing a design, they are taking ownership and making sure that their “client” has everything they need to pick up the project and run with it.
Depending on the processes in place, this might include:
A short handover meeting (that the designer arranges and leads).
Designs that are signed off by the client (to minimise future changes).
Wireframes prepared for both desktop and mobile views.
Copy that’s finalized in collaboration with a content writer.
Clear documentation and videos explaining the work (and the thinking behind it).
A follow-up chat to address any issues.
This is a concrete example of “caring beyond your silo”, and works all the way down the line. If the developer is handing the project over to Testing, they should see Testing as their client.
Teams that work this way function smoothly by default. There are always issues to resolve, but they are far fewer because no one is “done” until the next person in line has everything they need.
Some people (diamonds) naturally work this way. They make it their business to understand what the next person needs and deliver it. Others—perhaps the majority—need help to make this step and understand what “done” looks like for them.
And that’s where we (and our processes) come in.
Defining what “done” looks like
If we want people to take ownership seriously, we need to define what that means. In other words, what does “done” look like for each role within the project?
Building on the ideas above, this can be achieved with:
Clarity in roles and responsibilities
Every team member must understand their role in the delivery process, who they are handing off to, and what is required before they can hand it over.Checklists
These requirements are codified in a checklist that must be completed before the project moves on. (Checklists remain the most undervalued assets when it comes to delivering our work with speed and precision.)Structured handovers
The baseline for this—believe it or not—is simply that a formal handover actually happens. I’ve been parachuted into teams where there was no handover process, and it was all too obvious in their performance. If you aren’t doing it already, start. Make it a formal process and improve as you go.
… which leads us to another critical aspect of ownership.
There is no “best” way
I’ve been working in digital development for decades, but I’m well past believing that I have the “best” production process. All I can claim is that I have the best so far for my particular teams and their needs.
We don’t carve our processes in stone and demand that others follow them unthinkingly, we write them in digital ink and challenge others to improve them.
Better ideas are everywhere, especially when we break out of our silos and look at what’s working elsewhere. We didn’t always ask our designers to create videos of their user journeys, but an idea sparked by YouTube demos has become a valuable part of our handover process. I can’t remember exactly who suggested it, but it was just as likely to have been a developer or product owner as the designer themselves.
Ownership isn’t just about meeting deadlines and doing good handovers—it’s about continually improving the outcomes for the team and business.
At least, that’s what I hope for you and your team. Unfortunately, some people struggle to care about what happens outside their silo. What about them?
Square pegs versus round holes
We’re all familiar with the square pegs of the development world. They may be brilliant—although often less so than they believe—but they can’t (or won’t) get with the program.
Whether in nature or digital development, lone wolves rarely survive.
Whether in nature or digital development, lone wolves rarely survive.
Our job, of course, is to help them as much as we can. Mentoring. Clear processes. Warnings when appropriate. If that works, great. If not, we need to consider more radical action.
Great teams are built of great people, great people take ownership of the whole as well as the specific.
It’s often said that one brilliant developer is worth ten mediocre ones, but honestly, I’ve seen it go either way. Brilliance can sometimes struggle to see that there might be a better way, or that someone else might have a useful idea.
I have and want brilliant people in my team, but ownership and teamwork are a baseline if you want to build an accelerated digital delivery practice.
If someone can’t work that way, they are going to be better and happier somewhere else. And so will we.
Actionable steps that strengthen a culture of ownership
Before we finish, let’s just review the actionable steps I take when I’m working with a team that’s struggling with ownership. Here’s a roadmap to turn things around:
Name the person with overall responsibility for the final project outcome
This will be your project lead… the specific person who aligns the team and oversees the steps below.Define the process
Break your delivery pipeline into clear stages (e.g., Design → Design Handover → Development etc).Assign responsibility for each stage
Make it clear who owns each step in the process. Define at what point ownership transitions.Create explicit checklists
Include detailed criteria for what “done” looks like at each stage. Automate these checklists where possible—for example, adding them to your cards on a Trello board.Set Work-in-Progress (WIP) limits
Avoid overburdening team members by limiting how much work can be in progress at once.Mentor and monitor
Use the process itself as a tool to mentor team members, showing them how to improve their delivery approach.
Start with yourself
There’s one last thing to talk about, and it’s our responsibility.
If you paused on step 4 above, setting Work-In-Progress limits, you’ll have noticed that it was new to the article. I’d be shirking my responsibility to you if I didn’t touch on that in greater detail.
While it’s lovely to get caught up in fantasies of everyone caring about everyone else and pulling in the same direction, it’s useful to remember that we are all human.
It’s hard to care about anyone else when we are buried under work and stress.
The biggest threat to ownership—and accelerated delivery in general—is too much work in progress. Lean manufacturing has a word for this, Muri, that’s usually translated as “overburden”. Put simply, when there’s too much to do, shortcuts get taken, critical steps get missed, and systems fall apart.
If we want our teams to take ownership seriously, we need to give them the time and space to do it. That’s easy to type in an article of course, but is infinitely harder to do.
What I can confirm, while nursing the scars of long experience, is that the universe will happily reinforce whatever path you choose (or are forced) to take. Too much work will lead to stress, mistakes, and siloed-behaviour as people seek to protect themselves. Rework and missed deadlines will mean more work but less progress.
By contrast, doing less work promotes ownership, teamwork, and adherence to processes that will accelerate your digital delivery.
If we want others to take wider ownership for the results of the team and business, it’s up to us to take the first step.
