Early learnings from an engineering manager on a fully remote team

Jun 3, 2021 by yihwan kim. 18 min read.

This week officially marks my 6 month milestone of leading a fully remote engineering team at Curology. It’s been fun; it’s been challenging; but above all, it’s been an incredible learning experience.

This week also marks a year-plus of mandatory work from home. While strange at first, I’d say we’ve done all right. On my end, I’ve become an expert at unmuting myself before speaking and rocking the sweatpant office athleisure look like a pro.

So much has changed in the past year, and I think we’re all getting a sense for how we like remote work. From what I’ve heard so far, the reviews seem decidedly mixed. Some revel in skipping early morning commutes and working from secluded cabins near Lake Tahoe. Others lament the relative isolation and less-than-stable Internet connections (which can be common, for example, when working from secluded cabins near Lake Tahoe).

I’m told working remotely can especially be a godsend for parents with younger kids, but other parents (sometimes the same ones) admit that, while they love their children dearly, they wouldn’t hate the idea of going back to in-person classroom learning sometime soon.

More often than not, these positive and negative reviews come from the same person — showing that even a year later, some of us, myself included, may still be a little torn on this new normal.

However, if there’s one benefit of going remote that’s more certain, it’s hiring. It seems so obvious in retrospect, but embracing a remote-first team has made hiring talented engineers from diverse backgrounds exponentially easier. It turns out looking beyond a seven-by-seven-mile square of the country’s most expensive everything enables that. Who knew?

I also have a personal reason to be thankful: the Site Engineering Team at Curology (the team I lead) is comprised entirely of remote software engineers spread across the country. Without having gone remote, we wouldn’t exist.

Yet I can’t help but wonder about the downsides of working on a fully distributed team, especially over the long-term.

I wonder how working across time zones through Slack messages and Notion pages will impact our ability to coordinate our efforts (which in turn, might affect productivity). I wonder how not seeing our colleagues or going out to lunch together will impact our ability to form meaningful connections as a team (which in turn, might affect retention). I wonder how people will manage an increasingly fluid boundary between work and home (which in turn, might cause burnout).

I wonder, and I worry.

I don’t think I’m alone in wondering — or worrying. I often hear many people frame remote work as a trade-off. Roughly paraphrased:

  • “It’s nice that I don’t have to wake up early to commute, but I kind of miss seeing everyone in the office sometimes.”
  • “I still Zoom with people I knew before the lockdown, but I don’t think I’ve met anyone who joined after. Sometimes I log into a meeting and wonder ‘who are these people?‘”
  • “Being remote is fine, but you lose out on the magic of a great brainstorming session. You can’t get that without being in the same room.”

After only six months on the job, I haven’t figured everything out. But after pushing through countless projects and tasks asynchronously, messing up a time zone conversion or two, and most importantly, listening to my team, I’m starting to understand how we can not only create high-functioning remote teams, but re-create some of the more compelling aspects of co-location as well.

Some practices like maintaining situational awareness, working in public, and design thinking are things I’ve been doing for a while, back when I was an individual contributor or even well before I entered the wild world of software development. Others, like embracing meetings, not being so serious, and keeping events on the calendar are things I’ve learned along the way. And finally, a number of items such as reconciling my issues with Donut or connecting with people outside my team are things I still haven’t figured out how to do well remotely, but hope to someday.

Above all, I hope that publishing these notes to the world will bring a certain accountability from others and be the first of many living documents of my own personal growth and development. I hope what I write today marks the first milestone of many — and shows how far I’ve come, but more importantly, how far I’ve yet to go.

Maintain good situational awareness


Years later, I still remember the email from my boss. It ended with “cc’ing the team for SA!”

“What on earth does SA stand for,” I muttered to myself as I frantically searched the Internet for clues. South America? Salicylic Acid? Special Agent? Google suggested Société Anonyme, which certainly didn’t help.

“Situational awareness,” a co-worker whispered across the table. She was cc’d on the same email and had noticed my confusion. “I had to look it up too.”

I admit I was annoyed. Why use such an esoteric acronym? If the goal was to save some characters, why not use a more commonly-recognizable one like FYI? But after my initial grumbling and mumbling, I ran across this really long Wikipedia article devoted exclusively to the subject of Situation(al) Awareness. Huh, I thought. Maybe SA is a thing after all.

I can’t say I’ve read the whole Wikipedia article, not even to this day. But I have learned to appreciate the immense value and importance of maintaining good situational awareness. Good situational awareness enables you to foresee the secondary and tertiary effects of your actions, adapt to unexpected circumstances, and make better decisions overall.

One way I “measure” my situational awareness is by asking: How often am I surprised at work? If I find myself constantly caught off guard by projects falling through, team members unexpectedly departing, or executive decisions being announced seemingly out of the blue, I might reconsider the quality of my situational awareness.

Situational awareness is important in any environment, but it’s critical in a distributed one. This presents a bit of a Catch-22 because maintaining situational awareness is arguably harder to do without a physical office. But it’s still possible on a fully remote team! Here’re some tips that might help.

Check your activity feeds

At Curology, we’ve set-up multiple #alerts- Slack channels that create automated activity feeds from various tools. For example, we’re plugged into GitHub activity:

Screenshot of GitHub activity notifications in Slack. Team members discuss PR titled "Center div horizontally and vertically on page".

And scheduled Pull Request reminders:

Screenshot of scheduled GitHub PR review reminder.

We also have a separate channel devoted to Asana task activity:

Screenshot of Asana task completion.

Much of our team’s documentation happens in Notion, which offers feeds in the form of “Updates”, including a somewhat creepy “All” tab that tracks changes across all pages you can access. If your team can get over the initial creep factor, this can also be an excellent source of situational awareness.

Screenshot of "All Updates" tab in Notion tracking changes to this blog post.

I spend about 5-10 minutes at the start and end of each work day checking various feeds. As with Twitter, I don’t read everything. But if something catches my eye, I might click into it to learn more. I’m careful not to spend too much time in the feeds (It’s not healthy on Twitter; it’s not healthy on Slack; it’s not healthy anywhere!), but devoting 10-20 minutes a day to catching up on what’s been going on has probably been the single biggest contributor to my situational awareness.

Communicate and work in public

At the risk of stating the obvious, it’s a lot easier to build situational awareness if information is readily available. It’s a lot harder if it’s not.

That’s why I generally prefer public Slack channels over private channels and direct messages, unless you have a specific reason to make a channel private (e.g., to discuss a candidate’s interview process). Anyone should feel free to peruse or join, and people can always leave quietly if desired (you can set “leave” messages off for public channels, but not private ones).

Spinning up public #proj-specific channels can be an excellent way to document project activities. Anyone can join and catch-up on key details that have been “pinned” to the channel, and this information lives on even after a channel has been archived. In many ways, public Slack channels are the improved, modern-day cc’s.

On a broader note, you should always have a general idea of how your company is doing. This doesn’t mean you need to pore over marketing metrics or sales KPIs, but you should have a working understanding of your company’s competitive position in the market — as well as a cursory picture of its future prospects.

To develop situational awareness of the overall business, transparency is crucial. I’m especially appreciative of how transparent Curology’s leadership is about the state of the company. Our KPIs and core metrics (e.g., number of active subscribers) are available for anyone to see in Chart.io, and our CEO updates us regularly on how things are going in a monthly all-hands meeting.

There’s signal in everything

I learned early on the job that there is signal in everything. A seemingly off-hand remark made during an all-hands, an unexpected transfer to a different team, a busier-than-usual calendar — these are all signals. Whether they mean anything remain to be seen.

Intelligence gathering and processing are best kept separate. I don’t judge or assume based on signals alone; I just listen and observe. When signals start to collide and collate, I might take a second look to see if there’s anything meaningful in the data. Sometimes, I extrapolate.

It can be hard to preemptively separate useful signal from noise, so I err on the side of listening and observing more. Even signals that don’t seem immediately actionable can go a long way in improving situational awareness.

Intent matters

At what point does improving situational awareness and “intel gathering” become creepy and unproductive? It’s an important question, and one where intent can mean the difference between a culture of fear and surveillance versus one where it feels like everyone is looking out for each other’s best interests.

When executed well, building situational awareness should feel like a friend giving you a heads up that a project is starting to look a bit rocky and helping you come up with a backup plan. It should not feel like a micro-manager breathing down your neck and watching your every move.

So much of this depends on your company’s culture and is largely outside the control of any one individual. However, I’ve done my best to communicate and reinforce my intent, which is to ensure that our team stays aligned, productive, and happy.

First, I share everything I just wrote with my team. I talk about which feeds I’ve found helpful, why I nudge towards public Slack channels, and how I try to get a sense for how everyone’s doing. We laugh about how, yes, the Notion “All Updates” tab is kind of creepy, but we also recognize how it can be used to better coordinate our activities — and how it’s even saved a few projects from tipping off the rails.

I also actively encourage my direct reports to maintain their own situational awareness using these techniques or their own. After all, the goal is not for a manager to surveil the team, but for the team to ensure collective success.


Finally, it’s worth mentioning that situational awareness is “situational” in that it comes from passive observation rather than direct lines of communication. Hounding engineers for status updates does not gather situational awareness. Maintaining situational awareness should not feel like extra work for anyone other than the observer.

On the flip side, situational awareness can only get you so far. After all, context is important but doesn’t tell the full story. This actually segues to the next point quite nicely, which is …

Embrace meetings. They can be great. (Yes, really!)


Wait, what? Software engineers hate meetings. They’re a waste of time! This could have been an email! Asynchronous not synchronous!

I know, I know, but hear me out.

Meetings deserve their reputation. We’ve all been in bad ones: the ones that consist of nothing but status updates that, yes, totally could have been an email; the ones that drone on until everyone is clearly staring at something else on their screens, typing away on something obviously unrelated; the ones that have collectively turned an entire industry against the very idea of synchronous communication.

But it doesn’t have to be this way. In my opinion, there is no better way to share honest thoughts and feelings, brainstorm and ideate, and bring a team closer together than through the much-maligned meeting. Even on a remote team? Especially on a remote team.

At the risk of completely alienating my entire audience, I will say that my biggest accomplishment in my first six months of being an engineering manager was creating a meeting. We call it Site Team Time, and the purpose is to talk about whatever we want. That’s it. We do it every week.

As expected, there was some initial hesitation about committing to an hour-long meeting on a weekly cadence, especially with such a vague purpose. Could we do every two weeks instead? Maybe shorten it to 30 minutes? I listened to these concerns carefully and reassured everyone that we could always revisit cadence, length, and the very existence of this meeting later on. But I asked that everyone commit to 1-hour to start — and to try it for at least 3 weeks in a row before making any firm judgments.

That was six months ago, and I’m happy to share that we all voted unanimously to renew Site Team Time beyond its initial 3-week “pilot”. Not only that — multiple team members have shared that this meeting has been incredibly helpful in creating a space for us to talk to each other, bring up concerns and questions, and just have fun.

I started writing, in detail, about why I think Site Team Time was successful. However, that section quickly became as long as this post, which has already grown to be four times longer than I expected. So I’ll save those details for another day and instead focus on some common themes that could apply to meetings generally.

Don’t be so serious

Some meetings have to be serious. Most don’t. Sometimes I wonder if the tech industry’s pervasive antipathy towards meetings has lurched us too far in the wrong direction, where meetings are regimented with strict agendas, statements of purpose, and measured down to the minute. This might be appropriate for some situations, but it all just seems so serious.

One of my primary goals of Site Team Time was to create a space where everyone could get to know each other: what we like to do for fun, foods we like and foods we don’t, our hobbies and interests outside of work. I felt this to be a particularly urgent task, since all the ways this normally happens in an office (e.g., going out to lunch, celebrating happy hour, or walking by someone’s desk to say hi) were not available to us as a remote team.

Sometimes we have an agenda going into the meeting, with important items to discuss such as team announcements or tech decisions. Sometimes we don’t, and that’s okay too. We always find something to talk about.

I’ve noticed that when you keep things light, people feel more comfortable expressing honest thoughts, half-baked ideas, or just how they’re feeling overall. This is so important.

Every high-functioning organization I know has a strong intellectual safety net. People feel comfortable asking questions, expressing doubts, and challenging assumptions. They feel comfortable saying “I don’t know” to learn from one another. They recognize that the best ideas can come from anywhere, and that even the best ideas start out a little rough around the edges.

Would people feel the same if they had to memorialize their thoughts in highly regulated agendas? If they were asked to please only communicate through thoroughly considered and rigorously proofread emails? That they should do all these things and more — or risk wasting everyone’s time? I don’t think so.

Make the most of your time

It seems to have become a common practice to “give back time” when meetings run short. I’m often tempted to make a bad dad joke about it (“Oh thanks you can just put it on that shelf over there”), but fortunately I usually have the self-control not to.

I think this is partly influenced by the fact that I don’t really know what to do with the time I’ve just been re-gifted. When I see a meeting scheduled for one hour, I mentally segment the day’s tasks around that hour. So when that meeting only runs 38 minutes, what should I do with these extra 22 that have suddenly and unexpectedly appeared before me?

This is an especially vexing question when, as is common in engineering manager life, meetings are scheduled back-to-back. The context-switching cost is too high, so I usually end up doom-scrolling through Twitter.

I like to think there’s always something to talk about. Sometimes we start Site Team Time with absolutely nothing on the agenda. But we never cancel or call the meeting short, and so far, we’ve always ran out of time (!) to discuss all the things that came up once we got started.

As an aside, there is something to be said for breaks. We all need breaks! That’s why I generally don’t schedule meetings up to the hour, but usually leave some breathing room at the end (e.g., 11:00 – 11:50 instead of 11:00 – 12:00). Sometimes the meeting runs up to the hour, but other times everyone gets a break. Nice!

Try design thinking

This is the section that could easily double the length of this entire post, so I’ll save the 2,000+ word scramble I’d written for another day. Instead, I will just ask this question:

What if engineers could think like designers?

Would that be fun? Terrible? A game-changer — or a total disaster?

Typically, designers focus on pie in the sky ideas while engineers are brought in when it’s time to bring those ideas back to earth. Designers say “yes and”, while engineers say “no but”. Both are important for a healthy product development process.

But what if we could switch roles every now and then and engineers could try their hand at design thinking? What if we tried outside the context of the typical ideation session — and applied it to how we approach everyday conversations with our peers? It’s something to think about.


At the end of the day, there is no substitute for in-person communication. On a remote team, calls (video or old-fashioned telephone) are the next-best thing. And yes, this means having some meetings — even if scheduling across time zones makes things harder.

Meetings can be worth it. Emoji reactions to Slack messages are nice (some might even say an important source of situational awareness), but they could never replace seeing and giving people space to react in realtime. You’ll get more honest feedback. You’ll learn more from your team, and your team will learn more from each other.

Don’t give up on meetings.

Connect with people outside your team


Hold on, connect with people outside your team? If you think this sounds like more meetings, you’re right!

I understand the trepidation. As an engineering manager, I already meet with a lot of people: weekly 1:1s with direct reports and my manager, skip-levels with my manager’s manager, roundtables with other engineering managers, project kick-offs, retros, and more with everyone else. But these people are part of my team, and I should be meeting with them anyway. It’s part of the job.

Connecting with people outside my immediate team is arguably not as hard a requirement, but I am always grateful that I do. This could include engineers from other teams, designers, product managers, biz ops people and people ops people, marketers and accountants, support and success, among many others.

Some might say this is a great way to keep a pulse on the company as a whole or grow your network. To be sure, both are true. But motives don’t always have to be so calculating. Sometimes, I just like meeting new people. The more the merrier, I say. Life is a party, and everyone’s invited.

Admittedly, this was a lot easier when we were all in an office. We were in the middle of the Financial District in San Francisco, which is right next to Chinatown and not too far from Little Italy. This means, you guessed it, so much food! Anyone want to get dim sum? Banh mi or som tam? The deli in Embarcadero Four isn’t bad. What about that place next to the Ferry Building? The food sucks but the views are great.

You’d send a message in #san-francisco, and a posse of hungry colleagues would instantly swarm around the elevators, eager for a respite from the day’s work.

We can’t really do that on a remote team anymore. What’s more, I’m still figuring out how to re-create this on a distributed team. For that reason, I’d say a lot of the proceeding sections qualify as areas of improvement for myself. So I’d mark this all an active Work In Progress, in more ways than one. With that caveat, here are some of my notes taken thus far.

Start early

The best time to introduce yourself to someone is right after they’ve joined. It’s so obvious, so intuitive, so why do I procrastinate on scheduling intro chats? My schedule is busy, but it’s not that busy. I could easily find 30-minutes to say hello to someone who’s just joined the team, once a week or twice a month.

As someone who worked and generally enjoyed working from an office during the before times, I can’t imagine what it must be like to remotely join a completely remote team today. Maybe I’m making a bigger deal out of this than I should, but I can’t help but feel that it could be intimidating to introduce yourself to a sea of squares, not sure who’s who, without the ordered chaos of a physical office to guide you.

Even when I’ve probably passed the socially-acceptable time to “introduce” myself to someone (is it 1 month after joining? 3? 6 … ?), I try to schedule chats whenever I can. Sometimes it’s after someone gives an amazing demo (“that was great!”) or when someone seems frustrated in a larger meeting (“I’m always happy to listen, off the record”). In general, I’ve found most people are open to chat whenever.

Have a Donut?

Most of us have probably heard of Donut, the Slack app that randomly connects people to chat.

The little thing is persistent, sending nudges and reminders at aggressive intervals. “You’ve been randomly chosen to take point on making this meeting happen!” “Why don’t you suggest a time or use a conversation starter?” “Have you had a chance to connect? “Did you have a chance to connect?”

Donut is great in theory, and I’ve heard it works well for many people.

Yet, I find myself ignoring these reminders more often than not. After some reflection, I think it’s because they always seem to come at the most inopportune times. It would be as if someone walked up to your desk, when you have headphones in and are clearly occupied, waving their hands in front of your face, and shouting “Hey! Got a second?” No! Go away!

I wonder if there’s a way to schedule Donut messages more seamlessly. Maybe it could integrate with your calendar and avoid sending messages during designated focus times? Perhaps this is a new feature request in the making (sorry, Donut team).

I also wonder if it’s because I don’t like a computer telling me what to do. What’s the context, computer? Why are we meeting? You’re not the boss of me! Not yet anyway.

After failing to connect through Donut a couple times in a row, I ended up snoozing my pairings for now. It’s only fair to everyone else while I figure out my (potentially existential) issue with Donut.

Keep it on the calendar

One day, I was paired with a senior engineer mentor. The idea was to schedule weekly 30-minute chats to further develop my technical skills. We weren’t given any specific direction on how these chats should go, but they started off with the senior engineer helping me debug specific technical problems.

Over time, I had fewer problems I needed help to solve. Hooray! Personal development unlocked. One week I realized I had nothing to talk about at all, so I let my mentor know out of respect for his time. After all, I knew how much software engineers (especially senior ones!) hated meetings.

“Let’s meet anyway,” he replied. Okay, I thought — but don’t get mad if it feels like I’m wasting your time. He didn’t get mad, and I don’t remember what we talked about. But I do remember that was years ago, and we’ve been meeting weekly ever since.

He’s a staff engineer now, and I’m an engineering manager. Our careers have taken diverging paths, and we technically sit on different teams now that our company has grown. But I will be eternally thankful that we kept our weekly chats on the calendar — not just for our relationship, but because it taught me to do the same for others.

… even after you leave

One idea I’d like to try whenever I eventually move on is to see if I can keep at least some of these chats on the calendar. They probably wouldn’t be weekly or bi-weekly anymore, but the important part is that they stay on the calendar as recurring events, even if the next event seems comically far away.

I’ve received countless “goodbye” emails over the years. They’re all more or less the same:

Dear friend, my last day will be on [last day date]. I will miss you dearly but it is time for [a break/new opportunity]. Here are some [funny/poignant/otherwise memorable] anecdotes from working together, and (always) let’s keep in touch! [email, cell, LinkedIn, et cetera]

I’m a little embarrassed to admit that of all these emails I’ve received, the number of people with whom I’ve actually kept in touch is vanishingly small. Now on one hand, this is fine. People drift in and out of your life as time goes on — it happens, and that’s okay.

Plus, just because someone is absent from one act of your life doesn’t mean they’ll never re-appear in another. I frequently run into friends and colleagues from long ago, and sometimes we’re able to pick up right where we left off. This is especially true when former colleagues become current colleagues again. Given the incestuous close-knit nature of Silicon Valley, the chances this will happen are actually quite high. I’m sure someone’s done the math somewhere.

I’ve also heard that group chats, either informal ones or official “alumni” channels created by people ops, can help maintain connections too. I’m currently nomadic (hence the title of this blog), so whenever I drop into a new city I always think about who might be around for coffee or lunch. I can’t help but feel it’d be less awkward, or more natural, to reach out to people I’m still in contact with — even if it’s every 6 months or a message here and there — than people I’ve last spoken to a relative century ago.

In any case, no matter the tool or practice, the goal is the same: let’s keep in touch!

Wow, that was a lot

This post started off as a brief check-in on my first 6 months as an engineering manager. Then it never really stopped, did it? Until now, that is!

I guess I had a lot of thoughts bouncing around in my head. It feels good to get them out there.

Here’s to many more learnings, mistakes and wins, and maybe even a few more posts in the years to come.


Comments? Thoughts? Let me know! @yihwan 🐦


Read next

On the Origin of Digital Nomads


© 2021-present Yihwan Kim. All Rights Reserved.