Daniel's notes on Become An Effective Software Engineering Manager

Since you're a management application that has just been deployed into production, you're going to need to restore from backup. But-oh no!there isn't a backup to restore from. So you're going to need to create one. You're going to create a snapshot for yourself. This snapshot will be the basis on which you will begin your work with the team.

With time, you'll be able to form your own independent view of your team. You'll know how they are performing, the direction of their work in the future, and the individuals themselves. However, since you've only just started, you're going to have to do some investigative work. At any given time, there are three views of the team that you can compare and contrast. They can be used to discover areas you can work on right away. • your observations • your manager’s observations • your team’s observations

• Your own observations. What you see day in, day out when working with your team. However, you've only just started, so you'll need to rely on others while you form your own view. • Your manager's observations. Your manager will be interested in your performance, which fundamentally is your team's performance. What do they think about them and why? • Your team's observations. This actually consists of the individual views of each member of the team, but we'll group them into one for simplicity. How do they feel about themselves and their colleagues? How do they feel as part of the wider company? Your initial task is to work out what those views are. Once you've done so, then you can compare them against each other to discover where your work can begin.

You form your snapshot by taking what you've learned from the team, your manager, and yourself and overlaying them like a Venn diagram. Then you can begin to work out where particular observations fit into the intersecting circles: • Alignment: Observations or beliefs that you, your team, and your manager all share. For example, you could all observe that everyone is generally happy or that dev servers seem to break all of the time. • Poor communication downward: This is where you and your manager share observations or beliefs, but the team is either unaware or disagrees. For example, both you and your manager may both observe that the team cause a high number of bugs in production when compared to other teams, but the team themselves are unaware that this is an issue. For some reason, the team hasn't been clearly informed.

• Poor communication upward: This is where you and your team share an observation or belief, but your manager is unaware. For example, both the team and you have observed that they are understaffed for the roadmap that they have committed to, but your manager isn't aware that they are struggling. For some reason, this problem hasn't been raised. • False beliefs: Here, both your manager and the team have a conflicting observation or belief from your own. This can be especially true if you're new to the organization and have seen things done differently elsewhere. For example, the team and their manager could think that their deployment process is fine, but you can observe they only release once a month and it requires a lot of manual effort and often fails. At your previous job, teams deployed to production automatically whenever they wanted, often daily.

The core principle of the system is this: you want to keep as little information in your head as possible. Human brains are terribly clever, but when there are many sensory inputs, they're not great at remembering every little task. How many times have you said to yourself that you'll pick up dishwashing liquid on the way home from work, only to reach for the nonexistent bottle after dinner? It happens because we are humans.

Several reasons explain why it's often hard to find the satisfaction as a manager: • You're primarily working through other people, so there's less to feel that you have tangibly done by yourself. • You do dozens of little tasks rather than fewer substantial ones. • You are context-switching throughout the day, which can be tiring and frustrating. • More of your time is spent in meetings and discussions, which do not produce a concrete document, block of code, or production deploy. • You're more likely to be interrupted and just end up not being able to get your work done anyway!

Being a Role Model Being a good manager is about walking the walk as well as talking the talk. The best way to demonstrate to your staff and your peers is to lead by example. Be present and visible, get involved in day-to-day discussions, and contribute technically if you have the time and inclination. Demonstrating the standards that you wish to see others perform to is the best way to create change, so lead from the front! If you want to increase the flexibility your team has in their core office hours but you're in the office from 8:00 a.m. to 7:00 p.m. each day, then you're not being a role model. Go home!

Nudging The concept of nudging is influencing a decision by contributing your own viewpoint to the discussion. For example, you may be involved in a discussion about whether to build or buy some particular software, and you make it clear how you feel about the situation. You are not the decision-maker, but you can influence the decision. Like decision-making, nudging can occur for decisions of all sizes. You may put your viewpoint across about whether to book a meeting immediately or tomorrow, or equally state your case in a discussion as to whether to open an office in the United Kingdom or abroad. Try to view your daily interactions through the lens of nudging, and you'll soon see that there are ample opportunities to broaden your influence on the organization, thus increasing your output as a manager.

• You are ultimately accountable for your team's output. If they're not able to perform well, then it's your job to improve it. • Your team's output is more important than your own personal output. This means you should be spending more time delegating, coaching, and mentoring, rather than doing tasks yourself. • You also do your work through those outside your team that you influence. This means all of that nudging and being a role model is important. It helps improve the rest of the organization too.

You Do Not Delegate Accountability The key to good delegation is understanding the difference between accountability and responsibility. Despite the words often being used interchangeably, there's a subtle but important difference between them when it comes to delegation: • If you have accountability for a task, then you are being held to account for the completion of that task to the required level of quality. • If you have responsibility for a task, then you're the one who is actually doing it.

• Delegate enough to challenge your staff. Delegation is a win-win since your team can get more done and your staff get to feel challenged, learn new skills, and accomplish things together. • Retain enough control depending on the criticality of the task. For important, highly visible work, don't be afraid to do more frequent check-ins to ensure that you're on top of what's going on.

Don’t: • Abdicate. You cannot delegate without maintaining accountability for the task. If you are not accountable for the result, then you are abdicating from it. • Expect others to work the same way as you. The more you delegate, the more likely it is that the person will approach the task differently to you. That's absolutely fine. You should maintain accountability over outputs, not the process. Doing otherwise is not delegating: it's micromanaging and meddling.

Talk About Performance At the beginning of your relationship with your manager, you should talk about performance, Notably, there are two areas to explore: • What does your performance equate to in the eyes of your manager? Is it the retention and happiness of your staff, the amount of work that you get done on time, some strict uptime SLAs, or is it entirely subjective? • What is their performance dependent upon? You can begin to get a view into the wider organization. Are they fundamentally accountable for everything that their teams ship, or are they accountable for more abstract business metrics? Do they even know?

The simple act of taking time for yourself every week to summarize how things are can be extremely therapeutic. It can help you abstract away from the problems that you are facing and work them through with yourself on paper. Studies have shown that journaling in one's personal life can have a positive effect on mood and well-being. I've found the same to be true about weekly journaling at work. If you struggle with what to write, then perhaps you could try based on four Ps: • Progress: What has happened since last time you wrote? • Problems: What issues have occurred and what needs addressing? • Plans: How are you going to approach those issues going forward? • People: How are the individuals on the team? Are they doing well or are they having a hard time? What could be improved?

What to talk about in one-to-one? • observations from the past week either about their work or the team’s. • a deep dive into a project or piece of architecture that they are working on. • updates that will be interesting for my staff, such as what has recently gone on in any other meetings that I am part of. • coaching.

In your first one-to-one, ask the following questions: • which areas would you like the most support with? • how would you like to receive feedback and support? • what could be a challenge of us working together? • how might we know if the support I am offering isn’t going well? • How confidential is the content of our meetings?

It's Their Meeting, Not Yours Despite the fact that your one-to-ones are your best chance to positively impact your staff each week, the paradoxical stance that you must adopt is that the meeting is theirs, not yours. What this means is that you must "keep the thought bubble over their head" for as much of the meeting as possible. Do this by asking leading questions, nudging the conversation in particular directions, and most of all, by listening. It's not your job to direct the conversation or pontificate in this meeting; it's your job to absorb and guide.

Try and get your direct reports to do 70% of the talking. If you feel like solving their problem for them, don't. Ask another question and let them arrive at the conclusion themselves. This is an art that takes some practice, although some are naturally good at this with little to no training.