Back to resources

How the Tension Between Technology and Business Units Can Enhance Cooperation

Collaboration
Ownership

21 September, 2020

Michael Mac-Vicar
Michael Mac-Vicar

CTO at Wildlife Studios

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Should You Stay Up to Date with Technical Skills As a Product Manager?

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, describes how she keeps learning hard skills to increase motivation and respect her team.

Alignment
Innovation / Experiment
Different Skillsets
Personal Growth
Ownership
Coaching / Training / Mentorship
New PM
New Manager
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Getting Creative to Land Your First Tech Job

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, shares how she gained her first technical position, creating a direct method to apply for jobs.

Personal Growth
Ownership
Hiring
Strategy
Juniors
Career Path
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Change Management in Engineering Organization

18 January

Joëlle Gernez, Vice President, Engineering at Pinger, shares how she collaborated her engineering team with the designers to bring about a change in the processes.

Architecture
Deadlines
Collaboration
Cross-Functional Collaboration
Joëlle Gernez

Joëlle Gernez

Vice President, Engineering at Pinger

The Role of Testing in the Engineering Product Development Process

18 January

Joëlle Gernez, Vice President, Engineering at Pinger, shares how diligently she made the existing developers a part of the testing process instead of bringing in new hires.

QA Team
Collaboration
Cross-Functional Collaboration
Joëlle Gernez

Joëlle Gernez

Vice President, Engineering at Pinger

Navigating Unexpected Cultural Differences

18 January

Markus Aeugle, VP Engineering at Doctolib, shares how he succeeded as an inclusive leader by helping his team navigate through the various cultural differences.

Building A Team
Company Culture
Diversity
Collaboration
Cultural Differences
Markus Aeugle

Markus Aeugle

VP Engineering at Doctolib

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.