Back to resources

Growing Engineering Organization: One Step At a Time

Scaling Team
Building A Team
Large Number Of Reports
Leadership
Delegate
Hiring

2 August, 2020

Peter Fedoročko

Peter Fedoročko

Director of Engineering at Workday

Peter Fedorocko, Director of Engineering at Workday, recalls his early efforts to build a large, multilevel engineering organization in a short period of time -- one step at a time.

Problem

When we were acquired by a large company I was working on a small engineering team of five people. In two years we scaled from seven to 30 engineers -- more than quadrupling the number of people. The rapid scale impacted both the existing and newly arriving employees as well as managers who were handling that growth. I faced multiple challenges along the road that I dealt with one step at a time.

Actions taken

I was initially tempted to manage everything by myself. I was avoiding hiring managers and deliberating on the organizational structure. Hiring only engineers positively impacted scale and velocity short-term, but threatened to harm not only my performance and well-being as a manager but the efficiency of the organization as a whole.

I had to delegate some of my responsibilities but we were short of managers who could take it on. Moreover, we lacked the organizational structure that would enable those managers to propel our work forward.

For starters, I had to develop the organizational structure that would serve our need for rapid growth. I would sit down with every person on the team to discuss the draft that included roles and responsibilities and solicit their feedback and ideas. I received far better feedback than I could have possibly imagined. I tried not to be misled by what would look good in the Powerpoint presentation and I relied on the perspective of my employees. For example, if I were to place a UI engineer in every team -- because presumably, every team would need one -- I would have to confront realistic arguments of my engineers who would then explain to me that they had already established good cooperation with another team that excelled at UI. Moreover, people would be very appreciative that their voice had been heard which increased their engagement and sense of ownership.

When developing the structure, you should think about roles and responsibilities, write that down, instill it into every new leader and a new team, and repeat it unsparingly. I made sure to avoid any blind spots around who owns what and why. The latter you would deal with that, the more opportunities would be lost. By the time people would start shifting their responsibilities around, it would be much harder to fix the problem. I would bring a chart with me and facilitate a session during which I would encourage feedback from the team. They would likely add a problem you overlooked or further specify (part of) a role.

I would follow the MECE principle (Mutually Exclusive, Collectively Exhaustive) principle when I was developing our structure. I wanted the teams to be functional and able to cover a variety of different tasks but you want them to be -- as seen from the outside -- as much autonomous and self-reliant. I would always give teams autonomy but I would stay away from managing dependencies.

Hiring and recruiting is always hugely time-consuming as well as onboarding and introducing new people to all the details of your ongoing business and I was putting that off for a while. Only once when I was unable to streamline a focus on my own responsibilities, I started to think about adding a few managers to the team.

Lessons learned

  • I started to think about the organizational structure too late. Growing internal leaders or hiring external managers takes more time than onboarding new engineers. If you start onboarding new engineers without having EMs you will end up with too many direct reports and most likely the complete overwhelm. Then, you’ll get stuck in a vicious circle of not having time to grow people, while not having people means that you will have to do everything by yourself and have no time for anything else, including growing people. Think about prospective leaders in advance, identify those with leadership potential on your team before you even start to grow.
  • Usually, organizations are structured from the front- to back-end and database teams where people are organized by their expertise while the work needed to support the business should usually require their cross-functional collaboration. Leaders you will choose should be able to manage people to have their work done, not manage different capabilities.
  • Initially, when I was deciding on new managers I was looking for high performers among ICs and more often than not that didn’t work. More than once I was disappointed by people who were highly productive as ICs but failed as leaders managing people.

Discover Plato

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


Related stories

Scaling Engineering @ Trustly

22 January

We doubled the Engineering team from 54 to 109 full-time employees. We expanded our team footprint to include: Brazil, Portugal, and the US. We evolved our road mapping and planning processes from two Product squads to eight Product squads, in alignment with PM areas of ownership.

Scaling Team
Reorganization
Hiring
Ron Pragides

Ron Pragides

VP Engineering at Trustly Group AB

How to Spark Sales-Driven Change

19 January

Nani Nitinavakorn, Sr Product Owner at Revolut, recalls her experience initiating a structural change to optimize her entire company.

Customers
Innovation / Experiment
Leadership
Meetings
Impact
Users
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

Strategies to Deliver Effective Employee Feedback

18 January

Rachit Lohani, Head of Engineering at Atlassian, shares all his ideas and principles on providing feedback and avoiding discomfort while doing so.

Leadership
Internal Communication
Feedback
Motivation
Strategy
Team Processes
Rachit Lohani

Rachit Lohani

Head of Engineering at Atlassian

Reasons Promoting From Within Is Better for Growing Your Business

18 January

Vishal Ramrakhyani, Director of Engineering at Zoomcar, shares how grooming an existing senior team member to a leader can boost team morale and keep the culture intact.

Alignment
Building A Team
Handling Promotion
Company Culture
Feedback
Coaching / Training / Mentorship
Fairness
Juniors
Vishal Ramrakhyani

Vishal Ramrakhyani

Director of Engineering at Zoomcar

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.