From Tension to Trust: Rethinking How Architects and Engineers Work Together

By Ben Justick

Introduction

Engineers and Architects have both played important roles in designing and building solutions from as far back as I can remember. However, the working dynamics between these roles have changed a lot over the past 10+ years as the industry and technology has advanced at a rapid pace around us. The days of groups of Architects being huddled together in a room for weeks coming up with the “perfect” design to hand over to Engineering teams have come and gone, and have been replaced by teams of Engineers collaborating in real time to iterate on a design. As Engineers have continued to grow their architectural acumen and responsibilities over time, I’ve started to observe some quiet tension start to build between some groups of Architects and Engineers as both groups struggle to adapt and find ways of working together that are mutually beneficial. Some Architects have a tendency to lean harder into the past and produce more design documentation in a bubble primarily to be consumed only by other Architects. Meanwhile, some Engineers are starting to produce the design documentation they need by themselves without needing to engage an Architect.

There’s a way to address this expanding rift, but it’s going to take changes in mindset and behavior from both sides. I’ve personally observed and experienced how a great partnership between an Architect and an Engineer can be a true game changer when it comes to taking a great idea and making it a reality. In this post, I’ll expand on the key behaviors and practices that I feel are the most essential to maximize this partnership for mutual success.

What Makes Us So Different?

In order to better understand how we can work together, we need to spend a bit of time digging into what makes us different. I realize that not all Engineers and Architects will fall into these patterns and there may be some overlap in tendencies depending on the person. However, these are the key tendencies that I’ve observed over the years of working with Architects and Engineers in many different areas of focus and contexts.

Key Tendencies of Engineers

• Excel at coming up with new concepts and ideas that make use of new technologies.
• Prefer to convey new ideas by writing code.
• Tend to care more about building out end-to-end solutions rather than navigating organizational dynamics and edge cases.
• Very productive working independently.
• Tend to think more practical and near term.

Key Tendencies of Architects

• Excel at taking complex ideas and making them easy for others to understand.
• Prefer to convey new ideas by creating diagrams and visualizations.
• Tend to think a lot about organizational alignment and agreements that need to be made across area boundaries to build out an end-to-end solution, and non-functionals/edge cases that could “break” a solution.
• Very productive working in groups and leading group collaboration activities.
• Tend to think more abstractly and long-term.

Are you seeing a pattern emerging here? Engineers and Architects both want to design and build great solutions at the end of the day, but the things they tend to care about the most and their strengths are almost at direct odds with each other. Being aware of these strengths and weaknesses is the first step in learning how to maximize this partnership in a way that leans in to the things that each role does best while also working proactively towards growth.

Collaboration for Acceleration

A few years ago, I moved to a new area in our organization and was paired up with a very talented Engineer that was working on the design and build of a solution that was targeted at enabling a new bundled quote and purchase experience in the Customer Channel. He had been working for a couple of months on a new API that would be needed to enable this experience and had made significant initial progress on the API interface design and writing some of the code that would enable this design. My initial assignment was to work with him to refine the API interface design, but we soon realized we could do a lot more than that.

This new API was targeted to be fully built and owned by a product team that had a lot of experience in developing frontend components, but limited experience with developing backend APIs. Handing over an API interface design spec along with some partially written code to this team and saying “get to work” on building this out would have certainly been a slow, confusing mess. However, this Engineer realized that he could lean in to the skillset that I had to help with enabling the target team with getting up to speed with what needed to be built in a way that they could hit the ground running as effectively as possible. This started with some detailed code walkthroughs/reviews to gain an understanding of how the code was structured, what code was already written, and what code was left to build out. This gave me what I needed to then create both high level and detail level architecture documentation that was targeted at initially getting the team to see the full scope of the solution we needed to build, and then easing them into the details of the specific work that was needed. I walked the team through sequence diagrams instead of code, so they could understand the problem from a logical perspective before trying to think about how to adjust to a new context and syntax. By working together, we were able to rapidly bring this team up to speed with the design and the work they needed to do next.

Obviously, this approach worked really well, or I wouldn’t be telling this story, but what are the key behaviors that led to that success?

From the perspective of the Engineer, it was:

• Acknowledgement that architectural documentation could help bring the team up to speed with the vision and details faster than with just the API interface spec and code alone.
• Willingness to invest time in walking through the details of the code to bring an Architect up to speed with the details.

From the perspective of the Architect, it was:

• Being vulnerable to step outside of the typical architecture comfort zone to build an understanding of the details of a code base.
• Willingness to go beyond the initial parameters of the assignment to create detailed solution architecture documentation that could help to accelerate a product team.

Getting the Organization Aligned to Enable Big Ideas

More recently, I’ve been working as part of our Enterprise Architecture area, and I’ve observed how the same types of collaborative behaviors between Architects and Engineers can be applied at a different level to achieve great outcomes. A few months ago, one of our Principal Engineers informally met with me and a couple of other Architects to talk about the high level vision for a new solution that would enable end-to-end traceability across our systems. Over the course of this initial conversation, it was clear that this Engineer had already spent a good amount of time researching and thinking about this and had already jumped ahead to identifying detailed solution and design ideas. However, there was a need for multiple leaders across the department to become aligned on a common vision and outcomes, or these ideas were just going to remain just that… ideas. We already had several teams that owned solutions that provided a portion of the capabilities that were needed for traceability, and there was some perceived overlaps in scope of ownership/responsibility across these teams. There were also several other areas across the department that were very interested in specific outcomes related to a solution like this, and some of them started to build out their own “homegrown” solutions to address the parts of the scope they cared about the most.

We needed to get our department aligned on what the problem was, who the key players in the space were, the key gaps, and next steps that needed to start moving forward in the short term to begin to enable the longer term vision. This is where Architecture was the perfect fit. A small group of Architects and I were able to create a set of visuals in a relatively short timeframe that effectively broke down the problem space and provided a recommended near term plan of action for 1st and 2nd line leaders across the department to react to. As we iterated on our work, we shared our draft documentation back with the Principal Engineer that initially reached out to ensure we were on the right track and make updates based on feedback. Our visuals included:

• A scope breakdown to clarify what was core to the problem space vs. non-core/adjacent scope.
• A view of the different products in the current state that were solving for parts of the problem that showcased the points of overlap between these solutions.
• A gap analysis to show where we currently had traceability across different platforms within one or more current state solution vs. where we had gaps.

We shared our output as a pre-read to the 1st and 2nd line leader group and though we setup an hour to discuss and walk through the documentation, we only needed 30 minutes because the documentation spoke for itself. It helped to clear up the different ideas of what was meant by “traceability” in everyone’s heads and illustrate exactly where the current state overlaps in products were rather than everyone going off of a general feeling that there was redundancy. It also helped to get everyone focused on the gaps that needed to be addressed collectively by the teams that were already working in this space and provided a clear plan of action for bringing these teams together to work on near term next steps.

Would it have been possible for our Principal Engineer to get the key players in the department aligned and focused without engaging Architects to help with articulating the vision? Maybe, but it likely would have taken a lot longer with significantly more potential for organizational swirl. Instead, an Engineer decided to engage Architecture for help/assistance with one of the things that they do best, and was able to rapidly gain organizational support for a big idea.

Giving Architecture a Reality Check

All of the examples I’ve provided so far have been stories of Engineers taking the initiative to engage with Architects. So, what does it look like when the engagement starts in the other direction? To be honest, it’s hard for me to highlight one specific story because it happens so frequently and usually has a really short feedback loop. So, I’ll highlight how this usually goes more abstractly to illustrate the general pattern.

As an Architect, I get asked to think through a lot of different high level problems at a conceptual level, and I’m often asked to create some initial conceptual architecture diagrams to illustrate possible high level design options. These are often the “boxes and lines” diagrams that a lot of Engineers aren’t the biggest fans of, because they often can provide a false impression of the complexity or amount of work necessary to actually enable the solution. It’s these types of situations where early engagement with some trusted Engineers can result in the feedback needed to either make some key adjustments to a proposed conceptual architecture or to even eliminate possible design options before they get shared with other Engineers, Architects, or Leadership audiences.

There are several Engineers I’ve collaborated with over the years that I’ll reach out to for informal architecture review requests in situations like this. In many cases, I find it ideal to review initial design concepts with an Engineer that may be fairly close to the problem space and a different Engineer that might not be familiar with the scope of the problem space at all. This helps to vet the conceptual design from a practical perspective to ensure that there aren’t major technical feasibility issues or missing points of integration that need to be represented to better illustrate the potential complexity, while also ensuring that the design is easy to understand and consume by a more general engineering audience. It would be impossible for me to count how many times I’ve reached out to an Engineer with “got a few minutes to look at something…”, and within a few minutes of hopping on a call, some critical insights are shared with me that either make or break the design. While it requires me to be vulnerable about draft designs that aren’t fully “baked” yet, it’s so much better to find out a critical flaw in a design early and either adjust or scrap it entirely rather than continuing to take time and effort iterating on something just to find out later with a much wider audience that you should have done your homework.

Building Connections Organically

Over the course of this post so far, I’ve provided you with some practical examples of the mutual benefit to be gained through close collaboration between Architects and Engineers. However, unless you’re used to already working in that way, it takes some focused and intentional effort to break through those invisible barriers of misunderstanding. This starts with a mindset shift to be more vulnerable on both sides. For Architects this often means letting go of the potential fear of harsh criticism and/or being willing to admit when you don’t have a detailed enough understanding of how the code works and taking the next step to reach out to an Engineer for help. For Engineers this often starts with the acknowledgement that there’s value in good design documentation and having a willingness to engage with an Architect to help with creating the documentation you need to articulate your ideas to the masses. Sometimes a seemingly small behavioral and/or mindset shift is all that’s needed to reignite the spark of collaboration between an Architect and an Engineer. This may mean that you need to lean away from some of your existing tendencies for a bit and lean into someone else’s tendencies to demonstrate that you value their perspective and contributions. This starts to build a foundation of trust that will begin to go both ways over time, but you can’t expect the other person to acquiesce and lean into your tendencies first.

When you’re ready to take that next step to build or foster a connection, sometimes all it takes is reaching out to that Architect or Engineer you’ve worked with on a recent effort and asking, “Hey, any chance you have a few minutes to take a look at something I’m working on?”. The person on the other side of that request will more than likely feel honored that you reached out to them for their opinion, and likely will end up returning the favor.

Finding someone to reach out to could prove to be more challenging if you are new to an organization or if your organization is structured in a way where Architects and Engineers don’t often collaborate organically all that often. In these cases you may need to rely your manager, a mentor, or a peer for help with identifying someone that could be a good new connection for you, and you may want to approach this in the form of a cross-mentoring opportunity to begin with. These present a great opportunity for Architects to possibly take a deeper dive into a code base to build their low level design acumen, and/or for Engineers to expand their high level design acumen and diagramming skills in a setting that’s all about growth and learning.

Leadership’s Role in Creating and Fostering Perfect Pairings

While most of this post has been focused on the behaviors of Architects and Engineers, leaders also play an essential role in ensuring strong collaboration and partnership. Leaders should invest in understanding the key tendencies of the Architects and Engineers within their purview to look for opportunities to pair people together that may already have some overlaps in tendencies. This will create an ideal situation where the Architects and Engineers involved should be able to collaborate naturally and hit the ground running when it comes to sorting out and driving the work that needs to get done. Reflecting on the examples above, this was the case with the first example, where a strong strategic leader was able to pair me up with an Engineer that was a great fit for me, and I was able to start producing results almost immediately when I moved to the new area.

In an ideal world, leaders would always be able to create perfect pairings, but there are many situations where the people within a leader’s purview may be limited, and the Architects and Engineers may have very strong leans towards their respective tendencies. In these situations, it’s recommended leaders be more engaged and proactive in fostering and building the partnership and collaboration they would like to see between roles. This may involve taking on a more proactive role in leading initial working sessions to assist with breaking down the work and ensuring it gets assigned appropriately. It may also involve being proactive in showcasing and highlighting the benefits of the contributions and output that each role is providing in context to the overall work effort. While some Architects and Engineers may be able to effectively showcase and advocate for the value of their work, in these situations sometimes an extra boost from a leader that really sees the value of both roles is what is needed to break down pre-existing barriers and reshape people’s perspectives.

Conclusion

Over the course of this post, I’ve provided a breakdown of why the working relationships between Architects and Engineers often can have so much tension and several real-life examples of why it’s vital to change individual behaviors and mindsets to work through that tension to get to a place of trust if you want to maximize the value of both roles within your organization. In order to truly be effective, this involves change at the individual level for Architects and Engineers, and strong proactive leadership that understands both the tendencies and the value that each role can provide in context to the work at hand. While changes in mindset usually occur over time, small behavioral changes can start right away. So, what are you waiting for? Take some small action today to build or foster a connection. A small action today will eventually lead to more significant changes in mindsets over time that will result in trust and collaboration between Architects and Engineers that will lead to amazing outcomes.

To learn more about technology careers at State Farm, or to join our team visit, https://www.statefarm.com/careers.

Information contained in this article may not be representative of actual use cases. The views expressed in the article are personal views of the author and are not necessarily those of State Farm Mutual Automobile Insurance Company, its subsidiaries and affiliates (collectively “State Farm”). Nothing in the article should be construed as an endorsement by State Farm of any non-State Farm product or service.

<hr /><p>From Tension to Trust: Rethinking How Architects and Engineers Work Together was originally published in State Farm Engineering Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>