Accidentally in Code

Tag: management

Running a Manager Feedback Cycle
Credit: Flickr / Thorben

I just ran a thorough feedback cycle for the managers (leads) in my team. This is what it looked like.

Motivation: It’s hard to get feedback as a manager, the hope was that people would be more candid if they 1) submitted feedback anonymously 2) to someone else. Because we tend to amplify negative feedback, there was a benefit to having someone else go through it, find trends, and repackage it for the recipient.

Process
- Put together a document of questions and discussed with people who to send the feedback requests to (everyone on their team, other leads in mobile, people on projects owned by that lead).
- Sent those questions to those people using our anonymous feedback system.
- Gave people a week to respond (and then extended it so they had two).
- Asked people getting feedback to send me a 3-2-1-Oh! Put it in a doc for each person.
- Collated responses in a spreadsheet (and in the doc for each person). Made sure these were private.
- Color-coded the spreadsheet (green = positive, orange = actionable). I would have used red if there was anything that was particularly worrying, but thankfully I had no need to 🙂
- Went through and summarised under two headings: What Your Team Appreciates About You and What Your Team Would Like to See From You.
- Put together a section called Takeaways which contained 4-5 actionable things from the headings above (including things to keep doing).
- Copied relevant content into a new google doc (excluding responses), and shared it with the person. These were called “Name – Private” (my working doc) and “Name” (the one I shared).
- Had a call and discuss the content.
- Sent to HR.
Questions
1. On a scale of 1-10, how would you rate XXX’s overall performance as a lead? (one being “they suck” and 10 being “they don’t come any better”? Explain your rating.
2. What’s the best part of working with XXX?
3. What’s the hardest part of working with XXX?
4. What are three of XXX’s strengths?
5. What do you wish XXX would do more of? What do you wish XXX would do less of?
6. If you had one suggestion for how XXX could go from good to great, or from awesome to awesomer, what would it be?
7. If you were having lunch with a friend and talking about your job, how would you describe XXX as a lead?
8. Complete the following, “My ideal lead is someone who…”
9. Describe yourself when you are at your best. Is there anything XXX does to enable that?
10. Anything else?
My coach Dani put these together for me 💜

Document Headings

Bold: Included in the document I shared.
- Feedback
- > What Your Team Appreciate About You
- > What Your Team Would Like to See From You
- > Takeaways
- HR Questions
- 3-2-1-O
- Questions
- Response 1
- Response 2
- …
What I’d Change
- Keep track of who I sent requests to – mainly to have an idea of how many responses I was expecting, and be able to remind people via email (would have to be all of them) instead of posting general requests in Slack.
- Adjust the questions for people who aren’t on the team (e.g. have peer questions, and perhaps also project IC questions).
Time Commitment
- Researching and thinking about the questions: several hours. I asked a colleague and three of my CTO friends for advice, and ended up having my coach help me with the more detailed questions.
- Sending out feedback requests: 15mins / person.
- Collecting feedback into the doc / spreadsheet: 30 mins – 1 hour per person (I also read it through which got me thinking about the feedback before I started processing it).
- Going through the spreadsheet in detail, colour coding, and writing up detailed feedback (including the HR feedback questions I was sent): 2-3 hours per person.
Note: this is just the time commitment for me to run it. Writing the 3-2-1-Oh!s and filling in feedback for others also took up time on the team.

What People Said

I loved this feedback review mostly because of how structured and transparent it was. Not only did I know everyone who was getting reviewed, but I knew everyone was getting the same questions. That relieved a lot of the stress in wondering “why did I get this review request?”. The question format of listing things (name one thing, what are the three things, etc) also made it super quick.

~@kwonye

There weren’t any big surprises in my feedback, but I appreciated getting the reinforcement that I’m on the right track — knowing what you’re doing well is always motivating. I liked that the top-level points were broken down into “what your team appreciates” and “what your team would like to see” — where criticism is presented as concrete things that can be improved or changed.

~@mattmiklic

I’ve always been apprehensive about getting feedback about myself just because of a fear of failure. Internally I can feel like I am succeeding but still get nervous when I go through a feedback process. This process eliminated a ton of that upfront fear because I knew what questions were being asked and trusted the process to be fair and unbiased unlike in previous jobs. I love getting actionable things to do or try out!

~@astralbodies
March 23, 2017
The Weekly Notes Post
I read a lot of stuff on the internet, and a lot of that is about being a better manager. It’s rare to find something that is:
1. Extremely concrete and actionable.
2. At the exact time you need it.
But in November, I did. I found this post from @SonOfGarr about sharing information with his team.

Week-in-Review: a document containing relevant meeting notes from the week prior.

Over the past few months I’ve evolved my own process. We use internal blogs heavily, so I publish it there and include a link to the previous one at the end of each one. Either I wrap up my week with it on Friday, or it’s how I start the week on Monday morning. I put it together as I look over what I did the previous week and figure out what my plan is for the one coming. Because much of what I do ends up in written form, and the notes from meetings I was in are often in other places, it’s an opportunity to tie all that together in a more coherent narrative. It’s also an opportunity to talk more about the why – which is something that I haven’t always taken advantage of that I can work on.

I also find this a useful place to post initial or partial thoughts that I haven’t fully fleshed out yet. For example, I was thinking that we should probably improve our tooling, so I mentioned that one week to see what came of it. It’s also a place to explore themes that I’ve noticed in communication. Whenever similar things come up in 1:1s or skip 1:1s, then I’ll highlight the things I’ve heard from multiple people and explore them a bit.

With a team of 25, I don’t manage to interact with everyone, every week. However in my last round of skip 1:1s I asked people if they had any feedback for me and was pleased that this weekly post came up from a number of people as something they appreciate. It has become part of how I make my work visible to the team, and combined with skip 1:1s how I try to demonstrate approachability, accountability and transparency. Improving accountability on the team has been something that we’ve been thinking about lately, and I think it’s important to demonstrate that accountability in return.

I miss writing code, and the concrete deliverables of a feature, a test suite, the high of conquering a bug. It’s easy to want to go back there, when the nebulous and meta-ness of what you actually should be doing feels overwhelming. For me part of embracing longer term impact is to make it concrete where I can – to theme my weeks, and see if I can push one major thing forward – and to celebrate my wins where I get them. The regular act of sharing with my team what the details of that looked like helps with that, even as I judge myself by the impact over the longer term.

There is also a small, personal benefit to the WIR. I found that whenever I finish a WIR, I have this tremendous feeling of accomplishment. I used to look back on my meeting packed calendar and think that I didn’t get very much accomplished. The act of writing my WIR helps me extract the value from each meeting. It allows me to reflect and keep things moving forward. It makes me realize how much I “did” each week. Authoring a Week-in-Review has been simple, yet powerful management tool. If you’re trying to figure out how to share information your team needs, that only you have gathered, and you want to cut out a team meeting, give it a try.
March 16, 2017
Things to Figure Out as a New Manager: Part 5, Trust

Credit : Flickr / Glenn Lascuña

This is the fifth and final part of the new manager series. Yes, there’s plenty more to figure out, but the idea is that with some sense of these things you will have the basics under control, and then you can figure out what your team needs from you and go from there.

The fifth part is trust, because it builds on the other four. Trust is a characteristic of human relationships more related to respect than to like. It’s something you need to earn, rather than expect. It’s something you need to create any kind of change, and to get people to follow you into the unknown.

If you’ve figured out your schedule, you’ll be able to be where you said you would be. If you’ve figured out social support you won’t ask too much from those who report to you. If you’ve figured out communication, people will feel like they can talk to you and make sense of what you say. If you’ve figured out feedback, people will know that you will tell them what they do well, what they can do better, and that you’re always thinking about what you need to do better, too.

This is your foundation. When it comes to getting people to trust me, I have a simple rule: never ask for it. Just earn it. Lack of trust is the biggest, most implicit piece of feedback. If someone seems not to trust you, return to these pillars – have you been flakey on 1:1s? Sort your schedule out. Are they tuned into your anxiety? Figure out what support you need, and get it. Do you not communicate together well? Make more of an effort to adjust to their communication style. Do they not feel recognized or supported? Pay more attention to their work and highlight the things they do well. Or – give them clear information about what they need to do to be successful.

Motivations matter here. We’ve all encountered people who we didn’t trust because we felt they were selfishly motivated or just somehow inauthentic. We earn trust, not by seeking trust out directly, but by building the foundation of a strong and respectful relationship. Trust follows. Or doesn’t. Regardless – we do the right thing, for the right reasons.

It’s also important to acknowledge and appreciate acts of trust. The question someone asks, not knowing how you’ll react to it, or how supportive you will be. The failure someone owns up to, before they know how you’ll handle it. The risk that someone takes when they join the team.

Giving Trust

Whilst we can expect to earn trust ourselves, we can give it freely. Distrustful people are exhausting, and paranoid people cannot build a strong team.

But understanding people means understanding what the boundaries of that trust should be. You might trust someone to architect a system, that doesn’t mean you don’t ask any questions about the decisions they make. You can trust someone to do something, that doesn’t mean you never follow up to see how it went. You can trust someone and promote them to manage under you, but that doesn’t mean that you never check in with their reports to see how that’s going. Trust means that you bet on someone’s capacity to grow into something – it doesn’t mean you never help them along the way there.

Trust and accountability go together. Accountability works both ways – it’s hard to hold people accountable without making yourself accountable. When managers are flakey, this can bleed down onto the team. Accountability – like trust – rests on respect, rather than like. If people don’t take you seriously, even if they like you, you can find yourself being held accountable for a team you can’t hold accountable. This is unlikely to end well for anyone, least of all you.

Special Types of Trust

There are two people I seek out – people who can be relied on (trusted?) in a particular way.

The Person Who Keeps It Real

This is the person who tells you the truth, even when they think it’s not what you want to hear – in fact, especially when they think it’s not what you want to hear. This is a great person to have around.

The Super Reliable

The person who if you ask them for something, it’s done. Use judiciously. Appreciate tremendously. When there’s some kind of crisis and you feel overwhelmed, this is the person you turn to.

Now What?

I want to tie this series up in a neat little bow, but I’ll refrain. People are messy. The process of learning to people is messy. You’ll screw up. Some people you’ll try hard with, and you still won’t succeed. But if you act with kindness and empathy, avoid the trap of being self-serving, and work really hard… it’ll probably be okay.

This is part 5 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. Part 2 was about social support. Part 3 was about communication. Part 4 was about feedback. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.

February 2, 2017
Things to Figure Out as a New Manager: Part 4, Feedback

Credit: Flickr / Daniel Lee

There are two things we should talk about before talking about feedback.

First is the idea that feedback is just when you tell someone they screwed up in some way or need to do better. This makes us dread giving feedback (well, for those of us who aren’t sociopaths who enjoy tearing people down), and it means people dread receiving feedback too. It’s noticeable that we more often qualify “positive feedback”, because the default is negative (aka “constructive”).

Obviously constructive feedback is necessary, and something we need to get comfortable both giving and receiving. But we also need to get comfortable with the idea that feedback is just observations of another person’s behavior reflected back to them – ideally it’s normal, and not some big event.

Secondly is that feedback is often a very gendered experience. My friend Camille once observed to me that women get too much feedback, and men get too little. Women have often had the experience of receiving a lot of low quality feedback, which they then have to filter through to the pieces that are useful. Men are often not used to receiving feedback at all. Whilst this is not universally true, it’s worth thinking about how your own experience can affect your expectations.

Regardless of the baggage we bring to giving feedback, we can learn to be good at it. Step one is understanding where we are coming from.

Receiving Feedback

Implicit Feedback

Implicit feedback is feedback you observe rather than receive. It’s something I particularly look out for in communication. For example, when I communicate a complex topic to people, I always pay attention to see what they say about it later, because this tells me a lot about what they took from whatever I said. If what they are saying doesn’t fit with what I intended, then it’s a sign we need to talk about it more – and that I need to be more clear.

Other places to look for implicit feedback include: velocity, morale, and collaboration. For instance if you start doing standups, and it seems to improve team (or individual) effectiveness – that would be an example of implicit feedback.

Explicit Feedback

An important behavior to model as a lead is the act of listening and acting on information – including things that make you uncomfortable (e.g. “constructive” feedback). Bear in mind that it’s really hard for people to give their boss feedback, and that feedback more than ever is likely be based on partial information.

E.g. Someone gives you feedback that you’re not managing poor performance well, but what they don’t know is the context of that poor performance (e.g. events in someone’s personal life).

Or, someone gives you feedback that you’re not sharing information, but what they don’t know is that your boss isn’t telling you things, and you found out in the same meeting they did.

Or, they complain that you’re not involved enough in the day to day of the team. But what they don’t realize is that you’re spending most of your time being a shit umbrella.

Feedback that lacks context helps you understand what the person is experiencing, even if it doesn’t (shouldn’t!) inform what you are doing. Say thank you, highlight what you are doing, and be honest about what you’re not going to do – for example something you’re going to consider more before acting on.

Owning Up

Because people are less likely to give their boss feedback, it becomes all the more important for you to give yourself that feedback to them. To own when you screwed up, and apologise. To acknowledge what you learned and what you would do differently. To recognize implicit feedback, and make it explicit between you.

Giving Feedback

Positive Feedback

People often talk about building a relationship where you can give people constructive feedback and they’ll listen, and mention positive feedback in that context. Yes, it’s important to build a relationship where you can give constructive feedback. Yes, positive feedback helps with that. No, that’s not the only reason to do it.

In general, people like to be appreciated and recognized. Noticing what someone has done really well, or worked really hard on, is not a very arduous thing to do. It’s part of your job as a manager to recognize what people do well, and not just at performance review time, but continually. It’s good to recognize what specifically was good, in order for your feedback to feel personal, and not bland (and meaningless). Aside from this being a worthwhile endeavour in and of itself, it’s a safe assumption that people want to be successful, and telling them what’s appreciated is a way to get them to do more of that.

Pre-emptive Encouragement

This is encouraging people to do things they’re unsure about or a bit uncomfortable with, especially things that will result in positive feedback if they do them (or “constructive” feedback if they don’t). For example, at work, we have an internal blog, and I want to see people posting on it more. One thing I do to encourage that is to ask people questions about things they’re working on – their support rotation, or a project. Then, I listen to them. If they seem engaged by the topic, or I learn things from the conversation, I suggest to them that would make a really good blog post – and offer to help with that, e.g. proof reading it.

Constructive Feedback

There’s a lot written about giving constructive feedback, and I don’t feel much need to add to it. A couple of points.

Firstly, this is something that we often put off in some misguided idea of kindness, but mainly because it makes us uncomfortable. It’s not kind not to tell someone that they will eventually discover. For example, finding out that they didn’t get promoted because of something you didn’t tell them six months earlier. These conversations are hard, but not having them is harder.

Secondly, it’s important to ask yourself why you want to give them this feedback. Are you trying to make your life easier, or them better? People will often realize your motivations. Often the people I’ve learned the most from are also the people who have stressed me out the most. My life might be easier if they pushed me less – but neither of us would be better off.

This is part 4 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. Part 2 was about social support. Part 3 was about communication. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.

January 26, 2017
Things to Figure Out as a New Manager: Part 3, Communication

Credit: Flickr / Ravi Shah

Now you’re a manager, communication (always important) has become even more import, and your words carry more weight.

How do you communicate… one on one?

… to the team?

… about the team?

One on One

In a relationship with a power dynamic, the burden of a good relationship is on the person with the most power. I first made this observation with respect to interviewing but it applies here too. If conversations with someone are painful, it’s on you to make them less painful. Showing up regularly helps, as does taking an interest in them as people. Ultimately, different people will have different ways in which they want to communicate with you, and you can learn their styles and preferences and make an effort to accommodate that. Different people also have different baggage that they bring to work. If someone isn’t used to their manager seeing them as a human being, that will take a while for them to get used to. If someone has had bad experiences in the workplace they might take a while to open up.

Be consistent, and be kind. Work on doing good 1:1s. Take time getting to know people, and use what you learn. But don’t delude yourself that it’s kind to delay telling someone something they will find out eventually – for example, don’t delay talking to someone about their performance if there are problems. These conversations don’t get easier.

To the Team

How often do you talk to the team as a whole? What kind of things to you talk about? How do you communicate a the direction of the team and keep things on track despite all those tempting diversions?

Get comfortable repeating yourself. Decide what you will do, and make hard choices about you won’t do. Talk about why you are choosing to do what you are doing. This is team direction communication.

The other aspect of this is communicating the kind of things you spend your time on. Figure out what you’re comfortable with. I do a version of this, each week I post some notes about what I’ve been working on to the team blog. Bigger things get their own post, but consistently I show up and share how I’m spending my time. With a smaller team I used to share my priorities in the daily standup.

How you communicate to the team depends on the size and how people are receptive to information – some teams like to write, and others like to talk. But it’s easy to not share what you’re doing, in part because people don’t ask and it can feel like there’s not much interesting to say about the activities of management. But people having some kind of insight into the kind of things you worry about and spend your time on is really helpful.

About the Team

How do you talk about the team to your peers? To your boss? How do you highlight what is going well, and how do you get the alignment and help you need from other leaders in the organisation?

If you manage a team that has been underperforming (and particularly if your joining the team was supposed to address that) how do you communicate that things are getting better – given that they won’t change overnight?

This depends very much on the organization, but again I think consistency is key – and patience. People are focused on their own priorities, and can take a while to notice improvement elsewhere.

This is part 3 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. Part 2 was about social support. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.

January 19, 2017
Things to Figure Out as a New Manager: Part 2, Social Support
Credit: Pixabay / Alexas_Fotos

Welcome to being a manager! Did you think it was a promotion? It’s going to be hard, lonely, and emotionally exhausting for a while.

Why?

Because you have to figure out your social support. As an IC (Individual Contributor), you had teammates, and these were your peers. As a manager, you now have a new set of peers (hopefully, unless you’re one of the first managers) but with less clear cut ways to build relationships with them. There is no management daily standup, and no code review. You will be dealing with things that can’t be discussed openly – or perhaps, at all.

Why is it Hard?

People will tell you things. They will tell you about health problems, divorce, loss, and whatever other chaos is going on in their life.

Or they won’t tell you, but you’ll notice things and wonder, try and create space for them to tell you.

Or there isn’t anything, but things are still not right and you’ll try and figure out what will improve things, what will help, and deal with the uncertainty and the guilt if you… don’t.

Being an IC was much more about showing up and caring about code, or product. Being a manager is about showing up and caring about people, the code they write and product. It means caring about people you don’t personally like, and not being too swayed by the perspective of people you do personally like. It means hearing about pain, and sympathising, but as a supportive manager rather than an untrained therapist.

Why is it Lonely?

It’s lonely because you now have vastly fewer people – or maybe no-one – to talk to. HR may (if you’re lucky) give you logistical support, but they won’t give you emotional support. You’ll be representing what’s best for the team and the person against someone whose job it is to represent the company (and ensure the company doesn’t get sued).

It’s lonely because there is no stack overflow for people, and so you will live in the grey area where you have information but few clear recommendations.

It’s lonely because it’s fine not to know a programming language. But admitting you don’t really know how to be a manager when that’s your job – with no unit tests, no code review is terrifying. You’re conducting experiments on people’s careers; there are no AB tests here.

Why is it Exhausting?

Some months into my first year as a manager, I realised that my focus was the maintaining and recharging of emotional energy. From a WTHIC letter…

“My friend Diana and I had a long phone call the other weekend, and she asked me “what’s your current project right now?” My response was: the maintaining and restoring of emotional energy. This is my observation about becoming a manager. If being a manager is emotional labour, then the challenge of management is the source of emotional labour – emotional energy. As an IC it was much more about creative energy. Or just sheer bloody-mindedness.”

At least for me, I found that the ways in which I needed to recharge from the deep focus of an IC were different from the shallower and shorter focus and interruptions of management.

I just had less emotional energy on a daily basis. I was prepared to use what was left on close friends, less so on people who weren’t – and who maybe I never got closer to as a result.

As an IC my excuse for not dating was that I spent all day surrounded by men, I didn’t want to spend my evenings with more men. As a manager it became more that I didn’t want to find myself 1:1 with someone I barely knew, getting to know them and pretending to care about things that are of little (or no, formula one – yawn) interest to me.

What To Do?

As an IC, I had so many people I could talk to about my frustrations. We’d commiserate about XCode, or Eclipse, or Android Studio. About the state of testing, poor project planning, and bad managers.

As a manager, it’s amazing how often I’ll express some vague complaint to a friend, maybe mention that my day was exhausting because of some random thing I’m worried about, and get a response of “you need to fire that person”.

That’s not… how it works? Firing people can be necessary for medium or long term intractable problems. It’s a terrible default.

When two libraries don’t interact well together, the context of that is usually a straightforward description of the environment and dependencies. The description of the team and company environment will be really long, even if you fully understand it yourself, which you probably don’t.

The answer is:
1. People to talk to.
2. Ways to talk about things.

1. People To Talk To

Your manager is hopefully someone you can be really open with (one of my first observations as a manager of managers is that I spend energy supporting people on things they haven’t got anyone else to turn to on). If your manager is good, building this kind of relationship can be invaluable. It’s often helpful to be clear what you want advice on, and what you want to talk through.

A coach. Working with a coach has been really, really helpful. As she puts it, “I’m a vault”. Because we talk 3x a month, she has a lot of context on what’s going on with me. She’s also a non-judgemental space where I can be honest about the stuff I find really hard.

Trusted friend-mentors. My preference is to have one specific question and go deep on that rather than trying to talk about everything.

Peers. This is why we created the New-ish Eng Manager Slack. We operate under Chatham House Rules and it’s a place to discuss things that we don’t always feel we have other people to turn to about. When I was an IC I could just tweet random questions but it’s often not a great idea to do that as a manger. Aside from the impact on your team, it can be something you need to explain when you try to recruit.

2. Ways to Talk About Things

Complaining

If you have a bad day writing code, it’s fine. Everyone understands. If you have a bad day running a team… it’s harder to explain and riskier to express. Sometimes we all just need to complain. This is part of why we have a “no unsolicited advice” rule in the Slack (see also: The Gestalt Protocol). Obviously we need to take productive action on the things that stress us out eventually, but sometimes we just need to vent.

Gathering Information

This is good for getting a bunch of information about how other people solve things that you can then use to generate more ideas for things that will work for you. The thing is to make the question specific enough, and to frame it so you’re inviting people to share their experience, rather than tell you what to do.
- How do I do 1:1s? -> Do you have any questions you like to ask in 1:1s (and why you find them useful)?
- How do I onboard a new manager? -> Do you have a process for onboarding new managers? In particular are there any resources you share, or extra things you do for managers in their first 3-6 months, year?
- How do I fix this project that I think might be failing? -> What early warning signs of failure do you look out for in projects?
- I’m worried my team doesn’t communicate. -> What do you do to foster communication amongst your team?
Going Deep

Above I mentioned picking one question and going deep on it. This is good for example when you have an idea of a pressing thing that you need to solve for your team, but little insight into how to solve it. This is best for 1:1 conversations.

When I’m thinking about what to talk about, ahead of time I’ll think through three pieces: Question, Constraints, Observations.
- Question: What do I need to do? E.g. create a roadmap. Assess a project that seems like it might be failing. Resolve a conflict.
- Constraints: What constraints am I operating under? What do I not have control over? What about the wider organisation or team effects this? E.g. “The ratio of designers to engineers is really low.” “The culture of the server side engineers seems really different, and I’ve noticed resistance to planning or regular status updates.”
- Observations: Things I’ve noticed that seem pertinent. E.g. “I’ve noticed that people don’t seem to push back enough on things that get introduced later that are a lot of extra work – some of these really don’t seem worth the time spent on them.”, or “I’ve noticed that too often when I follow up on things they are untracked or progress hasn’t been made on them.”
This is part 2 of a series aimed at new engineering managers. Part 1 was about figuring out your schedule. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.
January 12, 2017
Things to Figure Out as a New Manager: Part 1, Your Schedule
Credit: Flickr / Maythee Anegboonlap

We normally talk about the challenge of moving to a manager’s schedule in terms of our desire to write code. But writing code is just part of it. As an IC, you probably had some kind of schedule that worked well for you. When we move to being managers, it’s tempting to try and slot “management stuff” into that schedule.

This generally doesn’t work that well. It can work, if you have a small team, with no major problems, and a clear roadmap. Otherwise, it’s probably going to fall to bits.

Small Team

It seems obvious that a larger team is more work than a smaller team, although this is not always the case because of other variables like organization, and team challenges. But we can break the major team time commitments down into two pieces – managerial, and person.

Managerial Overhead

This is the “stuff” you need to do now you’re a manager. Manager meetings (what happens in these? You finally get to find out). Process stuff. This differs everywhere, but in general there is some stuff you now need to attend to that you never used to worry about as an IC. Usually this involves some amount of meetings, and some amount of non-meeting work. This is the stuff more like a “fixed cost” in economics – it doesn’t change that much with the size of your team.

Person Overhead

This is the per-person responsibilities. Obviously, 1:1s are a huge part of this. Performance Reviews (whenever they happen) will devour huge amounts of your time. Then there are things like vacation entitlements and expense reports.

People have a tendency to capture this by time in 1:1s, but it’s not just time in meetings – it’s also time preparing and following up.

This is more like a “variable” cost in economics. As you add one more person to your team, how much more time a week do you spend on them? Newer people, and more junior people will tend to need more of your time.

No Major Problems

As a manager, it’s your job to fix the problems on your team, and at least mitigate the problems created in the wider organization. Three examples: re-orgs, performance, and conflict.

Re-orgs

There are logistical problems caused by re-orgs – your team is different and now you have to get to know people again! Your mandate has changed and you need to make sure your work is aligned with it.

But there are also people problems caused by re-orgs. Even the best organized and well communicated re-org does not leave everyone happy. ICs may not have insight into what caused the need for the re-org – why that director left, or what challenges exactly the organization is re-aligning itself to face.

And we all know that many re-orgs are neither well organized nor well communicated. At The Conglomerate they used to re-org every year. Many people who I knew there (including myself) have something that is best described as “re-org trauma”.

Re-orgs make people panic. They deliberately create change – which creates uncertainty. Even if people don’t leave because of it (which they often do), trying to create some kind of semblance of order and stability on your team will take a while. And when people leave, you have to deal with that as well.

Performance

Performance problems take a huge amount of time to manage. Biggest is the time you spend figuring out expectations, setting clear expectations, communicating those expectations, and then evaluating the person against those expectations.

You’ll also have to consider this when you plan, when you communicate what the team is doing. And you’ll have to deal with the people who notice what’s happening, without actually admitting what is happening and why.

Unless you’re some kind of monster, you’ll probably spend a lot of time feeling terrible and uncertain, too.

Conflict

Well-managed conflict will make your team better. Conflict arises because people feel strongly about things and disagree. This is great! People feel strongly about things! They have different perspectives!

This is also exhausting.

You’ll need to spend time with each person, understand where they are coming from and why, ask them questions that challenge their thinking, and lay some groundwork for them to listen to each other. You probably also want to be present to moderate the discussion and make sure it’s productive.

Also, pro-tip: if you have conflict on an engineering team, one of the first places it will show up is in code reviews. Especially with quiet conflicts that went on without blowing up and haven’t been resolved, or aren’t fully resolved yet, you can expect to spend a lot of time on code review – making sure they are done promptly, respectfully, and thoroughly. You may also need to spend time educating people on what good code review looks like, and modelling that behavior yourself.

A Clear Roadmap

If your team has a clear mandate, and a thorough PM, you’ll have a nice roadmap that they ask you for feedback on when they need it. You’ll give that feedback, highlight things that seem like a lot of work for little gain, do some sprint planning, maybe run regular retrospectives depending on how Agile you are.

If you don’t have a clear roadmap, expect this to dominate your working (and waking) thoughts.

What are People Doing Now?

If you don’t have a clear roadmap, and that’s not because you randomly had a surprise re-org yesterday, there’s a good chance that what people are working on now is uncertain and undefined. Hopefully people are working on important things, but are they working on the most important things? Do they know what the important things are, or are they drifting?

Before you figure out where to go next, you’ll need to figure out where you are now. Starting with the big, multi-month multi-engineer projects.

What are People Doing Next?

Is there stuff already scheduled? Is there stuff already promised to users or other parts of the organization? Are there things, or parts of things owned by your team that are on fire?

What Could We be Doing as a Team?

This is the endless list in the backlog or the ideas that people generate. But most important is to filter it by asking the next question:

What Should We be Doing?

What are the big opportunities that could potentially drive growth? How do we measure the potential? How do we break it down and measure progress – what metrics do we measure against?

Where’s the Organization Going?

It’s always important to stay tuned into the wider organization and be aware of decisions and projects that might impact your team. But when the roadmap is less clear this is especially important and liable to take more time. If your team doesn’t have a sense of where you’re going, it’s unlikely anyone else does either, and so you’ll need to look out for implicit expectations, and decisions made without you.

Rebuilding Your Schedule
- Figure out your external commitments: what meetings do you need to attend?
- Schedule your internal commitments: team-meetings, and 1:1s.
  - Scheduling 1:1s all on the same day can be really helpful for noticing patterns, and avoiding context switching.
  - Make sure you pick a good day – e.g. if you always cut a build on Thursdays, Wednesdays and Thursdays are probably not good days for 1:1s. Friday would be better.
  - With 1:1s (well, with everything, but let’s start with 1:1s) the goal is to be effective rather than efficient. It can seem efficient to schedule all your 1:1s back to back, but it’s rarely effective. Either schedule more time than you need, or add breaks after each one. This gives you time to get more tea (or coffee!), write up your notes, deal with quick things.
- Figure out your priorities.
  - You might not be able to work on the “most important” thing immediately – either because you need to address:
    
    Something more immediate.
    
    Ground work for the most important thing.
    
    Something that will build credibility to enable the most important thing.
  - I like to chose a “theme” for each week. At the end of the week, I measure myself by the progress on that theme.
- Figure out your tasks.
  - What needs to be done today? This week?
  - The kind of system that worked for me as an IC does not work for me as a manager.
This is part 1 of a series aimed at new engineering managers. For help and support, you can also ask for an invitation to the New-ish Eng Manager Slack.
January 5, 2017
My Favourite Management Reading From November

A collection of the articles I read in November that were most impactful on me – that I am still thinking about!

Credit: Pixabay / Alexas_Fotos

Defeat micromanagement by trusting more and controlling less

By @skamille

Whenever you level up as a manager, it’s easy to go back to what you are good at – but you have to spend more time on what you aren’t good at yet. Focus on outcomes not on the process.

A Manager’s FAQ

So much good stuff in this list of lessons about management, but is my favourite “If your employees do not ask you for advice, ask yourself why.” This is such a simple thing to measure, but it indicates so much. Do people trust you? Are they willing to be vulnerable with you?

Leading By Editing, Isn’t (and Why)

By @stevesi

I am going to be thinking about this for a while. It’s easier to critique (edit) things that to set up clear expectations, but it doesn’t make people more capable – and they have more information about the details than you do.

Generosity as Doing, Not Thinking

By @johnmaeda

Profound about how being generous creates generosity, and the idea that generosity is something you *do*, not think about – because otherwise it’s not generosity at all. I think this has a lot to teach us about the idea of servant leadership. Servant leadership is actually about generosity – about giving people space to focus, because you are taking care of distractions. One way that servant leadership becomes toxic, is because it’s become a demand for appreciation, like, “notice how much I’m doing for you” – which isn’t generous at all.

How I share information with my team

By @SonOfGarr

I really like this idea of doing a weekly review to share what has been going on with the team and I’ve been trying it out (my team also seem to like the idea). It’s easy as a manager to spend your time on activities and people are only vaguely aware – or unaware – of what you are doing as much of it doesn’t directly impact them.

Publish vs. Pull Managers

By @wiredferret

How do you communicate? How does this affect people you communicate with? I admit, I fall on the publish side of things – perhaps that’s why the weekly review appeals to me. I also think that in times of stress it’s really easy for people to stop talking to one another, and building habits around that when things are not (as) stressful helps.

My Writing on Management

The Secret to Good One-On-One Meetings: Show Up and Listen

I firmly believe that 1:1s are the most important activity as a manager, but they are definitely scary! I wrote up a bit about how I approach them, and my magical management trick of asking questions and listening to the answers.

Cate’s Career Coaching Process (aka a process for finding your next job)

I wrote up my Career Coaching exercise that I go through with people looking for their next thing.

The Daily 123

Replacing standup with text for remote teams.

December 13, 2016
On 1:1s

Credit: Flickr / Ivan

It’s a truth universally acknowledged that 1:1s are one of the most important activities of being a manager. And yet we all know of managers who don’t do them, or do them so badly that they can hardly be called 1:1s at all. I’ve heard about managers who show up to the 1:1 and talk at their report until the time is over. I’m not sure if this is better or worse than no 1:1 at all. The worst manager I ever had, I dreaded our 1:1s so much that I used to get up an hour later on days when I would have to speak to him. My recollection of them was that there would be a terrible, awkward silence, which I would feel compelled to fill, but anything I said would be judged and used against me.

Contrived social situations can be awkward. In a new report-manager relationship, both sides have to show up to a meeting with someone they barely (or don’t at all) know, and talk. Some people might face that situation with equanimity. As a new manager, I did not. It was terrifying, but worthwhile – and before too long had passed it was clear that everything I’d read about 1:1s being the most important use of my time as a manager was true.

At the core of a good 1:1 is this: show up and listen.

Let’s break this down.

Show Up

1:1s should be predictable. They should happen at regular intervals, and should only be cancelled under extreme circumstances – and then rescheduled as close to the planned date as possible. You should be on time. This is true for every meeting, of course, but being late for 1:1s can send a message that this kind of meeting is not a priority. That it’s something you fit in when you can, rather than a core part of your job.

Listen

Here is my management trick that works in almost every situation: ask questions, and listen to the answers.

Bonus points for good questions, but questions at all is a start. There are even lists of questions out there to help you! I loved Lara Hogan’s Questions for Our First 1:1, and I found some really helpful questions in First Break All the Rules.

The first question I like to ask anyone, though, is just “how are you?” And then I care about the answer. You don’t always get the most useful answer to this at first. In general “how are you?” is something people get asked a lot and the only answer the asker wants to hear is “fine”. But when I consistently show up and care about the answer I find I start getting interesting ones. Maybe someone is feeling under the weather. Maybe they are excited about something. Maybe they’ve been having a bad day. Maybe they just got some good news. Maybe they just got some bad news. You have no idea until you ask – and listen.

Starting with this question for a while made me anxious, because some people would respond by telling me about their work. I had internalised that 1:1s are not for status updates, but eventually I realised that how people are feeling about their work is not a status update, and it’s a perfectly natural way to start a conversation at work. I also realised that if someone is in the middle of some problem when you start talking to them, then it’s probably top of mind. Instead of asking them not to talk about it, giving them some time to talk themselves into a different headspace is a perfectly reasonable way to spend some of the time you have together. You should have better sources of information for “what is this person working on” than a 1:1, and more immediate signals for “things possibly not going to plan”, but a 1:1 can be a time to talk about “how does this person feel about what they are working on” – which if things aren’t going to plan can be good information about why things aren’t going to plan.

Having time for some undirected conversation is part of why I like 1 hour 1:1s. I read about them in High Output Management and the idea of spending an hour with someone made me feel uncomfortable enough that I sat with it and decided it was an idea worth trying. It’s not about spending the entire hour talking, but about making that time commitment that the whole hour is there if you want it. It gives you time to make feedback something you will work on together (so you don’t just drop it and rush to your next meeting), and it also gives time to work on something together, if that’s something someone wants to do. For example, working on an abstract for a talk they are thinking about.

At my last job, I did 1-hour biweekly 1:1s (every Friday, alternating between the iOS team one week, and the Android team the other) and whenever I mentioned this online I would get men telling me that biweekly wasn’t enough and giving me unsolicited advice about how often I should be doing 1:1s. This really annoyed me for many reasons, but eventually I realised that a core misconception that they had was that the biweekly 1:1 was our main communication. This was completely untrue. Once I found my rhythm, I spoke to everyone who reported to me every day, and if there was something that it seemed like we should talk about then we would jump on a call. Multiple times this resulted in one guy on my team telling me something and saying it wasn’t big, it was just because I asked right then. And maybe it wasn’t that important. But I would sooner know, and I would sooner he felt like he could tell me.

For me, 1:1s were about active relationship building, with a focus on the important-but-not urgent. But having built a relationships where we talked regularly and I listened, that created space for conversations to happen outside of the 1:1. And I never worried about missing something that was both important-and-urgent because 1:1s only happened every other week.

If 1:1s are the only time you speak to someone who reports to you, how to run that 1:1 effectively is not your biggest problem. The 1:1 is the time you set to demonstrate that you are someone who listens, and that generally things are better for you knowing about them.

TL;DR

If you think you don’t have time to do 1:1s, you don’t have time not to do 1:1s. Just show up and listen. It’s a solid start.

November 5, 2016