7 WFH hacks I learnt in organizing remote working in our startup
COVID-19 has first hurt, then helped us, get our shit together when it comes to working from home.
Thousands of years after our ancestors took a blunt reed to make wedge-shaped pictograms on clay tablets, communication remains one of the most important and overlooked aspects of running a company effectively. When operating a business, particularly a small tech outfit, real-time communication is key to everything from work distribution, to design and architecture or even troubleshooting.
As an entrepreneur, I’ve always thrived on — and strived to maintain — flexible work timings for my teams, believing in the fundamental principle that small, productive, self-organizing teams will always generate results. However, COVID-19 has plunged the world into an unprecedented era of remote working, and global lockdowns have forced teams to figure out a way to work remotely, productively, and effectively.
In the startup I have the privilege of overseeing, we implemented a few measures towards the end of March to make working from home effective. So, without further ado, here are the top lessons learned out of this journey.
1. Organize simple, effective scrum stand-ups with the right transparency
Scrum stand-ups are the bread and butter of working in a chaotic environment where tactical teams can only plan 24 hours at a time. Not all scrums have to be on remote meetings or teleconferences, scrum updates on workplace collaboration tools like slack are perfectly alright, as long as the updates are being given to everyone. A few important lessons learned from conducting scrums remotely:
- Coming prepared to a scrum meeting increases the likelihood of wrapping it up in 10–15 minutes with a 7–10 member team
- Scrum updates are for the team, not for the scrum master
- Avoid all technical deep-dives during scrum updates
- Send in your updates at any cost as a courtesy, not because your manager forces you to. It’s perfectly alright to binge all night on a weekday, and wake up at noon the next morning and miss the stand-up, just send in your updates; we understand crazy work hours these days.
- Biases, grudges, and fear have no place in scrum meetings. Be objectively clear, be brutally honest, even if the update is “I was extremely bored all day and couldn’t get myself to complete my tasks” — the unsavory truth is always better than sugarcoated lies in a scrum.
2. Pick the right communication tools, and learn to annotate
At appveen, we picked three primary communication tools; The ubiquitous WhatsApp for casual workplace chatter/reminders on key milestones, the superbly organized slack for day-to-day tech communication, and gold ol’ fashioned e-mail for anything official. I’m not saying these are the best tools out there; I’m just saying that these work effectively for us.
Ad-hoc remote meetings are either on zoom/hangouts. We use annotations in Google Docs/Sheets/Slides to comment/review on our work. We use Balsamiq for wireframes, Figma, and Adobe XD for screen design/creatives. The power of annotating google docs — or, for that matter — anything — cannot be expressed enough.
3. Organize the right story workflows
There are no one-size-fits-all workflows, put thought into what works for your team, understand where you can force things upon there, where you cannot, and design a workflow that ultimately plays to their strengths. Remember, a well-defined process should work for the team; the team shouldn’t work for the process. The workflows don’t apply to just engineering teams, but also sales/marketing/HR/etc. — it’s just a question of prioritizing them and including them
4. Avoid meetings
Many topics — including design, and design choices, do not require a meeting to be set up, the only exceptions being UX or complex architecture design. But simpler decisions (such as deciding whether an API should be a POST or a GET, or, what to name request parameters) can easily be done on slack. Encourage people to get together and use separate threads to filter out the deep-dive from hijacking the main chat thread.
5. Insist on overcommunication
Never — I repeat, never — accept discussions 1:1 unless they are sensitive in nature (financial, legal, personal, etc). Insist on EVERYTHING being discussed in the main channel, even if it’s a quick review of a document, a template, etc. In today’s day and age, no one gets to complain about spam on the slack channels; you can snooze notifications and choose to be notified only when someone refers you in a chat with the @ prefix. Otherwise, insist on every communication happening in the group.
An important aspect of the overcommunication principle is to discuss your thoughts in real-time. For instance, whether you are making a decision, or troubleshooting a problem, every single thing you do — trying out a few commands, thinking of a hypothesis for the failure, etc. — can and should be communicated on slack in real-time as you are thinking. This helps people understand what’s going on, and they can chip in to point you in the right direction (if you’re going the wrong way), or, validate your thoughts. More importantly, rather than just the decision, it gives people an insight into your thoughts, so rather than just accept your decision, they also know WHY / HOW you arrived at your conclusions.
For overcommunication to work, it has to work both ways: colleagues must give it to their teams, and teams must demand it of their colleagues.
6. Be inclusive
An extension to the previous point; never, ever, shut people out of a discussion. Invite everyone for every meeting. There’s no way you will make the next career step (from, say, development to architecture) if you do not help others make the same career steps and help you to fire yourself from your current role so that you can take up something more challenging. Give everyone — irrespective of seniority — access to what is being discussed. Just draw logical, soft, and porous boundaries around your teams.
7. None of this will work, unless …
… it’s culture. The truth is, you cannot force this down people. I’ve tried to explain this to many other CxOs who truly believe they can force processes and principles upon employees. It’s 2020; wake up and smell the kebabs — employees aren’t slaves, they’re partners in your journey as an entrepreneur, if they choose to work long hours, put in a higher level of intensity, or adhere to guidelines, it is not because of you/the organization, it’s because they feel vested in the company/product — financially, emotionally or otherwise. The only way we will work well together is if these guidelines are created, presented as — and executed — as a culture. Good luck trying it otherwise in a startup, in 2020 and beyond.
As managers, we have to remove from our folks the fear of fucking up. For this to work, our colleagues must not fear spamming, must not fear making mistakes. On the contrary, we must encourage co-workers to make their fuck ups public. We hired them — we don’t get to blame anyone.
Transparency, honesty, fearlessness, inclusion, and collaboration cannot be fabricated; it must be exhibited by everyone, especially the core leadership team. Easier said than done, I concede; but there’s no other way.
It is very easy to brush away a non-performing engineer, or write code yourself than guide someone into doing it. It’s also very easy to blame each other for their shortcomings — he has too much attitude, she’s not committed enough — but our jobs, as leaders, is to teach, guide, inspire, empower, trust — and then get out of their way so that they can do their jobs well.
Stay safe. Stay home. Let’s see this virus out and usher in a new era of remote working that’s clearly here to stay.
