BizDevOps: The way to bring technology to the heart of business (and build bridges along the way)

As technology becomes more sophisticated, sleeker, and sometimes hidden from public view, it tends to become more accessible for more users. In this process of tech democratization, a perceived ease of use and the abstracted, aesthetically pleasing technology make many people think: “Hey, we can do this ourselves!” That’s not necessarily a negative thing when it comes to an iPhone. Yet when it comes to colleagues of ours who are not developers or engineers, but rather responsible for our company’s primary operations – what we call business or, for short, Biz – they might get overeager. Faced with new technology such as public cloud services, low-code solutions, or other SaaS offerings that promise to improve daily operations and activities, business does not want to wait for IT’s advice. Moreover, business and IT rarely communicate or, if they do, they speak different languages. The issue, though, is that the technology’s actual complexity hasn’t disappeared, and misunderstanding that can cause difficulties for business in the long run. Hence, the need for IT experts to try to understand the business problem.

Meanwhile, these days business expects more from project teams than the by-now standard DevOps way of working. They expect developers, engineers, and all of IT to simply understand that technology development and operations should serve and support the company’s goals, not the other way around. DevOps practices have had a hugely positive impact on teamwork. However, the DevOps paradigm focuses on the more technical aspects of delivering value as a team. It doesn’t necessarily give business stakeholders reason to expect to be drawn into the actual development process. In fact, business requirements (let alone desired outcomes) tend to get lost in translation. This is why a solution provided by the development team rarely addresses the needs of business, and little value is delivered.

From 2012 onwards, DevOps is the way we’ve worked at Schuberg Philis. That wasn’t what we called it, per se, but it captures the spirit of our work culture. We also learned a lot along the way, moving up the stack to fulfill our customers’ more functional, less technical needs. Before long, it was clearly more fitting to call what we do BizDevOps. In fact, our customers have always been organizations demanding IT solutions that power their mission-critical activities and simultaneously respond to areas fundamental to their business. It’s in our DNA, therefore, to incorporate business priorities in all projects’ development and operations. So how have we managed to keep bridging that divide between business and IT?

Getting in a room and shutting the door
When we’re about to embark on a journey with a customer, one of the first things we do is establish which roles their business people can fulfill. This can be tricky because today IT is mostly still totally separated from business. It’s separated within different departments as well as when, if outsourced to a third party, between organizations. Neither side understands the other, yet both expect the other to do more to understand them. There’s a lot of finger-pointing and, as a result, fortresses, islands, and silos get built. But thoughtfully reaching out to the other side and inviting its members to cooperate prevents the corporate immune system from kicking in. The healthy outcome we observe is less bureaucracy and greater efficiency.

Before the start of the project, the involved people make themselves available and we all go and sit in a single room. We close the door. Call this a cross-functional team, self-steering team, or the first step in co-creation, this step is about putting the people with the right knowledge, expertise, vision, passion, and mandate together. We refer to this as getting the whole system in the room. In this setting, there’s not much hierarchy. It’s all about moving unnecessary management and overhead out of the way and putting experts in the lead.

Crossing over to the other side
Next, we strive to transcend the typical transactional customer-supplier relationship. We do this by crossing over into each other’s Biz, Dev, and Ops spaces and committing to bridge-building. Ideally, Biz then takes more ownership of tech decisions and understands better what‘s needed, non-functionally speaking. Dev then commits to understanding the desired business outcomes and the deeper functional why before building any solution. Ops, finally, configures logging, monitoring, and telemetry as such that they contribute to tracking the defined business outcomes. Since all sides are playing on a single team, there’s no finger-pointing. They become true teammates.

The challenge, however, is to find people from IT and business who can operate in this bridged middle ground area and won’t meet resistance from the business or IT sides, respectively. This is not a walk in the park. It takes people committing to honesty and vulnerability to genuinely understand the other side. Each side has its own language and practices. Business people are often coping with milestones, budgets, and release deadlines. Engineers are often seeking to understand the why behind the what before sharing their advice, much less committing to a deadline.

The product owner, also known as a component owner or a value stream owner, basically acts like an orchestra conductor, directing the harmony and tempo of business, development, and operations. Crucial for the success of the BizDevOps way of working, the product owner is like a mini CEO who should be fully mandated to make decisions on behalf of business.

Starting with the business need
In our projects, the starting point is the business need. Within a project team, we ensure business, represented by a product owner, defines the need. Its requirements should be detailed and refined enough for the developers and engineers to plan and build them. Final functional testing should be left to business to actually verify if the proposed solution meets their needs. Once that’s done, the team focuses on release and deployment, gathering and monitoring data to learn how a particular solution is behaving. That information about technical and functional operations is used to create primary input for the team. This input is taken onboard by business and, based on their learnings, gets translated into new wishes and requirements.

While BizDevOps is highly suitable for kick-starting a project, ultimately it’s a structural way of continually delivering value. That means it is also useful during the run phase. It encourages the team to stand in the shoes (or sit in the chairs) of end users, so everyone can feel what they experience when they have to wait five seconds upon each and every login. Getting into the same room from day one creates an atmosphere of trust and transparency. This helps us realize short time-to-value together. It reduces risk as it allows experiments to fail early and fast, letting all of us learn through trial and error collectively. It also means we can enjoy successes collectively.

In sum, DevOps alone isn’t going to cut it anymore. Business wants and needs to be involved. And so we need to keep bridging DevOps and Biz. After all, technology is now everyone’s business.