Mastodawn

# Balancing Innovation with Maintenance Through Collaboration (1/41)

A manufacturing marketplace SME running FDD with a team of six to fifteen people has a balance problem. The company operates a B2B platform connecting small manufacturers with raw material suppliers. The platform handles supplier discovery, request for quotation, order management, logistics coordination, and payment processing. The company has been around for five years and has forty one employees. Nine of them are in product development. (2/41)

The team is stuck. Seventy percent of every iteration goes to maintenance. Bug fixes, server patches, database optimizations, dependency updates, security patches. The work is necessary. It is not optional. But it leaves only thirty percent for innovation. New features, new capabilities, new experiments. Thirty percent is not enough. (3/41)

The roadmap has twelve features planned. At the current rate, they will take eight months. The market is moving fast. Two competitors launched similar platforms in the last six months. They are adding features faster. They are attracting the company's customers. Last quarter, three manufacturers left the platform, citing lack of new features as the reason.

The team must find a balance. (4/41)

Masaru Ibuka built Sony on innovation through collaboration. His model was straightforward. He did not separate the innovators from the maintainers. There was no research and development team that invented things and an operations team that kept things running. There was one team that did both. (5/41)

The collaboration was structured around a rotation. Every engineer spent six months on innovation, then six months on maintenance, then six months on innovation again. The rotation was mandatory. It forced every engineer to understand both sides. The engineer who spent six months on maintenance understood the pain of maintaining a system without innovation. The engineer who spent six months on innovation understood the pain of building new features on a fragile system. (6/41)

That understanding created empathy. The empathy created collaboration. The collaboration created balance. (7/41)

Ibuka applied the same thinking to product development. When Sony developed the Walkman, the team that designed the hardware also wrote the firmware. The team that wrote the firmware also tested the manufacturing process. The team that tested the manufacturing process also designed the packaging. The collaboration eliminated silos, which eliminated handoffs, which eliminated delays. The Walkman was developed in eighteen months, half the industry average. (8/41)

For a manufacturing marketplace SME, the balance problem is the same. The team spends too much time on maintenance and does not have enough time for innovation. Ibuka's approach says: rotate the team between innovation and maintenance. The rotation creates empathy. The empathy creates collaboration. The collaboration creates balance.

## The Core Principle (9/41)

Ibuka's innovation through collaboration was built on a simple insight. The best way to balance innovation with maintenance is to rotate every engineer between both disciplines. The person who builds the feature also maintains it. The person who fixes the bug also understands why the feature was built that way. (10/41)

Ibuka did not separate Sony's hardware designers from its firmware writers. He made them collaborate. The collaboration produced the Walkman in eighteen months. For a manufacturing marketplace SME, the balance problem is the same. The team is stuck in maintenance mode. The answer is to rotate the team. The rotation creates empathy, the empathy creates collaboration, and the collaboration creates balance.

## Four Steps to Apply Innovation Through Collaboration (11/41)

1. Audit the Current Iteration to Quantify the Innovation Maintenance Split

Ibuka audited Sony's development process in 1953. The audit revealed that sixty percent of engineering time went to manufacturing support. That was maintenance. The remaining forty percent was for innovation. The audit quantified the split, created a baseline, and set a target to increase innovation time to fifty percent. (12/41)

Your team should do the same. For a manufacturing marketplace SME, the audit might look like this. The product manager leads a one hour session with all nine team members. The session reviews the last four iterations using tracking data. The data shows hours spent on each type of work: bug fixes, server patches, database optimizations, dependency updates, security patches, new feature development, user experience improvements, and performance optimizations for new features. (13/41)

The audit reveals the split. Iteration one: 112 maintenance hours, 48 innovation hours. That is seventy percent maintenance, thirty percent innovation. Iteration two: 105 maintenance hours, 55 innovation hours. Sixty six percent to thirty four percent. Iteration three: 118 maintenance hours, 42 innovation hours. Seventy four percent to twenty six percent. Iteration four: 98 maintenance hours, 62 innovation hours. Sixty one percent to thirty nine percent. (14/41)

The average split is sixty eight percent maintenance and thirty two percent innovation. The target is fifty percent. The gap is eighteen percent. That eighteen percent must be reclaimed from maintenance and redirected to innovation.

For an FDD team of six to fifteen, the audit should happen in one session of no more than one hour. It should review at least four iterations. For FDD, the audit should be part of the overall model review as a review input. (15/41)

2. Create a Six Month Rotation Schedule That Moves Every Engineer Between Innovation and Maintenance

Ibuka created a six month rotation schedule for Sony's engineers. It was published, visible, and mandatory. Every engineer knew when they would rotate. The rotation forced every engineer to experience both disciplines. The experience created empathy, the empathy created collaboration, and the collaboration created balance. (16/41)

You should create the same kind of schedule. For a manufacturing marketplace SME, it might look like this. The product manager creates a twelve month schedule with two phases. The nine engineers are divided into two groups. Group A has five engineers. Group B has four. (17/41)

During phase one, months one through six, Group A works on innovation. Their work includes a supplier recommendation engine, automated request for quotation, and real time logistics tracking. Group B works on maintenance: bug fixes, server patches, database optimizations, dependency updates, and security patches. (18/41)

During phase two, months seven through twelve, the groups rotate. Group A moves to maintenance. Group B moves to innovation. The rotation happens at the start of month seven. It is mandatory. (19/41)

The rotation creates empathy. Group A spent six months building the supplier recommendation engine. They know its architecture, its edge cases, and its failure modes. When they rotate to maintenance, they fix bugs in that engine faster. Last month, Group A fixed a bug that caused the engine to recommend suppliers with low quality ratings. The fix took two hours. Under the old process, it would have taken eight hours because the engineer would have needed to understand the engine first (20/41)

. The rotation created that understanding upfront.

The understanding reduces maintenance time. The reduced maintenance time creates capacity. That capacity is redirected to innovation.

For an FDD team of six to fifteen, the rotation schedule should cover twelve months with two six month phases. For FDD, the schedule should be part of the feature planning process as a planning input.

3. Pair an Innovator with a Maintainer on Every Feature to Build Shared Ownership (21/41)

Ibuka paired Sony's hardware designers with firmware writers on every product. The pairing was mandatory. It forced collaboration, produced shared ownership, eliminated silos, eliminated handoffs, and eliminated delays. (22/41)

You should pair an innovator with a maintainer on every feature. For a manufacturing marketplace SME, the pairing might look like this. The product manager creates a pairing matrix that matches every innovation engineer with a maintenance engineer based on complementary skills. (23/41)

Pair one: Priya, an innovation backend developer who built the supplier recommendation engine, is paired with Tom, a maintenance backend developer who fixed the low quality rating bug. They work together on the next feature, automated request for quotation. Priya designs the feature. Tom reviews it. Tom asks what happens if a supplier does not respond within twenty four hours. Priya says the system sends a reminder. Tom asks what happens after three reminders (24/41)

. Priya says the system escalates to the manufacturer. Tom asks what happens if the escalation fails. Priya says the system logs the failure and notifies the account manager. Tom's questions improve the design and reduce future maintenance. (25/41)

Pair two: Lena, an innovation frontend developer who built the real time logistics tracking dashboard, is paired with Sam, a maintenance frontend developer who fixed the dashboard's memory leak. They work together on a mobile app for manufacturers. Sam asks what happens if a manufacturer loses internet connectivity while placing an order. Lena says the app queues the order and sends it when connectivity is restored (26/41)

. Sam asks what happens if connectivity is not restored within twenty four hours. Lena says the app notifies the manufacturer and offers to send the order via SMS. Again, the questions improve the design and reduce future maintenance.

Every innovation engineer is paired with a maintenance engineer. The pairing builds shared ownership, reduces future maintenance, and creates capacity for innovation. (27/41)

For an FDD team of six to fifteen, every feature should have a pair consisting of one innovation engineer and one maintenance engineer. The pairing should be mandatory and part of the feature design process.

4. Run a Monthly Feedback Loop Where Maintainers Tell Innovators What Is Hard to Maintain (28/41)

Ibuka ran a monthly feedback loop at Sony. It was a one hour meeting, mandatory, attended by all engineers. The agenda had one item: what is hard to maintain. Maintainers told innovators. Innovators listened, took notes, and changed their designs. The changes reduced future maintenance and created capacity for innovation. (29/41)

You should run the same kind of loop. For a manufacturing marketplace SME, it might look like this. The product manager runs a one hour meeting on the last Friday of every month. All nine engineers attend. The agenda is one item: what is hard to maintain. (30/41)

Last month, Tom said the supplier recommendation engine is hard to maintain. It uses a machine learning model trained on historical data that changes every week. The model must be retrained weekly. Retraining takes four hours, is manual, and is error prone. The errors cause bugs. The bugs cause maintenance work. That work consumes capacity that should go to innovation. (31/41)

Priya did not know the retraining was manual. She committed to automating it. The automation will take two days and will eliminate the manual retraining, the bugs, and the maintenance overhead.

Sam said the real time logistics tracking dashboard is hard to maintain. The WebSocket connection drops every thirty minutes, causing the dashboard to freeze. The freezes cause customer complaints, which cause support tickets, which cause maintenance work. (32/41)

Lena did not know the connection dropped every thirty minutes. She committed to adding a reconnection mechanism. It will take one day and will eliminate the freezes, the complaints, and the maintenance work.

The feedback loop produced two action items: automate the model retraining and add the WebSocket reconnection mechanism. Both are added to the next iteration. Both will reduce maintenance and create capacity for innovation. (33/41)

For an FDD team of six to fifteen, the monthly feedback loop should happen on the last Friday of every month. It should be one hour and mandatory. For FDD, it should be part of the feature review process.

## Closing on Rotated Over Siloed (34/41)

Masaru Ibuka did not build Sony by letting hardware designers design, firmware writers write, and the manufacturing team manufacture, then hoping the three groups would figure out how to work together. He built it by auditing the development process and discovering that sixty percent of engineering time went to manufacturing support (35/41)

. He created a six month rotation schedule that moved every engineer between innovation and maintenance so that the person who designed the hardware also wrote the firmware and the person who wrote the firmware also tested the manufacturing process. He paired every hardware designer with a firmware writer on every product so that the designer understood the firmware constraints and the writer understood the hardware intent (36/41)

. He ran a monthly feedback loop where the manufacturing team told the designers what was hard to manufacture, and the designers changed their designs to reduce complexity. (37/41)

For a manufacturing marketplace SME running FDD with a medium team of six to fifteen, balancing innovation with maintenance requires the same approach. Audit the current iteration by reviewing the last four iterations and discovering that the average split is sixty eight percent maintenance and thirty two percent innovation (38/41)

. Create a six month rotation schedule that divides the nine engineers into two groups and rotates them so that the people who built the supplier recommendation engine also fix its bugs in a fraction of the time. Pair every innovation engineer with a maintenance engineer on every feature so that tough questions get asked early and future maintenance gets designed out. Run a monthly feedback loop where maintainers surface the real pain points and innovators commit to fixing them. (39/41)

Start by having your product manager lead a one hour iteration audit session this week. Publish the six month rotation schedule and the pairing matrix next week. Your forty one employee company can increase innovation time from thirty two percent to fifty two percent within six months (40/41)

. Not by hiring more people or working longer hours, but by learning from a consumer electronics pioneer who proved that the best way to balance innovation with maintenance is to stop separating the innovators from the maintainers and start rotating them so that everyone understands both sides.

#SoftwareEngineering #FeatureDrivenDevelopment #Innovation #Maintenance #TeamCollaboration #DevOps #EngineeringManagement #AgileDevelopment #TechLeadership #ProductDevelopment (41/41)