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 because 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. Our precise performance did not serve the music.
Wong wanted us rougher, louder, and more desperate. In his words, “we should sound like hell!” A good conductor understands the piece, the purpose of the performance, and the result the sponsoring organization expects, then 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, but remains accountable for the performance. Management is not passive empowerment: the manager must understand the user need, delivery constraints, technical risks, and required quality, then shape how the team’s abilities come together.
Sometimes the product needs technical elegance, speed, a database specialist to lead, or that specialist to teach someone else so the system does not depend on one person forever. The manager is responsible for producing the performance the product requires. Beautiful code that never ships is a failed performance, and clean architecture that does not meet the user’s need is technically accomplished and functionally wrong. Engineering craft 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, while others could work with databases but did not have the same interest or strongest competency.
Knowing that let me route critical work to the strongest available developer and use that strength to grow the rest of the team. Someone with real competency or passion could serve as technical lead, shaping the implementation, helping others understand the domain, and raising the quality of the people working alongside them. Expertise should create leverage, not an island, so the team learned enough to share ownership and support the result.
I remained accountable for whether 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, but the systemic problems were remarkably consistent: developers worked on islands, planning ignored real capacity, stories were too large to finish, unplanned work was invisible, and specialists accumulated private ownership of critical systems. Managers responded by asking for more status, applying more pressure, or monitoring individual output more closely, creating the appearance of control without improving 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.
The playbook 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 team needs a better arrangement, not a manager with a more forceful personality.
Conduct the Performance
Samuel Wong did not tell the chorus that precision was worthless. He told us our precision was producing the wrong performance, and 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. 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, and arrange the work so individual strengths become team capability.
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.