BizOps—or, Business Operations—is more important than it’s ever been.
Ops teams, after all, are the people best suited for meeting the business challenges of the present. But ops teams still face impediments and challenges that inhibit them from going about their mission-critical work with true agility.
Some of these challenges are structural, like finding better ways to work with IT, and extend back to the very beginning of BizOps’ emergence as a business function.
To understand how to remove the obstacles BizOps still faces, it’s important to understand how BizOps became so important in the first place. The answer to how ops teams can better collaborate with IT, for example—and from there step fully into the roles operations teams were created to step into—resides in the history of the BizOps function.
That history, as it would happen, is intertwined with the history of IT. But this is not a story about ops versus IT—it’s a story about centralization versus decentralization.
The rise of BizOps is rooted in IT’s origins as a support-side function inside particular business departments. BizOps is a product, in turn, of IT’s transition from decentralized support function into a fully centralized department serving entire organizations. The limitations inherent to that model gave birth to the imperfect paradigm that remains in place today—where ops and IT fill both roles, respectively.
To understand why and how any of that even works, we have to go back to 1936 and visit a young finance guy named Alfred Zipf, who went to work for Bank of America..
Zipf’s first job at BoA was sorting checks by hand. Later in his career, he was instrumental in developing and implementing technology that automated the reading and sorting of checks, which simultaneously sped up the process and made it less prone to human error. This innovation came at a critical time, when the number of checks being written industry-wide was exploding.
What’s most notable about Zipf’s contributions is that he wasn’t a technologist who insisted on implementing the latest computing technology. He was a banking operations manager who identified a bottleneck to processing checks and pursued a business solution that would solve it. It just so happened to be technological in nature.
In effect, Zipf and employees like him were becoming embedded IT personnel, leaning into a role where they provided technological support for the finance department. This model was successful, but in order for other departments to repeat it, it was clear that the secret sauce was not about technology per se; it was domain expertise.
The technology experts over in Zipf’s finance department had been effective not just because they were good at technology, but because they were finance people who understood finance. This paradigm was repeatable across any department—legal, marketing, HR, and so on. Over time, more decentralized IT orgs grew inside companies on the back of domain-specific operational talent.
This began to change with the rise of the internet, which set in motion a great many changes (to use the understatement of the century). These included email, databases, and more.
The changes also introduced new challenges. After the burst of the dot-com bubble, in the early 2000s, CIOs were pressured to cut costs. One result: certain aspects of IT became commoditized, and many more aspects of it became centralized. (For a sense of how this happened, consider IBM, which centralized IT in the first years of the new century. Whereas before it had some 128 business units, each with their own IT leadership, a wide scale reorganization consolidated all IT as a shared service overseen by a single CIO.)
That makes sense, right? This model puts every available IT resource under one unified roof to more broadly serve the entire organization. (Also, it’s cheaper than having 128 separate IT departments.)
Well… sort of. There’s certainly a level of IT support that can and should be commoditized and centralized. But everyone knows the punchlines about the shortcomings of this model.
It’s not the fault of IT professionals. These are people who specialize in things like system administration, coding, software development, and so on. Yet, they’re constantly being asked to bring technological solutions to bear on complex, domain-specific problems, like within HR or legal.
Asking a software engineer to be responsible for building an HR onboarding automation is like asking a pastry chef to make a seafood dish. Sure, they work in the same kitchen, and both are skilled—but they’re skilled at different things.
Frustrations over such issues is what led to the birth of BizOps as we know it today. Dan Yoo, who first made his mark by helping to build and grow LinkedIn’s business operations team from 2009-2014, remarked in a blog post that he first encountered business operations (he called it “BizOps”) in the early 2000s, when Yahoo!’s Jeff Weiner built a team designed to give him the “levers he needed to move the company forward.”
Yoo quite neatly described BizOps as “a decision-support mechanism that helps with everything from optimizing day-to-day options to carrying out high-priority initiatives to tackling the most important strategic questions.”
BizOps served as a link, in other words, between business units and IT—as a force for business enablement, which a centralized IT department simply isn’t designed to do. And in time, guess what happened? Individual business units saw the value of that link, and they each began adding their own operations people.
What does that look like? It looks like the original, domain-specific model of IT!
It turns out that our man Alfred Zipf, a pioneer in IT, was not an IT guy as we know it today—he was an ops person.
A perfect solution, however, this new paradigm is not. It comes with built-in challenges. Turf wars. Battles over access and permissions. These are the challenges that hold back operations teams today—and likely frustrate IT to no end, too.
So how do you make this work?
That’s why we’re telling this story; the answer’s in the history.
The first and most important thing to remember is that the purpose of support personnel, be they IT or ops, is to better enable their organizations to conduct their business.
Think about this: Why do companies centralize their IT instead of leaving it up to each business unit? Control. Access. Accountability. Security. Visibility. Avoiding duplicative SaaS purchases (you don’t need every business unit to buy its own Salesforce instance, for example).
But these are not structural issues; they’re decision rights issues. Susan Cramm of The Harvard Business Review articulates this well (emphasis mine): “In allocating rights, a loose rule of thumb is that line managers should have authority over what services are delivered, and IT should have authority over how the services are delivered.”
She went on to say, “No longer should we ask, ‘Should we centralize or decentralize IT?’, but rather, ‘How do we decentralize IT in a centralized manner?’”
To put it in layperson’s terms, a possibly more symbiotic and productive model of Ops/IT collaboration could look like this: IT should be responsible for making sure nothing stupid happens inside of Salesforce. Meanwhile, Ops should make sure that Salesforce is actualized to its fullest potential—that the team is using the right values inside of drop-down, that they have the right process from stage one to stage five, and so on.
Another way of understanding how IT and Ops play nicely together is the RACI concept—responsible, accountable, consulted, informed..
The RACI model is a simple and clear way to identify who is in charge of what roles around a big task or project. It helps groups determine who is responsible for the actual work, who is accountable to ensuring that it’s done, who needs to be consulted about various details, and who simply needs to be kept in the loop.
Traditionally, IT has been responsible and accountable for things in the domain of business operations. That leaves Ops people consulted and informed but with no ability to do much, and of course IT is burdened with nearly all of the labor, which in turn creates bottlenecks to important tasks.
But you can shift those roles around to make things better for both groups. For example, with their Salesforce automations, Ops needs to be responsible for things like creating and updating accounts and contacts, managing invoices, and so on—and they can be accountable for major tasks within those boundaries. Meanwhile, IT is still accountable for governance and oversight. Ops can consult IT about issues and questions that extend beyond their technical depth and keep them informed so they can provision rights access and conduct day-to-day maintenance.
If the right parameters are put in place, IT gets to maintain its most important functions of gatekeeping security and maintaining controls, while Ops can run freely with whatever it needs to do to maximize its business unit functions.
Ops teams are a bridge between the business and IT. This is Ops’ innate function, grounded in history. As it was conceived initially—that’s how it should work now.
The key to success for organizations moving forward—the key to increasing efficiency, improving their operations, empowering more employees inside the organization to operate with agility and true creativity—will be finding a way to effectively get out of Ops’ way.
The first step is studying up on your history. The second, however, is considering what tools both Ops and IT might need to this end. We recommend technology built specifically for that purpose, such as a platform that breaks down bottlenecks and abstracts the technical expertise required of solving thorny operational problems, while allowing IT to maintain its critical controls over things like security and costs.
Want to see what such a platform looks like or what, more specifically, it should do? Click here.
Oh, and if you enjoyed this historical deep dive, check out our newsletter, Ops Digest, which’ll send more long-form articles just like this directly to your inbox every month.
