Emily Eng
Emily Eng
Jul 7, 2018 · 5 min read

Throughout the first half of 2018, the Meetup Pro team experimented with different ways to make our engineering teams more effective. We found that growing engineers into T-shaped engineers enabled our product teams to deliver more and deliver faster.

What is T-shaped engineering?

Looking at the letter T itself, the vertical bar on the T represents depth of expertise in a single field. The horizontal part of the T represents cross-discipline competence, a breadth of shallower skills and knowledge in other disciplines, enabling engineers to collaborate across those areas as well. Essentially, T-shaped engineering means having both depth and breadth when it comes to the skills one possesses.

What this does not mean is possessing every skill needed in order to be an expert in all disciplines. T-shaped engineers are not experts in every single discipline. The example shown above represents a core engineer possessing deep expertise in backend engineering while also knowing about web engineering, infrastructure engineering, user experience, and quality engineering.

How does T-shaped engineering impact a cross-functional team?

Let’s define what a cross-functional team is. To quote The Scrum Guide:

“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”

When Meetup made the organizational shift to business units, that inherently created cross-functional teams. Meetup Pro, our business unit, is made up of all disciplines: product, design, core engineering, web engineering, infrastructure engineering, etc. Therefore, we are empowered! We own everything when it comes to our customer experience and the delivery of that experience. Adding T-shaped engineering to a cross-functional team enables us to optimize our flexibility, creativity, and productivity.

Past vs. future

In the past at Meetup, teams were more I-shaped, or organized around a particular expertise. For example, Meetup had a web engineering team, an infrastructure engineering team, etc. Similarly, our management lines followed this structure — we had web engineering managers, infrastructure engineering managers. While I-shaped expertise is certainly a highly valuable skill set, we learned that this type of competence is not as effective for cross-functional team collaboration.

We knew that we wanted to move from being I-shaped engineers to T-shaped engineers, but this applied more broadly than just at an individual level; we wanted to improve how we worked as a whole team. We wanted to move away from being multiple I-shaped engineers balancing multiple, parallel projects and instead become a team of multiple T-shaped engineers rallying around a single project or objective.

A good example of how this happened on our team is to take a look at some of the projects we worked on in the first half of the year and how long they took to deliver. The team ran parallel projects in our sprints based on disciplines — the core engineers worked on a Salesforce integration with one of our Scala microservices, the web engineers worked on sending data to Google Analytics from our React app, and our sole infrastructure engineer worked on reducing the build time of our Travis builds. What this resulted in was multiple projects taking longer to deliver than if the team just had one single focus.

As a result, we made a conscious decision to switch the way the team worked, and for our next project, we had all hands on deck. The project was an entirely infrastructure-based project: build a canary pipeline for our web deployments. This meant everyone on the team worked on the canary, whether or not they were familiar with the infrastructure code. This led to engineers pairing with each other on tasks and learning a lot from our infrastructure engineer, who was the most knowledgeable about the code. This change not only focused the team, but also had some other great benefits.

Benefits

We deliver faster

When we previously had engineers working on projects only within their area of expertise, it took much longer for those projects to get done. When we assigned one of the team’s core engineers to work on a hefty backend integration project, it took almost two months, as they were the only one working on it. However, when the whole team focused on building on the canary pipeline, we were able to deliver it in two weeks.

We are more productive

There was less context switching on the team, making everyone more productive. Engineers always stayed in the same context when they rallied around a single objective. The new focus of our team was the true catalyst of our increased productivity.

We are breaking down silos

Having a T-shaped engineering team prevents bus factor and siloing of knowledge. When everyone on the team is working together on a single project, knowledge is shared by default. When knowledge is shared across the team by how the engineers work together, this reduces the need to explicitly arrange cross-training of disciplines — it’s already happening! With a single project focus, engineers will inevitably be pushed to do tasks in areas they are unfamiliar with, allowing them to grow their skill set in that area. Additionally, the shared knowledge of an entire project leads to team members no longer having an “It’s not my job” attitude and instead fosters full team ownership of projects.

Next steps

If you have been convinced that T-shaped engineering is something you want to try, here are a few easy next steps that you can take.

Make sure you understand the priorities of a given sprint

Know what is acceptable to rollover and what is not. If your engineering lead says the priorities of the sprint are A then B, make sure you are working on trying to get out A before picking up any tickets related to B. This will help ensure that all team members are rallying around a single thing at a time and learning and growing their skill sets.

Pick up a ticket that you are not familiar with and ask to pair with someone on it

Better yet, offer to pair with someone on a ticket you are already working on. Sometimes folks can feel nervous or guilty about asking to pair with someone. Make it easy and offer to pair with your teammates.

Attend a collective meeting that you do not normally go to

Meetup has a number of collectives, which are groups centered around discussing topics and establishing best practices related to a particular discipline (e.g., web engineering collective, core engineering collective). If you are a web engineer, why not try attending the infrastructure engineering collective meeting?


Our team is bold, supportive, and passionate about bringing people together in real life to create community and opportunity for everyone. Join us!

Making Meetup

We're here to make Meetup.

Emily Eng

Written by

Emily Eng

Engineering Lead at Meetup

Making Meetup

We're here to make Meetup.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade