Scaling an Engineering Org: A Journey Through Roles and Responsibilities
In my 8 years at Phorest, our product development team has grown by 20x in headcount. We have gone through many iterations of organisational structures, roles and responsibilities, and titles. This post is about how it has evolved and why. We aren’t the experts here and have learned from many great pieces of work and thought leadership (shared below). I hope it can give you an insight into how you could tackle similar challenges as you grow (if you have them), how engineering at Phorest is structured, and what our current version of roles and responsibilities looks like.
The Early Days
For the first few years we were very small — titles and hierarchy didn’t matter, everyone did everything, we were flat and communication was simple — it was fun and chaotic. However, we first realised we needed to split from that to two teams when one person (me) was managing everyone. So we created the “Engineering Lead” role and two individuals within the team naturally transitioned into this position.
As opposed to hiring externally, I can not emphasise enough how important it is to look internally for people to take on people management responsibilities because they know the customer, company, team, and should have the support of their teammates.
Our first official version of Roles and Responsibilities
As the team continued to grow, we identified the necessity for clearly defined roles and responsibilities. In 2018, we established a framework accompanied by some expectations for each role. This structure served us well for three years and provided a foundation for team members to understand their contributions, hiring and shaping the group. The two Engineering Leads became Engineering Managers and it allowed us to promote someone to be our first Principal Engineer at Phorest.
Challenges as we grow
In 2021, our team expanded rapidly from four to nine teams. This growth presented new challenges, including ambiguity in role expectations, a messy middle with overlapping responsibilities, and big organisational gaps as we had many teams contributing to similar areas of the product ecosystem. A team of managers, ICs and our HR business partner formed to define these challenges and carve a path forward. It took roughly 3 months to iterate on, it involved 3 important milestones. 1. Defined the problem, 2. Define how we’ll solve them. 2. Rolling them out.
3 Problems Defined
Problem 1 — Ambiguity
- Clarity Matters: Lack of clarity on expectations for various roles led to daily challenges. Communication became harder when we didn’t know who was responsible for doing what (in particular the EM / PM where lots of things overlap)
- Defining what good looks like: Understanding what constitutes a “Senior Engineer” or the role of a “Director of Engineering” became crucial.
- Promotion Criteria: Establishing clear criteria for promotions, distinguishing between technical and managerial tracks, and defining readiness for advancement were pressing concerns.
Problem 2 — The Messy Middle
- Role Overlaps: Ambiguity existed in the roles of Tech Lead, Engineering Manager, and Senior Engineer.
- Hands-On Leadership: Determining the appropriate level of hands-on involvement for Engineering Managers and Technical Leads was a challenge.
- Career Progression: Providing a clear path for Senior Engineers who may or may not want to transition into management roles was essential.
Problem 3 — Org Gaps
- New Challenges: The existing structure did not address newer business and org challenges.
- Team Strategy: Clarifying responsibilities for long-term team strategy becomes essential.
- Multi-Team Roles: Introducing roles with a multi-team scope, such as Staff Engineer and Senior Engineering Manager, addressed org gaps.
Principles for Solving
To address these challenges, we formulated a set of principles that guided our decision-making. We did this so that we could make sure we were being fair and could give the scaling group the roles and responsibilities structure it needs for sustainable growth and sustainability.
- Clarity is Key: Lack of clarity is the root cause for many day to day issues (eg who must do what)
- Consistency Matters: Consistent naming and expectations are central to achieving clarity.
- Long-Term Integrity: Long-term integrity of the levels is more important than short-term discomfort
- Impact over Tenure: Impact, not tenure, is the key measure for success at a given level
- Localised Reporting: Teams are healthier and perform better with localised, not matrix, reporting
- Selective Application: Not every team needs every level, and promotions should align with cultural messages.
Implementing Changes
To bring these principles to life, we made 3 key changes
Change 1 — Defining Tracks: Clearly defining Maker and Management tracks with consistent dimensions and expectations.
Change 2 — Eliminating Ambiguity: Streamlining roles by removing the Technical Lead designation and differentiating between Senior+ Engineer and Engineering Manager.
Change 3 — Multi-Team Roles: Introducing Staff Engineer and Senior Engineering Manager roles with a broader scope.
One point of contention with the working group was the title “software engineer” vs “product engineer”. This is a trend that many companies are making to emphasize the role of the engineer is to build product. We resisted that in the interest of not making too much change at once, and are happy with that decision.
In rolling out the changes we had a low impact on people affected because many roles were staying the same we just had clearer definitions and expectations set out. We did have some who were, the tech lead role was no more, and some of our engineers were more operating at staff level (a new role). We chose to talk to those affected and explain where we were going, that we’d work with them to transition them to where we believed they were. This took more time and was a great learning for us in getting used to the new roles and responsibilities structure (and we made some tweaks based on it). We are happy to have gone this way as opposed to down-leveling people and making them apply for roles they were already operating at.
What we’ve seen happen since
Well first off, many of the problems we outlined went away 🙂. We created clarity and a path for progression which has opened up many promotions and growth to be successful, and in turn our retention is very strong. It made hiring clearer in terms of speccing the roles in terms of what teams and the org needed. As a management tool, it allows managers to articulate expectations, and understand their responsibilities and their people.
Just like building software, it requires continuous iteration. As we’ve used these roles and responsibilities for 360s and the bar for hiring/promotions we have identified changes that needed to be made. We do that with our senior engineering leadership team.
One of the things I’m most proud of us achieving in the last few years is that we have two people make the transition from great Engineering Managers to IC and grow to be exceptional principal engineers, and 5 of our current engineering managers are homegrown (we grow our own timber).
Continuous Evolution
My advice is to initiate changes when you begin to feel the pain but before it becomes a constant source of frustration. Communicate with the affected individuals beforehand, minimise disruptions, and ensure everyone understands the why and how of the changes. Remember that org growth is a journey, and evolving structures and responsibilities are key to success.
Do not try to copy and paste this or any other version you can find online — it has to be specific to your business, team and mission.
Feel free to take inspiration from our Roles and Responsibilities Document as a reference point in your work — happy scaling 🚀
