Do You Have the Empathy to Make the Move to Architect? – InApps 2022

The career path for a developer is usually pretty clear. Start as a junior developer, either choosing between frontend or backend or moving back and forth to claim full stack. Then it goes: senior developer, lead developer or technical architect, and then team lead. It’s a delineated approach from individual contributor to software manager, all approached with a technical view.

What if you want to move across departments? What if you want to straddle technical and business? What if you want to be more customer-facing while still exhibiting your technical prowess?

Then maybe an architect role is for you.

Only problem is, at most companies, it’s not a clear path. There’s a pivot somewhere along the way. And you can’t just prove you’ve got what it takes with a code test. Architects bring a unique blend of curiosity, empathy and technical know-how. How to see the big picture and how the three pillars — business, tech and people — fit together. And then how to explain it to other people in their native lingo.

There’s no single path to an architect’s role. Here are some of the ways your peers have made the switch, what the role looks like, and the qualities that tie them all together.

What Is an Architect, Anyway?

Solution and API architects may focus on different levels of the stack, but also perform very similar roles. Usually, an architect is a more senior, but non-executive role. An architect typically makes high-level design decisions, enforces technical standards and looks to guide teams with a mix of technical and people skills.

“Being an architect takes social skills built on the foundation of the technical,” said Keith Casey an independent contractor, API consultant and author of “The API Design Book.”  “No matter how good at the socials you are, you need to have the technical. Have you built a system like this? Have you shipped a system like this? You can read cookbooks all day, until you’ve put that in the oven, you haven’t cooked. You actually have to succeed and fail a few times before you can really offer advice to everyone. Social has to come after the technical foundation.”

While a developer likes to dig deep into the weeds of a particular product or language, an architect is ready to broaden their understanding of enterprise architecture and how it fits into the business as a whole.

As an executive API consultant, James Higginbotham has spotted a pattern he calls the six different hats of the API architect:

• API trend-spotter: heavily uses API gateways and other metrics and dashboards to make informed decisions.
• API reviewer: seeks to understand the emotion behind what people like or don’t like, influencing the API design process.
• API risk assessor: wants to understand why something might not work, applying caution before adding new API protocols or adopting new standards.
• API advocate: focuses on the developer experience and usability.
• API creator: looks to leverage the creativity in how APIs blend business and product thinking and to process feedback to improve existing APIs.
• API planner: translates customer requirements, and then plans, scopes and designs the API product and its roadmap.

These aren’t necessarily six different roles; these hats could all be worn by one or a few people. What is certain is that any form of architect wears many hats. And there are many ways to get there.

The Sudden Architect

For Arnaud Lauret, senior API architect at Natixis, the title of architect encompasses a broad range of roles from highly specialized — with all those cloud-provider certifications — to purely functional architects and everything in between.

“It seems that many times people actually build their own ‘architect’ role,” he said. “My career path to ‘API architect’ was not clear at all, I actually had no idea what I was doing with my career until a few years ago.” He initially followed a career path typical, he said, to French organizations: developer to business analyst to project manager to application manager. To burnout.

“Then, as someone who knew very well how our systems worked, I ended up with the ‘architect’ title.”

In his spare time, he began to blog and give talks about APIs, and even wrote the book “Design of Web APIs,” which is what took him from solution architect to product architect. For the past three years, he has been helping different teams to design APIs and the software architecture behind them.

It’s certainly a self-driven role and a curiouser one, always playing around with new tooling, platforms and technologies to understand your own stack and its tradeoffs.

A coder since grade school and now a cloud app dev solutions architect at Red Hat, Aly Ibrahim is the paragon of the curious architect. He taught himself many programming languages, spending much of his work in systems administration, including with Linux and Oracle databases, and in telecommunications, across networking, OSS/BSS systems, and then the cloud.

At Ericsson, he was a solutions integrator until he took up a job opening for a solutions architect for an offshore team. He played around with Kubernetes on the side, which led him to get recruited to Red Hat. There, he’s a solutions architect, first with the DevOps consulting team, jumping from one customer to another, and now works on Kubernetes, cloud systems, and a lot of DevOps and digital transformation.

“People who are interested in this path find ways to increasingly do it, no matter whatever role they are in.”

—Joanna Hodgson, Red Hat

“I don’t think the solution architect should know just one thing,” Ibrahim said. The role “should be more broad so you can deliver more value to your customers.”

Casey, the API consultant, believes a solid pathway to an architect role is a decade in software development, followed by something customer-facing, whether it’s developer advocacy or more of a product role.

“This brings better understanding of the customer, with both the internal how but the external why,” Casey said. “How can have a lot of ways, but the why probably has a singular purpose.”.

Overall, more people seem to be outright asking for the job than are guided there by HR teams.

“I never thought it was in my career path. I don’t know if I knew any women architects at the time,” said Joyce Stack, a product architect and API subject matter expert at Elsevier.

She calls herself an “accidental architect,” having gone from Java developer to developer advocate to now product architect. She loved working with APIs and saw how her acquired knowledge could be applied to long-term strategy.

So she went to her chief architect and asked, “Can you please help me find a way to use these skills? I really believe in what you’re doing. I really want to learn.” Her boss responded that Elsevier was going to invest in her career and became her advocate.

Even with this support, she said, she wrestled with imposter syndrome. It took her a long time to describe herself as an architect.

Technical Chops Required

Any architect needs a technical foundation. The language, database or cloud provider doesn’t matter, but you have to have actually designed, built and shipped something into production.

Casey calls this, “The credibility of I’ve been there, done that, here’s what I faced before, here’s what I understood. And being able to design, build and describe everything from beginning to end.”

This ties back into the necessary empathy, persuasion and advocacy skills. “Put on the customer’s hat, and understand why they are using what they are now, and what is going to be better than the approach they already have,” he added.

Furthermore, you have to be extremely driven to learn on your own. “There are very few people out there that are doing this that can offer guidance and mentorship,” Casey said. “And no companies are in position to offer you a game plan to get you there.”

For Joanna Hodgson, director of solution architecture in Red Hat, most of her U.K.- and Ireland-based team of solution architects began their careers as developers. A common career path is to start out as developers and move into some sort of delivery roles, which makes them experts in whatever they started writing their code in.

Then, she said, they might migrate into a services delivery role on the implementation side of the product. “And then they may decide they’d like to get closer to the businesses, have the business problems, and solve those problems with technology.”

This path allows them to build skills along the way, going from understanding their bit of technology to expanding to how it connects to other components and integrates into the overall value chain. This journey is essential to develop curiosity and empathy for the different stakeholders — users, customers and even the business itself.

Only a technical background can give you the perspective of how a piece of technology could be improved, how it works with other things, and how it could make developers and other stakeholders in an organization more efficient.

While Red Hat offers a formal training roadmap and mentoring, it’s usually an organic evolution to the role. “People who are interested in this path find ways to increasingly do it no matter whatever role they are in,” Hodgson said.

“It’s not so much about the career path, but solution architects are often designing things which impact the developer and so having people in that role that have that background and therefore can appreciate what can make the developers’ lives better,” Hodgson said, pointing to how an essential piece of RedHat OpenShift is providing an efficient developer experience.

Ibrahim echoed this perspective: “My developer background is helping a lot because most of our work is towards developers. Most of the developers that I work with are just focusing on their code, but you need to understand what’s happening after you submit your code.”

Most In-Demand Skill? Empathy.

“Long gone are the days that it’s enough to be a coder and you don’t have social skills,” said Stack, of Elsevier.  Anything involving the architecture at an organization will surface many opinions and architects will mean different things. And a lack of progress often comes down to communication styles.

“If they’re not doing what you asked them, you need to look at yourself first,” Stack said.

Instead of technical or architectural certifications, she recommends psychological safety training, like one on inclusive behavior and habits that made her realize that the title of architect automatically comes with some status and authority.

“Put on the customer’s hat, and understand why they are using what they are now, and what is going to be better than the approach they already have.”

—Keith Casey, API consultant

For instance, asking “Why did you do this?” can come off as very aggressive, like you’re telling someone they’re wrong. Instead ask: “Can you help me understand how you got to this approach?” Stack said this is best done in one-to-one coaching sessions.

A lot of being an architect, Stack said, comes down to translating or creating a shared language; product silos can make that more challenging if each team has its own API standards and guidelines.

It’s the architect’s job to balance developer and product desires with architectural strategy.

The job of architect is often about compromise, Lauret said, about  “being able to accept that ‘not your way’ is not always ‘the bad way’.” He’s learned through API reviews that an architect has to learn to objectively analyze others’ ideas.

“What makes a good architect is actually understanding that software is there to serve business, that you build for the long run, that having empathy for everyone involved helps build better systems,” he said. “That there’s no silver bullet, and that asking — even silly — questions, and being able to make people talk are all must-have skills.”

Lifelong Learning — and Teaching

An architect has to be a life-long learner in order to speak all those changing roles, technical and business languages.

Ibrahim, for instance, holds certifications for Linux and Oracle databases, he’s studied for but hasn’t completed the AWS certifications, and is currently working toward a master’s in machine learning.

“When you start to do something and you want to learn more about it, don’t just take it on the high level, dig deep,” he advised.

Another way to reinforce learning — and to show your aptitude as an architect — is to blog or give talks. “It doesn’t matter how good your idea is if you can’t communicate it to others,” Casey said. This role requires being able both to express an idea clearly and also to persuade and advocate for it. You also often have to deliver a presentation to both technical and non-technical people.

He recommends practicing writing and expressing complex concepts in simpler terms. Use analogies that people across teams — and on the business side — can grasp.

Twitter, Ibrahim said, helps him hone his message in 280 characters or less.

As an architect, he is often forced to deal with something new. “Give it a try,” he said. “And always give some time for yourself to learn. There is some learning that you need from your work and you need to build your stuff.”

Photo by Renee Fisher on Unsplash.