Nvidia’s Jensen Huang may be an uber-talented chief executive, but his avoidance of one on ones is baffling. Maybe a lowly engineering manager isn’t one to critique the workflow of the head of one of the hottest tech companies around. Still, I consider 1:1s a fundamental management tool, one of the best ways to level up the team and build a culture of trust and open feedback within an organization.
Admittedly, Huang’s critique makes a few good points: 1:1s are usually a poor way to align strategy en masse or provide generalized downward communication. Managers should save that messaging for a Slack message or the next group all hands. But I suspect that 1:1s get a bad rap less for their potential, but instead from poor practical experiences.
The time we spend away from work can be as critical to our job’s success as when we clock in. That’s why active breaks – brief, focused, fun, and ready to go – are essential to my everyday routine. They keep me more productive and, on challenging work days, provide just enough fulfillment to keep the day palatable.
My active breaks all follow a pattern. They have natural stopping points that fall under thirty minutes. They demand lean forward, focused attention. No multi-tasking. No throwing something else on in the background. They are fulfilling and enjoyable to me, and only me. Active breaks aren’t for other people or my career growth. They are readily available, the kind of effort I can pick up almost any time; plans can change, and I never know when the mind needs a rest.
Watching Grounded II, a documentary on the making of The Last of Us: Part II, revealed unexpected parallels with my career. Making video games differs from shipping web apps, but the doc highlighted common challenges in navigating developers through hard deadlines, decision making, and resource management. I walked away from the experience with a newfound appreciation for how engineering managers can help ship great products.
Naughty Dog, the studio behind TLOU2, didn’t share my optimistic view on EMs. For most of its history, the studio went against industry trends by rarely hiring producers (dedicated roles to manage the project’s timeline and resource needs) or people managers. Department leads served as both individual contributors and quasi-managers. Naughty Dog leadership argued the producers and managers were a “crutch”, bureaucratic red tape that slowed down productivity and stifled creativity. Boasts around flat studio hierarchy appear as an aside in the documentary’s opening act.
Good engineering managers are good communicators. Good communicators are comfortable with silence, and often they luxuriate in it. Pausing after making a point conveys confidence and clarity. Waiting and considering a response to a question shows trust. Giving feedback or otherwise, uncomfortable news with few filler words delivers impact. Asking probing questions to a broader group can lead to awkward silence; good managers know the difference between contemplation and disinterest.
Admittedly, I’m still hit and miss managing silence, but I’ve come a long way since my start as an engineering manager.
Be succinct and to the point. Say what’s necessary, pause, and look for your audience’s comprehension. It might be non-verbal (e.g., a nod, leaning forward, flutter of the eyes) or verbal (“uh huh,” “ok,” “yes”). If you don’t connect with your audience, you’ll lose any further momentum you built up.
One of the hardest learnings from managing distributed teams for several years is that there is no single “best” environment for everyone on the team. Offices will eventually reopen with every individual strategizing what comes next. Some can’t wait to be in a busy, humming office five days a week. Others are cutting the cord entirely, moving away from big cities, and going fully remote. Some prefer a mixture of several days of the week in an office, the rest elsewhere.
It’s a challenging situation because managerial decisions around work environments can favor some and upset others. So over the years of managing engineers all over the country and across multiple time zones, I’ve established three simple rules to set expectations around work. Obviously companies have their own policies, so consider these more idealized or preferred for when there’s flexibility:
For an engineer’s “core work” environment, we treat every individual as a full time remote employee.
Outside of core work, we acknowledge experiences will be different. We strive for empathy, not equality, for this aspect of the job.
As long as we equip individuals to do their best work, location, and in most cases time of day, is entirely up to them.
Engineering managers get a high quantity and variety of inbound requests. At any point, you can be on the hook for the status of individual projects, career growth questions, support issues, and more. Questions and expected follow-ups can pop up in many contexts, be it 1:1s with reports, standups, or cross functional meetings. Managerial triage and delegation are commonplace that makes handling asks from all sides especially important.
However, none of this was apparent to me in my first engineering management role. Even when I caught up with reality, I naively expected to handle the increased load without issue. I organized my to dos in a trusted app setup. I could juggle taking detailed notes while simultaneously participating in meetings with ease. But at some point, a few months in as my number of reports increased and work volume spiked my system started to break down. I was dropping follow-ups. I would bury away action items in notes I would forget to review later. It was at that point I realized I had to adjust my workflow. One of the biggest lifts came from adding ticklers to my routine.
I define a tickler as a reminder of anything that I need to review on a future date. For example, a Slack thread where I’m waiting for a response. Or a good idea that comes up in a meeting that I don’t have time to process now but potentially will later. I generally structure ticklers in the form of simple questions:
Engineering teams working together in the same physical space every weekday will be a rarity. Fully remote and flex work was a phenomenon on the rise before 2020, and the pandemic exponentially accelerated these trends. Tech firms had to adopt a work from home culture overnight. After some initial growing pains, most companies found their productivity didn’t tank, and many of their engineers weren’t eager to head back to their open floor plan campuses. Today even companies with a strong office culture (Google, Microsoft, Salesforce) have shifted to a hybrid setup with the workweek split between the office and elsewhere. Other high profile tech companies (Square, Twitter, Shopify, Facebook) now allow employees to work fully remote.
There will be some holdouts like Apple that retain an in-office model. Still, momentum favors more distributed work setups over time. This new reality makes remote team management skills not just nice to have, but essential.
Having managed a team across the U.S. and Canada for several years, it can be challenging to keep meetings productive and helping the team gel together. If you’re read or listened to any other remote first advice, this isn’t revelatory news. But your actions in response to these headwinds can have a positive impact.
Smart engineering managers foresee what actions maximize long term impact and prioritize those actions accordingly. That is challenging to pull off in practice. The linkage between an EM’s immediate action today and its ripple effect a week, a month, or year from now can have little connection to time spent on the act itself. It also commonly lacks a paper trail or concrete “proof” of action taken. And managerial outcomes often depend on the fickle influences of human psychology and plain luck.
I’d argue individual contributors, a.k.a. developers have an easier time making the connection between action today and impact tomorrow. Most engineers deep in code have clean artifacts of their work to show progress. Developers edit files, merge pull requests, close Jira tickets, and pass automated tests. When they ship features, there’s often a tangible outcome, be it a new set of UI, a performance boost, or a database migration. Past performance across similar technical challenges becomes a predictor for future velocity. This factor is why more experienced engineers become more accurate at making estimates for their work, and why task estimation is such a core tenet of software development.
1:1s are deceptively hard. On paper, they look straightforward: set aside some time to let your reports talk through what’s on their mind. Actively listen, give them feedback, repeat. But no report shares the same personality, seniority, career trajectory, or learning style. Add to that mix a changing agenda and office politics, and you learn early on good listening alone won’t cut it. Knowing how to react at the moment in a way that’s tailor-made for your audience tends to elevate 1:1s from so-so to stellar.
But flexibility challenges aside, some principles work well for every report regardless of their background or environment. If you’re new to 1:1s or been doing them for a while and want to get better, adhering to these four basics will help.
Every engineering manager juggles multiple priorities: managing the velocity of the team, serving as a cross-team engineering representative, making sure the engineers are happy, and weighing in as a deciding voice on hard decisions. There’s never enough time to do everything which forces prioritization.
Unfortunately, promoting career growth among a manager’s reports can be the first item to get lost in the shuffle. It rarely carries the visibility that managing team velocity or a substantial presence in meetings can. Put another way, when you hit your deadlines, ship software on time, and take decisive action on the weekly sync, your boss notices. If you’re not promoting a report on schedule, you might have an unhappy individual, but it can get lost to the larger company view.