The Brainly Model

Introduction

Brainly is the world’s largest online learning platform with over 350 million monthly users. In 2020 Brainly underwent an organizational transformation which unlocked our ability to build value for our users and positioned ourselves for hypergrowth scaling of our organization while simultaneously improving the predictability, consistency and quality of our production output.

Why we did it is straight-forward. We were slowing ourselves down with logistical overhead built into our workflows. In industry consulting speak “our value streams were wonky” and this was primarily due to, and being limited by, the design of our organization.

What we did to fix this situation is something that tends to produce a strong reaction with many of the folks I’ve talked with about our solutions. The responses I’ve received range from “that won’t work” to “I want to do that in my company” with a generous amount falling into the category of “it sounds like you’ve figured it out but I still have questions”.

In this article I will explain what we did and why, focusing on two of the most controversial aspects of our solution :

• Production engineers at Brainly report to non-technical managers…
• Our Engineering Management Team does not manage engineers…

Before we dive in too deep you might want to start with the * disclaimers and warnings * so you know what you’re getting yourself into, if you choose to continue reading.

Organizing Principles

When we were designing our organizational change we were optimizing for a small set of outcomes.

We wanted to remove as much logistical overhead in our value streams as possible. We wanted to improve project delivery and increase innovation while removing as many obstacles as possible in these areas. For us this meant tightening up communication and collaboration at the project level.

We wanted to align work output at the individual level with the outcome of projects. We felt that if everyone contributing to a project measured their success by the outcome of the project holistically and not the outcome of their contribution to the project there would be numerous benefits for the individual, the team they worked on, the department that housed the team, and Brainly as a whole.

We wanted a solution that would work from the size of the company we were at the time we were thinking about these things to any size we were to become in the future.

Production engineers at Brainly report to non-technical managers…

… as part of a cross-functional team we refer to as a Production Team.

These teams have all of the skill sets needed to deliver on their typical projects. A typical Production Team might consist of multiple engineers with different domains of specialization, i.e. front-end, back-end, data-engineering, machine learning, etc. as well as designers, data analysts, QA, and any other type of technical or non-technical role which might be needed to deliver on the work expected from that team.

Each team has a single responsible individual that we refer to as the Team Manager. This is a role, not a title. All team members report to the Team Manager.

The Team Manager is responsible for the team’s output, and the individual contributions of each team member. We organize the Production Teams in this way to optimize for project level collaboration and communication while also minimizing logistical overhead and “domino effect delays” caused by dependencies across teams.

Inherently this structure promotes team identity and team work product over the individual — putting the focus on cross-functional value creation instead of individual contribution.

This cross-functional team model scales. By organizing in smaller units that are defined, staffed, and managed as a self-contained entity we are able to easily add more teams in a consistent and reliable manner with minimal disruption to any other teams and no need to reinvent our model even at the largest scale.

This design does not come without challenges and we were careful to name out and solve for the most obvious questions :

• Can non-technical managers manage engineers ?
• How will it be possible for an engineer to develop their career or technical expertise under a non-technical manager ?
• Is this an organizational environment that will attract and retain engineering talent ?

Our Engineering Management Team does not manage engineers…

… or their projects. At Brainly the Engineering Management Team is responsible for managing the practice of engineering. Let’s break this down starting with the questions asked at the end of the previous section.

Can non-technical managers manage engineers ?

The short answer is — yes of course — but internalizing this requires some context and challenging a long held assumption.

You do not need to be able to do the things that the people under your management can do in order to manage them. This may seem a bit strange to say because the common assumption is that people management, i.e. the personal and professional management of an individual, must be done by a more senior or experienced version of the role being managed. In the real world this does not work well, is not scalable, and is not actually what is happening in most cases even if the organizational design insists this is how it should be.

As already explained, our organizational model at Brainly revolves around the identity and value produced as a cross-functional team. In choosing Team Managers as the people managers of their teams we prioritize managing individuals in the context of being an effective team member over managing them by their professional practice, i.e. an engineer, a designer, an analyst, etc.

How will it be possible for an engineer to develop their career or technical expertise under a non-technical manager ?

We have 2 mechanisms which we created as a direct response to this need — our Technical Leveling System, and our Mentoring Program.

The Brainly Technical Leveling System acts as a form of credentialism within Brainly. Like many other credentialism systems out in the real world it does not qualify someone in all aspects of their job performance. It is limited by design to those topics which are the purview of Brainly engineering and technology leadership.

Our goal with this solution is to provide the technical evaluation, technical leveling, engineer titling, promotion, and development of the employee as a service to our Team Managers. Not only does this maintain quality and consistency across our organization when it comes to titling, technical competence, salary, and expectations — it allows the Team Managers at Brainly to focus on the management and assessment of the employee in relation to their own needs and first-hand perspective, i.e. as a team contributor.

This creates a unique dynamic in which engineers are inherently incentivized to be good collaborators and team members. It also acts as a form of quality control in our employee hiring and team staffing processes by the nature of being a predefined and explicit set of expectations for engineers across the organization.

The Engineering Management Team at Brainly act as custodians for Production Engineers in their careers at Brainly. Using the requirements defined with the Brainly Technical Leveling System as a guide they act as both a coach and an advocate for production engineers within the system.

In practice this means that the Engineering Managers help production engineers to identify areas to focus on in order to achieve their next technical leveling promotion. They work with the engineer to obtain resources that will help them achieve their goals such as formal training, mentorship, and hands-on-opportunities to develop the technical skills required for their desired technical level promotion.

When it comes time for the Production Engineer to submit themselves for a technical level promotion, the relevant Engineering Management Team Member will help them build their promotion case, then act as an advocate for the employee during the Leveling Committee process.

The Mentoring Program is complementary to the Technical Leveling process and is exactly what it sounds like. This is a formal program within Brainly in which we allow engineers to mentor and be mentored by each other, across inter-organizational boundaries. This allows us to share knowledge, information, and experience with each other while simultaneously developing our engineers’ skills.

In this program mentor and mentee candidates apply for participation within the program and indicate their topics of interest. Pre-qualification and matching processes take place to ensure a mutually beneficial relationship within a structured and time-capped program.

Is this an organizational environment that will attract and retain engineering talent ?

Hopefully by now you understand that we’ve been very thoughtful about our approach to our organization design and you see that we value autonomy, collaboration, and localized optimization at the team level over big process and top-down management structures.

We believe that this is an environment where engineers will thrive with transparent and direct lines between their work and the value being produced by the end user.

However there’s a tenet of the Engineering Leadership at Brainly that is too important to not mention when it comes to this topic.

We fully expect engineers who join Brainly to be better engineers for having worked at Brainly.

At Brainly the Engineering Management Team is responsible for managing the practice of engineering.

They create and apply tools like the Brainly Operational Maturity Framework which helps to identify which areas for improvement in the software development lifecycle practices of our Production Teams.

They act as expert coaches, consultants, and coordinators focused on the continuous improvement of how engineers work, instead of what engineers work on.

We’ve built this environment because we believe that these things matter and we value them highly. We seek out and hire engineers and technology workers who also value continuous improvement of themselves both in terms of hard skills and application of technology but also in terms of engineering process and professionalism.

* Disclaimers and Warnings *

Warning — I am purposefully avoiding comparing what we are doing now to what we were previously doing. The path from there to here is not the point. The overall solution design stands on its own merits and any starting point can evolve to take advantage of any or all of these organizational design decisions we’ve made for ourselves at Brainly.

Warning — This is not an article about any specific software-development / project-management-methodology. This article *is* about our organizational design and how we approached our org design to unlock and produce the outcomes that serve us best.

Disclaimer — I have no knowledge of your organization, your culture, and no way to know if you would get a similar result if you implemented the same things in your company. The outcomes we’ve achieved at Brainly would not have been possible without our culture of openness, collaboration, communication, and trust.

Additionally, the feedback loops between our engineers who were being asked to do something that was initially strange & uncomfortable for them and the Engineering Managers who did the bulk of the work-on-the-ground implementing these organizational changes was key to our ability to successfully implement our design.

Disclaimer — This article applies to Production Teams. We have teams at Brainly which do not work in this model as they are not cross-functional teams working in production and their value streams would not benefit from working in this model.