What is an Engineering Manager?

Introducing Engineering Managers

Engineering management is a discipline and role that has been growing in maturity over recent years, now almost all but the smallest tech teams will have an Engineering Manager there to manage and grow engineers. 

A typical Engineering Manager will have a technical background and be actively looking to move into people management, they’ll mostly concern themselves with hiring and growing engineers but may, or may not also be writing code, introducing ways of working, conducting code reviews, leading on architecture, ensuring delivery, setting the strategy and pretty much everything in between. 

 

Styles of Engineering Manager

To help with job hunting and meeting role expectations I think about the variety of Engineering Management elements as being grouped into four distinct styles based on time and energy spent on each of the primary responsibilities – Code (writing, and reviewing), Architecture (designing and setting technical direction), People (hiring, managing, growing), Team health (ways of working, productivity, happiness), and Product strategy (what to build and when). 

The Tech Lead Manager

Engineering Managers who play the Tech Lead Manager role will line-manage people as well as lead on technical decisions. They’ll be hands-on with code and code reviews and usually work with a single team to deliver on team goals. 

The Tech Lead Manager is often the most senior engineer on the team and will work alongside someone setting the product direction (possibly a Product Manager) and possibly an agile coach to guide team health. Companies with a Tech Lead Manager style of Engineering Management will usually have an architect designing the system architecture and ensuring all teams meet architectural guidelines. 

The ideal candidate for this role will have deep technical knowledge usually in the language or technology that the team is using as well as being a proficient people manager. 

The Tech Lead Manager will spend most of their time and energy on code followed by people. TechLeadMgr

The Architectural Lead Manager

Distinguished from The Tech Lead Manager by not being hands-on writing code. The Architectural Lead Manager will still set technical direction and be involved in code reviews as well as managing people. Compared to the Tech Lead Manager, the Architectural Lead Manager can more easily work across teams without causing too many bottlenecks since they’re not expected to be contributing code (although they often will write non-critical path code). 

This Engineering Manager will work alongside someone setting the product direction, and possibly an agile coach to guide team health. There may still be an Architect involved with team direction but they’re likely to be less hands-on and work in an advisory role with the Engineering Manager leading on most technical direction decisions. 

The ideal candidate for this role will be a people manager with technical skills but they may have a different technical background to the team. Job requirements are more likely to focus on technical strategy skills over technical execution. 

The Architectural Lead Manager will mainly focus on technical strategy and people.

ArchitecturalLeadMgr

The People Manager

The People Manager Engineering Manager will primarily be responsible for managing the engineers on the team. As a dedicated People Manager this Engineering Manager is more likely to manage people with different skill sets to their own, they can more easily work across teams, and with a single focus, they have the ability to create a superior environment for coaching and people development. 

This Engineering Manager will work closely with people who are responsible for the team’s delivery and direction as well as technical decisions. In some cases, this could mean the Engineering Manager works closely with a Product Manager, Tech Lead, and Agile Coach as well as an Architect. 

People Managers may come from different backgrounds although must still be technical enough to gain respect from the team. Coaching skills are likely to be more valuable than coding skills. 

Almost all of a People Manager’s time and energy will be on the individuals in the team.

PeopleMgr

The Team Lead Manager

The Team Lead Engineering Manager is responsible for managing everything to do with the team. They’ll usually line-manage the engineers in the team as well as being responsible for the direction and delivery of the product/project.  

The Team Lead Manager will usually manage engineers who are at least as senior as they are, and often more senior as they focus on the team’s health and direction over specific technical decisions. Additional roles such as Agile Coaches, Architects, and sometimes even Product Managers are less likely to be found on teams with this style of Engineering Manager.  

Technical leadership and project management abilities are likely to be more valued than a specific language or technology. 

The Team Lead Manager has a more even spread of focus on the team’s direction, health, and individuals.

TeamLeadMgr

Engineering Management Expectations

Confusingly these four styles of engineering management and numerous variants of the four are all referred to as Engineering Management despite being very different roles. Succeeding as an Engineering Manager requires you to work out exactly which version you’re expected to be and then to focus your time and skills on the relevant parts. If you’re expected to be an Architectural Lead Manager but you’re spending all of your time focusing on engineer happiness and no time on the technical roadmap then you’re unlikely to succeed. Likewise, if you’re meant to be a People Manager but you’re constantly getting involved in code reviews and maybe even trying to write code then you’re probably missing expectations as well as stepping on other people’s toes. 

Working out the style of Engineering Manager

The easiest way to work out which style of Engineering Manager you’re expected to be is to find out which other support roles exist in the team. If you’re joining a team that also has a Tech Lead and a Product Manager and an Agile Coach then you’re likely to be a People Manager or an Architectural Lead. But if you find there’s no Tech Lead then understanding if you’re expected to contribute code or not might help determine if this is a Tech Lead Manager role or not. 

For people already in the role, or for identifying the style of other Engineering Managers consider how you prioritise your time. Are you more likely to miss a team retrospective or a technical roadmap session? Do you prioritise one-two-one meetings over all else or are you finding a way to squeeze them in besides writing code? 

The style is just the starting point

A great Engineering Manager builds and grows a team to be achieving to the best of their ability. As the line-manager it’s up to you to create opportunities and support people in order for them to achieve their goals, it’s also up to you to create the environment to allow the team to succeed.

If you’re working as an Architectural Lead but have a great engineer who wants to get involved in technical road mapping then make it happen. Flex in and out of your responsibilities to better support your team or create space for others as needed. Maybe a critical project needs more of your hands-on time to make it succeed, or perhaps you want to give someone more responsibility to help them grow. Sometimes people will leave and you’ll need to pick up some slack, or you’ll end up overly busy and need to drop things. Use the style of your Engineering Manager role to determine your core responsibilities and make sure you’re always hitting them, everything else can be scaled up and down as needed. 

Holding the pen is a power move

How often have you gathered a work group around a whiteboard only to be surprised by how little people seem to want to contribute? All the ideas that have been raised individually or added to documents or Slack threads suddenly missing from the discussion. 

It can feel frustrating, like you’re the only person who cares about the problem. Often this results in you, or someone else going off alone to work out a solution by themselves, because if no one else cares then you might as well be the one to sort this out. Right?

Well, in many of these cases the problem is a simple one. Simply, you didn’t give them the pen. 

The person holding the pen in a whiteboarding session is the person in control. Standing beside the board holding a pen with the rest of the group sitting facing you is a power dynamic. You’ve placed yourself in the teacher role and no matter how much they like it the others are here as your audience. 

When you hold the pen you get to be the one to represent the problem to the group. You get to draw out the options and you get to manage the pace of the discussion. 

For someone who wants to demonstrate authority this can be a really simple way to do so. If you find yourself in a room with a group of senior people and you want to demonstrate that you know what you’re talking about try picking up a pen and drawing the problem out. 

But If you want other people to take a more active role in a discussion simply hand them the pen. 

The Best System Architecture

Your system architecture says many things about you; often it says you didn’t design it, or that you decided to follow the crowd, in the best cases it says you know what your needs are and have designed accordingly. There are many opinions about what good architecture looks like and depending on your situation there is likely to be an architecture that better suits your needs. When designing from scratch you have the freedom to design the best possible architecture.

Brownfield applications are a little different. Any system that has withstood more than a few years of operation should be celebrated; it has demonstrated its ability to do what it needed to do. Unfortunately, a system that’s been running for several years probably also shows its age and probably doesn’t look exactly as it would if you were to design it today. Some of the decisions might have been bad ones, but mostly they’ll have been the right decision at the time and need re-visiting to bring them up to date. 

So how do you re-architect a system? My preferred way is to do it gradually. 

As tempting as it is to stop working on features in order to rebuild part of a system, or even to build an entirely new system to replace the one that went wrong, this probably isn’t the best decision. Stopping ‘normal’ work to focus on rebuilding can help kickstart a tech-debt paydown project but it misses the opportunity to teach teams how to make incremental improvements alongside their regular work. Without these skills or discipline the ‘new’ system is likely to end up in the same poorly architected state within a few years. 

By gradually reviewing and replacing or removing parts of an old system you can turn a poorly architected system into something that exactly meets you needs. Focusing on the areas that cause the most pain, or are most frequently changed is a great way to start. By gradually removing dependencies, or bringing in new tools or technologies the system will start to improve. For many teams the best end state isn’t a complete re-design for 100% of the system but a more pragmatic approach to deal with the greatest pain points and isolate the infrequently changed areas.

But the work doesn’t stop here, system architecture is a constantly evolving being. Every day that you add or remove code you’re changing your architecture. When you decide to add or remove a dependency you’re changing your architecture. Even the decision not to change something is a decision on how your system architecture should be. 

Many teams look to successful companies to decide on the right architecture for them. This may work but it ignores the unique team and problem that you have. Knowing what you value, and knowing where you need to be are essential for designing a great architecture. If you value team autonomy then make sure the system architecture supports this. If you value throughput, or robustness, or ease of learning then take the time to understand exactly how your architecture will support this. Create shared values for the end state to remove the need for day to day decision approval and instead allow everyone to focus their efforts on analysis, education, and progress. 

When building new features teams should be working to move the architecture forwards at the same time as meeting their delivery goals. Sometimes that means a small change to a message, sometimes it means building a whole new microservice. Making this work means that every team needs to know exactly what their current architecture looks like, and also needs an opinion on what a better design would be. Regularly gathering around a whiteboard to discuss system design helps normalise design discussions and builds awareness of the pros and cons of every decision. 

Make time to build the architecture forwards by building awareness of the current situation and its impact. Help everyone to understand what needs to change and why. When estimating work factor in the time and cost of building it the right way, the way that allows you to get the feature you want AND the architecture you want.

A system that is under active development will never have a textbook perfect architecture for long because it isn’t a static being. Systems needs to evolve to support new decisions and ideas. So whether you have a monolith or services, microservices or mono-repos, the only thing that really determines how good your architecture is is whether you know it well enough to work with it. 

Reflections from 2019

2019, it’s the end of the year, and the end of the decade. This time 10 years ago I had just been made redundant, it ended up being perfect timing and the decade that followed was amazing and challenging. I’ve been lucky enough to work with teams full of smart and friendly folk and through the fantastic LondonCD Meetup and Pipeline Conferences discovered Continuous Delivery which ended up leading me into Engineering Management. 

Along the way I’ve spoken at conferences and meetups, contributed to a book, co-led Weekend Testing Europe, appeared on some podcasts, and launched Humans + Tech. Whoo. 

Not everything has gone exactly to plan and I leave this decade with greater patience and tolerance. Yes, really. I know that every situation teaches you something and for me at least, I need to look for that opportunity and focus on it. Moving into Engineering Management has given me great opportunities to learn about things that I had never even thought about. From coaching people to Kubernetes, and with an awful lot of AWS too, I’m loving the random things I get to learn day to day through work. 

I love to read and this decade has been accompanied by some of my favourite books. I’ve loved Radical Candor, The Unicorn Project, Deep Work, Resilient Management, Powerful, and The Coaching Habit as well as many, many others. I could read all day, every day but in the past few years I’ve started to realise that filling my mind with endless ideas doesn’t necessarily translate into successful execution. Reading a little less and working to apply the best ideas either to myself, my writing, or my teams is a better approach and one that I’ll be continuing to work on in 2020. 

In the next decade I’m going to be more intentional. I’m not very good at being bored and often end up agreeing to things without really thinking about what I want to do. In 2020, and hopefully in the years that follow, I’ll be choosing just a few things to really focus my attention on. The results may feel slower, and I might actually need to learn to accept boredom, but the end result should be far more satisfying. In 2020, my (out of work) focus will be on Humans + Tech, my book, and working out how to pull the millions of threads of ideas into a coherent story or tool that actually makes sense. 

Huge thanks to everyone I’ve had the pleasure of working with, getting to know, drinking coffee with, or sharing ideas with over the internet. Happy New Year!

Book Review – The Unicorn Project by Gene Kim

It’s been nearly seven years since The Phoenix Project made The Three Ways a regular topic of Tech conversation. These days most tech companies are at least aware of, and hopefully embracing Systems Thinking, fast feedback loops, and learning cultures to deliver value to the customers. 

In his new book The Unicorn Project, Gene Kim revisits the fictional company “Parts Unlimited” to explain the five ideals of Locality and Simplicity; Focus, Flow and Joy; Improvement of Daily Work; Psychological Safety; and Customer Focus. For anyone looking for, or undergoing a digital transformation these five ideals will be very familiar. Just like with The Phoenix Project, The Unicorn Project excels not from introducing radical ideas but in helping to highlight a path through the chaos. 

The Unicorn Project is set at the same time as The Phoenix Project and follows Maxine and a “Rebellion” team as they battle to break team dependencies, and operational silos to allow teams to deliver customer value, fast. For many people working in tech the description of discovering valuable customer features hidden in Jira backlogs and having to raise tickets with multiple different teams to access code, environments, and even to release will be painfully familiar. I loved seeing enjoyment and job satisfaction getting so much focus, Kim did a great job of capturing the levels of frustration that poor build and deployment setups can bring.  

Following a fictional team in a fictional company gives great creative licence and allows many of the most painfully secret Tech practices to be included and resolved. Not everyone will love the fable style of storytelling but I think it’s a powerful way to share the darker side of many tech teams; we see the power struggles that can play out, and the resistance to change surfaced. In one section the “Rebellion” team accidentally cause a Production Incident as they work to build an independent release pipeline. These are the realities of many tech teams but are rarely covered in real experience reports.

On the flip side the fictional storytelling does lead to some fairly incredible situations. Firstly the timeframes, whilst I know that developers only needing days, or sometimes hours to solve the trickiest of problems is useful to keep the story moving, it is incredibly unlikely that any company would manage to solve so many issues with this level of ease. Secondly Parts Unlimited seems to have somehow hired, and retained, a huge number of talented people, all of whom have been sitting waiting for this opportunity to come along. Again I know this helps keep things moving along nicely but anyone going through even a fraction of these issues needs to prepare themselves for at least a few months of code and platform wrangling. 

Despite this the story is engaging and does a great job of following the team as they fix things, step by step. In the real world dependencies, data needs, security, and more can end up becoming so entangled that it’s difficult to see a way out. In The Unicorn Project we get to see the whole messy, uncertain path to fixing things. It shows that things do go wrong, people lose trust, and maybe you make the wrong decisions along the way. Despite this by working together, and having a really clear end goal you can make a huge impact on your job, and on the company.

In conclusion I’d say that The Unicorn Project does a fantastic job of covering many of the current tech challenges. Anyone working in tech should read this book and either celebrate that they don’t have to work in an environment like this, or be encouraged, and inspired, to see how much different an individual can have. Now go and find your own Rebellion.

Full disclosure: I received a pre-release copy of The Unicorn Project in exchange for a review. All views are my own. 

Great development is about more than code

Most developers start out focusing solely on learning how to write code; usually a specific language and specific techniques. I started out with BASIC; spending many hours tinkering with games and graphics. I loved creating things just to see if I could create them not because there was any need to do so. 

Later I used the same approach to learn the syntax and capabilities of Java. It was easier this time, many of the skills I’d learned from BASIC were applicable despite the language differences. As my knowledge increased I created more sophisticated, and complicated solutions. I felt like I was becoming a better developer and I was, but I still wasn’t what you would call a good developer.

It took many years for me to really appreciate the importance of fully understanding a problem before even thinking about the solution. Spending time, often way more than you feel comfortable spending, thinking about the problem before writing a single line of code is hard. It feels counter-intuitive to see a problem and not immediately start trying to solve it. Experience taught me that good code design does not come from writing code.

Believing that complicated code is better code is a mistake, and one commonly made. Good code is the right code for the problem. It’s the right code for the team (language, tools, level of documentation), and it’s the right code for the problem (testability, maintainability, extendability). Often that means that the best code for the job is the most boring, simplest code. The kind of code that anyone in the team can pick up and work with.

Great developers are those that can see a business problem, collaborate with others, and design the simplest solution to get things done. They’re able to balance their time to support others, investigate ideas, as well as writing code. Being proficient in the language is a big part of their success, but it isn’t the only part. Anyone wanting to increase their development skills needs to look past simply writing code and start learning how to design great (simple) solutions.

How to stop being so busy

Busy people are not successful people.

We mistake being busy with being productive. We get hit after hit of dopamine, the so-called “Happy Hormone” as we check off items on the to-do list, or smash out emails, all the while boasting on Twitter that we are “Just so busy”. It feels good, and it can become addictive.

Many companies reinforce our behavior by creating a heavy meeting culture or constantly hitting employees with short-term deadlines that they have to scramble to meet. Of course there are times in life when we really do need to be busy; the day before a deadline, or when we’re planning a big event we might need us to push our sleeves and get things done.

The problem comes when we get stuck in the “busy mode” either through our own choice or because of someone else’s. Over time we lose the ability to even see that we’re permanently reactive with little ability to control our own workload or direction. For many of us, going home tired at the end of the day makes us feel satisfied. We equate tiredness to productivity, and come to think that we should always feel this tired as proof that we’re doing our job.

But being busy is a choice.

When we spend all our time being reactive and busy we lose sight of the long term. Even with the best intentions, you won’t find time to be strategic if you’re always fighting against the tide of being busy. Not being strategic means we’re not planning our choices and miss the chance to prevent reactive situations from occurring.

Maybe as managers we’re too busy to see or deal with someone who’s unhappy in their role. When they quit we’re forced into a reactive situation. As an engineer we can get stuck shoring up a crumbling architecture, desperately fixing bugs to keep things working. But at the same time we’re missing the chance to stop and design a system that scales, or is secure, and maintainable. Anyone seeking a promotion needs to find time to stop, look around, and work out what the strategic work really looks like. Otherwise you’ll be stuck where you are, all the time wondering why your manager isn’t rewarding you for fixing 5 million bugs or running 200 meetings.

When we get stuck in the permanent busy mode we need to work twice as hard just to stay where we are. All the while we miss the opportunity to make the right choices to help ourselves or our teams move forwards.

Strategic thinking is the only way to progress.

To create time for strategic thinking we need to do less stuff; either we need to delegate things or we need to reject things.

An Eisenhower Decision Matrix can be a great way to separate tasks into the Important, and the Urgent. Anything urgent but not important can be delegated, anything not urgent and not important can be rejected.

Everything else is either done now or scheduled in. Make sure you include self-care in this group. Self-care is often de-prioritised by busy people but neglecting yourself severely hinders your ability to stay healthy and sharp.

The Eisenhower Decision Matrix can be a great way to see when too firmly stuck in Tactical or Strategic mode. If all your tasks sit in one part of the matrix then you can clearly see that you place too much emphasis on tasks of this type.

EissenhowerMatrix

For anyone in a senior or leadership position having tasks in your Urgent, Not Important quadrant is a strong indicator that you’re not delegating enough. When you fail to delegate you fail to give other people opportunities. Correct this as soon as you can.

Once you’ve decided what you’re going to work on, and more importantly, what you’re not, you need to tell people. Make your priorities or calendar visible to the people around you and fiercely defend it so they know you’re serious. If they disagree with your priorities ask them to help you decide what gets de-prioritised to make space for their task. Be clear about the trade-offs.

If you have strategic work time scheduled in make sure you protect it at all costs. Lara Hogan has some brilliant advice on how to set up your calendar to be most effective for you. When you know the times of day that you’re most effective you can use them for the most important tasks. It seems obvious but many of us try to squeeze in important work when we have the time rather than carving out time for it. It should go without saying that important work is important. Give it the respect it deserves.

Finally, learn to say no. It doesn’t need to difficult, simply thank someone for thinking of you and politely decline.  You can’t do everything and you won’t be able to meet everyone’s expectations but that’s ok. Take control of your life and spend your time in a way that gets you to your goals.