5 reflections to help you discover why hiring more software developers may not accelerate your development velocity
You’ve grown your development team, taken on more developers and QA testers with the expectation that you can keep up your current pace of development as your product gets larger and more complex. You may even want to accelerate your product development to beat your competitors to the market—but you’re quickly finding out that adding more headcount hasn’t exactly improved your development velocity. For some organizations, adding headcount has actually slowed down development.
In our experience as seasoned dev and QA consultants, development leaders often find themselves stuck in a cycle of managing existing code rather than innovating—spending time fixing bugs, refactoring outdated components, maintaining legacy systems, and addressing technical debt instead of focusing on new feature development. and any new resources are quickly sucked into keeping up with code maintenance and overhead, especially in testing and QA. If adding a single new feature spawns hundreds of new test cases, adding more developers is unlikely to help.
Here are five extremely direct (and sometimes uncomfortable) questions you should ask yourself and your team to understand why your increased headcount hasn’t improved development velocity:
How much time are you spending testing in the current release compared to the previous one? What about the one before that? This should give you insight into the growth of test scenarios specific to your software product.
Are your development teams spending more time on managing debt than building new features? Is tech debt, and working around it, causing you to burn valuable and unnecessary resources?
Have you asked project managers to take on additional processes to relieve overhead from your coders and testers? When we see non-technical folks managing technical processes, that’s a sign of unsustainable overhead.
Have you missed a release or extended your release cycle in the last 12 months? If so, why? You may discover that while you may have planned sufficient development time. Manual testing, which can be time-consuming and prone to human error, often leads to uncaught bugs and errors. This creates bottlenecks in the release process, delaying deadlines or forcing last-minute feature cuts to accommodate unexpected issues.
Is your QA team testing absolutely everything—from start to finish—including all boundary cases that have rarely or never occurred? Is comprehensive testing of every boundary case necessary?
We’ve created a reflection guide for software leaders to critically examine their business, with real, practical question prompts that we use with our own clients. Download our reflection guide today and take the first step toward streamlining your dev and QA automation in 2025.