I recently finished The Culture Code by Daniel Coyle, and one of the final points was a flash of clarity for me. Coyle contrasts leading for proficiency where consistent task-based execution is key, and leading for creativity where a team discovers and builds original ideas.

Leading for proficiency

• Best for repetitive task-based execution.
• Examples: restaurants, flight crews, sports teams.
• Leaders should reiterate vivid examples of good behaviors and fundamental skills, “if X then Y” mantras. Celebrate when the team does the fundamentals well.
• Feedback is frequent and direct: “find ways to delight the customer”, “always hustle back for defense”.
• Since the feedback cycle is quick (minutes or hours), team members can immediately apply feedback and practice.

Leading for creativity

• Best for discovering and building original projects.
• Example: Ed Catmull’s teams at Pixar and Disney.
• Leaders should focus on team composition, interactions. Ensure it’s safe to fail and protect the team’s autonomy. Feedback is a gentle nudge or suggestion rather than an explicit command.
• Celebrate when the team tries something novel.
• The feedback cycle is slower, possibly weeks or months. This implies that some ideas will inevitably prove unviable after investing significant resources. Don’t seek to eliminate that waste, instead ensure the team will continue to take risks.

In software development, there is the need for both proficiency when scaling, securing, and debugging systems, and creativity in discovering effective products.

I’ve subconsciously gravitated towards a “proficiency” style of leadership, perhaps due to my sysadmin / operations background, or because I like the reinforcement of a fast feedback loop.

This distinction hit home for me because some of my most confusing discussions with coworkers can be characterized as the misalignment of these leadership styles. When a system was crashing a lot, a colleague advocated “we should give this team air cover while they discover a solution themselves”, and I’d say, “We already have a process for solving bugs like this. Can they please follow the checklist?” It was a recipe for talking past each other, and in retrospect, we should have first aligned on whether this was about teaching proficiency, or supporting creativity.

The difference in feedback speed jumps out as the most significant structural detail, and reminds me of Donella Meadow’s insight about systems:

“A delay in a balancing feedback loop makes the system likely to oscillate.” - Thinking in Systems, page 54 (pdf).

The delayed feedback of the creative projects makes feast-or-famine oscillations likely, especially paired with the direct “do this, don’t do that” feedback that works well in proficiency domains. In creative projects, knowing which conventions to bend and break is where the magic happens (and value’s created). Air cover and gentle nudges from leaders prevent overcorrection (and dampen oscillations) and support self-aware risks.

I appreciate that The Culture Code helped me understand the difference so I can blend and apply both styles in the future.