Back to resources

Structuring a Startup for Scale

Scaling Team
Ownership
Team Processes

30 December, 2020

Wadah Sayyed
Wadah Sayyed

Director of engineering at Ex-HPE

Wadah Sayyed, Director of Engineering at HPE, discusses how he helped set his startup for success by mapping out ownership structures and building teams around clear ownership.

Problem

When I joined my current company back in 2016 it was still an early-stage startup graduating with 20-some engineers in an office only to rapidly scale in no time to 250 engineers across four geographies (two at East Coast, one at West Coast, and one in Bangalore, India). The engineering processes were still taking shape and didn’t allow for clear ownership of product areas. Rapid growth was often at the expense of documentation and hardly anything was documented. You would have to go talk to one of the OG engineers with institutional memory to understand aspects of architecture and design in order to do your job. Field escalations were complicated as there wasn’t clear ownership and most of the escalations landed on one of the few OGs (with a few individual exceptions).

Actions taken

For starters, I documented all of our CLIs and started working with others in the organization to assign teams as owners to each one. The process I initiated was simple; I was able to obtain a complete list of customer and support CLIs from our documentation team and create a Confluence page of that list with a new column to document “Owner” of each CLI. Then I sent out a call-to-action email for our managers and Product Owners to fill in this info. By doing so, we were able to complete 75 percent of the information needed. We had some CLIs that weren’t straightforward to assign to a specific team and the only way to resolve that was by meeting with my peers and settling on a proposal that we would take to the teams for feedback and buy-in. This process enforced the assignment of ownership and the path for escalations and feature requests became more visible to the entire organization.

The very act of mapping and documenting product ownership empowered each team to further monitor quality, technical debt, feature requests, escalations by product area and focus their energy accordingly. As stakeholders started seeing the value of alignment, another ownership mapping effort was followed to map other product areas to the team (e.g. services, frameworks, etc.), which some teams started documenting on their own ahead of the mandate from our VP of Engineering.

As ownership cleared up, so did backlogs for teams. This created opportunities to dismantle some Scrum teams and start others with a new focus. Not everyone was happy about this turn of events, but when the dust settled and the population of engineers were surveyed about the outcome of this experiment, the majority felt a higher sense of purpose, empowerment, and satisfaction.

Lessons learned

  • As an organization scales, it’s important to consider how to keep focus within each team(s). The answer to dealing with more work isn’t necessary to bring in more people. Enabling a team to operate with minimal dependencies on other teams is critical to faster delivery and greater talent retention.
  • Have the courage to lead through change by performing your own analysis and proposing data-driven changes. I couldn’t recommend any reorganization from the get-go. I needed to understand how teams map to product areas to backlog items first. Once I saw the data and some teams raising the flag that they don’t have enough to keep them busy, I was able to put together a proposal for change that would benefit the business and employees. We were able to re-direct hiring towards starting new teams to develop new features as a result.

Discover Plato

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


Related stories

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems