Grow Fast, Change Faster: Accountability Is Fundamental When Scaling
Let me just say this right away: delivering a product is hard and delivering a platform that builds products is even harder! And, doing it while doubling the size of an engineering department every couple of years just adds even more pressure to the mix. All our new hires need onboarding and must learn about both our extensive product and the competitive landscape in which OutSystems operates.
With this going on, is it even possible to keep delivering a quality product at a fast pace? The answer is, yes, it is. Let’s look at how. I’ll be using OutSystems as an example, but you can make this work in your organization, too.
It Starts With the Roles
In our organization, the following roles are involved in the development process:
- Product managers work on our strategic roadmap and define the main direction for the next 1 to 3 years.
- Product owners take the strategic roadmap and decide what should be worked on next (the right feature with the right scope at the right time).
- Team captains lead and grow the teams so they deliver better and quicker.
- Developers do the magic so wonderful things happen!
Now imagine a scenario where developers are not 100% focused. The delivered features are not the best quality. Team captains babysit the teams, review the features, and put aside the execution of the initiative. Meanwhile, the product owner stops thinking about the next features and starts looking at the status of the current initiatives to make sure they are on the right track. Finally, the strategic product manager, who should be looking at the future and the impact of the business, is constantly worried about the short-term roadmap (the next six months).
Everyone is spending more than 30% of their time making sure others do their jobs. Needless to say, this is unproductive and doesn’t scale.
Although all of us are driven by excellence and would never dare deliver unfinished work, we did notice that we were spending too much time making decisions. There had to be a better way.
Organizational Shift: Where to Start?
We started with the developers, of course. There were five times more of them than product managers, product owners, or team captains; we had more developers than all other roles combined. Therefore any change would have to go through them; they were absolutely essential to scaling our organization.
Our goal was for all developers to be self-sufficient and accountable for what they are delivering. By empowering them, we could completely change the way everyone works as follows:
- Team captains can focus on executing, ensuring that deadlines are met because if something is wrong, the developers will raise a flag and ask for help.
- Product owners can focus on the next steps. If something is wrong with the execution, the team captain will raise a flag and discuss scope changes.
- Product managers can focus on the strategic, long-term roadmap. If something is wrong with the current initiative, the product owner will raise a flag and discuss roadmap changes.
If this went well, it would mean we would be increasing our productivity by almost 30%! So let’s see what we’ve changed in our process to achieve this.
1. Sprint Goals and Timeline Focus
First and foremost, we now spend more time defining the value we wanted to deliver in each sprint, including thinking about the demo we would present to our stakeholders. We take these goals seriously and embrace them as a must!
When moving from one sprint to the next, we check the overall timeline to understand the impact of small delays on the overall project. If you only think about the sprint, it’s pretty easy to let something go because you simply postpone it to the next sprint. But if you look at the overall timeline, you understand that the same delay might compromise the final deadline, which significantly changes your perception of failure.
2. Presenting Individual Work in Sprint Retrospectives
Before starting each sprint retrospective, each team member presents the work of that sprint. When someone explains what went well or wrong, that person is more accountable for what he or she does during the sprint.
The idea here, though, is not to publicly shame people but rather to get the team to identify problems and act on them. So, we try to ask, “What can we help you with?” as this is the kind of spirit that boosts the team’s growth (and spirits).
3. Small Syncs
When tackling multiple features or user stories during a sprint, more often than not developers are concerned and focused exclusively on their tasks. This could eventually compromise deliverables; the kind of problems we face on a daily basis requires more than one brain!
Because of this, we started doing small syncs, where developers not only share their challenges and problems but also show small demos of what they had accomplished. Other team members then make suggestions. The result is even smaller and faster iteration cycles, whereby we’re delivering stronger features and work better as a team.
These collaborative syncs and shared opinions encourage everyone to become more accountable for everything that is delivered by the team.
4. Feature Owners
We now assign each high-level problem or feature to a specific developer, the feature owner. This is not an official job title, but internally it means that that developer is responsible for the feature’s deliverable. Such responsibility includes making sure the design doesn’t have loose ends, the proper stakeholders are involved, the feedback is used to react accordingly, and the feature is delivered on time. If something goes wrong or a question arises, the team is not waiting for the team captain to deal with it and is more accountable for what is being delivered.
This person is basically a “Mini Team Captain” and is 200% accountable for the feature; I can tell you that! Some of them even write about “their” features in the end.
5. Whatever Works
Every organization is different, and it’s important to find what works for you. For example, we came up with small tricks to get everyone to embrace this new mission. A couple of months ago, we added “accountability” post-its to the team’s monitors so everyone reads them every time they look at the screen. This is a little thing that makes a big difference. You can try this in your organization or find something else. Big or small, choose what makes sense and go for it!
Quality and Focus
This shift was extremely important for us and this commitment paid off: we are delivering more without sacrificing one iota of quality. We also started having more feedback from stakeholders, and we noticed increased satisfaction.
As a product owner on an accountable team, I feel completely confident in what we’re delivering, and I am more focused than ever on what’s next.
