When I was in college, I sang with the University of Hawaii chorus in a performance of Verdi’s Requiem with the Honolulu Symphony under conductor Samuel Wong.
We had spent months learning the music and the Latin. By the time we rehearsed with the orchestra, we could sing it cleanly, precisely, and beautifully.
During the Dies Irae, Wong stopped us.
We were singing it too pretty.
I was astounded. We had worked hard to make the chorus sound polished. But the movement describes terror, judgment, and a soul experiencing hell. Precision was not the problem. The problem was that our precise performance did not serve the music.
Wong wanted us rougher, louder, and more desperate.
In his words, “we should sound like hell!”
That is what a good conductor does. He understands the piece, the purpose of the performance, and the result the sponsoring organization expects. Then he gets the best performance from the people in front of him in service of that result.
A development manager has the same responsibility.
The Product Is the Piece of Music
The development manager is responsible for understanding the product and the goals of the business, then getting the best from each developer in service of both.
A conductor does not play every instrument. The conductor remains accountable for the performance.
This is not passive empowerment. The manager is not there to tell every developer to follow their interests and hope the individual parts combine into a useful product. The manager has to understand the user need, the delivery constraints, the technical risks, and the quality required. Then the manager shapes how the team’s abilities come together.
Sometimes the product needs technical elegance. Sometimes it needs speed. Sometimes it needs the database specialist to lead. Sometimes it needs that specialist to teach someone else so the system does not depend on one person forever.
The manager is not responsible for producing the most technically pristine performance.
The manager is responsible for producing the performance the product requires.
Beautiful code that never ships is a failed performance. Clean architecture that does not meet the user’s need is technically accomplished and functionally wrong. Engineering craft matters, but it has to serve the piece.
Learn the Performers
I began applying this idea to software leadership in 2007 at a woodworking tool manufacturer.
Developers were not interchangeable. One developer had unusual database ability and a genuine passion for the work. Other developers could work with databases, but it was not where their interest or strongest competency lived.
Understanding that difference allowed me to route critical work toward the strongest available developer. It also allowed me to use that strength to grow the rest of the team.
When a developer had real competency or passion in an area, that person could serve as the technical lead for the work. They shaped the implementation, helped other developers understand the domain, and raised the quality of the people working alongside them.
The role was not a permanent claim on part of the codebase. Expertise should create leverage, not an island. The specialist led where their strength mattered, while the team learned enough to share ownership and support the result.
I remained accountable for the product. My job was to ensure the work served the roadmap, met the user’s needs, and shipped. The technical lead helped determine how we should build it. I remained responsible for why we were building it and whether the combined performance succeeded.
That is orchestration.
The Playbook Became Repeatable
The same operating model has shaped several team turnarounds since then. The companies and products changed. The systemic problems were remarkably consistent.
Developers worked on islands. Planning ignored real capacity. Stories were too large to finish. Unplanned work was invisible. Specialists accumulated private ownership of critical systems. Managers responded by asking for more status, applying more pressure, or monitoring individual output more closely.
Those actions created the appearance of control without improving the performance.
My playbook focused on the system around the developers:
- Build shared ownership so expertise can move through the team.
- Plan against actual capacity instead of aspirational commitments.
- Break work into units that can be completed and shipped.
- Make unplanned work visible.
- Give developers standards, context, and room to collaborate.
- Measure the performance of the system instead of relying on impressions.
This did not remove accountability. It made accountability useful. Developers knew the product goal, the expected quality, the work in front of them, and how their contribution fit with everyone else’s.
The results repeated across three organizations.
At a financial services SaaS provider, sprint completion had averaged 39%. The first sprint under the new practices reached 86%, and the team averaged 85% across the next 11 sprints. Team happiness rose from 5.5 out of 10 to 10 within six weeks.
At a healthcare SaaS provider, the team completed 63 releases in 52 weeks, including incremental delivery of a major reporting dashboard.
At a marketing services SaaS provider, injected work fell from 145% of committed work to 19%. As the operational burden dropped, feature work grew from 39% to 62% of sprint capacity.
The playbook is standardized because the problems recur. When teams are fragmented, work is oversized, priorities churn, and invisible interruptions consume capacity, the intervention becomes familiar.
The manager does not need a more forceful personality.
The team needs a better arrangement.
Conduct the Performance
Samuel Wong did not tell the chorus that precision was worthless. He told us our precision was producing the wrong performance.
That distinction has stayed with me.
A development manager should care about clean code, good architecture, strong testing, and technical growth. None of those exists outside the product. The manager has to understand when perfection serves the work and when it pulls the team away from the result.
Learn what each developer can do. Give strong performers room to lead. Use their expertise to teach others. Challenge people beyond the parts they already play well. Arrange the work so individual strengths become team capability.
Then keep the entire performance pointed toward the product, the business, and the user.
That is the job.
Receipts
- Origin of the metaphor: While singing Verdi’s Requiem with the University of Hawaii chorus and Honolulu Symphony, Sean watched conductor Samuel Wong redirect a technically polished Dies Irae toward the terror and emotional purpose of the movement.
- Financial services SaaS provider: Sprint completion rose from a 39% baseline to 86% in the first sprint and averaged 85% across the next 11 sprints. Team happiness rose from 5.5 to 10 within six weeks.
- Healthcare SaaS provider: The team completed 63 releases in 52 weeks while incrementally delivering a major reporting dashboard.
- Marketing services SaaS provider: Injected work fell from 145% to 19%, while feature work increased from 39% to 62% of sprint capacity.
- Musical context: The Cleveland Orchestra’s guide to Verdi’s Requiem describes the recurring Dies Irae through the chorus’s force against the full orchestra and the terror added by the percussion.