Big Meetings, Big Feelings
Notes from the field last week consulting in tech to a large enterprise.
Today we’ll talk about:
Asymptotic advantage of in-person work
Big meeting syndrome
The power of feeling heard
How to properly diagram in martech
Last week was a fun one. I received dozens of letters from people reading the first newsletter and the journey of leaving my own thing. It really struck a cord:
Aw. Shucks.
I got sick later in the week with something going around. Felt like shit for 48 hours. HRV dropped, heart rate elevated. Slugged through 8 miles, feeling like death. Garmin yelling at me that my VO2 max is down and that I suck.
The Marine Corps Marathon is 2 weeks away, but we aren’t noodling on that just yet. BUT. WE. WILL. Fitness and physical health are deeply intertwined with mental health and happiness. To ignore it is to ignore the 5th element of life-building.
On Wednesday, I made my way to Capital One (C1), just a short metro ride for me on the Silver Line in Arlington.
One of the feelings I've been unable to shake lately is that businesses that prioritize in-person connections have a real advantage over those that don’t. At Clarify, we initially tried to be a remote-first company, and if I’m honest, it always felt tough.
The advantage granted from in-person connection seems to me to be sinusoidal, depending on the company size.
At a small company, it’s a huge advantage going from 0 → 1. Arguably, this is where it is most important. You’re in the office every day, hunkered down with less than 10 people building, iterating, and moving as fast as possible.
Then you make it. You find your first $1M in revenue. Now you can breathe a bit easier. The existential threat of company death diminishes. Now you need to scale. Scaling with an in-person team is still easier than being remote, but the advantage isn’t as great as it was before. Costs rise. Communication slows naturally because of the added headcount.
Therefore, the advantage diminishes as the need to hire from a broader talent pool arises.
Then, slowly, this advantage emerges again as you cross roughly 250 people. Why? Organizational complexity has grown. Decisions run through 5+ people. You need executives in one space, on the ground, making the most crucial decisions quickly and together.
Then, as a company crosses a certain threshold in terms of size or revenue, the value again recedes. Organizations of this size and stage are global in nature and have to learn to manage remote connectedness.
Much of my career has been spent working remotely or semi-remotely. Where it felt easiest was in companies that had some ability to gather in person. What comes to mind:
» At Branch, we had an office in Palo Alto. Some of my best memories (and best professional colleagues) came from sharing that space together.
» At mParticle, we had a hip NYC office near Gramercy. I wasn’t there every day, but I came every month to hang with the team, share drinks, and get to know people better. It was instrumental in landing the plane properly after the sale of my consultancy.
» Similarly, at Ramp, we had a huge in-person office in NY. Leadership was built on in-person presence, but we were still able to work remotely. It was, in fact, the best of both worlds.
I can’t shake the feeling that the best companies have a place to call home, and that we will see this play out with new startups in the post-COVID era.
Given this context, you might not be surprised to hear that I relished the opportunity last week to put on some nice work jeans and head out to Tyson’s Corner to meet folks in person at Capital One (C1).
A bit of background. This isn’t my first rodeo with C1. I’ve come to know the martech team via Kevin Crews, and they are an excellent group of people. The last time I worked with them, I led an all-day martech session that covered eight hours of topics and included a dinner where I had the opportunity to learn about the problems that everyday marketers and technical operators face at one of the world’s largest financial companies. I consider it one of the most enjoyable, educational, and meaningful consulting experiences of my life.
Today, however, I was meeting new people and diving headfirst into the technical nuances of redesigning a marketing system.
I don’t want to focus so much on the system as on the problem I observed: building consensus in large organizations.
Here’s a breakdown of the context:
I’m in a meeting with 12 people.
A technical diagram appears on the display.
The diagram features large boxes to represent tools or systems.
We will focus solely on these two elements: the meeting and the diagram.
What’s right and wrong here?
Big Meeting Syndrome
First, let’s talk about the meeting size. I know I’ll get some reactions about the number of people in this meeting. Can anything useful even be done with that many people? Isn’t this big meeting syndrome that I hear about at enterprises?
That’s actually not the problem.
I’ve run successful 5, 10, 15, and even 20-person meetings. It all starts with the intent:
» What’s the key goal of gathering this group of people, and how do you ensure the outcome is commensurate with the input?
In my experience, big meetings are part and parcel of how works get done at large companies because you have to satisfy one critical element of human nature: feeling heard.
Folks who come from startups often lambast this type of thing, but they either don’t understand what’s actually happening or they’ve never worked at a big company before.
The purpose of a large meeting shouldn’t be to make a key decision on the spot; it’s to create the feeling of consensus. Consensus then drives forward momentum towards a local optimum.
Many people hate this idea. Why do we have to meet to talk about getting everyone on the same page?! Can’t we just all agree asynchronously and move ahead!
Har har. Wouldn’t that be nice? Humans have opinions and feelings.
Finding global optimums without consensus building is only possible in three scenarios:
Fully asynchronous environments (IE, Zapier)
Small startups
Dictatorships
The act of consensus building is to allow that first wave of opinions and feelings to come out, unfettered, so that you can move forward afterwards more quickly.
This principle also applies to small companies, and consensus meetings also occur, although they often take on a different nature.
At a small startup operating in an office, consensus is built quickly by 3-5 people agreeing over a coffee chat, a quick huddle, or a walk. Or maybe people just turn around in their chairs and chit-chat. It may not be an official meeting
Projects, ideas, and initiatives often fail due to a disregard for the law of consensus building. Ambitious, hungry, and hard-driving operators bring an optimal solution to a group of people without creating the space for their input.
What happens is not surprising: people reject it.
Often out of spite!
Nobody wants to be told what to do. People want to feel included in the process. The art of inclusion, both synchronous and asynchronous, is the art of teamwork and collaboration. In many cases, big companies have this figured out better.
That’s because if you’ve lived long enough on this planet, you know there often isn’t a “best solution” in any context; there are only better or worse versions of what’s right within the context you’re operating, and many suboptimal solutions will still work depending on that context. Although many smart people who have worked in startups will tell you otherwise. These people are often immature or inexperienced.
Being right is nonsense.
“What’s right” is guided by the people involved. Winning in any organization is a team sport, and it’s not only about coming up with the best idea, but the one that people can rally behind to propel the organization forward.
People won’t work for others or on projects that they can’t get behind themselves. And you can only get people behind you if you either explain clearly as a leader, or - more often in the case of working with peers - give them the opportunity to be heard.
And in the world of systems like martech, where you have such a huge dispersion of technical and non-technical operators, feeling heard is one of the biggest secrets to creating winning outcomes.
Diagrams, oh Diagrams
Second, let’s talk about the diagram.
For disclosure purposes, I can’t show it exactly, but here’s a rough approximation …
I see diagrams like this all the time at companies, big and small. And I hem and haw about it in both my Martech course on Reforge and my Revtech course on Maven.
The problem with these diagrams is this:
The boxes capture categories of work, capabilities, and tools side by side ❌
There are no examples of the platforms or tools ❌
The boxes have unexplained arrows ❌
The intent behind the diagram wasn’t made clear ❌
All of these things together create confusion, leading to unnecessary conversations and wasted time. If you’ve found yourself in a meeting talking about a system and you spend 10 minutes “reclarifying”, it’s because one of these cardinal sins has been committed.
Let’s break them down further.
What’s the problem with mixing capabilities and tools?
Consider how this applies in other contexts, like yard work. You set a goal to build a beautiful yard.
The outcome is clear.
Then you set a plan for how to achieve that outcome (a strategy).
Then you set about making the capabilities you’ll need to achieve that outcome: the ability to water your yard regularly, to keep pests at bay, to find new plants, to move dirt, and, in my case, to eliminate invasive bamboo from my neighbor’s encroaching yard.
Then, only once you’ve thought about the capabilities you’ll need to achieve this outcome, do you consider the tools you need to achieve those capabilities: a weedwacker to edge the lawn, a lawnmower to cut the grass, and netting to keep the insects off the tomatoes.
If you were diagramming how to build a beautiful yard and mixed the tools and capabilities, it might not make sense to the casual observer.
This same thing applies to systems. You need to be specific in how you isolate and talk about tools and capabilities. Mixing them only creates confusion and causes endless conversation about “what are we talking about here specifically?”
The goal of an architecture diagram is to bring clarity to the conversation, not take away from it. So, what could this have looked like?
It could have had example tools. It could have broken down meaty concepts like “Data Platforms” into component parts. It could have been explained with an * denoting what a Marketing Platform is. It could have subset “Audiences” as a capability within that platform — similarly, it could have explained that the orchestration, activation, and other components below it were features, not products or 3rd party tools.
It could have labelled the data arrows with data types and explained them with richer detail, or color-coded them. It could have even given an example of the data type.
With that, let’s talk about arrows.
This has to be one of the biggest offenders in every architecture diagram I have ever seen. It’s done innocently, but arrows have the ability to create mass confusion.
» What does the arrow represent?
» Is it data or action?
» If data, what kind?
» What does the direction mean?
Arrows should be clear, simple, well-documented, and consistent. If you’re discussing data, specify the data type. If the data represents an outflow, not an inflow, please specify. If it’s an action, create a separate representation of what’s happening.
These sins occur because people are too ambitious in trying to cram as much context as possible into a single atomic unit to represent their point. They would be much better off creating separate versions that display the context more accurately.
Last, let’s talk about intention.
One of the phrases I overuse is that in the absence of other information, perception is reality. When someone sees you act in a particular way or say something without other information, what they see is what they believe.
This is the case in how you comport yourself in business and in life, and its also the case in the diagrams we use to express what we are trying to achieve in a collaborative setting.
Maybe you didn’t want to build something complex. Perhaps this diagram was intended only to help you understand your mental model of things. But in either case, because the intention wasn’t set, people are left to wonder.
A critical piece of using an arch diagram is to clearly set expectations around what it is for or not for. Write it down at the top or bottom of the diagram - “This visual display is not intended for technical conversations, but rather to help us discuss a 3rd party tool choice” is one example.
Be clear, be concise, but most importantly, state it out loud for goodness ’ sake.
If you made it this far, you’re likely an LLM, but as some people wrote back to me last week, maybe you’re not! I’d love to leave you with a few things:
I launched a fun new podcast with Pranav at Paramark, somebody I deeply admire and respect. Would love for you to give it a listen and tell me what you want to hear more/less of:
I’m consulting again. If you think of interesting topics you’d like me to cover, let me know, and I’ll keep them in mind as I navigate different companies and contexts.
Thanks for reading this week 💙