How the Tension Between Technology and Business Units Can Enhance Cooperation
21 September, 2020
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.
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.
- 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.
Fei Xu, Engineering Manager at Square, Inc., explains what are the advantages of a bi-directional roadmap and how to set it up right.
Engineering Manager at Square Inc.
Fei Xu, Engineering Manager at Square, Inc., recalls how he approached the restructuring of his team with an intent to have them claim ownership and develop subject matter expertise.
Engineering Manager at Square Inc.
Caroline Parnell, previously managed product teams at O2 and Vodafone, emphasizes the importance of networking for product leaders and giving in return some value to her peers.
Most recently Head of New Product Innovation at Previously O2 and Vodafone
Justin Potts, VP of Engineering at MoneyLion, explains how including engineers in the product discovery process helps with assessing the feasibility of product ideas.
Head of Engineering at MoneyLion
Jeffrey Wescott, Director of Engineering at Splunk, describes how he introduced clarity on ownership between four disparate teams by drafting a charter that precisely demarcated who owned what.
Director of Engineering at Splunk
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.