Accidentally in Code

Tag: management

  • 4 Situations Where Managers Write Code

    P vs NP
    Credit: Flickr / Takashi Hososhima

    The two hardest things about becoming a manager have been: 1) the emotional exhaustion, and 2) letting go of the part of my identity that was tied up in writing code. I accepted that writing code wasn’t the best thing I could do reasonably quickly, but it took longer to finally stop saying I was an “engineer” and instead say “engineering manager” (or “soy manager de ingenieros de sistemas“). I still frequently think that my next job may be back to being an IC.

    But, I do sometimes write code, and I try to be very intentional about when and why. I’ve identified four reasons why managers might.

    1. I miss it and I wanna.

    I understand this, and I feel it. But, it’s a bad reason.

    This doesn’t mean that you never get to write code, but maybe write it on a side project and not the project your team is working on.

    Or maybe it means that you don’t actually want to be a manager anymore, or never did, and you need to change your job rather than inflicting that on your team.

    2. X is important, but not quite important enough.

    There’s something you would like to get into the next release but it’s not more important than anything your team is currently working on. Either you do it, or it’s not going in.

    I did this recently for a feature that had been cut that I thought was triggering too many support issues. It was pretty minor, and I could break it down into small pieces. Mainly I wrote it before my team woke up – and being in another timezone (5 hours ahead of our core timezone) made that much easier. I ended up working really long hours that week though, because I did it on top of all the stuff I normally do.

    I don’t think this is a good thing to do, because the real problem is that your team is overwhelmed. The real problem is that you are cutting stuff this important because there are things that are even more important. This is the situation you want to fix.

    And maybe writing code for this one thing helps achieve that. But maybe – likely – there are better things you could do instead.

    3. Modelling behaviour.

    I have a lot of thoughts about code review, which I will eventually document. At it’s best code review makes the code and everyone writing it better. At it’s worst, code review is a place where passive and not-so-passive aggression plays out under the guise of “technical standards”. If you have an interpersonal problem on your team, there is a good chance it is showing up in code review.

    Writing code as a manager is an opportunity to demonstrate the standards you expect your team to adhere to by adhering to them yourself. Test coverage. The code review process.

    When it comes to code review, giving thoughtful and thorough code reviews yourself is important – and also less time-consuming and more sustainable (I wrote about my desired SLA of looking at every PR once). But creating the odd PR yourself and submitting yourself to that process is a way to illustrate that as a team, code review is a process of give-and-take.

    4. Understanding.

    Your codebase is a product of your systems and processes as much as the people working on it. On approach you can take in order to understand what’s going on – why are there no tests? Why is there so much pushback on this migration? Why do we have so many problems that look like X? – is to go and feel that pain. Especially when there is disagreement about what is wrong and why, the best place to get an unbiased opinion of what is wrong is to go an experience what’s going on for yourself.

    One thing that came up for us was a JSON API migration. I went and wrote some networking code, and came to a much better understanding of what was going on, why that would be hard, and what work we should do ahead of time to make that easier.

    Could I have figured this out another way? Probably. But busy engineers are sometimes happier to pair for a bit and do some code review than to explain.

    Manager TODO List

    As a manager my todo list at a high level is:

    1. Is there a fire? Put it out.
    2. Are there potential fires looming? Do fire prevention.
    3. Make things better.

    Writing code needs to fit into this list. If there’s an interpersonal fire and you’re writing code to “understand” when actually what you should be doing is having a difficult conversation (and I feel not wanting to do that – but pro-tip – it doesn’t get easier), you’re really operating under reason 1 not reason 4. Don’t lie to yourself, or your team – they know.

    But… Does This Mean Managers Need To Be Able To Code?

    Nope.

    Nope. Nope. Nope.

    Let me say that again: No.

    Just because I find coding useful to managing doesn’t mean that it’s necessary for managing. I spent a lot of time learning how to be a good programmer, this is a foundational skill for me. But someone who comes in with a different set of skills will have their own foundational approach and take a different approach that is not necessarily better or worse, just different.

    My experience as an IC was that better managers I had, their technical ability was rarely relevant to me, and that bad managers often hid behind their ability to write code. I did not think that technical skills were that important to being a good manager, and had no idea why they were prized so much – other than the hubris of engineers that leads them to believe and insist that only another engineer can possibly lead or understand them.

    However, since I became a manager I have somehow been more confused and less confused about why people want engineering managers to have technical backgrounds. More confused, because the skills I acquired in spite of being an engineer are in fact more useful. Less confused, because there are certain things – like this one – where having that background is a shortcut, and a likely signal – but far from a given.

    Having a technical background doesn’t mean that you know what good code review looks like, and that you can coach people to do code review well. Having a technical background doesn’t mean that you can ask good questions and figure out what’s going on without having to get in there yourself every time. Hopefully these are skills acquired as an IC. But that is not necessarily true.

    TL;DR

    Being a manager is really hard and of course sometimes writing code seems more appealing. But it’s rarely the right answer.

  • How I Run a Remote Team

    Credit: Pixabay / IraEm
    Credit: Pixabay / IraEm

    Processes:

    • Daily 123 in slack: 1 – what definitely will happen today, 2 – what will hopefully happen, 3 – what I’m filling in the gaps with.
    • Daily standup: this is separate from 123, which I find is a better way to share?what. Standup is a little more about?how.
    • Pairing: this just means “working together on something”*. Talking about the plan before writing code, explaining some piece of non-code work. Screenshare liberally, and often.
    • Weekly build to QA. This is the best way I know to measure concrete progress – what’s in the release notes? What’s better than last week? It’s easy to have a performance of progress, where a lot of code is written but few features are completed and few bugs are fixed. Pushing something out every week mitigates this.

    SLAs:

    • PR-review. My desired SLA is that I look at every PR once. In practise, I fall short of this goal.
    • Every engineer submits a PR every day. It doesn’t have to be big, but if days go by with no PRs it can be a sign that someone is overwhelmed or has a task that should be broken down.
    • Speak to every engineer on the team 1:1, every day. This can be the equivalent of “hi” as you pass each other by in an open office. Or it can lead to a longer conversation.

    Warm and Fuzzy and Hard to Measure

    • Engineers who report to me will give me feedback. On PRs, on planning, on processes.
    • Engineers who report to me will tell me things. This is a sign of trust that they think things will be better for me knowing about them.
    • I can tell if someone is bothered by something and ask the right questions to draw them out.

    As in all things I write about management, there is very little evidence I have any idea what I’m doing. As in all things I write about processes, this is what I aim to live up to.

    * My initial reaction to “let’s pair” was “is this where you watch me code and judge me?” Much gratitude to the engineer on my team who taught me that is not the case.

  • Thankless Emotional Labour as Management Training

    Credit: DeviantArt / MylenaChan
    Credit: DeviantArt / MylenaChan

    My first month as a manager I barely had time to think about how I didn’t really know what I was doing, because there was so much that clearly needed to be done. So I accepted that stuff was not writing code, and got on with it.

    Month two opened, and I kept getting on with things, and I saw activities from Month 1 starting to pay off. I paused and asked myself: “why does it seem like I know what I’m doing?” and the answer I had for myself was… “Oh. Management is Thankless Emotional Labour”.

    Except… my job isn’t thankless anymore. What I do is valued. It’s also strategic – in terms of how we execute as a team, and what we build. Writing – and doing – “Emotional Labour” without the thankless prefix is something I need to adjust to.

    So, three ways in which management is like “thankless emotional labour”: 1) work for the collective, 2) being an emotional thermometer, 3) technical work becomes mentoring and grunt work.

    1. Work for the Collective

    Work for the collective is stuff that benefits the “team” not the individual. It’s one of those things that women tend to be dinged for not doing, rather than appreciated when they do [see: Women Don’t Ask – Amazon].

    Hiring is a good example. In the last 3 months I’ve worked on designing a hiring process, done countless phone screens, coached engineers on interviewing (we open sourced our prep guide!) etc. I actively worked on finding underrepresented people in tech, including offering anyone underrepresented in tech working on mobile a call about anything they wanted in February (my boss offered his time too, which was super kind). I met some great people this way and hope I was able to be helpful.

    The result: one of the engineers on my team observed that hiring a new engineer had seemed painless. As I looked at him, remembering the day I did six interviews in one day, he followed up with “or maybe you just made it seem that way.”

    I did. Because that’s my job, now.

    2. Emotional Thermometer

    Many women I know spend a lot of time thinking about and worrying about the emotions of the men around them. We’re conditioned to do it, men have come to expect it, and at darker moments it’s a way that we manage risk. It’s best captured by that quote from Margaret Atwood, “Men are afraid that women will laugh at them. Women are afraid that men will kill them.”

    At The Conglomerate, we did this personality test involving colors, and you have a primary and a secondary. Green: over-think (and engineer) things. Yellow: organize things. Orange: ship things. Blue: emote.

    I like to describe blue as “baseline human decency” but another good description is “emotional thermometer”. It’s about only being as happy as the people around you are.

    Most people at The Conglomerate are green or orange. I’m yellow with orange undertones. Which is fine, I know I value an organized way of getting things done. What I didn’t know was how weird that was. As a result, what I got most out of this exercise was a new understanding of how people judge or assume other people’s colors. People seemed to see organization, process, as a distraction rather than an enabler. When I listened to how people saw blue I was reminded of a weird and conversation I’d had with a manager I’d had, that had made me feel deeply uncomfortable. And I realised, he thought I was blue.

    One of my friends observed that it’s probably pretty common for women to be assumed to be blue. To be assumed that their first priority is everyone else’s feelings rather than what they personally value. We often force women to do an impression of that, with a feedback loop where the consequences of not doing that are unpredictable but potentially extreme.

    But as a manager, being tuned into the emotional temperature of your team is a strength. If you discover someone’s unhappy because you noticed something was up, and gave them space to tell you, you have better, more immediate information than if you wait for the point where they seek you out.

    As much as I deeply, deeply resent “prove it again” on technical matters I’m willing to prove to my team week in week out that I’m worth trusting. It seems to me that a manager is only as good as their worst screw up. Paying attention to how they feel doesn’t seem like a bad place to start.

    3. Technical Work Becomes Mentoring and Grunt work.

    As things have calmed down, I have been able to carve out some time to do some technical work. This falls into the categories of mentoring, and grunt work.

    Mentoring: helping someone else do their technical work. Helping understand and implement a pattern we’re adopting to improve our testing, or giving feedback in code review. The easiest way for one of my team to make my day is to ask me a technical question. Even if it’s something like “how do I fix this test?”

    Grunt work: something needs to be done, but not immediately, and it’s not very interesting. Infrastructure stuff, clean up, (small) refactorings.

    Both of these things are often unappreciated when done by engineers, especially women, because of the way work done by women is always devalued. Mentoring because of the same reasons as work for the collective, grunt work because it’s “not important” or “lacks impact”.

    Actually, the most useful thing that I’ve built when I’ve spent time on technical stuff is not lines of code – it’s understanding of the processes followed on the team.

    Thankless Emotional Labour Bootcamp

    You can learn how to run a functional 1:1. You can learn how to perform empathy. You can learn how to demonstrate listening. But actually tuning into all these things is far less easy to define. Luckily for me (and my team), I spent most of my time in industry being forced to.

    Before I had the realisation that management was emotional labour, after a day of doing it, I would message one of my friends and say “this is what I did today, how do I know if it’s enough?” I felt I had not created anything of value. As I approach the end of Month 3, I don’t feel like that any more. Partly because I have seen stuff start to pay off, but also because I have accepted that is what the job is.

    This realisation, by the way, also explained why women move / get pushed into management. It was one of those things that I intellectually knew, but now… feel like I understand.

    But the question I leave you with – if this stuff is valuable when done by managers, why isn’t it valuable when done by engineers?

    I think it is valuable, but I also think that more of this stuff falls on engineers when managers aren’t doing it themselves. As a manager what you do, and what you reward, communicates what you value. So if you don’t do this stuff, or you do it badly, it’s very clear to your team that this is not valued, so when others do it, even when they benefit from it, they are unlikely to value it either.

    Thanks so much to my friend Lara for listening when I felt like I had achieved nothing, and for reviewing and giving feedback on this post.

  • The Hardest, Shortest, Lesson Becoming a Manager

    "how does computer programming work" "magic"
    Credit: Abstruce Goose

    There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. Today I wrote X lines of code. Today I deleted Y lines of code. Today I implemented feature Z. Concrete achievements are reassuring. Today I left the codebase better than I found it. Good job.

    I too found this a really really difficult thing to let go of. I looked at tempting tasks. A nice feature. A refactoring. And I did not do them. The thing that I have found that helps is framing it as now coding is not the most important thing that I do. But then I get to the end of a day where I did not code, and I ask, how do I know I achieved anything today?

    Get Real About Your Schedule

    This week is a short one, but still – there was a point in it where I was triple booked. I honestly have no idea how I would cope right now if I didn’t have admin help. Ariel rules my schedule. I just look at it and panic.

    Even when I have open time, it’s like 2/3 of a day, half a day. If I have 2/3 as much time of the week that isn’t spoken for by meetings as I did when I was an IC, that doesn’t mean I can write 2/3 as much code. For starters when you code in bits and pieces you spend a lot more time rebasing. Secondly, transition between strategic (what are we doing), coaching (how can I help you) and details (what does this bit of code do) are difficult context switches. And switching in and out of details is the hardest of all.

    When a 1:1 starts with someone sharing technical details with me for ~10 minutes it’s my job to help lift them out of those details so we can work on strategy or coaching. That transition is hard. In both directions. I see it being hard on them, and of course it is also hard for me.

    I had a manager once who decided he would take on an important component in the app I was tech lead of. He did a half-assed job of it, and it took him ages. In the end, it was a really challenging piece, it ended up being rewritten 3x (2x by me) before we got it to a point where it performed well. How do you tell your manager that they are your #1 risk factor for missing your deadline? How do you tell them they did a bad job and the thing they made doesn’t work?

    I forget how I dealt with that – I think I procrastinated on dealing with it and eventually just picked it up and started improving it. I don’t in general believe we learn that much from what not to do, but I won’t inflict that on my team. If I’m trying to write code now, it’s something that me being slow to complete shouldn’t be blocking anyone. Cleanup tasks are a good place to start.

    What Makes the Team Better

    The truth that all managers must accept is that your job is now to make a group of people more effective, over a longer period than you usually consider as an IC. Even if you are genuinely the best and most effective person to take something on, does this make your team more effective 3 months from now? Unlikely. Instead of investing in someone else having context now, you’re postponing that moment to later, or indefinitely.

    And then they will have a fun time untangling your code and it would be great if you were there to talk to, but you’re in a meeting, again.

    The sooner you invest the time in coaching people on what you know that they should know the better it will be.

    One of my first weeks on the job there was a component that is pretty complex, that I have now built twice. Last time it took me ~1.5 days. I really just wanted to write this code, show everyone that I’m a good engineer, and have that win. But after sleeping on it, I took a deep breath, looked at my schedule, and encouraged someone else to do it instead. Would I have done it faster? Honestly considering my schedule, probably not. And now the person who did write the code is in a good position to own that component going forward.

    Does Your Team Need A Manager… or Another Engineer?

    As a manager I have this mental list of things about what does my team need. Things that I’m monitoring, things that I’m trying to fix, things that I’m trying to find for them. It’s my job to understand what is going on and what the team as a whole needs to be effective.

    Maybe you can look at the state of things and say, we have a deadline right now, and what we need is another engineer for the next month. That engineer is me.

    But more likely you look at the state of things and realize that what your team needs is a manager. Because you need to hire X more people. Because Y has a lot of potential but needs some coaching. Because product or design or some other team haven’t given you what you need so you need to go and get it. Because process is important, and the process you have is insufficient or just plain wrong.

    If you team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide if you’re going to suck at one which one that will be.

    I feel bad when I suck at being an engineer, but sucking at being a manager would be a choice I inflicted on other people. That’s not fair.

    So at the end of another day when I feel like I didn’t write enough code and I have no way to quantify what I’ve achieved, I tell myself I was being as good a manager as I know how to be. And that has to be enough for today.

  • New Manager Resources

    Danbo has fallen love with cute kitty
    Credit: Flickr / Takashi Hososhima

    A collection of some of the things I’ve found most helpful for becoming a manager.

    On 1:1s

    Two things that are most immediately helpful, especially in answering the questions: what does a manager do? How do I run 1:1s?

    @Geek_Manager gave a talk about what it means to be a manager [video]. I found it really helpful because I think we are much more aware of what bad managers do than what good managers do.

    Meri refers to some coaching stuff and a way of running 1:1s. There’s more detail on that in this talk [video] – it’s about how to help people come to their own conclusions about what they are doing.

    On Being a Manager

    @Skamille wrote about about taking the manager track [blog post]. I found it super helpful in terms of coming to terms with the trade offs, and why one might choose one over the other.

    @marcprecipice wrote this piece called “what do you make as a manager?” [blog post]. It’s something that I think about as I reconcile myself to coding not being the most important / impactful thing that I do.

    @ellenchisa wrote something about giving feedback which I think is really helpful [blog post]. The key thing I took away from it is that you build a relationship where you can give people feedback.

    On Avoiding Organisational Dysfunction

    Slack [my review] – this was an illuminating book explained why things that seemed wrong to me were harmful.

    Leadership and Self Deception [amazon] – this book made me fundamentally reconsider how humans interact with one another.

    On Decision Making and Meetings

    High Output Management [amazon] – I’m reading this right now, and the stuff on decision making and meetings and how to run them effectively is gold. The other thing that I am getting out of it is he takes a very broad view of what management is, and ties the skills from things that are less obviously being a people manager to having direct reports.