From Average to Exceptional: The Journey of One Development Team to Increase Productivity and Business Outcomes

From Average to Exceptional: The Journey of One Development Team to Increase Productivity and Business Outcome. Photo by Tobias Mrzyk on Unsplash

It might not be a surprise to you that engineers have always been in high demand in our industry. Highly skilled software developers are scarce. This is a reflection of the challenges of the past, present and future of software engineering colliding. Every year, more efficient, more user-friendly, more ingenious software is needed to run our worldwide economy. As a result, software is becoming more complex as well. And as threatening as ChatGPT may seem, it will most certainly not replace the innovation, collaboration, creativity, and the think-on-your-toes problem-solving of most human programmers for the next decade. In contrast, I believe that we need even more highly skilled (human!) software engineers to keep up with the speed of innovation and technology.

However, our industry has some big challenges to face. Only 16.2% of all IT projects are deemed successful as reported by the latest report by The Standish Group. Every year, we lose more than 300 billion dollars because of developer inefficiencies. Based on research, a software developer works, on average, seventeen hours a week on maintenance tasks. The latest State of DevOps report (2022) showed a drop in high-performing teams and an increase in low-performing teams compared to 2021. The researchers hypothesized that this could be due to less effective communication because of the pandemic but time will tell if that is indeed the root cause. 

Even if organizations have adopted Agile or DevOps, the biggest problem of all remains: More than 50 percent of all the projects or features developed by software developers aren’t delivering the expected business value. Rather than pandemic-related inefficiencies, I suspect something else is at play here that is holding us back. It is the ultimate soft skill that if we could master, could change everything. I am talking about behavior change. In my years of working with software development teams to achieve their goals through the use of Lean OKRs, I kept circling back to behavior changes again and again. I am sure you’re all aware of that saying: “Insanity is doing the same thing over and over and expecting different results”? Well, I postulate that behavior change is the remedy to revive our projects and set teams up to face the demanding future of lightening-speed innovation.

New behavior = new results 

Moving the Needle with Lean OKRs

But how to do this? How can we build these high-performing teams? More specifically, how can we change the behaviors of teams? Because, if we want to see better and new results, we must create new and better habits and behaviors. For example, we know, based on decades of research and Agile software development, which principles and practices work and won't work. It fascinates me that we, as an industry, are so drastically underperforming compared to other engineering disciplines like civil, or construction. Why aren’t teams applying these principles and practices? What are we missing? This question has become central in my research over the last few years and I must admit, I’m still learning. 

I’ve worked with hundreds of software teams throughout my career. I’ve worked in both low-performing and high-performing environments and held various roles within these teams from software engineer team member, to mentor and manager. So from experience, I know what it’s like to work as a part of these high-performing teams and how to lead them. If you’ve ever worked in such environments, you’ll truly never want to work anywhere else. When I was in leadership roles, I borrowed several techniques from the field of behavioral science. By changing things up, by shifting our focus from reactionary to that of learning, we saw notable, trackable results and were able to seemingly pivot on a dime.

I can still remember my first day so clearly. I was working for a big financial company and I was recently assigned to a new team as the lead engineer. We were a cross-functional team with four engineers and three business analysts. The team worked with Scrum (forced by Agile coaches), had a huge backlog of work, and hadn’t released any software for the past half year to a production environment, let alone gotten any feedback from real users. 

Many team members had a passive working attitude and I was totally taken aback (although I guess I shouldn’t have been based on their results) Coming in late, leaving early. Working from paycheck to paycheck without any strong motivation to deliver their best work. They came to work, put on their headphones, and only woke up to get some coffee, smoke, or grab lunch. If you ever find yourself walking through an open space full of software developers with headphones on, prepare yourself! It has to be one of the leading indicators of low-performing teams I’ve come across. 

The days started out OK I thought, with daily stand-up meetings with some directional report-outs. However, I quickly noticed that when somebody spoke, the rest was staring at their toes as if their shoelaces had become the most fascinating invention they’d seen. The demos and retrospective meetings were similar in nature. The demos were PowerPoint presentations designed for stakeholders of what the team was going to do over the next half year. The retrospective was a meeting facilitated by the assigned Agile coach, in which it appeared that the team members had had an arts-and-crafts session and summarized the same problems but in different formats and layouts of colorful sticky notes. Sometimes it acted as a therapy session, with tears and all.  During my early observations, there were never any changes made to their way of working. Stakeholders weren’t involved, so couldn’t complain too much. The business analyst had offered the team’s services to the company’s large call center, but barely got involved in talking about any software development work. 

It wouldn’t have taken a professional to see immediately that something was wrong. Yet, apparently, I was the only one. When I asked my team members how things were going, their response was something like: “Just fine, it’s almost the weekend”.

How could this group be transformed from a bunch of individual contributors to a high-performing team? This is where those techniques from behavioral science made their grand entrance. Back then, I researched behavioral science based on my hypothesis that this soft skill had to be our secret weapon because these people had impressive hard skills, competencies and years of experience that in principle should make a rock-star team, but instead were belly-flopping on an almost impressive scale! In recent years, this soft skill was featured extensively in my book called “Lean OKR’s” which takes the OKR goalsetting framework and applies both Lean thinking and behavior changes to see remarkable results. It is a practice I have been applying to software development teams for years that has cracked the code, so to speak.

With that said, there are four steps involved in changing a team to adopt new engineering principles and practices. I prefer to blend some of Kotter’s eight steps of behavior change with some of my own.  

1. Awareness & Urgency

2. Set a goal

3. Change Behavior

4. Behavior Change Support

There’s that one quote: “Change happens when the pain of staying the same is greater than the pain of change”. This is how change happens, isn’t it? Somewhere along the way, we realize that something isn’t working, in short, we’re unhappy. From there, we imagine where we want to be. We set a goal. Not an overly ambitious one, not to start out with, because at this stage we need to build confidence, too. I’ve learned that stepping out of a comfort zone is a fine balance. Not enough of a challenge and old behaviors quickly rear their ugly head, too much of a challenge and there is uncertainty and resistance. There is a sweet spot where behavior change is introduced, grows, is fostered and eventually becomes a new normal.

Steps three and four can be treated as experiments and therefore are non-linear. Any good experiment is always circular anyway. I tend to mix and match behaviorial changes and supporting those changes as I feel it lends itself more easily to a learning mindset.

Awareness & Urgency

Let’s go back to our story of this team and talk about that critical first step that they took, what I believe to be a fundamental first step in any change process: creating a sense of urgency. If you don’t know you have a problem, you will not change. If you don’t feel pain, you won’t take any action. This was also true with the new team I was assigned to. 

One of my favorite tools to create awareness for change is to play games. Besides instant human behavior change (you’ll know what I’m talking about if you’ve ever played Monopoly with your family), it’s a non-threatening environment (for most people then). In many scenarios, I like to play the Agile Fluency Game (AFG) created by James Shore and Arlo Belshee. It’s a super realistic European style board game that simulates two and a half years on a software development team. I play it with board rooms, executives and software teams. The total play time takes 90 minutes, plus some additional time for the introduction and a short debrief, so not a big time investment overall.

My first step was to get the whole team to have lunch (which was a challenge with conflicting agendas and such). Next, during lunch, were people seem jolly and optimistic,  I would do the ask: “It’s so nice to sit together and have some fun with you all, would you be open to playing a new board game with me on a Friday afternoon over some drinks and snacks?” Since some people are (still today) a bit allergic to anything with the word ‘Agile’ in it, I prefer to call the game the Software Simulation Game. Luckily the team loved playing board games, so it was easy to convince them to play that same week.

That Friday afternoon in November I introduced the game. Since you need an officially trained facilitator to play the game, I suggested facilitating the game myself. Within two hours, the team learned more about concepts like User Stories, TDD and Continuous Integration, Technical Debt, and the importance of experimentation than ever before. It was a true eye-opener for them.  

Immediately after the game, they became super enthusiastic about trying some of the elements from the game in real life. If you find this interesting, feel free to pull me aside later today to see how you can become an Agile Fluency Game Facilitator, I just so happen to be a licensed trainer. So far, so good my marketing pitch! Anyway, my mission to create awareness and urgency for this team to change was a succes. The success rate on average is about 80%, which (not to brag) is my score after playing the game with over 50 teams now. Yet another reason I love the Agile Fluency Game; it is good for my self-confidence too, because I see in real time that I am helping others.

Metrics

All games aside, another tool to create awareness is the (correct) use of metrics. These days there is so much hype around DORA metrics, Engineering Performance Metrics, and of course OKRs, that it is difficult to understand what helps and what doesn’t. Many mix up the use of these tools and techniques (which is a topic for another time).

The week after this very successful game night, I suggested running an Agile Fluency diagnostic to see where the team was at in terms of Agile Fluency, a model created by James Shore and Diana Larsen, that helps measure a team’s capabilities and behaviors.  Of course, there are many Agile or DevOps self-assessments out there, but I tend to prefer this one since it is measuring behavior and capabilities, instead of checking the boxes on some technical tools you need to have installed (yes, I’ll say it, using Jenkins does not mean your team is practicing CI). Other tools use binary questionnaires to measure if a team performs certain best practices, which for me, isn’t the point. For example, you can say yes to “do you perform code reviews as teams?”, but that doesn’t help a team understand why that practice is important. In contrast, the Agile Fluency diagnostic lets you examine if you have the capability to deliver code without bugs (or only a few). There are many practices to achieve this level of quality,  ‘Code Reviews’ being one of them (though not a very effective one in my humble opinion).

Going back to the story of our team, running the diagnostic made the team realize where some of the big improvements could be made and where challenges of the team were hidden. One of the biggest challenges was the realization of not getting fast enough feedback from real users. Another one was the existence and accumulation of technical debt, which caused changes in the system to become slower and slower every day as well as more complicated to perform. After creating awareness with both the Game and metrics, their eyes were opened, the urgency was created and the team was highly motivated to do something about it.

Setting goals

So we were now fired up, and our next move was to take action. As a team, we started to write down a goal for the months ahead: “Improve the speed of getting feedback from real customers”. We also defined some specific behaviors the team needed to perform to get there and agreed that we will discuss weekly if we actually performed these behaviors. Why? For accountability, of course! Some of these behaviors included “showing a product demo to at least five real customers per week” and “pair programming for two hours each day”. Although the team’s main concern was that they have never done this before, I comforted them that I had the experience to carry them through. I’ve found that having senior members with this experience is very helpful but not necessary. Another concern was time. How much can we spend on trying this stuff out? I said we could start with an hour a day and take it from there. The whole team found this a reasonable approach and we agreed to trying it out that same week.

Providing this kind of support is critical in behavior change. If you need to perform a certain behavior, you need to be able to have support, guidance, encouragement, and feedback from your environment to continue the pursuit. In this case, a manager or lead allows for time to experiment or on-the-job training. To no surprise, these are again some behavior change techniques that have been proven to work by science.

The behavior change

From the next day onwards, each morning, we came together and planned work for that day with the whole team together. We decided on how to split work between pairs, including the business analysts. As you can imagine, our team meetings looked drastically different to when I had first started with the team. They were engaged, accountable, and had fresh ideas.

During the pairing session with the engineers, I was able to teach them how I prefer to program: TDD, write tests, and build confidence in refactoring. After a few days, engineers loved to pair up with each other. Every day, they were more eager to try out some of the programming concepts and practices I had taught them. They wanted to do more of that (yes, software engineering done well can be incredibly addictive). 

The week after, during the Monday morning check-in routine, one engineer said “I’ve learned so much that last week, this is amazing”. A business analyst said: “I was skeptical about this approach, but together we had so many great ideas to reach out to customers, I would have never come up with this on my own.”

We decided to extend the pairing time to two hours each day. Starting small and then expanding is another behavior change technique. 🙂

As a result, three weeks later we even tried mob programming on some small tasks with the whole team. With mob programming, you sit with the whole team behind a single monitor (or screen). Only one person is allowed to type. Is a variation of pair programming which is very effective for knowledge sharing and moving the needle. It won’t surprise you that this technique is based on some behavior science techniques as well.

After about two months, I could hardly recognize the team from my first encounter. They came in on time, full of energy. We collaborated with each other the whole day as a real team during mob sessions. No more headphones, but rather great conversations with each other. Discussing how to run our next experiment in our production environment and how to measure it. Business analysts were closely involved with the engineers because they finally could try out things that normally would take months. New ideas on how to improve both the system and how we worked came from both engineers and analysts alike and were tried out every week. We were able to deploy software to production after every code check-in, resulting in multiple deployments per day. Even in this harsh corporate environment.

But above all, people in the company started to notice our effectiveness. Real users collaborated with business analysts and engineers, resulting in a system that was saving everybody in the call center a ton of time. 

The story of this particular team is still ongoing. They now work on software systems that bring the highest impact for the company. Some team members left and joined other teams, helping them to change as well.  Sometimes the team members have regrouped and built other great products for the company.

What started as an average corporate software development team, resulted in an exceptional, high-performing team. Was this a unicorn? Not at all! I’ve repeated this journey many times throughout my career.  Every time I learn and improve too. Applying behavior change techniques to help engineering teams become high-performing has become my passion. I’ve studied and tried many techniques. OKRs, metrics, training and mentoring. However, without the support of some bright leaders, this wouldn’t have been possible. Just as the team of this story, I myself have needed strong senior leaders in place that have had my back and supported me, too.

The brilliance of this “ultimate soft skill” is that you will see virtually immediately when productivity drops. When teams have direct access to technical mentors that have studied and practiced behavior change techniques, they can be brought back to the Steps: awareness & urgency, the goal, the behavior change to get there and the support in learning and experimenting. This story isn’t a description of a utopian ideal, it is the “meat and potatoes” of how to go from an average, maybe even below average team, to an exceptional team. It is an investment in time, money, energy, but most importantly in people, that is so well spent and where the return is more than just the bottom line. It is people that been activated to seek out ambitious goals and make measurable changes.

Making OKRs Lean Again

Objectives and Key Results. A 40-year old, simple goal-setting framework, initially created by and for technology companies that needed to innovate at the speed of light. They are still wildly relevant today, some four decades later, and when used correctly, they can help you to achieve 10x growth. The popularity of the tool is still rapidly growing, as measured by the number of software companies developing tooling for it. At the same time, we see companies abandoning them. Why is that? Why is there so much fuss about OKRs anyway? To paraphrase John Cutler: “[...] they are just goals!” They are supposed to be simple.

Let me tell you about a fictional character. Let’s call him Dave. Dave’s story will help to illustrate how most organizations start their OKR journey.

Click the links below to read the whole series and join Dave on his journey.

Part 1

Part 2

Part 3

Part 4

Now Available!

Categories

• Culture 2
• DevOps 2
• Growth 1
• HR 6
• Innovation 1
• KPIs 1
• Lean 1
• OKR Check-ins 2
• OKRs 19
• Strategy 8
• Technical Leadership 15

Making OKRs Lean Again - Final Part

Welcome back to the final installment of Dave’s story. Dave and his company experienced quite a few ups and downs when it came to OKRs. A lot of the challenges could have been avoided if they had put their OKRs on a diet (or what I like to call Lean OKRs).

Dave’s story isn’t all bad. There is one aspect of the story that I do like. I like the data-driven angle of Dave in this story: HR used measurements and information to initiate an organizational change. However, it’s based on the wrong assumption. Improved alignment, focus and engagement are how OKRs got sold by many consultants, but that is not the problem OKRs are trying to solve! These things are side-effects of proper goal-setting. There are many other ways to set goals on engagement, alignment and focus. Why not set SMART goals instead? Don’t bother then with using a tough-to-get-right framework like OKRs. Instead, ask this question: Why is the organization struggling to get alignment amongst teams and leaders in the first place? What is the core issue going on here?

In Dave’s story, it was Dave himself that initiated the change. However, this trigger can also come from different department managers as a reaction to low team morale, low-performing software teams, part of a framework like SAFe, or growth hackers that heard about them. It really doesn’t matter. OKRs won’t help you to fix these issues. They are all the wrong incentives to start using OKRs. Why? Because OKRs are created by and for B2C tech companies to execute ambitious strategies by empowering high-performing teams to work on hard problems. You are probably not that kind of company (just yet - maybe one day you will be and when that day comes, when you need a framework to achieve your moonshots, OKRs will be waiting!). That doesn’t mean OKRs cannot work for your company, but you need to put in a lot of effort to get some results.

You’ve probably spotted a lot of waste in Dave’s story that lead to the following symptoms: low employee engagement, overburdened people, lack of focus, context switching, too many conflicting priorities, a large inventory of goals (all they did was transform existing measurements and goals into a new format), a bloated goal-setting process. Don’t fight these symptoms, instead, get to the root of the problem. In the end, Dave’s company didn’t change and they didn’t benefit from OKRs at all. The side effect being that OKRs have gotten a bad rap because the intentions of working with them were misaligned to where OKRs really shine. Instead of piling goals on top of goals, we need to put OKRs on a diet. What if we apply Lean thinking principles to OKRs? We could make OKRs Lean again!

Lean OKRs - The foundation

It starts by understanding your strategy. There are many different strategies within a company. If you are small, you probably only have a company strategy. If you are bigger, you can have a strategy for your product(s). Having a strategy is key, without it, OKRs just won’t work! Then you need to think about what part of your strategy requires a radical improvement (we call this Kaikaku in Lean), a goal that requires a change in human behavior.

For B2C SaaS companies, to grow your company, you probably require different customer behavior. For example, to increase LTV, you need to make sure customers engage with your app more actively, or move them from a freemium to a paid subscription. Your product teams can then set OKRs to focus on these challenges. This is the preferred model.

For other companies, especially enterprise companies, using OKRs is even harder. Most of the time, teams are far away from the customers. But you are not entirely doomed. Instead, leaders in these companies can focus on an internal behavior change. For example, using internal APIs, improving how leaders communicate strategy, greeting customers in a different way, proactively reducing manual tasks, seeking feedback from customers, etc). OKRs are now used for Organizational Change, which requires a different approach, and could, with some strategic thinking, help to build modern product teams. Understanding the difference between the two is key. It doesn’t matter which company you’re in, OKRs are about solving hard problems. They are about changing human behavior.

The thing is this: If you need to execute a very ambitious strategy, then behavior change is part of that. Behavior change is hard and takes time. Have you ever tried to change your own behavior? Then try changing the behavior of your team or a whole group of customers. It now becomes even harder. It requires focus, dedication and accountability. At the same time, people have other stuff to do. “Business as usual” is the biggest enemy of OKRs. It is why companies and teams can focus on only ONE OKR at a time. On a company level AND on the team level. Cut down department OKRs or any OKR layer. Don’t use your organizational chart to set OKRs. It just makes everything more complex (there are some exceptions when you are a very big company, but I won’t go into details here). Instead, foster cross-departmental team collaboration and alignment. Let senior leaders plot a strategy for achieving the company-level OKRs. Let them define draft Objectives for their teams or let senior products teams swarm around the company OKR themselves. Let leaders fight on priorities and conflicting Objectives before the next cycle starts. Then they need to bring strategic context or their intent to their teams and collaborate with them on defining measurable key results (preferably focused on outcomes) and challenge them on their ambition level. OKRs are very ambitious goals. You always stop at the team level, not the individual level. They are a team sport. You cannot win the World Cup in soccer by yourself. You need a team.

Install a lightweight process

Next, you install a lightweight system to achieve the team goals. A system that is easy for everybody to adopt and can fold into existing ways of working (e.g. Scrum). That system is called the OKR cycle, and without it, OKRs won’t work! It’s the operating system to achieve bold goals and continuous organizational change.

The default Lean OKRs cycle is 90 days. It gives you and your teams enough time to make those behavior changes and build new habits. To stay accountable and measure progress, you need to check in on your OKRs every week. Look at the latest data, define obstacles and run experiments to remove them.

Mindset

It is this “scientific thinking” that will help your teams to move the needle on hard goals. It is “scientific thinking” that will create innovation, by letting the people close to the technology (and your customers!) solve hard problems. Can you teach your teams these skills? You should! Coach them. In the realm of Modern Product Development, teams and their managers use “scientific thinking” to explore and develop hypotheses to test. They have a whole arsenal of methods and techniques they can use to move the needle. And they have built the skills to run small experiments and to do so fast. Multiple per week even. If you want to use OKRs, your product team needs to master these skills. It’s not enough to convert existing goals and KPIs into OKRs and then tell everybody that you are “doing OKRs”. It’s not enough to ask people to work on a hard problem without the knowledge and expertise to do so. It’s not enough to only ship features to your customers. Probably half of them aren’t going to move the needle on your goals anyway (as Marty Cagan once said).

OKRs can look simple (and they are), however, it’s very hard to do them right. It requires slowing down first, changing people’s way of working. It requires people to think about problems to solve, to radically focus on one problem at a time, making tough decisions, fighting over priorities (and compromising), achieving consensus amongst leaders, behaviors to change, understanding that product teams will use OKRs differently than the rest of your organization, building strong data literacy, hiring strong leaders that are willing to coach people and empower teams, and having one-on-one’s every now and then. This stuff isn’t easy and it’s not for everyone. Are you prepared to change your way of working?

You have two choices when it comes to implementing OKRs. One, you use the OKR format to set your goals (you’ll reap some benefits, but not more than you would using SMART goals). Or, you use the Lean OKR approach I just explained to boost company and team performance to the next level.

How can we make OKRs lean again?

Here are three easy steps to make your OKRs Lean, which you can start implementing today!

1. In the next cycle, focus on ONE OKR per team at a time. Use strategic thinking. Focus on behavior change. Battle it out! Pick one high-performing team to start with.

2. Install a lightweight process to achieve your OKRs. Based on Plan, Do, Check, Act. Study and try scientific thinking with your team. Toyota Kata is a great resource to start.

3. Mindset. Teach and practice scientific thinking.

And with that, we wrap up our fictional character Dave’s story. For some people, this story isn’t too far off from real life. If you would like to know more about Lean OKRs, you can order my book “Moving the Needle with Lean OKRs” or you can contact me. I offer a free OKR discovery call for those that are ready to roll up their sleeves and get started with Lean OKRs within their company or organization.

Now Available!

Categories

• Culture 2
• DevOps 2
• Growth 1
• HR 6
• Innovation 1
• KPIs 1
• Lean 1
• OKR Check-ins 2
• OKRs 19
• Strategy 8
• Technical Leadership 15

Making OKRs Lean Again - Part 3

Welcome back to the third installment of Dave’s experience starting out with OKRs. As you know, the end of the quarter has arrived and their learning curve is huge.

End of the quarter

The end of the quarter arrived. Everyone was asked to report on their OKRs. Teams and departments reported little progress on their OKRs. The Sales team however did great! Dave had already informed Mary that this was to be expected. The first OKR cycle is for learning. All the OKR experts will tell you this. So they decided to give OKRs another try. Dave realized this OKR initiative took more effort than expected. But he learned from the literature that the process takes time, to be patient. He also learned that setting OKRs with so many people takes a lot of preparation. Dave had more on his plate these days, because of onboarding new employees, leading the talent acquisition team and increased sick leave. Therefore, he hired a program manager that could oversee OKRst. His name was Bob. Bob had years of experience in change management programs, so none of what the company was experiencing with OKRs was new to him. As good program managers do, he started to formalize the process. He created mandatory meetings for everybody to attend to smooth out the OKR process. With the company still growing, new people and teams popped up almost every quarter. When it came to setting OKRs for the upcoming quarter, it took three weeks to make sure everybody had filled in their OKRs into the software tool. Regardless, Bob was confident that he could mobilize such a large group of people every quarter to fill in their goals.

Not everybody was happy with the continuation of the OKR initiative within the company. Some people said there were too many meetings now. Some people didn’t enter their OKRs into the OKR software system. In response, Bob started to send automated email reminders to people: “PLEASE FILL IN YOUR OKRs”. After chasing people down, finally, most of them had submitted their OKRs.

This process continued on for almost nine months.

Evaluation

One day, Mary walked in and asked Dave: “We have been using OKRs for 3 quarters now, how is the engagement going on?” Dave responded: “Your timing is perfect! Yesterday, we ran another employee engagement survey, however, the results aren’t that great.” “Oh? How come?” asked his boss. “Well…,” John hesitated to share the findings with her because he didn’t like to be the bearer of bad news. “We only saw a small uptick in the engagement survey, it seems the OKRs didn’t work”. His boss looked confused. “How is that possible? Everybody has now clear goals defined, everything is now made transparent, why aren’t they working?” John replied: “People still complain that they’re missing the bigger picture.” He continued: “And they also don’t like working with OKRs because they see them as an administrative hassle”. His boss replied: “Mmmm, maybe this OKR thing is not for us. I don’t see very many results coming out of it anyway. Yesterday I had a meeting with one of our investors and he talked about OSGM and V2MOM or something. Let’s try that instead. I think it’s a better fit for us.” She looked at Dave: “By the way, can you prepare for the annual performance reviews, it is that time of year again! And we can definitely use the OKRs to evaluate people now.”

Analysis of the story

The problem with Dave’s story is that you probably believe it’s fiction. Unfortunately, this story is more real than you might believe. There are many things that went wrong that I’ve seen in real life, as well.

The main reasons that things go sideways when implementing OKRs are because there is an issue with one or more of the following:

• Company culture. It is one based on a command-and-control model and doesn’t have empowered (product) teams.

• Focus. There are too many OKRs and the “big picture” isn’t clear.

• Purpose. Leaders fail to communicate why they want to use OKRs.

• Routine. People get discouraged and disengage due to a lack of visible results (set & forget)

• Autonomy: OKRs are set by management (not independent teams) and the OKR software manages the progress on those goals.

We see similar patterns when companies try to adopt “Agile working”, Scrum or trying to scale any of the Agile methods. “We have implemented Jira so we are Agile!” If you struggle to get these things working in your organization, then OKRs are an even tougher challenge for you.

Deciding to jump on the OKR train is usually triggered by some shocking report score, like a poor score in employee engagement. For some time the HR department has been tracking employee engagement and usually, for the lack of any better measurement, they use eNPS. Some more senior HR departments use a more sophisticated survey, like the OHI or Q12. These measurements happen every year or every half year. The trigger to start looking into OKRs is almost always a low score on purpose, lack of direction or low alignment.

The problem is that OKRs are primarily for B2C product-led companies with high-performing software teams. OKRs is Agile on steroids. If you can’t get the basic Agile stuff to work, if your teams don’t master software delivery, if they are not empowered, then OKRs aren’t for you. Well, not yet, at least!

There is a different approach to OKRs that has proven results in large or enterprise organizations. With careful timing, in combination with hiring strong product leaders, you could use OKRs for transforming your existing company culture into a modern product development culture. OKRs can act as the framework for continuous culture transformation.

In my next post and the final installment of Dave’s story, we’ll talk more about where it all went wrong (and what went right!).

Now Available!

Categories

• Culture 2
• DevOps 2
• Growth 1
• HR 6
• Innovation 1
• KPIs 1
• Lean 1
• OKR Check-ins 2
• OKRs 19
• Strategy 8
• Technical Leadership 15

Making OKRs Lean Again - Part 2

Welcome to the second installment of Dave’s story as he embarks on his OKR journey.

“I want to be able to manage all of these goals,” Mary told him. Dave did a quick search and within no time, he was able to select software that supported his needs. The nice part? The tool also supported the annual performance management AND they offered OKR training. “Isn’t that great?!,” Dave exclaimed, while showing the tool to Mary. The next day, with the approval of Mary, he purchased the OKR software tool. Based on his previous experience with performance management, he understands the importance of such a tool. It should not only help to keep track of people’s goals but also to maintain the transparency of OKRs (which he had learned was vital to the process).

The lovely people working for the OKR software tool company suggested getting some employees “OKR certified” to smoothen the OKR process. He quickly found some volunteers. The marketing intern, the Agile coach (because they are the company-wide “facilitators”, right?) and an engineering manager. They were sent to a one-day OKR training and within a week, all three received their certificate of completion.

“We are ready to start implementing OKRs,” Dave said to Mary. “Next week is the week before the quarter starts. Let’s set the OKRs then.”

Setting OKRs

It’s the following Monday and Dave is really excited about launching OKRs. The CEO gathered all senior management and announced that “...from now on, everybody needs to create OKRs in order to boost employee engagement. Not only will OKRs improve our low employee engagement score, but it will also help with alignment and focus”. She looked at James, the CTO, who is always a bit reluctant to new company changes, and continued: “We have trained some of your colleagues in OKRs and they are now certified internal coaches. They will be helping everybody to set their OKRs.” With a stern tone, she wrapped up by saying: “And I expect each of you to deliver your OKRs before Friday.”

And so it happened. Everybody in the company started to set OKRs. The executing team set OKRs first, then managers set their OKRs, then those same managers set OKRs for their departments: Marketing, Sales, IT, Customer Service, Operations, Engineering, R&D and UX. Then each team was asked to set OKRs, connecting to the department OKRs. And finally, every individual team member was asked to set OKRs themselves.

During the OKR setting process, people had figured out quite quickly that they could transform their current goals to fit the OKR template. So, the Sales teams changed their sales targets into OKRs, Marketing created OKRs for each campaign, Customer Service changed their “Time on the phone targets” to OKRs, Ops their “Uptime targets”, Software engineering their “roadmap items”, UX their retooling goals, and even HR re-wrote their “new hires targets” into OKRs. The leadership team did the same. Revenue, customer satisfaction and EBIT numbers got transformed into OKRs. Even each individual team member converted their personal development goals into OKRs, too!

This resulted in five OKRs at the company level. Five OKRs per department and manager, three to five OKRs per team and the same for each individual. It was as if they were sprinkling some magical OKR fairy dust over all of their existing (and mundane) goals. Lucky for them, they had the OKR software tool to help them manage all of their OKRs.

Dave was in charge of coordinating the OKR rollout, but after one week it was already apparent that not everyone was happy with the changes. He heard complaints from multiple people, such as “OKRs simply don’t work here”, “We also have other work to do, we’re drowning!”, “We already do Scrum, so why do we even need OKRs?” Dave was able to placate them by replying: “I hear what you’re saying but we really need to improve employee engagement and therefore OKRs are necessary”. It is worth mentioning, not everybody was unsatisfied with the changes. Some were quite happy that their leaders took action based on the employee engagement survey result, so they gave the leadership room to try OKRs out and proceeded without too much resistance (something that isn’t always the case in other companies).

During the Quarter

After all the OKRs were set, people got to work. They continued working on the tasks they were assigned to. Developers continued working on the features they received from product owners. After all, the Objective was to “Deliver awesome UI to customers.” UX kept working on the designs for the UI and handed them over to the engineering teams. However, they couldn’t deliver as fast as usual because their OKR was about converting their existing UX designs into a new tool, which took up a lot of their time. Marketing couldn’t make any progress on their OKRs either. They couldn’t launch their new marketing campaign because they depended on engineering to deliver the new UI. At the same time the Engineering team finally received new UI designs from the UX team, the company welcomed a new “big whale” client. The Sales team was on a roll to move the needle of their KRs. This required at least five software teams to pay attention to delivering on this.

At some point, the management team took a look at their OKR software tool and noticed that there was low progress on most of the OKRs. So, they decided to put some pressure on the Ops and software teams to deliver on time. Because the Operations team didn’t have time to automate their own work, they had a hard time with this new customer coming on board. Some teams were working overtime to deliver before the due dates of their “epics”.

The pressure seemed to work. The teams did some amazing work. They were able to push out the UI changes and a new feature before the deadline. “These OKRs work great!” some senior manager boasted over lunch.

The team moved back to working on features for this new major client. Meanwhile, there were new bugs coming in because existing customers were also using the new UI. Some software teams couldn’t focus on the OKRs or the major client anymore because of customer issues. “Maybe next quarter we can set OKRs for reducing bugs and do a big refactor project”, one of the software architects cleverly thought up.

Weeks went by and little progress was made on their OKRs as they worked to keep their heads above water.

In my next post, we will learn more about Dave and his bumpy start with OKRs. Until then, can you predict what the end of the quarter is going to look like for Dave’s company?

Now Available!

Categories

• Culture 2
• DevOps 2
• Growth 1
• HR 6
• Innovation 1
• KPIs 1
• Lean 1
• OKR Check-ins 2
• OKRs 19
• Strategy 8
• Technical Leadership 15

Making OKRs Lean Again - Part 1

Objectives and Key Results. A 40-year old, simple goal-setting framework, initially created by and for technology companies that needed to innovate at the speed of light. They are still wildly relevant today, some four decades later, and when used correctly, they can help you to achieve 10x growth. The popularity of the tool is still rapidly growing, as measured by the number of software companies developing tooling for it. At the same time, we see companies abandoning them. Why is that? Why is there so much fuss about OKRs anyway? To paraphrase John Cutler: “[...] they are just goals!” They are supposed to be simple.

Let me tell you about a fictional character. Let’s call him Dave. Dave’s story will help to illustrate how most organizations start their OKR journey.

Dave is the HR manager of ACME, a cloud-native scale-up company that develops software to help sales teams find new business contacts. The company grew very fast last year. It went from 200k MRR to 1Mi MRR over 5 years. It now has about 150 employees, distributed over three countries. The leadership team still wants to grow the company and take it to “the next level”. Lately, the company has had some problems with finding and keeping good tech talent. The employee retention rate is very low, especially in engineering. Therefore, Dave decided to do an Employee Engagement survey to find out what was going on. When the results came back, he quickly found out that one topic in particular stood out: People wanted to have a clear direction, focus and better alignment (which was currently absent, according to a very large majority, despite there being a strategy paper that was written and shared back in December).

It’s Sunday morning and Dave is reading his favorite HR magazine and learns about OKRs for the first time. He gets really excited when he reads about how this tool has boosted morale, alignment and engagement in a company similar to his. This tool looks very promising; it seems like a simplified version of an employee performance system. Simplicity is key, which is something that Dave values. It makes perfect sense to start using OKRs to see if will help to “fix” the employee engagement problems within his company.

That same week, Dave dove into OKRs and spent some of his evenings researching the topic. He did a Google search and quickly found some interesting articles but also found that the information available was a bit scattered, so he bought a book on OKRs. Two weeks later, Dave read the book cover to cover and was convinced. This can really help the company improve engagement! The next day, he sits down with Mary, the CEO of the company. He tells her what he had learned and how this new tool could help boost employee engagement, and thus, retention. Getting Mary on board with OKRs was easy. Who doesn’t want to have highly engaged people? Within thirty minutes, they agreed: “Let’s start using them in the next quarter”. The start of the next quarter was coming up in three weeks’ time.

In the next post, we continue with Dave’s story. Until then, how hard do you think it could possibly be for Dave’s company to implement OKRs?

Now Available!

Categories

• Culture 2
• DevOps 2
• Growth 1
• HR 6
• Innovation 1
• KPIs 1
• Lean 1
• OKR Check-ins 2
• OKRs 19
• Strategy 8
• Technical Leadership 15