SOLID Principles of Engineering Management

All software engineers/developers should be familiar with SOLID principles and, I’d hope, an appreciation of the wider patterns from Robert C. Martin (a.k.a Uncle Bob) from his paper titled Design Principles and Design Patterns from 2000.

While the SOLID principles guide you toward good engineering practices I believe there are a similar set of principles which can be applied to engineering management. I feel this is especially true when trying to establish and scale high performing engineering/delivery teams.

TL;DR Version

The (or my!) SOLID Principles of engineering management are Sincere, Open, Lead by example, Invest in people, Do retros.

Longer Version with Added Context

SOLID Principles of Engineering Management

Sincere

Sincerity is about being true to your core beliefs and values. All organisations tend to have some form of core values or principles on which they are based. While these should be part of the DNA of the business and of daily interactions between employees quite often they can be just posters dotted around the premises with little meaning, which is sad. While useful as a basis for an organisation as a whole I have found it beneficial to have foundational engineering values or principles. Engineering values and principles help define ‘what good looks like’ for an engineering function.

I believe the following form the basis of good engineering principles and tend to have these as a basis for discussion at the very least.

• Transparency — Knowledge is power, but shared knowledge and transparency of information is even more powerful. This typically leads onto my next point.
• Documentation — Documenting everything so that you are kind to both current & future generations of engineers is a good thing. Tribal knowledge locked away in a small number of people’s head is not great for scaling, speed of innovation and can often be a huge bottleneck as teams grow. It’s also not good to have a bus factor of 1.
• Ownership —Autonomous teams and individuals who have freedom & responsibility to make decisions within their day to day work are often highly motivated.
• Trust — As an engineering manager there is an implicit level of trust and one should assume positive intent.
• Safety — It is important that all team members of all levels of experience can express ideas without fear of blame. I believe that ego-free risk taking enables innovation within individuals and teams.
• Team over individuals — I personally value 10x teams over (mythical) 10x engineers/individuals. The impact, success and speed is multiplied significantly when individuals can come together and be productive as a group rather than relying on individuals.
• Curiosity — Curiosity and a growth mindset is a key area I look for as a hiring manager. Curiosity can facilitate/accelerate learning and growth.
• Engineering/Technical Excellence — clean code, tests, code reviews, pairing and other day to day practical activities should form part of an engineer’s daily routine.
• Automation — Automating the s$$t out of everything wherever possible to ensure that repetition is carried out by machines in order to increase efficiency and achieve scale.

Open and Honest

Decision making can be hard. Technical decision making even harder when you are often faced with many alternative ways to solve the same problem each with differing positive and negatives. To promote open and honest communications I’ve promoted or made use of a number of approaches including chapter/guild meetings for discussion around specific topics (e.g. web performance), the use of RFCs, ADRs and tech reviews to document, discuss and agree approaches. Usually, the most successful teams move toward a Golden Path (or preferred/agreed) way of doing things based on shared/agreed principles.

Lead By Example

In my role, I optimise for people and my personal bias is toward building productive engineers and delivery teams of engineers. To achieve this, I often focus on speed and innovation and I consider it a failure on my part if I do not provide an environment for our technical talent to innovate (and learn) at scale very quickly in collaboration with the product and design teams. In order to optimise for people I focus on ensuring one-to-ones/1:1s happen with my reports and expect them to happen across the org.

I also try instil an expectation that there will be change and experimentation and encourage reducing faff (my favourite word BTW). Every team, individual and project I have worked on has been different. So, while I don’t know exactly what will work for any given context, I do believe that the only constant will be that there will be some form of change. Therefore, I try ensure that my own decision making process is guided by data and insight and that I am data informed. I expect this of others and of the business when it comes to product delivery.

Also, knowing when to shut up and speak up and the fine balance between coaching, mentoring and being directional in various situations is a skill I am still trying to master. It took me some time to realise that as technical leaders we are ‘on show’, as are all (formal) leaders. This means that behaviours you expect from your team should be exhibited by yourself.

Invest in People

In Daniel H. Pink’s book — DRiVE, he talks about the secret to high performance and motivation and work being deeply related to Autonomy, Mastery and Purpose. Essentially, satisfying the basic human need to direct our own lives, to learn and create new things, and to do better by ourselves and the wider world. In a business context this translates to working on something that has meaning, having an impact and continuous learning and self improvement. Ultimately this equates to ensuring all team members are able to understand and answer the following questions

• “What’s the company mission?”
• “What dent does this company allow me to make in the universe?”
• “What amazing people will I be working with and what opportunities will I be given to learn and grow?”
• “Do I feel in control or am I being controlled?
• Am I having fun?”

These questions should form the basis of regular 1:1’s as discussed above. Within my own career, I have used Objectives and Key Results (OKRs) as a framework to ensure we specify business/delivery, engineering (or skill) and personal (career) objectives. This framework, usually, allows you to directly address and answer the questions related to company mission and each individuals contribution toward it achieving them.

Do Retros

I fundamentally believe in continuous improvement and learning. I really think it is important to take time to reflect on all areas of software delivery. There have been many, many times I have seen retros being one of the ceremonies that get dropped within the software development cycle when deadlines approach or things get tight. However, I feel that reflection, taking a step back and looking at ways to optimise and improve are key to speed of delivery (and to reducing faff). I encourage reflection and retros on absolutely everything from sprint reviews, releases and the release process, hiring process and candidate experience, company meetings (all-hands, town halls), chapter meetings, basically everything!

From my experience, I often see that habits are acquired easily and routines are quickly established (part of creating a rhythm of business) but often, they can feel like they happen for the sake of it and may contain low energy of focus. This to me is waste/faff(that word again!). For example, if daily stand-ups are not adding value, participants are not engaged or team members do not realise the importance of a daily team huddle/re-focus, then hold a retro, and establish whether a small change could improve them. No habits, only value, usually determined through retros is one of my mottos.

That’s a Wrap 🌯

Thanks for reading and I’d love to have feedback so feel free to ping me.