Navigating the First Days as a Software Architect. Part I: Talk to people.

The first days in this pivotal position can be both exciting and challenging. Lots of new adventures. But, on the practical side, what should you do right after you land in this position? I’ll share what works best in this series based on my experience.

This first article is about Day Zero. The most important task you’ll need to start with.

Talk to people

Wait, what? 😕 Is talking to people the first thing to do in a technical position? I’m sorry if I disappoint you. This is not purely a technical position. You’re not the most excellent technical expert in the company; you’re the one who builds bridges between the technical people (including those experts) and the rest of the organization. You’re an enabler, an influencer, and a secretary.

Ask always similar questions to everyone you meet:

• What do they expect from you? What do they think are your responsibilities as a Software/Solution/Enterprise Architect?
• What would be a good tangible result that you can deliver? In different timeframes: short-term and long-term.
• How can you help them in their daily work? What are their main pain points? Let them talk about any pain point, not restricted to technical ones. The more knowledge and context you gain, the better.
• Do they want to communicate with you? If so, in what format and how often? Do they want to get involved or only informed?
• Some context about the system from their perspective?

Who should you have a chat with? Your stakeholders. I can give you some hints about who these people commonly are:

• Your manager. Please also ask your manager what they expect from you in tangible, measurable terms. The [Prefix-]Architect[-Suffix] position is one of many organizations’ most vaguely defined roles.
• Other engineers. You don’t need to talk with every single person, but make sure you get a diverse knowledge representation: backend, frontend, security, platform, infrastructure, etc. It’s often better to talk to them individually or in small groups.
• Product/Project Managers and Strategy teams (whatever applies). Pay special attention to their vision of your organization’s product or services. Ask for as much available material as possible. What do they want to accomplish in the short term? And in the long term? Who are our users, what are they looking for? Ask about user journeys, value streams, etc.
• Product Designers / UX. Usually, they’re good communicators of the product goals from a visual perspective and can give you an additional angle.
• Engineering Managers, Scrum Masters, Agile Coaches, etc. They’re not all the same, but they have something in common: they care about ways of working and processes. That’s also an excellent insight.
• Operations / Support. You’d like to know how people keep your system alive and how to deal with customer requests and incidents.
• Commercial / Sales / Account Managers. This is also one of the most valuable perspectives you can get as an architect. How is the whole thing being sold? How can you build bridges between this part of the organization and engineering, for example?
• Others, but it depends on your organization: compliance, security, human resources…

Start by introducing yourself if you haven’t met yet. Keep it as informal as possible since that’s more fun, although you may need to adapt to your audience. Tell them how you landed in that position and why you’re having a conversation. Listen more than speak. Learn. Let people know you’re on a discovery journey, especially if they ask about your plans.

Take notes. You can use whatever format suits you. If you need inspiration, I created a Miro template with a table to help you collect the notes.

Spoiler alert! Based on my experience, these are some common findings that you can expect:

• People outside engineering don’t understand the system’s architecture.
• People have wrong assumptions about your role or don’t understand what you should do.
• People understand your role but don’t think you’re needed and may consider you an Agile/other-methodology anti-pattern.
• People think you’re going to fix all the problems in the organization, especially on the technical side.

You can explain the wrong assumptions and provide more context about your role. However, I think you should do this after the Q&A session to avoid bias.

Processing the information

You can extract some conclusions when you reach a good variety of answers. Try to group some of the notes you took as “Challenges” and summarize them with one-liners. Prioritize them.

If you already had an initial plan in mind, where you proposed some solutions, now it’s time to validate your assumptions: Can you link people’s problems and expectations to the solutions you envisioned?

• If you can link them, that’s precisely what you must do next. Explain how you’ll tackle the challenges with your envisioned goals. Document that. Organize an Architecture Kick-off and share it with everybody. Ask for feedback.
• You have a more significant challenge if you can’t link the organization’s problems to your plans. How is this possible? Be self-critic: are you focusing on the right challenges? Perhaps it’s time to revisit them. It’s also likely that people can’t see the forest because of the trees: some minor problems and challenges are caused by more significant architectural issues that are not visible. In this case, it’s even more critical to slice your solutions and plans so that you can map them directly to how you solve the current problems that people experience. You can’t defend a massive refactoring and a change in the system architecture if it’ll only provide value at the end.

Next Steps

You can navigate to the following article of this series, where I’ll introduce the complete Software Architect’s Toolbox, which includes this Stakeholders Interview exercise.