Another early morning for me. Yep, still wake up at 5.30 (those who follow my journey know what I’m talking about). And yes it’s still hard to wake up, but it feels much better after my morning routine is finished.
Today I’d like to talk with you about working with and managing remote people.
Why?
First of all, I’m a big proponent of remote and think in the future most of the jobs (at least engineering) will be done remotely.
The second reason relates to the fact I’ve been managing remote teams overseas for the past 8 years and I’d like to share some tools and tips that help me every day.
In this post, I’m going to focus specifically on managing software engineers (coders) as that’s where I have the most experience.
Does it makes sense to go remote?
As you probably know there are a lot of debates going on whether companies should try to bring all developers under one roof to create this magical “team spirit”.
Sure, that could be beneficial and a bit easier to manage, but there are some cons as well:
- It’s extremely hard to find good engineers locally (and I think it will become harder and harder in the future)
This is probably the most important reason. The difference between someone great and someone not so great is HUGE when it comes to software engineering. It’s very hard to compete with big guys for the top talent on the local market.
- Hiring locally could be orders of magnitude more expensive
Well, I don’t think I need to go into details here. It’s pretty obvious – programmers in US are expensive, great programmers are VERY EXPENSIVE (if you can find some).
Plus we need to take into account benefits like health insurance, 401K matches…
- You need to maintain office and deal with a bunch of related mamba jumba.
I personally don’t mind office, especially now that I have a son 🙂 But it’s much easier to rent a small room just for yourself to be able to shut down all of the distractions and “switch” into the work mode.
It’s not only easier but much cheaper as well. You don’t even have to keep it permanently, thanks to the awesome shared office spaces.
- Don’t forget about the commute!
I recently wrote a post about my Penn Station experience. Yep, it’s not great to put it mildly.
The only thing I love about my commute is that it gives me time to read every day. Not so easy during rush hours when you need to stand all the way in the crowded train…
- Working at the same office every day limits creativity and could be very distracting
Let me explain. While I do understand that it’s great to see your people working hard in your awesome office (is it really that nice?), but in reality, you may be loosing on productivity.
Yeah, you programmers sit there, but it doesn’t mean they deliver results as efficiently as they could. I know because I’m the engineer myself and know this stuff in and out.
There is a lot of distraction. People scream, phone ring, ad hock meetings. Now there is this “awesome” movement of open offices which essentially promotes distraction even more… I personally hate open offices, but that’s a story for another day…
What’s funny is when people lose their cubicle walls thanks to the “shared space” / “open office” movement, they tend to use plants, piles of books, and fish tanks to re-create those walls.
When it comes to writing code, distractions are very expensive:
- It forces your engineers to stay at the particular location all day, instead of exploring the world (which again affects creativity and productivity)
I already hear screams like “BUT THAT’S WHY I PAY THEM SO MUCH MONEY! THEY HAVE TO SIT HERE AND DELIVER RESULTS!”.
Wrong. Wrong. Wrong.
In reality well rested and energized programmer can deliver 10X results. Even if she works only 5 hours a day. Maybe even less.
I think the same principle applies to all professions honestly.
Yep, I know, in the beginning, it could be a bit strange to not be able to find your employees immediately, but it also forces you to restructure and optimize the process. Make it more “out-of-band” should I say.
See, the most important thing you can do as a manager is to find out as many details as possible about the problem that needs to be solved and communicate this problem to your engineering team.
Then you need to let them find a solution.
A lot of times I see managers (especially technical leads promoted to management) that try to come up with very specific solutions and then make other developers implement those solutions. That’s wrong, it kills the creative process. Remember writing code is a form of art. Just like the painter, the programmer starts with the blank canvas and creates a masterpiece in the end.
Define the problem and let your engineers come up with the solution! They might (and most likely will) solve the problem differently than you would, but it will make your programmers happy, increase the trust and give you precious time to focus on the big picture. Win-win!
My tools and the process
Hopefully, I was able to convince you that remote engineering teams are the way to go!
Here is the extreme example before I forget, I used to have a pretty talented engineer on my team for 4 years and I never saw his face even once. Yep, that’s right. He solved A LOT of company’s problems over the years though.
When it comes to managing remote engineering teams the process is the key. It doesn’t need to be crazy complicated process, but it needs to exist.
Here is mine:
- Every day we have a short daily standup (meeting) at the same time where everyone has a chance to report the status of the current projects and raise any blockers (if any).
We do not use any fancy conferencing equipment and just use Skype or Google hangout. And no, we don’t use video during those calls, all we care about is the sound.
A lot of times I conduct those meetings while on the go with my iPhone and headset. Nothing fancy.
The goal is to make the call as short as possible. Ours usually takes about 20 mins or so. In case we uncover some major blocker during the call, we move it offline or schedule a separate meeting to discuss that particular problem.
- We use Trello to manage projects progress. Basically, we have 3 major lists (columns) called Icebox (big features or something with unknown requirements), Backlog (her we keep tasks that are defined enough to be taken by the developer) and Current (tasks that are currently in progress).
Then we also create Lists for releases (for example 15 Oct 2017) which we archive later on.
Basically, every task moves from the left to the right and end up in one of the release Lists.
As you probably noticed already, the process resembles Agile methodology. I had to modify it a bit to make it useful for our small team of 5.
We don’t use any well defined “sprints” or sprint reviews. It’s just not practical for small teams in my mind.
- Chat software is critical though. We use Hipchat at the moment – simple and useful (compared to Slack). Again, nothing crazy here.
-
Source control system – do I even need to mention it here? Well, I’ll do it for the sake of completeness. We use Github to keep track of the code changes.
Every feature that goes into master branch goes through Pull Requests and requires at least two OKs from other engineers on the team. Pretty standard again.
- Monitoring and observability – very important thing for the distributed (and local) teams. We use Pingdom, Datadog and Sumologic with occasional Newrelic traces when we need to debug some performance problems.
The key here is to create shared dashboards so every team member could quickly access any graph. We even considering writing a small browser extension to display the most important metrics right inside of the HipChat.
That’s about it as far as it goes for tools and processes. I try to avoid using anything that causes extra friction instead of providing real value for the team.
I’d like to mention one last tool/app that I think is the best for productivity enhancement – it’s called Google Inbox.
Let me give you a bit of a backstory here. Before the Inbox, I was using regular Gmail on both phone and desktop. It was working fine, but because I didn’t use any separate reminders/notes app (to be able to switch devices quickly without syncing data), I used to send emails to myself that would arrive as unread messages which I would later see and remember what I wanted to do.
Google Inbox changed everything for me. It was exactly what I needed.
Basically, it’s another interface for Gmail with a few important changes. The most important thing for me is the introduction of reminders integrated into the mailbox. Now, instead of writing emails to myself like I used to do, I just create a reminder with one click of a button and I can schedule those reminders for the future ( they even have recurring reminders) and quickly find all of those with the filter on top! Truly powerful and life-changing! Works between different clients, browser or mobile.
I use my Reminders as to-do items that I keep checking daily. There is even Done button next to every reminder with the additional filter to quickly see what was done in the past!
The other feature that I really like is the automatic email grouping. I have no idea how it works under the hood, but it works. Every day I get only emails that I want to read. If you stop reading emails from the specific sender for a period of time, Inbox will automatically start grouping those in the Low Priority folder. Really useful!
Try it out guys, Google Inbox combines the power of To-dos, Notes and classic email in one slick and fast app. Kudos to developers! Thank you for another great FREE product!
Leave a Reply