Amy Leadership, Management, Teams

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. 

Amy Management

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!

Amy Engineering Principles, Management

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.

Amy Decision making, Leadership, Management, Productivity

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.

Amy Engineering Principles, Leadership, Management

2018 in Books

Books_of_2018_-_Google_DocsSometimes we read the book we need to solve the problem at hand. Other times we read a book and only afterwards see the situations that it has taught us to see.

2018 was a little lighter on reading than I would have liked but I did discover, and rediscover some gems.

First up was a reread of The Phoenix Project: A Novel about IT, Devops, and Helping Your Business Win. Five years on from its first publication and it’s starting to feel a little dated but still an excellent book with relevant lessons. Focusing on flow, and making work visible were key takeaways for me this time around.

Next up I read, and loved, Powerful by Patty McCord. Patty writes about recruiting, motivating, and creating great teams based on her experience developing the culture at Netflix.

“What takes the place of rules, processes, approvals, bureaucracy, and permissions?” The answer: Clear, continuous communication about the context of the work to be done. Telling people, “Here’s exactly where we are, and here’s what we’re trying to accomplish.”

And

“You want to be a lifelong learner; you want to always be acquiring new skills and having new experiences, and that doesn’t have to be at the same company. The fact is that sometimes you’re hired by a company to do something, and then you do it and it’s done. If I hire people to rebuild my garage, when they’re done I don’t need them to rebuild the back of my house.”

The most practical book I read in 2018 was Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim. This is a book crammed full of tips for helping teams achieve success, I particularly appreciated the focus on burnout that threaded its way throughout the book. Important reading.

Radical Candor by Kim Scott was my book of the year. “Radical candor is the sweet spot between managers who are obnoxiously aggressive on one side and ruinously empathetic on the other. It’s about providing guidance, which involves a mix of praise as well as criticism—delivered to produce better results and help employees achieve”. There are many, many great stories and transferable tips shared in this book. A joy to read, and a book that has changed the way I manage and want to be managed.

I ended up highlighting most of the book but this quote neatly sums up how it made me feel

“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”

My final book of the year was Switch by Chip Heath and  Dan Heath. Years ago I struggled through Thinking Fast, Thinking Slow, enjoying the message but finding it hard to recall accurately. Switch does a great job of sharing the same message in a far more accessible format. I absolutely loved the Elephant and the Rider metaphor to describe our minds, and I found the stories in the book to be interesting and highly motivating. I can’t wait to put these ideas into practice in 2019.

How was your 2018? Did you discover any books worth shouting about?

Amy Management

Default to Good

Our behaviour is shaped by many things; our experiences, our values, the environment around us. At work we have to make decisions about things we may not fully understand. We have to explain our decisions, and convince others to join us even when we’re not sure of the way.

Sometimes things are easier, maybe you work for an ethical company that’s clearly doing things to make the world a better place. Working somewhere like this, I imagine, would easily lead to good choices.

For the rest of us things are more blurry. You might work for a fantastic company for the wrong reason. You might work for a friendly company that don’t make the world a better place. You might work for a downright bad company for very good reasons.

As you go about your job, and life, you have to make decisions. If you’re a manger some of those decisions will be about how other people should live and work. You oversee goals, objectives, promotions, and pay rises. You might make decisions about hiring or letting people go, re-locating teams or ending projects, These things can be hard. The right decision might not always feel good, maybe people are being made redundant, or you’re forced to u-turn on a hiring decision. Generally decisions like this come after a long, well-considered period of evaluating the options. There are laws and guidelines to make sure we do the right things in these circumstances even if they still feel nasty.

But not all decisions are so big.

As we go through our day-to-day life we make decisions about all kinds of things. Many of these decisions are made with little data, or even very little consideration but they can have big implications. You might need someone on your team to do some additional work, or work late in the office. Maybe they need to stop what they’re currently working on, or join a different team.

Sometimes it can feel even more minor, maybe someone wants to leave early for an appointment, or work from home. Even if we don’t have a full picture when we make these decisions we can make the right decisions by simply doing what’s right as a human. We can make sure they understand what we’re asking, and why. We can give them space and time to articulate their concerns or questions, in the format that best suits them.  We can trust them.

When asking people to do something different or new we can remove a large workplace stress by simply making the priorities clear. Adding more work to a busy workload is a common and unfair practice. We should clearly state out expectations of where this fits into someone’s work, and if we don’t know what else they’re working on we should make sure to find out before deciding to allocate more work.

As managers we will often have more context on situations and are well placed to drive direction through a team but we should treat that context as a privilege. People choose to work with us, and by taking just a bit of time to work with them we can remove so much of the work-place frustration and stress.

Amy Management

It starts with a change

The person you are at 35 is not the person you were at 25. No one really explains that as you grow up you change. You start to like different things, and maybe even dislike things you really liked when you were younger. Life experiences can open new doors, or scar you beyond all hope of recovery. Maybe most surprisingly you just get bored.

After many years of enthusiastically testing, re-testing, and hopefully overseeing smooth releases it’s time for a change. I’m still an avid fan of great testing, and will always love the incredible testing community that now contains a number of very good friends but my interests have changed. Right now I’m excited about working with, and supporting the teams who build the great products.

My original blog will remain up, and may even see a new post from time to time, but this is my new home. Follow along for thoughts on managing people, hiring, building great teams, and spreading happiness at work.