Goal setting as a tool for organizational change: a case study
/by Paul BultmannThis article explores how Objectives and Key Results (OKRs) and goal setting can change the collaboration style within an organization, based on agile42’s experiences with a particular recent case study. In this instance, we introduced OKRs and noticed a number of changes emerging organically within the organization. The OKRs were intended to set strategic product goals, but we noticed new ways of collaborating, bringing about positive organizational change and empowering teams to self-organize. In this article we outline the challenges the company was dealing with initially, the positive side effects the OKRs supported, and some assumptions that contributed to these positive side effects.
The challenges the company faced
We were approached to work with a product department made up of 15 tech teams, all of which work on a single product. They had several challenges that both the teams and management were hoping to improve.
Firstly, they had identified a strong lack of direction and priority on department level because there was no product strategy or roadmap. They were working from a long feature list from stakeholders, which had a number of contradictory requests and contained detailed descriptions with fixed scopes.
The teams were also noticing a lack of team autonomy. They weren’t able to make decisions related to product improvement. It was the kind of culture we refer to as a Feature Factory, where the team was building a large quantity of requested features rather than taking an iterative approach to build and improve the product. The result was a lack of focus on the value of the functionality. To make matters more difficult, the dev teams didn’t have access to the business problem, so they were not able to do any reasonable scoping.
Additionally, there were strong dependencies between teams. Most of them were able to deliver smaller features independently within their area, but when it came to bigger releases, dependencies occurred all over the place and created bottlenecks.
OKRs as a tool for organizational change
The leadership team started to experiment with OKRs and set strategic product goals for the department. Over time it grew to a full goal-setting framework. They started with big and broad intentions that were valid for the year. The intentions for the year included the following examples:
- Build up a new revenue stream (including a new customer type)
- Increase the product usability
- Integrate partners via an SDK (Software Development Kit)
- Migrate to new cloud provider
For every quarter the big intentions were broken down into Objectives and measurable Key Results, which were valid for the whole department. Some examples for the quarterly department Objectives and Key Results included the following:
- Yearly Intention: Build up a new revenue stream
- Objective: soft-launch our MVP
- Key Result 1: Launch two cities
- Key Result 2: Sign up 50,000 new users per city
- Key Result 3: Learn the top five feature wishes of our users
- Yearly Intention: Increase the product usability
- Objective: Decrease misleading items in sales funnel and checkout
- Key Result 1: Increase conversion rate by 4%
- Key Result 2: Reactivate 100,000 passive users
- Key Result 3: Identify the top three usability flaws during checkout
With those given targets all teams were asked to set their own quarterly OKRs that contribute to the abovementioned department goals. All this was synchronized and made transparent in newly introduced events: every quarter there was a Review, Retrospective, and Planning event with all teams together.
The positive effects of goal setting
Some time after introducing the new goal setting framework, there were three key positive organizational changes noticeable that had not been anticipated.

Photo by Jud Mackrill on Unsplash
Focus on outcome instead of output
There was a distinct shift in the mindset, from an output- to an outcome-oriented approach. In the beginning the strategic goals were used to get a feature list implemented (e.g. integrate voucher provider X). This gave little freedom to the product teams for problem-solving.
By formulating the Key Result as a measurable business value (e.g. increase monthly active users by X%) the teams were asked to find solutions themselves. In this case a voucher provider could help to reach the Key Result, but it is only one possible way to do so among many others. The teams needed to ask themselves, “what can we do in order to increase monthly active users”? And that's a totally different challenge than “I have to implement feature X”. It encouraged team members to consider the impact of their work and the features they built, rather than just checking them off a list.
Product Discovery Streams
This positive side effect came along with another challenge and opportunity. While the teams were great at delivering a clearly described feature, most of them were not accustomed to being involved in solving a business problem. They simply didn’t have the skills required to dive into the business context, understand the customer, run interviews, evaluate possible ideas, and design and run experiments with a subset of users.
The organization started to realize that there was huge scope for new skills to be learnt. So they began to experiment with product discovery streams that were using design thinking, user experience design, and other approaches depending on the situation. Within a stream, people from different departments started to work together that wouldn’t have been in contact before, e.g. business development, operations, UX, product teams, and developers.
The organization increased its ability evaluate and test ideas before implementation, and reduced potential waste of unwanted features. Customer centricity also increased significantly as there was research made about their needs and wishes rather than untested assumptions.
The emergence of temporary teams
Another unplanned positive effect was the building and dissolving of temporary teams around business problems. Depending on the nature of the topic, as well as its complexity and size, a group of people came together to solve the problem. Previously, backlog items would have been sent from one team to another, with bottlenecks forming in between. The new system meant that teams faced with time pressure, teams could simply come together for a short period of time, get the work done, and then move back to their original teams - with the added bonus of enhanced sharing of knowledge.
Why did these positive changes occur?
There are a number of conditions that contributed positively to the above side effects of the goal setting. Although it is highly multifactorial, we want to highlight some factors that we believe have had a strong influence.
Connecting people rather than coordinating
First of all we observed a strong focus on connecting people rather than coordinating them. The leadership team understood that if people know and trust one another, they will collaborate in a meaningful way when it is needed. So there were a lot of social events and team building activities that created bonds between people, especially during pandemic times. This made it easier to ask for help and to collaborate on a specific problem.
Leadership allowed freedom to self-organize
We observed that the leadership team gave the teams a lot of freedom and set high expectations for the teams to self-organize. This was to such a high degree that there were even complaints about missing structure to help teams coordinate themselves, and concerns that the leadership team was too uninvolved. Although we initiated rounds for coordination, the interference stayed low so that the relevant structures simply grew around specific work needs.
The UX department was strong, capable, and eager
Finally we saw that the UX department was strong, capable and eager to change the mindset within the department and company. They quickly took the initiative to drive a product-focused rather than a project-focused mindset, and to experiment with product discovery. It also was their first time doing so, but they did a great job by involving the right people, being willing to fail and to learn from that.

Photo by Annie Spratt on Unsplash
What can we learn from this case study?
In conclusion we observed these organizational and cultural changes happened due to the implementation of OKRs (or any strategic goal-setting framework). It guided the department towards a few common goals. This influenced how the organization collaborated, while new structures evolved and rituals grew organically around these structures. This resilient structure developed organically - not by management or consultant’s design, but by the needs of the people that work with them.
Many organizations focus on designing collaboration models and defining how people are supposed to do their work. There’s a saying that will be familiar to most who have heard of Agile frameworks: “manage the work and let the people self organize around it”. This case study was a great example of this, and can serve as inspiration for other managers and leadership teams. Allowing teams to self-organise around the goal-setting framework has a big impact and can be a change management tool in and of itself, leading to new structures and ways of working.
Interested in transformation at your company?
We are available for training, coaching, consulting, workshops, and courses, both in-person and remotely. Take a look at our online short courses, browse our Scrum and Kanban certifications, and check out our leadership courses. If you’re interested and want more information, feel free to contact us.