Code, Coach and Sell Ideas
DabbaGo's architect has a sound plan: move payments into a separate service before the Mumbai launch. She sends the design to all teams. The payments team ignores it because "she hasn't touched our code in a year". The rider team follows it but asks her about every small choice. Leadership delays it because nobody explained why it matters now. The plan was right; the way it travelled was not.
The rule
Code to stay credible, coach to scale, sell to be heard.
Three people skills sit alongside the technical ones.
How to code. An architect who never writes code loses touch with what is easy and what is painful, and teams stop trusting the designs. Staying hands-on does not mean owning critical features, which would make the architect a bottleneck. Good ways to stay close:
- building a small prototype or spike to test a risky idea before the team commits,
- reviewing code in the areas where architecture matters most,
- fixing small things and pairing with developers now and then.
Consult and coach. The architect cannot make every decision; there are too many. Coaching grows the team's ability to decide well without her. Instead of handing down answers, a coach asks questions: "What are the options? Which scenario does each one fix? What does it cost?" Over time, teams bring finished ADRs instead of open questions, and the architect's reach multiplies.
Marketing skills. A good idea still has to win support. Selling an idea means linking it to what the listener already cares about, showing evidence rather than opinion, and finding allies who feel the problem most. This is not manipulation; it is making sure a sound decision is understood well enough to be adopted.
The shortcut
Before pushing any architectural change, check the three Cs:
- Credible: have I touched this code, or built a prototype that proves the idea?
- Coached: could the team have reached this decision with me asking the right questions?
- Connected: have I tied it to a pain or goal each audience already has?
Credible
The architect builds a two-day prototype that moves one refund flow into a separate service and measures the result. Now the payments team is discussing real code, not slides.
The trap is thinking good ideas sell themselves. They do not. An unexplained correct decision loses to a well-explained weaker one.
Drills
Answer fast — trust the rule.
Which is the best way for a busy architect to stay hands-on with code?
A team asks the architect to choose their logging format. What does a coaching response look like?
How should the architect pitch the payments split to leadership?
The payments team ignores a design because the architect "hasn't touched our code in a year". Which of the three Cs is missing?
Remember
- Code to stay credible, coach to scale, sell to be heard.
- Shortcut: the three Cs: Credible, Coached, Connected.
- Trap: believing a correct idea will be adopted without anyone explaining it.