I’ve been an engineering leader for many years. Despite the experience under my belt, and as any good technical professional will tell you, you are always learning – every day is a school day. There are a lot of books, podcasts, articles and frameworks about leadership. The following provide me with the insights that heavily shape my thoughts on engineering leadership.
You have to understand your landscape; therefore, you must map. Simon Wardley has created a complete approach that he calls his strategy cycle. It’s brilliant:
Purpose – Why? Do you know what you are doing?
Movement – Wardley Mapping will help you understand your landscape; it’s evolution and blockers to change (inertia).
Climatic patterns – these help describe factors that you may be observing. Internal or external.
Doctrine – this is a list of potential things you could/should do. Do you know how good your execution is?
Leadership – given all of the above, what are you going to do.
And once complete, go back to the start (it’s a cycle). Wardley Mapping is a critical component of this – start there (and the book is free).
This may be a surprise, but the Pixel story as told by Ed Catmull is an excellent example of engineering leadership. The idea of the ugly baby and the machine is compelling.
Catmull explains: “….when you think of how a movie starts out. It’s a baby. It’s like the fetus of a movie star; we all start out ugly. Every one of Pixar’s stories starts out that way. A new thing is hard to define; it’s not attractive, and it requires protection. When I was a researcher at DARPA, I had protection for what was ill-defined. Every new idea in any field needs protection. Pixar is set up to protect our director’s ugly baby. Of course you can’t protect the baby forever. At some point, it has to grow up and change into something, because the beast is still there. That’s a positive thing. Because sometimes the ugly baby would rather play in the sandbox forever.”.
Every engineering leadership organisation must be empathetic towards the customer. There are many ways to do this, but the approach laid out by Seth is straightforward and effective. Seth explains that: “Most leaders and project teams think this is simply the evolution of “IT”—leaving business management unchanged. This is not true. As this technology becomes embedded in literally every phase and process of our businesses, we need new organizational structures and management practices capable of leveraging these new capabilities.”.
His book: “describes the tools, techniques, and practices that managers need to thrive in this new world.”.
There are too many books and complicated approaches to write great software. Some of the techniques are so contrived that the engineering leadership forget entirely what they are doing. There are dozens of metrics that teams can track, but many end up in confusion. Accelerate is incredible as it reduces delivery down to 4 key metrics [explain]. It is the simplest thing when talking to a team to ask “how many times did you delivery last week?” That question will unravel everything you ever need to know about performance in 3 minutes. Or you could spend three weeks doing a Root Cause Analysis.
Architecture is the lost art. In many ways, Agile has killed it as it’s seen to be a phase early in the waterfall cycle. Gregor has done the best job at explaining how an Architect should work:
“The role of architects has fundamentally changed. While knowing UML and architecture styles was sufficient a few years ago, modern architects reduce friction, align technology and organization, and chart a credible transformation journey. All while keeping up with the latest tech without being blind sighted by buzzwords. These architects ride the Architect Elevator to connect the organization’s penthouse, where the business strategy is defined, with the engine room, where the enabling technologies are implemented.”.
And it’s not just Architects.
The team has always been the fundamental unit of delivery. Not organisations or individuals. How you organise teams and how they interact is crucial. There are four fundamental topologies:
Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned team
The enablement team is the most powerful concept here and widely misunderstood.
It goes without saying, but psych safety is critical to allow individuals and the engineering leadership to bring their whole selves to work. Prof. Edmondson of Harvard Business School explains that: “psychological safety is required for team high-performance. Psychological safety is defined as “a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes“.
Finally, there are many complex ways you can structure communication channels and knowledge management. Millions are spent on this by large companies. Often the most effective method is “unscripted collaboration”. Put people together, and they will talk. The power of community inside an org is very effective. Webber’s 5 step process is very insightful.