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.
“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.
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.
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.
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.
I 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.
Do I know what is expected of me at work?
Do I have the equipment and material I need to do my work right?
At work, do I have the opportunity to do what I do best every day?
In the last seven days, have I received recognition or praise for good work?
Does my supervisor or someone at work seem to care about me as a person?
Is there someone at work who encourages my development?
At work, do my opinions seem to count?
Does the mission/purpose of my company make me feel my work is important?
Are my co-workers committed to doing quality work?
Do I have a best friend at work?
In the last six months, have I talked to someone about my progress?
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.
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:
Is there a fire? Put it out.
Are there potential fires looming? Do fire prevention.
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.
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.
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.
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.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
