It was the perfect storm. One of our lead engineers, Alex, had finally settled into coding a complex new feature that customers had eagerly awaited for months. Thirty minutes into mapping out the frontend architecture, a bug report came in from the customer support team. Every time they exported reports, all numerical data showed up blank. Alex dutifully stopped his work to dive into debugging. After an hour of tracing the code, his concentration was broken again — the CEO wanted to talk about prototyping screens for a new AI-powered app he promised investors by the end of Q3.
Overwhelmed and frustrated, Alex ended his day no closer to starting the customer-critical feature than when he began.
This scenario plagues engineering teams daily. The constant context switching between new features, technical debt, bugs, and other priorities destroys productivity. For companies relying on software innovation to stay competitive, it creates a growing sinkhole swallowing engineering bandwidth and morale.
Uncontrolled multitasking and interruption within engineering teams breed frustration and slow progress to a crawl. There’s a solution, though — proven structures to align engineers around focused, specialized teams insulated from the daily churn of competing priorities.
Engineering Productivity Slowly Erodes Over Time
It’s common to notice a decline in the productivity of a tech team as a project matures. This isn’t due to a lack of effort. In fact, the team is pushing as hard as ever. But over time, the pace of releases slows down, causing stress and frustration within the tech team. Meanwhile, users and stakeholders grow anxious; while they see costs rise, the speed of innovation drops. At the heart of this issue? The constant task switching by engineers.
For instance, if you’ve managed a successful software project over several years, your tech team eventually juggles four primary responsibilities:
- Creating new features based on user and stakeholder demands. For example, “We need to add an AI chatbot by year-end since our competitors already have it.”
- Enhancing existing features. Take the CRM system as a case in point; it initially showed customer meetings, but now there’s a demand to integrate a map with driving directions.
- Addressing support issues, like users being unable to download files.
- Ongoing application maintenance, ensuring the code remains efficient and manageable even if users see no visible changes.
Remember the early days of your project with a team of four senior engineers?
With little to no existing code, they enjoyed the freedom to craft new features without existing code constraints. There were no bugs to fix or support requests to handle because the application hadn’t been launched. It was a productive time, but this changed dramatically post-launch.
After the application’s release, users began pointing out bugs and suggesting improvements. While it’s possible to minimize bugs, eradicating them entirely is unrealistic. Some user feedback can be ignored, but issues, especially those raised by key stakeholders like the CEO, demand immediate attention.
So, what happens next? An engineer deep into developing a new feature is abruptly tasked with addressing a pressing bug. After a few days, he returns to his original project, only to be pulled away by another high-priority request. Over a month, this engineer could spend more than half his time attending to unplanned tasks.
Create Specialized Subteams
Identifying potential issues in a tech team before they escalate is crucial. But how do you realize when it’s reaching a critical point? Clear signs emerge. Stakeholders become restless, often seeking solutions to boost engineering productivity. They might even bring in external consultants to pinpoint what went awry. Simultaneously, engineers feel the heat, overwhelmed, and burnout looms. And if you ignore these signs for too long, the worst outcome unfolds: valuable team members resign.
These challenges indicate that your project has matured. It’s no longer sufficient to have a one-size-fits-all tech team. Instead, you should categorize and assign specific functions to address distinct needs:
Product Development: This team’s primary role is innovation. They’re the ones bringing new ideas to life. Their output is typically visible, signaling progress to end-users and stakeholders. Think of a situation where a new feature gets launched, and end-users see a tangible change in their user experience.
Product Improvement: While it might seem like an extension of product development, the goals differ. This team takes what’s already built and enhances it. For instance, a social media app might have a story feature, and now the product improvement team works on refining it based on user feedback. These intricate tasks may not always make it to the high-level roadmaps, even though they’re essential.
Application Support: This segment has a vast scope. It ranges from generating data reports to troubleshooting bugs. For instance, this team oversees a dynamic data strategy and swiftly identifies and rectifies data inconsistencies, ensuring the application’s smooth performance. This team’s responsibilities include monitoring servers, reacting to technical glitches, and consistently engaging with end-users.
Maintenance: Behind the scenes, this team ensures everything runs like clockwork. They handle tasks like database migrations or software upgrades. For example, a periodic software update should not be noticeable by end-users, but it’s crucial for optimal app performance and security. This team manages the backbone operations, from cloud setups to security patchworks. Often, refactoring code is also a part of their domain, maintaining the integrity and efficiency of the software.
Communicate the Long-Term Vision
Building software is complicated. It’s expensive. Maintaining software over the long term becomes even more costly and complex. Relying solely on engineers to handle everything might work at first. However, engineers will get burned out from wearing too many hats without the right processes, drastically reducing productivity.
To address this, split the engineering team into smaller, specialized subteams of 3–5 people that consist of more than just software developers. For example, hire analysts to understand requirements and work with data. Hire QA engineers to research bugs and test features. Hire DevOps engineers to handle the cloud and servers.
You don’t need to do this all at once. But it would help if you communicated to the team that you are building towards specialized subteams. This boosts engineer morale and retention. They understand it’s only temporary until the right roles are in place. Follow through on hiring strategically. Don’t just hire more generalists. Invest in specialized teams long-term.
Originally published on Medium.com
