We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

How the Tension Between Technology and Business Units Can Enhance Cooperation

Collaboration
Ownership

21 September, 2020

Michael Mac-Vicar, CTO at Wildlife Studios, explains how the tension between Technology and a business unit creates an equilibrium of competence that helps solve the problems most efficiently.

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.

Related stories

How to Set Up a Bi-Directional Roadmap
19 October

Fei Xu, Engineering Manager at Square, Inc., explains what are the advantages of a bi-directional roadmap and how to set it up right.

Roadmap
Collaboration
Fei Xu

Fei Xu

Engineering Manager at Square Inc.

How Restructuring Can Help Your Team to Claim Ownership
19 October

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.

Reorganization
Ownership
Fei Xu

Fei Xu

Engineering Manager at Square Inc.

Networking for Product Leaders: A Giving Mindset Approach
30 September

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.

Personal growth
Collaboration
Impact
Caroline Parnell

Caroline Parnell

Most recently Head of New Product Innovation at Previously O2 and Vodafone

Integrating Engineering Into Product During the Product Discovery Process
30 September

Justin Potts, VP of Engineering at MoneyLion, explains how including engineers in the product discovery process helps with assessing the feasibility of product ideas.

Collaboration
Cross-functional collaboration
Justin Potts

Justin Potts

Head of Engineering at MoneyLion

Driving Clarity of Charter in a Large Organization
27 September

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.

Ownership
Reorganization
Team reaction
New Manager of Manager
Managing Up
Jeffrey Wescott

Jeffrey Wescott

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.