Calling truce on the IT vs. Business holy war
Today, you are likely to find a divide between the technical teams who implement technology solutions and the business teams, or stakeholders, who specify requirements for solutions in their domains. The technology expertise needed to solve problems and the domain expertise needed to know which problems should be solved exists in seldom interacting and quite often antagonistic silos.
These silos can not only have a negative impact on the quality of solutions, but also have damaging effects on organisational culture.
But need this status quo persist?
Business requirements kill innovation
The following dance will feel all too familiar for far too many in the world of enterprise and technology:
A business team has a problem. There is some process or piece of operations that needs to be made more effective or efficient. A nice web application to replace and partially automate the incumbent Excel laden process would be nice. And so the business team does what business teams do - they write a set of business requirements. Though well meaning, these business requirements are usually flawed - they're wrong and premature.
Firstly, business teams usually do not have the necessary technical exposure to know what is possible, their solution space is limited. Secondly, little opportunity is left for experimenting and iterating on a solution in an agile manner, where both the technical and business domain knowledge areas are at hand. This will usually lead to the recreation of a spreadsheet on the internet which, in most cases, is just a worse spreadsheet.
The technical team, having received a list of features to implement rather than problems to collaboratively solve will look unquestioningly at said business requirements and then simultaneously scoff at their naivety and cringe at their impracticality. Then it's off to the salt mines to hack together just enough javascript to pass muster at the next sprint review.
Act 2 starts when the business team then receives exactly what was asked for, but observe that they are still failing to realize the efficiency and effectiveness benefits that were the original objective. The fix - more business requirements in greater detail, more scoffs and the dance continues.
The outcome? In the worst case scenario, the development team often needs to go back multiple times and rework the solution in order to meet objectives. In the best case scenario, the solution will “work”, but the organisation gains no competitive advantage since no opportunity for innovation at the intersection of the problem context and technologies/tools was created.
At Alis Exchange we hold the strong belief that in order to innovate towards the best possible solution for a problem, you need to have a good grasp of both the technologies or tools that are available, as well as a solid understanding of the problem context. A separation between these knowledge domains will ultimately lead to a subpar solution.
Damage to organisational culture
Divisions between the technical and business domains creates friction between teams and often leads to an atmosphere of outright hostility between IT and Business.
Technical teams often feel that the business teams do not have an appreciation for the work they do. Software engineering is a demanding craft and elegant, robust solutions take time and effort.
It is easy for an MBA to wave their hands and softly mutter "software software software" but those that live in the real world have to deal with scalability, extensibility, maintainability, security and a myriad of other important implementation considerations. The lack of appreciation for technical skills coupled with unrealistic expectations leads to a lack of motivation and an incentive to fight against being asked to do anything. IT teams invented soft quitting long before TikTok popularised the idea.
Business teams, on the other hand, often misinterpret technical challenges as IT "getting in the way". The sentiment is that the techies are just having fun whispering to computers while the grown ups in our corner are shouldering the burden of figuring out how to serve our customers and grow the business.
As an illustration of how deep-set this holy war goes ask yourself, "which of the above two arguments did I find myself most agreeing with?" And if the answer is either then you're part of the problem.
How do we avoid this?
Ultimately, you want to break down barriers to these knowledge areas. There are many solutions out there that are democratising the understanding and use of technologies, and there are also many ways in which organisations can give their teams more insight into the context of the problems that the business is aiming to solve.
Breaking down the barrier to building software
Given today’s accessibility of information, anyone can give themselves an education on the basic technology concepts like what an API is. It might be unrealistic to become an expert, but you should be able to have a meaningful conversation with a developer expert and understand what tools are used for which purposes. Not understanding the basics of what an API is today, is like not being able to use Microsoft Office Word 10 years ago.
Breaking down the barrier to the problem context
All individuals, including developers, working on solving a given problem, must feel the pain of the customer. Organisations should work to make customer feedback and interviews accessible to all team members. Nothing beats observing a customer in the problem context first hand! Nothing makes you understand customer paint points more than eating your own dog-food by becoming a user yourself.
Should we even have separate expert teams today?
One could argue that information or expertise on how to build software is a lot more accessible today. You do not necessarily need to be an expert to start building your first piece of software. It is however much harder to acquire a deep understanding of the problems that are experienced in a certain domain. This requires first hand experience and time.
Platforms like Alis Build also make building software a lot more accessible. Ultimately providing you with a control plane that makes it easy to configure the components you need to build robust, scalable and secure software solutions.
Organisations can afford to invest less resources into building up silos of technical expertise on how to build software and should now invest elsewhere to differentiate the quality of their solutions. What will differentiate them today is how well they can innovate at the interaction of the deep understanding of their problem domain and available tools and technologies.
Can this really be done effectively if teams operate in silos? Perhaps we have arrived at a new future where specialised silos are no longer needed and all individuals contribute to the digital economy to help solve problems?
Think this is still far away? I leave you with this example. Twenty years ago, asset managers differentiated themselves by adopting Excel as a tool. And purely having a team of experts that knew how to use Excel was a differentiator. Later on, everyone knew how to use Excel, but it was in how well you translated your problem into an Excel model that differentiated you. Needless to say, no matter how well you use Excel today, it does not really give you much advantage.
Today we again find ourselves in a place where it is not really special to have a team of developer experts that know how to build software. So what will differentiate us?