After what everyone has over and over lamented was a shitty year, I feel like I want to at least celebrate some things that I found gave me some comfort or joy in between the bleak moments.

First, on a professional note, I left my job at Dropbox after 7 years and joined a startup, Descript, as an engineer. My stint as a non-manager may end up being short, but diving back into coding and building for the past six months has been pretty great. It’s been fun to do more code reviews, talk about architecture with other engineers, have Less Meetings, and think about strategy. It has been a bit odd to work almost entirely with people I’ve never met in person, however. If I am deputized to go back to management, it will be a challenge to maintain the manager/report relationships with people remotely. At least at Dropbox, before we went remote, I had a couple years of managing and meeting people in person.

On the technical side, Typescript/NodeJS is a joy to develop in server-side, and I’ve been able to try out some modern tools that weren’t available at Dropbox, like Electron, Datadog, Honeycomb, Retool, BigQuery, Docket, Webpack, and Kubernetes. I’ve delved a bit into desktop app development, which is a pretty mind-bending paradigm shift from web client and server development.

Things I learned this year

This year was tough going, especially in the middle, but I think I exited stronger and with more tools in my life toolchest than when I entered.

I learned a lot about maintaining relationships, both at home and at work. I’ve fumbled through my first 30+ years, and it’s really only in the last couple that I started learning how to build and manage relationships more intentionally.

I learned how to better manage my mental and emotional energy at work, so that I don’t come home drained with nothing for my family. I spread out my 1:1s at work across the whole week, and I gave myself a consistent 30 minute afternoon mental break that I defended it obstinately. I still have much to improve here, but I’ve been able to make these changes stick.

At work, I grew a lot as a manager, too. I helped my team ship some Big Deadline projects, pivoted them to more iterative development, tried my hand at small-scale organizational design, gained experience in performance management, drove changes to our business strategy, and started to learn how to hire other line managers. There was a lot of stress that came with all of that, however, and it was harder than usual to switch off my work brain at home.

Favorite media from the year

There were so many good things I read, saw, and listened to this year! Below are some of my favorites. (Note: many of the below didn’t come out in 2019. This is just what I myself consumed this year.)

• Second half of The Vorkosigan Saga: This is one of my favorite book series of all time, and the way Lois McMaster Bujold pivoted the ensemble cast into new genres and directions in the second half of her series was poignant and bittersweet. I finally finished the series this year, and I’m sad that there isn’t any more.
• Designing Data-Intensive Applications: I’m not doing any more coding, but I’m managing people who are, and this book was great to recommend to the engineers looking to grow.
• Spider-Man: Into the Spider-Verse: Probably the best superhero movie of the last two years, and definitely the best Spider-Man film of all time.
• Memories of Murder: My favorite Bong Joon-Ho film. It’s like Zodiac, but 10x better.
• Fleabag (both seasons): Wow, this show is so hilarious and raw. Phoebe Waller-Bridge is a genius.
• The Americans season 6: One of the best endings I’ve ever seen. There’s such a stark contrast to Game of Thrones’s, because The Americans focused on resolving character threads, not plot threads.
• Steven Universe: On the surface, it’s a heartwarming children’s TV show, but with so much emotional depth about identity, expectations, and acceptance. Everyone will become a better person if they see it. The main series ended in January, a sequel film followed, and now there’s a final stretch of TV episodes to finish out that story. I’m not as much of a fan of the latter two, but the main series is terrific.
• Return of the Obra Dinn: A creepy video game puzzler with a throwback visual style and one of the most interesting story-telling mechanics I’ve ever seen. A friend described it as “you play an insurance adjuster”, which is both true and hilariously reductive.
• Pandemic Legacy: Season 1: This was one of the best board games I’ve ever played. Riveting, challenging, fun, and fascinating in how they took the normal game and turned it into a storytelling engine. I can’t wait to try Season 2.

It’s been about two years since I switched career tracks from software engineering to management, and I feel like I’ve learned a ton of lessons, some of which I wish someone had taught me long before I became a manager. Many of them are obvious in retrospect, but I feel like many management lessons are like that. Hopefully, others new to management might find these lessons useful as well.

Delegation and project management

When I was an individual contributor, I thought “delegation” just meant that you ask someone else to do something! But then, things I delegated sometimes got forgotten or went in completely different directions from where I had intended. High Output Management was incredibly helpful in making it clear what I was missing: “Delegation without follow-through is abdication”. I wasn’t checking whether the task is proceding as expected. I feel like this notion should be taught to every tech lead, to every employee: “This is what your manager is doing when they’re being annoying!”

Beyond basic delegation, I didn’t really know how to manage multi-person projects as an individual contributor, even when I was the nominal tech lead. They would regularly run late, and I constantly had to jump in to help pick up the slack. Becoming a manager and forbidding myself from pitching in directly gave me no room to continue being that bad at it.

The main mantra of “who does what by when” from the Manager Tools podcast has been incredibly helpful, because ensuring clarity for those criteria solved many miscommunication headaches; performance and organizational problems also become much easier to uncover. In addition, the “what” has to be based on concrete, unambiguously observable deliverables, not just effort or time spent. In other words, rather than “research options” or “develop X feature”, better deliverables are “write and send out a report” or “release feature X on internal build”. Just relying on some sort of summary status (“Are you on track? Is it green?”), as often happened in teams I’ve been on, is not enough. There’s too much room for miscommunication, misunderstanding, and forecasting error.

These aren’t the only important parts of project management—planning and forecasting are important, too—but it certainly helped!

Task-relevant maturity

Early on, I avoided telling people exactly what to do. I would ask leading questions, reflect questions back at the asker, and hint and nudge them in the direction I thought was right, because I thought that telling people what to do was the mark of a poor manager. “I have good people! I don’t want to micromanage them,” I thought. “I’m here to enable them to do a good job.”

The results weren’t always great, however: work that didn’t meet my expectations, team members getting frustrated about what I wanted. I learned that sometimes, you do have to tell people what they should do, directly and explicitly, and then check up on them frequently. People may never have done this kind of work before, and so they don’t have the tools to solve their problems themselves—their task-relevant maturity is low. Even if they could learn it on the fly, it might take them so long that it’s not worthwhile, or there may be too much risk that they cause something disastrous to happen. In those circumstances, telling them what you want them to do is a teaching moment, and not necessarily a management failure.

In addition, when I was an individual contributor, I never thought about the task-relevant maturity of the team as a whole. I was just responsible for solving problems, doing code reviews, and I never really thought about staffing in any other terms than “do we have enough people to write code”. That was pretty disastrous for the quality of what my team shipped. I had to work overtime to fix up code and catch problematic designs.

Now that I’m responsible for evaluating what kind of work people are ready to do, it’s become much more apparent to me that the team’s collective experience level and expertise should set limits on what kinds of projects we tackle. A software design-heavy project isn’t good for a team of junior coders, for example. Even if they manage to finish the first version of the project, the high cost of maintenance over time would be an incredible waste due to design flaws making the system buggy and fragile.

These days, I think a lot about matching people and teams with appropriate projects, and ensuring that I’m being just directive enough.

It’s possible to be too helpful

On the other hand, despite trying not to be directive early on, I did try to be as helpful as possible as a manager, giving lots of suggestions and helping people solve problems. I thought I was helping my team to produce better quality work! Maybe I was, but I eventually also realized that I was having negative side effects. Being so involved stretched me thin, and more importantly, crowded out my senior engineers from leading and influencing. I had to pull back and delegate this responsibility for technical leadership, so that my team could function more independently of me and the technical leaders I was trying to cultivate actually had chances to lead.

I still struggle with this (I do like software development!), but where I can, I try to ask myself who else could or should be helping instead of me. In addition, rather than making suggestions as I check in on the quality of work and technical strategy (my delegation follow-through), I try to couch my words in terms of expectations rather than suggestions.

Sponsors are critical for career progression

I didn’t really appreciate how important sponsors are for people’s careers until I became a manager, when I started writing performance reviews and putting people up for promotions. Before, when I was a staff engineer (a relatively senior position at my company), I took for granted that people trusted me when I gave peer reviews on who was doing well and on what.

As a manager, though, upper management was much more skeptical of my evaluation of people’s technical skills (rightly so), and so it mattered a lot to have other senior software engineers as sponsors that could vouch for my people, especially as they got to the higher end of seniority. It might sound like politics, but to me, it’s really about chains of trust, where my promotion proposals are treated skeptically like self-signed certificates. Now, I know to seek out sponsors that have the company’s trust when making the case for promotions.

Planning around my energy levels

When I was a software developer, I had a lot more control over my schedule and energy. If I needed a break in a marathon coding session, I could take it! As a manager, though, my days often fill up with meetings, and it’s not easy to just move those around to manage my energy levels. Even if I need a break, it sucks for the other person to cancel a meeting 5 minutes before it starts.

These days, I pre-schedule 30 minute mental breaks, at least once a day if not twice. That time is sacred, not to be spent on email, meeting prep, or any other work—not even mulling about things. Usually, I’ll grab a snack, a cup of tea, and just sit. Sometimes, I’ll try a mindfulness exercise or take a walk. It’s a chance for my brain to disconnect and for me to recharge.

In addition, I used to try to stack all of my one-on-one meetings with my team on one day of the week, in an attempt to reduce my context shifts from “one-on-one” mode to other types of meetings, but that was just too exhausting, not to mention a bit unfair to the people who I met with later in the day. I can’t keep up more than maybe two hours of active listening at a time, so these days, I spread my one-on-ones across the whole week.

Always be selling

I’ve realized I need to always be selling the team’s mission. This was easy to remember when I was quickly growing the team, because I was heavily involved with recruiting and hiring, but it was harder to remember to do when I wasn’t hiring. For the people already on the team,though, I’ve found that if I’m not continuously selling what our mission is and what our plans are in the future, people can feel lost, uninspired, or drift on to thinking about what else is out there.

I can’t say I find this easy. Selling is an emotionally taxing task for me, and I definitely feel more tired as I put in more effort, but it feels worthwhile nonetheless. It’s worth it to have the team feel productive, optimistic, and creative.

These probably aren’t profound lessons, but they weren’t obvious to me when I started, and I feel like they’ll be useful lessons for me no matter where my career takes me, whether it’s back to being an engineer in the future or continuing on as a manager. I tried as much as I could to learn from helpful books like High Output Management, but the real experiences in the past two years reinforced my book learnings and added nuances that I wouldn’t have noticed otherwise. I’m looking forward to what I learn over the next two!

I expect that to many people, “accountability” seems like a euphemism for “blame”. That’s hardly surprising, given how it’s used in the media and news.

From a recent Vox article on the opioid epidemic:

An overwhelming majority of Americans want pharmaceutical companies to be held accountable for the opioid epidemic, according to a new NPR and Ipsos poll.

From an op-ed by Chris Hughes, a co-founder of Facebook:

The government must hold Mark accountable….Any day now, the Federal Trade Commission is expected to impose a $5 billion fine on the company, but that is not enough.

From a Radiolab episode on Good Samaritan Laws:

“When you look at the [criminal case for reckless endangerment of EMTs], he needs to be accountable for those actions because he knew the risks that were involved.”

These uses of “accountability” feel very tied up in desires for justice and punishment: firings, fines, convictions. Consequences.

In the workplace, though, I see many uses of the word “accountability” for a different, less negative idea, one that I think is closer to “ownership”. This use is about who’s owning the final decision-making to ensure a project is successful. The accountable person is the one that knows what’s going on, what has already happened, and what needs to happen next.

That meaning of “accountability” is really useful, because I want to give my team accountability for their work; that empowers them to do what they think is best and gives them the recognition for it. Accountability is also important to divide up clearly, because otherwise, people pay a huge coordination tax, accidentally stepping on each others’ toes, getting frustrated trying to reach consensus. It’s not surprising that I see “accountability” often being used among managers.

My use of “accountability” isn’t meant to be about who gets punished when something goes wrong, since focusing on apportioning punishment or blame is often harmful to effective teamwork.¹ But I can’t control how language evolves; when I’ve tried to use “accountability” in the way I describe above, I too often see my team look uneasy—maybe on guard for the threat of punishment. Every time, I feel I need to reassure folks and explain the difference I see between “accountability” and “blame”, and when I do, it seems like I’m rowing upstream against the current. I don’t want my team looking over their shoulder or trying to cover their ass.

That’s why instead of “you’re accountable for this”, I’m going to start saying “you’re the driver for this”. The driver is the one at the controls, keeping things on track, taking detours, and course correcting to get things done. It conveys the same meaning, but without the implied threats. At the end of the day, what matters to me is that my team can work effectively together to build great products, and the word “accountability” is doing more harm than good for that. I doubt I’m alone in feeling this way, and I think it’s time for that use of “accountability” to end.

One of my favorite things about High Output Management was the way Andy Grove treated managing organizations as a special case of managing systems. He starts off his book with a model of a company as a breakfast factory.

Similarly, Acolyer in this blog post applies ideas from optimizing distributed systems to the scaling of organizations:

I was thinking about the advice I should give to the CTO of a fast-growing company struggling to maintain velocity amongst all the competing demands on his time. And it occurred to me that the Universal Scalability Law has a lot to say about this situation.

This also reminds me of Will Larson’s posts lately on systems modeling of organizations, such as this one on modeling reliability of an organization:

We’re doing an annual strategy refresh on how we’ll approach security, reliability and such, and incorporating modeling into developing these strategies has been a surprisingly effective brainstorming tool.

I’ve found posts like these to be very useful, so hopefully you will, too.