BA 43/52: 3 Years As Remote TPM

And the observations and lessons I picked up along the way on how to be productive in a remote era.

The pandemic resulted in the largest workplace experiment at a global scale. Prior to this, fully remote work was something of a novelty. Many companies, big and small, still cling to the mantra that in person will always be better. They all have their reasons, some good, some bad, and some are well ridiculous at best.

For me, someone who never worked remotely in his long career, the past years have been difficult, educative and insightful, but difficult. I have had to recalibrate a lot of my Technical Program Management methodology and philosophy. Along the way, I have picked up a few observations that I wanted to share, in hopes that for those TPMs, PMs, and Engineering leaders struggling with this new future of work or actively seeking remote roles, they might have additional data points to recalibrate their own methodology and approaches to managing software programs.

Lets start with some observations:

• We went remote and everything became worse — If you had issues with collaboration before the pandemic, those issues will be more pronounced when you go remote. It has nothing to do with going remote or rather remote may have exposed core fundamental organizational issues. So, before blaming remote as the root cause, I suggest organizations do a deep dive analysis of what productivity issues they had in the past. If suddenly those specific issues have increased in intensity, I would consider identifying solutions for those issues before dismissing remote work culture.

• Engineering teams are less productive when remote — A year into the pandemic, during a staff meeting for the Nike Digital Agile Program Management team, a statistic was shared that still blows my mind; more than 50% of engineering teams reported that their productivity actually increased by significant margins by going remote. Before proclaiming remote work as a harbinger of productivity, and in person is the best, ask your engineering teams what their productivity levels are after going remote? Keep a periodic check on this statistic. If we can be data driven in our product development, why are we not data driven when it comes to organizational policy, design, and structure.

• Remote is hard and employees aren’t happy — There is a lot to unpack here but here is a thread to pull on: just being able to work from anywhere is not enough especially if this is not the default state that your organization started with. You cannot also call it a day by getting a Zoom Enterprise and Slack subscription. Fully remote means a complete overhaul of how you do work as an organization. Amongst my friends and professional network, the biggest complains I hear about going hybrid (part in person, part remote) is the remote people struggle to stay connected as the in person system of work remains, in many cases ignores remote needs, and has not been updated to match the hybrid model.

• Not everyone can go remote — This is unfortunately true. Even though companies like Apple and Google have continued to ship hardware even during these pandemic years, I know for a fact that a great number of their hardware teams never stopped going to work. I have yet to see a fully remote hardware centric company but I am confident someone will make it happen. That company will chart a whole new branch of possibilities for the future of work, not just remote work.

• We are not fully remote, we are hybrid (as in you come to work on Monday, Wednesday, Friday) — Look, seriously, I will always be fascinated by the tech industries terrible choice of terminology definition and terrible ideas with it comes to organizational design. In my opinion, Hybrid is an option to be in person or remote from anywhere. If you are looking at remote opportunities and someone says “We are hybrid”, never forget to get them to clarify what that means.

Now, for those companies that are either transitioning to full remote or sticking to a hybrid policy (see my rant earlier), here is how TPMs and PMs can help their engineering organizations through this process:

• Develop a writing culture — Collaboration entirely depends on all those involved knowing exactly what is happening at any point in time during a project. In the remote collaboration era, the written word becomes more important, sacred. TPMs and PMs should start a practice of writing things down. This is more than meeting minutes and work breakdown trackers. Formal tools like 1-pagers for any project bigger than a week, or a sprint become the primary alignment tool for remote teams.

  • Why? Writing promotes two things - easier active sharing of ideas and opportunity for others to collaborate through comments without resorting to expensive collaboration methods like meetings.

• Move from Siloed to Town Square Communication — One of the startups that I am an angel investor has completely banned DMs and private channels in their Slack workspace even before the pandemic. All conversations including code reviews, individual work plans, issue discussions, project road blocks, everything that is engineering specific happens in public channels. Shared documents become the sources of truth, open to everyone by default. This can be, for many, a jarring experience to walk into but this startup leverages threads to a phenomenally methodical level creating this town square like environment where you have no excuse to not see what is happening across the entire organization.

  • But that’s a small startup, can a big corporation like Apple do the same? That is a great question. I believe, yes. But, it requires that everyone is bought into this concept and actively police themselves to not fall back to DMs. A big part of this is going to be psychological safety, without which this will never work.

• Async the day to day; Synchronous for setting tempo — Every day things like standups, discussions, water cooler chats, idea sharing and discussion, those are great areas to automate and make async. That will clear unnecessary time sinks from peoples calendar. Reserve frequent but spaced out synchronous meetings for planning, demos, decision making that needs lengthy discussions with leadership, etc. These synchronous events set the tempo for what gets discussed in the async day to day channels.

  • Avoid things like forcing engineers to respond to stand up reminders by 9AM. Give them space and time.

  • At the same time, leadership must show equal effort to read the async communication, be responsive, and actively share information otherwise you risk developing “going through the motions” process failures.

• Design Information Architecture for Both Readability and Discovery — As you develop a writing culture, along with discoverability, readability will be a necessary element towards a successful transition into this new mode of operating.

  • What do you mean by readability? Readability is not about using short sentences, with clear meanings, and avoid lengthy jargon etc etc, no. What is the current state of the document? What version of the document is this? Is this document approved, deprecated, or active? Who is the author and contributors? TPMs and PMs must work with the engineering teams to develop a robust, clearly defined documentation lifecycle which also includes what to do with documents that are no longer applicable or need to be deprecated.

• Town Halls > Awkward Zoom Mixers — This is a personal opinion of mine and many can disagree with me on this but, I would prefer spending two hours in a town hall with the leadership team open to any questions, sharing company updates, celebrating the wins and losses, than an awkward zoom mixer. I mean a genuine effort by leadership to open themselves up and subject to any and all questions from the rank and file. This is not a sermon but a conversation. I saw the value of something like this with TGIF at Google. I have heard of examples of this at startups founded by ex-Googlers. TPMs and PMs can help leadership develop this town hall into something meaningful. As for cadence, start with monthly, try weekly if you can, and adjust as needed.

• Redesign, Redesign, Redesign — Zoom fatigue, transactional interactions, information overload, you have heard it all, the consequences of going fully remote. Yes, those serendipitous conversations by the barista or water cooler is now a 5 min Zoom chat sliced between 30min meetings. This has led to many calling for less meetings and so, we TPMs and PMs being good team players and organizational citizens, do our best to subtract meetings from calendars. However, I argue what we need is not subtraction but redesign. An engineering leadership and organization with high-levels of retrospection and self-awareness is always looking for opportunities to redesign the way they do work. So, instead of subtracting meetings, try re-designing them. I recently came across a HBR article that is great inspirational source for what I am referring to. The redesign doesn’t have to be with just meetings but it can be the way you plan, develop, make decisions, everything needs to be redesigned in order for remote to be successful.

I am positive there are numerous examples of how companies, in particular engineering organizations, have adopted to this new era of remote work. I would love to hear what you or your organizations have done to adjust going remote.

Final thought — I will emphasize again, just giving permission to your employees to go remote is not enough. You must rework and recalibrate all your systems of work in order for remote teams to be successful. Otherwise, you can’t claim to have giving it a fair shot.

Until next time 👋!

-Aadil

---

How was this week’s newsletter?

🤯 Amazing

😄 Good

😊 Okay