The Spectrum
“It is literally true that you can succeed best and quickest by helping others to succeed.”
- Napoleon Hill
It’s natural to assume supporting an organization is the same as being its partner. Including “partner” in job descriptions is commonplace - HR Business Partner, Finance Partner, etc. - but it’s a trap to believe one inherently encompasses the other.
Supporter and partner aren’t synonyms. They’re gradients on a spectrum, with the distinction lying in the personal investment each side makes in the other.
In a supporter relationship, there is a clear boundary that delineates where the each function begins and ends. They may be parts of the whole, but rarely does either side invest the time or effort to extend beyond its borders.
Partnership, on the other hand, adds value beyond the box you’re required to check. You’re involved throughout the process, helping to shape the discussion around the problem and the solution regardless of title or department.
Over the last six years, I’ve thought a lot about how to embody a partnership ethos, particularly as my team has grown. Countless behaviors help us move along the spectrum, but simply documenting and evangelizing them doesn’t scale. A framework is needed whereby high-level principles can guide day-to-day behavior when specific heuristics either don’t exist or aren’t easily recalled.
For us, a simple ABC framework has served that purpose.
Aim to assist
Build clear boxes
Circle the square
Aim to assist
In the words of Wayne Dyer, our intention creates our reality. Partnership, at its core, is an intention to help someone else be successful.
This may seem obvious, but it takes significant cognitive effort to maintain this mantra day-to-day. As I mentioned in Being Useful, we are most effective when we focus inwardly, which becomes a challenge when our desire to make an impact pushes our focus outward.
For example, a well-meaning Finance employee may believe they are most successful when helping the business stay on budget. This can evolve into dictating what the business can or can’t do, rather than working with the BU on how objectives could be achieved within budgetary constraints.
The key is to step back and ask yourself, “Am I being useful?” If that feels unnatural, here are a few other ideas to maintain an aim to assist:
Look for friction points. Some friction will always occur, but you’re looking for unnecessary tension that stems from situations that are harder than they should be.
Start with why. Most requests are for actions that should be phrased as desired outcomes. If you lean in to understand the latter, you may be able to revise the former.
Challenge your assumptions. A supporter starts with can / can’t based on what they know. A partner starts with “how could we” or “what would have to be true” to achieve the desired outcome.
Build Clear Boxes
A black box exists when the internal workings to convert inputs to outputs is opaque to anyone outside the system. Black boxes are typically described in software/hardware environments, but they could be anything - systems, processes, or decisions. To increase trust, you have to identify what black boxes you’ve created and made them clear.
The goal isn’t to flood people with information - they don’t need to know the details of how the sausage is made. The goal is to provide a line of sight into how their inputs convert into your output. The goal is collaboration which requires a base of shared knowledge.
Here are a few ways we’ve applied clear-coating:
Close the loop. When a request or input is received, acknowledge it within 24 hours. That could be a response, a clarification, or a note to say it’ll take us a few days to look into it. The point is to shorten the “abyss” - the period between reaching out and having someone reach back - and set expectations as early as possible on what comes next.
No grand reveals. Classic storytelling suggests the best way to tell a story is build-up to a conclusion, a grand reveal, that rewards the audience with the coveted “aha!” moment. The reverse is true in partnership. Whenever possible, we lead with the conclusion to replace that anticipation with discussion & reflection. No one should have to sit through a long PowerPoint presentation to learn about the fate of their business, initiative, etc.
Simple without over-simplifying. Finance models are complex, spanning multiple Excel tabs with a litany of formulas that could easily be corrupted or broken. No partner should be subjected to such detail, but at the same time, they should understand what goes in and why it comes out the way it does. We use simple one-pager templates - stripped of the nuance while maintaining material accuracy - to show how the process works and give partners a chance to play with it as well. The easiest way to build trust is to show you’ve got nothing to hide.
Circle the Square
Constructing a square with an area equal to a given circle is a task proposed by ancient geometers. Starting in 200 BC, people tried to solve the problem until 1882, when Ferdinant Lindemann proved it mathematically impossible due to the transcendence of pi. “Squaring the circle” became a popular idiom to describe something that was impossible.
It’s worth noting that one can construct a square whose area is reasonably close to a given circle if you use an approximation of pi (e.g. 3.14) instead of the real thing. It’s not perfect, but more often than not, perfect isn’t what we’re after. I refer to this process - making the impossible more tangible - “circling the square.”
When faced with an impossible task, our first instinct is to point out why we can’t do it. There’s not enough data, or time, or resourcing. But that’s life. Big decisions often revolve around some amount of unknown. Dwelling on what you don’t know doesn’t add any value.
When the stakes are high, a partner looks past the constraints and identifies what is possible. There will be caveats and nuance, for sure, and as mentioned above those should be clearly identified. But identifying a problem is simply providing support - coming up with a workaround is partnering.