How our Engineering leadership team worked together to establish a shared purpose as a base for our group discussions - and how this forms our guiding principles for decision making and overall direction.

As the team I lead grows substantially, my role has changed during 2019 and the first half of 2020 from leading engineers to increasingly leading leaders who lead engineers.

One of the most obvious challenges in this period has been how to distil the principles by which I led engineers directly in such a way that as our leadership team became larger we could maintain some level of consistency and structure for our engineering organisation.  As we grow we want to take advantage of new perspectives on engineering leadership whilst at the same time maintaining a clear and unified direction for our organisation.

Our journey towards this goal started by focusing in on our specific role as a leadership team and, more specifically, why we exist and what we want to achieve.

A clear purpose is an essential ingredient for any high performing team and purpose is one of the essential building blocks for the motivation needed to deliver high performance.  

As a team we were clear that we needed to be focused around a shared purpose that could be the base for our group discussions and provide us with guiding principles for our decision making and overall direction.

### What do we want to achieve?

We started the process by working to really break down what we wanted to achieve as a team.  What was the one goal we all shared that could bring the greatest value to the organisation we lead?  

Our focus has always been on the individual engineer - building up each engineer, enabling them to be the best they can be, strong in the knowledge that with a group of motivated engineers at least some of the hard work of building a high performing team would be in hand.

With this in mind we thought about what engineers really need to be productive and to be able to perform at their best.  There are so many practical things that go in to this - a comfortable working environment, using the latest technology, working on an engaging product roadmap, working on a modern stack - but even with all of these practical elements in place it was clear that even more important than this was offering engineers an environment where they could be safe to experiment and focus on doing their best work.

### Our shared purpose

We agreed on the following statement and engineering leadership pillars that we believe encompasses our every day work as a leadership team:

> The leadership team exists to create an environment where engineers feel safe and encouraged to do their best work every day.
>  
> We will create this environment by:
>  
> - Ensuring squads and engineers have the autonomy they need to be brave and motivated to create awesome shopper experiences that they can be proud of
> - Creating safe spaces and opportunities for every engineer to be curious and enhance their craft based on a consistent and well-structured development path
> - Collaborating with product line leads to ensure that each squad has a clearly defined purpose and reason for being that enables engineers to focus on product outcomes
> - Providing a clearly defined set of engineering and architecture best practices and the opportunity for every engineer to shape and evolve these practices for the future

As engineering leaders we typically split our time between proactive technical leadership - of a product squad or technology area - and engineering leadership where we're scaling our organisation and working with each individual engineer to enable them to develop.

This core statement - and the four pillars - enable us to align our activities and ensure we are leading with a shared purpose to achieve the best possible outcome for our team, our squads and each engineer.  In upcoming posts I'll write more about each of our leadership pillars and how they can come together to enable us to create a high performing technology organisation.

If you have a new leadership team or an existing team that is perhaps not all pulling in the same direction, I'd highly recommend taking a step back and spending some time to think about what your shared purpose is as a leadership team so that you can regroup and move forward and start to lead with a shared purpose.

*__With thanks:__ defining a shared purpose only comes from working together and so I'd like to thank the Direct Shopper Engineering Leadership Team at the LEGO Group in London for their determination and focus in coming together to define our approach which I've shared here.*

Leadership with Shared Purpose

A guide to the principles I have developed over the last 10 years which I believe are key to building, leading and growing successful software engineering teams at scale.

I have been involved in leading software engineering teams for more than a decade — first as a technical lead, and then as a member of senior management teams where I have been responsible for software teams of different sizes using very different technology stacks. I am now responsible for leading a large and growing software engineering team as well as being responsible for our overall e-commerce platform architecture.

Over that time I’ve come to settle on some principles that I’d like to share here which I feel are key to developing and leading successful software engineering teams.

## A decade of change

Over the last ten years or so, software engineering has seen seismic changes in the technology world around it — even more so than in the periods that went before — particularly in the areas of cloud computing and open source adoption.

At the same time, whilst some traditional large enterprises have made the jump to change their strategies and principles in line with this industry shift, for many others the pace of change is hard — sometimes impossible — to manage.

For many years, enterprises have run core areas of their businesses on large monolithic ERP and trading systems from long-established vendors like IBM and SAP. Typically these systems move slowly and a 2–3 year major upgrade cycle with half yearly release schedules is pretty normal. Not only is it normal but in most enterprises it’s necessary as they simply don’t have the processes or systems to modify platforms and accommodate change more quickly than this.

Of course for an ERP or other financial accounting system this isn’t always too much of an issue — after all core stability is critical to the overall operation of an enterprise. However the rise - the takeover - of digital in almost every consumer-facing business around the world brings with it a completely different set of consumer and shopper expectations, different employee expectations, radically different vendor choices and a very different set of challenges to solve at many different levels of a business.

## Transformation is a grass roots effort

What I’ve learned is that you can’t drive the transformational change that is needed with a top-down mentality only. Of course you need ongoing support from very senior levels in an enterprise to effect transformational change — without this buy-in and support you will run in to a series of brick walls day after day — but where you really need to effect change is on the ground, where your day to day decisions are being taken, where your UX is being developed and your code is being written.

*Effective software engineering teams are one of the defining factors in the success of any digital transformation programme.*

So how do we go about creating these types of teams?

## Beware Conway’s Law

Nowhere is [Conway’s Law](https://en.wikipedia.org/wiki/Conway%27s_law) more prevalent than in the world of software engineering.

> “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
*Melvin Conway*

Simply put, Conway theorised that as teams across large businesses attempted to organise themselves in the delivery of solutions they would repeatedly design and build systems that mirrored the structure of the company itself.

A high functioning software engineering team, unconstrained by Conway’s Law, can deliver transformational change and bring it’s influence to bear across a much larger cross-section of an enterprise than it is directly responsible for — whilst an unsuccessful software engineering team is constrained only to create ever-repeating, slightly modified “Conway-esque” versions of the systems created by teams that went before it.

So how do you avoid being another example of Conway’s Law and create that high functioning software engineering team? Every team will necessarily be different — they will be building different systems on different software stacks for different businesses, most likely with very different principles and cultures — and most critically of all they’ll be building for a very different and individual customer.

There is no one size fits all guide to what a successful software engineering team looks like and how you should go about building it.

However with that said, over the last ten years I’ve learned a few things that I believe really matter when you’re serving engineering teams as a manager or leader and I believe that these learnings can give you the best possible chance of building a high performing team.

## Be clear about your leadership role

Firstly — and perhaps most importantly — you are no longer a front line engineer. Accept this. You exist primarily to serve your engineers and to support them in serving your customers.

Let the engineering team solve technical problems — instead concentrate your efforts on building and developing the team, providing them with strategic technical direction and removing any roadblocks that prevent them from succeeding.

Don’t be afraid to get involved when the team asks for your leadership — for example during an operational issue or to resolve low level chores that the team are too busy to complete — but whatever your engineering background you should be resisting the temptation to jump in with major codebase contributions that you can’t effectively support in the future.

If you want to maintain your coding chops then there is a whole world of open source projects that will welcome your contributions. I’ve long come to the conclusion that engineering leaders who feel the need to maintain significant codebase contributions are in fact exercising their passive desire to exert command and control and prove they can still mix it up with the most skilled of engineers.

## Be situationally aware

Your level of influence in the wider enterprise is going to vary wildly depending on the type of business you work in. Typically in technology companies, engineering leaders have a significant voice at the table whilst in more traditional media or retail driven businesses you might find your influence doesn’t stretch as far.

It’s crucial to understand your own playing field before you think about setting one for the team. Failing to understand your own role and influence can create a significant roadblock to your team’s ability to succeed as they will be unclear on their own mission and sphere of influence or how you can best serve and support them.

Once you clearly understand your own playing field make sure you take time to translate this in to a playing field and set of expectations for the engineering team.

There are a few different methods you can use to actually help to clearly define the playing field but at the end of that exercise you and the engineering team should share a mission and purpose that is clear and that you will all take pride in achieving.

## Build an environment where the team can thrive

Teams succeed when they can grow and work in a safe and supportive environment.

Most importantly of all a productive team environment must embrace setbacks and failures as fuel for future improvement. A blameless culture can be very difficult to achieve — particularly where teams are working on high availability or highly visible products and platforms but it is a crucial building block for success.

*A blameless culture is not equal to a zero pressure culture.*

There is a critical balance to find here — the right amount of pressure on engineers to do their best work and to continuously improve is good particularly for new and growing teams. At the same time you need to understand your team well enough to know when the pressure is becoming counter productive.

Teams need to be clear on what is expected of them. Ensure you are always able to set a clear and consistent strategic and technical direction highlighting your desired technical outcome and any guidelines around how to operate. At the same time work hard not to define the detail of ‘how’ things are built. If you slip in to defining the detail of every solution you will become a frustration to the team and an inefficient bottleneck for your business.

Always be ready to listen to new ideas from wherever they come — the better you are at this skill the better the ideas and solutions from your engineers will become.

## Know Your Team

Any engineering team is only as good as the individuals within it and only as strong as the relationships between those individuals.

Whatever size of team you are leading, you have a responsibility and an obligation to each individual engineer to support them and develop their careers. This starts with ensuring you know every engineer individually and ensure that they are also clear that you prioritise these relationships.

Even as your team grows and senior engineers take on coaching or mentoring roles, you should strive to maintain “one to one” sessions and conversations with every engineer in the team at every level of experience. As the team grows these sessions may necessarily become less regular but you should still prioritise this time, only ever rearranging or cancelling with very clear reasons and well in advance of the session. This investment in time, more perhaps than any other, will serve you and them well in to the future.

At the same time ensure that engineers have access to day to day technical guidance and mentoring and be comfortable with this coming from somebody other than you. Focus on coaching your most senior engineers to become trusted and empathetic mentors to the engineers around them and ensure that the team know those coaches have your complete trust and support.

## Hire Well

The best engineers I have hired have not always been the most technically experienced engineers that I interviewed. Always, always, hire for the person and not for their skills alone. New skills and competencies can always be learned but it’s rare that you can change the underlying personality of the person you hire — and indeed why would you want to?

I follow a few simple rules when I’m hiring:

- Diversity matters — both in the more obvious sense of gender, race, ethnicity and nationality of course — but it also matters hugely in terms of experience, career background and personal circumstances. A team full of computer science graduates with ten years programming experience each is not a guaranteed route to success. In fact it’s a pretty well defined way to achieve the exact opposite.
- Don’t be afraid to hire engineers whose technical knowledge or business experience far outweighs your own — in fact you should be actively seeking out those engineers. If you are the smartest engineer in the team then your team is probably in trouble.
- If you are hiring multiple engineers at once try to hire a group of people that you see working well together — even if they aren’t the most experienced or skilled candidates in the process. Bringing in small groups of people that are able to form good relationships with each other quickly will significantly lessen the inevitable impact on team efficiency that comes with new additions.
- If you are hiring a single engineer go all out to find the most skilled person you can for the role — they will be integrating in to the team by themselves without any other new starters for support and so confidence in their own abilities will substantially ease their path to integration.

Hiring is one of your most important tasks and also one of the most challenging — so ensure you prioritise it and always have the time available to concentrate on this crucial activity.

## In Conclusion

When I joined my current company I took a step out of engineering leadership and moved in to a product management role. I was convinced that the route to success and career progression lay in moving beyond a technology remit. I was excited to step out of a day to day technical role and focus on the challenge of building a wider sphere of non-technical influence across the business.

In reality however, this was much less fulfilling than I expected and felt a lot more like middle-management business — I soon realised that I belonged back in the software engineering world and that was the place where I could best serve my colleagues and the wider business.

As luck would have it, the opportunity arose quite quickly to step back in to an engineering leadership role at an incredibly exciting time for the business as it embarked on a new transformation journey at the beginning of 2018.

Since that time I’ve been focused on building a new engineering team, hiring a large number of new engineers at different levels of experience, delivering the first phase of a major re-platforming project and setting out a clear and exciting strategic direction for the future.

I believe that the principles I’ve outlined above can really enable engineering leaders to focus on the effective leadership of highly skilled and high-performing teams that can deliver amazing solutions for the business they work within.

*Simon Young is Director of Software Engineering & Architecture at The LEGO Group, growing and leading the team that builds [LEGO.com](https://www.lego.com/).*

Hello, I'm
Simon Young.

Leadership with Shared Purpose

On Leading Engineering Teams

Hello, I'm Simon Young.

Leadership with Shared Purpose

On Leading Engineering Teams

Hello, I'm
Simon Young.