The Beast Mode is an idea of splitting a team into squads, giving each the highest level of autonomy and trust, prioritizing properly, and eliminating distractions.
I became a team lead at Toptal in 2018. My team was responsible for the entire website, which was the company’s key marketing tool. It comprised thousands of pages and had accrued significant SEO traction and authority, which was important to retain and strengthen.
My team goal was to fulfill the Growth team expectations, and by the time I started, we also had to deliver an important project: an entire website redesign. This had, unfortunately, already been significantly delayed.
We were therefore presented with a challenge to make the redesign project happen – through choosing the right technology, motivating and structuring the team properly, and organizing their work.
I’ll briefly cover the team and technology elements, but the most important part of this article is about focus: the Beast Mode.
Structuring the team and hiring
Before we even started the redesign project, we had to reorganize the team in a way that would allow it to perform well and focus on important goals.
The team previously lacked focus and had accumulated a significant amount of tech debt. This was primarily because maintaining existing technology had been in constant conflict with a never-ending stream of growth-related tasks, which were always more important to the team.
We split the existing team into parts: the production team, which worked on the website and growth tasks, and the infrastructure team, which maintained the backend of the website. Although this is a bit contradictory to the idea of having cross-functional teams, it made perfect sense within the growth-marketing realm we lived in.
After splitting the team into parts, our goals became much clearer. This allowed us to advertise job positions more easily and split the work in frontend and backend streams to ensure that they wouldn’t interfere too much with each other.
We also intentionally re-branded the team to have a new name (before it was something totally esoteric) – the Public Pages team. Someone even proposed a contracted name, the PUB, which stuck nicely and became an integral part of our self-identification.
This allowed us to successfully hire new people and clearly articulate team goals. The redesign project was still overdue, however, and the technology stack remained a limiting factor.
Choosing appropriate technology
Back then, we had a Ruby on Rails website – a monolithic application, which was pretty standard. On the frontend, my team’s domain, we had a mix of templates sprinkled with Backbone and jQuery, and a few promising but incomplete new approaches to making frontend code better modularized.
In order to become an attractive team for new members to join, as well as complying with the company-wide choice of React as a frontend framework, we had to come up with a way of integrating React into Rails. There were a few existing approaches to doing this, although none of them would allow us to easily use the same code for server-side and client-side rendering.
Keeping in mind the importance of site SEO performance, we couldn’t just build a single-page application, which is normal for most web applications. Existing tools such as Gatsby or Next.js also wouldn’t fit our needs without significant architecture and infrastructure redesign.
So I came up with a new system design and created a stateless Node.js based React rendering engine connected to the website engine over HTTP – effectively, it was almost an RPC engine that moved the site view layer into a separate service.
This is an interesting story, which I could write a whole other article on. In summary, after a few months of experimentation and programming, we transitioned to React – a modern component-based frontend framework, which was attractive to developers.
Components on the frontend aren’t just a buzzword or a shiny new way of doing the same things. They allow large teams to split work into self-contained chunks that make sense, and compose these components into larger pages, then extend and reuse them.
(Guess)timation and planning
After doing most of the groundwork – hiring motivated people and providing them with the right tools – we still had to deliver the redesign project. And here the most important part of the story begins.
First, we split the set of redesigned pages into components, taking into consideration their reuse potential. Things like headers, menus, and navbars would be developed first, and parts occurring less frequently would be developed later.
As a team lead, I had a few possible ways of estimating the entire project. One would be to use the team’s expertise and opinions for every component, sum up their estimations as story points and organize work in sprints as usual. This could work, but it wouldn’t provide the necessary accuracy and sufficient progress oversight needed for a completely new project, which was required to be delivered by a certain date.
Story points also wouldn’t provide enough time context to the team, not to mention factoring in multiple possible sources of estimation errors, which would make the plan less accurate. So I decided to split each of the components into the smallest possible parts and estimate them in man-days myself.
For the purposes of my estimation, I assumed every team member was equally skilled and fast. Then, utilizing some of the most basic Excel magic, I crafted a spreadsheet showing the current progress of the project, completed and outstanding work, and a completion date projection.
After a few weeks following the new plan, with the entire team working on a single set of tasks during a sprint, it became apparent that we most certainly were not hitting the desired project deadline. More specifically, we would be late by a few months at least, if not half a year.
This was not acceptable, given how much the project had been already delayed.
Unleashing the Beast
Despite our best efforts to redesign the team and invest in better technology, which brought the team to a new level of output, we were still behind schedule. I had to do something else.
I analyzed what was going on and made a few observations. First, we weren’t focusing enough. The team, despite the urgency of redesigning the website, was still torn apart by unrelated requests, such as fixing existing bugs or implementing non-essential features and experiments.
Secondly, our regular process wasn’t tailored to be the fastest possible. We worked as usual, with pull requests waiting for review from other team members sometimes for days, and there were plenty of discussions about how to implement things in the right way.
Lastly, we were wasting quite a bit of time on regular meetings such as backlog grooming, plannings, daily meetings, and sprint retrospectives.
These are all regular processes and, under normal circumstances, demonstrate the qualities of a good team. With a pressing deadline to deliver a single most important project though, they didn’t make so much sense.
I had a think and came up with a plan: the Beast Mode, which I presented to our product manager and my engineering manager first, and to the team shortly after.
Providing full autonomy
Our team currently consisted of six members, four of whom were full-time developers. Knowing how important the social component of software development work is, I proposed to split the team into pairs of developers – the Beasts.
Each Beast would come up with their own name, emoji, and color. Which they did! Almost immediately after the introduction of this idea, the Beasts named themselves Chimera and Hermes.
This was voluntary, not imposed upon them, thus allowing my teammates to self-identify with a name that was more powerful and personal than just our entire team. This helped them to feel more pride in the work they were doing and compete with each other in a friendly way.
These pairs effectively become autonomous squads. Each had their own set of important tasks to tackle, complete independence to pick approaches and organize the work, review and merge their PRs without outside interventions, and plan their work however they wanted.
Additionally, each Beast would have its own leading member who would take initiative to organize work and present results. Thankfully, after successful team redesign and rebranding, we had no shortage of leadership on the team. My teammates, Erzhan, Mario, Aleksandr, and Viktor – with help from Paweł and Nicolás, who joined later – totally rocked that project!
Collaboration and knowledge sharing were still encouraged (in written format, asynchronously), but not required. I knew that in order to deliver the project, we had to compromise on something. This turned out to be possible code duplication and a little more tech debt than we would ideally want to have. Every stakeholder, including our product manager, engineering manager, scrum master, and team members agreed this approach made sense to finish the project on time.
Ruthlessly prioritize and focus
The second crucial part of the Beast Mode’s success was to convince stakeholders that we had to pause everything apart from the redesign project. Which we did – thanks to my fairly precise estimations and slightly more pessimistic project completion projections.
We still organized work in sprints but from now on, each Beast chose a single task from the redesign project scope to focus on during a sprint.
I also proposed to demo results twice per sprint, at the end of each week, to provide a better cadence and visibility of the progress.
The only thing we agreed to work on, apart from redesign-related tasks, was critical bug fixes. These were to be tackled ASAP by the team as a whole. This meant that no one Beast at any point would be required to fix any particular bug, and often I would jump in and do the dirty work so that the Beasts could continue uninterrupted.
The rest was ruthlessly deprioritized until after we had finished the redesign.
Each week I would update our projections and talk to each Beast leader to see if there were any issues with ongoing work. There weren’t many.
Eliminate distractions
Finally, everyone recognized that usual team activities – particularly important in a fully remote and distributed team – could be a tangible impediment to Beast Mode success. We decided to become almost fully asynchronous, switching focus from the whole team performance and processes to per-Beast ones.
Each squad had their own task grooming at the beginning of each sprint, followed by a shorter (30 minutes) joint team planning and two team demos, which took place at the end of the first and second weeks of each sprint. We shifted from being highly collaborative and thoughtful to crunching out as much working code as possible and showcasing it twice as often as usual.
As a team lead, I also rescheduled our 1-1 meetings with each team member to happen bi-weekly instead of weekly. We also made retrospectives happen only once a month.
Pressure on the team
It would be useful to ask ex-Beast members for their opinions, but I have a gut feeling that this way of working – particularly because of its focus on Beast autonomy and prioritization according to the most important team goal – was even less stressful and more joyful than our usual process.
People were energized and built features from the ground up at an unseen speed. We did accumulate some extra tech debt and took a few controversial decisions but thanks to the code modularization, they were almost always limited to the component boundaries.
We also kept hiring and got a few new team members on board while the Beast mode was being exercised. Each Beast then was reinforced with an additional developer (instead of introducing a new squad) to retain parity in work organization and output.
Regarding time off, I proposed only a slight change allowing vacations prior to the final month of the project, and limited time off during the last sprints to only a few days when needed to recharge.
Did the Beast Mode work out in the end?
Ultimately, the Beasts were able to crank out the redesign project on time, with a slight delay of just a few weeks – as opposed to a potential delay of multiple months.
What made this possible? In my opinion, primarily the amazing team members who were dedicated to the team goals, working alongside highly skilled developers from adjacent teams.
But the Beast Mode – an idea of splitting a team in squads, giving each the highest level of autonomy and trust, prioritizing properly, and eliminating distractions – definitely helped a lot too.
