Sean KilleenI recently had a colleague ask me about how to describe the difference between an great software architect and a mediocre one, or how to deal with "ivory tower" architects. I personally eschew the title of software/solutions architect because I don’t like to be lumped into that category, but I was struggling to sum up the differences well.
Then I took a trip to Greece, met a sommelier named Angelo, and had one of the best experiences I’ve ever had tasting wine.
I’ll paraphrase here a bit but will do my best. "I hate sommeliers", declared Angelo — who’d studied wine for over 10 years, obtained a 5 year masters degree, and been a winemaker — during our tasting. "They use their knowledge to feel better than people, to make them feel bad about themselves. This is experience is meant to be shared. It’s informed by your own preferences. I have tools and knowledge but this experience is meant to be built by you."
I mean, is that a set up for an extended metaphor or what?!
What it Takes to Become a Software / Solution Architect
The title and qualifications vary from place to place widely, as tends to be the case with our industry, but in general I would say a software/solution architect needs to have certain technical qualifications.
They likely:
- understand different architectural patterns or methods of building things
- have delivered more than one project successfully throughout their career
- excelled as an individual or lead contributor
- have opinions on the right / correct way to build software
I’m deliberately keeping this pretty general as a baseline. My point is, there are flukes but in general software/solution architects tend to fit the "smart, opinionated, gets things done" model. They’ve usually accomplished some things to get where they are, and the position oftentimes carries some distinction.
But how is the position approached by those folks?
Software Architects as the Snobby Sommelier
This is the ivory tower architect. They’ve studied their books, built some major pieces of software, and you should just listen to them. Those suggesting new ways of thinking / doing things are met with dissent and defensiveness and find themselves buried under articles about best practices that may or may not be current. This architect is the decider. Otherwise, they wouldn’t be earning their paycheck! The weight of the project is on their shoulders! Study this Visio diagram they’ve painstakingly compiled over the last 3 months to see how complex things are.
:eyeroll:
Software Architects as the Engaging Sommelier
Now, imagine a solution architect who engages the entire team for buy-in. Who guides with their knowledge rather than bludgeoning with it. Who helps keep concepts accessible for the team, invites discussion on a roadmap, pairs with team members, and enjoys questions. Someone who learns along with their colleagues, who isn’t afraid to explore and say "I don’t know." Someone who is willing to share decision-making authority and lessons learned with their group.
This person has the potential to change the trajectory for an entire team — to create an entire group of architects who can shape the application of technology for a project. They can raise the discourse.
The Same Tools, Applied Differently
Both sets of sommeliers in my strange little metaphor have earned the right to be called that. Both have the requisite knowledge and experience. The difference is in how
The difference isn’t about software at all. Technical skills, it turns out, are really not the point here. It’s about what an organization's politics and structure allows for, and it’s about whether an individual embraces the idea of leadership and collaboration as foundational/core skills. (I avoid calling them "soft skills" for exactly these sorts of reasons).
But How do you Change a Sommelier's approach?
This is the hard part. The mileage varies, but it was part of the question I was asked, so I’ll try to answer as best I can. What would I do if faced with a architect that wields knowledge as secret power and judges rather than teaches?
- Get leadership to make "I don’t know" a golden phrase. If someone sees the people around them being praised for uncertainty, they may be willing to embrace some themselves.
- Place a value on teaching, and make space for them to shine. Architects have expertise; show them the value you put into sharing that expertise and leveling up others on the team.
- Dis-associate the role of architect from the value that an architect brings. Show this person that you value you them for their expertise, not their title, and that there’s value for them in great feedback and advancement opportunities. Make the role of architect not a kingdom to defend but a calling to aspire to.
- Show them a better way. If an architect only respects expertise, show them some folks with real expertise leading by example.
- Be patient. It will take some time for the guard to come down. Once they know you’re there to help them and there’s some movement towards a culture that allows them to let go a bit, you may make some good progress.
- Show them work can be fun. Building things together can be great cause for celebration. Celebrate them along with the team rather than separate from the team.
- Build the relationship. After all, it’s what you want them to do, right? Find out if there are fears, anxieties, a bad history in a broken organization.
I’d love your thoughts!
What are some examples of sommeliers in our industry? Has your experience with sommeliers generally been positive or negative? How have you successfully (or less successfully) tried to change a sommelier's approach? Is this all just a ridiculous metaphor?
Add your voice to the comments! I won’t bite! I’m on vacation and just musing.
