Tech Lead Survival Guide

When I first started my job as CTO at MoveOn 3 years ago, I was immediately overwhelmed: within hours of logging on for my first day I had 100 unread emails, a new all-remote organizational culture to figure out and navigate, I was plunged into the midst of a high stakes platform and data migration I didn’t yet have any context or history about, I inherited an undocumented budget and legacy codebases, and I was tasked with hiring a team, building a data warehouse and figuring out “what exactly we should do with the website.”

More or less flying by the seat of my pants, I dove into intel gathering mode — talking to everyone, mapping out the organizational structure, mapping out the systems and structures and expectations I had inherited. I dove into the projects of running a hiring process, building the data warehouse, and co-leading the ongoing platform and data migration, while making huge, high-stakes, and hard to reverse decisions with only partial information. After my first 5 months I had a team, a data warehouse, a successfully launched migrated platform. I had a clear idea of the tooling and content management ecosystem, which tools I wanted to preserve, which tools I wanted to sunset, and what my team should probably build next. This period was a blur of excitement, overwhelm, and adrenalin, and at the end of it I was so proud of what my team and I had accomplished. Then, I wondered, does it get easier from here?

The answer as you can probably guess is no. Leading a team that directly serves so many other teams — at a well-established and well-known organization with more than a decade of history, processes, and legacy code, that does advocacy work on a national scale — means that there are always new, huge challenges on the horizon, and there will always be more work than any one person can handle at any given time. I quickly realized that I needed to become extremely careful with my time and my team’s time, and communicate very clearly what we were doing and not doing, so that we could work at a sustainable pace and ensure that we were working on the right work at the right time.

This period was exciting and overwhelming, and exactly the challenge I was ready for, but it was also stressful because there was no playbook for how to pull clarity out of chaos, and handle the overwhelming communication and myriad competing priorities. This essay is a letter to myself 3 years ago — the guide book I wish had existed. I hope it’s helpful to others who are stepping into new technical leadership positions.

A Different Kind of Problem Solving

When I was a software engineer, and also when I was a software engineering manager, I generally had the experience where the longer I worked on a codebase, project, or domain, the better I understood it and the more efficiently I was able to work. Coding experience compounds, and to level up I could write more code, or write more complex code, or take on risky refactoring projects, or learn how to scale up systems. The intellectual space I worked in was clear and self-documenting: if I didn’t know what a section of code did, I could run it and debug and inspect it. If I wanted to understand the full context of past decisions made in a codebase, I could look at the history of checked in changes. In general, most questions I could ask about a software system I could answer myself, if I dove into the details.

Being a CTO is the opposite: every month there’s some totally new and high stakes challenge coming out of left field that is not at all related to the previous big challenge, and sometimes it’s not possible to get complete or even sufficient information before making a decision. The intellectual space of the challenge is hardly ever clear and documented. If I want to understand the full context of past decisions, I have to find people who were around when the decisions were made, and sometimes I can’t. Every decision I make has tradeoffs that are hard to estimate, and impacts not just me but my entire team, and sometimes my entire organization.

While I was ready for this new challenge, I had come of age in the typical tech industry culture that worshipped ‘cowboy coders’, and generally didn’t respect management, and so I had no language for what my role was or should be. My best guess was I would be someone who solved organizational problems with technology and made hassles go away for the software engineers. Initially I had assumed that I’d do some upfront management bootstrapping work like hiring my team, and then we’d spend most of our time coding together. Soon I realized that the unit of productivity as a CTO was not lines of code written, but decisions made. Making decisions is hard.

Map The Organization and Assess Expectations

The first step in taking a technical leadership role at a new organization is the same as the first step in taking any kind of leadership role at a new organization: you need to map out how the organization works, and in particular map out expectations for yourself and your role. What are the current processes? Who is in which roles? Who are the deciders and stakeholders for processes and projects you’ll inherit, work with, or create?

My first instinct was to try and reverse engineer the expectations of this role from talking to the key organizational stakeholders. I asked a series of open ended questions to an initial set of stakeholders, followed the answers to the next set of questions, followed team and project references to the next set of people to talk to, and repeated until I had answered all my open questions. I was also fortunate to have a few hours of access to the previous CTO for knowledge transfer. Since I was joining a well-established organization with a long history of past decisions that had been made, and many of these decisions had financial implications, I found it helpful to start with questions to the previous CTO about the inherited budget and accounts:

• For each budget line item, why was this service purchased and what was it used for? Who made the decision? Which teams or processes did it serve?
• For each account you had previously managed, why does this account exist? Who decided to adopt it and which teams or processes did it serve?
• For each process identified by budget and account questions, how long was it in place? At what times of the year? Which teams and stakeholders were involved?
• What processes were you personally responsible for managing?
• What processes did you have to sign off on?
• What meetings or working groups did you get asked to join? What did you say yes to? Why? What did you say no to? Why?
• What else do you remember spending your time on that I should know about?

After gathering info about teams and processes from the previous CTO, I met with each stakeholder identified in the CTO’s answers, and talked about what processes they were involved in, their past interactions with tech, their experience and their expectations.

I wrote down everything and paid particular attention to the implied norms that had been set on how tech and the rest of the organization interacted. In aggregate these early meetings were exceptionally helpful in understanding how the organization worked, and how the tech team had worked within the organization.

I also found that I didn’t need to prepare much for these stakeholder meetings, that all I needed was to show up with the agenda item “what do you think I should know?” and be ready to listen.

Consider The Stage of The Organization

The First 90 Days is worth a read for any new leader. It’s a guide on what questions to ask and what to do in the first 90 days in a new leadership position. I found the following prompts to be particularly helpful:

1. What stage is the organization in? This book uses the STARs model: Start-up, Turn-Around, Realignment, and Sustaining Success. An organization’s stage matters because it’ll determine what organizational resources are available, the organization’s top-level priorities, what types of problems are likely to be encountered, and how teams are composed and staffed.
2. How can I match strategy to situation? There are lots of leadership strategies, and especially if you’ve been in leadership roles in the past, one common pitfall to avoid is rolling out processes that have worked in the past, without carefully considering the stage this organization is in, and this particular team and situation.
3. What “early wins” can I secure? It’s always a risk to bring a new leader into an organization: new leaders have significant positional power, and initially not enough context to understand current and past challenges the organization has faced. New leaders have to quickly establish trust and gain the confidence of the organization to be successful. One straightforward way to do this is to identify and roll out “early wins” — changes that show what your priorities are, and are an early glimpse of what kind of impact you’ll have over the long run.

After my early conversations with leads and stakeholders, I determined that tech at MoveOn was in a Realignment state according to the STARs model. Using The First 90 Days playbook, this meant I needed to redefine the role of tech at this organization, restructure and refocus tech resources, deal with deeply ingrained cultural norms that were no longer helpful, and carefully shepherd changes in a way that was respectful of current processes and organizational history.

I also acknowledged that while I had worked at organizations in the the Start-up, Turn-Around, and Sustaining Success stages, I had never been a part of a Realignment before, and so would need to be careful not to reuse strategies that worked in previous situations that weren’t appropriate here. And I decided to focus on planning some “early wins” that demonstrated that change in tech processes was a positive thing, that benefited and involved the rest of the organization.

Create a Personal Roadmap

After identifying the organizational stage I believed MoveOn to be in, mapping out organizational projects, processes, roles, responsibilities, and identifying what tech had owned in the past and why, I was now equipped with enough information to create my own proposal for what I should own, and what my team would own.

I published this proposal to my boss, the leadership team, and the key stakeholders I had met with earlier, got feedback and ratified this as my personal roadmap. I took special care to note how roles and responsibilities would be different between myself and the previous CTO, and the newly hired tech team. Here are some excerpts from this roadmap.

Things the previous CTO had managed that I will also manage:

• Annual budget planning
• Admin-level account management for core systems and services
• Regulatory data policy management: FEC reporting, PCI compliance, GDPR
• Build or buy choices for core tech systems

Process needs I identified that I will create and manage:

• Tech Team Hiring
• Tech Team Management
• Policies and standards around staff and org cyber security
• New system for tech support/ rapid response technical problem solving
• New forums and norms for how to interact with tech team

Processes that I’ll sunset:

• Making staff update the perl-based intranet by editing and checking in HTML directly — replaced with a self-service internal wiki
• Making staff update the perl-based public facing website by editing and checking HTML directly — replaced with Wordpress and training on how to use Wordpress’ admin interface
• Tech realms: instead of 1 engineer per project who has to handle all development, project management, and product management, we’ll centralize project and product management, and all developers will work on all systems

Now I had a clear sense of the realms my job involved, what I would own and not own, and where I would need to make decisions. The unit of productivity as a CTO is not lines of code written, but decisions made. But even with clearly defined realms, making decisions is still hard.

Conquer Time Management

To be able to make good decisions, first you need control of your time. You need to figure out what the landscape of possibilities is, and get the necessary context to be able to define and measure tradeoffs.

One great and terrible thing about holding a position of power at a well-known organization is that suddenly everyone wants to talk to you! Within a month of becoming the CTO of MoveOn, I found my calendar filling up week after week with meetings that had some nebulous value for the other party, but not a clear value for me. I didn’t know which meetings to say yes or no to. And I found that it was very easy to spend lots of time consuming the overwhelming amount of communication and relevant news related to the progressive organizing space, but then run out of time to engage with urgent team issues. Or the reverse: it was also easy to spend all my time with my team and then feel disconnected from the larger organization or movement’s work. How to balance this?

I soon realized that my time was the most valuable and most scarce resource that I had, and I needed strategies for spending it intentionally and fairly. And that I was responsible for a new and constantly changing landscape of responsibilities.

Build The Habit of Tracking Time

Inspired by Laura Vanderkam’s time tracking experiments, I started tracking my time in detail. There are a variety of tools for this, like google spreadsheets and toggl. The tool itself doesn’t matter, just the habit of tracking your time. Every week, I tracked every task I chose to work on from start to finish, along with the category of work that task was a part of. I tracked my morning email time, 1–1s with staff, tech team meetings, time spend reviewing code and pair programming, researching different framework options for an upcoming design decision. At the end of each day I had a log of where my time went.

I started tracking both tasks and task categories. As I tracked my tasks, I found that most of the tasks I work on fit into the categories of: software management, cross-team communication, cross-organizational working groups, tech strategy and architecture research, hands-on tech work like pair programming, and technical thought leadership like speaking at conferences and writing articles like this article.

At the end of each week I looked at my time logs and looked for patterns. Did I spend time on tasks that in retrospect were not important? What did I not get to that was important? What could I have said no to last week? Did I make space for the wildly important, or let my day fill up with tasks that were less important?

Then I analyzed where I spent my time by category: how much time total did I spend on communication? Management? Did I get enough time on hands-on technical work? How clear or split was my focus?

Analyze Time and Look for Insights

Reviewing my weekly time logs, I quickly discovered patterns that gave me insight into where my time would go by default, where I actually wanted my time to go. This helped me set more intentional goals around what I did and did not have capacity to carry at any given time, what to delegate, and what to say no to.

For example, I soon realized that staying 100% on top of my email inbox was not worth it, but hard to pull myself away from out of fear of missing something important. The progressive organizing space is all about the written word — many organizers do their planning and collaboration in email, much of staff work product ends up in emails or blog posts — and as a result I get about 800 emails a week on a slow week. I need to skim at least half of these emails to stay on top of emerging campaigns that will impact or are impacted by the work my tech team does. Tracking my time, I realized by default I would spend 8–12 hours in email every week- more than a whole day of time! Unlike other teams, email communication trades off against my actual work product, which is technical problem solving, software systems built and scaled. I couldn’t justify spending this much time in email. So I came up with a time management intervention: I stopped reading email sequentially, and instead developed a personal email filtering algorithm that used gmail filters to put emails into priority tiers by project and topic. If I only had 5 minutes, I’d only read the top priority tier emails. If I had more time, I’d work my way down the priority tiers. After tuning the filters for a few weeks, I ended up with a good enough system, and managed to stay on top of email communication for my top priority work, skimming everything else once every 1–2 weeks, getting me down to 3 hours per week spent on email — a savings of a whole day per week!

Tracking time week over week also helped me to understand how much time I needed to commit to different types of projects and responsibilities. I discovered that the cost of being on any cross-organizational working group was 2 hours a week as a participant, and 4 if I was leading the group. As a result, I decided I could only carry one of these types of projects at a time, and this helped me to refine my focus and say no to additional working group responsibilities.

I discovered that staff performance reviews took 20 hours a quarter to write and deliver every quarter, that an annual budgeting process took 10 hours, running a hiring process takes 25 hours over 6 weeks, and that team management takes 10 hours a week of non-negotiable team meeting and 1–1 time. Armed with this clearer sense of recurring obligations and required time, I began to understand how much of my time was available when, and then was able to start spending it more intentionally.

Time Management Strategies

I found the books Deep Work by Cal Newport, and Getting Things Done by David Allen to be very helpful for developing time management strategies.

Getting Things Done encourages you to track ongoing work and projects as ‘open loops’. When people ask you to do things or answer questions, if it will take less than two minutes, just do it then. If it’ll take longer, figure out what the ultimate goal is, what’s actionable and capture it as an ‘open loop’. Before switching attention away from an open loop, write down the next actionable step, so that when you return to the task it is immediately actionable and you don’t have to waste time pulling yourself back into the full context of the project. This is helpful when ‘work’ involves not just code but tracking communication through email, and you have ~10–20 active projects that periodically need followup.

Deep Work encourages you to separate out cognitively demanding “Deep Work” from not cognitively demanding “Shallow Work”, prioritize “Deep Work” first, create the right amount of focus time required to successfully do Deep Work, and fiercely protect this time. For me, roadmapping, build or buy decisions, crisis intervention research, budgeting, and writing both words and code are all Deep Work. While code reviews, email, consulting to other teams, administrivia like expense reports, stakeholder followup, and social media are Shallow Work. It’s easy to let your day fill up with Shallow Work, so instead aggressively carve out time for Deep Work focus sessions (for me, this needs to be 90 minutes at a time), and let the Shallow Work fill in around these focus sessions. This is similar to the “Big Rocks First” concept from many management philosophies.

Focus on the Wildly Important

Once you have time management systems in place that work for you, and guided by your personal roadmap, the next thing to figure out is how to spend the precious time you have day to day.

By default, as a leader it is easy to spend the majority of your time capturing needs and requirements, growing your to do list. Most emails are asking for something: advice, time, decisions, permission, resources. Most meetings are a place where work is discussed but not done. It’s easy for your whole day to fill up with activities that either add items to your to do list, or prevent you from working on your to do list. The result is a sense of overwhelm and of constantly getting more and more behind. What to do?

Every hour of every day you’ll be making decisions about what is most important to spend your time on —and every time you do this, you’re applying your own personal decision making algorithm to your time. Regardless of what your decision making algorithm is (or whether you think you have one — you do), you need to know how well it’s performing, and tune it to become better over time. You need to set clear goals, stay focused on these goals, and engage with a feedback loop that tells you how well you’re doing at meeting your goals.

Set Clear Goals:

1. Set goals at the beginning of every week: what are the 2 or 3 things you must accomplish this week? Is there space on your calendar to do this work? If not, cancel or push back meetings until there is.
2. Set goals every day before reading checking email: what’s the one thing you must accomplish today? Write this down before checking email or walking into the office, and keep focused on it even as you start to interact, and start receiving new requests for work.

Carve Out Time For Goal-Related Work:

1. Get work blocks on your calendar: other people take your time by scheduling meetings with you. You can use and protect your own time by scheduling work blocks on your calendar to carve out time for important work, and make sure in particular that you have sufficient time to start and complete cognitively demanding work.
2. Do or delegate? While most requests for work done will flow through you, you’re responsible not only for your own work plan but also your team’s work plan. It can be easy to accidentally hoard or bottleneck work and then get overwhelmed. Default to delegation whenever possible. A good rule of thumb is to only do the things that only you can do. Delegate the things that you’d only do a little bit better. Give your team real ownership and responsibility.

Stay Focused on Your Goals:

1. When overwhelmed or in doubt, hold onto the clarity of that one thing that’s most important to do right now. What choices drive you towards your daily or weekly goals? When you’re fully rested and working at a reasonable pace, you have the cognitive capacity to assess a whole landscape of options and make careful decisions. But if you’re on hour 12 of a busy day of firefighting, you’ve probably hit decision fatigue. When you’re in this state, don’t try to make more or new decisions, just focus on that one most important thing, and then pull back up and reassess the situation when rested.
2. Trust your judgement: when exhausted or overwhelmed, it can be easy to start doubting or second guessing your judgement. This can cause you to flip back and forth between tasks ineffectively, or lead you to redirect your team in unproductive or confusing ways. Make strategic redirects judiciously, as they have a high cost to productivity because of team context switching. And remember, after a few months at a new job or a few weeks at a new project, you actually do have the context you need to make good decisions.

Feedback Loop:

1. At the end of the day, check whether you met today’s one goal. Write it down and don’t spend more than 5 minutes thinking about it. If so, what did you do right that made this possible? If not, how could you have rearranged your day to meet this goal?
2. At the end of the week, check whether you met your 2–3 stated goals for the week. If so, what did you do right that made this possible? If not, how could you have rearranged your week to meet this goal? Were there meetings you could have pushed off to another week? Problems you should have delegated? Don’t spend more than 15 minutes on this.
3. In particular, I find it helpful to keep running lists of “Things that were definitely worth spending time on” and “Things that were definitely not worth spending time on” — I jot new items down as I encounter them, and if I’m facing what feels like a new quandary or I’m tired and have simply hit decision fatigue and I’m having trouble making a decision, skimming these lists helps me look for patterns that the new task could fit into, to guide my decision.

The most important part of tuning your personal decision making algorithm is not which goals you set, but taking the time for a feedback loop. With feedback, you’ll get better and better over time.

Tune the Personal Roadmap

After researching, defining, and ratifying my personal roadmap, now I had a big list of things I would own and my team would own, I had clear realms within which I would be the key decision maker. Armed with time management strategies and personal feedback processes, every day I felt like I was spending my time more intentionally. Auditing where my time went within particular categories, I realized that for technical leadership positions in particular, I needed to very carefully and intentionally figure out how my time would be split between the key realms of software engineering, software management, and organizational leadership.

The world of software engineering is always changing and evolving, but there is more or less a standard playbook of what a software engineering job entails — architecting, building, testing, scaling, fixing, launching code in some set of programming languages and frameworks. Most engineers have a similar typical daily routine, and most managers give engineers clear expectations on what work they should do, in what ways, on what timelines.

Software management is more nebulous, but typically involves people management, technical decision making, Building a Software Engineering Culture Where Everyone Can Thrive, and depending on the size of the organization, some amount of project, program, and product management.

Organizational leadership involves defining how your team interacts with other teams, defining what role your team serves within the larger organization, and it involves some amount of “steering the ship”, participating in discussions about what the organization should focus on, what problems it should solve, how it should grow.

There’s no one right answer here — at different times technical leaders might have to spend more time in one realm, and then as projects launch and organizational contexts change, focus might shift. The important part here, like with time management strategies, is to be intentional about where you are spending your time. In particular, it’s important to be aware of which of these areas are comfort zones for you. You’ll naturally gravitate towards comfort zones, especially when tired or stressed. Are you more comfortable coding than you are making decisions about how to operationalize upcoming regulation changes? It’s possible that you’ll procrastinate the regulatory decision with a really interesting coding challenge that suddenly falls on your plate. It’s important to be aware of which areas are comfort zones and which areas are growth areas, and make sure you’re spending your time intentionally in the right areas at the right times, and in particular that you’re spending enough time in growth areas.

Probably the one area most new technical leaders have a dearth of experience in is organizational leadership. The best way to get better at organizational leadership is just to do more organizational leadership.

But this can be all-consuming, as there are always more projects that need oversight, problems that need interventions, and teams that would love to pull you in to help. A key challenge I regularly face is to figure out how to do significant organizational leadership while staying technical.

Stay Technical

Technical leadership involves not just making the best use of your time, but also staying on top of a rapidly evolving landscape of tools, systems, and standards. Every few years ecosystem standards change that determine which problems are easy or hard, expensive or cheap, scalable or bottlenecked. To me, this is the most exciting part of working in tech, but it also presents unique leadership challenges. As a technical leader, it’s not possible to actually read all the code, monitor all the changes, manage all the systems, experiment with all the new tools and frameworks, read all the articles. Even if you managed to clone yourself a few times and tried to do everything, you’d probably drive your team crazy with micro-management.

The challenge is to figure out what technical work to do vs delegate, and at what level to stay involved in the technical details without bottlenecking work or micro-managing. Here are some strategies I’ve found helpful.

Look for the complexity, and front-load it: what are the biggest upcoming technical challenges that your team will face in the next 6 months? This could be the ticking time bomb of legacy code weighing a production system down, a system that needs to scale up 10x, a new regulatory change that will impact how your team does its work, a decision about whether to invest in a new system or product line. You likely wont be able to solve all the problems in this space yourself- you’ll need your whole team to work on it, but you’ll need to be well versed enough with the landscape of possible solutions to be able to point them in the right directions, frame the key questions, and be fluent enough in the tradeoffs associated with the space to be able to bring stakeholders along. You can generally identify these areas as the things on your todo list that seem most unbounded or terrifying. Get Deep Work focus blocks for this realm on your calendar and start digging in. Create deadlines and accountability for yourself on these challenges by scheduling meetings with stakeholders to introduce them to the challenges and tradeoffs that they’ll later have to make decisions on.

If you do hands-on technical work, prioritize the work that unblocks the most people: while it can be tantalizing to gravitate towards the technical work that was the most fun when you were an individual contributor, or technical work you’re most confident you know how to do, if you pick up technical tasks that other team members can also do, you can easily end up hoarding or bottlenecking work, and at worst disempowering your team, who also want to work on the fun stuff. Save the tasks that have the most technical glory for your team, and instead focus on picking up the tasks that unblock the most people days- that monster pull request everyone has been shying away from, the annoying database migration that will take hours to babysit, the build or buy decision that comes with the greatest risk. The greatest value you can provide in a technical leadership position is not coding 2x as fast as the software engineers on your team, but rather finding ways to unblock or streamline the whole team, which will always have more of a multiplier effect on net team productivity than the incremental value of your faster or more experienced hands-on technical work. Picking up the annoying tasks with the big multiplier effect also sets a good example to the team about the role of leadership.

Find ways to plug into technical context that serve dual purposes. You’ll never have the time to read all the codebases, skim all the changesets, and stay fluent in all the architecture decisions, and also you’ll never have enough time to spend all the quality time with each team member that you want, because time is your scarcest resource. Resist the urge to add “catching up” tasks like “learn framework X” or “figure out how feature Y works” to your ever growing todo list — more often than not you wont be able to get to this “catching up” task. It can be intimidating to feel more and more out of the loop on technical systems, especially if you suffer from impostor syndrome, and you are used to having to work harder than others to establish and maintain baseline technical credibility. So instead, find ways to incrementally catch up on technical context that serves dual purposes. I love scheduled pair programming and repeat-back code reviews for this purpose.

Scheduled pair programming: just schedule it as a meeting with one of your engineers and show up. Forget about knowing everything, feeling stupid, apologizing for not knowing all the things. You can’t ever be as in the weeds as staff (because it is your job to go broad while they go deep), but you can show up, ask questions, work together. Intentionally model being ok asking ‘stupid’ questions. Pairing gives your engineers attention and appreciation for their work and is a place where they can be the expert. Do regular repeat-backs as your work together to make sure you understand. This’ll help you catch up on a codebase way faster than going off and reading the code on your own, and this in turn models efficient learning to your engineers.

Repeat-back code and architecture reviews: what to do when you tried to be a good sport and picked up that monster code review everyone else was avoiding, but then you realized you lacked the context to be able to judge the design decisions or style choices? Schedule a “talking code review” meeting with the engineer who submitted the code review — this doesn’t have to be longer than 20 minutes — and talk through their changeset, section by section. Let them lead the explanation, and pause every 5 minutes or so to “repeat-back” what they described in your own words. The performance aspect of an explanation ensures you’ll be an active listener, and will force you to clarify for yourself whether you understand what they did and why. It’ll also always be faster than reading the codebase or tinkering with the system to get the needed context. It’s always fun to read code and tinker, but sometimes you only have 20 minutes when you would prefer 2 hours, and have to make do with what you have. Like Scheduled Pair Programming, this not only saves you time and gives you needed context, but also gives your engineers attention and appreciation for their work and is a place where they can be the expert.

Manage Confidence and Create Safe Spaces for Yourself

Creating safe spaces for your team is an important part of Building Software Engineering Environments Where Everyone Can Thrive, but in addition to making sure your team has safe spaces to ask “dumb” questions and get feedback, you need this too. The more your technical leadership broadens and the bigger your team grows, the more you’ll be making decisions but the less feedback you’ll get on your decisions, the more you’ll be solving problems or making tradeoffs that don’t have a clear precedent or right or wrong answer. This can end up feeling lonely and daunting. You can try to get feedback from your team, but because of the dynamic involved in holding positional power, it’s unlikely you’ll ever get direct, straightforward feedback — your direct reports wont have the same context you have, and everyone is always a little afraid of criticizing their boss.

So go out and find some tech lead peers, build relationships, and establish safe spaces for yourself where you can swap stories and get that real feedback that you’ll need to feel confident and accountable. I like to set up regular checkin meetings with my counterparts at other progressive organizations.

It’s also important to track and monitor your own confidence — understand when you’re feeling confident, when you’re not and what the signs of this are, and create a toolbox for yourself of confidence building interventions that you can deploy to support yourself when you need it.

If I’m tired or intimidated, I’ll start to get more reactive when people ask me questions or present problems to me, and especially when I’m tired I have a tendency to suspect that problems are more complex than they actually are. So I sanity check myself when I realize I’m immediately saying yes or trying to immediately solve a presented problem without scoping and sanity checking it first.

When I need to intervene and bolster my confidence, I try some of the following strategies:

• I love teaching people to code — nothing is more fun than showing someone the magic of automation, and helping them realize they too can harness the power of code, especially if they previously were intimidated of it. So I try to regularly volunteer with organizations that to teach people to code, like my local chapter of GirlDevelopIt. Teaching helps me remember what I love best about software engineering, helps me solidify my own understanding of core concepts, and puts me in a forum where I’m already an expert — all of these things bring back confidence.
• I’ll do a Mindset Intervention (from Kelly McGonigal’s excellent book, The Upside of Stress: Why Stress Is Good for You, and How to Get Good at It) like spending 15 minutes writing down my values, to reframe my thinking in terms of what is important to me and why, and how my values relates to my technical leadership.
• Celebrate successes: give yourself a gold star, write down a recent win you’re proud of and put it up on the fridge, call a family member or friend and tell them about it. In whatever ways are meaningful to you, explicitly give yourself credit for the work you’ve done. I clip new articles referencing MoveOn campaigns or projects I’m particularly proud of and hang them on the wall behind me, and then I see them behind me every time I do a video conference.
• Help others: at any given time I’m mentoring 1–2 more junior developers, or people who are interested in starting a tech career. This is not a service, it’s a mutually beneficial opportunity for growth. When we talk about goals, struggles, anxiety, paths forward, instead of wondering whether I’m good enough, suddenly I’ve re-anchored my mindset on reassuring my mentee that in fact they are good enough, and I remember that success is not about being good or being perfect, it’s about grit and working hard towards clear goals. And suddenly I remember my own confidence because I need to model confidence to help another person find and grow their confidence.

You Got This

Starting a new technical leadership role will be hard and stressful, but also incredibly rewarding.

As you advance in your software engineering career you’ll learn to code, and then learn to code better and faster, and then you’ll learn to figure out which coding challenges to solve and how, and the value of simplicity and elegance in problem framing. On good days, sometimes you can be personally 10x faster than you expected, and you’ll feel like a wizard.

As you advance in your software management career, you’ll learn that sequencing the right work at the right time in the right order makes it possible for whole teams to solve problems efficiently. You’ll learn the importance of Building Software Engineering Environments Where Everyone Can Thrive. You’ll learn that making sure the people on your team are listened to and feel respected lifts your people up and makes them more confident and productive. You’ll learn how to support your team in their professional growth. When your team is happy, your team processes are working, and your team goals are clear, you’ll unlock and boost the productivity of your entire team. This multiplier effect is way more than the 10x faster you personally can work on really good days.

As you advance in technical leadership roles, you can guide whole organizations to use technology to amplify their work, to make previously impossible problems solvable, and to scale systems to have national or even global impact. Organizational leadership has the ability to impact, amplify and support the work of 100s or 1000s of people. The right idea amplified with tech at the right time can impact millions of people. This multiplier effect is orders of magnitude more than the work even the most productive developer or developer team could do.

This is a lot of power. You can wield it, and you can use it to create and scale projects that make the world a better place!