Scaling Engineering Teams Without Traditional Managers
When I joined Alan, the engineering team consisted of roughly 20 people, and we firmly held the perspective that engineers should not necessarily pursue careers in management.
Since then, we embarked on a journey to design and scale an engineering organization and culture that would enable us to grow without introducing traditional managers.
Although this diverged from the organizational structures, I had previously experimented with at Intercom and Front, establishing a new organizational model was both exciting and terribly ambitious.
As the team has grown a lot since. It’s an opportunity to share some insights we learned along the way that might be valuable to others.
Context
Before digging into the details, let me provide a quick overview of our organization at the time of this write-up.
At Alan, our engineering team consists of approximately 100 engineers with a T-Shaped profile, and we have a few security specialists.
About 95% of engineers focus primarily on value creation for our members, while others are also involved in transversal initiatives.
The “conventional” responsibilities of a manager are distributed across 3 distinct roles: Engineers, Crew Leads, and Coaches.
- Engineers: All our engineers take on the role of tech-leads and are vested with the responsibility of driving engineering excellence. This means they have the autonomy to identify areas requiring improvement, and they take ownership of the necessary changes. Whether it’s proposing a process enhancement, adopting a new tool, or refining an existing system, engineers have the authority to initiate these improvements. They utilize GitHub, to document their proposals and move forward.
- Crew Leads: a Crew Lead is responsible for organizing a crew to deliver on-time high-quality work. They are also part-time “regular” Engineers and still code.
- Coaches: a coach is responsible for guiding and supporting mentees in realizing their potential and defining the next steps in their careers. Coaching is an activity that Alan employees perform alongside their regular job, and it is not a full-time position.
One of the defining aspects of our organizational model is the fluidity of roles. Engineers have the flexibility to transition between roles, including Crew Leads and Coaches, based on their interests and aspirations. This encourages individuals to explore different growth dimensions without artificial boundaries and enhances our overall team adaptability.
That organization model led us to navigate uncharted territories on how to scale recruitment, communication, and processes.
Recruitment
In other companies, many tenured engineers hold titles such as tech lead, manager, or director. Not having these traditional titles might complicate our recruitment approach. However, through discussions with various candidates, we found that it was not a major obstacle.
On the contrary, our approach offered an attractive alternative for engineers whose only career choice was to pick a manager or an individual career track. Engineers can determine where and how they can have the highest impact by combining different roles as they see fit.
Thus, we structured our career path based on expected impact, evaluating engineers at all levels based on their tangible contributions to the company’s trajectory. It enabled us to design a simple shared career track for the entire engineering.
That said, some potential candidates were on the fence about applying because they were not seeing their current job in our organization. To address their concerns, we published some portraits featuring engineers who joined from different backgrounds, including former managers.
Automation
Initially, some processes were managed by volunteers. However, over time, these processes began to strain their bandwidth, and we realized that relying solely on volunteers was not a scalable solution.
In many cases, managers would take ownership of these processes or act as the critical glue to make them function smoothly.
To overcome that challenge, we invested heavily in automation which became a powerful ally.
The benefits were twofold:
- Offload repetitive and time-consuming tasks, freeing us up
- Provide a reliable and scalable framework based on code.
For example, our onboarding process became a breeze thanks to a meticulously designed Slack bot that guided new team members through the necessary steps as described here. Additionally, we implemented another bot that tracked action items from incident post-mortems and automatically pinged the responsible engineer if any task was pending.
I can’t count the number of Slack workflow and bots that we use on a daily basis but automation is an ongoing journey. We continue to seek opportunities to streamline every aspect of our workflow, especially thanks to Large Language Models.
Communication
As the team grew, we encountered a few communication challenges to share context and act upon feedback at scale.
In traditional organizations, managers often serve as a relay to share context and collect feedback. So, we initially experimented with relying on coaches, but their relationship is not focused on day-to-day activities, so it failed fast.
Rather than persisting with an approach that did not yield the desired results, we decided to take a step back and explore alternatives leveraging our radical transparency and distributed ownership values.
After a few attempts, we landed on creating new tools: a weekly newsletter and a pulse.
Weekly Newsletter
One of the standout solutions we devised was the creation of the “Engineering Gazette.”
A weekly newsletter built as a collaborative effort, written and shared by the entire team.
Emphasizing brevity and humor, the Engineering Gazette serves as a lighthearted yet insightful communication channel that keeps everyone updated.
Pulse
Regarding feedback, we determined that an efficient way to approach it was to ask all engineers regularly a simple question:
“What’s preventing you from doing your best work”.
This simple yet powerful question encourages individuals to express their concerns, frustrations, or any roadblocks hindering their productivity, creativity, or well-being.
After collecting feedback, we channel it into a GitHub issue or a workshop to identify, prioritize and distribute ownership of the initiatives we want to experiment with.
And in the subsequent pulse, we circle back to evaluate whether the efforts have led to tangible improvements. This iterative process helps us gauge the effectiveness of the initiatives and identify areas where further refinement or alternative approaches might be needed.
Conclusion
Our experience has shown that it is possible to scale an engineering organization by distributing managers' responsibilities.
This approach enabled us to focus on creating value for our members, enhancing adaptability, and empowering engineers to develop in their unique way.
While we’ve only scratched the surface in this blog post, we recognize that our journey is ongoing, and there are still many aspects and challenges to explore and share. Let us know what aspects interest you the most in the comments.
