Recently, I’ve had the good fortune to meet Jon Lax – formerly of Toronto agency Teehan+Lax, now of Facebook. Beyond being terribly humble, Jon has put a ton of thought into how to best organize modern teams to deliver beautiful products. Teehan+Lax found great success for itself and its clients by exploring how to work “above the API”; a separation between the responsibilities of back-end and user experience on a product team.*
APIs have had huge impact on digital. Public and partner APIs have opened up new distribution channels, spurred new product innovation and made it easier for organizations to reach users across channels and platforms. Beyond the data and functionality that these programing interfaces provide, they also disrupt the typical structure of a web development team.
Web development teams will be familiar with the friction that can form between the front-end and back-end teams. The API offers a bridge that allows both teams to work separately without waiting on each other to progress – it sets front-end creation free from a dependence on back-end data.
Freeing the Front-End
Modern software architecture has allowed a decoupling of back-end and front-end logic. APIs have introduced a new layer between data and user interface. Products like Amazon Echo have shown the possibilities of separating back-end data from the front-end interface. Similarly, we can use this new layer to look at team structures and processes differently.
In the past, front-end developers and designers needed to be tightly coupled with the back-end team. There was some slight separation – interface teams could develop a static prototype to guide the back-end team, for instance. However, the reliance on back-end developers to fully realize speculative design work ultimately led to a lot of wasted effort on the front-end, or a finished product that didn’t carry the same emotional weight as the original design.
Working above the API offers a new dynamic for product development teams. Rather than relying on a back-end team to build the database, designers have the ability now to use the same JSON structure that the backend team will fill in later from the database. In the past, back-end teams have had to structure data to try and match visual design. This often required programmers to make design changes or to wait for the design team to create the visual interface before they began structuring a site’s data architecture.
Now, the designers and front-end developers can think about crafting a beautiful experience and simply tell the programmers the data they need to make it work. This empowerment of designer and front-end developer is critical to making a successful product. Allowing them to work as an integrated team – without the restraints of back-end considerations – empowers the front-end team to deliver designs that go beyond the flat pixels. The subtle interactions that happen during usage are often the most endearing aspects of a product experience, and they can only result from a close collaboration of design and front-end development.
Putting It Into Action
This creative freedom creates two distinct workstreams – a user experience workflow that can set design and content knowing that it won’t be merely inspiration for programmers, and a back-end workflow focused on the business logic and the database. The back-end team can simply provide the data endpoints, and front-end developers can choose how and when to pull specific data to meet the needs of the interface.
Airbnb offers a strong example of the power of this model. Programmers know that each rental listing will need certain data points: weekly and daily rental rates, property photos, room counts, etc. But since they can simply deliver JSON data through the API, they don’t need to worry about how it will be consumed – they simply provide the data knowing that the front-end team can determine how and when to use the data points it needs.
This offers a degree of freedom that was nearly impossible just a few years ago.
New Team Dynamics
Before we transitioned to the MEAN stack to fully leverage the wealth of APIs, our teams were boxed in by the tight integration needed between the front end and back end. When we built teams, we considered values and team dysfunctions as much as skillsets. We knew each product team would have a designer, a front-end dev and two back-ends to build data architecture. Working above the API, it made more sense to organize our front-end developers within the design department, not in software teams, to reinforce creative collaboration.
These new technologies have opened up new possibilities for team dynamics, but most importantly, we’ve been able to deliver new solutions to our clients.
At 352, we’ve already seen a rapid evolution of our team structure through the use of APIs and new workstreams. In two years, we’ve grown from five .NET teams to 10 teams working almost exclusively in Node.js. We’ve been able to spin up UX and marketing micro-teams – still dedicated and iterative – that can deliver powerful experiences without the need for robust programming.
Rather than decoupling the team, APIs simple decouple the reliance that designers previously had on back-end engineers. We still believe strongly in standing cross-functional teams, but working above the API allows each side of the fence to do their best work and then meet in the middle.
As the industry progresses into the API-age, we’re excited to see how teams and output continue to evolve.
*We’re aware that “above the API” has other connotations in the skills economy, but at its heart we view it as a freedom from the structures old development models.