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.