Adopting the Collaborative Operating System, Confronting a Common Leadership Error, and Fixing the “Untrained Muscle” of Alignment with Plum’s Co-Founder, Caitlin MacGregor


Alignment,” at least in the cursory, dated-business-book sense of the word, has certainly overstayed its welcome. In the following exchange, Plum’s co-founder and CEO, Caitlin MacGregor (@caitlinmacgregor), records an earnest rendition of what it really means for a team to be aligned.

With a reflective probing of the limitations of her own leadership style, a weighing up of oft-recommended frameworks, and the work of constructing cultural scaffolding that enables a VP of Engineering to contribute, as critically as a CRO, to a breakthrough RFP win.

Recognizing why different ways/goals of operating must eventually cohere
Why most alignment frameworks have an “accountability” problem
How Plum has adopted the Collaborative Operating System

How (not) to end up with siloed leadership

A great way to introduce the premise of this framework is perhaps to briefly introduce what we’re building at Plum and why that led us to question how we were operating.

We’re a platform that helps companies hire and retain talent that really is measured based on human potential. That is focussing on quantifying someone’s innate, transferrable capabilities. Things that, one job to the next, scientifically make them successful.

As the research is clear. It isn’t about hard skills or past experience. Not what schools they went to. Not the internships they’ve had. Not what brands they’ve worked for.

It comes down to quantifying the core behavioral needs of a given job and then matching people’s natural leanings to those. Ultimately pairing people up with jobs that’ll make them the happiest, most fulfilled, and accomplished in the long term. Greater performance, of course, means greater retention.

Being a company that quantifies human potential and focuses on people thriving in their roles, the bar is set pretty high, in terms of us drinking our own champagne.

So we obviously use our own tool for hiring, onboarding, and attending to a new hire’s development across their lifecycle.

And when I started hiring senior executives at Plum who came from really mature organizations, and brought along really high expectations in terms of leadership and operating structures, a personal realization quickly became apparent.

It was the awareness that areas that allowed me to thrive as a leader could also be draining for the rest of the team.

For instance, I thrive in chaos. I can adapt and iterate based on anything that’s thrown at me. Which is fantastic in an early-stage startup environment, but when you’re the CEO, responsible for guiding an executive team, you want anything but chaos.

The most important thing is to foster sustained alignment on company goals.

Also, my leadership style early on was really, “hire the best people for the job and get out of the way.” Informed by what had enabled me in my past work. Leaders who had never micro-managed and had trusted me to do the right things.

Well, that doesn’t always work.

When you entrust your department heads to solely run their own functions, you can end up with very siloed leadership. All, independently (with great intentions I must add), running in different directions.

This creates a place where finger-pointing becomes rampant. Assuming some or the other form of: “My job is just to make marketing/product/sales/finance work.” Or, “We failed because this person in this other team isn’t doing their job well.”

A lot of this was stemming from me. From the fact that I personally didn’t need an overly processed directional sense and structure as an individual. I loved checking off tasks on a to-do list, but not necessarily building systems to make those tasks more efficient.

I had to change. I had to earn the right to retain excellent talent. And I could only do this by providing alignment and a clear strategy for collaboration. A north star that all of us could contribute to. And, most importantly, a framework that supported us as we pursued this change.

Searching for a system of collective ownership

First, we settled on a cadence of quarterly goals cascading from a larger annual goal.
And I knew that if I was going to do this every three months, I needed a process that I could build once and run over and over again.

Next, I started looking for frameworks we could study and adopt. What immediately stood out to me as I was doing research, was that most of these operations frameworks relied on an underlying theme of keeping people accountable.

They all seemed to start from a place of “I don’t necessarily trust that you’re going to do what you said you were going to do, therefore I’m going to make you write it down and make you report back. Because without this level of accountability you’re just going to collect a paycheck and not deliver.”

All seemed bent on isolating who owned a given function and how exactly were they missing the mark. And, to me, that was simply backwards.

Because if you’ve hired right, people will be driven to get their job done; you wouldn’t have to chase anyone on their execution. What they might not do is take the time to align with the rest of the team on what the right collective goals are.

So I wanted something that went beyond “what am I going to deliver as a department?” and got to “what are we owning as an exec team holistically?”

I wanted that collective ownership to ensure that with the amount of people we had and the amount of resources we had, what we were biting off for the quarter was achievable.

If the product team was being pulled in one direction by engineering and being pulled in another direction by marketing and then in another by sales, I wanted their goals to have enough room to accommodate the different priorities.

I wanted a system that could communicate, “hey, these meetings, with these other departments, on these joint concerns, need to take priority over other things.”

After reviewing various approaches, I finally settled on taking a professional development course (which lasted a year) called the Collaborative Operating System (COS); it helped me learn the mindset and principles needed to build true collaboration.

The COS training showed me how I could create a culture that wasn’t top-down, had joint ownership and collective buy-ins, where everyone was organically trying to accomplish something together.

Then I reached out to consultants who had run several alignment efforts with executive teams at companies similar to ours, to understand what the common challenges were.

And one of them told me, “what happens is when a VP of Engineering is giving their update, the sales leaders’ eyes start to glaze over as it doesn’t relate to them.”

“This update isn’t getting you anywhere. It’s not benefiting the company. It’s not holding anybody more accountable than others. Because people always have a way of making themselves look good.”

When I asked her how she had countered this in the past, she said, “what I’ve found to be especially helpful is to create goals together as a leadership team.”

Figure out what at the company level are you collectively creating together. Don’t have department goals first. Have company goals first. So that everyone is owning them.

So if you set a sales target, that is a sales target that engineering realizes they may have an impact on, because they may have a customer request they can help prioritize to unblock a deal.

Or they may have due diligence on the security and the infrastructure side that they should be part of and have joint goals where everyone can see themselves reflected, and that they’re jointly owning that goal.

If someone has to drop what they’re working on to jump in and help they know that that’s the right use of their time. Thus we had to come up with quarterly goals that each of our leaders saw as their departments being able to support and drive.

And not every single goal necessarily involves every single department, but the more we’ve done this, the more we actually see how every single leader is tied to delivering on every goal that we’ve laid out.

When we began saying, we wanted to hit this revenue target together, for the first couple of quarters, product and engineering felt they couldn’t possibly directly influence revenue goals.

Well, we just won a huge RFP.

And our VP of Engineering played an integral role in us winning the RFP. He dedicated a lot of time to being a part of the presentation, doing prep, and creating visual mock-ups so that the customer could better understand what was going to happen from an implementation standpoint.

He had to put down other things in order to do this. Because we were all aligned on how important this was, it made sense that the VP of Engineering was playing just as much of a part as our CRO in the RFP process and we won it because of that alignment.

“Getting everybody to row together is an untrained muscle”

The way that Plum’s COS works is, each leader, independently, marks an org-wide, quarterly goal as green, yellow, red, or grey:

Red: We’re not going to accomplish this goal by the end of the quarter. So either we need to change the resource allocation or we need to maybe recognize that this is no longer a goal. Or we need to have a serious conversation about why something is red.
Yellow: It’s mostly on track and if we were to course correct, we can get it to a green by the end of the quarter.
Green: Which, of course, means we are perfectly on track.
Grey: Essentially a leader saying, “I have no idea where we are at with this goal, I’d like an update.”

These individual reviews are done async and in advance. So when we meet each month to conduct reviews, instead of running through passive updates on, “we’ve done what we said we’re going to do,” we’re actively discussing how we can act together to influence a goal’s trajectory.

Let’s say, three leaders said “green” but two people said “grey,” well, let’s give them an update. Then we’re going to the next one. Woah, one person says “green,” one person says “yellow,” one person says “red.” You know what that just signalled? We’re misaligned.

This exercise facilitates real strategic conversations every month.

The COS practice also raises the stakes of being explicit. You can’t just assume people get the goals. So a big part of the work is being explicit and making sure that leaders can cascade that clarity down to department goals and then into individual goals.

Developers should see how the work that they’re doing contributes towards unlocking revenue; towards ramping up those upsells; towards the pipeline.

At the end of the day why are people coding? Well, they’re coding to accomplish a bigger business strategy, that strategy needs to be clear and explicit.

A related endeavor that has helped is establishing a cadence of cross-departmental meetings. Constant touch points, every other week. Product and customer success meet. Product and sales meet. Product and engineering meet.

It filled up people’s calendars. And at first these meetings were almost universally resisted. But then people found out that we are saving so much time by getting aligned upfront. We’re steering clear of many, potentially time-intensive problems way in advance.

It was a real change to develop the right cadence and we constantly have to reevaluate it as we get new leaders in, and as we set new priorities

Are we meeting too often? Are we meeting too infrequently? Who’s setting the agenda? What’s the type of agenda? Are these meetings that need advance prepping or are we carving out time to sketch the solutions/challenges together?

I think the biggest thing is understanding how to align an entire team around just a few key goals and getting everybody to row in the same direction, is, for most companies, an untrained muscle.

That’s why COS is the operating system we run on as a team, a vehicle for bringing collaborative thinking to every single decision we make.

Related reading from the Relay archives:

Tara AI’s co-founder, Iba Masood, on workflows and culture that tie engineering with growth


Hey @caitlinmacgregor, I can attest that recognizing how one’s own strengths or ways of operating might be getting in the way of teams, is a harsh lesson to learn for any founder. And it’s great to hear how you took the academic route to find a system that led to progress. What was it like, studying and building in parallel? Any recommendations for fellow founders who’d want to do that? Thanks for sharing such an important part of the Plum journey on Relay!


Building a start up is all about learning and building at the same time. Normally I’m learning from the trial and error of doing, as well as hearing lessons learned from Peers. Taking a course on learning some fundamental principles was key to get me to fully wrap my head around a fundamental change I needed to make. The course had a study group component with homework that made me constantly have to apply my learnings, which was a style of learning that really resonated with. It basically allowed me to trial and error with the course material. Not sure if that answered your question. Happy to take more questions.