In engineering, growth is a double-edged sword. It’s great for expanding what we can accomplish on the product, but a growing department can also make it harder to make progress on technical initiatives that affect the entire department.
Here at The Zebra, our engineering team has grown at a stampede’s pace over the past couple of years — and we’ve accomplished a great deal. With the addition of a herd of talented developers, we’ve expanded from three core frontend applications to eight. However, the biggest hurdle we faced wasn’t the development of these applications, but maintaining cohesion across teams and tackling big picture initiatives.
We needed a proactive solution that could scale with our future growth.
At the end of 2019, our department managers floated the idea of putting together a task force of frontend developers that would represent each of our product and marketing teams. This task force came to be known as FEAR (Frontend Architecture Representatives).
Despite the somewhat intimidating acronym, FEAR’s mission was to collaborate, identify and tackle cross-team initiatives.
Three other frontend developers and I began as the initial team with a clear directive:
- Help guide standards and best practices.
- Focus broad ideas into initiatives.
- Show meaningful cohesion amongst our frontend + design teams.
- Help the product team stay up to date on UX/UI initiatives.
What We Did and How We Did It
Before we delve into the nitty-gritty of how we accomplished some pretty amazing things, let’s go straight to why it was all worth it. Nearly two years and one pandemic later, the accomplishments of this FEAR task force have yielded clear, qualitative results. We have:
- Aligned engineering, design and QA on the same list of browsers we support — and to what extent we support them — based on our quarterly traffic
- Migrated from Enzyme to Jest
- Set up frontend performance monitoring tools across all our apps
- Created a shared component library
- Aligned and documented our workflows between our engineering and design team in a remote-first environment
Now let’s look at the key pieces that made this success possible.
1. A passionate team of developers
The success of this initiative would not have been possible without a team of developers that share a passion for our product and incredible respect for one another. Our shared purpose motivates us to work on these often ambiguous projects that require us to step out from our primary function. As developers, we know how hard it is to shift your focus throughout a work week. FEAR is asked to do precisely that for the sake of our user and developer experience. If you’re looking to do something similar for your department-wide technical initiatives, it’s important to have the right team in place.
2. An (evolving) shared ownership model
From the get-go, we knew shared ownership and maintenance of this program were key drivers for success. We didn't want an engineering manager or just one of us to lead meetings, take notes, facilitate follow-ups and send out reports. Therefore, we set up a rotating schedule where all of these responsibilities shifted each week. This collective buy-in created a sense of camaraderie among the FEAR team.
While this rotating format was great for managing meetings, it proved to be restrictive for driving projects. We were limited to the number of projects we could manage at once. To maximize efficiency, we shifted to a model where each project had a single, clear owner. We needed one person to own technical design documentation, identify key stakeholders, update status reports and drive the overall project forward.
3. A consistent structure
Since this team was only meant to spend ten percent of their time on FEAR-related initiatives, we needed to nail down a structure so it was easy for any member to pick up an initiative or lead a meeting. Our weekly meetings follow the same pattern and include a note template so whoever is leading can easily facilitate discussion while taking notes and assigning action items. This includes a step-by-step process for getting started on a new initiative for the designated owner. Our team meetings always follow this basic structure:
- Kick-off with a list of action items from the previous meeting
- Discuss any new ideas or questions that have come up over the past week
- Allocate plenty of time for a thorough investigation of all ongoing projects and status updates/needs from project owners
- Curate a list of action items for the following week and tag owners
Challenges Faced and Lessons Learned
As we can continue to scale FEAR, we have adapted to the challenges we faced and learned some things that have helped us work more effectively.
One pretty obvious challenge we face is time. A project like building a shared component library involves a ton of coordination and time — a resource developers just don’t have. We’re still pushing through, but we’ve had to accept weeks without updates.
An important lesson for us to learn was knowing when to call it a day on an investigation or issue. It’s easy for us to slip into the role of actually doing all of the work for an initiative we own, but that’s not practical with the allotted time. The purpose of the FEAR team is to guide solutions across frontend teams. We need to make sure we’re not falling into the temptation to solve a problem entirely ourselves and instead designate the right individuals to prioritize and carry out the project.
The challenge of scaling
Another challenge we’ve run into is figuring out how and when to add new members to our FEAR squad. Since we started, we’ve added more frontend applications with their own dedicated teams. We anticipate that our FEAR team will need to echo this growth. However, it leads us to question FEAR’s structure. Does a frontend developer from each team still make the most sense? We recognize the benefits of being a small, caring team and fear that too many people on the task force could potentially be less efficient.
On the other hand, interest in our FEAR squad is growing. Other developers have expressed interest in joining, seeing this task force as an opportunity for career growth. We’re currently working with our leadership team to brainstorm some ideas around how involvement on this team could evolve in a sustainable way while supporting leadership opportunities for those interested.
Based on our planning with leadership, we recently opted to open FEAR membership to whoever is interested in being a part of company-wide frontend conversations and initiatives. The same type of backend architecture team formed and decided to keep their involvement totally open, so we shifted our model to echo theirs.
We've kept much of the structure the same. We still have a rotating schedule for logistical responsibilities, an established owner for each initiative and time set aside to prioritize incoming issues and ideas. We started to see great feedback about what our team was doing, and it felt wrong to keep that sort of recognition locked into an exclusive group. That said, the original FEAR team knows this change will come with a new set of challenges. As I identified earlier, the right team is so important to the success of a program of this nature.
However, as we get ready to shift what our existing FEAR team looks like, I’m reminded of some key learnings I experienced in my tenure.
- Know there’s no ‘I’ in FEAR. Whether it’s an open invite or a carefully selected team, this task force needs to have passionate, respectful developers who share a common goal.
- Stay organized. Documentation, especially in a remote environment, is a necessity for collaboration.
- Get OK with ambiguity.Some projects are going to stall due to a lack of time and resources. Follow up and resist the temptation to do it all yourself.
- See the big picture. Your team may need to evolve with company growth. What exactly does that look like?
With these in mind, I look forward to helping to shape the future of FEAR as The Zebra continues to expand in exciting ways.