Two Seniors, One Architecture
You manage a nine-month integration project with a fixed deadline. Your senior solution architect has 14 years in the organisation and designed the current platform; your lead developer joined six weeks ago from a consultancy with a strong microservices record. They disagree on the target architecture: the architect wants to extend the existing monolith, the lead developer says that will not meet the performance figure in the non-functional specification. Design reviews now overrun, the team has split into two camps, two developers have asked to be reassigned, and the architect has begun skipping reviews. You are in month 3, the budget is 8% over, and you have no technical authority over either of them. The steering group wants one architecture signed off in three weeks.
1. Before you intervene, what do you need to establish about this conflict?
Read the worked answer
Diagnose first: is this a task conflict or a relationship conflict wearing a task conflict's clothes?
They are disagreeing about technical fit to a requirement - that is a legitimate task conflict and can be healthy. What is damaging is the escalation: camps, reassignment requests, skipped reviews. That is relationship and process damage layered on top.
The critical diagnostic question: is the performance requirement in the non-functional spec quantified and testable?
- If yes, this is resolvable by evidence, and my job is to force the evidence into the open rather than pick a side I am not qualified to pick.
- If it is vague ("must be responsive"), then both are arguing about an untestable requirement, and the real fix is to get the requirement sharpened - which is a project management failure, not theirs.
I would also check whether the lead developer's arrival has been experienced by the architect as an implicit judgement on 14 years of work. That is usually the emotional core, and naming it privately costs nothing.
2. What intervention do you run, and what do you deliberately not do?
Read the worked answer
Run a structured technical evaluation; keep behavioural issues separate.
Process (two weeks):
- Ask each to produce a one-page option: how it meets the performance figure, cost, schedule impact, key risk, and what would have to be true for the other option to be better.
- Commission a time-boxed spike or benchmark (two to three days, small cost) against the actual performance requirement. Evidence beats seniority.
- Chair the session yourself. You own the process and the decision date; they own the technical content.
Two private conversations:
- With the architect: skipping design reviews is not an acceptable way to register disagreement, whatever the merits. That is a behavioural expectation, stated once, clearly.
- With the lead developer: how the challenge is made matters as much as whether it is right - route it through the review, not around it.
Deliberately not doing: adjudicating the technical merits myself, splitting the difference to keep the peace, or reassigning either person as a first resort. All three destroy credibility and lose capability you cannot replace in month 3.
3. The sign-off date is in three weeks and they are still deadlocked. What now?
Read the worked answer
Escalate the decision, not the conflict.
- Take both options, the benchmark results and an explicit risk statement to a named technical authority - enterprise architect or CTO - with a decision date and an agreement in advance that both parties will implement the outcome.
- Record the decision, the rationale, and who owns the residual risk. If the authority picks the monolith despite the performance evidence, the performance risk is now explicitly accepted by that person, not silently absorbed by the project.
- Protect the date in parallel: identify the parts of the build that are architecture-independent (data model, interfaces, test harness) and start them now. A three-week architecture debate should not idle nine people.
- Re-baseline expectations with the steering group honestly: the 8% overspend is partly rework and partly decision latency. Say which.
What I would resist: a "you do your bit, he does his" compromise that produces two half-architectures and defers the same argument to integration testing, where it costs ten times as much to resolve.