How the Tension Between Technology and Business Units Can Enhance Cooperation

Problem

As a technology organization, we are often approached by different business units that have their own ideas on how to solve -- by the means of technology -- a wide range of problems. What they would propose to build is frequently unfavorably assessed by Technology and therefore, rejected. Business units would naturally have a lot of questions and demanded to be more included in the decision-making.

I find the tension between Technology and business units, including push backs and disputes, the healthy response in a situation where different parties have different interests. Business units would oftentimes propose solutions Technology can’t deliver or thinks are not the right solutions. However, in the end, the technology organization and business units need to come to an agreement and be aligned around how Technology can best serve the business.

Actions taken

To enhance cooperation between Technology and business units we had created a new structure and ramped up the process that would effectively address the concerns both sides had over the problem-solving process.

First off, we reached an agreement on who owns which decision, defined roles of all actors in the process and circumstances under which decisions could be questioned. The agreement clarified who decides what was the problem, what was the solution, and who is dealing with misalignment instances.

Then, we had created new squads that would work with business units. Technical product managers were added to the technology organization, including stakeholders from different business units and representatives of clients, along with technical leads. We also introduced monthly stakeholders’ and weekly clients’ meetings.

It was decided that priorities would be always set by business units. Problems would be proposed by business units and they would have to seek approval by Technology. Technology would always propose solutions but business units would have to agree, while the technical design would be done by technical leads.

If a problem would be entirely owned by business units, they would have the power to pick the problems and design the solutions. However, no business unit had a PM role and as a consequence, they would choose short-term problems and prioritize operations. An autonomous PM would not be incentivized to look only for short-term gains and would seek more sustainable solutions. By adding a PM, both Technology and business units were forced to agree on the best solutions that bring long-term value.

Also, we would collaboratively define new verticals where we could extract value and create new squads whose scope would encompass those opportunities.

Most importantly, we as a technology organization would not allow business units to use engineering resources arbitrarily but would require them to clearly define their objectives and their proposal. Similarly, the technology organization must be only working in solutions approved by the business. Our interaction was always intensive and no proposal coming from whatever side would remain unquestioned. The tension that existed between Technology and business units created an equilibrium of competence and demarcated ownership.

Lessons learned

• The question of ownership was a key question and agreeing who decides on what established a foundation for a structure to be created. Governability is there to make conversations happen. Having different stakeholders from different business units pushing for their solutions gave rise to arbitrariness and caused misalignment.
• Adding PMs with a robust domain knowledge was crucial for setting structure in place. Typically, the best PMs were already in business units, they only had to be placed in an adequate structure to make the most of their knowledge and skills.
• A squad with well-defined scope and aligned with business units is a happy squad because it has a clear purpose and a doable goal.