3 Dev Leaders Open Up About Remote Software Development

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. When we left the office Wednesday night we thought we were coming back. We never did. During the test day Thursday we made the decision to work from home permanently.

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.

Chris Downard, VP of Engineering at GigSmart, and Jeff Juliano, Director of Software Engineering at VeriShip, are two of the smartest dev leaders I know.

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 4 most actionable ideas that came out of our talks.

1) Lead from the front during extreme priority 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.

Anyone remember Lemmings? I used to love this game. Our devs are NOT lemmings but it helps to get everyone aligned around one goal in the game and real-life. 

👉 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

Review each team’s workload

Make sure no individual is taking on too much

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.

Cycle Time prior to 100% work-from-home:

First weeks into 100% work-from-home:

Most recently after our team settled in to 100% work-from-home:

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.”

Team productivity and efficiency numbers from GigSmart’s LinearB dashboard. 

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 devs are used to getting by on Slack and Zoom alone. No lunch meetings. No hallway conversations. They are better off now that everyone is remote. At GigSmart, Chris is seeing a noticeable increase in productivity from his devs that normally work remotely. It makes sense because the whole team is living in remote culture now. The playing field is level for them and it’s easier to collaborate with their teammates. Give them time to share their tips and best practices with everyone else.

👉 Don’t confuse more code changes and commits with customer value

Individual productivity does not necessarily translate to team productivity. When Chris showed his boss Mitchell (GigSmart 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. 

And Chris pointed out the effect one dev can have on many teammates. 

“Remote devs usually are higher performing individual contributors because they are essentially heads-down uninterrupted all day. In-person team members are spending time collaborating, pairing, etc. We consider this a “force multiplication” in that if one dev can unblock or improve the speed of 5 other devs, it’s more beneficial for them to stop working on their own deliverables and help their teammates. It’s not that this collaboration can’t be done remotely. It can and we’re trying to find the right balance. We know remote devs can be more productive but can remote dev teams be more productive… that’s a question we’re trying to answer.”

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 individual dev productivity once we are all sitting next to each other again. Our remote devs typically outperform in-office devs. It comes down to synchronous versus asynchronous communication, office layouts, and remote culture.”

It’s hard to imagine. But we need to be prepared. Even if productivity is up. Even if it is translating to more value for customers. 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) Show 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.

LinearB Investment Profile view.

👉 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.

Visibility leads to confidence which leads to action.

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. 

I felt great after talking with Jeff and Chris. Something about their high level of confidence really struck me. They didn’t have all of the answers but they also weren’t afraid to take action to help their people. 

As I thought about this I realized they have something in common… strong visibility into what’s happening in their teams. 

They have qualitative data from listening to their teams. Jeff sent his team a questionnaire to give them a chance to open up about what they’re going through. Chris listened to hours of conversations on the Coffee Talk Zoom. 

They have quantitative data from LinearB and other tools showing how their people, process and productivity has been affected. 

This information gives them the confidence to take small, incremental steps to help their teams each day. 

That feels like the right approach to me. So that’s what I’m going to do… Stay connected to my team at all costs. Find ways to help them each day. Formulate a plan for the future but stay prepared for anything. Have fun during the process. And of course, continue asking smart people for help.

Visibility leads to confidence. Confidence leads to action. 

Previously published at https://linearb.io/blog/3-dev-leaders-open-up-about-remote-software-development/