#26: A Personal Perspective: What To Expect As a Software Architect

The software architect gig can look pretty different depending on where you are working. But don't worry - there is still a bunch of stuff that pops up everywhere, or that you can bring in.

The day starts. I am sitting in my ivory tower, drinking coffee. Thinking about the past, the current, and the future. My developers scurry about below, their frantic typing echoing through the halls. I adjust my monocle and stroke my perfectly groomed beard, pondering which grand architectural pattern I shall decree today. Perhaps I will invent a new one.

Fortunately, the above is not true at all.

In the early days of my career, software architects often seemed like distant figures, separated from the day-to-day work of development teams. They set strict rules, and every major decision required their stamp of approval. This setup caused two main problems. First, it slowed everything down. Getting decisions made took ages because we always had to wait for the architects to weigh in. Second, since these architects weren't closely involved with the programmers or their code, their choices were frequently off the mark. As a result, a wall was built between programmers and architects (and a lot of complaining from both sides).

Thankfully, the field has evolved considerably over the years. While you might still encounter organizations clinging to outdated practices, they are becoming increasingly rare. Allow me to paint a picture of what you can expect as a software architect in today's more progressive environments.

A quick disclaimer: I am focusing on software architects here. Enterprise architecture, while related, is a different beast altogether. I have dabbled in it without the official title, but I wouldn't consider myself the definitive voice in that particular role.

My personal philosophy? I believe in rolling up my sleeves and diving into the problem alongside the development team. This hands-on approach has been my modus operandi for the past eight years, ever since I first stepped into the software architect role. With this approach in mind, let me walk you through what to expect. I like the comparison to squeezing a lemon: an architect’s experience is the lemon, and the team uses it to its fullest extent until all the juices are squeezed out.

The role of a software architect can vary widely depending on the company's size, culture, and structure. It is not uncommon to see the architect's responsibilities merged with other roles. On paper, this consolidation might seem efficient – one person doing the job of three, right? But while it may look good on the org chart, it can wreak havoc on your work-life balance.

In my experience, the most frequent combination I have encountered is the architect doubling as a tech lead. Now, if you add to that the responsibility of integrating other systems (from within or outside of the organization), plus all the talks, meetings, and agreements that come with it, you might find yourself drowning in an endless sea of meetings. Before you know it, your calendar is packed solid, leaving little time for other work. That’s why it is so important not to fall into such a trap.

When you step into the shoes of a software architect, think of it more as a function within your team rather than a standalone role. Gone are the days of the "I am the boss, everyone must listen to me" mentality – and good riddance! Your job isn't to lord over others but to collaborate and guide. You are there to facilitate, not dictate.

One of my top priorities as a software architect is getting everyone on the same page. I am talking about stakeholders, managers, developers; the whole crew. It is crucial that we all understand the problem we are tackling, who we are solving it for, and why we are approaching it the way we are.

That's why I spend a good chunk of my time running workshops. But let's be honest – nobody wants another "useless meeting." So, I make sure these sessions are anything but. My goal? Active participation, meaningful discussions, and concrete, actionable outcomes.

How do I do this? I lean on collaborative modeling techniques. My go-to methods are usually Event Storming and Domain Storytelling. They are powerful techniques that get people thinking, talking, and, most importantly, understanding the problem.

I am sometimes joking that being an architect is like the glue - you connect all the people together.

Next up on my architect's hit list? Making sure everyone on the dev team gets a chance to shine. I am talking about juniors, mids, seniors, and the ultra-seniors. Everyone's ideas get a spot at the table and a fair shake in the discussion. You would be amazed how often the newbies with fresh eyes save us from costly blunders. Their different angle can be a real game-changer.

Now, here is something that makes me cringe: someone calling me "boss" and asking for my almighty approval. That's one of the first things I try to nix as a software architect. What I am after is a team built on trust, where it doesn't matter who is pitching an idea or making a call. The stamp of approval? That comes from the whole team, not just one person wearing an architect hat.

Sure, there will be times when not everyone is on board with an idea. That's cool—we put it to a vote. Once the majority speaks, we roll with it as a team. Even if it turns out to be a misstep, no finger-pointing is allowed. We made the call together, and we will fix it together. That's just how we roll.

You can achieve such an attitude by practicing pair and mob programming, swarming, and developers' carousels, which I described here. There are also other methods, but these are my favorites.

Another key item on my architect's playbook? Spreading the knowledge wealth. It is all about letting others get their hands dirty with architectural (and other!) skills.

Got someone itching to learn modeling? Perfect. Here is how you roll: First, they are workshop participants, soaking it all in. Next round, they are your sidekick, helping out. Before you know it, they are running the show themselves.

Or maybe someone's keen to tackle authentication. I will be their safety net, but they are doing the heavy lifting. My experience is their cheat code—they will omit most of the mistakes I made back in the day.

This approach isn't just about delegating tasks. It is about growing your team's skills, boosting confidence, and building a crew that can handle whatever comes our way. Plus, let's be honest – seeing someone nail a skill you helped them learn? That's a pretty cool feeling!

Finally, you must be aware that your weeks might look completely different. Sometimes, you are drowning in a sea of meetings – workshops, system integration talks, management pow-wows – and you can't find a spare minute to code if your life depended on it. Other times, the meeting storm calms, and you can roll up your sleeves for time with the technical stuff.:

• 60% of meetings, workshops, talks; 40% of tech stuff (coding, infra)

• 70% to 30%

Now, here is my personal red flag: If I regularly spend more than 80% of my time in meetings (especially the "blah blah" kind), that's my cue to shake things up—either within the organization or by looking for something else.

Being a software architect is like being a jack-of-all-trades in the tech world. You are not just building applications; you are helping people work together and ensuring everyone knows what problems need fixing. Sometimes, you are knee-deep in code, and other times, you are explaining tech stuff to non-technical people in a way they can actually understand.

In short, you are helping your whole organization win, one day at a time.