Redefining Productivity: what insights from remote work and speed layers can teach us

One topic has been on my mind lately: productivity.

Both connected with all the discussions about WFH and companies forcing back employees to the office, and connected to how we best organize product teams to ensure that we can deliver on both being responsive to market trends and long-term plans.

And I was so thrilled that last week I was at a conference where two speakers talked about these two angles of productivity and gave me some food for thought.

Darja Smite and Magnus Billgren made my head spin with their presentations and here is what I take home with me:

Three key takeaways on remote work’s future

Darja Smite is a professor at the Blekinge Institute of Technology and together with her group, she is doing some cutting-edge research about software development. What she brought on stage were some super interesting insights about the impact that working from home has had on companies, individuals, and teams. 

With data collected before, during, and post-pandemic from multiple companies in Sweden, she could provide an extensive picture of what the state of the remote work is. It is the first time that I have seen real and not anecdotical evidence of the rules that are set around days at the office, when people are at the office, what are the reasons why they are there, and what is the impact of this way of working on individuals and teams.

Three things stuck with me the most

1- Remote work demands getting beyond fears

To me the red thread beyond Darja’s data is that remote working is directly connected to fears. Therefore we have to actively acknowledge and act on them if we want to get this new model to work. Which fears, you might ask:

  • Companies bounce between the fear of not being able to recruit and not being able to innovate. As a result, they fail to find a way to organize hybrid work

    • Half of them have no central policies and delegate to managers and teams. This might sound like giving flexibility and trusting one’s employees, but it also comes with the consequence of having to accommodate too many individuals’ needs.

    • Half of them have policies, but they are set on a company level (anyone familiar with the 2-3 mandatory days at the office?). Look at the picture below, if you let people choose when to come to the office, the chances that all the ones that need to work together will be in at the same time are quite slim. Which defeats the purpose of having people in the office and collaborate.

  • Individuals are afraid of losing flexibility in their day-to-day and because of that they do not bring up issues of psychological safety connected with remote work, or it is difficult for them to highlight when they are stuck, afraid of being deemed not good for the job

  • Teams do not talk about the negative sides of remote work, anxious that the flexibility could be taken away, or that some team members might get labeled as not good enough for the job.

I think the biggest takeaway for me is that for hybrid work to work, we need to have discussions about it and not being afraid of acting. Not delegating to individuals but taking a stand, as a company and as a team. Flexibility requires taking responsibility, and in my experience, if you are explicit about it, it works.

2- Remote working requires shifting the focus from me to we

With remote work, flexibility is coming front and center, and with that the n number of individual needs connected with “what works for me”. If you ask the question “What do you need to be the most productive?” The answer is always different, from individual to individual, but also from day to day for the same person.

This is the flexibility paradox: if remote becomes optimizing for individuals, or for the company as a sum of individuals, there are too many variables to take care of.

This is why is super important not to fall into the trap of individual flexibility, but to optimize for tasks and teams.

Teams are the ones that are more impacted by the negative effects of hybrid work:

  • Remote work tends to significantly inhibit collaboration 

  • Remote workers are treated like series B citizens. I am guilty of saying the phrase “And now, let’s listen to what the ones on the screen have to say”

  • Remote teams tend not to talk too much about what is not working with remote in order not to risk individual flexibility

This is where the shift from me to we need to come in.

Some concrete examples that were shared were about having an explicit conversation about what is needed to succeed as a team. Make the responsibility explicit (to support new and more junior members for example), and dare to adapt to a synchronized hybrid - where everyone is colocated simultaneously and the major issue of the remote setting, collaboration, can be addressed better. By being in the same room and talking to each other, and by having lunch or other social activities together.

3- Don’t trust the urban legends on remote, data prove otherwise 

There were also some super interesting insights that Darja shared and debunked some common myths. So next time…

  • Someone says that remote work is more productive, you can point them at the graphs below and say that on average we are more productive, but there are also many more individuals getting stuck in their work while WFT

  • Someone says that individual asking about WFH policies in interviews are lazy and do not want to come to the office, say that there is evidence that these very same people are at the office more often. 

  • Someone says that you need to have a policy to make sure that people come to the office, tell them that fully flexible policies bring more people to the office than mandatory ones

Remote is about accountability as much as flexibility. Give people a clear goal, make it explicit on why it is important, and they will take responsibility. I think that as leaders and companies we have to understand that remote is not a problem but an asset, as long as we are explicit on how we want to work with it.

While remote work redefines individual and team dynamics, it's also crucial to understand how we organize various types of work to maintain productivity and innovation. This brings us to another concept discussed at the conference: speed layers.

Speed layers: A model to balance different development speeds 

One of the most common and most difficult questions to handle in product management is about organizing the different types of work that your team(s) have. How do you prioritize efficiently between the core and the stability features, the efforts that drive your strategy and you can plan for, and the ones that require more agility and are not foreseeable?

The struggle: Short-term eats long-term for breakfast

Raise your hand if you have recently heard one of the following:

  • We have to be able to seize the opportunity  when it arises 

  • Keep it stupid and simple, do not overcomplicate things

  • Speed is everything, we need to be fast!

  • Ecosystems are the future, we have to build a system

  • Build it fast, and scale it fast

There are so many expectations, and sometimes even conflicting ones. 

Product as an execution organization is expected to be fast, and it is also expected to be scalable and stable. It is not an easy balance, and I must admit many times I struggle with it myself.

Suppose you have had an hard time with making the business case for a really long investment, or advocating for initiatives that are not so easy to measure. In that case, you probably have felt my struggle too.

I’ve been writing and reflecting on the balance between speed and confidence, and I have also seen more and more companies drifting towards “speed at any cost” in the current economic climate. The core, or the features that make our product and are expected to work are taken for granted and all the effort goes towards growth. You expect the foundation to hold you up, but does it? And how many understand and support that it takes time to be fast?

So the real question becomes: how do you take charge of what your team/organization delivers and avoid only working on short-term efforts that can only get you so far, or only focusing long-term and missing crucial opportunities?

Image from Magnus presentation

The concept of speed layers

On the stage Magnus Billgren gave one concrete framework to tackle this challenge: speed layers - organize the work based on the speed that the different types of work require.

It was quite refreshing to think about the challenge from another angle: what is the expected outcome of the work and what is the time that is needed to complete it?

Magnus presented 3 different speed layers that you can use as a mental model to organize work for your team or organization. Here is what they are, with my words on it:

  • Mind The Core - The slow stuff
    Algorithms, ecosystems, platforms, operational models, and all that it is hard to copy strategic investments that is hard to calculate but mandatory to protect. These are bets that are almost impossible to create a business case about, it is what your company believes will create value in the long run. These are long-term leap investment. Speed: multi-years. 

  • Keep the edge - The stuff we can plan
    Features that make us stand out from the competition, strategy-driven, and proactive. This is what you can and should create a business case about to compare and contrast your opportunities, and this is what your roadmap is made of. These are the short-medium term investments. Speed: yearly.

  • Need for speed - The stuff we could not foresee
    Features that come up from the market, based on customer demand and where we have to be reactive. Here you expect a payback within 3-6 months, and something out in the market in no time. These is what you could not foresee but want to act on. Speed: as fast as you can.

My interpretation of speed layers

What I like the most about this model is that it helps define expectations - on the time horizon, on the possibility or not of a business case, and on the commitment and stability of the team.

And the interesting conversation becomes:

  • In which speed layer does your organization want to be?

  • Does your architecture support the different types of speed layers?

  • How do you balance different speeds on your roadmap based on where you want to be?

What are your thoughts about productivity in the era of working from home and speed-driven development?

Previous
Previous

HOW TO: make continuous discovery part of your development processes

Next
Next

My main takeaways from Drive