{"id":3785,"date":"2026-08-06T09:00:51","date_gmt":"2026-08-06T07:00:51","guid":{"rendered":"https:\/\/getnave.com\/blog\/?p=3785"},"modified":"2026-08-06T15:07:20","modified_gmt":"2026-08-06T13:07:20","slug":"team-structure-mistake-delivery","status":"publish","type":"post","link":"https:\/\/getnave.com\/blog\/team-structure-mistake-delivery\/","title":{"rendered":"How to Unleash the Power of Your Highly Specialized Team (Using a Simple Process Policy)"},"content":{"rendered":"
<\/div>\n

If you\u2019ve been managing highly specialized teams, you\u2019ll certainly have seen how specialization dictates the priority of the work. Worse yet, it often creates road blocks preventing your team from delivering results quickly and efficiently.<\/p>\n

The fact is, specialization decreases flow. And the combination of specialization and significance within a team can be a particularly devastating one.<\/p>\n

Today, we\u2019ll explore how specialization affects your overall performance. And If this is something that impacts your business outcomes, I\u2019ll give you some actionable advice (that you can apply as early as tomorrow morning!) to address this challenge.<\/p>\n

The Dilemma<\/h2>\n

Let\u2019s analyze the following scenario. This is the Aging Chart<\/a> of a development team of one designer, 2 front-end developers, 2 back-end developers and one QA specialist. Their process consists of the following states: Development, Code review, Code review (Done), Testing, Testing (Done) and Deployment.<\/p>\n

\"Specialization:<\/a><\/p>\n

This team has implemented a Kanban pull system<\/a>. All their \u201cDone\u201d states are queue states. These states are used to communicate that the work is ready to move on to the next state.<\/p>\n

The CONWIP of the system is 10 work items. CONWIP refers to constant work in progress or simply put, the max number of work items in progress that are allowed to stay in the system at any one time.<\/p>\n

At the current moment, there are 5 cards in Code Review (Done) waiting to be handled in the Testing state.<\/strong> No one is working on them, they are just sitting and aging in the process. The team is currently working on 8 work items in total, so they actually have the capacity to handle 2 more tasks.<\/p>\n

Now, my question to you is: \u201cShould the team start new work in this situation?\u201d. They still have two more slots free before they reach the WIP limit of the system. As the developers have the capacity to do more work, should they pull new tasks into the Development state?<\/p>\n

Your Delivery Rate Has Been Limited<\/h2>\n

Here\u2019s what\u2019s actually happening. There is a ridiculous bottleneck in the Testing state. It\u2019s obvious that the QA specialist is not able to handle all the work that has been produced by the developers.<\/p>\n

The results? The team can only deliver at the speed of the slowest step in the process – the testing phase. The team\u2019s performance is now limited by the performance of the testing state.<\/p>\n

So, given this perspective, would you say it makes sense to start new work? Would that action make any difference to the delivery rate of the system, or rather, wouldn\u2019t piling more and more work items in front of the Testing state make the problem worse?<\/p>\n

The best approach for handling this scenario is to stop starting and take people who have the most availability and allow them to make a contribution to the work of the people who have the least availability. This will soon enable the flow of work to resume.<\/p>\n

<\/div>\n

Calling Back-up<\/h2>\n

Let\u2019s put the pedal to the metal. Would a developer be capable of testing? Does the developer actually have the skills<\/strong> to help with testing?<\/p>\n

Yes, and if they don\u2019t, the difference between the skills they have now and what they need to have is probably narrow.<\/p>\n

Of course, to make this work, there must be some rules applied. For example:<\/p>\n