Back to Resources

Preserving Developer Flow in a Cost-Cutting Climate

  • 4 Minute Read

Table of Contents

    Written By Alex Lewis

    Between AI fears and high interest rates, for many companies 2024 is the second year in a row of attempting to accomplish more with less. Peloton laid off 400 team members in May. Amazon and Tesla laid off many in April. Apple, Expedia, Snap, Sony, and Zoom have respectively laid off large teams since the start of the year.

    It's cost-cutting season in tech. But there’s still work to do. 

    Individual software engineers now face burnout, juggling the responsibilities once carried out by entire teams. It’s time for engineering leadership to bolster engineering productivity despite this cost-cutting climate. 

    That means preserving the foundation of developer productivity: Flow. 

    Preserving Developer Flow When It Matters Most

    Mihaly Csikszentmihalyi defines flow as “the state in which people are so involved in an activity that nothing else seems to matter.” It’s when you are so focused on a task that you get lost in the work.

    More specifically, developer flow is when an engineer gets lost in the work of writing code. This means spending significant blocks of time producing without distractions and interruptions like Slack pings, redundant meetings, and unstructured administrative tasks. 

    Preserving developer flow in any business climate is important. But it’s most important when engineering teams are strapped for resources like they are now. Engineers must maximize productivity.

    With lower budgets, more non-engineering teams rely on fewer engineers to accomplish the same amount of work. This pulls the engineer’s attention in many directions—the exact opposite of flow state.

    It’s your job as an engineering leader to preserve developer flow for your entire team.

    Thinking in Systems

    The biggest factor that prevents developers from entering flow state isn’t individual willpower or lack of time management. It’s a lack of support from leadership and existing internal work structures.

    Engineering leadership will feel downward pressure to keep engineers juggling numerous projects. But the best thing you can do for your company is defend the calendars of your engineers. The mantra during cost cutting climates is to do fewer things, but better. 

    Get crystal clear on the projects that matter and what tradeoffs must be made to prioritize them. Communicate those critical missions to your engineers. Then protect their time so that there’s always space for flow and deep work. 

    Francisco Trindade, VP Engineering at Braze, discusses how he thinks of priorities as “options” for business stakeholders:

    Work culture and internal structures might need to change during a cost cutting time. If anyone can put a meeting on anyone’s calendar at any time, then engineers will inevitably be pulled away from the work that matters most. Instead of coding, their work will devolve (against their will) into answering questions in Slack or joining meeting after meeting. 

    This can also create the problem of scattered meetings. As one company learned a few years ago, space between meetings can matter as much as the number of meetings themselves.

    Flow state doesn’t occur naturally in modern work environments. It must be intentionally planned. That means making it a normal part of your organization’s culture. Focus should be the standard. Distractions and interruptions should be minimized, not encouraged.

    Clarity of Mind Starts with Clarity of Impact

    Following a layoff, there’s one additional hindrance to flow state: Engineers fearing that they’re next on the chopping block. It’s hard to work effectively when you’re unsure if this week will be your last at the company.

    As an engineering leader, you should go above and beyond to communicate clearly with your teams. You don’t have to have all the answers. You shouldn’t make promises you’re unsure you can keep. Instead, be clear about the highest impact work that engineers can do.

    Engineers are builders. When resources are pulled, there can be dozens of unorganized projects awaiting completion. It’s your responsibility as an engineering leader to prioritize the few tasks worth doing. Clarify which projects matter and which ones don’t. 

    “The biggest value for me as the head of engineering here is the focus on the health of the person and the team. To be effective, you simply need to be able to protect your time and let your builders build.

    Drew Garner, Executive VP Engineering @ Accolade

    As a leader, your mission is to reduce the number of decisions that teams and individuals need to make on their own each day. When things feel uneasy and uncertain at work, you must go out of your way to provide a firm foundation. That means clear prioritization, communication, and expectations. 

    What Separates Great Engineering Teams from the Rest?

    At Uplevel, we’re in the business of measuring engineer productivity across enterprise teams. That means we have clear visibility into how the best engineering teams in the world get so much done.

    When we look at the data, there’s nothing surprising about the exceptional teams. If anything, their methods are only surprising insofar as they’re rare. It can be distilled down to one idea: Do the simple fundamentals well. The results will take care of themselves. 

    Here’s what separates world-class engineering teams from everyone else:

    World-Class Engineering Teams Average Engineering Teams
    Prioritize projects: The best teams are ruthless when it comes to cutting unimportant tasks and projects. If it’s not a priority, it’s not assigned. Work on everything all at once: Average teams have little sense of direction. Any project that lands on their desk today is as important as the one they received yesterday, and so on.
    Deep work is put first: Leaders at the most productive companies have normalized a culture that prioritizes deep work time. Coders have the space to write code. Work is unstructured: Most companies have no rules around scheduling meetings, pinging one another on Slack, or pulling others into a project. 
    There are rules around tools: New tools are adopted with intentionality and used with a clearly defined purpose. Teams (for the most part) use the same tools to ensure clarity across departments. Tools are a free-for-all: Each product team can pick and choose the tools they use. There’s very little structure when it comes to how, when, or to what capacity a certain tool should be used. Working in Slack is as important as working in a code editor.
    Clear communication is part of the culture: Documentation is standard. There are clear processes for launching new projects, defining scope, and determining which devs are responsible for specific features. Communication occurs ad hoc: Project management happens over email and unstructured meetings. Some things are documented, others aren’t, with no clear evidence of why. 

    Every Company Looks Great in a Bull Market

    When resources are plenty, it’s hard to tell the good companies from the great. Average companies can hire their way to productivity. It’s only when resources are scarce — like they are now — that you see which companies truly have engineering effectiveness and the ability to create great products efficiently. 

    Developer productivity requires space for deep work and flow. That doesn’t occur through sheer willpower. It’s the direct result of a good leadership team that prioritizes the most important work, communicates effectively, ruthlessly defends the calendars of their engineers, and gives each engineer the tools they need to work on their most important tasks.

    Lean Software Engineering Strategies for a Down Market

    Learn how leaders are doing more with less

    Lean Software Engineering (1)