This is a continuation of The Agile Architect Part 2 — Spend Time with the Teams.
As much as we like to think we’re infallible, none of us are. What separates success from failure is the ability to identify problems early and act on them. You’re not always right.
We were three months into a project to overhaul our architecture and we found a big problem. We had to change directions and do significant rework.
I remember talking to a junior developer who told me that he thought the approach had problems early on. I pressed him to understand why he didn’t speak up and he said “You’re the architect. I thought you knew something I didn’t”
I was furious. Why would this developer knowingly keep problems to himself? Didn’t he know that keeping problems to himself was putting the whole project at risk? When I look back on this moment I’m not proud of what I was feeling. Rather than blaming him, I should have been thinking about how my behaviours were leading him to believe that I couldn’t be questioned.
Make it easy to speak truth to power
Invite dissent from those you lead. Help them question the architecture and be introspective about it. Architects who are perceived as defensive will discourage critical information sharing. If people aren’t coming to you with problems, seek them out. Practice being approachable. Some great advice from Richard Sheridan: The only response when someone finds a problem is to smile and say “thank you”.
Assumptions are very useful. They let us make mental leaps and arrive at solutions faster. The only way to find out which assumptions are invalid is by testing them. The people to notice problems first are the people doing the work. Build understanding and communicate your assumptions and people will tell you when these assumptions are invalid.
Don’t be afraid to admit your uncertainty
A common mistake leaders make is thinking that they have to be infallible. This is reinforced by Hollywood’s fearless leader who saves the day with a bravado of confidence. We may have insecurities, and we way be tempted to try to prove that we can do this job. If an architect is unsure about which direction to go and it is really a 50/50 decision, the team should know.
Involve people in decisions
Make as few decisions as possible and involve people in the ones that you feel you have to make. Someone is far more likely to question a decision that they helped make. Treat the decisions like an experiment and invite people to find problems.
It took time, but eventually people started openly disagreeing with me. When a design didn’t pan out, people began questioning the approach and suggesting alternative solutions. I had to train myself to let go of my ideas and embrace the feedback. Rather than getting defensive when someone questioned me, I learned to be thankful that they were doing me a favor.
Continue reading the Agile Architect series with Part 4 — Build Consensus.