Balancing Engineering Resources: A Case Study in Data-Driven Decision Making

Problem statement:
At NCTC, a cable provider cooperative, engineering teams struggled with competing priorities. Leadership expected rapid feature development while engineers balanced new development with system maintenance and customer support. Without data to show time allocation between these responsibilities, both sides grew frustrated. Leadership saw missed deadlines for new features, while engineers felt overwhelmed by constant customer support demands.

As a product and project management consultant, I needed to accomplish several things with this team:

1. Create transparency around engineering team workload
2. Establish a structured process to manage competing priorities
3. Build trust between leadership and engineering teams
4. Set realistic expectations for feature delivery timelines using data
5. Protect engineering team focus during development cycles with PMO process

I worked closely with engineering leadership and implemented several key changes to address these challenges. First, I set up Azure DevOps to track all engineering work. This included both feature development and customer support tasks. The system allowed us to measure time spent on each type of work through story points and sprint tracking, including all the asynchronous work that came at the team.

Next, I established a proper Agile framework. This meant creating clear sprint boundaries and protecting the team from mid-sprint interruptions. I trained an internal project manager to maintain sprint integrity and manage incoming requests. This person became the team's defender, ensuring they could focus on planned work.

I worked with the engineering team to properly size their work. We created consistent story point estimates for both feature work and customer support tasks. This helped everyone understand the true cost of different types of work. The team ran four complete sprints under this new system. During this time, we collected data on the story points completed for new features and customer support, sprint interruptions and the time impact, and team velocity against team capacity (time off, etc.).

Results
After four sprints, the data told a clear story. The engineering team spent about 40% of their time handling customer support and system maintenance. This left about 50% for new feature development considiering meetings and other day to day obligations. This data changed the conversation between leadership and engineering. Instead of arguing about missed deadlines, they could have productive discussions about priorities and capacity. Leadership now understood why feature development took longer than expected - due to solid data.

The new process brought several benefits as leadership gained realistic expectations for delivery timelines and the engineers felt less stressed as their support work became visible. Also, sprint planning became more accurate and the new project manager role helped reduce random interruptions. Both sides could make informed decisions about resource allocation and the team started meeting their sprint commitments because they now planned based on real capacity. Customer support work no longer derailed feature development because we reserved time for it. Leadership could make informed decisions about hiring needs based on desired feature velocity.

Key Learnings
This case study showed that data visibility often solves what seems like a people problem. When teams can't see the whole picture, they make assumptions that create friction. Simple tracking and measurement can transform team dynamics.

The project manager role proved essential. Having someone dedicated to protecting sprint boundaries and managing incoming requests allowed engineers to focus on their work. This role became a bridge between leadership's goals and engineering's capacity. Even if your company cannot afford a dedicated project manager, agreeing to someone having the authority to act in this role can be pivotal to development velocity.

Most importantly, we learned that improving processes isn't about working faster - it's about working smarter. By acknowledging and planning for all types of work, the team actually delivered more predictably and with higher quality.

Long-Term Impact
The changes we implemented became standard practice at NCTC. The engineering team continues to use Azure DevOps for tracking all work. They maintain the split between feature development and support work. The project manager role evolved into a permanent position.

Leadership now uses data to drive decisions about team capacity and hiring needs. They can better predict delivery dates for new features because they understand true team capacity. This has led to better roadmap planning and more realistic commitments to stakeholders.

The engineering team reports higher job satisfaction. They no longer feel pulled between competing priorities because the process acknowledges and accounts for all their responsibilities. This has improved retention and made it easier to recruit new team members.

What started as a conflict over missed deadlines turned into an opportunity for positive change. By making work visible and establishing clear processes, we turned friction into collaboration. The team now delivers better results because everyone understands and respects the reality of their work.