An open letter to everyone that I will ever work with as a remote tech worker

📅️ Published: June 11, 2024  • đź•Ł 10 min read

đź“Ś career

I am writing this letter as a summary of my work style and expectations as a remote software engineer. Consider this post as a source of truth to the way I think about work, how I communicate, and other team culture related thoughts.

Assumptions

  • I am working in a remote-first environment. If I am working in a hybrid environment, this letter applies to me from working from home as well.
  • My team is distributed across different timezones.
  • I am working in a team that is using Atlassian products for project management and Slack for communication.
  • My total work hours are 8 hours a day, 5 days a week. For the sake of this letter, let’s assume I start working at 12:00 PM and end at 8:00 PM “on paper” in my timezone.
  • At the time of writing this letter, I have been in the professional software engineering space for 2.5+ years. I will keep the letter updated, as I change my style.

Communication

Meetings

  1. Before scheduling ANY ad-hoc or one-off meeting with me, please send me a heads-up, doesn’t matter how it comes, you could casually mention it during standup or a different meeting or send a message, “Hey bhupesh just a heads-up we have a client call tomorrow I will be sending you an invite, LMK if you are unavailable”. If I don’t say anything, consider it as a “Yes” although I will use emojis like 👍 or ✅ to acknowledge.
    • I just want to know that I have a meeting coming up. It also doesn’t matter if my calendar looks empty. But it’s ultimately my calendar, you have no right to schedule a meeting without my consent.
  2. It’s expected from me that meetings that are recurring will be on my calendar like Standups, Sprint Planning, Sprint Retrospective, etc. I will attend them unless I can’t. I will inform that it on the team channel.
    • I don’t know how others work, but it’s possible that I may get lost in something just before the meeting starts, making me late. Even though I will eventually join the meeting, please feel free to send me a reminder.

Slack

  1. I don’t have the “Slack” app installed on my personal phone, and please don’t expect me to (unless of-course you are providing me a work phone). I will not use the Slack app on my phone during everyday work hours unless I am travelling or on a vacation, for which you will be informed at least a week in advance.
  2. When I am working, it’s obvious that my work laptop is open, but it’s not necessary that I will be on slack all 8 hours of my work time. I close the slack app on my PC regularly to get rid of distractions. Rest assured, your message will be replied to within my working hours.
  3. Even though slack represents itself as a “real-time” communication tool, I don’t treat it as one. I will reply to your message when I am free. I don’t expect you to reply to my messages immediately, either. I may be away to make lunch, taking a break, or just away from my desk. I will not update my “slack status” for ad-hoc breaks. If I fail to reply to your message within my working hours, please send me a reminder.
  4. Please don’t call me on slack, unexpectedly. I will not pick up. I will call you back when I am free. If it’s urgent, please send me a message first. I will reply to that.
  5. If for some reason I realize that during a communication thread, we are jumping on arguments with each other (or blaming each other). I will drop the communication right then and there. This is different from holding my position in a discussion. I will not engage in a conversation that is not productive. I will take a break and come back to it later.

Email

  1. When I start working, I will open my mail to check for any important updates. This doesn’t mean that I will open my email at sharp 12:00 PM. I will open it when I am free. If a reply to an email is expected, you will get it within my working hours.
  2. Since we are talking about remote culture, if you are emailing me, I know that it’s “not something urgent”. If it is, please send me a slack DM.

Engineering Work

  1. I value documentation, so you will see me creating niche documents on confluence and link to it in team channels or in JIRA tickets. You are free to write comments in those documents and ask clarifying questions but I don’t expect the team members to replicate what I do (or even read the docs). I am writing these docs for myself, some of them may eventually become critical & maybe referenced in meetings and conversations by me.
  2. If I am involved in a late-night production release, I will be on the lookout for any production issues until my shift ends, so my slack would be open to communicate and resolve any critical issues. I will extend my shift end time by 1-2 hours on critical release days.
  3. If PR reviews are delayed by a team member, and the work is critical, I will not wait for reviews and merge the PR informing the same to team members.
  4. I am NOT coding 8 hours a day. Don’t expect me to. What am I doing? Thinking, reading, debugging, procrastinating, attending meetings, cooking food.
  5. If processes are not already setup for activities like data migrations, deployments, rollbacks, git branching strategies, etc. I will take the lead to set them up & share them with the team. I expect the members to adhere to these processes to the best of their abilities.

Initiatives

  1. If I end up working in a full-time capacity with you or your organization, you will see me being active in a channel where I consistently share interesting engineering reads from the web. I don’t expect you to read or hangout there, but I will keep sharing. I like doing that, I believe that it may help other team members. You are free to share your reads as well, or start a discussion on any of the articles I share.
  2. If your organization decides to set up an engineering blog (or already has one), you will see me active a lot in conversations around it.
  3. You will see me create JIRA tickets to improve the developer experience (DX) within the team, i.e., things that will improve productivity within the “engineering” team. Some examples,
    • Writing tests for different modules.
    • Improving build or CI/CD pipelines.
    • Using 3rd-party tools to improve code quality or code security issues.
    • Updating outdated dependencies.

    If we as a team have decided to incorporate those tickets in our everyday sprints, great, but if for some reason we are in “hustle mode” and we don’t care about anything other than a working product. I will still make pull requests for these tickets from time-to-time. I will ask for reviews in team channel, if I don’t get any after sometime I will merge them myself.

    With time, I will analyze how the team is responding to these tickets or pull requests, if I see no engagement either positive or negative, I will stop creating them. I don’t consider this as wasted effort rather I am trying to test waters here, “How does my team think about this” if the team doesn’t care, I will adapt to that style as well.

Product

Empathy

During my very first job, I understood how important it is to have empathy for the end-users. However, it’s not easy to build it and can sometime take months to understand the core problem of the end-user and relate to them on a personal level.

I expect that people who are hired to manage the product are helping the rest of the team to build that empathy. If not, I expect founders to share interesting tit-bits from people in the ecosystem we work in. This is enough for me to understand how the user-space that we are building for, thinks or works.

Critical Work

I assume that whatever I work on doesn’t endanger the life of the end-user. At best, we are fixing a problem by building a CRUD application, at worst the application crashes during a possible money transaction.

Where I am getting at is that I will make mistakes, I will write bad code sometimes, I will not be productive all the time. Please hire an AI if you want a 24x7 productive worker.

At best, you can expect me to,

  1. Deliver the work I was assigned to do, or I agreed to do.
  2. Communicate with the team.

Anything else, is largely superficial and depends on the team culture.

Feedback Loops

It’s possible that our team might not already have a feedback process setup. In this case I advise you to either give me feedback directly, but I don’t expect you to do that, you might fear confrontation or you just don’t care what happens. In any case, I recommend giving feedback to my immediate manager.

During my 1-1 calls with my immediate manager or founder, I regularly ask whether any team member has shared any feedback for me.

Middle Ground

Some managers and founders are rolling their eyes, This bhupesh doesn’t seem like a person I would like to work with, and you may be right.

What I do understand is that building a product requires team effort, so I would be willing to change my work style well within the boundaries set above in desperate times.

Sincerely,

Bhupesh Varshney