Tools are Divisive

If you work in a software-as-a-service (SAAS) organization, you likely encounter a group of people that are (for better or worse) referred to as “Software Decision-Makers” (or SDMs). These are the people who can buy and/or approve the purchase of goods and services on behalf of the organization. In small organizations, the overlap between the “end user” of a piece of software and the SDM is quite large (think of a founder or early employee buying something for themselves/their team), whereas large organizations have incredible distance between SDMs and end users (i.e. finance, legal, and other individuals dedicated to “procurement”).

As I was riding with Max this morning, I shared a bit about this project and some of the insightful conversations I’ve had as a result already. Max — in addition to being a brilliant designer and product thinker — is in the middle of an organizational transformation himself as Uber has acquired his employer, Postmates.

I shared the organizational pace layers with him, and our conversation turned to the topic of SDMs and who was going to be making what decisions as Uber and Postmates moved forward. This conversation helped crystalize something that Nicole Zeng did incredible research on during our time at Slack (which I don’t have access to, but would love to share):

End users and SDMs prioritize different organizational pace layers when they make decisions, especially about tools.

This decision about tools and purchasing was top of mind at Slack as we’d seen incredible bottoms-up adoption (Slack starting with one team, then growing slowly to the entire organization) much before we (at least as I remember it) had a dedicated sales motion for large enterprises (what you’d consider “top down”).

When it comes to decisions about tools, end-users prioritize the layers of work and communication. They want the tools that will best support them in doing their jobs - often choosing those that reduce friction, provide leverage, or otherwise feel en vogue.

Unlike end-users, when SDMs make decisions about tools, they prioritize the layers of process and culture, considering the (human and capital) costs of implementation, integration, and maintenance (which you could argue are their layers of work and communication).

Both groups tend to assume that the other layers will adapt to the new tools. End-users probably underestimate the kind of inertia they need to overcome to make process and cultural change, and SDMs underestimate the importance of speed and control in work that employees want. Obviously, this is a bit of an oversimplification, since purchasing decisions also involve broader business relationships and financial considerations - and it’s unlikely that finance teams(or end-users to be fair) have a concept of “value” for a given tool. More often you’re talking about these decisions in terms of TCV or “total contract value” - which is much more about cost than value if we’re being honest.

Choosing your own tools

Something I’ve wanted to write about as it relates to starting Yet Another Studio (and working for yourself more broadly) is the freedom to choose your own tools. I’ve been operating the studio under the principle of “minimum necessary infrastructure,” which means that I’ve been choosing the tools that are best for me and my work - rather than the communication about and representation of work (as I might in a larger organization that needs such visibility). I build process on top of that, which is admittedly very limited at this point.

This situation highlights the fact that as I am both the end-user and the SDM, I can think about making the best tool decisions with work in mind and build the process to support that, rather than try and pick tools with process in mind, in hopes that such a process will be flexible enough to adapt to the changing pace and needs of new work and new clients. It’s almost as though the pace layers have collapsed/blurred for me as an “organization of one” (though they are much more visible as I work with clients) because “process” is simply patterns of work/ways of working that I’m repeating.

Some things I’d be interested in hearing from folks about as it relates to the above:

• Where have you run into challenges as you try to bring a new tool into your organization? How/where were these expected or unexpected?

• Which organizational pace layers provided the most inertia? How did you overcome them?

• What are your strategies for easing adoption of new tools into your organization - besides having an SDM as a champion or sponsor?

Thanks to Max and Kevin for providing feedback on these ideas.