The RevOps Systems Architect

How to identify and cultivate great technical operators.

Mar 17, 2024

You might notice I write a lot about the need for RevOps to focus less on technology and more on business impact.

This is, in part, a nudge to correct what I see as an imbalance of focus in our field. But, of course, that doesn’t mean tech isn’t important — far from it!

Technology and data are the backbone of modern ops teams. And the technical anchor of your ops team is the systems architect.

What is a systems architect?

We can think about systems skillsets in a rough hierarchy. This is often reflected in the different tiers of platform certification a vendor offers.

System User: executes key tasks within the system.
- Example: executing a webinar campaign in a marketing automation system.
System Admin: configures the global settings and environment that users operate within.
- Example: configure fields and page layouts in CRM.
System Architect: creates the vision and design of the system as a whole. This potentially spans many discrete platforms.
- Example: define jobs-to-be-done, determine which tools will do which jobs, define how all the tools connect to each other.

Profile of a Systems Architect

I’ve observed that people who excel in each of these roles tend to have a particular orientation.

By “orientation,” I’m speaking less about skills and more about the type of work that people find interesting, exciting, and gratifying to do.

People succeed when their role matches the work they love.

Practical example: 

Campaign Ops

People who excel at campaign ops tend to have amazing attention to detail and get satisfaction from working with stakeholders to bring a campaign vision to life. 

However, if tasked to design a net new solution without an existing framework, they may find it stressful. 

Systems Architect

Conversely, an architect absolutely craves to be the one solving that new problem. But they're unlikely to do well in campaign ops. 

Repetitive work doesn't suit them, and they and may find the communication with campaign stakeholders frustrating rather than fulfilling. 

In both cases, it's not really about skills. The two personas are simply oriented towards a different type of work.

I used to lead a solutions architecture team at a marketing ops agency. When evaluating if someone would make a good architect, these were the main attributes I looked for:

Figure-it-out-ability

When presented with a challenge that has no existing solution, can the person autonomously take the steps to solve that challenge?

(E.g., through searching documentation and forums, trial and error, asking peers, etc.)

Craving for challenges

Do they love the process of solving those new challenges — of being the one to figure it out? Does their hand shoot up right away if someone needs to volunteer to do it?

Systems thinker

Are they able to quickly perceive or envision the different parts of a system and how they relate to each other as a functional whole?

Do they have an innate drive towards clarity and logic in how roles are assigned within the system?

Fastidious

Do they sweat the details?

Good architects are generally allergic to loose ends, redundancy, or messiness.

They have a drive to create order and to account for edge cases.

Love of tech

Architects have an intrinsic fascination with tools and technology. They’ll gravitate here naturally, and if left alone will usually focus on the systems aspect of a project.

Developing a systems architect

So are architects born, or are they made?

In my personal experience, I’ve found that many of the personality and interest factors are relatively fixed and innate (at least for the purposes of work).

You might be able to take someone who is a 7/10 on figure-it-out-ability and get them to a 9/10 with coaching.

But it’s extremely difficult to get someone from a 3 to 7. Or to take someone who simply doesn’t enjoy solving new challenges and get them love it. They won’t be happy or successful.

So in the first place, you need to select for people that demonstrate the interest and aptitude for architect work. Then you can train them on the hard skills required.

If you’re an aspiring architect, or if you have one on your team, here’s a non-exhaustive list of things you can do.

Cultivate an architect mindset

Mindset isn’t a specific skill. It refers to your whole way of thinking and approaching work. It’s the “lens” you’re viewing problems through.

I’ve found the most efficient way to cultivate an architect mindset is through osmosis — by observing and ideally interacting with other architects and technical folks.

Practical example: 

Earlier in my career, I subscribed to Sanford Whiteman's posts on the Marketo community. So I got emailed every time he posted.  

Keeping in mind he sometimes posts dozens of times a day, this provided a steady intravenous drip of developer mindset that I took in for years. 

I learned a lot of valuable information this way, but the more important benefit for me was internalizing how Sandy thought about problems, the types of thing he was concerned with, and how he talked about them. 

I acquired the developer mindset through osmosis.

To work on your mindset, here are some resources and people / channels to follow:

Understand software architecture best practices

Software architects have been figuring out best practices for decades, and many of these principles apply to no-code/low-code/configured solutions. So we don’t need to reinvent the wheel.

Keep in mind that, depending on your application, we aren’t always applying these principles 100% literally. It’s more a way of thinking about system design.

Practical example:

You can create “microservices” (operational programs) inside your Marketo instance to perform different functions. 

These probably wouldn’t be considered literal microservices by a developer; it’s more an application of that idea to the configuration within Marketo. 

Alternately, you can also apply that design by building a composable stack made of totally separate applications connected by APIs.

Each of these concepts would be a long post in themselves, but here are some topics to read up on to get started.

Microservices and Composability

An Introduction to Microservices by Amanda Bennett
Microservices explained - the What, Why and How? (Video) by Techworld with Nana
Microservices as a Future Approach to Marketing Tech by
Leonardo Federico

DRY (Don’t Repeat Yourself)

Separation of Concerns

Separation of concerns on Wikipedia
Separation of Concerns by Talin

Build your hard skills

APIs

A composable martech stack is built on a foundation of APIs.

Modern iPaaS tools have pre-built connectors for many common apps, which makes it easy to connect tools without any direct knowledge of their APIs.

However, inevitably you’ll need to perform an API action that isn’t supported by the pre-built connector, and so being able to work with APIs directly is vital.

JSON

JSON is the data format commonly used by modern APIs.

JSON - Introduction by W3Schools
Learn JSON in 10 Minutes (Video) by Web Dev Simplified

iPaaS Platforms

An iPaaS platform allows you to sync data and orchestrate and automate processes across your martech stack.

There’s a bunch of them out there. Some truly do require a developer skillset. And some, like Zapier, are too limited for serious use in my opinion.

There are two platforms I’m aware of that find the Goldlocks zone — combining enterprise-grade power with a GUI friendly for non-developers: Workato and Tray.io.

Workato has an Automation Institute and a free trial instance (kind of like Salesforce Trailhead). So you can really get your feet wet and start learning right away.

Coding

I don’t think coding is essential for an architect, especially if they’re working in a larger team with access to developers.

However, there’s no denying that coding is very useful and will extend your capabilities significantly.

I tend to pick up bits and pieces of coding knowledge on an as-needed basis and then forget them in between projects. 😂

If you want to invest in your coding skills, the two languages to think about are:

JavaScript (for web / client-side work)
Python (for API / scripting work)

RevOps FM

Discussion about this post