For those developers who suddenly have to lead a remote team and answer to stakeholders, I compiled a checklist that you and your teammates can follow to have a simple, transparent, predictable and frictionless workflow.
I spend my years managing remote development teams. Either you work on a client's project or a startup, any workflow stands on three pillars:
- Communication
- Task management
- Time management
To master those, we need frameworks and tools as simple as possible to get the job done without distracting you from creating the product. While I describe some frameworks below, I suggest you stick with Slack and Trello for communications. Harvest (teams of 5+, paid) or Toggl (5–, free) is the best if you're required to provide timesheets or you want to make a point.
Communication
- Use channels, avoid direct messages. This makes your chats transparent. With more than two folks on a project, you don't want to get in the "gosh, we forgot to tell this to everybody else" situation.
- Start a thread to discuss a particular issue. Mention only those who need to participate. Two points here: threads make channels much cleaner; you don't distract anyone who's not directly involved in the discussion, yet preserving their access to information.
- Wisely add integrations with other instruments like Github, Trello, and Sentry to have anchor points in discussions.
- Slack resembles an open space working environment. And yes, you require quality time alone. It's ok to turn off the app, but make sure that everybody knows how to reach you via phone or your personal messenger (btw, never continue work conversations there, return to Slack). And, never leave Slack when there is an ASAP situation.
Task management
-
Team leader special: subscribe to the boards, so you don't miss important messages and the big picture of your project. By subscribing, you allow Trello to send you notifications via email. Don't check your email on every inbox message, look through notifications during your everyday zero inbox routine and make sure (buy manually archiving each email) that you don't miss anything important.
- Here's my framework: make lists and describe tasks in cards. Make the priority cards top your lists. Then, take tasks from the top left and start moving them to the right.
TODO → IN PROGRESS → TEST → RETURNED FROM TEST → IN PROGRESS → TEST → READY TO PRODUCTION → DONE
-
Decompose tasks into subtasks: create "Frontend," "Backend," "Markup," "Questions," "Etc" checklists. You might want to split large tasks into smaller ones. Completing each small task provides its separate value, like, you can deploy a subset of features to production.
-
Deadlines, if added as due dates, are real. If you're not sure that you can make it, then move a deadline, so everybody can see it and act accordingly. Don't forget that it can take a couple of extra days to test, fix bugs, and deploy a feature to production.
- Learn a few hotkeys (hit shift + ? in Trello).
- Use color labels to differentiate tasks. This helps you evaluate progress and balance the team load visually. You can invent your own system or use mine: Backend, Frontend, Bug, ASAP, Non-tech, Tech debt, Design, Tech special, Discuss, Temp mark.
Time management
(optional, depends on circumstances)
- Install time tracker browser extensions and desktop apps. Assign a hotkey for popping up a desktop app.
- Track everything related to work: coding, fixing, refactoring, discussing, thinking, reading, etc.
- Track time from Trello cards (via the browser extension), so your records get attached to the tasks (useful for analyzing and reporting).
- No card to track? Create a new card (for example: “Update dependencies”), so the task can be visible, testable and trackable. In some cases (like general talk about the project) just track the project's overall time.
- Track honestly. Tea time, side chat? Pause. Forget to stop? Correct later. But never track time post factum.
That's how, after much back and forth, I manage remote teams. The goal here is not becoming a control nazi but ensuring the transparency of the processes and availability of information to achieve the comforting work-life balance.
Hope this post will help you avoid mistakes. Share it with your teammates if you like it. :-)
Oldest comments (33)
So much this.
I've been working as a satellite with a fully co-located office for a few years and I find it so difficult to enforce (or rather, nudge towards) this. Everyone defaults to direct messages and I have direct conversations with every possible combination of people on the team. But because they are co-located I assume folks just want to avoid notification overload on main channels.
Sigh
I think co-location is just an excuse for poorly written communication discipline. :-( It takes being a very patient person to fix this situation, but that's possible.
Facts are simple:
Different tools have different solutions for that. Slack has notifications settings and threads. But using them requires some effort at the beginning.
Honestly, I found it easier to try at all costs work with people who understand that than change others behavior... But still, if you're patient enough, then one by one you can show the benefits and convince everybody.
This is how Slack might look with an active discussion that notifies only the right members:
31 replies in the background. In this particular case, it was a simple feature gone wrong. Non-developer spotted the mistake only because communication was open.
Installing time tracking software/plugins into the remote developer's machine does not work and could potentially backfire.
First of all, there isn't a time tracking software in the world capable of tracking the time somebody spent thinking and reflecting about a solution.
That's bad, because the manager could think the developer is lying about the time he worked and the developer will want to spend less time thinking and more doing - which is not very good for the product.
Second, you want your team happy. A happy team will be more productive and effective. I haven't seen anybody happy with micromanagement or feeling like his boss is monitoring his every move.
Third, you have to let your team feel like you trust them. If your team member doesn't feel trusted, there will be lack of confidence and, therefore, less productivity.
A manager / team leader should trust their employees and validate their time based on each team member's productivity according to what they usually accomplish.
Invasive time tracking is bad.
Hi Erik!
I think you've got the "tracking" part wrong. It's not about installing spying software. It's about the frictionless approach for the time-tracking when it is really needed.
I completely agree with all the points you have written. But we need time-tracking sometimes:
It's impossible without data.
We're probably from different backgrounds. If you're from the startup world, you never had a need for this kind of data. If you worked with the clients, you should be familiar with this.
Also, I want to elaborate on two more points:
I install time-tracking software for myself to improve my estimates. I'll think that a task will take me six hours, and then I use the timer and see how off I am. Estimation has always been a weak point for me, so this is helping me build up a pool of data so that I have references if I am asked to estimate similar tasks in the future.
I did exactly the same!
Also, for a few months, we decomposed features very deeply and tried to estimate those tasks to an hour. Then we time-tracked it and watched the results. By doing this we learned to estimate better and it taught us to see things for what they really are.
So far, I've learned I'm freakin' terrible at estimating things! I need to be more focused, I'll be jumping between multiple tasks and next thing you know an hour has passed...and then another...whoops.
Great tips!
Re: Slack, a few additional thoughts:
/status :alien:and folks see 👽 they know I will only reply to DMs / @-mentions#headsupchannel where people post things that don't require any real coordination, but might be good to know about. The sort of thing you'd likely pick up on in a traditional office settings./remind #team "Share an accomplishment from this week" every Friday at 4pm ET.This is all particularly interesting to our team because we are fully distributed, and we're trying to do it the right way.
So I agree with a lot of it, and then also find spots where we're trying to go in a different direction.
This is probably the area we are most trying to experiment and get right. As a team distributed all over the world, we want to make sure asynchronous workflows are reasonable and be able to operate effectively without certainty about the status of others. It's all a work in progress for us.
All in all we definitely have less structure than is outlined here, but it will be interesting to see how we evolve. I've bookmarked this post and will keep referring back to it.
Longterm, we also need to try to find the right answers for the social implications of distributed work. Different people have different ideal situations in terms of ongoing interactions, face to face time, etc. And we're just trying to figure it all out too 😄
I'm still not sold on Slack being the ideal tool for remote communication. I think it works well enough for "everyone is in the office at the same time" type teams, but when asynch and catching up quickly and efficiently become important it falls short.
My biggest complaint with Slack is that it is too easy to fall behind and feel like you most of your time just trying to get caught up. I found myself reading through old channels that really didn't pertain to me, or were just people chatting nonchalantly, all to find the one or two messages that did matter.
Threads help, but getting everyone to use them properly is hard.
It would also be nice if you could clearly denote who a thread needs attention from. Eg in a #design channel it would be nice to create a thread like "Increasing accessibility on the checkout page" and to then mark the people you think need to see the thread. Right now it just gets blasted out to everyone in #design, which isn't bad, but not having a way to say "bob and jane need to read this thread sometime" kinda sucks.
I suppose that isn't entirely honest, as we could just @ mention them, but @ mentions usually suggest urgency that often isn't there in threads like this.
I think there are some outage tools out there that handle this by created channels for each outage, linking to them in a common #outages type channel, and then I believe channels are just archived upon an outage being resolved and cleaned up. I wonder if that approach might work better for remote teams with the right sort of app integration... 🤔
This is exactly how we use threads. With @ mentions. It is somehow ok for us without suggesting urgency. We're just trying to be really careful with each other's attention.
I suppose if everyone agreed that this was what we were doing, and everyone always used threads, it could work well. I'd be curious how this compares to one of the other tools out there (eg Twist)
My friend worked in Doist on Twist back in the day and he hooked me up on the early beta.
I think Twist is like Basecamp. It's good for planning and long conversations, but it sucks when you need to discuss something quickly because you end up in a direct messages conversation. I ended up using Trello + Slack, and Google Docs for planning.
I probably should mention that this is more an exception than the rule... In our case, we didn't need that anymore, because we use threads 99% of the time. Even if there is a new message in the channel, if thread counter is zero, it doesn't require immediate attention.
My most strong team almost never saw each other. The key factor here is mutual respect and love for our craft. I think it can work this way for almost everybody. Though it's still a very warm feeling when you finally see your peers. :-)
1 — At the beginning of my career, I had a completely fracked up big project (music social network) that our team should fix in a week. It was very long and taught week, but there were two lessons I learned:
From your brief comments, it seems the environment would be conducive to very strong maintainer tendencies. (With a risk of burnout.) It would be pretty soul-crushing for a builder to have no choices or freedom to create. And the stuff you mention in #3 or worse would be unsurprising (though still unhealthy) responses to #1 and #2.
I do wonder what kind of growth opportunities your devs have considering the first 2 points. Is there a path for them to take ownership of something above the task level? Just curious since this perspective seems pretty different from mine.
2 — I don't believe in pure self-organized teams. Not that I don't believe in people, but just because it's a huge overhead for each teammate, and it's more effective for one person to take the burden of prioritizing the work.
I used to take the responsibility of choosing tasks for the foreseeable future and prioritizing them. But then the whole team discuss those tasks (to better understand and find out the gaps) and everybody decides on what he takes.
So basically I think it's right to take on yourself the overhead + prioritization and let the team decide on everything else.
So say we all. :-)
3 — You know the answer — fire. But before, I think two things are important:
1) Sit with this dev and very carefully write down everything he's working on. Those devs usually forget to keep books in order. You'll need it after you fire him.
2) Make it very transparent. The team might love this dev, but up to the point until they see for a few iterations that he doesn't deliver. Then it's safe to remove him from the equation.
Can you clarify how the other team mates will realize “that he doesn’t deliver?”
Through transparency. It's a sketchy subject though... If there is such a problem, that a person is the soul of the team (that everybody will be really pissed of to see him gone) but doesn't deliver, there is an algorithm that I hope you'll never have to execute.
It's better to act quickly. Last time I saw it, it was 6 months later than it should be done. :-( Very important update was postponed and paused because of it.
I normally like to foster a team environment, but yea there aren't a lot of options available to you when someone is struggling. I do think transparency is best, as you mention. And if you can give the troubled person a heads up that you're concerned for them, that probably helps to make the whole thing easier for everyone. I find that when I speak to someone and let them know that I care about what they're going through, I can often figure out why their performance is low and work with that person. On a few occasions I've been lucky enough to learn that their low performance was related to a process that was really bugging them (so we changed it), or a life issue (so we gave them time), or a lack of excitement (so we gave them stretch goals). But sometimes, yea... it's just someone who might be happier at another job.
But wow. What a tough subject. This is probably the hardest thing someone can deal with. It's not easy on the team, the manager, or the person in question.
Thank you for responding.
It’s like breaking up. First, you try to fix your relationships (as you described above). But if it doesn’t help — you have to make the thought decision. :-(
The only difference is that firing somebody from the team is like breaking up in a polyamory group — so many interests should be balanced.
Thanks for this outline, Roman. It's great, I love the transparency. How do you deal with someone that's underperforming? Any tips?
Read this dev.to/rsedykh/comment/c2gl.
Though there are two kinds of underperforming:
If you see a lack of experience — you can guide a person towards the right solutions with some micro-management (breaking up code architecture for him, etc). But if it's lack of motivation — fire, you can't help it.
Yeah, that's good advice. I'm seeing the 'fire fast' theme appear all the time as I lean more about this industry. It's tricky though, it's a small world. Thanks for the reply.
Firing fast is about trusting your instincts and taking responsibility. It's way easier to wait for months and make sure that you are right to fire the person when you see the damage. But, still, the damage might kill you.
Yeah. Good point.
First I was talking about the toxic one. But then @cubiclebuddha brought up a few occasions with a positive outcome.
Of course, sometimes you'll encounter cases when a good developer stops delivering. Some troubles like his neighbors do apartment renovation and it's hard for him to work from home office.
When we're working remote, we might miss those things that are crucial for the well-being of our teammates. But I don't think that remote is some special case. Just talk to your colleagues as with your friends, observe their behavior, try to help. Help him with coworking space, send to the conference, or invite to your city to work together.
One of the challenges I face while managing a remote team is that people don't really update tasks on Trello or JIRA. Any suggestions on how to ensure that they do it?
In my experience, it helps when people understand fthat they do it for their colleagues, who depend on them. For example, a QA guy won't start testing until card in the TEST status, because he wouldn't know.
Another way was to make it as frictionless as possible. Integration with Slack, time-tracker, GitHub, etc. Saves little time but lots of friction.
I also always do that developers take a role in creating those cards. Before they start writing code, that must create a checklist inside a card with everything they plan to do and discuss it at least with one another dev (usually another dev who also works on this card). Then it becomes their own card, and they start caring more.
Though, if somebody still doesn't understand the importance of updating tasks to update the team and help everybody to understand the whole picture in the most frictionless and mistake-proof way, this person is probably just a bad worker. He can be a brilliant engineer, but he's a bad team player.
Ah! That clarifies it. I guess you cannot force people to do things and maybe have a decent conversation with them to understand what the problem is.
I'm really not a fan of what I see here, it is just the same usual advice that always shows up "Task Management" and blah blah blah. With an article title of If you ever have to lead a remote dev team... the advice should be something way more important.
I'll give the following instead:
If you ever have to lead a remote team, make sure you are explicitly available. While co-located, it is easy to see when some one is "available". They may be getting water, or sitting at a lunch table. They could standing around the coffee machine talking about nonsense or walking to their next meeting. When remote, you may get a little green circle next to your name in Slack that tells you "I'm online". But what this doesn't do is tell you I'M AVAILABLE. This is one of the biggest challenges.
It isn't about being available, it is about being available.
Misunderstood those phrases are the same, but really being available means that others can actually come talk to you. If they never do but have a problem, then irrelevant of what you say or how available you think you are, you really aren't.