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.
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?
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.
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.
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.
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.
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.
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.
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.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
