Who Owns Team Effectiveness?

Is your team effective? Is it getting more effective every week? How do you know? These are questions we’ve been asking ourselves for decades in our efforts to help software teams become great, however, I think the first question that might need to be answered is, who owns team effectiveness? That is, who is it that is primarily responsible for understanding and answering the earlier questions?

I’ve seen this take shape in many different forms on various teams. From the engineers to the CTO, varying degrees of leadership have tried to drive team effectiveness.

Engineers

This is by far the most effective position for team effectiveness initiatives to come from. Given that the engineers are responsible for the technical side of implementation and delivery it makes sense that any improvements they make in their internal working processes or tooling will have a direct impact on results. These are also, generally, the only team members who are in a position to identify and understand things that are enhancing or hindering the work. In addition, on many teams, the engineers can have a fairly direct influence on the whole team process through running iteration planning meetings, retrospectives, etc. When the engineers understand the reasoning behind the process they can have a significant impact on the flow of features.

When you have a team where effectiveness is mostly driven by the engineers the difficulty lies in:

1) Ensuring other influences participate productively with the team rather than hindering them. Examples include: hiring too quickly without considering the impact to the team; and enforcing arbitrary rules from higher levels such as, “thou shalt code review every change”.

2) Most teams only know what they’ve experienced and don’t know what else will foster improvement. At this point you are restricted by the team’s initiative and available time to research and study other techniques and practices to experiment with. Many teams fall into this trap by pressing too hard to get as much done as possible all the time.

Project Manager

When team effectiveness is mostly put into the hands of a project manager or product owner the results are usually minimal. This role is able to identify some issues hindering team effectiveness, such as external blockers, but they aren’t able to identify most of the major skills that the team may be lacking. In addition, I’ve found that these roles just don’t have the sway required to enact larger changes to allow for the training required to learn those skills.

Engineering Director / CTO

In situations where I’ve seen this level in the org chart get involved in team effectiveness it has not gone well. Usually this happens when someone decides the team isn’t getting enough done or there are constant problems with the product. In search of solutions someone will decree that everyone must TDD or that project deadlines are “drop dead” critical and must be taken seriously. These types of solutions are reached for because at this level the one doing the problem solving isn’t close enough to the work to truly understand the issues. All they know is that the team isn’t delivering the results the business thinks it wants and they’re attempting to change things they’ve heard of. Another source of these decrees are those who are searching for answers and find an article or video posted by a well known, seemingly successful, organization. They’ve spent 10 minutes reading how some other team works and then try to implement the same things on their team. Problem is, without the entire context behind the other team, it is impossible to know whether the things they’re doing are actually what has made them successful.

Who should own team effectiveness?

So, we’re back to the original question. Who should own team effectiveness? I would suggest that the ownership lies at the highest levels of the organization. Are the other team members involved? Of course. But much like a user story that has many sub tasks, there is a single owner responsible for ensuring the delivery of the final result.

The issue is in how, exactly, the director can own their teams’ effectiveness, well, effectively. This is the leadership bit. Make it known that effectiveness is important, make it known that everyone has a hand in it, and then provide the space and resources for the team to actually treat it like a priority. Ensure everyone knows that pushing out code as fast as possible is not the end goal. Bring in resources to coach and mentor all levels of the product teams so they may learn new things and apply them to their projects. Reward the enabling behavior and don’t tolerate the hindering behavior. Listen to the experienced members of the team when they have proposals. Allow them to experiment and guide them but hold them accountable for reporting results.

It’s up to you. You can try to hire the right engineers and hope they come with the perfect experience to guide a team to high performance. That’s a little like basing your retirement plan on winning the lottery. Or, you can invest in your team’s education and watch your returns compound over time.

Whichever direction you choose, don’t leave it up to chance. Make it clear who is responsible for the team’s effectiveness so there’s no confusion.