Check out the on-demand sessions from the Low-Code/No-Code Summit to learn how to successfully innovate and achieve efficiency by upskilling and scaling citizen developers. Watch now.

The modern workplace is full of distractions. Once a bastion of cubicle-sized fortresses of solitude, it’s now a buzzing hive of activity, fueled by the rise of open office spaces and an emphasis on teamwork.

Indeed, we’re in danger of over-collaborating – too many opinions, too obsessed with consensus, not enough time spent getting work to the “done” column.

Over-collaboration is especially tough for software developers, being people who decided to pursue a career requiring long stretches of time spent alone, solving problems. It’s not hard to figure out what problem we should work on. What’s hard is finding the hours and gumption to tackle it.

At a time when our urge to collaborate and our need for “deep work” are pulling us in opposite directions, what’s a development team to do? The answer is surprisingly old fashioned: Develop some self-discipline.

Cultivating the discipline needed for deep work

As a manager, when I look to assess the effectiveness of a team, one metric I consider is the amount of unbroken time a developer has to concentrate in a given week. We need space to dig deep into solving the problems and writing the code that will propel humanity – and our careers – forward.

I equate writing code with scuba diving: It takes a long time to shut out distractions and descend into my zone, but once there, I’m highly productive and time seems to behave differently. It’s an amazing feeling. If I’m interrupted at that point, I have to re-fight procrastination as I battle my way back into the zone. So I try to stay submerged as long as possible.

Some of my strategies include:

  • Setting up a distraction-free “focus mode” on my laptop where I disable all notifications and close everything but my IDE.
  • Reserving 2-3 hour blocks on my calendar to preserve focus time and ensure my meetings are grouped together.
  • Letting the team know when I need some quiet time to work on a task.
  • Every morning, writing my most important tasks for the day on a sticky note or Trello board.
  • Scheduling a “weekly review” for myself every Friday where I look back at my accomplishments and decide whether to tweak my work habits or plans for the upcoming week.

Overcoming over-collaboration

A constant stream of notifications about broken builds, pull requests, and ChatOps alerts from monitoring systems keep developers busy, but not necessarily productive.

As an engineering leader, it’s my responsibility to ensure the team culture emphasizes effective teamwork. We build trust so the default assumption is that everyone will make the right decisions and praise those who show a bias toward taking action. We make sure we have something truly valuable to add before chiming in with comments. We enforce coding standards with automated tools and favor team-approved architectural patterns to keep time spent on trivial details to a minimum.

What works varies from team to team. The important thing is to keep evolving your team culture until you find your way of making space for deep work. I love this quote from Kevin Scott, former VP of Engineering at LinkedIn and now CTO at Microsoft:

“Calling all engineering leaders: Please start spending a disproportionate amount of your management time thinking about culture as a design process.”

In the meantime, individual contributors may need to employ a few “focus hacks.”

Productivity hacks for software developers

  • Add 2-3 hour blocks of focus time to your calendar. Defend them against encroachments. As people come to understand that you’re serious about your focus time, they’ll respect it.
  • Tune down notifications further than you’re comfortable with. You can always increase the verbosity if you need to. Do you really need every build notification, or just the ones about breakages? Can you get by with daily notices of updated pages in Confluence instead of instant alerts? (You probably can.) As valuable and well-intentioned as dev tools are, the default settings tend to be highly interruptive.
  • Be extra-clear with your team about whose feedback is crucial vs. whose is nice to have. Call out specific pieces you’re unsure of, and ask teammates to focus on those. When there’s a decision to be made, use a decision-making framework like DACI to establish everyone’s role: who’s on the sidelines waiting for the outcome, who’s contributing recommendations, and who will ultimately make the call.

The value of “no”

The rewards of deep, focused work, and the craftsmanship it enables, are hard to overstate. If you don’t believe me, just type the word “craftsmanship” into Google image search. Notice how happy everyone looks? Now compare that with how you feel after a day spent checking email, debating with your teammates over the best name for a variable, or responding to comments on your internal blog post. Not to mention how much more we accomplish with focus and discipline.

Take a moment to sit with that before you move on to the next article in your feed. Think about small changes you can make today – yes, today! – to set yourself up for deep work. Strategically saying “no” to tasks or activities that don’t contribute to your goals is every bit as important as saying “yes” to those that do.

Mike Melnicki is a life-long developer and currently head of engineering for developer tools at Atlassian, where he leads engineering and helps define and execute the product strategy.

VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.