Accidentally in Code

Tag: management

Org Survey Part 1: Questions
Credit: Wikimedia

I remember when I managed a 6 person team, and I always felt like I had a handle on what was going on (perhaps I’m being overly nostalgic here). Now I manage a ~26 person organisation, and on a good day I feel like I have a general idea of what’s happening, and certain specific things that I’m focusing on in more depth.

For all the effort I make to be accessible and to build a relationship with individuals on the team, the reality is that a bi-monthly 1:1 and the odd slack conversation can only go so far. This is managing at a level of indirection.

A couple of months ago, with some input from existing practises, HR, and my colleague John, I put together an organizational health check. This took the form of two two-part surveys (using Google forms), that I’ve since refined and helped my peers use for their orgs.

Survey 1: The Org Survey

This survey goes out to all ICs on the team. The first set of questions focus on their overall impression of the org and org leadership.
1. My org lead communicates division strategy and direction to me in a way that’s clear and enables me to act on it.
2. My org lead regularly shares relevant info from the company, org, and other relevant parties.
3. My org lead has articulated to me a clear vision for the future of the org.
4. I agree with the vision that my lead has articulated for the future of the org.
5. The org is aligned with the the mission of the company.
6. The mission of the company is the right one for the future.
7. The org is high performing.
8. The wider organisation recognises the performance of the org.
9. My org lead provides a space for me to use my voice, and really listens when I do.
10. My org lead has helped me develop as an individual or leader on the team.
11. My org lead has actively supported me with technical or people issues.
12. Any other comments about the org?
The second set of questions focuses on their direct manager.
1. Which team are you on?
2. My direct manager gives me actionable feedback that helps me improve my performance.
3. My direct manager does not “micromanage” (i.e. get involved in details that should be handled at other levels).
4. My direct manager shows consideration for me as a person.
5. My direct manager provides a space for me to use my voice, and really listens when I do.
6. My direct manager keeps the team focused on our priority results.
7. My direct manager has had a meaningful discussion with me about my contributions to this project in the past six months.
8. My direct manager communicates clear goals for our team.
9. My direct manager has the relevant expertise to effectively lead me.
10. I would recommend my direct manager to others.
11. Any comments?
Survey 2: The Manager Survey

This survey goes out to all managers. The first set of questions are the same as for the first survey. The second set are slightly different but substantially similar to the first survey – except that because it’s just people who report directly to me, I can use my name rather than “direct manager”.
1. Cate gives me actionable feedback that helps me improve my performance.
2. Cate supports me in developing my own leadership skills.
3. Cate shares interesting and helpful resources with me to make me a better manager.
4. Cate has the relevant expertise to effectively lead me.
5. Cate does not “micromanage” (i.e. get involved in details that should be handled at other levels).
6. Cate keeps the team focused on our priority results.
7. Cate communicates clear goals for our team.
8. Cate shows consideration for me as a person.
9. Cate has had a meaningful discussion with me about my contributions to this division in the past six months.
10. Cate has had a meaningful discussion with me about my career development in the past six months.
11. I would recommend this org to others.
These fall under the general categories of Development (1-4) / Priorities (5-7) / Appreciation (8-10) / Recommend (11).

My hope is that these topics come up in our 1:1s, but there’s something to be said for stepping back and looking at the overall picture as a series of graphs. It’s hard to get feedback as a manager, and it’s hard to trust the feedback you do get – so this can be a helpful checkpoint.

Now What?

Well… wait.

Next week, I’ll share how I analyse the data and make it actionable.

For now, if you want to use these, I’ve made a shared folder available. Feel free to make a copy and customise them!

See part 2: Analysis.
July 27, 2017
Running an Effective Mobile Team, Part 4: Building Connections

Credit: Max Pixel

Connected: People work together and take an interest in each other (this doesn’t mean everyone has to be friends – but they are friendly).

Problem: We lack a clear model for mobile infrastructure. This leads to discussions like whether to have a mobile team or pods.

Regardless of what your “mobile teams” look like – product pods? A small team that focuses on mobile? Some new configuration that hasn’t been Think Pieced on Medium yet? You have a challenge of connection.

In a dedicated mobile team, how do mobile engineers connect with the engineers working on front end features? Or the engineers developing the API? Was the API written with mobile in mind? Or does it… work on someone else’s machine?

Often the answer to this is to have product pods. Which is great – people have been known to build an API that actually works well for mobile this way. But a good app is not just a collection of features. It’s an architected thing that has components that are shared throughout – some notion of user identity, a networking layer, a database. Ideally it follows some standard patterns that are – gasp – possible to write unit and integration tests for. It’s also going to need to be mindful of memory management – mobile is a constrained experience not just by screen size.

There’s a joke about micro services. It goes:

“I’ve split the application up into seven micro services”
“So you have seven teams that hate each other?”
“How did you know?!”

Now this isn’t a good way to run any team. But there is no micro services architecture for mobile. Regardless of your configuration, people are going to have to – revolutionary idea – talk to each other. When you organise teams to better facilitate some kind of communication, you make the other kind harder.

Since there is no micro services architecture for mobile, there is no way for one team’s architectural decisions not to affect the rest of the people working on mobile. Bonus! We are still evolving our patterns and standards for architecting mobile applications. There’s not currently the concept of a “mobile infrastructure engineer”, and great mobile engineers are usually more product focused. How’s that move to VIPER going? What percentage of your iOS app is now in Swift? How’s that networking layer written 4 years ago or so holding up?

Let me guess: behind schedule / around half / err… not so well.

OK, but we can’t make people like each other, so now what?

Align Incentives

The best way to get two teams to fight is to give them conflicting incentives. Incentivise one team to Ship Maximum Features As Fast As You Can and another team to Maintain Zero Crashes, sit back with the popcorn and watch the show.

If you incentivise one team to move metrics around user engagement and happiness, and another team to maintain sustainable execution… well it will probably be less like robot wars and more like a functional work environment.

Invest in Infrastructure

If your app is badly architected, everyone will pay for that every day. If your networking code is a mess, it will bleed through your entire application. Invest in the things that make everyone more productive and guess what? Everyone will be more productive! These things are often harder to explain to product and business, but every team should have some maintenance time – be strategic about how you use it.

Build a Team

The easiest way to build relationships quickly is to unite against a common enemy. This is a short term strategy and not conducive to long – or medium term – good work environments. Your team is not just the one denoted by the org chart. A team is a group of people who work together to achieve a shared goal. Ignore the org chart for a moment, and think about something you’re trying to achieve. Who is on your team? Who do you need on your team to be successful? Reach out to them.

Read the next part, on automation.

May 4, 2017
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