Back to resources

Introduction of a Matrix-Based Organizational Model in a Software House

Innovation / Experiment
Motivation
Performance

9 December, 2021

Jan Pieczykolan
Jan Pieczykolan

Head of IT Development at Santander Bank Polska

Jan Pieczykolan, Software Engineering Director, shares his experience changing the organizational model to matrix-based resource pool one.

Problem

Companies use multiple organizational models. One of them is a silo-based organization in which each department is a sort of a silo that manages its projects and sometimes uses some of the services offered by the company – for instance, HR, IT, etc. Usually, such a department has its P&L, and its autonomy is relatively high. As long as profits are higher than costs and margin is on the expected level, everything is fine.

The division of a company lost several contracts simultaneously; therefore, several departments grouped within this division started to lose their profitability. The situation was specific as none of the departments lost all warranties, but all were impacted. None of them could survive on its own, therefore merging was an option to recover profitability on a macro scale, on the division level.

Actions taken

We reviewed our profits and costs – to understand expected revenues and determine how much FTE we could afford.

We went through our employee list to identify those we had to keep and those we had to let go of.

We understood that we would have to prepare a flexible, matrix-based organization in the short time horizon. Our solution grouped all engineers and project managers in a single cost center while projects were grouped in programs, and programs were aggregated in separate organizational units. Those organizational units were super lean – they consisted only of a Program Director, who was responsible for a profit from a specific contract or a specific customer.

Program Directors could hire project managers and engineers only for a specific project ordered by a customer. As soon as the engagement was finished, those people were available for other initiatives. Sometimes a person could be shared by more than one project – especially in the case of small projects or maintenance contracts (maintenance contract was a project as well). We were allowing overbooking, at least to a certain level.

After some time, when Program Directors stabilized their profit centers, they started to build their own organizations as they had guaranteed income. Therefore, they were able to afford permanent hiring of employees.

Lessons learned

  • Silo organizations are often non-transparent ones.
  • Engineers can be shared by more than a project only for a limited amount of time – focus switching is usually too difficult to handle for a longer time.
  • In matrix organizations, people usually have a problem identifying who their manager is and who influences their salary and bonus.
  • Performance review in a matrix organization is complex and requires unambiguous criteria to be conducted fairly.
  • It is challenging to build innovation in matrix-based organizations.
  • It is essential to define clear responsibilities between a line manager and a project manager who engages an engineer in a project. Lack of this clear distinction will lead to conflicts and demotivation of the staff.

Discover Plato

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


Related stories

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

Mindsets of High Performance team

14 October

Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.

Innovation / Experiment
Mission / Vision / Charter
Building A Team
Productivity
Feedback
Motivation
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB