Boosting Team Ownership and Accountability Using the 4DX Method

Caio Arruda at UXDX Community: Tech Leadership Essentials: From API Mastery to Team Dynamics. Video: https://youtu.be/Bwa3MUTq6d8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

When the semester goals get forgotten

[00:00:00] Caio: Hello everyone. Once again, good evening, good afternoon, good morning, depending on when you will be watching this in the future. Today I would like to share with you a bit on boosting team ownership and accountability using something that I fell in love with years ago, which is 4DX. Not a four-dimensional experience, but the Four Disciplines of Execution method. Before I explain what this is all about, let me ask you something. Imagine the following. It's the beginning of the semester. Your team is excited about the semester goals you set together. You defined where you want to go, you defined all the measures you want to work on, all the numbers you would like to achieve at the end of that specific time frame. And then you blink, something happens, and suddenly it's the end of the semester. Your team forgot about the semester goals, and now everyone is asking themselves, "What happened? We didn't work on this specific thing. Now it's the deadline, what should we do?"

[00:01:04] Have you ever lived in a situation like this? Picture yourself. Perhaps yes, perhaps no. If no, I'm sure that you know at least one person who lived something similar. Who is me. I left that in the past, and I would like to share with you how, in a recent experience, myself and the team I was part of managed to overcome such a challenge. Understanding why such a thing happens is very important; it's fundamental to overcoming it.

[00:01:39] Before answering that question: my name is Caio Arruda, as already mentioned. I'm working as a product manager for Volkswagen Digital Solutions. That's a pretty big name, so VW DS tends to be our way to go. I've been working there for a while, and I'm sharing a bit with you this experience that my team and I lived in the previous months, starting last year actually.

Urgent versus important

[00:02:02] As I mentioned, one of the very important steps to understand how to solve such a situation is to understand why it happens. That's the question guiding us. To understand this, I'm sure that most of you have already seen this specific matrix at least once. The Eisenhower decision matrix helps us to decide if we should do something, if we should delete something from our to-do list, if we should delegate, or decide, by analyzing whether something is important or urgent. Then we go through the matrix.

[00:02:39] Theoretically we should focus on distributing this, but in reality we focus on the urgent things. We are human beings; we are not as super rational as the matrix expects us to be. In the day to day, when your boss brings something to your table, when a fire is going on somewhere, when you have a massive critical bug to fix, you need to put some energy into that specific topic, and suddenly you forget about what is important, because the urgent is taking control over you.

[00:03:12] To make this more clear, a good way to separate both activities: imagine that you have the day-to-day activities, which are the activities that act upon you, and you have the goals, which you must act upon. The day-to-day activities are the urgent ones. They act on you. It's something that pops up on your table: it's an email that you received, it's a support ticket that appears. They simply appear; you don't need to do anything in your day to day for these to appear for you. The goals, on the other hand, are important, and you need to be the one acting on them. It's something that you set with your team, or with yourself, and you said, "This is important for us, we should achieve such a thing." In order for this to happen, you need to be the one putting some time into working on that activity.

[00:04:00] Understanding these two concepts will help you and the team, and whoever is watching here, to analyze and distribute your day-to-day activities on one side and your goals on the other, but at the same time make sure that in your regular routine you have enough time to work on both. Because if you go to the crowd, to your team, and ask, for instance, "What are your product goals?", people may think about it. But if you ask them specifically, "Okay, what are your personal goals?", some of them may have an answer, others may have defined something in general but now forgot about it, and some others will say, "Okay, I have this very clear in my mind."

[00:04:43] What is important is this: if you don't know where you're going, any road will take you there. If you don't know the personal goals that you are aiming to achieve, then anything that appears in front of you will do. It works the same for your teammates. If you don't define with your team where you want to be, any road will take you there. The most important thing in this is making sure that you are constantly reviewing it.

Discipline one: focus on the wildly important

[00:05:07] To make this more concrete, I would like to share with you the example of Indoor Viewer Portal, IVP as we call it. That was the internal product I was working on recently inside Volkswagen Digital Solutions. Briefly explaining what this is about: IVP facilitates the collaboration between factory managers and planners for better decision making, with always up-to-date 3D building scans. It's a Google Street View for VW factories. You could enter there, find some factories, and have some digital data that would help you take decisions better and faster.

[00:05:41] What exactly did we do? Because if I'm coming here to share with you that we overcame this challenge, we did something differently. What happened is that we implemented 4DX, the four disciplines of execution, in a way adjusted for product teams. These four disciplines go from focus on the wildly important to the cadence of accountability, and during this presentation let me explain to you each one of them, with practical tips on how we implemented them and the effects that they had on the team.

[00:06:15] The first one is focus on the wildly important goals. How does this translate into the day to day? The first thing you need to keep in mind is that your goals must be simple and focused. This means that they should not focus on how you're going to achieve something, but rather on what you are focusing on achieving. Everyone involved, meaning everyone in your team, should be able to understand it. Maybe your mom doesn't need to understand what this is about, but your boss, your team and people involved in that ecosystem should read this and say, "Okay, this is where you're pointing to, this is what you want to achieve." It's simple, it's focused, you can spread it out there, and people read it and understand.

[00:07:00] The second one is that your 100% focus must be on these objectives. They are the most important ones. If you define that something is your goal, your objective, something that you want to put some time into, it must be aligned with the expectations on top of you, and your team's time should be put into it. That's your focus. Because if you define that your goal is to achieve A, but you know that day to day people are asking you to deliver B, you need to make a decision. Either you align with everyone that A is more important than B, or you shift your goal to be more related to B, or third, you find some middle ground to work on both at the same time. But this means that whatever is written there should translate into where you're 100% focused.

[00:07:49] To make it more concrete, I will bring the example from IVP. Our team name was Bin [?], and the goals that we defined for 2023, not specifically the whole year but a specific time frame, were split into three different ones. We had something focused on the user experience, to make sure that even though this was an internal product, we had a very good user experience. The second one was related to the team. For us at Digital Solutions it's very important to have a good team dynamic, and we wanted to keep that, with some quantitative measures to ensure that we were on a good track. And the third one was about value generation: on the business side definitely, and at the same time on the user side, absolutely. These were the objectives that we defined at a higher level, and from them we ended up defining specific measurable goals.

[00:08:37] For confidentiality reasons, of course, I can't share every single one of them, but this is just for you to have an idea. It's important to check that all of them are very explicit from the beginning about what we want to achieve, and have a specific time frame as well: the end of the year, the end of the quarter, whatever that looks like. Looking at this, you may find this structure familiar, and it's no surprise to anyone that this looks pretty similar to OKRs. On the top you have the objectives, then you have the key results. I would say that the structure you're using for this doesn't matter. It can be OKRs or any other objectives and goals framework that you would like to use. What is most important, from the four disciplines of execution, is what you're doing in your day to day. The structure really doesn't matter, as long as you keep in mind that you should focus on the wildly important ones.

[00:09:32] In our specific case, we had a workshop to define this. It took no more than two or three hours. We split it over two days, one and a half hours one day and one and a half the other day, to make sure that everyone was involved and we were collecting the right inputs, in order to have a structure that everyone was happy with. But this specific structure, these specific objectives and goals, or objectives and key results, that we have here, have a problem. I will give you five seconds to look at this and guess what the problem is. Thumbs up? Maybe not. If not, five seconds are up, so let's keep going.

Discipline two: act on the lead measures

[00:10:13] The problem here is that those points are lag measures. What does lag measure mean? By this time you've probably heard about the concept of lead and lag measures, and this connects with the second discipline: you need to act on the lead measures. To make it more visual, you can imagine that the lag measures are those rocks, and the levers are your lead measures. You can influence your lead measures, and by influencing the lead measures you can predict the movement of the lag measure.

[00:10:47] To make it more specific, imagine that I want to lose weight; that's the classic example. My weight is a lag measure. I have X kilograms, and I want to have X minus 5 kilos. It takes a while for me to lose those 5 kilos. At the same time, it's easy for me to check how many times I go to the gym on a weekly basis. That's my lead measure. Let's say I go to the gym five times a week. It's easily checkable, because a week only has seven days, so I can constantly check if I'm going five out of those seven. And I know that by frequently going to the gym, this helps me to move the rock. It helps me to lose weight and helps me to achieve my goal. This is the second discipline: act on the lead measures.

[00:11:37] To bring it to a more product-related example, we can think about the following key result. Let's say we want to go from 30 to 50 NPS score by December 2024, by the end of the year. The problem with such a quantitative objective, with this key result, is that we can only know whether we achieved a 50 NPS score by December 2024 in December 2024. This means that in July maybe I already have an NPS score of 70, but if it's December and my NPS score is 40, I didn't achieve my goal. This is a clear example of a lag measure. I can only know if I achieved it by its deadline.

[00:12:26] At the same time, I can look at this and know that adoption is something I could take a look at that would help me influence and understand whether the NPS score will move in a positive way or not. Or I could use the average referrals per user: are people referring my product to other people, are they promoting my product out there? I could also take a look at user retention: do they continue using my product? Perhaps it can influence their satisfaction. And there are many other things that could help with your Net Promoter Score. All of those three, four, countless examples are lead measures. They are things you can act on on a regular basis that help you impact your major goal, your lag measure, in this case NPS. The second discipline is about acting on those lead measures. It's important to have defined your objectives, your goals, at the beginning, the ones that are important, but in your day to day you need to find the ones you can easily influence, which can help you predict movement in the big ones, the ones that you care about.

Discipline three: keep a compelling scoreboard

[00:13:34] The third discipline is keep a compelling scoreboard. This is quite interesting, because so far the first two parts are pretty easy, I would say. You define a workshop, you sit together with the team, you ask them what is important, you write it down, you go from that to the lead measures, those that you can influence in your day to day. But here it's more about your routine, and the scoreboard will help a lot with this.

[00:14:02] The first thing to keep in mind with the third discipline is to understand if you're winning or losing. We're having the Euros right now, so imagine that you're watching a football game. Knowing if you are winning or if you are losing completely changes how you will behave during that game. Imagine that you are playing as, I don't know, Portugal, Ireland, Germany, Brazil, any football team. If you're winning, you play one way. If you're losing, it changes completely. And everyone in your team must have this information, because the way they will behave depends on it.

[00:14:44] The second one is the five-second rule. Knowing if you're winning or losing is not enough; you need to know the answer within five seconds. You need to look at the scoreboard and know very quickly if you're winning or losing. Imagine you turn on the TV and your team is playing. You know immediately, looking at the corner of the TV, if your team is winning or losing, if it's 0-0, if it's 2-0, and so on. You need to come up with something where in up to five seconds everyone can understand what the situation is. You can use colors to help you with this, or whatever your imagination can help you design.

[00:15:21] In order to achieve the five-second rule, something that is fundamental to keep in mind as well is the difference between the coach's scoreboard and the players' scoreboard. If you are the coach of a team, you have a lot of data that you're constantly looking at. You look at number of passes, goal attempts, the metrics and statistics from the previous match, the data from the team you are playing against. You have a lot of information. The players, the ones in the field, only care about the score. Are they even, are they winning, losing? With the team it's the same. It doesn't matter if you put in all the velocity metrics and all the reports that you get from Jira, et cetera. For the dev team, for the designers, in the day to day, on a regular basis, you need a players' scoreboard. You can have your coach's scoreboard with every detail that you believe is relevant and will help you achieve the goal. At the same time, for the day to day, your team needs something simple where in five seconds they can get the answer.

[00:16:27] Here's one example from the team. Perhaps too many colors, I acknowledge that nowadays. But the important thing is that for us this was working. We were looking at this and just checking the percentages: "Okay, this is good, this is bad, we can work on this one, this one is not going at the right speed, let's check it out." This is one example; we were doing it as simply as in Excel, but you can come up with whatever you want, if you want something automated. In our case we were updating it manually, and how we were updating it connects with the fourth discipline.

Discipline four: create a cadence of accountability

[00:17:01] The fourth discipline is perhaps the most difficult one. Defining your goals, the wildly important ones, is easy, as I already mentioned. The lead measures from them are also easy. Designing a scoreboard is also easy; you just do it. But when it comes to the routine, the accountability routine, that's the hard part. That's the fourth discipline, and I would say the most important one: create a cadence of accountability. This needs to be part of the culture. Build a culture of accountability that seeks the achievement of the wildly important goals with the right next steps. You need to review this on a regular basis. That's the first thing everyone needs to keep in mind: okay, we are striving for this specific objective, for these specific goals.

[00:17:50] The structure for this specific meeting is pretty simple. You can go for: account, report on commitments, where each member presents what they did that was working towards the achievement of the goals; review the scoreboard; learn from the successes and the failures; and plan the next steps: "Okay, based on this, let's do this, this and that." As simple as this. The hard part is to add this to the calendar and make sure that everyone is following this structure.

[00:18:19] In our particular example, it came a lot from me as product manager. After we had the workshop to define the goals, the calendar invite was sent to everyone, and every two weeks we were sitting together for a meeting just to review the objectives' achievement, the goals' achievement. This was the accountability routine that we were having: biweekly touch points, every two weeks. At the beginning it's pretty hard, because everyone goes off immediately after the workshop, and five days or one week after the workshop you don't have that many updates to give. The machine is still gaining that momentum; you have that initial friction to get it moving.

[00:19:05] So what we did was start using the meetings at the beginning for something that was connected with the goals' achievement but was not exactly it. We were using the meeting initially for two main things: to share key dates for the teams, and to share announcements. Because I needed the team to create this routine of "every two weeks we're sitting together to talk about something that is relevant for us": the goals, the objectives, and at the same time key dates and announcements. Slowly the team started to only talk about the goals, because we ended up having more updates, more relevant updates about the goals that were worth discussing. But to achieve this I had to sit down and split the meeting between those two parts: key dates, announcements and other topics, and the goals. After one month, two meetings, everyone was purely talking about the objectives. They were purely talking about the goals.

[00:20:09] An important point at the end of this definition process for your goals is to answer four questions. You design everything, you have the event, but make sure that once you define those specific objectives and goals, you know the answers. By defining this, is the team aligned to those objectives? Will everyone work daily to ensure that these goals are achieved? If so, yes, you can pass; this is a relevant goal. Second one: is it in the structure, in the objectives and goals format, so that you can easily understand what's going on? If you have OKRs, that's your structure, that's it. If so, move ahead. Is it simple? Can everyone at all the levels of this organization understand it? If so, that's clear, let's go. And the last one: does it focus on what, not how? Don't say "we want to" and then describe how you're going to do that thing, but actually what you're looking for, what you want to achieve. Leave the hows for the strategies.

Results and learnings

[00:21:05] At this moment you may ask, "Okay, what were the results?" Because I'm sharing all those tips, those four disciplines from the amazing book The 4 Disciplines of Execution, but what were the results? Initially we had more goals, but at the end, if you paid attention to one of the slides, some of the goals were deprioritized. So at the end of our time frame we had nine goals, and out of those nine, eight were achieved and six were overachieved, so with more than 100% achievement, which was amazing for us. On average we had 161% goal achievement.

[00:21:42] And most importantly, out of all of this, the ownership within the team increased incredibly. Everyone was taking care of this. If we had something more related to user experience, one developer was responsible for driving that goal. Not necessarily was he the one crafting it or acting on it, but at the same time he was the one wearing the hat and making sure that no one in the team was forgetting about it. And this is a bonus tip: make sure that every single goal that you have, or key result if you're using OKRs, has one person to drive it, be it a developer or a designer. And if you can, cross over. If it's something more related to design, usually a designer will take the lead. If you can put the developer to work on that, the designer will still be responsible for doing it, but the developer will be accountable. He or she has the responsibility to make sure that no one forgets about it.

[00:22:43] As for the main learnings after all of this, I can tell you that we keep using this structure. We keep using it with the other teams. I ended up moving team and going to a different challenge, and the same structure is in place. The main learnings are four things. The first one is prepare yourself to be a role model. If you don't have such an accountability routine, you need to be the one pushing the team and bringing the good practices for this specific framework, for 4DX.

[00:23:11] The second one is write in the sand. Perhaps this doesn't make that much sense in English, but it does in Portuguese. You need to write something and feel okay for the water to come in and clean it, so you can adjust. Especially if you're pre go-live [?], developing an internal product, or any other product where you don't have a very clear baseline of what you want to achieve in terms of active users or conversion rate, et cetera, you need to write something that you can start working on, and as the data comes in, you update it to make it make sense.

[00:23:44] The third one is don't limit it to the product team. This is connected with our context, but don't limit it to the people working at the core of that specific product. Involve the people that you believe would make sense there, other departments, other people that have a take on it, because it's important to have the buy-in from other people. And fourth, only keep the ones you can act on. That's a clear one. Don't add something to your OKRs, or to your goals, to your objectives, that depends exclusively on someone else, where you cannot do anything to impact that specific metric.

[00:24:22] I hope that you enjoyed it. You can find more about me through this QR code. Thank you so much, and if you have any questions, feel free to jump in here, leave them in the comment section, or reach me on LinkedIn, or on Instagram, where I create content in Portuguese. If you speak Portuguese, we can also talk there. Thank you so much.

Q&A

[00:24:43] Host: That was wonderful, thank you so much, Caio. Really, really inspiring. Lots of questions, if you don't mind, so I'll jump straight into them, because we won't get to all of them. The first one goes back to point number two, act on lead measures. How can you identify what the levers are, the influencers?

[00:25:05] Caio: That's a good one. If they're more related to product (I'm just hearing myself here twice), this tends to be an easier one, I would say, because we have a lot of literature that will help you with such a thing. If you're talking about monthly active users, for instance, which is usually a metric that we tend to define, you can take a look at acquisition, you can take a look at churn, and check out the metrics related to those ones. Something that perhaps can also help with this is to design a metrics tree, or a constellation of metrics, because you will start seeing all the metrics related to each other, and by doing so it may be easier for you to find the lead measures that will impact the important ones for you.

[00:26:01] When it comes to more technical ones, or even financial ones, I always recommend having someone good by your side before the workshop. If you know that something more related to revenue or to costs will come up, it's important to have perhaps some lightning talks before, or just a one-on-one, to understand a bit more of what is going on. And on the technical side, if you have a tech lead in your team, or a more senior dev, count on him or her to help you build up this constellation of metrics, or metrics tree, whatever name you want to call it.

[00:26:34] Host: Fantastic. And can you give examples of how you and your team have worked in silos versus together? I'm assuming it's more: how have you shifted from working in silos to working together as a unit?

[00:26:51] Caio: Good one. I assume that here this is within the team, so silos as individuals, myself as product manager and the developer; I'm assuming that this is the silos. Something that is important for me in every team I'm working on: in the very first weeks, but if you didn't do it in the first week there is no problem, I invite every single person to have a chat where I ask them two questions. The first one is, "What is your story?" And the second one is, "How do you define your way of working? What is important for you, what don't you like?" If the person feels a little bit shy to share, I start by sharing myself: my story, where I'm from, where I studied, what my hobbies are, what I like to do, and so on. This helps a lot to build this connection on a personal side, which for me is the basis for whatever will come later, because once we establish this connection it's easier to count on the other person to achieve the professional objectives. That is one of the things that can happen, of course.

[00:27:52] The second one is more on the day-to-day basis. Depending on your company structure, you can take a lot of advantage of managers. If you have someone who is overseeing your career, or the career of your developer, the designer, your peer, you can have a conversation with that person to understand if he or she has some tips on how to better establish this collaboration with every single person. Because for me it's important to make sure that the collaboration is happening one-on-one, so myself and the other person, and multiply this by every single person in the team, so that the whole ecosystem as a team is working in a smooth way.

[00:28:40] Host: Love it. We don't have time for any more, and there are loads more in, but maybe online you could also touch on things like motivations. People are different, so it's hard to motivate some people; everyone has a different motivation, or personality, or drive, or rewards. So that could be another one to touch on as well. Caio, that was really, really fantastic. Thank you so much for that, and I hope to see you again soon.

[00:29:09] Caio: My pleasure. Thank you so much, everyone, and for the questions, reach out to me and hopefully I can clarify those missing ones. Thank you.