Getting the most out of your Software Architects

Architects can save you tons of time, and prevent crucial mistakes from happening. They are very experienced software engineers, who have seen it all.

* This applies to any cross-team Senior+ engineers you have. They can be called Architects/Staff/Principal engineers - in each organization it’s different.

We are going to cover:

• How to do your side of the deal

• What should you expect from the architects

• Advice from an experienced architect - Mike Thorton from Dev Details

The article is not about being manipulative to get your needs. It’s about how to make the relationship as productive as possible, for both sides.

Do your side well

Don’t drag out their requests

When the Architects need something from you - do it well, and fast.

For example - security updates, a refactor in a shared microservice, or implementing a new testing methodology. Those things are almost never urgent, and you might be tempted to take your time. Don’t.

Embrace those changes - they are always good for the long term. The more you drag it, the more painful it becomes (and the more credibility you lose).

A huge side benefit is when you are the first one to work on such initiatives, you’ll also get more help and guidance 🙂 I’m using this one constantly, and it allows my team to always finish fast those ‘side-projects’.

Proactively consult with them

When you have a complex technical dilemma - before you decide, ask the opinion of the architects. Even if it’s something smaller you are leading yourself, and doesn’t require their involvement.

When you keep them in the loop, there is a bigger chance they’ll be able to help in later stages.

Appreciate the work they are doing

Imagine this scenario:

Your little brother asks you for help in designing a new table, which he is going to build as a present for your parents' anniversary. You buy the needed materials, prepare detailed blueprints and step-by-step instructions, and hand it over to him. He builds it in a few hours, calling you a couple of times to help him when he is stuck.

When the day arrives, your excited parents tell him: “Wow, Danny, you are so talented! Thank you so much for the present!”. Are you bothered that Danny didn’t even mention your help?…

Yes, people enjoy getting credit where it’s due. Often, software projects take weeks or even months. By the end of the project, we don’t remember the huge help we got from the architects in the initial phases.

When presenting the feature mention their help, thank them personally, and if they did a great job - let their manager know.

Their side of the deal

Ok, so you got an Architect to help in one of your projects. What’s next?

Take ownership at the right time

In complex projects, Architects might code themselves, to show the way. They’ll start with the basic infrastructure, and maybe a couple of examples of how a good implementation should look like.

But what happens if there is a bug in the part that THEY did?

You should always remember - it’s YOUR project. Their role is to help you do it in the best way, but you cannot offload the responsibility in the case of incidents or mistakes.

Once the initial phase is done, the ownership is 100% in your hands. This is a huge temptation for me - I like to ‘protect’ my team and delegate as much work as I can to other people. I need to constantly remind myself that they are helping US, not the other way.

Don’t hesitate to push

Let’s face the reality - like all cross-team roles, there is never a clear definition of who should the Architect help. There is some roadmap of course, but often those who shout the loudest are the ones getting the help.

If you need help from an Architect, it won’t just arrive out of nowhere.

• Clearly define the scope of work you need help with

• Explain why you need the help, and what is the benefit of that project to the organization. For example:

  • A time-sensitive project that clients are waiting for

  • The project uses a new technology, which can help other teams

  • You are touching a sensitive part of the code base, and it’s important to minimize the risk

• Argue your case.

Often, this comes to experience - the more senior team leaders know how to present their case better, and get more resources. Practice makes perfect :)

Don’t offload trivial things

Continuing on the previous point - never abuse the privilege, and exaggerate the amount of help you need.

The Architects/Staff engineers are key people in your organization, and you shouldn’t waste their time. Their goal is to help navigate tough decisions, and set a technical chart of the future.

As soon as you know exactly what to do and how to do it, you don’t need them anymore. Let them move to the next important projects.

What does an architect think?

And now the best part! Expert Tips from Mike Thorton - the writer of Dev Details and an experienced architect - on engaging with architects.

Before consulting with architects, collect information first. For them to help you design a solution or for them to design a solution, they will need to understand the context of the problem you're working on.
Write down:

• What you know about the problem

• Why the business needs it solved

• When it needs to be solved

Those are the first questions I ask when starting architecture work on a new project. From there, the architect can guide the next steps.

In my experience, software architecture teams adopt one of two working models: centralized or decentralized.

Centralized architecture teams

The Architects make all architecture decisions and design the software for other teams to implement.

They will make the designs with your collaboration. You will likely be the Subject Matter Expert (SME), and they will consult with you to understand the problem space in order to design a solution.

Ultimately, they will design a solution and make the architectural decisions. For success with this type of process, you will need tight communication between you and the architect.

Decentralized architecture teams

The architects will help YOU design solutions and make architectural decisions for YOUR team.

Here, you will need to follow the design process defined by the architecture team. Typically this involves a set of Architecture Principles, a Tech Radar/Menu, or other guiding principles.

As long as you follow these, the architecture team leaves the decision-making up to you and your team. Communication does not need to be as tight, but the architecture team is available for any questions or concerns. For success with this type of process, you will need to drive things forward and reach out to the architecture team as needed.

In either scenario, early collaboration with architects is essential. Architects will help guide the process, clarify the problem, and provide direction on the solution. Engaging with architects too late is the biggest mistake I see. If too much work has been done, it might be too late to change direction, or it could involve a lot of rework. Before starting on a solution, consult with architects.

To sum up

Working with a strong architect is a huge advantage. It helps your engineers grow, and your team achieve better results. Don’t miss out on it!

• Appreciate the opportunity, and respect their time

• Involve them as early as you can!

• Be clear on what you need from them

• Don’t offload the responsibility - it’s YOUR projects