December 10, 2018
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.
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.
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?
Nowhere is Conway’s 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.
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.
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.
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.
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.
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:
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.
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.