Project Leadership Styles: Are you a Conductor OR Soloist?

In the world of project management, there’s no shortage of project leadership styles to choose from. From the servant leader to the transformational leader, from agile coaches to scrum masters – the profession has spawned more role definitions than you can shake a Gantt chart at. However, when it comes to the day-to-day reality of delivering projects, particularly in the professional and financial services sectors, I believe there are two fundamental approaches that capture how most of us actually work: the Conductor and the Soloist.

The Conductor stands at the front, orchestrating every section of the project team, ensuring harmony between different departments and keeping everyone in perfect time. The Soloist, meanwhile, steps forward from the orchestra, taking centre stage not just to coordinate but to demonstrate mastery of their craft whilst still keeping the broader performance on track.

Both approaches to project leadership have their place, and understanding when to use each can make a big difference to the overall success of the project.

The Conductor: Master of the Big Picture

Picture Sir Simon Rattle conducting the London Symphony Orchestra. He doesn’t play every instrument, but he understands how each section contributes to the whole. He knows when the strings need to come in, when the brass should build to crescendo, and how to bring all those individual talents together into something greater than the sum of its parts.

This is the traditional project manager – the person who coordinates, facilitates, and orchestrates without getting their hands dirty in the technical details. In financial services, this might be someone managing the implementation of a new core banking system across multiple departments, ensuring that IT, Operations, Risk, and Compliance all work in harmony.

Where the Conductor Approach Excels

The conductor’s greatest strength lies in maintaining perspective. When you’re managing a project team of 20+ people across five different departments, someone needs to keep their eye on the big picture. The conductor excels at:

Stakeholder Management: In larger firms, project success often depends more on managing personalities and politics than technical complexity. The conductor PM becomes expert at translating between the Chief Risk Officer’s regulatory concerns, the Head of Operations’ efficiency demands, and the IT Director’s technical constraints.

Resource Juggling: On complex implementations, resources are constantly shifting. The data migration team finishes early whilst the testing team hits unexpected issues. The conductor PM can quickly reallocate people and budget to keep everything moving forward without getting bogged down in the technical reasons why things went wrong.

Communication Orchestration: Large projects generate enormous amounts of information. The conductor PM becomes a master of synthesis, distilling complex technical progress into clear business updates for the board, whilst ensuring that detailed technical coordination continues smoothly between teams.

Risk and Issue Management: By staying above the technical fray, conductor PMs often spot risks that specialists miss. They notice when the integration team’s delays will impact the parallel training programme, or when the vendor’s latest change request will blow the budget even if it solves a technical problem.

Consider a recent example from a mid-tier investment firm implementing a new portfolio management system. The project involved integrating with existing trading platforms, updating client reporting, retraining relationship managers, and ensuring compliance with FCA regulations. The project manager took a pure conductor approach – they couldn’t code the API integrations or design the new reports, but they could ensure that when the compliance team identified regulatory requirements, those were communicated clearly to the technical team, and that when the technical team hit roadblocks, business priorities guided the solutions.

The result? The project delivered on time and budget because someone was constantly watching the interdependencies and ensuring that technical decisions served business objectives rather than just solving technical problems.

The Conductor’s Blind Spots

However, the conductor approach has significant limitations, particularly in smaller organisations where project teams might be just 3-5 people and technical complexity can be hiding in plain sight.

The biggest risk “dashboard delusion” epitomised by beautiful status reports that mask underlying problems. When your technical lead reports that data migration is “80% complete,” how do you know whether that means eight out of ten straightforward tables, or eight simple tables with the two most complex ones still to come?

Without technical depth, conductor PMs can struggle with:

Vendor Management: Technology vendors are notorious for overselling and under-delivering. A conductor PM might accept vendor assurances about system capabilities that a more technical PM would immediately question based on experience.

Realistic Estimation: When the development team says a seemingly simple change will take two weeks, the conductor PM lacks the context to know whether this is reasonable or whether someone’s padding their estimates.

Technical Risk Assessment: Some risks only become apparent when you understand the technical implications. The seemingly minor change to how client data is classified might have major implications for regulatory reporting that aren’t immediately obvious.

The Soloist: Leading from the Front

Now imagine Nicola Benedetti performing a violin concerto with the BBC Symphony Orchestra. She’s not conducting in the traditional sense, but she’s absolutely leading the performance. Her musical expertise elevates the entire orchestra whilst she simultaneously delivers a world-class individual performance.

This is the consultant-style project manager – someone who brings deep domain expertise to their projects whilst maintaining overall project leadership responsibilities. In financial services, this might be someone with extensive experience implementing payment systems who can engage in detailed technical discussions whilst keeping the project on track.

The Power of Domain Expertise

The soloist approach transforms the PM from coordinator to trusted adviser. When you’ve implemented half a dozen payment platforms, you immediately understand why the proposed system design won’t handle the complexity of multiple banks with differing mandates, or why the suggested reporting approach will fall apart when the auditors arrive.

This expertise delivers value in several critical ways:

Early Risk Detection: Domain knowledge allows you to spot problems before they become crises. You know that the vendor’s standard chart of accounts structure won’t work for a firm that trades derivatives, or that their “standard” reconciliation process will take six hours instead of thirty minutes with your client’s transaction volumes.

Vendor Credibility: Technology vendors respond differently to PMs who can engage in detailed technical discussions. When you can ask specific questions about database partitioning strategies or API response times, vendors quickly realise they can’t fob you off with marketing speak.

Accelerated Decision Making: Instead of facilitating lengthy technical discussions, the soloist PM can often cut straight to the heart of issues. Having seen similar problems elsewhere, they can guide teams toward proven solutions or away from approaches that look good on paper but fail in practice.

Value Engineering: Domain expertise allows you to identify opportunities that weren’t in the original scope. Perhaps the new system’s workflow capabilities could streamline the client onboarding process, or its reporting tools could replace several manual procedures that currently take days each month.

A good example comes from a recent project at a wealth management firm implementing a new client portal. The PM had extensive experience with similar systems and immediately identified that the proposed user authentication approach wouldn’t work with the firm’s existing identity management system. Rather than discovering this during technical build (which would have caused significant delay), the issue was resolved during design, saving both time and money whilst delivering a better solution.

When Expertise Becomes a Trap

The soloist approach’s greatest strength can also become its greatest weakness. Deep domain knowledge can lead to several traps that can derail even the most well-intentioned projects:

The Detail Rabbit Hole: It’s incredibly tempting to dive into technical architecture discussions when you have the knowledge to contribute meaningfully. However, whilst you’re debating database indexing strategies, project timelines might be slipping, stakeholders might be losing confidence, and budget burn rates might be spiralling out of control.

Premature Solution Convergence: Experience can lead to assumptions. You might immediately recognise a problem as similar to something you’ve solved before and guide the team toward your preferred solution without fully exploring alternatives that might be more appropriate for this specific context.

Scope Creep Facilitation: When you understand that a “simple” report change actually requires significant data model modifications, you might be more willing to accommodate the request rather than pushing back on scope. Your knowledge makes additional complexity seem manageable when it should be questioned.

Resource Dependency: Teams can start using the PM as a subject matter expert rather than developing their own capabilities. This might accelerate short-term progress but creates longer-term risks and reduces knowledge transfer to the people who’ll actually support the system once it’s live.

Finding the Right Balance: Practical Strategies

The key to successful soloist-style project leadership lies in maintaining clear boundaries between PM and technical expert responsibilities. Here are some practical approaches I’ve developed:

Time Boxing Technical Involvement

Protect time for traditional PM activities whilst allowing focused technical engagement. I typically reserve mornings for stakeholder management, progress reporting, and strategic planning, then allow focused technical deep-dives in the afternoon. This ensures project fundamentals don’t suffer whilst leveraging domain expertise where it adds most value.

The “Two Hat” Approach

Explicitly communicate when you’re switching between PM and technical adviser roles. In meetings, I’ll often say “Setting aside the project management view for a moment, from a technical perspective…” This helps teams understand when you’re providing expert input versus project direction.

Delegate and Validate

Rather than doing technical analysis yourself, delegate it to team members whilst using your expertise to validate outputs. Ask the integration specialist to assess performance requirements, then review their analysis against your experience. This develops team capabilities whilst ensuring technical soundness.

Business Translation

Use domain expertise to provide richer context in stakeholder communications. Instead of reporting “Testing is 60% complete,” explain “We’ve validated standard processing, and we’re now testing the complex scenarios that handle 30% of transactions but represent 70% of the technical risk.”

Small vs Large Project Leadership

The choice between conductor and soloist approaches often comes down to project context, and nowhere is this more apparent than in the difference between large and small financial services organisations.

Large Organisations: The Case for Conducting

In major banks or insurance companies, projects often involve:

• Teams of 20+ people across multiple departments
• Complex stakeholder hierarchies with competing priorities
• Extensive regulatory and compliance requirements
• Multiple technology systems that need to integrate
• Significant political and cultural change management

Here, the conductor approach often works better. The sheer complexity of coordination typically outweighs the benefits of technical expertise. You need someone whose primary job is keeping all the moving parts aligned.

Take a recent core banking replacement at a high-street bank. The project involved IT, Operations, Customer Service, Marketing, Risk, Compliance, and Legal teams. The PM’s day was spent managing dependencies between these groups, escalating decisions to senior management, and ensuring that technical solutions served business needs. Deep technical knowledge would have been nice to have, but the project’s success depended primarily on coordination and communication.

Small to Medium Organisations: The Soloist’s Stage

Smaller financial services firms present different challenges:

• Leaner project teams (often 3-7 people)
• Limited specialist resources
• Direct access to decision makers
• Greater flexibility but less formal process
• Higher impact of individual technical decisions

Here, the soloist approach often delivers superior results. With fewer people involved, coordination complexity is lower, but technical complexity per person is often higher. The PM’s domain expertise can make the difference between success and failure.

Consider a boutique investment management firm implementing a new portfolio management system. The project team consisted of the PM, a developer, a business analyst, and the head of operations. The PM’s deep knowledge of portfolio management systems allowed them to:

• Spot immediately when the vendor’s proposed data model wouldn’t handle the firm’s complex derivative instruments
• Guide technical decisions based on experience with similar implementations
• Identify process improvements that weren’t in the original scope but delivered significant value
• Provide realistic timelines based on understanding the true technical complexity

The result was a project that delivered early, under budget, and with additional functionality that significantly improved the firm’s operations.

The Future of Project Leadership

As financial services technology becomes increasingly complex, I believe the most successful project managers will develop the judgement to switch between conducting and soloist modes as project needs evolve.

The pure conductor approach works when coordination complexity outweighs technical complexity. The soloist approach excels when technical expertise can materially impact outcomes and when team sizes allow for hands-on involvement.

However, the key insight is that these aren’t mutually exclusive career paths. The best project managers develop both capabilities and learn to recognise which approach serves their project best.

For those of us working primarily with small to medium financial services firms, I’d argue that the soloist approach offers greater value in most situations. The technical complexity of modern financial systems, combined with leaner project teams and direct stakeholder access, creates an environment where domain expertise can directly impact project outcomes.

But this only works if you maintain the discipline to step back from the technical detail when project leadership requires it. The goal isn’t to become a subject matter expert who occasionally manages projects, but to become a project manager whose subject matter expertise enhances their effectiveness.

Conclusion: Choosing Your project leadership Style

Whether you’re a conductor orchestrating complex stakeholder relationships or a soloist leading through expertise, the fundamental goal remains the same: delivering projects that meet business objectives, on time, within budget, and with minimal disruption to ongoing operations.

The choice between these approaches shouldn’t be ideological but practical. Look at your project context, team size, stakeholder complexity, and technical risk profile. Consider your own strengths and the value you can add beyond pure project management.

Most importantly, remember that both approaches require mastery of fundamental project management principles. Whether you’re conducting or performing solo, you still need to understand scope, time, cost, quality, risk, and stakeholder management.

The difference lies not in abandoning these fundamentals, but in how you apply them. The conductor uses them to coordinate others; the soloist uses them whilst directly contributing to project outcomes.

In my experience working with financial services firms across the spectrum, both approaches can deliver exceptional results. The key is choosing the right style for your context and having the courage to perform it with conviction.

After all, whether you’re conducting the London Philharmonic or performing a solo at the Albert Hall, success ultimately depends on understanding your audience, mastering your craft, and delivering a performance that exceeds expectations.

The stage is yours – how do you choose to lead?

If you’re grappling with a complex project and wondering whether you need a conductor to orchestrate your stakeholders or a soloist to navigate the technical complexities, I’d be happy to discuss your specific challenges. With extensive experience in ERP implementations and business change projects across organisations of all sizes, I can help you determine the right leadership approach for your project’s unique context. Get in touch to explore how we can ensure your next implementation hits all the right notes.

P.S. If you want to review the leadership style of a current project check out my Project Health Check Tool which is a great way to self-assess projects within your organisation.