joined Managed by Q in 2015 (just before the Series A), to take on a dream scenario: help scale an incredibly complex operation with cloud software (especially Salesforce). Five years into its journey, the business had grown massively, honed team efficiency, out-competed rivals and was acquired by WeWork. But it was a bumpy road, and I’ll share my mistakes to help you avoid them.

My mission was to bring operational excellence to the company through software and process. There were a ton of things to take on, and the proposed first step was to implement Salesforce, a deeply customizable web app I had never used before. It was a serious undertaking with a massive initial scope. BUT, with some perseverance, I accomplished everything in our initial scope considerably before my first anniversary at the company.

By the end of my time at Q, we had a clean, reliable Salesforce instance that served every team at the company with powerful automation and data. People used it because it was useful to them, and it was deeply integrated with Hubspot, Intercom, Looker, Slack, Taskray, Truly, and dozens more apps via Zapier.

Yet, with years of hindsight, I’ve realized that even having successfully executed the company plan, I also unknowingly made painfully recurring mistakes

‍

Making and Executing the Plan

Scoping “Initial Implementation”

We had processes in place, but they were fragmented, so the plan (the sum of requirements gathering from ~5 team leaders across the company, myself, and our VP of Ops) was to bring every process at the company (dozens) under one roof, and improve them as we digitized them. We would call this our “Initial Implementation”.

What we did

We had already chosen Salesforce as our ‘platform’ before I joined. We then spent about a month vetting Salesforce consultants (references, picking one, designing Scope of Work). The “Initial Implementation” was estimated at 200 hours of consultant time, a reflection of a lot of work estimating planned buildout tactics, as well as roles and responsibilities for us and our consultants. It was a laundry list of Awesomeness™ for the team. Once we began, here’s how the execution went down:

• Immediately got Sales using Leads, Accounts, Opportunities, and Contacts, on minimal customization
• Conducted weekly status meetings across the 4 other stakeholder groups about progress against their portion of the “Initial Implementation”
• Along the way, opportunistically customized Salesforce to look just like our business: a home for every process and piece of data
• First major user migration 5 months in (fully moved support process into Cases)
• Consultants helped do deep training and rollouts to understand the highly custom processes that were built and the hidden automations at work
• Taught myself advanced Salesforce administration
• Completed initial SOW ~9 months in, mostly according to plan
• Moved consultants to a retainer for follow on work

So where were these “mistakes”? We no longer had fragmented systems, and everything was in one place, just like we had set out to in our “Initial Implementation” plan. People were finally happy with the system and using it a ton. Believe it or not, they are hidden in the above.

Diagnosing mistakes

While the mistakes made might have been hidden to me, some paradoxical symptoms were presenting (see if any of these sound familiar):

Heavy meeting and ‘communication’ overhead, yet:

• Company confusion about project priorities
• Lack of timeline clarity / accuracy

Feeling underwater with work, yet:

• Perception that progress was slow
• Value of delivered work was poorly understood

Lots of operational and data synergy, yet:

• Arduous rollouts
• Slow user adoption
• User error in core processes

Hindsight: What Was Wrong

First, even a cynic would be hard pressed to deny all the good that was done early on. We standardized and digitized processes, creating data around how they worked and what could make them better. Lots of terrible problems disappeared.

But when I look back at my first few months, I’m actually embarrassed at those early days. The reason? I had forgotten my mission in pursuit of the scoped project. My mission was not to make a digital home for all our processes. It was to bring operational excellence to our business by doing so. Considering that important nuance, the contribution of the “Initial Implementation” project was much more of a mixed bag, stumbling to reach the top of a unique hierarchy of needs.

Operations Software -  Hierarchy of Needs:

The top can’t be reached step by step. It took years to learn the thematic mistakes I stumbled on. I’ve made an effort below to summarize them, in the following 4 lessons.

Two Lessons From the Product Discipline

With the recent emergence of highly advanced workflow automation, GUI’s for API integrations between webapps, and the increasing use of deep customization in data models, configuring 3rd party software is no longer administrative work. Creating bespoke user journeys in software is Product work. It should borrow much from modern Software Development Life Cycle techniques, which have evolved considerably in the last decade. Operational team leaders and career-IT-admins overwhelmingly lack depth with these philosophies.

This blind spot leads to many mistakes, but most universal and dangerous is the tendency to get sucked into a scope creep feedback loop, resulting in massive batches. You know it when you see teams conflating many business objectives under a single project name, often a reference to a nebulous object or ill-defined process (like “Opportunities 2.0”, “Universal Activity Tracking”, “Billing”, and yes, “Initial Implementation”).

What can be done?

1. Clear outcome goals should precede all else

Our post on this a.k.a "Outcome-First Operations"

Relating this lesson to my “Initial Implementation” project:

• I overbuilt for business concepts that changed. Sticking to a plan for 9 months was a mistake and is rarely the right course of action with software
• Lack of synthesis of where our data model was going led to pages littered with checkboxes
• I structured processes that were happening on a small scale (<5x per week team-wide) and in many cases, working just fine (for now) without dedicated software
• Bundling work into large batches of value made for longer wait times, slower feedback loops, greater scope confusion, and put people ‘out of sync’. A 200 hour SOW under a single project name should have raised another huge red flag, and an initial rollout fully five months into a software project is a sure sign we shipped too slowly
• In doing the above, I put dozens of nice-to-haves in front of every outstanding need-to-have. I learned that Awesomeness™ is not an outcome. Some impeccable mentorship from my manager taught me the value of knowing what’s important (his post on the topic), and my team prioritized and started delivering immense business value as a result

What I’d go back and tell myself: Think critically about the components of business value behind feature ideas, and redesign your approach, seeking the smallest increments towards business value that you can. If it takes you more than two weeks, the project is too big. Split it up. If the batch doesn’t contribute business value as a standalone, you’ve split it up incorrectly.

2. Prioritize by saying no

Our (incredibly short) post on prioritization

Relating this lesson to my “Initial Implementation” project:

• I struggled to give the team an estimated ETA on ‘when Salesforce will be done’. This was a reflection of how overloaded the word “Salesforce” was (dozens of projects, with more being added all the time). Weekly meetings and impromptu conversations with 4 teams was burning about a day per week on ‘status updates’ that, individually, each didn't have much progress to communicate. Impatient managers had a weekly forum for adding half baked ideas ‘to the list of stuff to do’, a vicious cycle taking my eyes off of real business goals
• But even more, my mistake was in concurrently running many projects at the same time. By taking work off my plate, undergoing the pain of saying no to stakeholders, and focusing all my effort on one or two clear business Outcomes until they were shipped, I nearly tripled the output of my team and delivered the average individual project in a quarter of the time. This has been the single most shocking and powerful epiphany of my career. WIP limiting is miraculous.

What I’d go back and tell myself: Take your list, and move everything off of your plate. Look at all your options, and figure out which one or two items will have more impact or you need to do more urgently than all others. Then, make sure each of those items is a unit of business value that you can accomplish in less than two weeks. DO. NOTHING. ELSE. No meetings, no email threads, no Google Doc comment chains, unless they are pertinent to your active project (you can find room for project prework after you master WIP limiting). The harder it is to do, the more you’ve created real priority.

Two Lessons from the Operations Discipline

Designing operations software with the ‘user’ in mind is complicated. Usually, a manager is the stakeholder and requirements setter, but the end user is actually the people who report to them. The manager typically becomes too prescriptive about what should exist, compounding on the aforementioned mistake of underinvesting in outcome clarity. This disconnect leads to problematic design patterns, favoring edge-case-laden mental models that reflect their own operational ambition, not user-centric journeys to accomplish outcomes. Ultimately, you get user error in core workflows (whether from confusion or disregard).

What can be done?

3. Always make workflows and automation dead obvious

Our post on making automation obvious

Relating this lesson to my “Initial Implementation” project:

• That our initial rollouts needed ‘deep training’ should have been a red flag
• Many projects took as long as they did to build to actually get them rolled out to the team, or required lots of follow on work to fix usability
• Furthermore, training new employees or making changes to existing workflows became increasingly expensive over time
• Eventually, core processes ballooned into having many (often annoyingly required) steps; and worse, the steps were easy to get wrong
• Automations that hopped over to a different team or piece of software were easy to misunderstand because only institutional knowledge could predict they had occurred
• Admins got tons of questions about why things were happening, or weren’t happening, or by whom. Users didn’t know when they were in the driver seat vs. the passenger seat

What I’d go back and tell myself: You should have user confirmation that every new process you build is intuitive. When you automate steps of a workflow, make the automation obvious to your users. (e.g. don’t be afraid to throw a Chatter @mention at your user telling them something happened, on the object it happened to.)

4. Data is only valuable if it helps you make decisions

Our post on Decision Centric Data

Relating this lesson to my “Initial Implementation” project:

• Managers became greedy: they underappreciated the cost of many small operational hurdles for their teams, and overestimated their own process design and future use cases for data. I shouldn’t have been proud of building ‘highly custom’ processes until we were all sure they were part of our company’s winning formula. Some were, many weren’t. For example, our agents were required to tag every customer support email for nearly two years. I finally killed this process because we NEVER. ONCE. USED. THIS. DATA.
• Put the needs of end users before managers and do enablement upstream first. If you have a workflow, always find the best tool for the work doer.

What I’d go back and tell myself: Never ask a user to manually log information or tag objects unless it will directly help you make a specific decision you need to make. Never add steps to their process unless you are certain it will better accomplish specific business goals. If in doubt, ask the manager to define the goal, and ask the end users if they think the step will contribute towards the goal.

Summary

Deeply customizable software, advanced workflow automation features, and developerless integration tools are incredibly new and poorly understood. My position is that many of the people who are tasked with this type of work lack best practices and strategies that will help them succeed. Through my experience leading a team whose mission was to pursue operational excellence through operational software, I took away the above themes as recurring lessons. Over time, we became excellent at avoiding these mistakes. This is a domain that will grow much deeper. Still, it shouldn’t scare away newcomers. Despite many mistakes and lessons, we did manage to accomplish business outcomes more quickly and cheaply, even from the beginning.‍

This is why we created this consultancy: to bring this experience and advice to help companies get the most out of their software.