One of the more interesting things about the Product Team at 50onRed is its mobility. While relatively small, the Product Team has its fingers in three totally discreet products simultaneously. Not only that, but each member of the Product Team is working on at least two products at any given time and works on every product at least some of the time.
Why would we do that? At first glance, it appears that such an approach would be quite ineffective: It leads to a team that is spread too thin, a lack of domain-specific expertise, and the costs of constant switching. It seems hard to manage. Mostly, it just seems inefficient.
Of course, there is validity to those arguments. Being involved in so many projects simultaneously does incur some switching costs, and it does increase the managerial overhead. We spend a little more time in meetings because we need to keep abreast of the development of multiple projects. These arguments are part of the reason that most of our engineers work hard to become experts on one, just one, product. Nonetheless, there are some great advantages to having at least one highly dynamic, mobile, distributed team, despite the cost.
The most visible advantage is that, by being able to touch everything, the Product Team is able to maintain consistency across projects. This seems tough. After all, 50onRed is a company that believes in using the right tool for the job. As a result, we have products with Python/Flask backends, projects with PHP/Laravel backends, and projects built on Ruby on Rails. We use Redis and Redshift and MySQL. Some of our products use Backbone.js, some don’t. Managing consistency with so many languages and frameworks seems futile.
But here’s the thing: It’s not. Focussing on the elements that are common to all products saves us an enormous amount of time, effort, and money. By investing in consistency, we’re able to recycle front-end components across projects. More than that, common file structures and design paradigms increase the fungibility of engineers between products. While it doesn’t happened all that often, when engineers do switch between products, the common structure dramatically decreases switching costs.
One example, which you’ve probably heard about in one of our previous blog posts, is our plug-and-play style guide. It is a set of styles that we can drop into a new project to immediately kickstart the front-end, complete with tables, widgets, CSS, and JavaScript utility functions. That’s cool.
Even cooler, though, is that when our designer decides that a change to our navigation bar would make it more functional, or smaller table rows would make tables more useful, or maybe #6baff5 isn’t the prettiest color for buttons, we just need to update things in one place and bump the style guide version of each of our products. If each product had its own class names and HTML organization, that wouldn’t be possible.
Similarly, if push comes to shove and there’s a new feature that needs to be rolled out yesterday, it’s easy for us to re-allocate resources. At a moment’s notice, we can have all hands on deck, without requiring any onboarding or explanation of a product’s structure or design paradigm. Note that this applies to all of the company’s engineers, not just the Product Team. Because the Product Team has tried to help expose consistent patterns across products, even brand new code isn’t that foreign to anybody.
Most seasoned engineers know the difference between a good team and a bad team. The engineers on the good team work with each other, leverage each others’ know-how, and build a self-reinforcing community that leads to accelerated personal growth. The bad team, while it may be filled with excellent engineers, is less performant due to poor communication and deficient collaboration. Worse, the engineers on the bad team will have stunted personal growth because they fail to learn from their colleagues.
Fortunately, 50onRed has very good engineering teams. In the last half year at 50, I have learned far more than I did in the previous two years at school combined. That’s because at 50onRed, I am surrounded by extremely talented, motivated engineers who teach me a lot, helping me learn about patterns and techniques I never would have had the expertise to learn on my own. Moreover, our “floating team” structure has the added advantage of helping everybody learn faster—not just the people on that team. See, through exposure to all of our products (and all of our excellent engineers), the Product Team acts as an aggregator of best practices and a compendium of failed experiments. It can then relay those things to the siloed product-specific engineering teams. As a result, when the engineers working on Product A face a particularly tricky hurdle that we know the engineers working on Product B faced just a few months ago, we can ensure that the Team A guys know exactly who to talk to on Team B to avoid reinventing the wheel.
Let’s recap: At 50onRed, most of our software developers are grouped into relatively fixed teams centered around a product. Those engineers become experts on their product and domain. In addition, we have a Product Team which touches all of the products. This enables us to build consistency, which in turn saves time by allowing us to recycle components and reduce switching costs across the company. It also increases the circulation of knowledge and best practices around the company, resulting in a workplace that produces not only better products, but also better engineers.