AWS lead and EMR General Manager, Peter Sirota, joins Mapbox as Sr. Vice President of Engineering
By: Eric Gundersen
We’re excited to welcome Peter Sirota, previously of AWS and Elastic MapReduce (EMR), as our new Senior Vice President of Engineering.
Peter was employee # 30 at AWS, directly working with Jassy & Charlie Bell building the early architecture and foundation for AWS back in 2005. He was then asked to build and grow a new product, Elastic MapReduce (EMR), where he was the General Manager from 2008 to 2014. EMR remains one of AWS’s highest grossing margin business, as AWS continues to build services “up the stack.” For the last three years, Peter has been running engineering and product at Quantcast, where he helped redesign services, scale the organization, and improve efficiency.
We’re excited to welcome Peter to the team and asked him to share what he thinks is critical for running a successful engineering team.
How do you see structuring our engineering organization?
- We should have a set of teams small enough to thoroughly understand their operational footprint (customers, product, code base, metrics, tickets, graphs, etc.). Somewhere between 6 and 12 engineers depending on the service. If complexity increases, then we split the scope and partition the team. If you don’t actively partition these teams and make sure they understand their customers and operational footprint, overtime the attention drifts and engineers don’t understand their customers’ problems and/or how to operate the stack they are responsible for. Everything becomes slow and error-prone. Getting out of that state is difficult.
- You need to delegate full ownership of a customer problem to a team and hold them accountable for all aspects of definition, delivery, and operation. Product management should be integrated directly into these teams so that they have resources required to define as well as deliver. On balance, full ownership drives better results faster. It is also more satisfying for the teams and requires less overhead.
- Require teams to produce operational plans where they outline strategic objectives of their area, problems they are going to solve for their customers, and what resource do they need to solve these problems.
- Make business/operational metrics, roadmaps, and goals visible to everyone at the company and review/audit them frequently. This introduces joint accountability and transparency where all employees understand where the company is going. Wherever possible goals should be organized in a pyramid structure, cascading from the most important corporate initiatives.
How many people should one person manage?
I’ve noticed that at scale (over 150 engineers), a good ratio of engineers to managers is about 7 or 8 to 1. This ratio allows many manager-in-training initiatives with a low number of direct reports and a number of larger teams with a line manager overseeing a dozen or so direct reports. It is difficult, even for an experienced line manager, to run a team over 15 direct reports for an extended period. This ratio accounts for the organization depth with department heads owning a number of interactions with managers.
How do you make sure managers support career growth for individual contributors (ICs) as well create space for up and comers who want a management track?
A healthy organization must be set up to grow talent from within. Systems must allow ICs and new managers to experiment with new responsibility safely so they either grow into it or fail and move back to the original scope of role without career repercussions. In case of managers, I’ve done several programs in the past that work, including “manager in training” which allows ICs to transition into management and LoL (leader of leaders) which enables line managers to grow into area heads.
“Manager-in-training” is a mechanism where any developer with a good track record of delivery could decide or be encouraged to try management. In that case, a small number of developers (2–5) and a corresponding scope of responsibility is given to that person for a trial period of typically 6 months to a year. If things work out, the manager title is given and the transition is formalized. If not, the person goes back to IC and their trial is celebrated.
IC growth is an important and multidimensional question. Each IC is responsible for their own career growth. Each manager is responsible for providing opportunities for growth. The organization at large has to have mechanisms where these opportunities are reviewed and invented for high performing ICs. First, an organization needs to know who the Top Tier employees for each level are so some calibration mechanism needs to exist that drives consistency in evaluation. Second, each manager should have a plan for their TT employees where they discuss specific areas of employee’s interest and how those intersect with the business need. Moving across the organization should be easy so that ICs can join other areas where their interests are better aligned. It is easy to have good intentions but to fail to execute on these programs. The organization needs to look at these programs frequently.
Another effective mechanism to stimulate individual growth across the organization is mentorship. To have an effective mentorship program an organization needs to have the right ratios of junior to senior engineers.
How do you help engineers understand the impact their work has on customers?
Insist they talk to customers, instrument customer pain metrics, and work with customer success teams. It always helps to have frequent “all hands” and bring at least one customer for each of those where they discuss the impact. For SDKs and technical products, a broad number of engineers should answer customer questions.
Welcome to the team, Peter! We’re excited to see how you will use your experience to grow and lead our team.
