Engineering Managers and team health: building trust that lasts
In today’s post we sit down with Rodrigo Neves, Senior Engineering Manager, to discuss the many elements of the second component within our Engineering Manager framework: team health.
I moved to Berlin to join GetYourGuide 6 years ago as a Software Engineer. The company was quite small and just starting to gain traction. On February 1, 2013, I walked into the office for the first time. The Engineering team in Berlin was made up of only 4 engineers, all from outside Germany, and three of whom were also starting that day.
All the startup buzzwords applied — we had a flat hierarchy, an open-plan office, agile development processes, strong relationships between team members, and lots of cross-department communication. As we grew and matured as an organization, I was fascinated by how quickly all these wonderful startup features failed to scale, and I was drawn to explore this topic more deeply.
One aspect I grew passionate about was how to sustain a healthy team environment within a fast-paced, dynamic organization going through hyper-growth. I have come to realize over time that a healthy team tends to demonstrate a larger amount of grit, which enables it to embrace change quickly, develop further, and naturally progress into a leading force within the organization.
Upon this realization, I started to develop what would become our Associate Engineering Manager program. The program aims to facilitate an Individual Contributor’s internal transition to a management role. When I began developing the program, I took time to reflect and collect a list of all the things I wish someone had told me when I took on a management role years ago. I spent countless hours reflecting, analyzing, reading books and blogs, and asking other managers for advice. I collected the most relevant of my learnings into 5 main pillars, which I share here hoping they will save precious time for current or future Engineering Managers.
Trust and dynamics
The strongest indicator of solid team trust and sustainable dynamics is the existence of an open and honest feedback culture. A team with a high level of trust proactively addresses internal conflicts and does not shy away from difficult and meaningful conversations.
It is the responsibility of the team's Engineering Manager to facilitate, coach, and relentlessly lead by example. Every action you take and word you say is under scrutiny by the team and carries a lot of weight. When I first became a manager, I felt this was an exceptionally heavy burden to carry. This added to the pressure of all the new tasks, expectations, and unknowns; it felt a bit like getting pushed under a bus. I strongly recommend you display openness and vulnerability in your 1on1 conversations with your team and manager, to facilitate empathy building and release some of the perceived pressure.
The other aspect you own is creating an environment with dynamics that promote trust, fairness, and cooperative behavior. More important than striving for a perfect environment in one go, is facilitating meaningful conversations on the topic and helping the team slowly but surely create and adjust to their own ideal environment. You are responsible and accountable for the environment that is created, and you should focus on helping and guiding the team.
We all aspire towards healthy team formation (Bus factor >= 2), distributed knowledge/ownership, and continuous improvement. But, realistically, the vast majority of teams I’ve worked with have had very limited resources, less than ideal knowledge distribution, and little to no processes in place (or even worse, unhelpful ones) at the start. At this initial stage, what proved most beneficial was putting in place basic processes for knowledge collection and continuous improvement and starting to draft a mid-term plan, even if it was filled with uncertainty.
On new teams, I was able to quickly make a positive impact by planning regular team sessions, creating a safe forum for issues to be shared and discussed. In holding these meetings yourself, focus on the most contentious topic and agree on actions, then move to the next. If you maintain a good frequency, you will start identifying patterns. These are your gold nuggets. I’ve found it extremely powerful to pair these sessions with increased 1on1 activity (either frequency or duration) to capture signals that wouldn’t have normally surfaced during the team sessions.
Regarding team formation, bus factor, and skills distribution, I’ve often been frustrated with the fact that it isn’t always feasible to hire 2 of every possible role in a team. So, how do we go about building this much needed resilience into the team?
When it’s possible to staff up the team, go for it, but when this isn’t feasible or sustainable, encourage a distributed ownership model inside the team where everyone feels comfortable leading initiatives end-to-end and plan regular cross-domain knowledge-sharing sessions inside the team.
Every manager I talk to, from Associate to C-level, agrees good onboarding is key to ensuring new hires reach a high performance level quickly, yet most struggle to come up with even a basic plan to get them there. We all agree onboarding is a critical piece to the team health puzzle, especially when hiring at a high volume, but it’s often one of the last items on our to-do list.
In a fast-growing company where the number of new hires quickly outpaces the number of established team members, it’s just a matter of time until the majority of your organization is in the onboarding process. This situation comes up often during the transition from 1-2 engineers on a team to a full cross-functional team of 8-10 people.
As I built onboarding plans and collected new hires' feedback, I learned two fundamental principles:
First, you will never be able to cover every single detail with documentation (and even if you do, no one will read it).
Second, it’s much more empowering to connect your new hires with the right network of people and resources from which they can fetch information as they need, rather than force-feed them large amounts of knowledge and context.
Based on those principles, I now tend to start small with a short onboarding plan and iterate with every new hire, thus, continuously improving the program. It’s important that everyone involved, including the new hires themselves, knows you expect the onboarding program to evolve. As soon as someone notices a missing detail or too much or too little information in one area, they change the program, making it better for the next newbie. The most recent onboarding then serves as a template for the next. Here's my basic 4-step onboarding plan framework:
Make a list of all the topics your team owns or are highly relevant to the new hire, basically everything the new hire must know in order to do a good job. A simple bullet-point list will do.
Group those topics into knowledge-sharing sessions that can be hosted by 1 or 2 existing employees. Assign one host for each of these sessions keeping in mind:
Everyone from the immediate team, and knowledge-bearers outside the team, should be involved.
As a first session, you should sit down with the new hire, introduce the program, and set expectations.
Spread the session topics over a few weeks, assign owners, and ask them to schedule as it best fits their agendas (within that week). Try not to overload the agenda, and don't worry too much about how many weeks it will take. You can optimize all of that later.
Collect feedback regularly from the new hire and adjust the program accordingly. When the time comes to onboard the next new hire, grab the latest version of the program, review it, make final adjustments, and then repeat steps 3 and 4.
At GetYourGuide, we put a lot of emphasis in growth, learning, and personal development, and we do our best to empower everyone in the organization to own their own development. Our role as Engineering Managers is to nudge, support, coach and guide our engineers to make the most out of this powerful cultural trait and align the incentives and opportunities between the individual and the company. We do so in 3 steps:
1. Define and document the company's expectations
We have developed our Engineering Career Framework detailing GetYourGuide's expectations for our engineers at each level in their careers, using our Engineering Principles and Core Values as a foundation. The framework includes a matrix of 5 career levels and 9 different traits, grouped into 2 areas: technology and behaviors. For each of those traits and levels, we describe what is expected and provide a few examples. One of the biggest challenges while developing and iterating on this framework has been to align everyone on what should be the Spirit of the Law, matching the intention of the framework, rather than the Letter of the Law, following the framework word-for-word. A personal learning so far is to avoid writing an extensive bullet-point list of example behaviors. They tend to lead people to think in checklists, rather than grasp the actual intention behind that rubric.
2. Understand the engineer's expectations
Growth and career progression are only built through meaningful conversations. Some engineers will proactively bring up the topic in their regular 1on1 meetings, but others might need to be nudged. I try to ask a few simple questions to get the conversation going if I realize the topic hasn’t been approached for a month or more. (E.g. What have you learned recently? What would you like to learn next? In what area of development do you feel you are progressing faster/slower?) My role in these conversations is to listen, ask open questions, and take lots of notes.
3. Find opportunities to align those two sides
With the privilege of knowledge and an understanding of expectations and ambitions on both sides, identifying opportunities to align becomes a daily routine. These can come in many different shapes and formats: prioritizing a certain project, making changes in a process or how the team works, enabling lateral / cross-team moves within the organization, etc. As Tao, our COO, puts it:
"Managers need to identify and reward potential with greater responsibility. It can be risky but there is no alternative. It is also the only way to grow people. Personal growth does not come from reading business books or taking ten trainings. It comes from encountering and mastering new challenges."
An often overlooked aspect of Performance Management is that it works both ways: more often than not, low performers tend to make everyone’s alarms sound while high performers are considered to be just doing their job and receive little attention. I‘ve caught myself in this trap multiple times.
An employee's performance may vary over time due to a large variety of reasons. Low performing periods only tell one side of the story, so reacting solely to low performance is like trying to solve a puzzle with only half the pieces. To effectively manage an individual performance over time, it’s important to analyze both high and low performance periods in order to find patterns. I find it extremely useful to raise the topic of performance, directly or indirectly, during our regular 1 on 1s, to understand how each individual feels they are performing and identifying the reasons for the current level of performance. The knowledge and understanding collected during normal and high performance periods will be key to managing those moments when things inevitably slow down.
There are a few things I tend to look for on a regular basis:
Are they particularly excited about a current or upcoming project?
Are there lingering/growing conflicts between colleagues?
Is the team environment contributing or detracting from overall engagement?
Besides gathering knowledge, these overperforming periods are unique opportunities to push the boundaries of an individual's development. I often take these moments to give the engineer more ownership/responsibility, making the most of the momentum and demonstrating a lot of trust. In a few situations this also meant offering these engineers opportunities outside of my own teams, which might look counter-intuitive for many managers, but will definitely yield greater results for the engineer and the company.
When it comes to managing low performance for a particular individual, I always start by trying to bring the root causes to light I recommend taking the time to dig deep in your 1on1s. These conversations are my biggest challenge as a manager, and I keep reminding myself (I often have it visible on my screen, on a post-it, written on my hand, etc.) of three main principles:
I am here to ask, listen and understand.
I do not need to find a solution right now.
Words and tone can hurt, if I am not sure how to phrase it, stay quiet.
Once I‘ve explained the source of my performance-related concern, I ask for the engineer's perspective and keep digging from there. It’s not uncommon for my observation to not be shared, so I strongly recommend being as prepared as possible for these conversations, bringing in facts, examples, and evidence to support the claim. I always assume good intentions, keep an open mind, and demonstrate extreme candor in order to build a trust-based environment. This also includes talking about the elephant in the room: does the company/team provide the right environment for the engineer to perform?
Understanding the source of the performance drop enables me to setup a plan accordingly. Not all dips require a full-on Performance Improvement Plan (PIP), I have actually come to realize that most of the time, all you need is a clear and honest conversation, re-aligning expectations on both sides. Only in the case of repeating performance issues, or an inability to align on expectations do I start an official PIP.
Again I strongly recommend keeping it simple, documenting what was already discussed in regards to expectations and performance gaps, including examples/evidence, and then defining with the Engineer what areas to focus on and how to achieve significant improvements in the next week and month.
Despite all the effort and good intentions on both sides, sometimes things just don't work out. And that’s ok! After going through the previous steps in an open and honest way, there is no point in postponing the inevitable, just ensure everyone is treated fairly and that the company's best interest is covered.
Managing people's performance is complex and there are no silver bullets. You are not alone in this process and it’s ok to ask for help from your manager/mentor, more experienced colleagues, and HR.
Team Health is a foundational pillar to how we build high-performance teams, demanding prioritization and time investment. Balancing the different components of team health creates an exciting challenge for any Engineering Manager aiming to lead a happy and trusting team of engineers on-track for personal and professional growth. Although every Engineering Manager will have their own style and priorities, and every organization/team its own culture and maturity, team health is one aspect that must stay top of mind.