Things good Solution Architects do
Published in
2 min readAug 23, 2017
- They get requirements and design directly with the end users, not an Account Rep or an executive. If someone says “what they’re looking for”… ask to speak with “they”. Don’t ask, demand.
- They realise their most important skill is communication. They communicate visually, slowly, clearly, in plain english, they show not tell wherever possible, and check often if people understand. Ditch the jargon and acronyms… Your goal is to have everyone leave the room with clear comfortable understanding, not to be admired as the solution wizard who no one understands (these people exist).
- They draw — pictures, diagrams. Not words.
- They build a prototype or mockup. Not slides.
- They create videos walking through their ideas.
- They use Design Thinking / Human Centred Design.
- They don’t say ‘no’, they say ‘we need to find another way to do that’. They’re problem solvers.
- They know themselves. They ask for help often. (don’t ask me to do a technical security interface design… I’ll be contacting Steve Herod for that).
- They consider methodologies, accelerators, frameworks… but happily ignore all of them if needed. Context is important.
- They are great with people. You need rapport to get things out of people.
- They work on their presentation style constantly. They self improve constantly.
- They are self assured. You did your best with the design, there are many things that may pop up during the project that you didn’t know at the start. That’s ok.
- They ask all the dumb questions, all the time. What does LOB stand for? What does ANT mean? They get into the detail and know the customer well.
- They know the detail. They don’t know everything, but they aren’t just floating at the top.
- They try new things with the right customers.
- They suggest creative new ways to package deal pricing. Value based, skin in the game, less Time & Materials.
- They know the context… your ‘estimators’ can’t foresee how easy a client will be to deal with, or how willing they are to change direction half way through.
- They know who their delivery team is, and estimate accordingly. A senior developer is better than a junior developer. I’d rather have Kate instead of Joe on this project, Kate is enthusiastic, brilliant. Kate is a junior developer. People complete the tasks, not levels.
- They get it wrong, but keep learning. Not every solution is going to be perfect, but you learn from each one.
- See #2.
