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.
An engineering team’s formal processes — how you track sprints, run meetings, handle release cadence, and manage code reviews — helps set team velocity and impacts the happiness of individual team members. As the engineering manager, you’re in an impactful role to shape and improve these processes over time. Remember when making any change in process, be patient yet firm.
Engineers tend to dread meetings, and for good reason: bad ones can be soul crushing. Not only are bad meetings a waste of everyone’s time, it can make the meeting’s organizers look incompetent. Paradoxically, as engineers grow in their career, meetings grow more important. You attend and organize more of them, and as a senior voice in the room, your words can have an outsized impact.
Meetings get a bad rap. Well run ones are an efficiency multiplier, leaving people energized and productive, and a team more cohesive. The right meeting can even turn around an otherwise doomed project.
One of the easiest ways to improve the quality of your meetings is to prepare for them. Without preparation, you’re fighting an uphill battle against context switching; one minute you’re coding and the next you’re in “meeting mode” without clear direction.
I like design teams built around collaboration and transparency with outsiders, especially engineers. Yet that openness has to be balanced against productivity. Even with formalized designer-engineer connections, I still structure meetings to give designers as much uninterrupted time as possible.
An open structure largely derives from designer/engineer ratios. Across technology, from hot startups to well established brands, designers are almost always heavily outnumbered. And given it’s a fairly young industry, design is often underrepresented in company leadership. Granted, with “design thinking” surging in popularity, that’s changing. But across many companies, it’s still an uphill battle. If you box your design team in, you’ll stack the deck against you.
Capturing and organizing tasks is a highly personal exercise. Some turn to simple tools like pen and paper or a Google Doc. Others prefer complex systems with filtering, contexts, and customization like Omnifocus.
After trying several options, I’ve found a sweet spot between these extremes with Todoist. It provides some structure for work, but remains flexible for whatever flow I’m managing. That said, the basics I outline here should work with most task management systems.