This is a presentation I’ve done now about six times, starting back about 6 years ago. It stemmed from seeing people new to being a tech-lead on a team (either as manager or not) and what were the common pitfalls they fell into. So without further ado, the talk.

Hi and welcome to the non-technical guide to technical leadership!

One preface here before we start, I refer to the role of tech lead (or TL) often in this talk, but to be clear, the tech lead is a role, not a title. You may be an engineer, or a manager. Basically, any project which you are responsible for driving technical decisions on, you are the TL.

I say non-technical in the title because most of the issues I’ve seen with tech leaders is rarely the technical part. If you’re teach leading a project, you very more than likely have the technical chops required to do the job, or at least have the resources available to you to figure it out. However, the leadership part is where I’ve seen many run into trouble.

So good news! You’ve been made a technical lead! Bad news! You’ve been made a technical lead! Often when people are made TLs, they’re not given much guidance or training. And so you’re left figuring it out on your own. If you enter management, often there’s management training (of varying quality), but if you don’t enter management, well… I find wisdom much cheaper when acquired second hand, and so I figured to give TLs and future TLs some things you need to know, and concrete things you can do to make it easier. And from what I’ve seen, much of management training I’ve seen doesn’t cover the stuff I’m going to anyway.

There are some things I’ll talk about here, that you may not run into much where you are today, but odds are, you’ll work someplace else before your career is over, and it’s not all that unlikely that you’ll wind up having to deal with it there. Some of what I will say may seem obvious, but I’ve seen enough stuff done wrong that I cover it anyway.

Now, the #1 thing that makes leadership challenging is simply this: People are broken. And by this, I don’t necessarily mean that other people are broken. We have baggage, fears, biases, insecurities, conditioned responses, neuroses, and so on that can drive us to think, argue and behave irrationally – and yes us, being technical people, you’d think of any population we’d be the ones who are rational and logical. News flash: we’re not. Other people aren’t either.

We have funny mental play buttons where funny, weird or sometimes bad things happen when we press the wrong one. One funny one from my own experience: I keep my car keys and my id badge in the same pocket of my computer bag. One day, I’m approaching the building, I reach in my bag and for some reason grab the car keys, and there I am clicking the button on the fob, and I’m like “why brain?!”

We forget things we wanted to remember; we remember things we want to forget. We miscommunicate, we misunderstand, we piss each other off, we make mistakes. We have buttons that can get pressed by other people; hopefully, it’s by accident, but you may wind up working with bad people who will try to manipulate you by pressing those very buttons.

Another problem I see is that people tend to think themselves smarter than they are. That is: we’re really smart in this one area, tech, and often it makes us think we’re smarter in other places too. The problem is: this isn’t as true as we’d like to think. Not only that, but our wisdom and intelligence curves are not some smooth zero-slope line across the axes of time and subject matter. Rather the curve is very lumpy. Like up here, I’m Brilliant! Over here, there’s a bag of doorknobs that is smarter than I.

Case in point: I used to own a Kcup brewer that had all of 3 buttons on it. And one morning, it took three tries to hit the right button to get the coffee to brew.

There’s a great book I read which I recommend, called “The Intelligence Trap” subtitled “why smart people do stupid things” Well worth the read.

Now why do I go through all this telling you that people are broken? First, it’s to encourage you to just be patient with other people. Second, it encourages humility and patience with yourself. Third, broken people are the ingredients we have to work with in delivering our projects.

On that note, there are some things that I’m going to say you should do, and I know I don’t do them as I ought to. So part of my brokenness is that I know what the right thing to do is and don’t do it.

Ok, so with that in place, what are some things to deal with common people brokenness things? Part of people being broken is we forget things. When you’re coding by yourself, it’s not unreasonable to be able to keep everything in your head. When you’re a leader, you now have to keep track of people other than you. If you try to keep it all in your head, unless you have an eidetic memory, two bad things will happen: 1) you won’t remember everything and 2) you’ll know you forgot something, and that never feels good.

You need an organization system. There’s a book call Getting Things Done By David Allen which I think is a great framework, as it’s based on principles rather than a given implementation. So you can explore and discover an implementation of it that works for you. I’ve written about the topic of organization systems a lot on my blog and have many thinks on the subject, but the main thing is balancing utility with complexity no matter what form your system takes. I find the whole organization system thing an interesting topic, so if you want to chat on that, let me know.

Something to note is that organization systems are by their nature, one size fits one, and for a particular season of your life. There are so many variables that affect what “works for you”. While you might use someone else’s setup to get started, don’t handcuff yourself to it, but rather tweak it until it works better for you.

A good system can allow you to juggle more things – without one, you’ll constrain the amount of concurrent work you take on. If you have one, you can get more done and with less stress because you won’t be worried you forgot something. A good system can become your superpower. For example, here’s a piece of feedback I got that’s representative of feedback I’ve gotten over my career:

Any system you use will have to be able to deal with entropy. The layout of it will evolve over time because your needs will change, and it will get messy – and you’ll need a way to do garbage collection on it that won’t make you hate life. You’ll want to also plan for the time to garbage collect. Hmm… if only there was a place to put that…

Ultimately, you’ll want a system that can capture stuff easily – if it never makes it into your system, consider it lost. If it’s too inconvenient to capture, you won’t. You’ll want a place to brainstorm on things, a place to have references to docs, links, etc. You need to be able to use it to plan. You can use it to keep track of what you did (think performance reviews or keeping a brag doc up to date – you have one, right?), what other people did (again perf reviews!) but it also has to be convenient enough to use. If it’s perfect, but a pain to use, you won’t use it, and by definition is not perfect.

As a TL, keeping track of Done is super important. It can be where you wrote down decisions you made, People you spoke to, etc. And this is even more important if you’re new to being a TL. As a regular IC, getting stuff done usually results in some fairly obvious artifacts of code or a design document, or what have you. As a TL, you have to measure your productivity differently – those meetings, code reviews, design document reviews, time spent thinking about some project you’re on, planning, that all counts as work. Your productivity is no longer measured in lines of code. Done will help you see that on the days where it feels you’ve just been running around all day and are like “I didn’t get anything done”.

But overall, if there’s a line I can jam in your head, it’s this: treat your memory as lossy. Because it is.

Speaking of meetings, another larger part of your job as a TL will be

Pro-tip: for meetings, when you can, leave the laptop closed, or only one window covering the whole screen. It’s way too easy to be in the middle of a meeting and a slack notification pops up. Especially if it’s not a two-person meeting. 5 minutes pass and you’re basically coming up for air after having tuned out after having gone down the rabbit hole and hear your name and have no idea what’s been going on. But what about meeting notes, new todos, etc.? Good question! And the answer is: I’m a fan of paper input. If your organizer is in dead tree form, no problem. For a computer based one, try to set it up so you can’t see slack or email notifications. However, the upside of handwritten notes, is that science tells us that we retain things better when we hand write notes than when we type them. When I was in school, I always took notes, but never looked at them. At one point I asked, “why am I doing this if I never look at them?”. So I stopped and my grades went down. I learned to take notes even if I never looked at them.

But getting back to communication…

When communicating, there are three main communication directions, up, down, and across.

When communicating towards your team, talk to them more often than you think you need to. There’s usually more going on than you think. Ask them about their complaints, even if they’re about you, feedback is a gift and shows they trust you not to be stupid with it. People don’t often get a venue to gripe about things. Some things you can fix. Some things you can’t. Sometimes, they just need a place to vent, and you can give that to them. It also is a chance to build trust with them. Also make sure to tell them when everything is going well. Don’t assume they know. Impostor syndrome is a real thing, especially at companies like this one. And if they’re not hearing that feedback, that’s not good. Some people need more feedback than others. With some, if you give too much positive feedback, they’ll get annoyed. You’ll have to figure that one out.

All that said, unless context dictates otherwise, assume what they tells you goes no further. Specifically, anything that would make them vulnerable. Done well, they’ll tell you things they don’t tell other people. Downside, every once in a blue moon, they’ll tell you something you really wish they didn’t, but if your default is to keep your trap shut about it, all will be well.

When communicating across to your peer TLs, you may find that there are common problems – technical or people issues – and working together, you may be able to productively make progress on those issues. Also, if you’re working in a nearby area, it can be nice to have the heads up that things will be happening – avoiding surprises is good.

Now, at any job, there is a set of people you ultimately need to keep happy. This set always includes your manager, and may include your manager’s manager. Main tips here are: Find out how to partner with your EM (and or PM) – what do they think is important? When you see things that need to be done, it’s very useful to sell it in terms that they care about. They have a set of things that’s different than yours, that they need to deal with, and knowing the coordinate space by which they evaluate things can be really helpful in deciding how best to pitch an idea. It may be super important to you that work item X solves Y, your manager may not care because they don’t care so much about Y, but Z. You may not agree that Z is important, but in the scheme of things, that usually doesn’t matter as you generally won’t have visibility into all the things your manager does.

Getting foundational agreement as to direction is also really helpful. You may disagree over the particular approach to get there, but if you don’t have fundamental agreement on things, conflict is nearly guaranteed. But get fundamental agreement on things, and negotiate the path from there. I’ve found that being on the same page with my manager isn’t magic, it’s mostly just listening. When negotiating things with your EM/PM, try to offer some choices whether it be priority, or features, or whatever. With explicit choices, negotiation goes better.

Also, remember your EM has advancement goals of their own. Find out what they want to do and see how you can help. Teamwork here goes a long way for the both of you.

I’m a big fan of the root/leaves way of analyzing disagreements. When you have disagreements with people, try to understand if there’s an underlying root disagreement that gives rise to the disagreement you’re having. Addressing the root issue makes many of the “leaf” issues that will spawn from that go away.

When it comes to communication generally, there are some guidelines that I’ve found work well in making things go smoothly. Assume anything that has been miscommunicated/misunderstood from you is your fault. This alone will save many arguments. Because it’s almost always true. As the communicator, it’s incumbent on you to ensure you’re understood.

Try to be good about finding appropriate metaphors. This is key when relating to people outside your domain to explain what you’re doing. If you’re “encroaching” into someone else’s domain, make the attempt to learn their jargon.

Text communication (slack, email) can often be interpreted more negatively than the writer intends – I presume it’s because of the other signals of voice timbre and facial expressions that aren’t there – If in doubt, add an emoji indicating happiness of some sort. It might sound dumb, but humans are weird like that.

If you’re working with people in a different office, arrange to meet them in person from time to time. For some reason, I’ve noticed that people treat people they’ve only ever seen on VC differently in that people they’ve met in person. Again, people are weird.

When trying to persuade someone to do something for you, give them choices when it’s practical. It’s empowering. People like agency. Sometimes, being able to make a choice will prime the pump and they’ll come up with alternative ideas you wouldn’t have thought of. But don’t be stupid and give them a false choice – assume you don’t work with idiots.

If you’re in leadership long enough, especially if you go to management, there are hard conversations you’ll need to have. Don’t avoid them. Not having them is always worse. If you don’t know how to have them, look into the SBIR framework. I’ve used it on a number of occasions, and one that was the hardest feedback I’ve ever had to give and they thanked me, twice – once after the initial read, and another a day later after they had more time to absorb it.

Maintaining confidence effectively sometimes can be a real challenge. Most times, it’s just STFU and all is fine. But this can be especially hard when it affects decisions you have to make, or planning, or other things, where visibility is a problem – that is, it will look odd to people not in the know as it’s an unseen force acting upon you. So not only can’t you tell what you know, but you have to proceed as if there’s nothing to know in the first place. Some examples are if you know the company is going to be acquired, or layoffs are coming, someone is planning to leave, someone is going to be let go, etc. What do you say? The information doesn’t belong to you, so isn’t yours to share. You have a few options: You can say screw it and betray the confidence – I don’t recommend this. You can lie – I don’t recommend this either. So pretty much your choice is to obfuscate. I admit I don’t like obfuscating either, but I’ve not found any other way that isn’t lying or betrayal – either of which is decidedly worse.

Obfuscating well requires some forethought, so I don’t recommend trying to wing it. After getting the info, you want to spend a little time thinking about what you plan to do if you get asked. [pause] The trick in obfuscation is to say something true, but incomplete in a way which doesn’t betray that there’s something to know – because there are times where even knowing there’s something to know is all the hearer needs to know to figure out the rest. Like if someone asks you if a friend is throwing a surprise party for them, and they are. I’ve heard this technique described as strategic ambiguity. What I mean is that there are some times where saying you “can’t talk about it” in response to a question it is itself letting the cat out of the bag. I’ve acquired a few phrases and themes for cases like these, which I would share, but then they wouldn’t work any more.

Ok, that was a little vague. Let me give you an example. You have a team member who’s leaving, but hasn’t publicly disclosed this, and it’s planning time. People on the team are going to notice that this person doesn’t show up anywhere in the plan, or that the plan just looks off or incomplete, or work is distributed in an interesting way, or why is this person only scheduled for about a week of work in the whole sprint – all depending at what was known at the time the plan was drafted (and shared), relative to when the information became known. We don’t work with idiots, assume people will ask.

How about a real-life example: someone was being let go, which we found out during quarterly planning. We had written and shared some preliminary docs already, but the timeline of exactly when they were being let go was unknown, and the plan looked weird if you didn’t know as the work was distributed strangely. It would have been nice if we could have held off sharing, but timelines were what they were. Fortunately we realized this would look weird, and had time to formulate a response. Someone did ask, and I responded “We’re waiting for something to land” and they didn’t ask any follow up questions. Had they dug in more, I might have said something like “we were working through the plan when we found out that some priority changes might be coming [because if the person doesn’t work here…] and so we’re blocked on management [that is: management letting him go]”. A few tips: 1) less is more, 2) use passive language, 3) blame management – and a say this now as a manager.

Fortunately, the need for obfuscation in my experience is rare. Here, I’m not talking about social media skills.

If you’re an extrovert, as a TL you’ll get to make more business use of it! If you’re an introvert, <shrug>, you’ll have to develop the skill of being more gregarious when you have to be.

If you’re an extrovert, remember not everyone is like you. Extensive interactions for people who are introverts can be draining and they (me included) will need to recharge. It’s not that we don’t like people, or don’t enjoy people, it’s just an energy drain.

Tech is not exactly known for its practitioners elite social skills. Sometimes it’s due to neurodiversity, sometimes people are just really bad at it, some just need some practice. For the neurodivergent, which in tech we seem to have a higher than average proportion of, they often aren’t treated very well as some people are put off when some of them lack the ability to pick up on social cues, some don’t get irony or sarcasm, and some can be very unfiltered in what they say, some are very blunt and direct (which I actually appreciate). They’re not bad people. But their condition can put some people off. This is going to sound really basic but: be nice to them, as you should be nice to everyone.

As to those which just have bad social skills, they are often all too painfully aware of it. They know. Be understanding. If you have a mentoring relationship or something similar, and you feel it’s appropriate, ask if they’re interested in feedback about it. Social skills are a skill, and most people can improve their abilities. I’m living proof. As a kid, one of my friends mom’s told my mom that I was a social moron. My mom wasn’t happy about it, but looking back, my friend’s mom wasn’t wrong.

There are other people that may have decent social skills, but just rub you the wrong way – be nice anyway.

That brings us to Conflict is inevitable if you have broken people congregating, and having ideas…. and thinking… It’s the recipe.

If the conflict is with you:

First, don’t take yourself too seriously – just being self deprecating can defuse a situation.

Second, you can’t please everyone – Some people just thrive on being unhappy – it ironically seems to make them happy. If you run into one of these people, don’t try to spite them, but don’t hang your happiness on them either

So, inasmuch as it depends on you, be at peace with everyone – making enemies at work is a fool’s game. This is a reason why talking about politics that are not germane to the business in the workplace is unwise – talk long enough and you will disagree on something, and one or both of you may feel very strongly about the specific thing you disagree on and then there’s now an emotional divide where there didn’t need to be one.

Something that can feel like an attack is when a more junior person challenges you on a decision. When they do, answer it. Sometimes, we’ve been doing this for so long that we just pick things by default. Sometimes, we forget why that became our default. Maybe it’s not still the right choice. Sometimes it is. But walking through the scenario will a) help you discover it your choice is still correct and b) help the other engineer see your thought process about how you arrived at the choice you made. But remember, sometimes, they’ll be right. That’s good, by answering the challenge, at least one of you will have learned something.

If you work long enough, you’ll work with idiots. When you encounter them, it’s really tempting to flip the bozo bit on them right away and just ignore anything they say from that point forward. Be slow to flip the bit. Sometimes, they’re that way because of something going on in their life and they might just be surviving work. But sometimes, they’re just idiots – but before you flip the switch, make them earn it.

There will be times when you are wrong. Own it. When you’ve wronged someone, apologize, be sincere, and be specific, and no excuses, and do better next time. Nobody likes a B.S. apology, so don’t give one.

If the conflict is between two other people, it’s best if they can work it out between each other. Offer to coach, and give feedback, but also to mediate or … translate if they’re not able to work it out on their own. Sometimes they’re just talking past each other, and so can’t hear each other.

You might think that arguing and conflict are the same. They’re related, and often go together, but not the same thing. In arguing, you disagree, but there’s no enmity, no discord between you.

Remember: arguing here is a good thing. It means you have people who care, and want the right thing. It’s that they’re evaluating the “what is the right thing?” question differently, or they’re misunderstanding each other.

If you find yourself in an argument, consider if you’re using the same words to mean different things. I’ve found myself in violent agreement with people I thought I disagreed with, once we got the words figured out. There was a coworker I ran into this a lot with and we got in the habit when we noticed this might be going on to ask: “Say the same thing using different words.”

As I mentioned before in communication: people value different things. That can cause misunderstanding if you’re not aware of this. If you understand the different value systems in play, it can help you find a negotiation path to come to agreement, or at least get to a disagree and commit situation. So if you think this may be going on, ask questions and get to the bottom of it. Often the where you’re arguing is not the layer where the disagreement is.

When arguing, remember to critique the argument, not the person – you won’t win any friends criticizing the person. Ultimately, you want the company to win the argument, right behind that is you want to win the person, lastly you want to win the argument. If you win the argument, but have pissed off the other person, you now have someone who maybe isn’t going to work with you as well as you’d want. Depending on who they are, you may have just made an enemy. If you win the person, you now have a teammate pulling with you on the result of the decision to be made.

A couple of tools regarding argument that I find useful. First: If you haven’t seen this, I highly recommend it. If you search for thou shalt not commit logical fallacy you’ll find it. On it are 24 logical fallacies used in arguments. It’ll help you argue better, as well as pick up when someone isn’t arguing logically. There are more than 24 logical fallacies, of course, but this is a nice easy one that most people should be able to work with. Also there’s YOUR COGNITIVE BIAS IS (http://yourbias.is) If you search for your cognitive bias is, you’ll find this, which should help you think better.

Just remember, at the end of the day, you should be seeking truth. If you argue with that goal in mind, and engage your critical thinking skills – which please, please do in all areas of your life, not just work – then it should help you defuse some of the emotions that are often part of vigorous discussions when both of you are passionate on the outcome. It would also be good to know what the signs/symptoms of cognitive dissonance are, so you can recognize when it happens to you, or the person you’re arguing with.

Now for little switch, let’s go to As a TL you get the privilege/curse of being involved in planning.

There are Type 1 and Type 2 decisions to be made. Type 1’s are reversible, Type 2’s are the kind where you’re screwed if you get it wrong. When planning out the project, know which of the decisions you have to make are which kind. Sometimes, you can turn a type 2 into a type 1, which is nice, so look to see if you can, but don’t count on it. What kinds of things do you look for to turn a Type 2 into a type 1? Ultimately the Type 2 v. Type 1 boils down to risk. Is there a way to peel off some of the risk and test it in a Type 1 kind of way? In engineering terms, maybe I can send 1% of traffic in the new direction to see if the idea works. Maybe I can dual write and run tests against a new data store before switching over entirely. Is there a way I can test something before risking the whole? Peeling off risk this way comes with the cost of time and resources, so there’s no free lunch here. Because of timing and other constraints, it may make sense to make the Type 2 decision even though you could Type 1 it.

Either way, just make sure to be concerned over the right things because I’ve seen times when a lead isn’t making a call on a decision and it’s like “any decision is better than no decision”.

Be prepared to improvise when executing the plan. Things come up unexpectedly, other teams’ plans may change and you’ll have to adapt. There’s a phrase that plans are useless but planning is essential, which reflects this. There’s another that says, that plans never survive first contact with the enemy. Therefore, work out the plans, but don’t be surprised or upset when things change. Sprint plans aren’t carved in stone – there are times when it’s absolutely the right thing to blow the sprint. Sometimes, there are enough risky unknown unknowns, that you do mostly have to play things by ear and adapt as you go. It’s frustrating to everybody because it’s hard to give firm dates and commitments when this is where your project is. But just calling out that this is the nature of your project, and explaining your strategy is enough to set people at ease. They want to be confident in good execution, and saying “we don’t, and can’t, know until we get there” is exactly what they need to hear.

Along with that: “Failure isn’t an option; it comes bundled for free”. Your plan will be flawed, execution of the plan will be flawed, the code will fail in some way, priorities will change, maybe a reorg thrown in for good measure, and so on. Try not to get flustered when it happens, but rather expect it. When it happens, step back, and reevaluate. Communicate the change to people who need to know, readjust, and improvise. So much as we expect unit tests to fail the first go around, expect changes to the plan.

When planning, consider there is work that take a long time to complete, but know whether it’s clock time, or engineering time. Sometimes it’s that something takes a while to burn in, or a long migration task, and so on, but doesn’t actually take a lot of engineering time. Other things are exactly the opposite. But if some task takes a long time, but it’s mostly clock time, this gives you opportunity to parallelize the work stream.

If your work depends on other teams, engage them early, and check in on some cadence. Not everyone will be as well organized as you will be (right?), or as good as reporting changes that happen on their end. This will give you more reaction time to adjust.

Start the long pole tasks as soon as you can – they’ll sometimes run longer than you thought, so you want to account for the uncertainty, and again, give you more breathing room near the end of the project.

There will be tasks that are uncertain how they will shake out. Try to start them earlier too. You want to learn as early as you can how they will go. If you learn early, you have more reaction time to deal with the fallout, than if you left it to the end, facing a deadline looming with a whole bunch of “I hope we make it.” Get the uncertainty out of the way early.

Delegate. As a TL, you’re going to have more interruptions, and less focused maker time. If there’s something which requires very precise technical execution which no one else who’s available on your team can do, you’ll be on point to do it, but delegation is key to your sanity and effectiveness. If anything, I tend pick more small tasks than I’m normally inclined to just because they’ll fit better into a swiss-cheese-like schedule, and hopefully allow the team to retain focus, rather than deal with some random thing that you can just deal with.

Plan small milestones. If you’re on a project that’s to run for 2-3 quarters, you don’t want for it all to have to come together at the end. Having smaller milestones has a few benefits:

1. management can see concrete progress
2. you can validate assumptions before the end
3. might be able to give product people a thing they can start playing with sooner
4. it’s a morale boost as the biggest state transition in software is from the non-working to the working state

Along those lines, When you can, try to get components wired up early, even if they don’t really do anything. As the system starts existing more, you can catch problems earlier than if you wait to the end, and those connections won’t rot without you noticing.

If stuff’s on fire and you’re in the weeds, it’s very tempting to turn inward and hide. Don’t. This is also where trying to conceal it from your manager is a huge mistake. One, because they likely either know already, or will shortly, so you won’t be fooling anyone. And two, because they can help. Either by adjusting priorities, or help get something out of your way, or any number of options. But sometimes we can think we’re in the weeds but the reality is the situation is worse in our heads than it really is, and your manager can give you the reality check you need. Or maybe your just fried and need a day off to regroup. Your team needs you. You going into into silent mode for some indeterminate period of time is not good for the team because your personal blast radius encompasses at least your team.

Lastly, plan to 100%. It’s really easy to get to 80-90% and declare Mission accomplished, but you’re not done until you’re done. Which can mean clean up, or documentation, monitoring, alerting, and so on.

If you’ve noticed, most of this really boils down to buying yourself time at the end of a project, because you may very well need it. It’s much nicer when you finish a project early because you didn’t run into as many problems as you thought than the other way round.

There’s another kind of planning, Long Range Planning.

As you’re doing your normal work, think about the problems that you see. Whether it’s things in the codebase, or features that you hear are coming, and so on. If you’ve partnered with your EM/PM you can use that to start laying the foundation work both from a code perspective and a people perspective before you get there which can make your life a ton simpler. Couch these things in the terms that your EM/PM care about and that’ll help a lot as it will help them do long term planning as well (wrt projects, headcount, and inter team dependencies). And while in some of this longer range thinking you’ll be at least somewhat wrong (compared to when you get to that time horizon), you’ll be at least directionally correct.

As a TL, you do have to stay on top of things. Which things? That’s a good question. At first you won’t know and will have to absorb the firehose of info, but over time you’ll develop filters as to what needs attention and what doesn’t. But you’ll need to tap the hydrant, that is: you’ll need to find input. There’s obvious things like 1:1’s with your EM/PM and team members, and your email and slack channels. But I find it helpful also to look at the commits of my team members periodically. This is useful because you may find out about things that you might not otherwise had any way to know. There are tasks that never make it to sprint planning, but still need to be done. Looking at their diffs can also be a good check to look at the code reviews themselves, as a way to check “are the code reviewers doing a good job”, and give you a chance to mentor them to do it better. Code review is a skill, just like anything else.

If you discover things you’re not finding out with what you’re doing, consider how you might have found out about it sooner. What slack channel might you subscribe to? What questions should you be asking of those you already talk to? Is there someone you don’t talk to that you should? What does your work social network look like?

In 1:1’s I like to get a reality check. When having your 1:1’s, see if there’s differences between what you see and what they see, by asking them what they see about a thing before voicing any of your own opinions. Rectify when there are differences. Notably, ask if they see any blind spots. One of my favorite questions is: what’s the question I should have asked, but didn’t? Or what should I be looking into that as far as you know, I’m not? This will help reduce the number of unknown unknowns.

Be slow to be offended, and have an open ear for things you don’t want to hear. It will allow people to tell you things you need to hear. For me, I tell people, it’s ok to tell me to my face that I’m being stupid – but tell me why you think that. Because either a) I am being stupid and I need to correct it, or b) there’s a misperception that I’m being stupid that now has an opportunity to be corrected, or some combination of a and b.

Another part of being a leader is that you need to Burnout is a real thing. And if you’re leading, and it goes wrong, your blast radius is now considerably larger, so you need to take care of yourself. Therefore work/life balance is even more necessary than before. That being the case, combined with the scientific analysis of knowledge workers for nearly 100 years, I can say this: at the end of the day, go home. Unplug. Research has shown that knowledge workers working much more than 40-45 hrs a week don’t do well. As an example, analysis was done on game developers, and broken into two groups of companies: one that trimmed features to meet the deadline, and the other that crammed to meet the deadline. The ones that crammed did worse on every metric: sales, bug count, etc. So after you’ve put in your day, go “home”. Depending on your mental energy on a given day, go home earlier.

Consider getting a second phone that’s just work, and remove your work accounts from your personal phone. This way you don’t find yourself answering slacks & emails late into the night, or especially on PTO! Because if you do that, then your team members will expect that they too should always be online. It’s not good for you, it’s not good for them.

Find a group to hang with that’s not your coworkers. The average tenure of people in tech companies is something around two years. Have friends that survive a job change. Find a community group, something.

Find a analog hobby. Some kind of sport, activity, art (including fiber arts, performance arts, visual arts), music - even if it’s just listening, carpentry; reading, sudoku puzzles, etc.; something that gets you mostly away from staring at a piece of glass. I say mostly just because computers have become useful tools in otherwise analog hobbies these days.

Take mental health days when you need to. Sometimes, after a bad week, or after a stressful launch, or any number of other things, take time off. Overall, make sure you’re taking at least 3-4 weeks off a year. You have plenty of vacation here. Make sure you use it. It’s not just a perk to have vacation, it helps you be better at your job.

Lastly for this, you can’t be 100% leader and 100% IC. If you find yourself managing and doing IC work, even more so. Find a balance and be content that you can’t be 100% all things. You may have to adjust the percentages from time to time. Pick your priorities and try to order your work according to those, and then be at peace with things. And while you may see a pile of work on you, work on the most important and ignore the rest. Some of it honestly doesn’t need to be done at all, no less right now, and some of it can be done by “not you”.

Some companies have made a conscious effort to celebrate failure, and that’s a good thing (within reason). But we don’t often do “postmortems” when things go well. That’s unfortunate, as there can be good lessons learned when things go right. For example, did you take a risk that paid off? Did you invent a new technique, or refine a known one? Maybe your team didn’t know about the technique at all. Were there specific challenges you faced and solved? Did you just get lucky? Celebrate when things go right. Maybe we need to start a culture of writing post partums.

Trust your gut and your people Systems grow over time. Some projects are quite large. Often, you just can’t know everything. It can be really unsettling at first, but at some point you have to get used to it. When you get to that point, you have to trust that your people (for some definition of your people) are doing the best they can with the information they have.

However, listen to your gut too. Believe it or not, there’s actually science that backs up the notion of the “gut feel” for something. Evidently, something in your unconscious mind has noticed something that your conscious mind hasn’t quite figured out yet. When your gut speaks to you, listen to it, and figure out why it’s nagging you. In my experience, I don’t recall it ever being wrong. That said, you really want to find out concretely why, because if you need to change things that affect other people, they’ll want a reason other than “my gut told me so”.

One particular example where my gut tends to speak up on is when answering questions of the “how do I do X?” variety. Sometimes you’ll get a question that, while perfectly valid, seems weird. It may be reasonable, or even easy to answer, but something feels off. When that happens, inevitably, they’re ultimately trying to do Y, and going for X as an intermediate step, where X is the wrong thing. It turns out that this situation has a name, called the XY problem. Basically you ask: what’s the question behind your question?

And nearly lastly, especially when you’re new to technical leadership, but even if you’re not. There will be times when you feel like this:

Considering the weight on your shoulders it can be very disconcerting. What if I make the wrong decision? What if I delegate to the wrong person? And so on. But if it makes you feel any better, I’ve probably spent somewhere more than 1/3 of my career feeling this way, and the more I learn, the more I feel this way. If you feel like this, it’s entirely normal, and try to learn to be ok with it. What I will tell you is the old maxim: when you don’t know what you’re doing, try to do it neatly. There’s also a poem that was in the Communications of the ACM called the Beginner’s Creed By Peter J. Denning, while it’s pointed at CS students, is also applicable any time you’re getting into something new. I’ve included a link to it in the slides at the end.