Ownership and High Performing Teams
Imagine you’re making a change to a codebase you don’t like. Testing is difficult and you don’t have a good understanding of how all the parts of the system fit together. It’s tempting to just do a bit of cursory testing, deploy it to production and keep your fingers crossed. This is not a pleasant situation to be in, and will inevitably lead to production incidents, sad developers and cross managers.
As a manager, if you encounter a situation like this you’ve got a choice to make about how to fix it. Instinctively you might want to put more processes in place around deployment and testing. Maybe kick off a project to refactor the code base and make testing easier.
Maybe you can reduce failed deployments, but at what cost? Slower development caused by extra bureaucracy and more policies to follow is going increase friction, delay releases and eventually lead to an unhappier team.
The underlying problem is that the team feels disconnected from their software. They might own it according to your org chart, but they don’t feel ownership of it. This lack of ownership can manifest itself in many ways, but principally it results in a “good enough” attitude and a lack of interest in the negative effects that a deployment might cause, or future issues caused by the code change.
So, rather than adding more policies how do you encourage the team to feel more like the owners of the software they are responsible for? There’s no one answer to this, but you can start by looking at how detailed their future technical plans for the software are. A team that feels a high degree of ownership will likely know exactly what technical changes they want to make over the coming months or years. A team that doesn’t will be content with just tinkering around the edges, or maybe they have some plans but talk about them in a jokey, “we’ll never get around to this” kind of way.
If the team doesn’t know what they want to do with their software then you as a leader can help by taking them through a process of working out what changes they do want to make. These need to be practical and realistic, this is no time for pie-in-the-sky “let’s just start from scratch” ideas. If the team is already in difficultly then you need to start small, and incrementally make improvements.
Begin by assessing where the biggest pain points are. Once you’ve identified the area come up with some easy wins, and create time for the team to work on them. By starting small and getting something done you can help the team feel a sense of achievement. It won’t happen overnight, but once the team feels like they are making progress they will start to feel a sense of ownership.
Another aspect of feeling ownership is a connection to your clients. How easy this depends strongly on what type of business you’re in, but it’s worth fostering this connection if you can. Maybe people can spend a day shadowing a client? If you run user experience research then developers sitting in on a few sessions will help build that connection. Developers don’t need to build as complete a picture as a product manager or UX researcher needs to, but if you’re building something that it’s not possible to dog food then gaining some first-hand connection with a subset of users will help people to think about them in less abstract terms.
To try and build an understanding of your clients you might be able to get one to attend a town hall or other meeting and talk about what impact your changes have had on them, what their priorities are, or a recent success that your software has enabled. Hearing directly from a client, and putting a face and a voice to them is hard to beat as a way to build empathy and understanding of your users.
If you’ve been successful you should start to notice a change in the behaviour of the team. They might be more proactive about suggesting improvement projects and be keener to iteratively improve on what will still be a “bad” codebase. Hopefully, you’ll notice a keenness to resolve issues more quickly, and more attention to detail when preparing and executing changes in production. If a company’s users become the team’s users then they will feel a personal responsibility for their experience, and for the success of your product that can only be a good thing.
Comments