Wanted: a New Set of Engineering Leadership Skills

A while ago I did a series on how key roles in the engineering organisation changes as a result of introducing devops practices. I covered the software architect, the program manager (at that time I was at Cisco and some of the projects were huge), and the product owner, but left out the engineering manager and the product manager as other priorities called. In this post, I circle back to the key skills necessary for engineering leadership, independent of the role you have.

What makes good leadership is sometimes seen as magic. It is difficult to get it right. On the other hand, engineering leadership can sometimes seem like black magic! You typically don’t have the sales or the financial aspects, but you are supposed to lead people who are rumoured to be motivated by weird things regular people don’t even know what is, and technology development is so fast that it seems that last week’s new stuff is now old. And in software development, you are supposed to deliver a product that at best seems fuzzy, at a pre-defined time, and with a limited number of engineers where your most productive individual can deliver 10, 20, or even 30 times of the least productive individual.

One challenge is that you can bend pretty much everything: what is shipped, the quality of the features that are shipped, the quality of the code, and the technical debt you leave for later by cutting corners.  And in addition you are supposed to be innovative and solve the customer’s problems in a “delightful” way. A good engineering leader understands the customers, the business, as well as how to solve the customers’ problem. Getting all this right is very challenging and why I love building things in code!

I did a quick review of various engineering leadership programs and found MIT’s Engineering Leadership Program to be one of the most explicit on what they believe engineering leadership is. They emphasise six core capabilities where five of them are common with general leadership: core personal values and character, relating to others, making sense of context, visioning, delivering on the vision, and technical knowledge and reasoning.

We now know that a key characteristic of high-performing teams is trust among its members, and humans are more capable of trusting others when they feel safe. Any change introduces uncertainty, which again can reduce the feeling of being safe. In an environment of developers used to code and solve problems in front of their screen, the introduction of devops can be a dramatic change. We know from the introduction of agile that tension can raise quickly. Devops is an even more dramatic change in how developers work. Thus, anything that can be done to increase the feeling of being safe is critical! Simon Sinek has done a lot of work on trust leadership and this quick introduction to his thoughts on creating a circle of safety is a good use of your time.

An interesting difference between Europe and the US is how management education in the US is seen as something separate from the professional degree (MBA or engineering leadership programs). In Europe, leadership is embedded in professional degree programs, and it is more often assumed that a manager has a professional education and then promoted based on merit to leadership positions. There are pros and cons with each model. In Europe, it is often a problem that the only career path is management and the best people in their area become managers. You risk loosing a great specialist and get a lousy manager. However, if the transition works out, you get a very efficient manager who knows what is important and can guide others in doing their best. Regardless of model, it is important to promote people to leadership positions who have a real passion for accomplishing great things through other people, not only doing things themselves!

Devops is an approach to software development that is only possible if your product is a service that you operate and control, typically from a public or private cloud. This is called Software as a Service (aka SaaS). One of the key characteristics of devops is that the team writing the code is also responsible for operating the service. This allows modification of code as an immediate response to issues, requests, improvement needs, learnings, and feature requests. Jonathan Rosenberg, CTO of Cisco Collaboration, wrote a very good post explaining what this really means.

However, what are the requirements of a good engineering leader when you develop Software as a Service? Let’s look at some of the relevant things that change with devops:

• Classic project management becomes difficult as there is no project, just many small chunks of work being done in parallel
• Realising customer needs and desired business outcomes become a more direct deliverable as the whole product development process is condensed into the devops process
• The team’s responsibilities get much bigger, and the type of people and number of roles expands where QA, operations, security, and other functions need to be taken care of by an integrated team
• It may make sense to organise product management, product marketing management, technical marketing engineers, as well as support into the same group
• The architecture of what you build typically shift from one integrated piece of code into many smaller, loosely coupled components (called micro-services). This has an impact on how the teams are organised and how they work
• The continuous deployment pipeline and your test infrastructure become critical assets
• Reliability and uptime become important in areas where you earlier could be lax (like your build server)
• The team becomes responsible for delivering on key business metrics

This list is by no means exhaustive, but offers a flavour of the type of changes a team experiences when introducing devops. There is one immediate thing that is obvious: the scope of the engineering leader’s work has grown tremendously, both in topic areas and type of people and deliverables. This calls for a very different type of engineering manager than the classic “first among peers” approach where the most senior developer also gets a manager responsibility. 

In the new devops-centric engineering organisations, HR and senior leaders need a much more systematic approach to educating its engineering leaders and train, coach, and mentor people to reach a broad set of leadership skills, and who also thrive on the challenges of leading software organisations.