Talking to several business owners and employees around me, I’ve noticed that working from home is still a sensitive subject a year after the world resumed normal operations. Businesses coming up with innovative ways to make it harder to let people work in the manner they feel most productive seems obviously counterintuitive.

Having worked remotely for over 8 years now, I’ve learnt that like most things, it’s teachable and can be immensely productive and enjoyable in most situations. It’s important to understand that remote work isn’t an all-or-nothing sort of arrangement. Workplace interaction offers a lot of different benefits and making it accessible in the remote context alleviates a lot of the fear that invokes an immediate knee-jerk reaction to the subject. Making sure to include everyone is essential to the overall effectiveness of working remotely as a team.

There are millions of reasons to reject the “remote way”, but if you’re looking to make a real effort to embrace the practice then here’s how we do it.

Solve for face time

Usually the CEO and the ideation crew demand face time, and it’s usually brainstorming and follow-ups. Brainstorming is more about bouncing off energies. If it were about clarity and direction, we wouldn’t have so many in-office meetings that end inconclusively. It’s only hard in the beginning to switch approaches. Faith and trust alleviate more concerns than dashboards and project trackers. Once again it bottles down to comfort. I’ve worked with CTOs that chose to call someone, over clicking a link that opened JIRA charts and dashboards.

Often, it’s the resistance to change that makes it hard. It’s harder to carefully plan ahead. Concrete discussion points and arguments require dedicated uninterrupted time. It’s definitely easier to wing it. So the resistance is natural and being dismissive of it can be hurtful.

Brainstorming is real work and requires dedicated time. It induces a rush that drives action. It’s critical for businesses to have productive brainstorming sessions to propel them ahead. The real problem we’re solving here is ensuring everyone comes energized for these discussions. If the ideation crew is periodically co-located for these sessions, it makes remote work seem achievable. This buy-in is critical.

Teach Them To Write

One of the best ways to get product and business teams comfortable with the remote ways is to share product specifications and ideas a day before the meeting, even if you’re meeting in person. These are usually one-pagers during the ideation phase and more detailed documents during the implementation phase. It ensures the context is clear before the discussion begins. The arguments are posed quickly and noted down for a response if one isn’t presented right away. If the answers don’t emerge within 2-3 meetings, you’re probably not ready to start working on the idea anyway.

Writing for product is about the purpose and appears most effective when it’s a narrative and often, less direct. It usually describes the problem, the market (or the value) and the solution. It provides room for questions and is usually effective when the person leading the discussion has the expertise or access to an expert in the domain.

Writing for engineering takes more time and meticulous work. This starts with setting up the code. The setup documentation must be fast and easy to follow. Ensure your instructions cover docker-compose and an approach for complete local installations. Provide access to sample datasets. Ensure the engineer can copy installation steps line by line and have a working system in less than a day. Ensure the documentation includes steps on how to run migrations, launch tests, create pull requests, run load tests, the coding standards, the database schema, access to passwords and environment variables and common gotchas with specific environments. Writing documentation and specifications is a practice. The more you do it the better it gets. Dedicating effort to incrementally improving the documentation is essential.

Timeboxing

Timeboxing doesn’t necessarily help, and having fewer context switches does. If you’re jumping into a product meeting after toiling away at something entirely different, it’s likely that it may not be as productive as when the time leading up to the meeting was devoted to the topic at hand. So, if it’s an ideation meeting, try to see it through. Aim to reach a conclusion within a few sessions or defer it till clarity emerges.

Use All The Tools That Make Life Easy

There is no honour in the struggle. Product documentation for engineering takes practice. Ensure you use the tools at your disposal that make life easy and improve visibility. Maybe use Confluence, as it easily connects with your primary management tool. Connect your project management tool to Git. Ensure, error reporting tools alert with the right kind of errors without being too chatty. Ensure your product dashboards and metrics give you the basics at a glance. You don’t always have to use it, but it’ll offer additional insight when you need it.

When new engineers are assigned work, the specification should contain a summary of the broader goals the feature accomplishes. Context is everything here and teaches engineers to care. Start with writing down where to find the contextual services. This may require engineering managers and product folks to have technical skills (Yes, you’ll need managers that can code). Define, how you’d envision the application layer to function with pseudo-code (or even actual code). How the application layer speaks to the domain layers and the side effects it triggers. Define the basic criteria for acceptance. Create a branch off of the `main` for them to start work. This may seem like a lot of work but over time this will simplify execution and build context faster.

Once the work is done, offer the same documentation to a peer and let them review the code. Ensure colleagues actually read the code and offer meaningful corrections with justification. Write tests.

You Don’t Have To Commit Code On Your First Day

Allow colleagues to take their time to understand how things work, and why they work the way they do. Let them brush up on things they don’t know. Make it easy for them to reach out. Check in on them to know if they’re comfortable and need help with context.

What If It’s Urgent

JIRA has an urgent flag. There’s always Slack but it’s important to acknowledge that urgency is contextual. If you’re always marking stories as urgent, maybe your process needs more attention. And it’s important to be mindful that tasks that are actually urgent and critical might get missed if everything is marked as such.

Write Tests

Teach engineers to write tests. Teach them about dependency injection. There is no sidestepping this. Setting a CI/CD pipeline is easier than it’s ever been. Automate as much as you can. Make it easy to release quickly. Simplify the day-to-day. Pick a style of development you’re comfortable with and embrace it fully.

Make It Acceptable To Wait

Don’t expect or offer immediate answers but ensure no question remains unanswered. Use Slack judiciously. Set up a cadence for formal sync-ups, stand-ups and honour schedules. Ensure your calendars are up-to-date. Show up on time and respect people’s time. People don’t need to work the same hours as you do as long as they honour their commitments. It takes maturity but it works.

Speak To Your Team

It doesn’t always have to be about work. Learn about your colleagues, their goals and ambitions. You don’t have to party with them but being able to understand their lives will make it easier to help them be their best self. The friendships and feeling of camaraderie that become the biggest proponents of an office setting can very well be created in a remote one, if we allow the space for them to grow naturally.

Share The Decision Flowchart

I’ve never seen anybody gush over JIRA but there is enough documentation and answers to help you deal with a problem. Stay abreast with the bleeding edge but build a system to embrace something new. Ensure that everyone knows the questions they need to be able to answer before advocating the use of a paradigm, tool or technology. Share your guard rails. Don’t kill fleeting enthusiasm, put it to the test instead.

Proof

There are several famous companies in the world that can be used as great examples of working remotely. Automattic and 37signals are among a few I’ve followed very closely. Ours is a 14-member engineering team with our clients at Alphacoach, including product and design, that have stayed remote and distributed across cities from the inception. The teams commit code to a giant monolithic code base that drives all core business functions several times a day, and deploys to production multiple times a week. Our code gets deployed via Gitlab to an ECS Fargate cluster on AWS. We communicate on JIRA, Confluence, Gitlab and Slack and every single member of our team has been onboarded remotely. If you’d like to know more about how we write, onboard and train, please write to us at hello@core27.co