
One of my engineers asked to me to do a brown bag on "hiring good people". I responded by saying just hire smart people and let them do their thing. Predictably, that wasn't a great response and probably doesn't do the question justice. I'm not the best engineer or manager but I do pride myself on building great teams so I agreed to do the talk. I want to share here what I shared with them.

### TEAMS

I want to start by saying I don't hire individuals in a vacuum. I try and think like a General Manager putting together a sports team (yes this will be a sports analogy). What matters most to me is how a team is going to function together. You wouldn't just get throw a team together without any thought to roles. For example, a team where no one can shoot would be terrible (cc: Rob Pelinka).

And I'm not simply talking about skillset. That's important but it's obvious and if you're reading this you probably already know how many backend, frontend, mobile, etc engineers you need (chances are you need more than the headcount you have, am I right!).

I'm talking about the roles people play on the team. Who is going to be the stickler for following good practices, who is going to bring excitement to try new tech, who is going to be the curmudgeon to slow down just enough to make sure there is a good reason to do that shiny thing...

The roles people play matter a lot. Imagine a team where there is no one who enjoys mentoring. You _could_ make this part of the career ladder (and you should!) but it's not the same when you don't have someone who is passionate about it to at least show everyone else how it can be done. Imagine a team where everyone wants to be social but no one wants to take part in organizing something. Again, you could mandate it or do it yourself as the leader of the team (and I recommend you take this on some of the time) but it's more fun when it's organic. The best events I've been a part of at work were organized by someone who cared.

(Important Note: There is a whole other post I could write (and many have) about how women tend to take on tasks that don't lead to promotions like organizing social events. Google it and be aware of it!)

So the questions you really need to ask yourself when interviewing someone is how does this person fit into my team. What will they add to make it a better, happier, more productive group of humans?

### But How

The questions I ask in interviews aren't particularly sophisticated. The trick is to let the candidate talk and then listen. If you ask about a time they mentored someone, do they go through a laundry list I could read off an informational sheet or do they share details that show engagement, joy and most important pride.

The best mentors will tell you where their mentee is now, what they are up to and how proud they are. The engineers that care about best practices will tell you about their pet peeves, their favorite tools, the changes they've made and why (the why is so so important). The bad answers are usually some form of "We catch stuff in code review. Code review is super important. We do code review. I named my dog Code Ruffview." Lots of buzz, no substance.

When I'm not sure, I take a step back and ask myself if I've learned anything from them and if not did they challenge or strengthen an opinion I already have. I don't even care if they told me tech I think is garbage is actually the best thing since sliced bread. I have even hired folks who told me mongodb is a good database (it's not and if you chose to use it, you should feel terrible about yourself).

There's one kind of candidate here to look out for. The one that throws buzzwords until they get you rolling and then agree with what you're saying. That's your fault, not theirs. They may not even realize that's what they are doing. They told you they use FAVORITE LIBRARY and you were like "omg yes lol I love FAVORITE LIBRARY" and now you think they are like you when they _didn't say anything particularly interesting_. Did you ask them _why_ they like FAVORITE LIBRARY, how they used it, when not to use it, what were the challenges involved, how did it disrupt their existing practices, what would they have done differently next time and on and on and on until you really feel like they understand why they are talking about it.

### Two last rules

First, I have a very strict "no jerks" rule. I think I have something like a 85%-90% hit rate on my filter. I have been wrong a few times in both directions. There's at least one person I didn't want to hire, was overruled on and later ended up loving working with them. There's at least one person where I was overruled on and turned out right. They were managed out and it was not fun. So you never really know. But here's the thing, as much as I loved working with that first person, had I not been overruled, I wouldn't have taken the chance. Jerks kill your team. Full stop. It's the hardest thing to recover from.

Humans, fortunately or unfortunately, can tolerate a lot at work but the thing they can't take is someone on their own team being a jerk. When that happens, they don't have the safety of their team. So I personally think it's always better to be on the safe side. If someone is giving off jerk vibes? Don't hire them. I would however give them some feedback on it to be kind. Maybe don't say "you sound like a jerk" but something like "when you spent 10 minutes ranting about how everyone on your former team didn't get your genius, you didn't come off great".

Second (and pay close to attention here!), GET OVER YOURSELF. You're a hiring manager. You're already in your role. There's no one you need approval from. An interview is not where you show someone how smart you are. For the entire 30-60 minutes, you have all the power. Act like it. It's very rare a candidate isn't nervous and feeling off the entire time. Don't abuse it.

Here are some gotchas

- You ask a question that only has one particular answer
- You ding people who don't agree with you
- You like people who do agree with you
- You like people who changed their mind mid interview because you convinced them (first, why are you using interview time to convince them you're right and two GET OVER YOURSELF)
- You spend more time talking then they do
- You take more than 30 seconds to ask your question (and that's a max time dude, not a goal)

There are so so many hiring managers I've worked with where I either had to train this out of them or I wanted to (but didn't) slap them upside the head and tell them to get over themselves.

You'll notice again that I never talked about technical skills. There are a million places where you can read up on every leet code, take-home, interview tool, etc that's out there. My opinion on this changes all the time based on situation, company, role and a million other circumstances. What I will say is that I'd rather take an engineer with B technical skills who is an A+ teammate than someone who has A+ technical skills but is a < A+ teammate.

### Onboarding

So you did it! You hired a great engineer. You're super stoked. You did your job and now you can go back to meetings and status updates (I mean, we are being real, right?).

HA! WRONG! Your status updates will have to wait a little longer. You missed the most important part. Onboarding an engineer too often gets overlooked.

I'm not even talking about getting a dev environment set up (though my rule here is you should be able to get set up and commit to production on day 1). I'm talking about the norms and expectations of being on the team. You think they'll just figure it out? Maybe.. but it'll take longer.

I'd recommend putting together a few living documents. I like to start with a North Star. The North Star describes your ideal future for your team, product, goals and anything else you deem important. The idea is that if folks on your team are trying to make a decision, it should reflect moving towards your North Star. It creates a system where you don't have to be in every meeting or review every decision to trust that it's mapping to the way you want the team to perform. The team should obviously be involved in editing the North Star and it should be revised as your team's missions and culture evolves. It's nice to look back at it from time to time and see how much closer you are to it.

The next document is your roadmap with the goals clearly laid out. It should be easy enough to digest for a new person and help them orient themselves within the team's day to day. If the North Star is the compass, the roadmap is your map to get there. A team that doesn't have a roadmap tied closely to clear goals is one of the worst team smells.

You should have a doc of docs. A place where you can put all other important things to read. Again, update this from time to time. It goes stale fast. Let anyone contribute. It should have enough content to understand the business domain, major tech used, important decision docs, company norms and procedures, glossary of terminology and acronyms, how-tos (e.g. how to deploy code, rollback changes, handle an incident) and a list of the fun stuff (slack channels, fun groups, etc).

Lastly, a 30/60/90. I tell everyone who joins to put a 90 day invite on their calendar. I tell them to not panic about being overwhelmed until they hit that day. Let them know it's ok to ask the same questions over and over. They should feel safe being lost in meetings. Don't worry about being less productive. Your job for 90 days is to learn. The 30/60/90 is a good way to break down that plan. If done well you usually aren't even following it by the end. It's just there to make sure you have a plan for getting someone from zero to full teammate.

### So there it is

I told you. I didn't really have much insight. It's all fairly obvious and has been written about a million times before. I think the trick is to do it. Hiring is hard. The worst managers are just trying to find _someone_. The best managers are scared of hiring the wrong person. If you have infrastructure around you like a recruiting team with quotas, other hiring managers competing for talent or engineers who don't really want to be interviewing, you'll be in a struggle against their own opinions, biases and incentives. I've worked with some recruiters who are the best of the best. I've also worked with recruiters who want to check a box so they make their quarterly goal.

This is your team. It's up to you to hold the line. Remember that for every person you hire, you have to believe you're going to be hiring 10 more of them. They _will_ interview other people. They _will_ refer their friends. They may not be able to get over themselves. They are people too. So you want to make sure that you never bend the standards or give in. Sure this can't always be helped. I've been overruled at times. There have been circumstances outside of my control. But you do the best you can. I've hired some amazing teams and it's been a joy to work with them. Not just because they make me look good (though that helps) but because it makes coming to work (even virtually) a pleasure. And in the end, I believe that most people care more about who they are working with over what they are working on.


Hiring Good People


The past few weeks at work have been rough and I've had to deliver stressful and distressing news to my teams. It got me thinking about honesty.

Someone asked me about the best way to deliver news. Especially when it can be subjective. Like the state of a project, team, business or company. How do you tell your team that everything is going to be alright? Why would they even believe you?

I think that's where banking honesty is important. When you're always honest, no matter what, you can start to build up credit with your team. When it's time for a hard talk, they believe you because of all the other times they knew you were being honest with them.

This can also backfire. It takes one time where you stretch the truth, misrepresent something or flat out lie and then you go bankrupt.

My policy is that I always share the truth as I know it or I tell the person who asked that I can't share. It's also how I want to be treated.

As a leader this can get you in trouble. I'm certain I've shared information I wasn't supposed to. I treat my team like adults and I hope they live up to it. Ultimately you have to use your best judgement. Your team's belief in you is more important than the potential harm it might do.


The Honesty Bank


Rejoice, performance review season is upon us again. Is there anything less fun than carving out time to reflect on six months of your reports as your mind goes completely blank on all of your thoughts and conversations. I’ve made it through many of these seasons and my team hasn't revolted yet (as far as I know) so I figured I’d share my own process.

First of all _(said in Charles Barkley voice)_, if you haven’t been taking notes since the last performance review, what are you doing? This shouldn’t be a deep strategic exercise. It should be a summary and reflection on months of 1:1s.

Second, it should be extremely rare to share something in a performance review that you haven’t already talked about at length at a 1:1. You may not consider performance reviews that serious, but your report knows this is written down and shared with your company. Don’t use performance reviews to tell your report about that time three months ago that they talked over someone in a meeting. Doing that hurts and they won’t forget it.

The only time this is ok is when you’re gathering feedback and you learn something new from multiple sources. If you hear something new from a single individual, you’ll want to go ask others (tactfully and privately) whether they’ve seen something similar. Performance reviews should include peer feedback and should absolutely include feedback from your report’s own reports if they have them. This is one of the few times people really sit down to think about it seriously. I often ask for feedback on my reports in 1:1s but performance reviews are usually when I get the most honest and thoughtful answers.

So you have your feedback. Now what? Look over your notes and take stock of all your conversations. You need to figure out what kind of performance review this is. Is this a person who has been crushing it and now you’re discussing ways to advance? Are you promoting them and sharing new expectations for their next role? Or are you reflecting on them falling short of the goals you’ve set out for them and regrouping to do better for this coming period?

I want to focus on the positive case first because I actually find that much harder. This is especially true when you have someone amazing and you’re really searching for feedback. Peer feedback is invaluable for this case. Some helpful questions are:

- What is the next progression for this person?
- Why can't they get that promotion / be in that role today?
- For each blocker, what will help them make up that ground?

I’ve made this list for myself but it’s useful to run through and check off which points make the most sense to advise or set as a goal:

- Acquire new soft skills (writing, presenting, running a meeting, planning, etc)
- Learn a new technology
- Take on a new role
- Take on leadership responsibilities
- Work on or lead a more challenging project
- Work on or with a different team
- Learn a different part of the stack
- Mentorship
- Coaching
- Owning cultural or organizational initiatives
- Run or participate in trainings or classes

If you’re managing managers then their own performance very much depends on their reports’ performance and you can use the above questions to frame success.

I want to emphasize that with a high-performer the most important question to ask is “what’s next?” and “what’s preventing them from getting there?”. You should _always_ be thinking about these questions but this is the time to actually set a roadmap.

Next you have the report who is doing _fine_ but not amazing. They are mostly content with the status quo and they are here for a modest bump in comp but mostly to just keep chugging along. I generally set myself a challenge here to see if I can help them grow in a few small ways. I take pride in trying to grow every person who comes into my sphere of management. Sometimes I’m not successful but I’m always trying.

For this case, I’m picking something small and focusing on it. I’m giving very concrete advice and some tactical actions I want them to take. Most people in this bucket do what I ask verbatim and I check it off. It’s not always satisfying but at the very least I feel like I’ve accomplished something.

The last bucket is the poor performer. If you wait until the performance review you’ve failed them. Then again, sometimes they won’t hear what you’re telling them until they have a hard “didn’t meet expectations”. I always have someone else read my feedback first (usually my manager) and role-play my feedback (again usually with my manager). I want to make sure my feedback is direct, actionable and I give plenty of examples. Bad feedback is usually something like “you’re not working hard enough”. Good feedback is closer to “while working on project Foo, you weren’t able to unblock yourself or ask for help in a timely manner. When your PM checked, you didn’t share any blockers until much later”. And then the advice would be something like “you should be communicating blockers as soon as you run out of threads to pull on or after X amount of time”. This is a contrived example but it’s just trying to outline that you need to be very very specific.

When I give constructive feedback, I will start the conversation by sharing that this is going to be a little tough but that I still believe in them and their ability to improve (and I actually do believe that or I wouldn't be bothering). I tell them I want them to listen, absorb, ask clarifying questions but then sleep on it before responding. Don’t let them respond when they are emotional or upset. It’ll be much more productive if you can schedule a followup regardless of whether they think they want that at the moment.

Once you’re done with your performance reviews, you need to make sure you’re holding yourself and them accountable for what you’ve talked about. This is much harder than it seems. Wok and life get in the way and suddenly months have gone by and they haven’t progressed and you haven’t pushed them on it. This is on you as much as it is on them. Part of your role is to push and make sure they understand you are keeping them accountable. So many performance issues stem from a perception of a lack of accountability. If you’re not talking to them about something, they probably think you don’t care and won't act on it.

If you forgot to take notes last time, you damn well better start taking notes now. It makes your life a lot easier.

If you’re reading this as someone who gets a performance review but doesn’t give them, remember that your manager is human just like you. If you completely disagree with their feedback, try to think about why they think it. Maybe they are projecting their bias onto you. Maybe they want you to be more like them? But maybe you're actually weak in the areas they point out. Sometimes all of the above. It takes a lot of strength to recognize your weaknesses, accept them and strive to be better. It also takes a lot for one human to give honest feedback to another so try to value all of it.

You might not be getting good feedback at all but that’s not an excuse to not seek it out. And if your sole motivation going into a performance review is to get through it or to get more comp, you’re really missing out. Feedback is a gift and performance reviews are the giving season. Good luck!


Performance Reviews


Every few months, a friend will ask me if I’m willing to talk to someone they know who is in a bootcamp, graduated from a bootcamp, or is a self-taught programmer. They’re looking for their first job and they want advice. I’m always happy to talk to someone and if you’re reading this and in that situation, you should feel free to hit me up. But I want to take some of my thoughts and write them down.

First a caveat, I’ve been writing code since I was 14. I took computer science in high school and majored in it in college (in a so-called “target” school for NYC tech). My own personal experience is very much the traditional route. But I’ve been interviewing engineers for nearly a decade and a hiring manager for the last several years. I’ve looked at thousands of resumes and screened or interviewed thousands of candidates. I’ve hired bootcamp grads and even picked a very talented Flatiron grad to replace me at my last role. What I’m trying to say is that I don’t have a bias against someone from a non-traditional background and I hope that eventually bootcamp isn’t even considered non-traditional in the startup world.

## What you need to know

I can’t stand when folks say that a six-month bootcamp is equivalent to a four-year college degree in computer science. It’s not and if you think it is then you’re a big part of the problem. Yes, you can count raw credit hours as being similar but at least from my own program, I would spend days locked in a lab or library writing or debugging code. The sheer amount of time you’re actually writing code spans years. You also have time to allow certain concepts to get absorbed because many assignments are repetitive. Even if a bootcamp spent half it’s time just on data structures, that still wouldn’t come close to how many different classes I had that required some kind of assignment based on data structures and algorithms.

Luckily, you actually don’t need that many hours to become a valuable programmer. I don’t think I’ve ever needed to balance an AVL tree at work. I’m glad I learned about it because it was interesting but you’re ok to skip it. But you do need some of the fundamentals depending on your role. The other great thing about a bootcamp and to a lesser extent being self-taught is that you learn relevant and modern skills that I didn’t learn in college. So what you need to do is understand what role you’re applying for (frontend, backend, fullstack, mobile, QA, data, etc..) and make a list of the concepts you didn’t learn. I’ve had someone tell me that a frontend engineer doesn’t really need to know data structures. I would argue that you can’t tell me the difference between `filter`, `find` and `map` without understanding data structures. Those are some of the functions that are the bread and butter of a frontend engineer.

Don’t just read a book. You need to intuitively understand them. Actually sit down and write code. Do you understand the differences between a queue vs a stack? Well implement them in your favorite language. Write some code to see the performance difference if there is one. Try writing some real code using each one. Do this for everything you learn! Make sure it sticks. I can’t tell you how many people I’ve interviewed who _know_ that they’re supposed to be using a HashMap because it’s the most efficient but then don’t actually know or remember how to use one. Yes, interviews are tough and I’ve forgotten many things while interviewing due to stress and pressure. But certain things just need to become a habit. They won’t if you don’t practice so much it becomes ingrained. I won’t go into the full list because many other people have written blog posts and books about it. Just make a list and get cracking.

## Projects

I think it’s great to have some personal projects and it shows that either you really enjoy programming (always a plus) or you have the work ethic to sit down and complete a project without direct external motivators (obviously getting a job is a motivator). Personal projects only go so far though. Software engineering is a team sport and like most team sports you actually need to play with others to develop certain skills. There’s a reason some of the best one on one basketball players in the world don’t play in the NBA. So my advice here is actually to find an open source project you can contribute to. You’ll learn many relevant skills like how real code reviews work, dealing with a large codebase, explaining technical ideas in writing and working with others. Also some open source projects are run by people who can’t communicate well and learning the art of communicating with a difficult person is both an unfortunate reality and a necessary skill in this industry.

If you don’t feel comfortable or can’t find an open-source project you’re interested in (highly unlikely there isn’t _something_ out there) then try something local. Maybe you can volunteer to build some software for a local business or charity with some friends. How about seeing if some of your bootcamp class wants to collaborate on something?

## Sourcing

So you’re feeling good about your skills but need to actually get some interviews. First think about the kind of company you want to join. My personal recommendation is to find a startup big enough to have a good ratio of senior engineers but not so big that you get siloed to very specific tech. Though I don’t have first-hand knowledge, I’ve heard some of the big tech companies have good programs for non-traditional engineers. But you should decide for yourself what interests you most. Next make a spreadsheet of the companies that interest you. This used to be constrained by geography but increasingly your city of residence is becoming less relevant.

Now go on linkedin and reach out to folks at that company. Expect that many people won’t answer you and some will be very delayed (I get so many linkedin messages every day but I try to filter through the crap to answer genuine requests eventually). Do your research first. Nothing is worse than realizing that you’re talking to someone who has no idea what your company actually does. It’s going to take a lot of cold outreach to even get some interviews. Don’t get discouraged if they tell you they don’t have a role open. Most startups won’t. It’s not malicious. It’s just that most startups are already under-water on capacity and having a senior engineer spend a few months getting you up to speed is going to hurt the roadmap and their ability to deliver.

“But I don’t need that much attention” you’ll say. Yes you do. It’s the little things that you’ve never encountered before. How to decide what is good vs bad code review feedback. How to give a proper estimate when your product manager asks if you can get something done tomorrow. How to think about debugging your code across a much larger system than you’re used to. These things just take reps and time. Being a software engineer is so much more than just the code you write.

## The interview

So you finally get an interview. That means they have the possibility of a role for you. Exciting! Don’t screw this up with unforced errors. That means do your homework. Ask your recruiter for advice on how to prep. Learn enough about the company that you can give an honest and meaningful answer about why you want to work there. “Because I like not starving and food costs money” is a fair answer but that won’t cut it. It’s ok if you care more about tech than mission or vice versa. Just sound like you’ve thought about it.

You will very likely have to write code for your interview. Lots of folks try and bang out the first 10,000 questions on leedcode. I think what’s important is that you feel comfortable with a language appropriate for interviewing. I strongly recommend javascript (which is basically the lingua franca of interviewing) but I’ve seen python and ruby work fine. I don’t recommend languages like Java or C# (aka Microsoft Java). You don’t want to be suffering through imports and compile errors while you’re trying to solve a problem. You can’t guarantee the editor they give you will have any features beyond basic text editing.

Know all the important features of the language. Do you really want to change your answer because you don’t remember how to remove something from an array? I’ve literally seen this happen and it sucks. Practice your language of choice until you don’t even need to think about the language and can focus on the algorithm you’re writing.

If a company asks you to do a take home, you have to decide whether you will accept. I personally strongly believe in them. It’s much fairer to folks who aren’t comfortable live coding and is closer to what you’ll be doing on the job. Not all takehomes are fair but mostly the ones I’ve seen have been fine. Give yourself enough time to complete it and ask questions early if something isn’t clear. Even if they don’t ask for any, write tests and add a good readme. If possible, make sure they can run your submission with one command. Explain your assumptions and reasoning. Add some of your personality to it. When you get to the onsite and need to run through the take home, make sure you re-familiarize yourself with your work. It might be days or weeks between the original work and the onsite. Make sure it runs. If you get to the onsite and your submission doesn’t run, it’s basically a hard no from me. Expect that they’re going to ask you to add something to it and practice. Maybe they ask you to change a feature or add a feature. Maybe there’s a bug you need to solve.

When it comes time for you to ask questions, don’t waste it selling yourself. Oftentimes I’ll see a candidate ask about the company culture and then spend a bunch of time telling me why they fit that. It has never convinced me to change my mind on my existing thoughts. This is your time to see if we’re a fit for you. It also shows me what you care about in a role. It’s totally fair to ask about your potential future boss, onboarding, training, culture, the team you would join and anything else you can think of.

## Hired! Now what?

I’ll probably save this for another time but I do recommend you invest in yourself if you’re able to beforehand. Ask about the tech stack and do some prep. A few hours on youtube will actually change your first few weeks! Also make sure to ask everyone you talk to for advice on how to be successful and about their own experience.

## Final notes

Pay it forward. That’s it. You’re going to make it if you stick with grinding to your first job but someone coming up after you is just starting their journey. Don’t make it difficult for them just because it was difficult for you. Advocate to hire non-traditional folks at your company. You’d be surprised how often there is a bias based on little to no information. But you must also respect your company’s situation. Recognize that your team just might not have the capacity at the moment. And finally, never lose the curiosity and passion that made you decide to learn to code in the first place. Good luck!


Advice to non-traditional candidates looking for their first job


This is a framework I try and use when explaining different levels to my team. This obviously doesn’t encompass the skills and experience necessary to advance levels. What I’m trying to convey here is a mentality that some people have and some don’t. The mentality itself is almost as important as the skills you acquire over time. For example, feeling responsible for the success of a project requires one to get good at learning how to communicate with a broad audience. So the levels as I’ve defined them for myself are Accountability, Responsibility, Ownership, and Vision.

The exact words I use don’t really matter. Many people will define this same idea using different words or some variation of them. It’s more important to keep track of what each level means with respect to the relationship to the work being done and the team.

## Accountability

At this level, you feel accountable if your work has a problem. This is the lowest level of mentality. The best people start beyond this level in their first role. It’s defined as the fear that you’ll be blamed if something goes wrong so you do the work necessary to avoid that blame. Sometimes it's not fear itself but missing a sense of urgency around work getting completed.

I’ve seen many engineers get stuck at this level and they don’t understand why they are not promoted. It’s true that you can get your work done and feel like you’re accomplishing something. You’re also putting a burden on others you might not realize. Take the example of an engineer building a mock given to them by a designer. Maybe there’s an issue with the mock that requires that designer to weigh in. The engineer goes and puts a comment on the ticket and then leaves it. Some time goes by and the designer might have missed it. Nothing happens until a tech-lead or manager has to poke the designer and engineer to see why it’s delayed. This engineer believes they did the right thing. After all, it’s not their job to chase down the designer. That’s why this level is so tricky. They have done the technically correct thing. Other team-members (especially cross-functional stakeholders) will not feel comfortable without oversight.

One strategy to get someone to advance to the next level is giving them a role model to look at. Point to the senior engineer and see how they unblock themselves. Make them understand that “not my job” will hinder their advancement. Make sure they get plenty of praise when they perform the desired action like chasing down something they need to finish their work. Public praise is the best because then others see that this behavior is rewarded.

## Responsibility

At this level, you feel responsible for your work. For some people, this is a perfectly fine terminal level. You won’t make it to leadership but you can be a valuable contributor. Folks at this level know how to unblock themselves. They will seek out others who can help them move faster.

Engineers here can be given complicated tasks and left without much oversight. They will have significant autonomy because you trust them to ask for feedback when it’s needed or important. At this level, you’ll usually find someone’s title as a senior engineer and sometimes tech-lead. They will form the backbone of your engineering team. You need to have a hard conversation about whether they want to advance. The next step requires significantly more investment and time. If you do find that they want to take on more then pairing them with a specific person for a longer period of time is most helpful. The jump to the next level is not as hard because the foundation of this mentality is already in place. Keep in mind that there will be times where they mess up trying to grow. Don’t let them get too discouraged.

When an engineer starts to excel at this level, it’s tempting to start talking about the issue of the day in their 1:1s. You talk about projects and people on the team. While that’s important for their development as a strategic thinker, you want to make sure you keep their goals in mind also.

## Ownership

At this level, you feel ownership for the success of your projects, product, system, and team. This level is not that different from the previous one but the main difference is now you’re proactively thinking of others as well. It’s not enough that the engineer’s work gets done. They want to help everyone get their work done. That means if the other engineer on their project is blocked, they help them get unblocked. If they see an error that they recognize or know how to fix, they speak up and help. This means documenting what they learn for others because they want to leave the world better for the next person. It also means that their sense of worth no longer comes from their individual work. It's a hard mental transition to make. Many struggle separating themselves from the volume of code they feel they should be shipping.

Now we’re getting into the first level of leaders. These are the engineers that you count on every day. The engineers that you need to keep challenged and engaged. We’re no longer talking about performance issues in 1:1s. Now we need to find new and exciting work. Often they have great communication and planning skills so you find ways to delegate more strategic work to them. These engineers are hard to find so don’t take one for granted.

With more experience, they are running your teams and making sure work is progressing through the sprint. When something is delayed, they find out why. They’re working to give everyone what they need. For stakeholders, it’s information and timelines. For engineers, it’s keeping work in the queue.

This is a hard level to stay at for years. They take a lot of crap at this level even when things are going well. They’re not exactly in leadership but also not really a contributor anymore. Sure, they find it exciting to be a fly on the wall in important meetings for a while. Don't get complacent with their growth. You want to have a plan for what comes next. You want to either move them into a technical or people leadership role once they’ve mastered this level.

## Vision

Welcome to the level you probably hope to be at (or you’re already there!). This is the level where you develop the ability to predict what will be needed in the future. We’re no longer talking about developing a mentality for excellence. You’re excellent at this point. Now it’s about pattern recognition and strategic thinking. You want to see the whole chessboard. This is thinking about organization design. You want to be thinking about changes that scale the whole team, not individuals. How can we maximize productive hours? How can we bring in more candidates? How will we scale our platform with 10x the traffic? These are the types of questions you are concerned with.

Once you start thinking strategically, it’s a clear path to higher levels of leadership including CTO/VPE roles. At this point, the mentality is as a leader. You may have a boss but the as far as you’re concerned, the buck stops with you. This takes a long time (I’ve only scratched the surface as the head of engineering and a director). Different size companies will require vastly different skill sets. The more advanced mentality here is that you’re thinking about how engineering fits within the entire company. You're learning to move the entire engineering team to respond to the changing strategic needs of the business.

And that’s it. The great part about this framework is that it doesn’t require years of experience. It’s a mindset. You can just decide to think differently. As with most things, you’ll have to practice. There will be times that you want to just let someone else deal with something you know you can help with. Maybe it’s been a long week and you could just ignore it. No one will blame you. But just like any habit, you have to be consistent about it or it’ll never stick. But also like a habit, one day it’ll be your norm. Then you won’t have to consciously try to think that way anymore. That’s just you now.


The different levels of ownership mentalities


The first time I met with a senior manager who would later become an advisor, she asked me what my philosophy on management was. I had no idea. Get shit done? Don’t screw up? She told me that her philosophy was to take care of her people no matter what. She said it flew in the face of everything most management books and training say. Which is that your responsibility was first to the company and then to the team. She didn’t care and said that’s what made her so successful (and she’s crazy successful). She asked me what my philosophy on testing was and I gave her a long rant (which I will write up one day). “If you have such a deep philosophy on testing, why don’t you have one on management,” she asked me. She’s right.

Thinking about my philosophy it boils down to “be a person first, manager second”. First, I make sure I behave as a thoughtful, ethical, and moral human would. Then I worry about all the other stuff. Or at least I try. Managers should think about their relationships in years, not weeks. I was thinking about that recently as I've gone through some unusual situations. I’ve had quite a few of them in my career so far. Blog posts, books, and manager trainings will only get you so far. I thought I could retrospect three situations and how I might handle them according to the “be a person first” mantra.

## Unexpected Time-off

Most startups will write down some policies to govern situations that apply to everyone. Things like parental leave, vacation time, expense rules, unique benefits, and many others. Inevitably, someone who reports to you will come and ask about an ambiguity with a policy. You’ll have to weigh the benefit to the person and the precedent that this might set. You'll also have to think about whether you’re being fair towards everyone and who else this might impact.

Someone might ask for time off that you can’t grant because of a tight deadline. They might ask for relaxed rules around work from home (we’re talking non-COVID times here). You might find yourself in a situation where they are in the wrong. Yet deciding against what they’re asking might have serious repercussions on them.

I know of another manager friend who had a difficult time when an engineer forgot to ask for vacation until the last minute. That engineer had already spent thousands of dollars on travel expenses. What do you do in that case? Other people on the team are going to be impacted negatively if there is a deadline. It’s not the team’s fault, why should they suffer? And what message does this send to the rest of the team about the company’s policies? Are you going to damage your relationship with this person who you have to say no to? What if they decide to go anyway? You or someone else in leadership could be in the wrong for not setting expectations up front? I’m sure everyone has their opinion and there are so many nuances to consider. This is where my philosophy kicks in. Be a person first.

First, take yourself out of the mindset that you are part of the issue. I know plenty of managers who would feel hurt or a threat to their authority. That’s not the issue right now and if you make it about that, you’re only making a bad situation worse. What is the best outcome for everyone except you? I’m not talking about the company as a whole but the people in the company. Can you find some solution where everyone compromises a bit? Maybe they still go on vacation but they end up working for part of it? Maybe you talk to the team and figure out a way for that person to make it up to everyone (like taking on-call shifts over holidays?).

Make sure to include the person asking in your thought process so they understand what happened here. You want them to understand the burden they are adding to the team so they’ll be open to compromise. Trying to shield them from the consequences, even if you’re doing it to be nice, only hurts them. You'll be setting the wrong expectations in their mind for next time. Sometimes it’s not possible to find a solution and you do piss that person off. It’s happened to me. I’ve had to say no and it never feels good. My hope in every situation is that they understood why I was saying no and that I was consistent in my decision making with everyone.

Afterward, you want to make sure they understand the policy for next time. You also want to make sure everyone understands this. You don’t want to create an unfair or biased culture. One where the “good” people are hurt for following the rules and the “bad” people get away with not following the rules. You might not pay attention to it but the folks who see their peers not adhering to the existing policy are very aware. They will get upset and likely won’t say anything until it’s too late. Specific of which..

## Giving Notice

Any time someone has given me notice that they are leaving the company, it’s been a huge test for me to react with compassion and thoughtfulness. In the moment, my first thought is how did I fail? I also get doubtful about my own skills as a manager. I’ve seen other managers turn negative and try to make the person giving notice feel bad or guilty about “abandoning the team”.

Your goal at this moment is to treat that person with respect, understand their feelings, and their new opportunity. Then talk with them honestly but respectfully about their options. There are many differences of opinions on whether it’s worth trying to save someone who has given notice. I won’t go into that now but from experience, it is possible to address the underlying reasons and keep them. Multiple times I’ve seen that person go onto a long and happy career at the company.

What you don’t want to do is make them feel bad in any way. Congratulate them on the opportunity. Tell them you’re excited for them (and you really should be!). Make sure they feel comfortable telling you why they felt the need to go looking. Sometimes you can’t solve it. For example, if they are looking for a role or domain you don’t have available. Sometimes it’s comp or company level issues that are out of your control. Sometimes you didn't do a good job and they are specifically leaving you. Take that as a wake up call to improve. Ask them for feedback on the team, yourself, and the company. Ask them what, if anything, you or the company could have done differently next time. Ask them when they started looking and if anything prompted it. Don’t get upset or pushy if they don’t feel comfortable sharing with you.

A few things you definitely should not do (and yes these are real examples). Tell them they don’t have control over the end date and that the company will decide when their last day is. Tell them their new company isn’t good or share gossip that negatively impacts their feelings towards their next opportunity. Tell them they are making a big mistake. Shut the door on future opportunities with you. Get angry or emotional. Start telling other people in the company about their departure in a negative way.

If you find yourself having a hard time controlling your feelings then it’s completely fine to say something like “Thank you for letting me know. Let me go talk with [another leader] and get back to you about a plan. Please don’t share this before we’ve had a chance to talk again”. Then end it there and go gather your thoughts.

After you’ve mutually agreed to an end date, make sure they feel comfortable winding down their work and making time to say goodbye. Folks who have been with the company longer will have more people to say goodbye to. You want them to feel like they can and should get goodbye coffees or meetings. Celebrate their work and their contributions publicly. Make sure they feel good about the team. You have no idea what kind of impact they might have on others if you leave things negatively. Most of all, make sure you ask them for feedback near their last day. That final feedback is some of the most honest you will get from someone who reported to you. Get their contact info and stay in touch. You may cross paths again. Follow up later to make sure they are doing ok in the new role. Once their manager, always their manager.

## Not _My_ Person

The last situation involves a tricky case where someone on a team that is not yours needs to hear tough feedback. It might be a manager or a tech-lead that is not a good leader. It might be an individual contributor that you notice needs some tough love. Maybe you’ve tried to give their manager that feedback but they’ve disregarded it. Maybe their manager has tried and isn’t getting through and could use some support. Sometimes this person needs to hear it from an unbiased third-party.

So how do you give someone feedback where there is clearly a power dynamic (you're at a more senior level) but not a manager relationship. Many people would actually not give feedback at all. That’s unfair to the person. True that some people can’t be taught. But many people are only a few pieces of honest feedback away from turning a skill or role around into a strength.

So let’s give a more concrete example. You’re in a meeting with a manager from another team. They should be owning the meeting, advancing the discussion, taking notes, giving everyone room to speak, and making sure we stay on track. But for whatever reason, they are either reluctant to lead, ignoring parts of their responsibility or they are veering off track. You may or may not have your own people in that meeting. It doesn’t matter. So the meeting is a few minutes in and you realize that this is going off the rails. Maybe you are very invested in the outcome of the meeting or it doesn’t matter to you that much. Either way, as a leader, you want that time to be useful and the meeting to be a success.

Here’s what you don’t do. Take over the meeting formally. Criticize the other manager publicly. Say something about this meeting not being useful. Stay silent in a way that makes it clear you are unhappy. What can you do? Try asking probing questions that get the meeting back on track. Sometimes I outright lie and say something like “[Manager], weren’t you also talking about X previously”?. If the manager is at all smart, they will jump on this lifeline of advice without making it seem like I told them what to do. Sometimes you might know that someone else can help steer the meeting towards a useful outcome but they aren’t getting the space. That’s where you can use your voice to amplify their voice with a “[Quiet Person] might have some insight because of X”. If you remove your own ego from the equation and don’t need credit, there are many tactics and tricks you can use to incept an idea into someone else.

When a meeting like this is going poorly, I’ll usually take some notes to myself on things that could have been better. Afterward I’ll message that to the person privately with a prompt like:

> Hey [Person] I like to give direct feedback when I can. Here are some thoughts from that meeting. I'm happy to talk through them if you want. Hopefully you will find this useful.
> [Notes Here]

If they are someone that wants to grow as a professional, then they will be receptive. If not, then possibly you hurt someone’s feelings. I’m ok with that because more often than not, this works. Several people have actually followed up with one-on-one meetings to talk more about my feedback. I love it when I later see someone actually use a strategy I taught them in a future meeting. I think it all starts from a place where you genuinely want to help that person. Most people can tell when you’re giving feedback as a performance vs when you actually care. If they really take it to heart, tell their manager so they get some praise for the turnaround.

So that’s it really. Don’t just manage someone or a situation because you’re a manager. Do it because you care about them and their success. When you strip away your own feelings and the need for credit, you’re left with their growth to think about. Just be a person first. Everything else about being a good manager will follow.


Be A Person First


This week I was talking with someone at work and they seemed to be stuck trying to wrap their head around a new idea. I asked whether they spent time watching videos or googling. They mumbled a bit about not knowing much about it and then veered into a different option. This got me thinking about what I used to be like. How I used to be intimidated when I didn't know something. This will probably only be applicable to a certain type of person so bear with me. Or completely ignore this.

Lots of people and cultures have some variation of [the monster of the bed](https://en.wikipedia.org/wiki/Monsters,_Inc.). Basically, when they’re a child they’re scared to go to sleep because there is a monster under the bed. They haven’t seen the monster but believe it’s there and are too scared to look. The fear of the unknown is so much worse than anything that could actually be there. There are many approaches to help a child (or adult) to cope with this fear and overcome it. In software, I think this manifests itself as being scared of a new tool or technology.

Early on in my career, I used to be terrified when someone talked about a technology I wasn’t familiar with. I remember someone on my team started talking about some new software thingy I hadn’t heard of (I think it was containers or microservices? It was a while ago). I had no clue what it was and was worried I’d be “found out”. I started trying to pick up some general buzzwords from conversations and repeat them to sound smart. It worked (I think because no one ever called me out.. maybe they were too polite) so I did it again when the next new tech thingy came around. It was a bad habit and took a while to unlearn. The worst part is that it robbed me of many years of learning new things.

I don’t remember what actually changed but at some point, I just stopped faking it. I learned to say "I don't know" and stop pretending I did know. I'd keep asking questions until I understood.

I also decided to start a list of all the things I heard about during my day. I’d go down the list when I had some spare time and learn the new thing until I felt I understood it. I’d cross it off the list and then keep going. Sometimes I’d dive deeper.

It felt so much better and liberating! More than that, I enjoyed it so much that when the list got low I’d go seek out the next thing. It started what is now a nice tradition of using certain times during the week for breadth learning (for me it’s mornings with coffee before I start my day).

When you find yourself scared of a new tool, try and consider what it’s like when someone else asks you about something. Do you mock them or think less of them? If you do, you’re a tool. But for most people, you’re more likely to want to be helpful and provide resources or explain it directly. That’s how people perceive you when you don’t know something. Not as an imposter or "dumb" for not knowing.

My goal here is to hopefully show someone else that there’s no need to be scared of the technology you don’t yet know. The difference between someone who knows a thing and someone who doesn’t is a lot less time invested than you think. I wish I understood that when I started my career. Next time there’s a monster under the bed, get to know it and you’ll realize it wasn’t so scary after all.


The Monster Under The Bed


There are many definitions of what an epic is but I like to think of it as a user story that is too large to be delivered at once and will span longer than the average sprint length. A sprint is about the length of time that a team can hold context in their head without putting an epic around it and being more formal around ownership. Less than a sprint of work and you can (if you choose) keep them as a few small tactical stories without using this guide. Another dimension of an epic is how many dependencies it might have. An epic is an easy abstraction to talk about work with another team.

Some time ago I put together an epic checklist with my team. We’ve continued to add to it as we take on new projects. I’d like to share that checklist in the hopes that other teams will find it useful and save them some of the pain we went through learning these lessons. In certain places, I add additional notes to explain that item. The checklist is meant to be as short as possible so that it may be read through quickly and often.

**Note**: I also highly recommend the [Tech Lead Expectations for Engineering Projects](https://docs.google.com/document/d/1kngKHUCS0DHNvZAO8PfkcsTD4Mq7b11L09RIaVpQnwI/edit) by Gergely Orosz. I refer to it often.

## Preamble

To facilitate larger efforts, we group tasks into a structure called an epic. Every epic should have one engineering point person who takes the project from ideation to deployment and maintenance. The epic lead is ultimately accountable for the engineering success of a project. This checklist sets the expectations of the epic lead and their responsibilities through the lifecycle of the epic. Many of the tasks in the checklist can be safely ignored when not relevant. A good epic lead will delegate many of the responsibilities in the checklist but ensure they are followed through.

## The checklist

### Gathering Project Requirements

- [ ] Outline current existing functionality
- [ ] Meet with Product Lead and stakeholders
  - Discuss different solutions including describing tradeoffs and risk factors
  - Elaborate with Product Lead to come up with the scope of the project
- [ ] Ensure that feedback from stakeholders makes it way back into the plan
- [ ] Ascertain what is the actual minimum viable scope for initial rollout and what can be delayed to a phase in the future.
- [ ] Ensure that there are measure-able success metrics for this project and that data needed is available or is part of the build effort. **Note**: This is usually the responsibility of the product lead but the epic lead must insist that we are building this new thing for the right reasons™.
- [ ] Identify gaps in the project.
- [ ] Identify areas where we can improve the quality of our system and incorporate it into the project within the appropriate level of scope.
- [ ] Creating and updating documentation around the changes and additions of the project.

### Planning Epics & Creating Stories

- [ ] The epic lead is not responsible to write the stories by themselves but is accountable for the result that comes to estimation.
- [ ] Stories should be [INVEST-able](https://agileforall.com/new-to-agile-invest-in-good-user-stories/)
  - Stories should be as independent as possible.
  - Stories should be small and estimable
  - Stories should not dictate implementation unless strictly necessary to mitigate risk
  - Stories should have clear success criteria
  - Stories should have a testing plan
- [ ] The epic lead is responsible for bringing the set of stories to an estimation session with a quorum of engineers.
  - This group must include all engineers working on this project
  - This group can include at least one engineer not working on this project
  - It is strongly advised to include all engineers with relevant prior context
- [ ] The epic lead is also responsible for gathering feedback from engineers during estimation and incorporating them into the stores.
- [ ] The epic lead should understand and document the deployment and rollout strategy during the planning stages.

### Implementation

- [ ] The epic lead is not expected to implement all features by themselves.
- [ ] The epic lead is responsible for dividing up stories into mostly independent work-streams among the engineers on the project. **Note**: The tech-lead or engineering manager on the team will usually be the most knowledgable on each team member’s capabilities. The epic lead should collaborate with that person on assigning work.
- [ ] The epic lead is responsible for helping unblock other engineers when they are not able to unblock themselves and communicating roadblocks that come up with the relevant party that can unblock that engineer.
- [ ] The epic lead is responsible for always knowing and regularly updating stakeholders on the status of the project.
- [ ] The epic lead is accountable for each engineer keeping their story tracking accurate and up-to-date.
- [ ] The epic lead is responsible for the ultimate quality of the architecture and data model for the project.
- [ ] The epic lead is responsible for communicating trade-offs in terms of refactoring and tech debt accrued to the product lead. **Note**: Together they should negotiate the correct level of tech debt allowed to be taken on by the team.
- [ ] The epic lead should consider the long-term maintainability of the code the team is adding.

### Testing / QA

- [ ] The epic lead, working with the Product Lead, should make sure a testing plan is created for every story (or sequence of stories).
- [ ] The epic lead is responsible for making sure there are sufficient automated tests.
- [ ] The epic lead along with the Product Lead must monitor the progress of QA testing and alert stakeholders of any unforeseen delays.
- [ ] The epic lead must ensure defensive tests are put in place to guard against regressions in the future.

### Deploying

- [ ] The epic lead is responsible for the deployment plan including when necessary:
  - Release order of packages.
  - Backward compatibility issues
  - Migrations and backups
  - Rollback plan
  - Soft launch plan if necessary
  - Configuration changes
  - Feature flags
  - Metrics and data changes
- [ ] The epic lead is responsible for making sure any deprecated code is torn down before the project is declared complete.

### Monitoring plan

- [ ] The epic lead is responsible for monitoring including:
- [ ] Ensuring the product is working in production on the release
- [ ] Errors are surfaced at the correct level (i.e. not too noisy but visible)
- [ ] Thinking through potential future points of failure and how to track them
- [ ] Determining with the Product Lead the priority of bugs that are reported post-release


Epic Lead Checklist


In startup land, you’ll find that often the tool of choice is the one that the first person was most familiar with. It makes a lot of sense to go with the familiar. You’re building a business and a product and you can’t stop to learn every new thing. That's why it makes sense to pick a technology that you’re familiar with. And why it makes sense to work with people you’ve worked with before. But over time, if you’re lucky, the team will grow and those tools stop making sense. You’ll need to migrate to a new tool for the team to scale. It sounds easier than it is.

First, make sure you’re doing it for the right reasons. At a new company, I tend to want to replace everything with something better (or at least I think is better) as soon as possible. I have to fight the urge and wait. I want to understand why we chose that tool and whether there is a significant benefit in migrating. It’s not enough for the new tool to be better. It has to be better for everyone and it has to be better right away. Otherwise you should delay the migration.

Start by writing out the goal of the migration and what specific problem this is trying to solve. Convince yourself first that this is the right thing to do. Migrating to a tool that isn’t better is a sure way to lose credibility fast.

Once you’ve convinced yourself, find the power users of this tool and try to convince them. Give them a little demo and see what features they think are the most important. Does the new tool have those features? Are there other features they might find as or more useful? Is the tool faster? More responsive? They are going to ask for things you find trivial or not-important and it’s your job here to not push back but listen. It’s impossible for you to put yourself in their position and understand why something is important for their workflow. It is ok to ask a lot of questions and try to understand. If you get significant push-back then this new tool might not be right for the team. But they also might be scared of change. It’s hard to differentiate sometimes but you’ll need to figure out a way to understand the difference.

If the power users do come around then you move on to any decision makers that need to be involved. At this point, you should be able to state the goals and share that your power users are onboard. You want to come with the outline of a migration plan in place. They are going to have doubts and need to sit with it for a little while. There are lots of other issues they might need to consider that you aren't aware of. In the past I’ve failed at this and was impatient for an answer in the very first meeting with my manager. You want them to sit with this and come around to be an advocate for this change. You don’t want them reluctantly agreeing to keep you happy.

Next comes the roadshow to the team. You want everyone who can to see the tool, try it out and even create an account in advance. You want them to have an opportunity to play with it at their leisure. You’re going to be answering the same question to multiple teams so gather your patience. Be positive and kind. Realize that some folks are going to be nervous about any kind of change. Share how this will make their own workflow easier. You’ll also want to figure out a key talking point for each team around extra features they might benefit from. Suggest material for them to learn more. Keep letting them know that you will be around to answer questions and help. I always stress that this is an experiment and that if enough people don’t like it we can always go back to the old tool. In all likelihood, if you’ve done your due diligence right this won’t happen. But they need to know it’s a real possibility because you’re fallible and could have made a huge mistake.

As you sell, you should be working on the migration plan. I prefer one-day cut-overs but sometimes it’s best to start with a small group and expand outwards. A lot of this depends on what kind of tool. If it’s something that multiple teams work on together like a wiki it might be harder to have two tools at the same time. If it’s more of a siloed tool like a video calling system then it might be ok to have it start small and expand outwards. The migration plan should include the timeline and a plan of what needs to be migrated. It should also include any decisions needed in advance. It should set guidance on how to migrate and who owns each part. I like to keep the "circle of pain" small and within a leadership role. Maybe you only need your team-lead to own the migration for the team. That person will bear the pain of the migration itself so no one else needs to. Since they are part of leadership, they should expect to bear some pain in their role.

Ask the vendor for guidance. They might recommend some blog posts or open-source tools that will help you move data. I’ve even seen some vendors do the migration themselves manually. They will be keen on getting folks onto their platform. Remember, they’re not doing you a favor most of the time. In all likelihood you’re paying for this service. Even if the vendor doesn’t have a tool, you might be able to find advice on the interwebs. You’re not picking a brand new tool (please don't be the first) so expect others to have tried this migration before. Their might be strategies to deal with the same issues you’re expecting to see.

The day comes and you should expect to spend it helping folks resolve their issues. Spend some time with each team that needs it. Expect some hiccups and troubleshooting. It might even be good to let the vendor know you are migrating that day and to be on-call for support. Make sure to keep the old tool around for a while. You don’t want to lose any information. To save money, you can downgrade the account to less users and slowly start to minimize the people who can access the old tool. That will help you know it’s longer being used. If it is being used, you want to know what use-case they still need it for. Let everyone knows the date you’ll sunset the old tool in advance. They need to be comfortable that you’re not going to take it away from them. Sometimes you won’t be able to ever get rid of the old tool because it has too much legacy information that is valuable.

Remember to keep selling the tool after the migration is over. You’ve given the team the right to not like it and move back to the old one. You want to get over the hump and keep the excitement until it becomes natural and habit. That usually happens pretty quickly. Teams tend to adapt to the new in startup land. My last advice is to run a small retro. What did you learn that you hadn’t thought of? Who was most helpful and what did they do to help? Who made this more difficult? Who had good push-back and who was frustrating without good reason? Who was cheerleading the effort, who was nervous and who was indifferent? An what could you have done differently to make this smoother. When this migration succeeds, you'll have built credibility and likely have another migration at some point in the future. Learn the right lessons to make the next one easier. And then share them with me so mine will be easier next time as well!


Migrating your teams to a new tool


A hackathon is an event meant to allow engineers to build new ideas outside of the existing day-to-day process. Engineers come together to collaborate on building a brand new feature or enhancing an existing feature.

The hackathon is meant for all of engineering. Members of other teams are welcome to join contingent on their own schedules allowing.

Here a few talking points for a startup trying to start their hackathon tradition. I recommend starting with a day because it'll be an easier sell to stakeholders when you have a small team.

### What is the goal of hackathon

First and foremost to have fun! We work hard and need time to grow the creative energy that’s so important to our discipline.

The projects we build are meant to showcase what’s possible and inspire what the future might look like.

### But I need to ship by the end of the hackathon

You should _demo_ by the end of the hackathon but need not have your code ready for production. You should be spending your time hacking away to demo an idea. You should not be spending your time on best practices, linting, naming conventions, where to put files, testing or anything else that would take away from being able to demo.

### Does it need to be product related

If you’re more interested in building a tool for engineers or some infrastructure project, that should be totally fine. The point is to get creative and some engineers prefer to work on tooling over product.

### Can I ship my code eventually

Depends. Obviously in order to ship code to production it must adhere to your normal best practices including rigorous testing. In addition, you need to make sure your PM or accountable stakeholder is onboard to avoid any potential negative business outcomes. Once you have production-ready code and the green-light, go for it!

### Do I need to prepare for hackathon

I always recommend announcing hackathon weeks in advance. At that point, start thinking about what you want to build. If you don’t have an idea then take some time to solicit ideas from other people or join someone else’s team! You can start an ideas group in chat or a shared document. If you need inspiration, try reading business content in chat, documents or presentations to see if someone has an idea you want to build.

I encourage everyone to work with at least one more person but not every team follows this practice. It's helpful to ask everyone to share their idea beforehand so you have a sense of whether someone might be too far afield. It also gives folks a chance to join another team.

### What happens during hackathon

At the start of hackathon you should expect to come in and get started with your team. All meetings are cancelled. Providing meals and snacks throughout the day is always appreciated and avoids engineers getting out of the flow to find food.

Set a time to demo all of the projects to the rest of the company followed by an engineering-sponsored party for everyone. Having the company join in on the celebration gives your engineers pride and also cred with other folks at the company who normally don't see individual's work.

Happy hacking!


Tips for a first hackathon


Today is the 25th anniversary of Bob Ross passing away. I watch The Joy of Painting pretty often as it's one of my favorite ways to relax. Among the many important life lessons that Bob shares, there is one that is especially relevant to me. Learn how to use your tools. I also appreciate how much Bob is able to communicate what he's doing as he works. In that spirit, I want to talk about a particular communication tool. There is no more important tool in your toolkit than the status update.

A good status update inspires confidence in the work being done. A good status update keeps other people from constantly pinging you and your team with questions. A good status update will save you time in unnecessary meetings. And yet too many people never learn how to write a good status update. Most organizations default to a meeting culture because we expect a status update to be bad or non-existent. My goal is to share some tips for good status updates in the hopes it saves you time in the future.

A status update can be about anything that requires coordination or accountability on a team. It could be for a long or short running project. It could be during an incident or outage. It can be for a hiring process or team event. It can be for anything where the results of the work are interesting to others less aware or not actively involved.

## Why

First, it’s important to explain why you’re giving this update. The right context sets up the rest of the update to be read and understood accurately. There are a few tactics but my personal favorite is to include a quick section at the top. Something of the form:

Goal: Ship the widget builder 2.0 so that users can start building mini-widgets
Timeline: ETA July 1
Status: On Track

That’s about 20 words but it conveys so much information to the reader. They now understand the context, a frame of reference for other dates in the update, and whether they should be concerned because of the status.

## When

A good status update is shared at the right cadence. When you're thinking about how often to send the update out, consider a few of the questions. How often does new information surface? How often do engineers complete work and move to new work? When are your stakeholders required to give their status updates up the chain of command? Are there any dependencies that would enjoy an update at a particular time? For example, what if there is another team that prioritizes work at a certain cadence? Would it make sense to share a status update at a time where they can use that update to change their own work-in-progress?

Once you understand what the best cadence for updates is, send it slightly earlier. Keep your team from waiting for your update and have it in front of their eyes the moment they are ready to think about it. Often times a good status update will come in the morning to start your day or evening to end your day. Sometimes you can include the next update time in the current update. For example, if this a status update for an ongoing incident, it might be important to convey the status and say something like “next update one hour”. That way your stakeholders won’t be interrupting your work. They'll know that the next time there will be meaningful information is in an hour.

## Where

If a status update is shared but no one knows it exists, is it really useful? Make sure the update is shared in a predictable place like a public Slack channel or emailed to a specific list of people. The status update should exist beyond the moment you share it. That means sharing a status update in an ephemeral place like a zoom chat is not a good practice. Similarly, using a resource that is hard to discover like a private google doc can be problematic (though this depends on context). The location should allow for reading the status update asynchronously.

A status update should be short enough that it’s easily digestible by someone who doesn’t have enough time to understand all the complexities. That’s why a layered approach can be handy. In the layered approach, the main status update is shared in a public place that is very visible. Then it has links to other sources of information that may be able to answer more in-depth questions. You might share that the widget builder is to enable virtual widgets and then add a link that explains what a virtual widget is. Most of the folks reading will likely know what a virtual widget is. This allows a stakeholder who might be less involved to pull the information at will.

## Who

I strongly believe that all work should be owned by one person and that person handles the status update. This also implies that the owner is keeping tabs on all work so that they can give a status update. This person may not be the one doing all the work but they’ve had a strong hand in planning and will ultimately be accountable for the success of the project. This doesn’t have to be a formal leader with a formal title. Anyone can own a project and anyone can the leader on a project. Getting good at giving a status update is an important skill for a junior person to grow into a formal leader.

The audience of the status update is anyone who may need to know something about the project now or in the future. Unless there is a reason why the information should not be circulated, it’s better to bias towards over-sharing than under-sharing. Often times, a status update can trigger a thought in a person who might not have been part of planning. It can lead to exposing new risks or work that might be unnecessary. It’s not always necessary but I like having defined groups to make it easier for each update. Instead of typing out 30 names in an email, send it to widget-team@example.com and you won’t need to worry about missing someone.

This also leads to an important by-product of the status update. Celebrating individual hard at work completing tasks. This is a great place to show appreciation and shout out someone who hit their milestone. It can be for anyone that did something important for the success of the project. Don’t overdo it or seem artificial. Just add a small note so that others can appreciate their work as well. Giving someone praise and credit in public is one of the easiest and most important parts of leadership.

## What

So here’s where we get to the meat and potatoes of the update. What do you put in it? We added a first part that explains why this update is happening. Implicitly the sender and the audience comprise our second piece of information. Now we need to fill out the content.

I prefer a line item for each task being worked on of the form:

What needs to happen - Who owns it - Current status - (Optional) When does it need to get done with (Optional) risks

Here’s a more concrete example with weird formatting to emphasize the point (in reality I’d make it more human-readable).

Build the widget marketing page - @Bob - In-Progress - Likely will be ready for QA on Monday if we get the theme from Design by Friday

That one sentence is enough for everyone to understand this particular task's status. Also, I’d add a link to the ticket itself with more information and potentially a visual marker of the form green/yellow/red for confidence or status. But, you’ll want to limit how much visual treatment you add to keep it from being overwhelming. If the update is long, you might want to split it into sections either by status, by person, or by milestone. It often depends on the project itself and what is visually easiest to understand.

When it comes to dates, you want to be very conservative when giving time and risk estimates. Don’t use the status update to commit to any work or times without consulting the team first. You want to avoid having the person doing the work comment publicly that the timeline doesn’t make sense. It is detrimental to the confidence of your stakeholders if you appear not to be speaking for the team.

You’ll also want to highlight certain tasks that are either going off track or have significant risk. Stakeholders should be directed towards those items because they are the most important for them to understand. It’s critical to point out which parts of the update are significant because of new information or risks discovered since the last update.

Finally, the update is a great place to add the next steps section. This section will let your stakeholders understand what is being planned and where this project is headed. It is often the most important section left out of the project. It's also the most likely information you’ll get pinged about in private.

## Next Steps

(See what I did there)

Hopefully, this has been helpful in giving you some suggestions on how to give your own status updates. There are many other helpful techniques I haven’t included here but could be of value to your team. The most important take-away is not how to write a perfect status update but to give one. Over time, you’ll refine your own practices as new questions arise that you haven’t been able to answer. You’ll also start training your stakeholders to expect an update instead of going to you or someone else every time. This will translate to less meetings, more focused work time for you and others, and a happier team.


The most important tool in your leadership toolkit - the status update


Here's a common discussion between a business stakeholder and an engineering leader. Why aren't we hitting our deadlines? Or the alternative, why aren't you able to give me accurate timelines. The engineering leader sucks in a deep breath. Then they begin a tirade on how impossible it is to know how long engineering work will take. Or the engineering leader will agree to put a date on work they know won't get completed in time. This situation plays out week after week. The business person loses confidence in the engineer. The engineer loses the motivation to even try communicating anymore. The relationship turns toxic and everyone is unhappy. The real kicker is that both of them are smart, ambitious, and want the best for the team.

So how did we get here?

## Startup Land

This is a startup. At any given moment, there are a dozen experiments we need to launch. We're always in danger of running out of money. Founders are pushing hard towards the goals the company needs to hit to survive. And at the center of it all is the engineering team which builds the thing that all this hoopla is about.

Most startups don't plan years ahead. A few people have an idea and they build the smallest product they can in the jankiest hackiest way. The few companies that survive this stage don't have time to go back and start over with good technology. So they forge ahead and hire an engineering team. That first engineering team does its best to make good decisions but they are only a handful of people. The stresses of everyday work usually get the better of them. They make more decisions we'll have to fix later.

So here we are a few years later. The engineering team is several dozen people, broken out into a handful of teams. Everyone knows the foundation is shaky but we continue to add on new layers. Work takes longer than it would in ideal conditions. Hidden mines are lying in wait, soon to become the next urgent incident. Documentation is non-existent. Engineers need to find a person who knows the thing. It takes time. Memories are fallible. Planning tickets is either straightforward or complete guesswork. Most engineers complain about legacy code. They would prefer to refactor rather than understand the existing systems. Testing isn't part of the culture yet ("takes too long") so bugs run rampant. You can't be expected to deliver on time with all this mess.

Now what? How do you manage expectations when you know the situation is unforgiving? When you can't predict what's around the corner or even know exactly what you're building. Here are a few suggestions. They seem obvious but you have to practice each one until it becomes a reflex.

## Be Honest

First, be honest with your stakeholder. Set the expectation that you and the team will do your best but sometimes you're going to miss and that's ok. Promise that you'll always be open and transparent about why. Communicate early. As soon as you identify new information that changes the timeline, let them know. Communicate with detail. Take this example:

"We won't make the Friday launch because the code turned out to be more complicated than we expected"

Now read this one:

"We won't make the Friday launch. The model we're building only expects one widget per person. We need to change the model to allow for many widgets per person. To do this we have to run a migration on the database. This is risky because it could delete every person with a widget. We want the other team to review it and they can only do that the day after next. We also need to test it against real data which will take an extra three days of setup. The new timeline is the following Wednesday."

Which one of these explanations inspires more confidence? Sure, some stakeholders will still get upset but most will understand. You've communicated the reason for the delay and a new deadline. You've also allowed the stakeholder the opportunity to decrease scope. They can come back and say "I'm willing to take that risk" or "Let's ignore everyone with a widget for the first version". You gave them the tools to make a more informed decision. Now you are partners in the timeline instead of the stakeholder being a passive observer.

## Stay Firm

When you're working on a project, you have two levers to play with. Time and Scope. (Burning out your engineers by having them work more hours is a third but let's pretend we're good leaders).

So many folks have talked about this already that I won't go too far down this path. I do want to add one point I don't see as often. If you're asked to commit to a firm deadline, take care to talk in specifics about scope cuts. Don't agree to loose generalities. Make sure your business stakeholder understands what they aren't getting in this version. Repeat it often. Write it down. Don't assume the absence of scope means everyone is aware. Your stakeholder might assume it's an implicit criterion and expects it done anyway.

When new scope gets added ad-hoc, be firm about the tradeoff between new work and the deadline. Too often I see someone ask an engineer to add one thing. And then another thing. A month later, you're at a retro discussing why the thing shipped late. No one mentions the small ticket or the extra success criteria. But that work adds up. The add-in ticket is the morning ice-coffee of productivity. There's nothing wrong with buying an ice-coffee every morning. But very few people realize how much money that adds up to. Imagine every morning before you bought your coffee, you had someone show you the cost. You might make a different decision. The same rule applies here. It's not bad to add more scope. Make sure the tradeoff is explicit. Convey that doing the extra thing comes at the expense of time or scope. We're not doing an extra thing. We're doing an "instead of" thing.

## Make Actual Progress

You're kicking off a project due in a month. At the outset, you get to decide between two paths forward.

In the first path, we create a bunch of tickets that are more or less the bullets from a planning meeting. The ticket can spend weeks in-progress. Engineers are coming up for air to ask their peers to review thousands of lines of code at once. We defer QA to the end of the project. The engineer might have understood the requirements. But we won't know for a while. When the time comes to merge in big chunks of the project, there are conflicts to resolve. You're now dependent on other teams that you didn't expect. We've created many more days of work than we accounted for in planning. The deadline is coming closer so we start getting "scrappier". We turn the feature on and hope that we did enough testing at the finish line. It's time to pray. And prepare for the incident post-mortem.

In the other path, you create small bite-sized tickets. Every ticket is only marked as completed when it's shipped to production and live on your site. Pull requests are small and manageable for engineers to review. QA (whether design or product) happens as work is ready. Engineers ask more questions because each ticket has more specific criteria. Other teams merging code must ensure it works with yours because yours was in first. As you're nearing the deadline, there is no panic to start QA-ing everything. Most of the code is already merged. You don't need to resolve a ton of merge conflicts. You're able to turn on the feature and sit back and enjoy it. You might even have the opportunity to soft-launch and have resolved some bugs. The rollout is smooth and your team celebrated as heroes.

Did I need to ask which path you prefer? So here's the obvious insight. Create smaller work. Ship often. QA often. It feels so much harder but it's not. It's a habit that your team builds. Sometimes we mistake "Done Thinking About This" for "Done". Then we actually have to go back and redo something. Again this is un-accounted for work.

Shipping often also helps you narrow the window you can miss on a timeline. If a certain ticket should take a day or two then missing by 50% is another day. If we allow a ticket to take weeks then missing by 50% can be a week or more. We also won't seek to understand risks or complications until the ticket is in danger. If we expect a ticket to take weeks then we will wait for weeks to probe the engineer for more information.

## The good cycle

In my experience, no one ever talks about the tickets that finish ahead of schedule. At most, we give the engineer a pat on the back and move on. Tickets that take far too long get retrospectives and action items. We change the process for tickets that take too long. We rehash them over and over. It's not a bad thing to learn from mistakes. But when we don't follow through too often, it becomes a matter of blame. The goal isn't to get to perfect timelines. It's to instill better habits so that we create the conditions for misses to happen less often.

If you miss less often, the times you do miss won't be as big of a deal. Your stakeholders will take your word more often when you explain delays. In fact, they will start to recognize the same patterns and appreciate them. Your team will be happier and act with urgency (not pressure). And with all the spare time from not chasing impossible deadlines, you can work on planning for tech debt. Improvements to productivity mean less uncertainty. Less uncertainty gains you more credibility. Now you can sell more code improvement projects to stakeholders. The improvements create even more predictability. It's a beautiful cycle.


Being Accountable For Timelines


Welp. You’ve just found out there’s an urgent issue that needs to be addressed. Someone released a bug or maybe there’s an outage with a critical system. Whatever it is, you have a “drop everything” situation. You have yourself a fire.

## Step 1: Don’t Panic

Your first responsibility is to keep yourself calm. Your next responsibility is to keep everyone else calm. The first few moments are going to be tense, especially if there is a real user impact. Lots of folks are going to rush in and try to help. Engineers will start working on solutions without fully understanding the problem. There will be duplicative efforts. Ask everyone to take three deep breaths. Good. Now let’s begin.

## Step 2: Establish The Correct Communication Lines

There’s going to be multiple lines of communications happening at once. Some of that communication will happen outside of public forums. For example, a few folks might jump on a video call and start talking without letting anyone else know. It’ll be a very difficult task to understand who needs what information in-order to do their job. Because of that, I often find it’s best to keep all communication in a public chat room. If a video call is necessary, post the link publicly to give whoever needs a chance to jump on. After the call, summarize the info and post it back in chat so there is something written to refer back to. Let me say this again because it’s so important. Keep all information and decision making public and written down.

Stakeholders are going to be very worried and while they might not be part of addressing the mitigation, they probably need to be involved in some of the decisions. Establish who needs to be actively informed and who needs to be passively informed. If you’re familiar with [RACI](https://en.wikipedia.org/wiki/Responsibility_assignment_matrix), use those principles (though I probably wouldn’t mention the phrase itself as it tends to reek of Process with a capital P). Either you or someone else needs to own frequent updates in the public chat room with clear owners for each action item and a time to the next update. Some people prefer creating a dedicated public room to gather all information. I’m mostly indifferent as long as all information is in one place. It’s always surprising to me how fast information flow can spiral. Suddenly a chat turns into emails and phone calls. There are a few Google Docs floating around. Keeping everything in one place won’t be a small effort.

## Step 2: Investigation and Mitigation

Before starting to work on any solutions, determine the impact and what can be done right now to mitigate that impact. Maybe it’s displaying a banner on the homepage? Maybe it’s updating a status site? It depends on the situation. Before making any code changes, determine with 100% certainty what caused the issue. Often times, engineers will rush into a situation without fully understanding the root cause, deploy and fix, and only after the issue is not actually fixed realize they’ve wasted precious time.
Establish a timeline for what caused the issue. Some important questions to ask:

- When did this start?
- What caused the issue?
- Is it ongoing?
- What is the impact to customers?
- Are there legal implications concerning the next steps?
- Do we need additional resources that are currently not aware of the issue?

## Step 3: Take Action

This is the easiest and most frustrating step. If you’re working on communication, you most likely won’t be part of the group that actually solves the issue. It’ll be very hard to just wait and let someone else work. Fight the instinct to bother them as they work. But continue to ask questions when they come back with status updates. Make sure everyone understands the scope of what they’re working on and stress urgency but not panic. The code should still be tested and reviewed. Any system changes should still follow the normal rollout process.

It’s important to take smart shortcuts but not cut dangerous corners. A smart example might be reverting the change instead of finding a fix that will stop the bleeding. A dangerous cut corner could be pushing a code change without testing it. Your job here is to keep everyone thinking clearly and avoid additional damage caused by a stressful situation.

A common fix is running a script directly against a database. I think there are arguments to be made for and against this kind of action. I believe certain situations make this unavoidable. There are ways to be smart here. If you’re running a script that touches a large number of records, start with a handful of records and verify the change was successful. Backup your database first. Keep a record of every script that was run and when. Make sure that every script is reviewed by a second person (usually I prefer at least two people).

## Step 4: The all-clear

As the situation starts to clear, continue to provide updates to stakeholders. Continue to ask whether there are any additional steps that need to be taken. Be aware that this is a stressful situation for many people and be considerate when some people continue to ask questions that have been answered already. Continue to write down everything.

When all action items are done, it’s important to give an official all-clear. It really sucks when the team is just hanging around unsure of what to do. Make sure you voice appreciation for everyone helping out (whether or not they were part of the original cause). Your team worked hard that day and should be acknowledged for it. Many of my favorite moments at work have come during incidents because it’s very much a bonding experience for a team (though you really should wait to laugh about it until after the issue is fixed and some time has passed).

## Step 5: Post-mortem

Run a post-mortem. This should never be started during the incident but is critical afterward. Make sure everyone knows this process is not about blame but about making improvements based on the learnings. I like this [template](https://response.pagerduty.com/after/post_mortem_template/) from Pager Duty but really any document with a timeline, steps taken and future action items is fine. Keeping this conversation away from blame is key. Remind everyone that when something like this happens, there are multiple layers of failures. It’s easy to blame an engineer for some bad code. But what about the reviewer? What about the previous engineers who never built-in safeguards? What about management who didn’t prioritize training and education for this kind of issue? What about stakeholders who push engineers to move faster and don't want to hear about edge cases? There is more than enough blame to go around. Let’s be productive and think about solutions instead.

Keep the post-mortem factual and friendly. This is a dangerous meeting where one wrong thing said could really harm team chemistry. Start by thanking everyone again. Make sure to acknowledge folks who might not have been as visible like customer support or legal. Brainstorm action items that will help prevent or mitigate issues like this in the future. Assign owners and time-frames for each item. Not every item actually needs to be assigned. Generally, there will be a handful of items that have the highest value. Focus on those. A lot of frustrated people who just experienced a really bad day will throw out some ideas you will think are not great. Let them. Write everything down. If it’s not valuable or achievable, you can find time later to talk it over.

The post-mortem is really just the beginning. It’s your job as a leader to keep everyone accountable for follow-ups and make sure work is prioritized to ensure this kind of incident never happens again. In fact, this is where most managers earn their paycheck. Everyone is usually all positive right after an incident but as time passes, other priorities start to bump incident followups out of the To-Do column. You must keep pressing the team to prioritize this work. Keep reminding your stakeholders about the potential impact of a future incident like this happening a second time. Do they want to go through this again? It's your job to make sure they don't.


Fire


I have a little figurine on my desk that I look at from time to time. It’s Michael Jordan soaring for a dunk. The plastic base is missing a corner, chewed off by my dog years ago. The metal stand is rusted and most of the paint is faded. But it’s unmistakably MJ with that red 23, tongue out and hand palming a basketball. I’ve had this figurine since elementary school and it’s been on my desk through high school, college and now as I navigate my professional career. I use it to calm myself down, inject a boost of confidence or when I need a push to stop procrastinating. I look at my little figurine and remember that Jordan wouldn’t be scared and then direct that feeling towards whatever needs to get done in that moment.

Easier said than done, right? I hear about imposter syndrome from almost every engineer I’ve ever managed or mentored. My peers in college and now in industry share that they experience imposter syndrome often as well. It only seems to get worse as you gain seniority. There is a constant feeling that you’re only as good as the last code you shipped or the last value you explicitly produced. A few days without a win can make a person worried that they’re about to be “found out” and colleagues will realize they aren’t as senior as the title or role they hold.

I think on a rational level, most folks in our industry realize this is true of most people around them but somehow it’s taboo to talk about unless you’re speaking in generalities or talking about someone else. Very few people I’ve worked with will come out and say “most of the time I feel like a fraud”. I wonder how much healthier software engineering would be if we talked about this phenomenon more openly. But here I just want to talk about one strategy that has worked for me and might work for you.

To borrow a little more from basketball (half of my manager tools are from sports), I think about how the greatest [basketball shooters](https://www.breakthroughbasketball.com/training/shooters-dozen.html) train themselves mentally and have tried to emulate it in my career. Great shooters always care more about consistency in their form than being perfect. They don’t worry about their last shot, only the next one. And a truly great shooter will continue to shoot even when every shot isn’t going in because they believe the next one will.

How does that apply to imposter syndrome? First, it’s about changing your mentality from thinking you always have to be right or perfect to realizing that sometimes you’re going to miss. Software engineering is a team sport. You want to embrace that you’re only going to get it right part of the time and rely on your team to carry you when you’re making a mistake. When you’re in a meeting and say something that ends up being wrong or even sounding stupid, try and shake it off so that you don’t stay silent the next time you have an idea. It’s much harder to do than it sounds but with practice you can get better at training yourself to be ok with being wrong. When you put up a pull request and get dozens of comments and corrections, you have to trust that if you were consistent in your practices (whether that’s writing good tests, using the team’s conventions or whatever that may be) then this feedback can improve your skills. Instead of getting upset, incorporate them into your “shooting form” (ie the way you write code) for next time.

For tech leads and managers, this can be just as important. Your work is much more visible and it can be much more mentally difficult to screw up because it’s usually in a larger forum. I remember a time right after I became a manager where I presented a new framework for the team’s values at an all-hands meeting. It was a disaster and my boss at the time mercifully suggested we shift the discussion to asynchronous (a polite way of saying “stop talking and let’s regroup privately on this”). It really hurt at the time because I knew he was right and I thought folks on the team realized I wasn’t qualified to be in that role. As hard as it was, the rest of the week I just put my head down, put in the work on other things and slowly built up some wins until I felt a bit better. I doubt anyone besides myself even remembers that meeting years later. I just kept shooting because the only thing I could change was the next task I was going to work on.

As soon as you embrace being wrong, you also get better at asking for help and seeking feedback proactively. Seeking feedback can be a powerful counter to insecurity because it gives you validation (or course-corrects) on your own terms. It is important to distinguish between seeking feedback and seeking answers. You don’t want to outsource your thinking to someone else because then you won’t get better. Wait until you feel like you’ve done all the work you can on your own and only then ask someone else to take a look.

When all else fails, I try to remember that I’ve been able to get by so far and that it’s unlikely this challenge, whatever it may be, is going to be the one that stumps me. I know it’s not as easy for some people as it is for others to adopt a certain mentality and this advice won’t work for everyone. I hope that the take-away you get from these thoughts is that so many other people have the same insecurities and fears that you do and most have figured out how to overcome those challenges and they (and I) aren’t any better than you. The only difference is that we’ve found a strategy that has worked and maybe you haven’t found yours yet. But maybe you have and you don’t even realize it.


How Michael Jordan helps me get over imposter syndrome


I recently went through my own round of interviews for several companies and I was expected to write code in multiple sessions for each one. I’m not particularly senior (though I was interviewing for a Director role) and I still love coding so it didn’t strike me as odd. But I’ve now had this conversation with multiple folks so I thought I’d try and gather my thoughts. So the question I’m posing to myself is:

_Should senior engineering leadership (Director, VP, etc) be expected to code during an interview?_

A caveat first. I am not referring to system design questions like “design twitter”. I firmly believe those types of questions are very important for any technical leader who will be running a team that develops software. I'm talking about interviews where you've given an editor and expected to produce working code within 30-60 minutes. What I would refer to as leetcode / hackerrank questions.

## The Case For

Presumably you started as a software engineer and have been writing code for at least a few years before moving into management. You’ll be expected to manage engineers who code or manage the managers of those people. One of the best ways to understand productivity is to read code reviews and design documents with snippets of code. As a leader you’ll be expected to form an opinion and mediate groups attempting to make technical decisions. All of these actions require some level of experience with writing software. How can you prove you actually had that experience without proving a baseline? If you’ve been part of engineering teams recently, you’ve had to stay at least a little bit current in the codebase. If you can’t manage an easier question that employs the basic ideas of your favorite language then how much can we really trust that you’re as technical as you say you are. If you've coded for a reasonable amount of time, you'll remember enough to get through an interview question with some minor practice.

There is also a human component. I’ve seen engineers who’ve been able to stay employed as a coder without having to write much code (story for another day). Maybe that was you? You must work to gain some credibility with the team and one of the ways to do it that is by contributing code or ideas surrounding code. How will you be able to show empathy towards developers that are struggling with tooling or architecture if you don’t have the capacity to learn what that means in this new environment? What happens when there's a discussion and you're asked your opinion? What about being helpless if there is a production issue? The best managers I’ve ever worked for have truly loved engineering and engineering culture. If you’re just a professional manager, why do we even need you to be an engineer?

## The Case Against

At a certain level, it’s counter-productive to be spending your time writing code when your main responsibility is towards your team’s growth, productivity and happiness. If you’ve spent the last few years of your career in 1:1s and meetings, how much time do you really have to code. Folks get rusty after a while and why ask someone to brush up on their coding skills just for an interview. Do you really need to be able to sort an array to prove that your org design skills are excellent? Isn't it more important to prove that you can communicate ideas, present to different audiences or write effectively?

You would assume that a reference call, discussions about your philosophy and exploring different situations are much more important. And if you’re coming in at a level where you won’t be expected to code often (if at all), you’ll only be growing further away from the code as the company (hopefully) grows. If you had someone with years and years of proven experience building teams, would you fail them because they couldn't solve FizzBuzz? This is why you hire and promote great technical talent into tech-lead and architecture roles.

## My philosophy

I thought about this for a while and I still don’t have a great answer. I do think it’s important to love coding to truly empathize with your engineering team. It’s hard for me to believe that someone who loves coding would be afraid or unable to solve simple interview problems. I wouldn’t expect a senior candidate to be able to do more complex algorithm questions but maybe something that shows you can at least think through a problem. I thought about whether a take-home would make more sense. After all, that would demonstrate that you can learn and solve problems and that you are focused enough to get shit done. I like that idea but for a candidate navigating multiple options it can be a real blocker

Another thought (while watching [Space Force](https://www.netflix.com/title/81021929) which is highly recommended), I wouldn’t expect a military general to be able to perform at the same level of a Navy Seal but I think I would be suspect if they were completely out of shape and couldn’t do a push-up. What kind of message does that send to your team?

So yes, I do think an engineering leader should have to code in an interview but I would weight it much less than other areas and I’d be very explicit upfront about what I expected prior to the interview so as to give them a chance to brush off a little rust. I’d also be forgiving if they forgot specifics but were able to describe what they intended with their code. Not everyone can remember every function of an array after not using it for years.

The argument that ultimately swayed me is the signaling of not wanting to code in an interview. I keep asking myself what kind of message would that send my future team? That I expected them to be able to do something that I can't or wasn't willing to do? I'd rather be lead by someone who knows they might have a hard time but will do it anyway because the kind of team they want to build is one where everyone is stretching out of their comfort zone and expects the highest of each other.


Should engineering managers code in interviews?


I’ve read plenty of blog posts and books on testing in my career that extol the benefit of testing and give great instruction on frameworks and best practices. I don’t often see any thoughts on what happens next. I’m going to attempt to skip past the first part and assume if you’re reading this you a) believe and understand that testing is important and b) have a good sense of how to set up your favorite testing framework.

## Culture

The most important part of testing is building a culture of testing. It’s not enough to convince engineers and business stakeholders that tests are important and valuable in the abstract. Everyone can talk about how tests lead to more productive engineers in a meeting. But when crunch time comes around (and that’s basically every week in startup land), they need to _feel_ that testing will help them.

So how do you get there? In my experience, engineers need it to become habit to write tests and uncomfortable to not write tests. I’m primarily a Node developer at the moment and I’m learning Ruby. It’s incredibly uncomfortable for me to end a statement without a semicolon. That sounds trivial but that needs to be the level of discomfort for an engineer to not write a test. They need to look at their pull-request that’s being sent out for review and feel deeply that tests are missing or insufficient. That feeling comes from repetition and from having culture-carriers on the team who already have that feeling learned from elsewhere. In general, I’ve found that a 3-1 ratio (3 learning to 1 culture-carrier) is sufficient to spread the culture as long as the 1 engineer is senior, respected and weighting their time heavily towards code review and pairing.

Habit is important and repetition will get you there but you can speed up the process and make your life is easier if writing tests, debugging tests and monitoring tests is an easy task. Most companies under-invest planning and refactoring of their testing infrastructure so that it grows much more haphazardly than your app code. It’s my (and many others) belief that your testing code should be as clean and easy to maintain as your app code. That might mean prioritizing and pushing for projects around cleaning up your testing. It might mean that you need to assign ownership of different parts of your testing infra to individuals. One example is when I assigned an engineer to come up with a better way to make commonly used mocked object factories easier to discover. We were in a situation where engineers wouldn’t be able to find the factory and then just create a new one. That reduced each engineer’s motivation to write tests for more complicated use-cases and even if they did push through it was wasted dev time that duplicated work and required significant cognitive overhead.

It should go without saying that every engineer that contributes to your codebase whether it’s a complicated system or a small css tweak should ideally be writing some kind of test that verifies the change works and protects against future regressions.

To your business stakeholders, it’ll be very hard to explain why they are seeing value but there are strategies here as well. Start tracking your bug rate or other metrics that might be impacted by user-facing bugs (conversion? support tickets?) and put a dollar amount against it. As you improve your testing capacity, show them the trend and prove with numbers that there is real business value here. I would have charts that showed the user-reported bug rate with an average amount of time that each engineer spent on a bug that made it into the sprint. I would update this chart and mark it with milestones around our various testing improvement efforts. There was one significant downward trend that started right after we introduced end-to-end tests and the trend continued to decrease for months as engineers added coverage over new parts of the system. We were easily able to add at least one engineer’s worth of time without hiring a new engineer.

## Critical Mass

Say you’ve convinced the team and your testing framework is in decent enough shape that writing tests are easy. You’ve reached several thousand tests and you think all is well. Except you start hearing about flaky tests or skipped tests that keep cropping up. Alice needs to add a new widget and a completely unrelated test fails about half the time. This widget is business critical so Alice (along with her manager or tech lead) decide that just this once you’re going to skip the test or rerun your CI workflow until it passes. Then it happens again with Bob’s important ticket. Then Conrad does the same thing with a really slow test that is taking forever to run. Suddenly your test suite is a leaky bucket where you're losing code coverage quickly because tests are annoying engineers. So what do you do?

First and foremost you want to have visibility into the problem. Hearing about bad tests anecdotally is a good way to get your spidey-sense tingling but not good enough to actually fix the problem and make sure it stays fixed. Get actual metrics on the issue. Many of the popular CI tools these days even have built-in or easy to integrate tools that give you details on what tests are flaky and what tests are slow. Make this automated and create a process around fixing these as soon as they come up. Once you have reporting in place you first want to stop the bleeding. Sometimes that means dedicating time to fixing each broken (I include slow tests in this definition) test and sometimes the problem is so widespread that you have to declare testing bankruptcy and just delete huge parts of your testing suite. The decision is too situational for me to get advice here but know that I've done both in different circumstances and have not regretted either decision.

My concrete recommendation is to get a periodic report (weekly worked best for me) including all tests that are slower than the threshold you deem acceptable and which tests have failed in the last week or whatever heuristic you think is best for a test being flaky. Then assign someone (as often as possible the engineer responsible) to fix them as if they were bugs. This has the added benefit of making the engineering team realize that they need to be aware of what can cause these issues. You can start a tradition of adding learnings into your documentation so that engineers can learn from each other and also have a place to read up on possible gotchas in the system. Make sure these test failures are not being assigned to the same folks over and over. It’s tempting to just assign them to the engineer who will fix them the fastest or has bandwidth. You want these test breaks to feel the same as bugs.

## Test Environments

As I said above, I don’t want to get opinionated on specific test frameworks and what you should be looking for but it might be worth a cursory overview of some features of good testing environments. The first thing I usually look for is whether you can run your entire test suite locally. Being able to have your tests running locally (an important part of TDD) is much more efficient than pushing to a CI and waiting for test feedback. If your test suite takes an unreasonably long time or if you can’t even run it (whether because of missing configuration or environment limitations), you’ll make it that much harder on engineers who are making significant changes to the system. It can also be a sign that your application itself is getting too large and might need to be split up.

A good testing environment also lets you use the least amount of code and resources to maximize your testing coverage. That means using end-to-end tests for user flows and not for testing business logic. It means using a screenshot test for visual regressions but not for state changes. It means being able to test database changes in an integration test and not having to setup a staging environment (all silly examples but you get my point) You want to have different tools to test different levels of your system and make sure every engineer knows which tool is best suited to which situation. I’ve seen teams just get drunk on end-to-end tests (which are often much more expensive to run and change) when a unit testing suite would be just fine. I’ve also seen integration tests that are trying to simulate what a user would do when an end-to-end test would have made more sense. Identify what you need and make sure the team is aware of the strengths and weaknesses of each tool you have. Dev talks and mob-programming can be very helpful here. As often as you can buy off the shelf rather than build it in house. It'll make it that much easier to get up and running and you're likely to get the benefit of community and vendor documentation rather than writing your own.

Many people differ on whether it’s worth running CI on every commit for near-instant feedback or wait until after code-review or some other condition. I’m not strongly opinionated as long as you run the entire test suite on a development branch before being able to merge into master to avoid interfering with other engineers. Then run the entire test suite before deploying to production to make sure conflicts in code and logic haven't made it in and also as a sanity check. Test suites failing should block engineers from merging. I know this seems like overkill or that I don’t trust individual engineers but it’s actually cover for them so that they can avoid pressure to just “merge and fix after”. It also creates an opt-out culture rather than an opt-in. Often called [“The Default Effect”](https://en.wikipedia.org/wiki/Default_effect), it’s a powerful psychological phenomenon that’s used for influencing policies as varied as organ donation to voter registration and it works for engineering team testing policies.

Engineers need to be able to easily debug failing tests both locally and in CI. That means choosing a framework with robust and verbose logging but also storing history so that patterns can be observed between runs. Some folks fall into the trap of logging too much which can actually make it more difficult to debug issues. A good framework has sensible defaults but also the ability to modify the level and nature of logging for your unique situation. It’s also helpful to be able to share logging easily. I’ve always preferred hosted CI for most of these reasons.

One topic I don’t often see mentioned is making sure you have a way of avoiding CI interruptions due to third party service issues. For example, does your CI call out to a vendor API and if that API broke would you be able to push code? Folks are conflicted on mocking third-party services vs using sandboxes (obviously never use your production service). What I will advise is having a very simple and accessible way of turning off the test or dependency such that you can keep on working in the event of an outage outside of your control. Some dependencies won’t have a solution (like if your CI vendor or version control goes down) but as often as possible, ask whether you can continue to test and deploy even with this outage by adding simple configuration options to turn off the dependency.

## Other Practices

I could write an entirely separate piece on my thoughts on monitoring, alerting and logging and their respective uses. For now I’ll settle on making sure you realize I’m not advocating for testing instead of monitoring, alerting and logging. I think it’s important but that they solve a different problem than testing and are too often confused. Don't rely on alerting to catch regressions you could have caught before they were deployed. Don't rely on logging to see if a certain condition happens or not when you could have written a unit test.

It’s important to note that many organizations believe in manual QA at some point in the development process. Manual QA is a great role and can be used very effectively when done right. It’s not a replacement for automated tests and when possible QA should avoid trying to catch small regressions or verify system correctness. QA is too valuable to waste on doing something that a test can do. Manual QA should be used to test issues that are extremely difficult or impossible to automate. It should most importantly be used to verify correctness of the product requirements and determine whether new features adhere to the product and design spec.

## Failure

I’ve failed at most of this advice at some point or another. It’s mostly how I came to the opinions I’ve mentioned. A testing culture is something you just have to continually work at. There’s never a “there” that you can get to. If you come in with the attitude that there is an end-goal you'll disappoint your team when it never really ends. You should just start making incremental improvements and one day you'll realize how far you’ve gotten as a team. Make testing a priority, demonstrate its value concretely and reward positive advancements and you’ll be shocked at how much support you’ll get from your engineering team and your organization over time.


Testing Advice Part Two Or What Comes Next


A friend of mine worked as an investment banker right after college. As he described it to me, in i-banking you essentially have a very fixed career that comes with well defined [roles](https://www.mergersandinquisitions.com/investment-banking-career-path/). You start as a summer intern and (usually) from there you get an offer to come work at graduation as an analyst. From analyst you progress through associate, vice president, director and then managing director.

Many tech companies have a similar career path for both individual contributors (ICs) and engineering managers (EMs). In startup land, if you even have titles, roles are very rarely as well defined. By the far the least understood or defined role is the Technical Lead. The tech lead role is so hard to define that at my last company I actually ended up using the term “Team Lead” instead (in most cases) because it came with less baggage.

The tech lead is usually a senior engineer who has shown ability in technical execution, organization of work, communication with their peers and strategic thinking in their domain. The tech lead keeps a foot in the IC track but also stretches into areas that overlap with an EM. Since every team is different the following responsibilities aren’t universal but should be used as a rough approximation if you’re trying to understand what you might be doing as a tech lead or if you’re already a tech lead then some thoughts on how to level up. A tech lead role _can_ lead to a people management role but not enough engineers realize that it can be its own discipline. A good tech lead is invaluable to a team and very hard to hire.

## Quick disclaimer

As with all roles, a tech lead is just a hat you wear and not an expression of seniority in itself. Senior engineers are senior because of the way they carry themselves and their constant dedication to best practices, high performance and self-improvement. If you need a title to convey your abilities or authority (this word makes me feel gross) then you probably aren’t at the level you think you are.

And here’s where you call me a hypocrite for displaying my titles on linkedin. So why do we use titles? Besides getting your next job, titles are helpful in quickly setting expectations about what someone’s responsibilities and capabilities should be. But usually within a few minutes it’s easy to tell someone’s abilities (or lack thereof) outside of the title. That’s true of a VP of engineering as it is with a summer intern. Keep that in mind when you ask for your next title change.

## Delivery and Execution

By the far the most important part of being a tech lead is helping your team get sh\*t done. Most tech leads are part of a team composed of other engineers. Some may be more junior and some may be more senior but the tech lead must be able to aid in everyone’s work. That doesn’t mean literally being able to do another person’s work (especially for very specialized engineers) but it does mean that as a tech lead you might have some tools for helping others deliver their work on-time, within budget and with a high degree of quality. Some examples might be removing roadblocks for others or helping facilitate an engineer thinking through a design decision. The tech lead should be spending a healthy portion of their time keeping a pulse on the various projects in the sprint so they can quickly react when necessary to help out with work that is struggling along before it goes off the rails.

In fact, if it seems like your tech lead doesn’t often intervene but projects seem to be going really smoothly, that could be a sign that your tech lead is very good at subtle, discreet and effective assistance (or your team is just really really good and doesn't need any help.. It’s very case specific). Tech lead is definitely not a job for glory seekers and you will rarely get credit from anyone other than your manager (if she's good at her job) for the sprint running smoothly. It's only when things go very wrong do you get recognition and not always in a good way.

As a tech lead myself, I was often responsible for the delivery of work that I personally could not have completed with the same quality as an engineer on my team. For example, I’m not the strongest frontend engineer so helping someone else code a mobile responsive page is a losing battle for me. But what I can do is help them think through their work and use universal strategies like testing, chunking work into smaller problems, finding other folks on the team or outside the team to advise or being a [rubber ducky](https://en.wikipedia.org/wiki/Rubber_duck_debugging) when they get stuck. With a higher view of the organization I can also help find other examples where someone may have already completed similar work or may be facing a similar challenge. If the work is taking too long or is too difficult, I can advise and facilitate changes to the requirements or make recommendations on scope to cut.

It’s important to distinguish between helping and gate-keeping here. For example, “a tech lead should review as much as code as possible” is a good example of helping but “a tech lead should review all changes before merging” is gate-keeping and counter productive to the team. The tech lead should also avoid becoming a [bus count](https://en.wikipedia.org/wiki/Bus_factor) of one for any process (this also for your own sanity because at some point you’ll want to go on vacation). The tech lead shouldn’t be the only admin for a service or only contact for a vendor. The tech lead should also not be making all of the decisions directly but creating a space for decisions to be made by the team.

Ultimately the tech lead is responsible for work being completed but delegation is not only acceptable but highly encouraged and almost always a smart decision. The main driver should always be setting up others for success counter-balanced with keeping the team running smoothly. A really good tech lead will know when they need to do the research themselves or when they can delegate to someone else.

## Planning

My engineers are used to hearing me describe the tech-lead / product manager (PM) relationship as the most important relationship in a startup. That’s because the best effort-to-value ratio in any company is planning. An old manager used to say “weeks of coding will save you hours of planning”. This is both true and unfortunate that not enough teams realize this fact. Coding is very very expensive both in salary and in the opportunity cost of working on a different task. That’s why planning is a very critical component of the tech lead role.

Planning is a big word to describe a few different activities including acting as a partner to the PM to help turn feature ideas into technical specifications that can be worked on by an engineer. The tech lead knows their team’s code, the product itself and the business well enough that they usually can spot opportunities for simplification or risk better than anybody. When I was a tech lead I would sit down with my PM every week and we’d talk through the list of new features, bugs and tactical tasks and see how each one could be communicated to engineers and which seemed not flushed out enough to be worked on. It’s much less expensive to ask a PM to spend another day thinking through a flow than it is to have an engineer start working on a vague card and be blocked by a decision after work has started. Even worse is when that decision causes the task to be delayed or even scrapped (the horror of wasted work!). The tech lead is supposed to do everything in their power to guard against this happening.

The tech lead also knows each team member’s capabilities and can communicate whether the team has the resources in place to work on a feature. For example, if the task calls for integrating the left phalange and the team doesn’t have a phalange expert, the tech lead can recommend that the work go to the team with the expert or see this as an opportunity for someone on the team to get some experience with new technology and recommend training / learning prior to starting the task. This also means the tech lead has the best view on who should be assigned which work based on their abilities, preferences and capacity. Not every tech lead does the actual assigning of work but every tech lead should think of themselves at the very least as an advisor on the sprint.

One interesting dynamic between an EM and the tech lead is career advancement and technical learning. Strictly speaking I advise that a people manager should always be accountable for the advancement of every engineer on their team but the tech lead in their role as assigning work is in a unique place to advise the EM on upcoming projects that can fit the career goals of each engineer and thus the EM should keep the tech lead apprised of what work each engineer is interested in pursuing. For example, the Em can let the tech lead know that Jane is interested in learning about the thingamajig and when there is a task coming up to add a whatsthatthing to the thingamajig, the tech lead can let the EM know.

The last example I’ll add (and this is certainly not an exhaustive list) is technical prioritization. The tech lead is in a role where they can see across different projects to understand what is causing decreased productivity or unhappiness and either suggest prioritization or directly prioritize tech debt projects. In a larger organization with multiple teams, the tech lead can communicate with other engineers outside the team to find patterns and suggest larger technical projects. Often the technical lead will have to balance multiple competing priorities within the team especially as it relates to the trade-off between building for today vs building for months from now. The tech lead must use the information available to distill the technical and business context into the best decision possible.

## Communication

We’ve talked about a few different types of communication that a tech lead is either responsible for or is actively a part of. Communication is important for every role but for the tech lead it’s important to be well versed in talking to both technical and non-technical folks. In fact, one of the best qualities for a good tech lead is being a good storyteller. It's very difficult to convey subtle and nuanced technical issues to a PM, business stakeholder or executive without a colorful metaphor or example at hand. Engineers on the team will often look to the tech lead to help them describe a technical problem or sticking point in their work. Bridging that communication gap is one of the core parts of the tech lead’s role and often a big part of how a good tech lead starts to build credibility for themselves and the team with the organization.

That bridge works in both directions. A good tech lead will take the larger product context and paint a picture for their engineers which in turn helps engineers make better tactical decisions within their work. It can also be important to understand whether a certain decision actually matters in the long-run. Sometimes it's important to steer the team away from [yak-shaving](https://medium.com/@firehoseproject/a-guide-to-yak-shaving-your-code-d30f98dc759) (engineers love to shave that yak).

The tech lead can also be responsible for the team’s communication ceremonies (often just called the sprint meetings) like [estimation](/estimation-guidance-best-practices/), standup and retrospectives. Sometimes the tech lead is also responsible for processes like bug tracking, on-call or rollout communication. There are other important responsibilities that are situation dependent and can vary. One example is the tech lead of a team that is responsible for a database where the tech lead is responsible for reviewing risky migrations. The tech lead should help facilitate meetings (both intra and inter team) where it's necessary to reach consensus on a sticky subject.

Finally the tech lead can often be accountable for the technical documentation of the team. Documentation is due its own large conversation but in a quick summary, documentation can often come down to the culture of the team. The tech lead should consider themself responsible for pushing the team to be better at documenting new and changing features, preserving decisions and formalizing proposals in writing. This can take the shape of design docs, implementation details, diagrams and any other important artifact that helps a future engineer. A good tech lead is encouraging and not prescriptive about documentation. I would often not only publicly praise an engineer for great documentation but take the time to comment and share it more widely and do my best to loudly refer back to that documentation in the future to show its value.

## Contributing Code

There’s a reason I saved this for last and it's because it’s the hardest to get right as a tech lead. Universally a tech lead is expected to contribute code in some way. Many teams differ on whether the tech lead should be in the [critical path](http://epkatz.com/2020/05/15/in-the-critical-path-as-a-manager/). I won’t get into whether a tech lead should be coding 30% of their time or 80% of the time. That greatly depends on context, team size, company maturity and the skillset of the tech lead. Some tech leads are great at context switching and can jump in and out of code all day between meetings. Some find it much more difficult. What’s more important than how much code they contribute is what they contribute. A tech lead should always always embody the best practices of the team. There is no wiggle room here. If your tech lead takes shortcuts or takes a “do what I say, not what I do” approach to coding then there is a serious problem. Whether that’s focusing on design patterns, writing tests, refactoring code or adopting tools into your process, it’s critically important that the tech lead is (as much as possible) above reproach for cutting corners.

A few helpful tools for a tech lead to gain more leverage for their limited hours coding are code reviews, technical documentation, demos and pair programming. Code reviews allow the tech lead to spread best practices between the team and quickly (and kindly) nip bad practices before they make it past that team member. Technical documentation, especially guides and tips, can help engineers get up to speed and scales well asynchronously. Demos are a great way to showcase what’s possible and facilitate discussions on the team. In fact, sometimes I’ll just do a half-assed demo (aka a modified version of the [McDonalds’ approach](https://medium.com/@jonbell/mcdonalds-theory-9216e1c9da7d)) just to start a conversation on a topic without directly specifying that the goal of the demo is actually a consensus meeting.

Finally pair programming can serve several purposes. You can use it as a tool to teach or learn quickly. You can use it to encourage an engineer towards best practices. For example, I’ve often commented on someone’s code that they really should add a certain type of test and gotten pushback that it was “too hard”, that the code is “time sensitive” or that they’ll “add it in the next branch”. I can use pairing as a way to help them add the test together so it seems less scary and can get done quickly without just doing it myself. Pairing is also a great way to see if an engineer is using the latest and greatest tools, has an efficient coding process or to surface complaints about the dev environment that you might not otherwise hear.

## Challenges

We’ve talked about all the things a tech lead should do but one last very important challenge is aimed towards the tech leads who are already extremely capable. Tech leads sometimes fall into a trap where they are so experienced, so senior, so knowledgeable (hear the sarcasm in my voice) that they struggle with junior engineers who are not as capable. The tech lead then adopts a “I’ll do it myself attitude” and takes over a project, a pairing session, a meeting, etc. It’s important to remember that you were also once that junior. And even if you weren’t (ha!) you have to accept other engineers’ capabilities. I’m not talking about situations where an engineer should be let go for performance but engineers who are good at some things and need to improve in other things. Your frontend engineer might be able to work magic when coding but maybe doesn’t run a meeting very well. Your backend engineer might be a great planner but has a hard time explaining the technical plan to the PM.

You need to augment and amplify their voices, not steamroll them. I’ve seen too many tech leads just run roughshod over their team to get work done. It’s not scalable and will lead to resentment and long-term issues on the team. It’ll happen sometimes. It always does. But the trick here is to constantly be evaluating yourself so you can do better next time and obviously point it out and apologize to the person you hurt.

## Keep Going

This isn’t meant to be an exhaustive list or try to capture everyone’s experience. I took a hard look at what worked for me and some of the best qualities of the tech leads I’ve managed and tried to turn that into a small set of roles. Your own tech lead experience must differ widely. I mentioned at the beginning of this (rather longer than I expected) post that a senior engineer is concerned with self-improvement. There are many great resources out there to read further but I highly encourage [The Manager’s Path](https://www.goodreads.com/book/show/33369254-the-manager-s-path) which was given to me by my former manager when I started to think about leadership. It will not only dive deeper into what a tech lead is but will put it into context within other roles in the organization.


What does a tech lead do?


When an individual contributor becomes a team lead or manager one of the hardest challenges to overcome is removing yourself from the critical path. I’ve failed at this multiple times but I’ve found that there is a pattern to my failures. They’ve all come from a slow burn rather than trying to take on something large from the get-go.

My biggest failure was becoming the de-facto data analyst after our original data analyst left the company. Don’t get me wrong, I’ve enjoyed learning about the data stack and being part of the data community (shoutout [dbt](https://www.getdbt.com/)!) for a while now. The failure is that it came at the expense of the time I should have been dedicating to people management.

## The seeds

It starts slowly. In my case our data analyst was on vacation and I decided to help out with a few tasks. Slowly those tasks turned into an on-going project because I knew the code the best. I found myself enjoying the work so I didn’t mind when there were additional small tasks added to the project. I didn’t feel like I was in the critical path at first. I would get some of it done in the early mornings or late afternoon and no one ever felt blocked.

For you this might start as a small internal tool or an IT issue. Maybe you’re helping a team that is under-staffed. At this point it might feel nice to contribute code again and you tell yourself it won’t escalate any further.

## The turning point

Our data analyst had a few vacations and life events in a row and I found myself as the part-time data analyst. At this point I should have brought other folks into the fold so that they could also do the data work. My responsibility was to be a people manager first and not an IC. If I had trained a few engineers on the data work then I could have taken a step back. That’s what I should have done. What actually happened was that I just took over more and more until it was taking up several days a week.

After a few months our data analyst decided she was going to leave for a different adventure (very excited for her!) and her end date was coming up. At this point I also could have decided to bring more engineers into the process. Instead I decided I would be the data analyst until we could hire a replacement. I felt at the time that if I could do all of the work for a while then I could spare engineering from the extra workload. I also felt guilty to offload this work that I was perfectly capable of doing. Several people warned me against doing this. Their point was that I would burn out and do both jobs badly. They were right. I didn’t listen though.

## Crash and burn

So I found myself with no data analyst and all the data work. On top of that I had to hire a new data analyst and be the people manager for the team. I’m honestly shocked I didn’t burn out sooner. I ended up doing a mediocre job at all three tasks. I introduced several avoidable bugs into data that could have been prevented if I had been more focused on just data work. I also neglected part of my people management responsibilities and didn’t prepare as much as I normally would have for 1:1s and other meetings. I’m pretty good at winging it so most of the time I got away with it but there were definitely moments I wish I could do over. There were many opportunities for me to bring in another engineer (or several) to help me out but I stubbornly thought I could handle it.

A really bad side-effect was that I was very lax about how work was prioritized because it was just my work. Normally I do everything I possibly can to protect engineers through a very healthy sprint process. But if it’s just me.. “Sure I can do that this week”!

I distinctly remember the moment I finally realized how bad I had let it get. I was working on a report for some financial work and for the first time in my career I just didn’t test anything. I just shipped it and moved onto the next thing on my list because I was so stressed. I didn’t have an engineering manager to catch me the way I would help my engineers. Well you can guess what happened, right? It obviously broke and I had to fix it a week later when someone discovered my really embarrassing mistake (luckily he was cool about and it didn’t impact too much).

On some level I also enjoyed being the only person working in this repository. It felt like a freedom I had lost when our team had grown. I didn't have code reviews or standards for myself. I occasionally pushed directly to our master branch. I did everything I always preach not to do because I just needed to get the work done as quickly as possible.

## A better way

I ultimately started bringing the data work into the regular sprint and having other engineers do the work while I paired with them for training. It was easy for me to give up the systems I knew best and loved working on when I became a manager. It was much harder for me to recognize that I was slowly taking over a critical path as it was happening much farther into my management role. If you are a blocker or resource that is counted on for coding and you put that work ahead of your people then you’re failing.

If I could do it over I would have considered data work the same as product feature work. As often as possible the engineer responsible for the production change would also implement the data change. For projects that didn't have an obvious owner, we would prioritize an engineer's time against the other priorities in the sprint. Ideally this would continue until we hired a full-time data analyst. I believe had I gone this route the team would have understood how their changes to the data model impact our metrics and proposed more robust plans when making data model changes. In a way, I robbed the team of additional training by trying to "spare them". In fact, I wonder how often managers end up keeping engineers from gaining additional skills in a misguided attempt to spare them work.

As I’ve talked to a lot of different companies I see that there are many philosophies for how much code a manager should contribute. I don’t yet have an opinion on volume but I do feel strongly about content. Stick to bugs and small features or projects that don’t have firm deadlines. Try and make sure that at least one other engineer has context on what you’re working on in case you need to hand it off without warning due to your main responsibilities. As a people manager you owe it to your team to always put them first.


Don’t be in the critical path


I believe in estimation of software projects because I’ve found it works well when you do it for the right reasons. I know estimation is a controversial topic so I thought I’d add my own opinion to the chorus of voices advocating the pro side. My only disclaimer is that my experience is entirely based on startups so this may not apply to larger companies or other industries.

## Relative Estimates

First and foremost I never give exact timelines in estimation. I’d rather use some abstract buckets (e.g. t-shirt sizes, points, types of hot dogs.. don’t ask..) over asking an engineer to give me a specific hour or day estimate. People are very bad at absolute estimations. If you ask someone to estimate anything, they’ll usually get it wrong unless they have very specific previous knowledge. But if you’re given _relative_ sizes it makes it much easier to estimate.

Let’s look at an example. I live in Brooklyn and I want to estimate the length of the Brooklyn Bridge in feet. Since I have no idea how long the bridge is I’ll swag it (scientific wild-ass guess). I’ll wait while you take a shot at it. Ready? Ok so the bridge is about a mile and a mile is roughly five-thousand feet so let’s say that’s my current best estimate. Before I tell you if you’re right (no cheating by looking this up) let me give you some more information. The Brooklyn Bridge is shorter than the Williamsburg Bridge which is seven-thousand three-hundred and eight feet and it’s longer than the George Washington Bridge which is four-thousand seven-hundred and sixty feet (I’m using words rather than numbers so it doesn’t draw your eye while reading this). So now that we have a relative size let’s take another shot at this! I’ll take the average of those two bridges and guess that the Brooklyn Bridge is six-thousand and thirty-four feet. That’s much much closer! What if I told you that the Manhattan Bridge was longer than the Brooklyn Bridge but shorter than the Williamsburg Bridge? Would you guess the average which is six-thousand six-hundred and seventy-one? That’s also pretty close to the real number (see the bottom of this post for the actual numbers!). Because we have relative sizes and accurate prior knowledge, we can apply those values to our new estimates and get near accurate results.

How can you apply this to software engineering? Well Ally and Bob both built widgets last month and now Conrad needs to build a widget. Ally, Bob and Conrad all estimate the relative effort of building a third widget. Ally says it’ll be a medium task and Bob says it’ll be a large task. They talk it over and decide that given their experiences this widget should also be considered a medium task. Most medium tasks on the engineering team take 2-3 days and thus a relative timeline is communicated to the product manager, Deloris. Relatives sizes work well when looked at in aggregate. That means on average the tasks will be accurate to their estimation. Some tasks will be overestimated and some under-estimated but the roadmap timelines will ultimately be close to what happens in practice.

## Scope

Our story doesn’t end with estimation. Deloris is now going to take the estimate and decide whether the value of the widget is worth the approximate estimate. Deloris also has another card to play. She’ll ask the engineering team whether there are ways to reduce scope. Ally mentions that one of the hardest parts of building a widget is the phalange (especially the left phalange which is very tricky) and without it the task would be small. Deloris agrees and the task spec is updated to reflect the new requirements. Deloris can also decide that the phalange is too important to cut. Having the trade-off made explicit is a goal of estimation. There are other ways to expose the trade-offs without estimation but with estimation it becomes a natural part of the conversation.

## The Conversation

The conversation before and during the session is where estimation really shines. If the team is only going through the motions to slap a size on each task or rushing through the session because there are too many tasks to estimate then you’re missing an important part of the exercise. You can start by talking through the different parts of the task and trying to find hidden complexities that change the effort calculation but avoid trying to plan out the entire feature. It’s enough that you understand the requirements and have a sense of possible solutions rather than mentally building out the feature in the session. Planning everything out will take too long and won’t be as exhaustive as one might expect because the engineers aren’t actually sitting in front of code with the ability to try ideas and see additional issues.

Once you have a good understanding and an estimate, the product manager can actually probe the estimate with questions to see where scope can be cut or requirements can be changed to lower the estimate. It’s important that this is done collaboratively rather than accusatory so that engineers don’t feel obligated to lower their estimates against their judgement.

## Commitment

Finally the act of estimation means that every engineer on the team is committing that they understand the goal of the task and they believe it’s within reason to be worked on. Giving the engineers time to reflect on what work will soon end up in the sprint and whether it’s a reasonable task creates psychological safety on the team. Obviously they still have the ability to discover new information that will change the effort of a task but in most cases that won’t happen if you’ve followed a good estimation process. Keep in mind that there are many factors that influence estimation:

- Bad Assumptions
- Anchoring
- Presentation
- Dominating personalities
- Peer-Pressure
- Optimism
- Varied skill sets

Pay attention to team dynamics in every estimation and try to head off any of the above issues. Many of these factors will pop up outside estimation as well but won’t be as noticeable.

When execution is _consistently and significantly_ different than the estimates it can impact team morale. Projects are rushed which leads to bugs and more time is spent planning in the future and retrospecting what went wrong. That’s why it’s not only valuable for engineer’s happiness but it can impact productivity and perception of the team.

## Summary

### How to estimate

- Estimate your tasks relative to each other
- Time limit conversations
- Use a small number of values (S, M, L, XL or 1,2,4,8)
- Don't use time estimates.. or even infer time estimates
- Re-calibrate your estimation values periodically with real examples
- Have a strong transparent culture that encourages engineers to raise their hand when a task balloon

### The act of estimating

- We're not good at estimating in absolutes but we are good at comparing things.
- When asked to make decisions with incomplete information we rely too much on the information we do have.
- When people of different experience estimate, we tend to follow a leader ("anchor") that biases our estimate.
- People of different skill levels will have vastly different estimates.
- Our motivations have a significant influence on our estimates.
- The presentation of information can change our estimates.

(These are the values for the example above)

- Williamsburg bridge - 7,308′
- Manhattan bridge - 6,855’
- Brooklyn bridge - ‎6,016’
- George Washington Bridge - 4,760′


The best estimation guidance I have so far


When I took over my first engineering team I thought deeply about my core philosophy for an engineering team and how that might impact my decision making. I try (and occasionally succeed) at being as consistent as possible so that engineers on my team have a good sense of what they can expect from my thought process. Most of these thoughts are not original but I think they form a good basis for how to approach thinking about startup engineering.

- The main purpose of a startup engineering team is to solve business problems with technology. Everything the team does must be taken within that context and must always ask how does this work impact the business?

- Focus on building systems around core competencies and use open-source or buy technologies for already solved problems.

- Startups usually operate without existing patterns to build on and to succeed they must experiment as often as possible on new ideas around the business. The engineering team is the "tip of the spear" building most of those experiments and the tech stack needs to enable that ability.

- Velocity (the rate at which new features are shipped) is a competitive advantage for the business and therefore a good team dedicates time to increasing velocity through improvements to their systems, tooling and code.

- Improving code without a business objective should be considered wasteful but it's not necessary to always prove every single improvement has a defined impact. Sometimes it's important to trust that the ROI is self-evident when there is team consensus or has been proven in the tech industry already.

- There is no team without happy engineers so keeping an engineer happy and productive is a very good reason to focus on improving code or tooling.

- Don't be dogmatic. A good team continuously reflects and evolve how they think about their technology and what the stack should look like in the future. That means every tech stack should be considered a work in progress and will constantly be under revision.

- Startup engineering necessitates making trade-offs that over time will no longer seem like a good idea. Try and approach past decisions without seeking blame and instead recognize that there were probably decent reasons at the time the decision was made.

- Smart engineers know that not every decision will go their way. Make sure your team gives you reasonable time to make your best case for why you believe in a certain decision but learn to commit to an outcome you don't agree with when you aren't able to convince others.

- Creativity comes from feeling safe to fail. Failures borne from good intentions and process should be celebrated because there is always a learning in failure. Build an engineering team that feel safe to fail or you'll build an engineering team that is scared to try.


My philosophy on startup engineering teams


# Reflections on my time at Wonder

Today is my three year anniversary at [Wonder](https://www.askwonder.com).

I won't go into the entire story of how I ~~fell ass-backwards into~~ became the head of engineering but as I'm leaving Wonder soon I thought I would take some time to reflect on many of the lessons I've learned and record them here.

I've been very lucky to have many great mentors, books, blog posts, networks and friends to ask questions and seek advice. I truly stand on the shoulders of giants and want to contribute back some of my own thoughts to pay it forward.

I'll do my best to cite sources when I remember where I heard something but if you notice an idea copied from somewhere else that I didn't cite please let me know!

As for most things you read on the internet, take everything here with a healthy dose of salt.


Tech and other stuff