I’m writing this from my new “office” which is a small desk in a large closet located under the stairs of my house. Harry Potter style. We have our first baby on the way so I got kicked out of our 2nd bedroom and I’m embracing the office-under-the-stairs life.
This isn’t a normal work-from-home situation for any of us. No one had time to prepare.
On Monday, March 9th our company started planning a test work-from-home day for our dev team that would take place Thursday the 12th. Before that test day was even over, we had made the decision to work from home permanently. When we left the office Wednesday we thought they were coming back. We never did.
Our devs are a resilient group. Morale is high and we continue to write code, ship code and deliver value to customers.
But as a leader (former VP of Engineering & Ops, now COO), I’ve been spending a lot of time thinking about how I should be helping my team right now. The truth is, I go to bed every night and wake up every morning thinking about it.
I’m not afraid to ask for help so I reached out to a few engineering leaders I know to see what’s happening with their teams and how they’re handling it.
They shared a lot of tips. And they had some questions of their own. I condensed 4+ hours of Zoom conversations and 6+ pages of notes into the 5 most actionable ideas that came out of our talks.
1) Micro-manage the extreme changes
Rapid product roadmap priority shifts are happening. Longer-term roadmap items are being rocketed to the top of the priority list and sprints are being disrupted. Rightfully so. The business mindset is emphasizing “how do we help our customers and prospects right now?”
Jeff summed it up well:
“I think the biggest factors impacting project delivery, right now, relate to the constantly changing environment we’re in… Our customers are reaching out to us more than ever with questions regarding changes we’re seeing across the logistics industry, and we’ve shifted a lot of our priorities from things that won’t deliver value for several months over to things that can deliver value today.“
Rapid priority change is always challenging for software teams. Add in all of the other rapid changes we’re dealing with right now and even more challenges will arise.
When there is a need to change and execute rapidly, you as a dev leader are most empowered to wrangle your ecosystem because your team is building the thing. Regardless of your leadership style, now is a good time to be hands-on. It’s an awesome opportunity for you to step up and shine for your company.
Tips from the group for leading your team through rapid change:
👉 Get buy-in from your team and ecosystem early.
It takes a village to rapidly change priorities and actually deliver. Not only do you need to ensure that your immediate team is bought in (team leaders, developers), you also need to ensure that product, UX designers, marketing and customer success are also a full go. The momentum of getting everyone moving in the same direction quickly is what will accelerate the delivery of your new feature priorities.
👉 Remove old work before adding new work.
It seems obvious but it’s easy to forget. In order to enable your team to rapidly embrace the priority shift, you have to take existing work off of their plate. This is the time to be firm with Product, CEO, etc. and ensure that you are removing the old work immediately. This will demonstrate to your team you’re serious about shifting course. It will help everyone mentally shift faster and all of your people will thank you for being conscious of their workload. If churn can ever be a good thing, this is the time.
👉 Balance your team’s WIP:
This falls into the basic visibility category. Priority shifts usually cause some developers and teams to be “slammed”. If a team or person is overloaded with WIP, you are not going to hit your delivery deadline and morale is going to dip. Take a look at the workload on each of your teams, have proactive conversations with your team leaders, and enable them to relieve pressure on their developers as needed. And be on the lookout for hero developers who think they can do it all and offer to take on extra. One of our jobs right now is to protect them from themselves.
2) Use work-from-home to your advantage
My initial thought was that software teams unaccustomed to being fully remote would take a productivity hit. And that actually is what happened to us at LinearB. Our overall Cycle Time is up significantly.
You can see our coding time (the time from first commit to first PR issued) went way up initially. Which makes sense. Coding requires uninterrupted quiet time to get in the zone. Something a lot of people didn’t have for a while there.
Our pick-up time (the time from PR issued until the first review comment) is also up. A lot of teams working in the office rely on talking directly to their peers when they have a PR in need of review. Again, a spike here makes sense since we can’t talk to each other in the same way.
By focusing on our process and each phase of our cycle, we know what we need to do to get back on track. We’re already seeing great progress.
But hold on… New information has come to light!
The GigSmart dev team is actually more productive over the past few weeks. Chris said
“We are actually seeing an increase in productivity across my organization since going fully work-from-home. And it is a little surprising because we are traditionally not a remote-first mindset company although we do have contractors that are 100% remote. There was a concern and worry from my ecosystem that productivity was going to tank. After our first week, I was looking at our numbers and was like ‘oh my gosh’, we are way above what I was expecting.”
Tips from the group for using work-from-home to your advantage
Open up a virtual “Coffee Talk” Zoom Chris shared several reasons he thinks his team is thriving right now. “Coffee Talk” is his favorite. Listen to him describe how it works and the benefits he’s seeing.
👉 Empower your devs who are normally remote to help everyone else
Many teams have some developers that are always remote. These people are used to getting by on Slack and Zoom alone. No lunch meetings. No hallway conversations. These devs will be better off now that everyone is remote because it levels the playing field for them and they can help show everyone else how it’s done.
👉 Don’t confuse more code changes and commits with customer value
When Chris showed his boss the COO (who owns product) the increase in the numbers, he made an insightful comment “That’s great. I’m excited to see how this increase in velocity translates to an increase in value for our customers.” In other words, if devs have extra time and they are using it to work on tech debt or pet projects, that doesn’t necessarily mean the increase in productivity aligns to company goals.
3) Prepare now for your transition back to the office
So let me get this straight… we’re going to spend months helping our team adjust to this new way of working and then one day we’re going to get the “all clear” and just go back to the way things were before??
Here’s how Jeff is thinking about it
“People are finding that remote work is a lot more convenient for their daily schedules due to things like removal of commute time, being able to perform tasks throughout the day like laundry, increased ability to eat meals at home, etc. Some people are doing things like taking a walk around their neighborhood before work to simulate a commute and get some exercise to start the day. These are some aspects of WFH that are going to be hard to adjust to when things get back to normal.”
I also personally like all of those things… even the laundry 🙂
Chris is thinking ahead too
“I expect to see a decline in productivity once we are all sitting next to each other again. My remote teams outperform in-office teams every single time. And it’s not because they are more talented. It’s due to focus ability, office layouts, and remote culture.”
It’s hard to imagine. But we need to be prepared. Even if productivity is up. Even if we have the data and results to prove it. Some of our organizations may not be ready for 100% remote to be the norm going forward.
So as engineering leaders, what should we do?
Tips from the group for going back to the office gracefully:
👉 Be prepared for some of your people to ask if they can continue working from home
It’s going to happen. And everyone that asks will have legit reasons for it.
Hopefully your executive team is already working on a plan. Either way, these are some actions you can personally take now:
Think… Am I open to having some/all developers switch to full-time remote?
Decide… Am I open to implementing certain days of the week as remote days?
Document… How will I communicate my thoughts to my CEO and executive team?
👉 Be prepared for some of your people to request adjustments to your in-office process
What are the biggest adjustments you can make to give your team the sense of comfort they get working from home?
Can you create more quiet sanctuary-like spaces where devs can go to get in the zone and get work done?
How can you optimize your meeting load and cadence to ensure that there are 3-hour work clusters that allow for focused development?
Jeff says “Ideally each team would have at least one 3-hour uninterrupted block of time every day. If we can have 2 of those each day that is even better. We need to find ways to make this happen rather than just accepting that the meetings on our calendar are there and can’t be moved or canceled or done in a group chat”
Is it finally time to get facilities to do something about the classic “the lights are too bright” feedback from your developers?
How can you maintain the momentum you gained with your devs that always work from home?
Can you keep the “Coffee Talk” Zoom channel going with the same enthusiasm?
Chris, Jeff and I don’t have all of the answers but these are the questions we’re focused on answering as we get closer to the day when we all get called back in.
4) Use more data when communicating with your business
Translating between engineers and executives is always a critical part of our job.
The combination of personal stress, lack of face to face interaction, priority changes and budget cuts put us under even more pressure to communicate clearly with the business right now.
CEOs want to know how priorities and investment levels are affected. CMO and CROs want to know the precise impact on feature deadlines. You may even find yourself presenting engineering directly to your board of directors like Chris did recently.
“Our board is in tight sync with dev. They are very invested in the product and want to understand our struggles. So when it comes to data… code changes don’t tell them much. Merge requests are an interesting proxy for velocity because if that suddenly drops you can tell we ran into problems. And now I’m introducing cycle time and showing them the phases of our cycle that we care about.”
So how can we better align engineering metrics with business goals?
Tips from the group for being an effective translator
👉 Back up your requests with data
Your CEO might be skeptical of any work style changes. The key to having an effective conversation is to come with data that provides thought out insights into why you are requesting a change. Doing this will show that you are serious about the change enough to build a business case. It will also allow you to take the fear and emotion out of the conversation which will lead to a better outcome.
👉 Use pictures whenever possible
People are visual. Even super-smart executives. There’s a reason your peers come to the meeting with beautiful charts and graphs from their respective systems of record (e.g. Salesforce, Hubspot, Netsuite, Gainsight). If you can translate your data from spreadsheets into dashboards, you’ll land your message more effectively.
👉 Give them a chance
If Chris’s board can understand Cycle Time, your executive team can too. I’ve heard dev leaders complain the only question they ever get from their business is “when is feature XYZ going to be ready?” There’s some truth in that of course. But I think sometimes we don’t give our counterparts enough credit. If we take the time to teach them the core phases of our development process and the key indicators for success, they’ll learn it. We learned about the core phases of our customer sales cycle. It isn’t that different.
Create a new playbook
I felt great after talking to Jeff and Chris. They didn’t have all of the answers but they also weren’t afraid to take action to help their teams.
Visibility leads to confidence. Confidence leads to action.