Communication for team leaders - Ownership

And we’ve come to the last post in the series of “communication for team leaders.” This one is about ownership.

You can find the other posts here.

• https://frederickvanbrabant.com/blog/2024-10-11-communication-for-team-leaders-context/
• https://frederickvanbrabant.com/blog/2024-10-31-communication-for-team-leaders-trust/

And these posts are based on a part of my talk, “I just became a team lead, now what” (https://www.youtube.com/watch?v=oWtSbTded0o).

The red line in these posts

A smart reader like you has probably found the pattern in these posts; they all have a focus on keeping people engaged and motivated. This is a very important part of leadership. If you can’t motivate your people to stand behind their work, you will never get good results. At best you will get passable work; at worst you will get an open vacancy.

I strongly believe that ownership is one of the main pillars of keeping people engaged; you can, however, only do this if there is mutual trust [1].

Giving ownership to people seems very actionable and easy to do, but I do think there are some things to keep in mind and maybe think about first. This goes a bit further than “You are now the application owner of application x.”.

What is and what isn’t ownership

Ownership has two big parts:

• You can decide what happens to the thing you own.
• You are responsible for the thing you own.

This is where I often see inconsistencies. A lot of people in an organization only get the second part. You are tasked with keeping the application/process/project [2] running and operational but can’t decide where it goes.

In that case, you are not the owner; you are the maintainer. The person that owns the bigger strategy where your application fits in, would be the actual owner of your application.

Now this is obviously not a black-and-white thing. You can’t just have a bunch of fiefdoms in your organization. Little pockets of applications that all just do their own thing. That would result in an unmaintanable mess. It is, however, important that there is a direct communication line between the layers of strategy and operation. Ideally, everyone is aligned on where the organization is going and the path that brings it there.

It was important to start off with that outline before we can dive into how we can give ownership so you know what you are actually giving [3].

A bit less theoretical

As discussed in the previous post, we are now deciding what to do ourselves and what to pass on to someone else. Say, for example, you have to figure out what testing framework you want to use for your custom applications. As a team lead, you probably have an opinion on that call, but this can also be a nice example to show how ownership could work.

Say you ask 3 team members to do a deep dive into the testing frameworks available for your chosen programming language and have a follow-up meeting where you decide what to use. You tell them to keep an open mind; don’t just go with the one that comes with the framework they use or the one they used in the past.

You give them a week or two and have a follow-up meeting. If you are lucky, they are now well read into the pros and cons of the testing frameworks available, learned why some frameworks approach some things in a different way, and talked between them about it at the coffee counter about these aspects. If you are even more lucky, they had some discussions about their preferences and eventually came to a mutual understanding to present their findings to you.

This is amazing; let’s see what we’ve gained here:

• They learned more about testing.
• They shared their past experiences and learned from each other.
• They might now be more passionate about testing and could become the ambassadors of good testing practices in the team.
• You have smart people working, so you now get a concise explanation of the testing landscape out there with the pros and cons.

That was the happy path

Now what are you going to do when the team comes back with a decision you don’t like? Say they come back from that exercise and are all hyped about a testing framework that you really don’t like, or even worse, they didn’t like the one you from the get-go actually wanted to use.

That’s why it was important to start with the outline of what is and what isn’t ownership. You now got yourself in a corner and at the tricky part of tasks like this. Personally, I take two different approaches here.

If it’s an operational change that is fairly contained, like the testing framework example, I would at that meeting have a good conversation with the team and bring arguments about why you would go with X where they would like to go with Y. But if you can’t reach an objective better option, I’d probably lean more toward following the team over making the call yourself. You run the risk of getting the team into “What was the point of all that work?" mode.

If it’s a change that has strategic impact that you have the feeling will come back in your face in a few months, you need to make the call yourself. That is, with a big caveat that you would have given the context of the exercise in the beginning. It wouldn’t have been “How can we solve X?” It would rather be “What would be some options for solving X?”. One implies that they bring a solution; the other asks for some options where you can give a call on.

What about the even worse path?

The worst outcome of our fictional exercise, and one that sadly happens often, is apathy. The people that you ask to research something come to the end presentation with some very high-level information or nothing at all.

In this case, this is also very valuable information. You’ll have to do the research yourself, but at the same time you have learned that there are some issues in the team. Are they demotivated about work in general? Do they have too much on their plate? Do they just assume their voices don’t matter and would get overruled anyway? Or maybe they just aren’t very motivated in researching topics.

This doesn’t mean you have to stop giving people ownership over applications/processes/projects … You just have to find a route to make it so people take it more seriously.

[1] https://frederickvanbrabant.com/blog/2024-10-31-communication-for-team-leaders-trust/

[2] For the sake of brevity I’m just going to call this application, but please note that this goes way further than just applications. Think application/processes/projects/teams/capabilities …

[3] let’s call it context