Tag: management

  • 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.

     

  • Things to Figure Out as a New Manager: Part 1, Your Schedule

    danbo stands looking at the "geek calendar"
    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.

  • 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.

  • On 1:1s

    a wooden figure towers over danbo, danbo leans backwards, appears intimidated
    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.

  • New(-ish) Eng-Managers Slack

    Credit: Pixabay / IraEm
    Credit: Pixabay / IraEm

    For 8 months, from the start of December to the start of August, I was a manager. This was in many ways incredibly rewarding – now that I’m no longer a manager my favourite thing is being friends with the people who used to report to me. But it was also at times crushingly lonely. Especially when I was the only engineering manager other than my boss (who managed everyone else), at a struggling startup.

    In June, I finally had time to go and take management training (I took this course, run by my friend Meri as part of The Lead Dev event), and one of the things I talked to Meri about was wanting peers. I’m really fortunate in that if you made a list of who you would want to mentor you as a new manager, you’d probably be making a list of some of my closest friends. But, sometimes you don’t want to talk to someone who has been there and seen that, you want someone else who is also a bit lost.

    Turns out, it wasn’t just me who felt like that. So Meri introduced a bunch of us, and we ended up in a Slack team together. Once I was embracing funemployment, I had the time and the headspace admin it better, so I tweeted about it, and turns out – a lot of people were looking for this. For days, my DM’s were full of people requesting invitations. Thanks to my fellow admins @steve_codes , who set up our GitHub site, which is a very lightly edited fork of the amazing site @zenparty put together for the Women in Tech Slack, and @lenazun who has been organising our first meetup – in SF this week.

    It’s a lot of work to create and sustain a healthy community, and this is just the beginning. But I think that funemployment is a great time to create the things you wish you’d had when you had a job – and I really wish that I’d had this.

  • Worthless Intent

    danbo appears to be moderating an argument between two lego characters
    Credit: Flickr / Adriane Dizon

    One of the things that I write about in my lessons learned from 6 months of managing blogpost was about my realisation that intentions do actually matter.

    “I’ve long found discussion of “intentions” completely worthless. I just don’t want to hear about it. Especially in the context that it invariably is – men who tell me about their intentions after screwing things up. I still don’t think there is much value in discussing intentions. But intentions are actually the place where your actions come from, and that is important. It’s not what you do, but how you do it. And regardless of what is said about intentions, people always know what your intentions really are. For example feedback can be given from a place of “this will make my life easier” or from a place of “this is how I believe you can be more effective” – which one do you think is better taken?”

    But I still find discussion of intentions worthless. And the reason why has everything to do with conflict resolution.

    This was a big gap for me – I had seen very little constructive conflict resolution in a professional context. At the conglomerate it often felt like there was the assumption that if everyone was smart and well intentioned their would be no conflict, so when conflict arose it felt like you were expected to just be smarter and have better intentions. And then of course the “best” intentions win out, where “best” is often what best re-enforces this collective self image of smart, well intentioned people.

    The thing is, the intellect and intentions of people around you have nothing to do with whether or not there will be conflict. Conflict arises when people disagree. So when people think and want different things, there’s conflict. When not everyone can have an outcome that works for them, that conflict can be particularly vicious. Regardless of how smart they are. Regardless of their intentions.

    The thing about intentions is that they are the start of conflict resolution, but we often talk like they are the end of conflict resolution. This is completely wrong. Believing that someone means well might get you to the table to talk to them, but it does not get you to agree with them.

    We see some very circular arguments on the internet sometimes, and often one person is talking about intent and the other is talking about action and outcomes. The person talking about intent often responds very badly to this, but the thing is their intent is either irrelevant or accepted – and that is why they are getting a response at all.

    I still don’t know much about conflict resolution, but one thing I’ve realised is that you have to get people to start talking about the same thing. The intentions of two (or more!) different people are never going to be the same thing.

    In the talk I gave (twice now) about burnout one story I tell is about an awful manager who – amongst other things – told me that he thought by never giving me positive feedback he was training me not to need any. I quip “this did not work, by the way” and a room full of people laugh because it’s so obviously stupid, so obviously wouldn’t work.

    But here’s the thing: he told me that with this ernest expression on his face. He truly believed it. He truly thought that he was helping me be a better developer, a better human being.

    But his intentions are worthless next to the harm that management technique (and non-techniques) and countless others did not just to my emotional well being, and my career, and (I think to a lesser extent) the careers of other women (and men) who reported to him. That manager did more than anyone else to drive me to want to leave tech.

    So do I care about his intentions? For a while maybe, they got me to keep showing up to work, to 1:1s and trying to deal with him. But that only went so far. There came a point when – No. Having some distance – No. His actions outweighed his intentions by a factor of 100:1. His intentions don’t make me feel like I should forgive him; I don’t think we are obliged to forgive everyone who harms us. Accept, because accepting the past is how we move on. But forgive – No.

    We state our intentions – I have done, do this too – because we want to be seen as “good”. Because it matters to us that people know that whatever disconnect arose was not deliberate, on our part. Okay. But if you want to resolve a conflict – or right a wrong – you can’t end there. You haven’t even started. It’s just the beginning.

  • Creative Coding Podcast

    I was on another podcast! This time, creative coding with @seb_ly [listen].

    We talked about managing coders, color theory, side projects, lasers, being homeless, interviewing (and applied humaning). It was really fun (but cold!) to record, and I hope you enjoy it.

  • 6 Months. 6 Lessons.

    Danbo likes to learn
    Credit: Flickr / Kai Lehmann

    Last week marked my six-month anniversary at Ride, which also marks six months of being a manager. It coincided with my team being in Medellin all together for our offsite. It was amazing to have everyone here, and this was part of something I have been thinking about since I started this job – how do we become not just an iOS team, and an Android team, but one mobile team? The offsite was the final step in that process.

    Back in December I shared some resources that I had been finding helpful. One of them was a post by @marcprecipice called “what do you make as a manager?” in which he talks about the impact you have over the long term and the relationships you build.

    But the question “What do you make as a manager?” is one that I have asked myself a lot. Maybe, if you’re lucky, if you have a good boss yourself, and a good environment, and some amazing people, you get to build a team. Maybe you get to have a milestone, like this one, where they see, and you see, what’s changed. Maybe they change the way they talk about the team, maybe you make a new slack channel, maybe one of them looks at you and says, “you’ve built a good team”.

    That was my week, anyway. And it was the best way I can imagine to mark six months.

    But if that’s my biggest achievement of the last six months, what have I learned?

    1. Intentions Do Matter

    I’ve long found discussion of “intentions” completely worthless. I just don’t want to hear about it. Especially in the context that it invariably is – men who tell me about their intentions after screwing things up. I still don’t think there is much value in discussing intentions. But intentions are actually the place where your actions come from, and that is important. It’s not what you do, but how you do it. And regardless of what is said about intentions, people always know what your intentions really are. For example feedback can be given from a place of “this will make my life easier” or from a place of “this is how I believe you can be more effective” – which one do you think is better taken?

    One of the engineers started talking about my intentions and I cut him off to tell him intentions are worthless. But he stopped me and finished what he was saying, telling me that “no-one can doubt that you care about us”. Which is not something I really talk about that much. But it is something I show up and do, every day.

    2. There’s a Difference Between Honesty and Openness.

    This is the loneliest thing sometimes. Where I never, I would never, lie to my team, I find myself not always being able to be open. Change the topic. Give a less than satisfying answer. Redirect the question. Often part of my job (especially at a startup!) is to take uncertainty and turn it into direction, which means you don’t relay every thought in your head about the uncertainty but focus on the direction, and the outcomes you think will be helpful.

    On the flip side, if you are a new manager your team knows that and you don’t need to pretend you have all the answers. They’ll be pretty confident you don’t. You may as well admit what you know you don’t know, or find hard, because it’s probably pretty obvious to them. There’s something that I realised I wasn’t doing well a few months ago, and I’ve been working on it ever since. An engineer commented how much he appreciated that I had been doing better at that, because he knew it was work for me.

    I doubt he would have been quite that positive if I had just kept being bad at it, or pretended it wasn’t an issue.

    3. Time Spent Understanding People is Never Wasted.

    I do bi-weekly 1-hour 1:1s, and make an effort to spend quality 1:1 time with engineers who report to me when we are in the same place. If your team is a system, the people who report to you are components, and the better you understand how they work in general the more sense their behaviour will make in times of stress.

    When you join a team, things are the way they are for a reason. There’s a hubristic approach that says things sucked because you weren’t there yet – and it’s wrong. Things are the way they are because of the people, because of the structure of the organisation, because of the constraints people are working under.

    Structure can be both explicit and implicit, and hard to figure out. Constraints can be stated and unstated. People, if you are kind, and patient, and accepting, will mostly just be who they are, because anything else is too much work. If you get to know who people are, then a lot of things will make sense. And, they’ll probably explain to you their realities of the structure and the constraints, too.

    But understanding goes both ways and there are things people won’t always ask you. I think people often talk about their Achievements and Experiences to explain who they are, but I’m much more interested in the how and why of making decisions. It tells me a lot more about how people think, and what they value. So I’ll ask people about why they think a decision is the right one, and I’ll also explain my decision making process in return. I feel like I’m winning when engineers on my team can predict decisions I make, even when they would make a different one.

    4. Questions are Better than Answers.

    If you tell people things, they may or may not believe you. If you ask them good questions and get them to see the world in a different way, they are much more likely to adjust what they are doing.

    This is something I continually work at, because I’m always tempted to just give the answer – it’s more efficient! And I’ve been trained by Prove It Again to always, y’know, want to Prove that I Know What I’m Talking About. But – asking good questions is so much more effective.

    I asked one of the engineers how often I gave him advice and he said “constantly”. I responded, “wow! I’ve really been trying to ask questions instead.” He told me that he took asking questions as a form of advice giving. So I guess this strategy is very transparent. But still – effective.

    5. The Worst Mistakes Are The Ones You Don’t See Coming.

    Three months in, I posited the theory that a manager is only as good as their worst screw up – and I still think this is true – but depending on the severity you can use it to make your relationship stronger. You can apologise. Talk about what happened. Be accountable for your actions.

    If you learn the way in which you will make mistakes, you can look out for them. For me a big one is that I care too much – largely the result of having terrible managers and being so determined to be a good manager myself, and so afraid that I don’t know how to be. Which sounds like a humble brag. Like “oh I will only screw up because I care too much and try so hard” but the fact is fucking up is fucking up. It might come from a “good” place, but that only goes so far. And frankly, any place where you are lacking self-awareness to the point where it impacts your team isn’t all that good.

    The worst mistakes you make are the ones you won’t see coming – it won’t be the thing you know you are bad at (unless you hide from it and refuse to take responsibility), so it’s all the more likely that your worst screw ups will come from a place of “good intentions”. Now that I know that caring too much is how I will make my biggest mistakes I will be more intentional about spotting them before I inflict them on my team.

    6. Build a Shared Language.

    This was something that we worked on a lot at the offsite, on building commonalities across platforms and as a team. We worked through a discussion based on the book Leadership and Self Deception (Amazon) and now we have this shorthand where someone will say “that will put me in the box” and everyone knows what they mean.

    But what was cool was how much of a shared language we already had. Much of our weekly schedule is oriented around cutting the build every Thursday. Both teams were doing what we call “123” in Slack (I wrote about some processes for running a remote team). Both platform teams had similar rhythms, similar challenges, similar frustrations. When we came together, it was pretty straightforward to talk about them.

    Bonus Lesson: Recharging

    The bonus lesson is what we all know: being a manager is a different job. But that doesn’t just change what I show up and do at my job, but also outside of it. It’s changed the kind of work I want to do on side projects; I’m writing code on my side-project in a way that I was never able to sustain as an IC. I need more alone time to recharge, and I’m much less excited about the prospect of giving talks, because giving talks are about other people, in the same way that my job is about other people, and I want to recharge by doing things that are for me.

    6 Months Down. ??? To Go.

    The learning curve and emotional exhaustion of being a manager has been really steep. Whenever I think about my next job, I think there’s a good chance that I’ll go back to being an IC. But I’m so grateful to have had this opportunity and whilst I have my current job I’ll keep trying to learn and do better.

    And to go back to the question of “what does a manager make?” if you’re not continually reflecting and trying to do better, you’ll probably make a big mess.

    But if you’re lucky – as I was – and thoughtful. Maybe you’ll get to make a team.

    Thanks and love to my team, because they are kind, smart, hard-working, hilarious and adorable, and because every day I work with them I learn something.

  • Book: First Break All The Rules

    First Break All The RulesI spend a lot of time obsessing about: 1) how to be a good manager, and 2) how to have any idea if I am doing a good job. So I was happy to discover First Break All The Rules (Amazon), because it contains (data driven!) information on how to be a good manager, and also a list of questions which – if you’re doing a good job – the people who report to you will be able to answer a resounding “yes” to.

    Treat people as individuals. Focus on strengths. Don’t fix people, fix situations. Focus on outcomes not process. 

    When I became a manager one of the things that I had – and continue to have – a lot of anxiety about is that I didn’t feel like I had a good model of what a good manager looked like, and I was really wary to learn from bad managers, because I don’t think that teaches you very much (this sentiment is echoed in the book). So for me the biggest and most useful takeaway is that a great manager can look any number of ways, but the people who report to her will be able to answer “yes” enthusiastically and confidently to all these questions.

    1. Do I know what is expected of me at work?
    2. Do I have the equipment and material I need to do my work right?
    3. At work, do I have the opportunity to do what I do best every day?
    4. In the last seven days, have I received recognition or praise for good work?
    5. Does my supervisor or someone at work seem to care about me as a person?
    6. Is there someone at work who encourages my development?
    7. At work, do my opinions seem to count?
    8. Does the mission/purpose of my company make me feel my work is important?
    9. Are my co-workers committed to doing quality work?
    10. Do I have a best friend at work?
    11. In the last six months, have I talked to someone about my progress?
    12. This last year, have I had opportunities at work to learn and grow?

    Note – the first 6 are foundational, and to address the second 6 without the foundation of the first 6 is like building a house on sand.

    The book is a little dated in places, but I’ve found it a really worthwhile read and I’ve got a lot out of it. If you’re a manager at any stage, I highly recommend reading it (I wish some of my managers had read it!). And in my 1:1s over the next little while, I’m going through this list with the individuals who report to me and figuring out the places where I can do better.