Becoming a Software Architect

03-14-2022
#Career Growth

In recent conversation I was asked these questions. I wanted tow also share my thoughts in writing.

It’s your job to choose the least worst option - Neal Ford

0. How did your career lead you to being an Application Architect?

My career path has not been a linear path. I weaved quite a bit to get to this point. Programming is actually my second career, I began as an outdoor guide, educated and trained to lead individuals and groups through various outdoor adventures. Adventures like whitewater rafting, rock climbing, and mountain biking. While I really enjoyed this period in my career, I felt that it wasn’t the right challenge for me at the time. I spent time really evaluating my passion areas and how a change in focus could help me achieve a new set of goals. I eventually found my way into software development where I’ve spent the last 15 years learning and honing my skills. Trying and succeeding or failing to build and maintain systems has been a big part of my journey. I’ve spent time building and maintaining software systems in transportation, healthcare, Software as a Service(SaaS), and finance.

I’ve been in various roles from a solo developer to a Senior Engineer to a Tech Lead. The titles may have varied, but the goal was always to use technology to deliver business value and a great user experience. A few years ago I began looking for my next challenge and I spent some time evaluating the areas of development that I really enjoy and the areas I think I can excel. I’ve always been able to hold the complexity of larger systems in my head as well as explain technical solutions clearly and concisely. While I enjoy building full end to end solutions, I found I got bored with never-ending feature sprints. The role of Architect ticked a lot of boxes for me. Allowing me to continue growing, both as a technologist and a technical leader.

I first started in the Architect role at a growing FinTech startup. It was there that I helped to shape the technical vision, reduce technical complexity, implement tooling and best practices that allowed the team to continue to deliver great features more reliably.

I joined Calendly at the beginning of 2022 to help with the explosive growth of the engineering organization and the platform. It’s a really exciting time to join Calendly where the growth is significant.

1. What does it mean to be an Architect and how is it different from say being a Team Lead / Tech Lead or a Director of Eng?

I’ll use the obligatory “it depends” answer here. It really does depend on the organization. The title may vary across organizations. Some might call them Tech Lead, Team Lead, Lead, Staff, Principal Software Engineer, Software Architect, Application Architect, and on and on. The size of the organization and the maturity of the engineering team might change what certain job titles mean and the responsibilities for each role. The industry still struggles to define the role of Architect as well.

There is a famous Ralph Johnson quote, “Architecture is about the important stuff. Whatever that is.”

Often what I’ve seen is that the Team Lead/ Tech Lead will be the lead developer for a single team, the person responsible for keeping their developers moving forward, attending cross team meetings and removing technical roadblocks.

A Director of Engineering is usually responsible for multiple engineering teams, ensuring projects are moving forward and teams are functioning together as a unit. It’s at the Director level where they almost certainly have folks reporting directly to them. They will work to grow teams and retain talent.

The way I distinguish the role of an Architect is they are responsible for taking large problems that span multiple functional areas, breaking them down into smaller chunks, and defining an approach to solve the many problems we might encounter, known and unknown. On smaller teams the Tech Lead might also be the Architect all while being the lead developer too. As teams and organizations grow there becomes more of a need for someone who is responsible for understanding the bigger picture, across multiple teams or projects, and how to best manage the technical complexity to keep those teams and projects moving forward. That’s usually the role of the Architect.

2. How can someone interested in a technical career track prepare themselves for success and landing Architect positions in their career?

To be successful as an Architect you have to be passionate about technology, like really passionate. It’s not required, but it’s extremely likely that you’ll spend significant time outside of work, reading, writing, and tinkering with various technologies. You’ll listen to podcasts and watch conference talks. You like to solve complex problems. A genuine curiosity is critical to being a good Architect.

I like to say that “technology is the easy part of what we do.” As an Architect you will spend a lot of time talking and working with other folks. Understanding how businesses operate and how the people in those businesses operate is hugely beneficial. Understanding the motivation behind why something is being considered will help you evaluate the potential outcomes.

Focus on both breadth and depth. Study and understand how larger systems are designed and work. There are a lot of great blog articles and conference talks that go through various architectures for systems we use everyday. Study them, does everything make sense? Is there a gap in your knowledge about a certain area of the system?

3. What are the critical technical skills and what are the critical soft skills required in Architect’s role?

As an Architect you will play part technical SME, POC/Prototype Builder, therapist, conflict arbitrator, and Chief Googler.

I think of these two areas as technical skills and personal skills. Technical skills vary across Architects I’ve met. I think the biggest area to focus on is gaining experience across the entire stack on a number of different projects. Having experienced the pitfalls of working in a new environment, the “cloud” for example, a legacy application, or adopting a new framework will all help you to identify and hopefully mitigate issues in the future.

Learning and understanding new technologies, and being able to implement a project with them quickly is supremely important. You’ll be evaluating new technologies and solutions months before they are possibly implemented. You’ll want to be able to implement a technical solution, ensure it meets as many business use cases as possible and be able to transition the solution to a development team. The transition includes working code, documentation, and hands-on walk throughs.

IMO, being a strong technologist is table stakes for being an Architect. To be successful it’s important that you have taken more than one decently sized business system from idea all the way to production. You understand the idea phase, you understand why it’s important to be flexible, “agile”, and you understand the when, where and how technical decisions are made to ensure successful delivery of a software system.

Technical Skills:

  • Know at least one programming language really well, 2+ is better
  • Understand and have experience across the stack, not expert level
  • Have a focus area, for me it’s application security
  • Understand the *ilities (i.e. observability, reliability)

Personal skills are the most important in a technical leadership role. Architects are leaders, while they most often do not have direct reports, it’s their job to define the technical plan, weigh tradeoffs, and then evangelizing and guiding teams through implementation. You’ll work with individual engineers, teams of engineers, product owners, and other stakeholders. Since you often don’t hold a “manager” role or title, more people will confide in you their wants and frustrations. You’ll play part technology guru and part therapist.

You have the opportunity to gain a lot of respect among your peers. Architects have the unique opportunity to lead individuals and teams to be successful.

Personal skills:

  • Presentation
  • Facilitation
  • Decision Making
  • Trustworthiness
  • Conflict resolution
  • Team building (among an existing team, not hiring)

(4) bonus :) Are there any books in particular that help in shaping an Architect Mindset that helped you get where you are?

I recommend all of the classic coding books, even just for reference. Here’s a list of books that have really stood out to me recently: