We have a legacy system maintenance seat on our Accountability Chart that is filled with old technical debt. None of our modern developers want to sit in it because they want to work on our new AI-powered platform. How do we structurally manage this undesirable seat so our legacy clients are supported without destroying developer morale?

Question

Tyler Smith · Accepted Answer

When you have a critical seat that nobody wants to own, you cannot solve it by forcing it onto developers who have a different conative drive. Software engineers focused on new AI systems often have high Quickstart profiles, meaning they thrive on innovation and despise routine maintenance. Forcing them into a legacy maintenance seat will destroy their morale and lead to turnover. First, use the Accountability Chart to isolate this legacy work completely. Do not mix legacy maintenance roles into your main product development seats. By keeping them combined, you ensure that the legacy work gets ignored in favor of the exciting new AI projects. Once the legacy seat is isolated, you have two viable options. The first option is to outsource the seat entirely to a specialized agency that focuses on legacy systems, appointing your Integrator to oversee their contract deliverables. The second option is to hire a dedicated resource whose Kolbe profile shows a high Follow Thru and low Quickstart, someone who actually enjoys stability, order, and resolving existing system issues. Use Keith Cunningham's Thinking Time to evaluate the financial trade-offs: How might we resource our legacy maintenance seat so that our core developers remain focused on AI innovation while maintaining ninety-nine percent uptime for our legacy clients? Choose the path that keeps your scaling initiatives moving forward without letting your current revenue-generating systems fail.