Boosting Team Productivity During Growth Stages
A team with an inspiring mission and a supportive environment can achieve remarkable outcomes. But if you put the same team members in a different setting, they’ll become demotivated, and their productivity will stall.
So, what factors can boost team productivity and motivation?
In this article, I will share a story to reflect on how to boost team productivity. I’ll conclude with the key principles you can use to build an effective and scalable team.
Situation: Growth with Declining Productivity
A few years ago, I was brought in to help a software development team working on an innovative product.
This team, which had been working together for several years, had achieved remarkable results and built a well-functioning product that was well-received by end users.
When I joined, the team was a harmonious unit — members supported each other and shared good collaborative efforts.
But as the team grew to a dozen people and the number of customers rose, they faced a significant productivity decline. Delving deeper into their daily work revealed substantial challenges: diverse priorities and a productivity trap.
Diverse priorities
The backlog was stuffed with diverse activities — from server management tasks to customer-specific software configurations, customer requests, product refactoring to increase scalability, or long-term initiatives aimed at improving product usability.
And with every new sprint project, the list of tasks was growing overwhelmingly long.
It was not feasible to select the top three high-priority items, as everything on the list appeared to be of high importance.
Plus, new items, often urgent, constantly emerged from customers or other departments. These tasks were critical to address early — delaying them could result in unhappy customers, blocked workflows, or risks to important milestones.
Productivity Trap of Early Growth
Growth was on the horizon.
New customers were coming in, bringing new needs for the product. And we needed to expand the team.
But, adding more people to the team without ensuring an efficient workflow didn’t seem wise.
The current team setup had worked well when the team was smaller, but now, it was clear that changes were necessary. Moreover, the current team structure was not scalable. Hiring more people might increase the headcount, but coupled with the already existing inefficiencies, it would mean a waste of resources.
We identified these productivity problems:
No clear team purpose — No single inspiring mission unified all team members. Asking them about their goal gave me so many different answers
Insufficient accountability — With so many priorities circling in the team, some areas were left immature, lacking clear ownership and responsibility
Suboptimal scalable structure — The team structure was not prepared for scaling. And without a clear structure, adding more people was ineffective and wasteful.
How did we Boost Productivity
So, although everyone was eager to drive improvements, it was essential to first understand the existing dynamics. Why are things done the way they are? What are the team members’ perspectives? How do they feel about change?
Disruptive change could be a double-edged sword.
When executed correctly, it can lead to rapid improvements and inspire the team. But, if introduced at the wrong time or in the wrong manner, it can disrupt existing workflows, demotivate team members, and cause chaos.
So, we didn’t make the change overnight. It happened gradually. People needed time to gain the right skills, adapt to changes, and, most importantly, understand the strategic direction of the change. This gradual approach ensured everyone was on board and ready for the next step.
1. Understanding the team's activities
We began by categorizing the backlog tasks into distinct categories. Each item needed a clear purpose and had to fit into a specific bucket, whether technical debt, customer support, product enhancement, or another area.
This initial step gave everyone a clearer picture of the team’s activities. The initial list of categories needed some refinement, but the pile turned neater with each new week.
Planning sprint tasks became much more straightforward, and identifying bottlenecks in the team became easier. We could now see where most of the work was coming from and where we needed more capacity.
2. Identifying domains
Within a few weeks, it was clear that we could identify certain domains of work within the team.
Customer support domain
It became evident how much time was actually spent addressing customer requests. These activities were challenging to plan in advance and often disrupted other development work, slowing the team in building new features. Moreover, this supporting work required different skills than those typically possessed by software developers.
So, we dedicated a few members to this subdomain and hired people exclusively for service management. In a few months, this became a separate team with clear goals — service delivery excellence, customer satisfaction, and continuous improvement.
Product domains
Initially, everyone viewed the product as a single, unified entity — a sophisticated piece of software that analyzed data from customer software systems and provided various insights for the end user.
However, as we delved deeper into its functionality, it became clear that two distinct parts of the product had emerged over time:
User-facing product — This part of the product was designed to be intuitive and user-friendly, providing a seamless experience for our customers and had its own challenges like users demanding more features, greater ease of use, and faster performance
Analytics product — The user-facing component relied heavily on a complex analytics component in the background. This part needed understanding different software languages, tracking language trends, and analyzing performance metrics. The challenges here were different: optimizing performance, building for reusability, and understanding software patterns
As these two parts became more distinct, we naturally began to form subteams, dedicating roles focused specifically on one or the other part of the product. This allowed for more specialized attention and expertise, improving both the user experience and the effectiveness of the analytics.
3. Decreasing dependencies between teams
Making the subteams effective and fully independent didn’t happen immediately. Knowledge was shared across teams. But as the split became more distinct, it became apparent that the teams needed to be more independent.
So, people started working more on documenting the knowledge, establishing clear, standardized processes, and thinking about automating specific process steps.
The user-facing and analytics products were already well split into precise modular components, which helped teams be more independent in their development and maintenance.
To make the split fully operational, we started establishing more apparent interface dependencies (APIs) between them so we had more agile teams, and each team could be independent in its release cycles.
4. Building small but effective teams with a clear mission
By creating smaller and well-aligned teams, their mission became much clearer.
The customer support team started to focus more on customer satisfaction. They could see the effect of delaying requests more clearly and began implementing new tools and processes to increase efficiency and customer satisfaction. By tracking data from customer requests, they discovered bottlenecks in the entire process.
The analytics team became more focused on its mission. It had to empower the product with advanced data-driven insights and robust software analysis, ensuring optimal performance. It also needed to follow programming language trends and optimize analysis algorithms. Relieved from the burden of handling various customer requests, its work became much more meaningful.
The user-facing team had a different goal — providing an exceptional user experience, ensuring ease of use, and continuously adapting to meet the evolving needs of users. They could now incorporate new ideas and ways of working to achieve better results in their goal.
Lessons Learned
This evolution happened over a few months, more like a year. It was a continuous improvement process. As the company grew, new needs emerged, necessitating further changes.
However, adopting an improvement mindset makes new changes easier to implement.
So here are the key takeaways from this story.
Establish a clear mission
A team with a clear mission is happier, more motivated, and more productive. A clear mission helps team members understand their purpose and remain focused on their goals. They can quickly implement meaningful OKRs connected to the company’s strategic goals. Eventually, they are more challenged to change the status quo.
Small teams are more effective
Small, focused teams are more agile and effective. They can make decisions faster, communicate more efficiently, and clearly focus on their specific goals. This structure allows for greater accountability, stronger synergy, and better collaboration within the team. And it allows for growth.
Less dependencies means higher productivity
If teams are separate, they should be able to work independently and autonomously. Fewer dependencies allow them to manage workflows, set timelines, and release features without being bottlenecked by other teams.
Last words
Revolutionary changes can offer significant advantages but also come with substantial risks.
Instead, implementing changes gradually allows time for adaptation and skill development. It carries people along the change journey, minimizes resistance, and helps smooth transitions.
Following these basic principles inspires, motivates, and encourages a team to make a difference, which is when productivity flourishes.
Originally published at https://blog.logrocket.com/ on 17 Jul 2024.
If you enjoyed this article, don't miss out on more content! Subscribe to Lean Product Growth for more valuable resources on how to build and lead scalable product organizations, delivered directly to your inbox.