Give Teams Ownership of Delivery

It’s a poorly kept secret that increasing levels of responsibility, particularly with knowledge workers, often correlates to an increase in performance.

We strive to have the team dedicated to a software product responsible and accountable for the end-to-end delivery: from initial requirements capture, right through to launching and supporting the application.

In devolving responsibility to teams, there are a number of areas worth consideration, the first of which is what skills you’ll need on the team to best achieve this.

Shaping the Team

When pulling together a new team, it’s important to consider the blend of skills that you need. We tend to shy away from specialist roles, such as database administrators or dedicated testers, though we do see value in ensuring a healthy mix of experience levels on a team.

We package desirable behaviours in to documented traits, describing a series of attributes people can work towards. One of these traits is delivery, which encompasses process improvements, understanding commercial objectives, and ensuring customer needs are met. Other organisations may choose to recognise related attributes in other ways, such as through team lead or similar titles. Whatever your flavour, it’s sensible to consider having an experienced pair of hands in the team with the nous to nudge things in the right direction.

On the flipside, it’s wise to be wary of conflict in teams where everyone is chasing the same personal objective. If you have multiple people on the team who are used to playing a delivery lead role, the team may not easily settle. Having a mix of people skilled in a number of different areas who can coach and upskill other members in their various strengths is a positive place to be.

Once you’re confident you have the right mix of people together, the next step is to consider how to better empower them.

Empowering the Team

Successful team empowerment typically comes from blending expectations, responsibility, and accountability. Without these forces working in balance, you’re likely headed for frustration.

It’s firstly important to instil a sense of responsibility that everything from understanding what the customer needs, right through to launching the thing in production is down to the team.

Depending on the culture in your team and wider organisation, you may need to do some work to set expectations on what you expect the team to be achieving. This should shy away from task-level goals, but be a higher level goal – perhaps something along the lines of: increasing customer happiness through delivering valuable, working software regularly.

Once you’ve done this, your next step is to not interfere. For many managers, this part is particularly tricky.

Your only responsibility from here on in should be to hold the team to account for meeting their commitments and for delivering to the higher-level expectations that you’ve agreed. We cover accountability in a little more detail later.

An empowered team should be focusing its efforts on problems, not on implementing perceived solutions provided by an external architect or other higher being.

Task Teams with Problems, not Solutions

Ensure that the team are being engaged at the correct level. If you’re looking to encourage strategic, rather than just tactical skills, don’t ask the team to deliver a pre-defined solution to the problem.

Instead, ensure the team are empowered with, and over time, are actively seeking out an understanding of the commercial goals behind each and every feature.

Have the team take responsibility for identifying and then delivering solutions to these commercial problems, rather than executing against a pre-baked task list. This ownership of the fuller problem should help accelerate a feeling of empowerment.

When relinquishing any kind of control, or when trying to increase the empowerment of others, it’s highly likely that many things will not be done as you would have done so yourself, and it’s important to quickly come to terms with this.

Be Prepared to Accept Mistakes

If you were managing a task-list for a team and having them execute it, likely you’re going to be getting your own way a lot of the time. When a team moves to working toward higher order goals, this is likely to not be the case.

It’s important to be prepared to accept that mistakes will be made. Wherever possible, you’ll need to allow the team the freedom to do this, even where there’s a cost involved, and where you believe you can clearly foresee the problem.

If you’re overly keen to jump back in and provide input, you’ll too easily undo the work involved in imparting a true sense of responsibility and empowerment, and before you know it, members of the team will be deferring decision making outside of the team.

You should try to see your role as preventing the team from jumping off a cliff, but not much more. Opening yourself to the right conversations can help a seasoned leader more easily accept this transfer of decision making.

This topic is discussed more fully in our article on Accepting Mistakes.

Ensure You’re Being Asked the Right Questions

Particularly with newly empowered teams, you should make yourself open to discussing strategies with the team. However, you should be careful to avoid allowing the team to too easily devolve lower-level decision making your way.

A quick and easy technique is when asked a question, first ask the other person what they think the best course of action is. Even if you’d consider doing things differently, unless you believe what’s being proposed is significantly detrimental, let the team run with it without providing input.

You should move to a mindset of providing advice from outside of the team. One easy tactic to accelerate this shift is to ensure the day-to-day point of contact is inside the team.

Point of Contact

In most engineering teams, it’s natural for there to be a primary point of contact for the Product Owner, Customer, or similar role. It’s of paramount importance that this primary day-to-day contact be someone in the team, rather than having communication fed through intermediaries, particularly those more senior within the organisation, and those not full-time committed to the engagement.

Having communication come from a conduit outside the team disempowers the team from building direct relationships with those commissioning the software, and it hinders open conversations that help engineers better understand the true commercial objectives and pressures.

The point of contact is unquestionably an important role within the team, particularly if you provide consultancy-like services to other organisations. You should be conscious to invest in upskilling, nurturing, and providing regular support to those new to this role.

Upskilling the Team

There are a number of areas in which you could consider upskilling the team, particularly if increased responsibility and empowerment is new for them.

Delivery Mindset

If someone has spent much of their time being assigned tasks, and then executing them, it’s likely some work is needed to coach more of a delivery mindset.

This involves thinking at a higher level about how to best move from a stated problem, to working, released software. Likely this will entail higher level of communication with customers, helping shape priorities, identifying and articulating solutions, and ensuring there’s an appropriate framework in place to facilitate fast delivery and fast feedback.

Customer Service

Many organisations make the mistake of hiding their engineers away from the customer, instead relying on a middleman to collate requirements, showcase the software, and generally keep the customer happy.

You should encourage a solutions-focused culture, where engineers see their role as facilitating the customer, be it an internal or external stakeholder, in achieving their commercial goals. Ensuring regular and open communication, and regular showcasing of the software can go a long way.

In many organisations, if software engineers have historically been engaged later in the process, after pre-conceived solutions have been devised, there can be a pervasive ‘no culture’, where engineers will not be used to engaging in the process of helping to solve higher order problems. In these cases, additional effort will be required to shift the culture to one of more open, helpful dialogue.

Understanding the Problem

If your team have historically been focused more on solving task-based problems, coaching is likely to be necessary to help in how to better gain an understanding of the higher level problem to be solved. Consider encouraging communication with the end user, support in navigating organisations to reach the true stakeholders, and relentless questioning of why requirements are important.

Commercial Understanding

In some organisations, you may observe engineers shielded or otherwise isolated from the commercial drivers behind software deliveries. In the worst cases, which are thankfully a little less common nowadays, engineers can be tasked with building libraries with specific interfaces, with no understanding of what’s going to be interacting with this interface, even at the software level, let alone the higher-level commercial goal it’s designed to solve.

Instead, we believe people perform best when they understand the domain in which they’re working, and when they understand the commercial goals that the software is supposed to solve. Empowered with this understanding, coupled with their software engineering know-how, engineers can often propose easier and cheaper solutions to achieve the same aim.

To ascend a team to true autonomy, healthy mechanisms need to be in place to keep accountability levels high. Without them, the temptation for managers to interfere often become too great.

Keeping Teams Accountable

An important, and sometimes overlooked trait when increasing ownership within teams is putting in place appropriate mechanisms to hold the team to account for unacceptable deliveries.

As a consequence of empowering the team with higher level responsibilities, you’ll often see teams naturally holding themselves to higher account. This is the ideal culture to be building.

That said, it’s likely that, given enough iterations, even amongst teams who have plenty of experience with higher levels of empowerment, there will be occasions where less desirable performance will be observed and should be surfaced.

To avoid disempowering the team, it is suggested to give higher level feedback, and to allow the time to digest and work out solutions without taking involvement. Describe the situation that you observed as undesirable, and explain the reasons you feel this way.

You should use this mechanism sparingly, as its effectiveness is likely to be reduced the more you lean on it. If you find it necessary to follow this recourse every week or so, it’s likely you’ve got larger root problems that need to be addressed, or that you’re not truly comfortable in allowing the team to be fully empowered.

This feedback should be given at an arms length, avoiding the temptation to roll your sleeves up and become a part-time team lead.

Supporting Teams from the Outside

While a large part of encouraging ownership is allowing teams to operate more autonomously, it’s important to also offer an appropriate level of support.

You should keep front of mind that you need to provide this support from outside of the team to avoid undermining the team’s autonomy.

Ideally, you should encourage a culture where a team will proactively ask for help or input when they feel they need it. Offering up too much assistance can have an undermining influence, even when well intended.

You should consciously aim to always ask the other person, or the team, how they think to best handle the situation before offering up your own solution, further nurturing independent thinking.

The nature of the team and the individual will dictate the best way to provide support. For some people, carving out a small dedicated amount of time each week may provide a good forum for supporting, for others, you may find you naturally have more informal conversations throughout the day.

Next steps

Depending on where your teams are currently at on the spectrum of empowerment dictates how much effort will be needed to give teams full ownership of their deliveries. As with rolling out any organisational change, we’d recommend to introduce change progressively and subtly, beginning by exhibiting and coaching the behaviours yourself.

If you’re currently integral to the delivery of software projects, particularly in cases where you’re not truly a part of the full-time team, you should consciously look for opportunities where you can transfer these responsibilities to the team.

With teams taking on more autonomy, not only are you likely to reap the benefits of people feeling more responsible, more valued, and more productive, you’re also building a foundation that allows you to scale engineering efforts across many autonomous teams.

About the Author