Tech Lead Survival Guide

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.

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?

  • 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?

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.

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.

  • 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
  • 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
  • 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

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.

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.

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.

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.

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.

  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.
  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.
  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.
  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.

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.

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.

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.

  • 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.



Mission-driven tech exec, CTO, formerly senior advisor SBA, CTO MoveOn

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store