Communicating with Engineers
Earning technical credibility and giving guidance that engineers act on — which depends more on how the reasoning is shared than on whether it is correct.
Definition
Most architectural influence is exercised over people who do not report to the architect. The skill is producing agreement rather than compliance, because compliance without agreement produces a design implemented in letter and defeated in spirit.
What earns credibility
- Having built things, and being willing to look at code. An architect who cannot read the codebase is advising on a system they do not understand.
- Being specific. "Add a bulkhead" is guidance; "the payment client shares a connection pool with the catalogue client, so a payment slowdown will exhaust catalogue capacity" is analysis.
- Being wrong publicly and changing your mind. The fastest route to credibility is being visibly persuaded by a better argument.
- Doing the unglamorous work occasionally — writing the migration, taking the on-call shift.
What destroys it
- Deciding without context. Making a call about a system you have not read.
- Absolutes. "We never use X" invites a search for the counter-example, and there always is one.
- Design by document, handed over without conversation.
- Being unavailable when the decision is being made, then objecting afterwards.
Giving guidance that lands
Share the reasoning, not the conclusion. An engineer who understands why will apply the principle to the next case; one who receives a directive will apply it literally and stop there — including where it does not apply.
Ask before asserting. "What happens if the payment service is slow?" produces better outcomes than "you need a circuit breaker", because the engineer arrives at the answer and owns it.
Distinguish preferences from requirements, explicitly. Conflating them means genuine requirements are treated as negotiable, which is far more damaging than losing an argument about style.
Be present early. An objection raised on 800 lines of finished work is the most demoralising thing an architect can do, and it is entirely avoidable with a ten-minute conversation beforehand.
Failure scenarios
- The ivory tower — decisions made without the people who will implement them.
- Guidance as directive, producing malicious compliance.
- Every preference expressed as a requirement, devaluing the real ones.
- Only appearing at review, when changing anything is expensive.
Interview question
"How do you get a team to adopt an approach they initially disagree with?"