Engineering gets agile: Beyond’s Tech Director promotes ongoing learning with a fluid team structure

Published on October 17, 2018

By: Cassiano Surek, Technical Director, Beyond London

Throughout my digital agency years, I’ve directed engineering teams with highly delineated roles. From recruitment to project allocation, the focus has for long been on bringing in Front End, Back End, Mobile or Quality Assurance engineers. More recently, also DevOps, given the need for interaction with Cloud computing providers.

Whilst collaboration has been abundant, team members naturally deeply focus on their own subjects, without crossing over to other engineering areas.

Then along came the full stack developers with a desire to cover the whole stack, but realistically translating into Front End and Back End only. Understandably, stacks evolve at breakneck speeds these days and to stay on top of everything, one needs to almost have another full time job learning. Not to mention the highly complex orchestration for distributed applications of late, where containers and message buses reign.

So when Beyond reached an inflection point of 20 engineers in the London Studio, we understood that re-structuring for scalability was necessary (more on that on another article, soon). We however also noticed that engineers, by their very curious nature, wanted to explore other areas. Their eagerness to learn had a cross subject, wide angle nature with an ongoing desire to experience more fulfilling and challenging work.

Intra-department mobility

To meet this challenge, we created a framework that would allow department members to move more freely from one area to the next, without the traditional position constraints.

We also understood we had to detach our engineers from projects, structurally. That was particularly important as agency engineers work with numerous clients and projects, as opposed to engineers having long engagements with the same client or product.

We therefore considered three main areas:

  • Title standardisation
  • Expanding areas of interest
  • Defining mobility-centric objectives

Title standardisation: Devs? Techies? Engineers or technologists?

These definitions are usually interchangeable in the tech world. We had to, however, agree on a common term for everybody. We considered the terms Developers, Technologists or Engineers, with the different positions having varying feelings towards them.  After discussions and deliberations with the whole team, we settled for naming everyone Engineers.

Expanding areas of interest with ‘chapters’

We removed the traditional Tech department position segmentation (Front End, Back End, DevOps and QA) in favour of 12 chapters, some of which would touch on Artificial Intelligence, Leadership and Creative Tech. They promote a consolidation around areas of interest, ensuring there is a positive spread of experienced team members and newbies. Our chapters started with a very loose structure, but we soon added more guidance to support their success.

Mobility-centric objectives

With the titles defined and the chapters in place, the next step was for managers to sit down with their team and define objectives to encourage the engineers to explore different areas. Whether training, leading, or applying the newly acquired knowledge to live projects, the chosen objectives had to promote mobility within the department.

The future

Just a few months after implementation, we can already see results. No engineer has moved fully to the opposite extreme of the spectrum, but lateral movement has been observed and is now fully encouraged and expected across the team. Moreover, new horizons have opened up to the engineers, there is more clarity on how they can grow and in which directions Beyond can further support them. We will continue to monitor performance closely and to iterate, supporting each other to experience more varied and interesting types of work.