Moving teams as an engineering leader

At Lendable, people are encouraged to pursue opportunities to move between teams and domains. This is a fantastic dynamic that gives everyone the chance to keep growing and learning. However, as an engineering leader, that comes with a specific set of problems that may not be all that clear from the get go…

So far I’ve completed two of these transitions, soon to be three! I have found that having a methodical approach to moving between teams has helped me ensure that the transition maintains an expected level of delivery, a clear definition of success, and — most importantly — that the team members that report to me have a safe space to continue doing great work.

In the past, I have utilised the following three strategies:

• Decisions through your principles
• Listening tour
• Engineering Readiness

Although these are not an exhaustive list of what could be leant into as part of the transition to a new team, they’re a great starting point for you to identify other problems to lean into and explore.

Decisions through your principles

Simon Sinek speaks around leading with values when it comes to operating a business, and the same can be said for leading a team. When coming into a new team it is extremely important you show consistency in your leadership style, and the values & principles you use to drive your decisions.

These principles should be actionable. It’s easy to say, “let’s be more innovative”, but how does that translate to execution? When beginning to work with and lead a new team, it's vital you set the expectation and foundation for the type of leadership style you want to embody as you move forward.

My leadership principles can be distilled down to three core definitions;

Accountability

Every piece of work I undertake, I am accountable for the success of that work

Every team member should know what they are accountable for. If somebody takes on a project or task where they feel unclear who is ultimately accountable for that work, they should hold up a big red flag and get that answer.

Examples in this space vary greatly by company, but for us we have the concept of a project owner for each project that we undertake on a quarterly basis, similar to how GitLab envisages a Directly Responsible Individual (DRI). As an engineering leader I need to ensure that every team member is clear on what is expected of them when owning a project.

Ownership

When executing on work, I am in control of everything required to get it over the line

Similar to accountability, however it is important that as a team member you know who is involved and what needs to happen to successfully consider that work complete. It means owning the spaces required to achieve that success. Owning this space could vary depending on the problem in front of you, but you should feel empowered to make decisions or move the strategic direction of the problem in the way you deem appropriate.

For example, if an engineer has a project that they’re leading they should be able to appropriately break down the work, resolve ambiguity, and ensure there are clearly defined definitions of done. That may require some support from the engineering manager but it is the direct responsibility of the engineer to know what flight level to escalate to. The engineer may consider reducing scope or adjusting the objective of the project to fit some technical constraints, and you as an engineering leader should support the engineer in deciding what changes need to be made — creating that space is vital for the success of this value.

Transparency

At every opportunity, I will be completely open with my thoughts and work

One of the most important aspects, especially as a leader, is to be as transparent as possible. Of course as an Engineering Manager there will be times when you can’t be completely transparent but it’s important to be clear, concise and targeted in the communications you make

Let's say you are moving between teams at a company. You’ll need to ensure you have a clear communications plan, detailing the why, who and how. This doesn’t just mean for the people you’ll be taking over/handing over, but the wider company as well. Sometimes, the medium is the message too, so with some stakeholders or people it’ll be just as important to create a space where you can be vulnerable, both ways, and listen.

These three principles all align toward a common goal which is not only embodying & consistently being the leader you want to be as you move between teams but also setting the team up for success giving them a high level of psychological safety which can take a lifetime to build, but seconds to destroy.

Listening tour

Evolution over revolution has always been my tried and tested method for moving between teams. As an engineering leader you should be leaning on your previous experiences to shape the future of the team, coming in too strongly opinionated without having all the facts risk two less than ideal outcomes:

1. You’re wrong. You didn’t get enough information before making a decision and have taken the wrong thing to lean into/change.
2. People see you as too pushy. Imagine someone came to you in your job and changed everything after a couple weeks? This wouldn’t bode well for your future working relationship.

To avoid these, always consider engaging in a listening tour. Make no decisions at all for a specified amount of time, approach the problem like a beginner, listen to the concerns of your team and stakeholders (and the things that are working well too).

By engaging in a listening tour you should be touching base with every person within your business unit, not least to begin to form those key relationships to enable continued success.

The First 90 Days is a fantastic resource for more insights on this point. It details really nicely where you should be focussing your efforts in the first 90 days of any new role and how to frame your journey from onboarding to execution.

Engineering readiness

On a more practical note — and a topic that probably deserves its own post — having an Engineering Readiness checklist is a fantastic resource to create the space to get a consistent “lay of the land” before diving into the work.

This list can vary drastically but it could cover everything from ensuring there is a clear definition of what ceremonies the team run, all the way to engineering risk registers, alerting for technical infrastructure degradation and even things like code quality/complexity integrations.

This checklist leans quite heavily into the “work around the work” and what engineering readiness looks like really depends on the type of team & problems you’re walking into. But having a concrete list of things you’d like to understand more about really helps to clarify not only your own understanding, but also that of the team too, as this could highlight any potential misalignments within your team.

These three strategies are a great starting point for any engineering leader to move between teams in my experience. This isn’t just exclusively between teams at the same company either, they also work at a new opportunity too!