The Four Pillars of Engineering Management

Matthew Bill
9 min readJan 2, 2024

--

Becoming a first-time Engineering Manager (EM) can be an exciting and challenging experience. With so many aspects to consider, from managing teams to ensuring the quality of software deliverables, it can be hard to know where to start. However, breaking this complex problem down into smaller, more manageable chunks can help. The four pillars of engineering management — People, Technology, Processes, and Product — provide a framework for approaching this task. Expanding these four pillars will also enable new managers to understand what is involved with the job.

Each pillar focuses on a different aspect of the role, and by considering each one in turn, managers can gain a comprehensive understanding of what they need to do to be successful and the kinds of activities they may have to perform.

By focusing on technology, managers can ensure that they have the right tools and resources to build great software. By focusing on people, they can build and lead effective teams that are motivated and engaged. By focusing on processes, they can streamline their work and make sure that projects are completed on time and budget. By focusing on the product, they can ensure that the software they build meets the needs of their users and provides real value.

As Engineering Managers, you are no longer a specialist focussing on one area in depth but become polymaths having to learn about all different types of skills. Therefore openness, adaptability, and drive are always going to be great qualities to have.

New Engineering Managers

I hope that publishing a brief overview of the method I use (which is heavily borrowed from various sources), will allow other people considering this path to have a better understanding of whether it is right for them and empower them to have an idea of what they should dedicate their time to once they start the role. It should also be useful for people hiring new technology leaders and how they can develop their hiring pipelines to ensure they get the best candidates.

There is a big difference between being a tech lead and an engineering manager and the ironic thing is, where people think going into management will give them more control over the technical detail, you will often have less. Engineers are creative people and we love having ownership over what we build, and as an EM one of your roles is to create that environment for them.

Individual Contributor vs Manager

Many people move into EM roles without a real understanding of what it entails or the proper support to be successful. People can also tend to want to move into these roles as they feel it is the only way to progress and then are surprised when many things they didn’t know were part of the role. The good news, however, is that within the modern tech industry, both management and individual contributors (IC) are often seen as just different paths and therefore you can follow what you are passionate about. For these reasons, I think it is important to:

  1. Not view engineering management as a promotion, but as a career path that runs in parallel with individual contributors.
  2. Give new internal EMs a grace period of around 3 months to if it is right for them and go back to becoming an IC without any shame attached to it.

A position such as Engineering Manager will also mean different things to different organisations and the amount of focus given to each of the pillars will depend upon this and the supporting roles already within the organisation. For example, an organisation that has dedicated agile delivery leads (ADLs) will require less of your time dedicated to the process. Likewise, organisations that have architects will likely mean you spend less time on technical oversight. Where you spend your time will also depend on how mature the company is and also its size, as within smaller companies you will probably have to get involved in a wider range of activities.

👤 People

Example Activities: 1:1s, Performance Management, Recruitment, Growth Framework, Organisational Structure, Goals, Onboarding, Culture, Learning & Development, Employment Law, etc.

The first pillar of software engineering management is people. This is to recognise the primary focus of EMs is people first and technology second; whereas for ICs, it is technology first and people second.

People are the driving force behind software engineering projects, and managers must understand how to recruit, onboard, and grow existing team members to successfully scale the organisation.

They will also need to understand the strengths and weaknesses of their team members to allocate goals effectively and provide the necessary support and resources. Managers must also create a positive and supportive work environment, where team members feel valued and are motivated to perform at their best.

As well as this, you will also need to understand how those people work best together to build teams and organisational structures. This can be one of the hardest pillars for new leaders to learn as it often requires focusing more on empathy rather than logic which was so prevalent as an IC.

🖥️ Technology

Example Activities: Technology Radar, Solution Design, CI/CD, Technical Debt, Coding Guidelines, Branching Strategies, Peer Reviews, Shared Code, Observability, etc.

The second pillar is technology. Technology is the foundation upon which software is built, and engineering managers must have a deep understanding of the technology they are working with to ensure good decisions are made about architecture, design, and development.

There is often a debate about whether a technology leader has to be technical or not and arguably one of my best managers has not been technical at all, but enabled and promoted me in my career whilst staying clear of any technical discussion. He was, however, a people manager working within the technology department of a large company, rather than what might be called an EM.

As an EM, you need to have the maturity to accept that you are probably not going to be the smartest person in the room. You also need to understand that although you may know something better than someone first starting in their career, they are closer to the problem than you and you need to give them space to take ownership. You may not be the person to make the decision such as the exact coding standards, but you need to ensure the decision is made.

⚙️ Processes

Example Activities: SDLC, Team Events, Agile Delivery, Release Planning, Post-mortems, Maturity Frameworks, Capacity Planning, Inter-team Collaboration, etc.

The third pillar of software engineering management is processes. Processes are the methods and procedures that are used to manage software engineering projects, and they are essential for ensuring that projects are completed on time, within budget, and to the required quality standards. Managers must have a deep understanding of the processes used in software engineering, such as Agile, Scrum, and Kanban, and they must be able to make informed decisions about which processes are best suited to their projects.

Another area you may find yourself responsible for within the processes column is finance. This includes creating a budget for the year of what you wish to spend money on and then tracking against that throughout the year. Aspects such as salaries, licenses for tools, and cloud costs will all have to be taken into account. Having an understanding of basic finance, such as tax, cash flow, and depreciation will be of great advantage here. Learning more in this area will also have fantastic benefits in your personal life as well, such as how to better invest your own money.

🚀 Product

Example Activities: Product Roadmap, Project Kickoff, Success Metrics, Project Steering Group, Prioritisation, Competitor Analysis, Story Templates, etc.

The fourth pillar, but the most important pillar of technology leadership is Product. Product is the end goal of software engineering projects, and managers must have a clear understanding of what their stakeholders expect from the final product. They must also be able to make informed decisions about the features and functionality that should be included, and they must be able to communicate these decisions to their teams effectively.

At the end of the day, we can create some of the best code technically, but unless that is of value to someone, then it can all be for nothing (but perhaps the learning experience). It should clearly be stated what the goals of a product or feature are and work out a way to track against it. That way you can create more autonomous teams that re-focus on the end goal if they get distracted by focusing their energy on the tools themselves rather than the outcome. This nicely leads us on to… metrics.

📊 Metrics

In addition to the four pillars of software engineering management, it is important to have a foundation of metrics to effectively measure the success of products and teams. Metrics provide a way to quantify and track progress, identify areas for improvement, and make data-driven decisions.

Metrics can be generally broken down into those that understand how good our product is and how well the engineering machine at the organisation is running. Once again, it doesn’t matter how good we are at following a process or how technically excellent we are if we end up building something that isn’t any good. A well-oiled machine and the right direction are the perfect combination for success.

Technology metrics can include measures such as code quality, unit test coverage, and security vulnerabilities. These metrics can help managers understand the technical quality and maintainability of their solutions.

People metrics can include measures such as employee satisfaction, retention, and productivity. These metrics can help managers understand the well-being and engagement of their teams, and make informed decisions about how to support and motivate them.

Process metrics can include measures such as sprint completion rate (reliability), cycle time, defect ratio, and deployment frequency. These metrics can help managers understand the efficiency and effectiveness of their processes, and understand how to remove bottlenecks and dependencies.

Product metrics can include measures such as NPS, adoption rate, speed to complete tasks, and revenue. Success metrics will tell you how good the product is or the impact that work is having on it and tracking metrics enable you to drill into the detail when you need to. Interestingly enough, these can be the hardest to convince organisations to start measuring as they are often the hardest to measure and generally, we have a tendency to automatically assume our ideas will work.

For those wanting to learn more about metrics and how you might use them as an EM, there are a few very good places to start:

  1. Evidenced-Based Management: A framework for how to use metrics, along with a great list of possible ones at the end of the guide.
  2. DORA Metrics: Four key metrics (with a recent fifth) that measure high-performing teams, such as deployment frequency. You can also read the Accelerate book to find out more about the metrics that are always on the list I want to track.
  3. The Lean Startup: To understand the importance of success and tracking metrics for products.

Summary

In short, the four pillars of software engineering management provide a roadmap for software engineering managers. By considering each pillar and the activities that make it up, they can build the foundation for a successful and sustainable software engineering practice.

Software Engineering Management is a complex field that requires a comprehensive understanding of various aspects, such as technology, people, processes, and product. These four pillars are crucial for the success of software engineering projects, and managers need to have a good understanding of each of them to make informed decisions and drive positive outcomes.

Of course, different people will have a leaning towards some over others, so one of the first steps is to identify where your strengths are and where you can learn a few new things. Sometimes a problem will require a tech solution and other times a people solution would be best. Having a selection of tools on your belt across the four pillars will help you apply the right tool for the job.

Please share with all your friends on social media and hit that clap button below to spread the word. Leave a response of resources you find useful for systems design. 👏👏👏

If you liked this post, then please follow me and check out some of my other articles.

About

Matthew Bill is a passionate technology leader and agile enthusiast from the UK. He enjoys disrupting the status quo to bring about transformational change and technical excellence. With a strong technical background in Polyglot Software Engineering, he solves complex problems by using innovative solutions and excels in implementing strong DevOps cultures.

He is an active member of the tech community, writing articles, presenting talks and contributing to open source. If you would like him to speak at one of your conferences or write a piece for your publication, then please get in touch.

Find out more about Matthew and his projects at www.matthewbill.com.

Thanks for reading!

--

--

Matthew Bill
Matthew Bill

Written by Matthew Bill

Technology Leader | Agile Coach | Polyglot Software Engineer | Solution Architect | DevOps Enthusiast | Speaker & Writer | matthewbill.com

No responses yet