NickSchaden

Making one on ones better

07.17.24 | Work | ∞

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.

Focus is a typical problem; many managers reframe 1:1 meetings around their needs. So you get horror stories of thirty minutes of one-way communication from a manager to a report that could have been an email. Or a meeting that devolves into a mini status report, a format for the manager to “deep dive” into the latest tactical project with the report on their back foot. And because it’s their meeting anyway, the manager happily shifts around a 1:1’s timing at the last minute or cancels it outright.

Managers need to reframe their mindset to make 1:1s productive and lasting. 1:1s aren’t about you, the work, or even the team. Instead, they’re all about serving the perspective of the individual report. What will build trust? What will help this engineer grow in their career? What will keep their morale from torpedoing when times get challenging?

1:1s provide no “one size fits all” solution. Details change based on the manager, the report, and the team mission. However, the proper format balances flexibility and rigidity, a concept that may sound contradictory but is by design.

1:1s are, from the report’s perspective, flexible or, at the very least, fungible. Most weeks, the report sets the agenda; it’s their meeting focused on their needs. I like a weekly thirty minute cadence as a starting point, but I often size up or down the meeting frequency on demand. Occasionally, an engineer can be heads down on a project with little on their mind in the long term to discuss; we’ll mutually cancel the meeting and give time back. Alternatively, we’ll touch on a subject for which the conversation will easily blow past thirty minutes. Maybe it’s a promo packet due soon, or a report’s morale has cratered, and we need to get back on track. In these instances, it may make sense to book multiple meetings in a week and dial back the frequency later.

But 1:1s are not a free for all. They work best with a set degree of rigidity and consistency. Because I, as the manager, generally have a packed, inflexible existing meeting schedule, I set the times when my 1:1s happen. I’ll post a signup sheet with a narrow set of open slots. Those openings are purposefully clustered around other existing meetings in my schedule, often back to back on just one or two days so that I can stay in “1:1 mode” for an extended period of my week.

I’m also inflexible around a shared source of truth for 1:1 notes and agenda items. That means a private document format (e.g., Google Doc, Confluence wiki) shared across the report and myself. I list out 1:1 dates in the doc in reverse chronological order, starting from several weeks ahead of the present. Against each date, there’s room for the report or me to write bullet point summaries. For future dates, the space is for proposed topics to discuss on the agenda. After the 1:1 happens, the space becomes a place to recap significant points covered in the 1:1.

The shared doc is purely a tool to facilitate good 1:1 conversations. Some otherwise talented engineers may struggle with topics to discuss, so I encourage them to capture ideas as they pop up in the doc asynchronously throughout the week. I’m also a heavy notetaker, so after a 1:1 wraps, I like to add a few bullet points to summarize our conversation. It’s a trivial effort on my part, and it can give reports a clear paper trail of our chats, hopefully spurning further ideas.

Rigidity can also be helpful around 1:1 topic cadence. In particular, for some reports, especially those earlier in their careers, I like building in a schedule so that once every two to three 1:1s, we explicitly focus on their career growth, usually on a focused, narrow aspect of their job like reviewing PRs efficiently or stakeholder management. Building a consistent schedule can help engineers keep a growth area at the forefront of their minds, even amid an otherwise busy or scattered day-to-day.

My personal 1:1 flow may only work for some. That’s fine! Tools and structure are only beneficial if you see a corresponding gain in the quality of your 1:1s. When one reflects on the latest few conversations, are the reports engaged? Are conversations two-way and productive? Is the total cognitive and time load – prep work, the actual meetings, and follow-ups – manageable? If ‘yes’ is the answer to all these questions, that’s a move in the right direction.

But even at my best, I rarely can give a universal yes to the questions above. On a team of eight or so ICs, I might have one report for which 1:1s remain challenging. The IC may be an otherwise strong developer and quality team member, but in the 1:1, they are unprepared and convey disinterest.

Before I worry too much about exceptional cases, I consider the bigger picture. If the engineer is knocking out the work, is happy, and is growing in their career, there’s no need to stress out. Cut down the frequency, keep check-ins for only the most critical topics, and let them loose. Remember: it’s ultimately their meeting, not yours.

However, if the 1:1s are a drag and the engineer has some clear growth areas, I’ll mix it up with a more direct approach. Without a 1:1 connection, I’ll lose my best venue for building trust and open feedback if I don’t take action.

Usually, I’ll book a straight one-off hour with them, with the focus on exclusively deep, more philosophical questions about why we’re meeting to begin with. I’ll probe on 1:1 experiences with prior managers; there might be a horror story or two to work through that has bred a deeper mistrust in the ritual. I also like to ask what they would want with zero limitations on what we could make happen in a 1:1 manager-report context. Crystal ball wild swings can bring insight into their real goal, to which you can react and size accordingly. If there’s a key growth area, I’ll discuss how I can help. Even the biggest 1:1 cynics want to grow their career, and if they see the meeting format as a way to move up, they may have a change of heart.

And when all else fails, be it with a report resistant to 1:1s or any other 1:1 that misses the mark, I remind myself that the meeting format’s idiosyncratic, humanistic setup ensures not every chat will be a winner. But occasionally, we listen and converse with empathy and curiosity and emerge as better, more productive engineers. Embrace the meeting format’s inherent messiness, and know that a few well timed, impactful conversations will outweigh those that feel unmemorable in the long run.

Active breaks help the daily grind

05.07.24 | Work | ∞

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.

Naughty Dog and the pitfalls of flat hierarchies

03.07.24 | Work | ∞

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.

Get comfortable with silence

09.20.23 | Work | ∞

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.

My rules for managing distributed engineers

09.07.21 | Work | ∞

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.

Staying organized with ticklers

08.02.21 | Work | ∞

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:

Navigating the downsides of remote first engineering management

05.11.21 | Work | ∞

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.

Maximizing long term impact as an engineering manager

02.11.20 | Work | ∞

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.

Principles for stellar 1:1s

06.10.19 | Work | ∞

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.

Career conversations as an engineering manager

05.28.19 | Work | ∞

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.