Skip to content

Instantly share code, notes, and snippets.

@hansenc
Last active September 6, 2019 01:37
Show Gist options
  • Save hansenc/5af8c4d371bb3498b490b2d9413a399d to your computer and use it in GitHub Desktop.
Save hansenc/5af8c4d371bb3498b490b2d9413a399d to your computer and use it in GitHub Desktop.
What makes one a good software architect

What makes one a good software architect

Notes from the Utah Software Architecture meetup discussion on 9/5/2019 on what makes someone a good software architect.

People skills

  • Influential. Able to gain buy-in from colleagues. Sell to stakeholders. Meritocracy of ideas -- let the best idea win. Influence across teams and functions, up and down the org chart.
  • Seek to understand.
  • Conflict resolution.
  • Negotiation and persuasion.
  • Mediation. Balance the needs of different stakeholders.
  • Able to gain trust. Respectful.
  • Communication. Verbal and written. Driving discussions to conclusion and next steps. Able to communicate effectively to stakeholders with different backgrounds, needs, etc. Able to relate to people with different personalities, communication styles, etc.
  • Radical Candor
  • Able to understand people's motivations.
  • Coaching and mentorship skills

Other soft skills

  • Humility
  • Confidence
  • Thick skin
  • Organized
  • Decisive
  • Risk assessment
  • Understands which decisions to spend more time on
  • Intellectual curiosity. Always learning.
  • Empathy
  • Self-awareness
  • Strong opinions, loosely held

Tech skills

  • Abstraction
  • Decomposition
  • Maintains proficiency for writing code
  • Craftsmanship. Eye for detail. Consistently excellent.
  • API design
  • Architectural patterns
  • Gap analysis
  • Able to make tradeoffs for cost, scope/effort, risk, quality
  • Product/vendor evaluations
  • Understanding how to meet non-functional requirements
  • Managing technical debt
  • Passion for technology
  • Establish standards and practices

Experience

  • Able to manage change well
  • Successful product releases
  • Failed product releases
  • Breadth of exposure to different ways of doing things
  • Integrations
  • Business analysis

Are NOT / Do NOT

For contrast, what architects should not be/do (a very incomplete list)

  • Design in a silo or ivory tower.
  • Dictatorial
  • Arrogant
  • Analysis paralysis. Get lost in the details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment