The following excerpt is taken from The Agency Owner’s Guide to Hiring Web Developers, but it’s relevant to anyone managing remote team members — particularly as we all adjust to the effects of COVID-19 on the workforce.
While the focus of the excerpt is on web developers, most of the same principles can be applied to any remote team. Flexible scheduling, effective communication, and uninterrupted sessions of deep work are all essential to maximizing our productivity at home.
Scheduling, Communication and Deep Work
WHAT AGENCY OWNERS SAY…
“My biggest challenge in finding developers is determining whether or not they are going to be good communicators. We can figure out pretty quickly if the price, timeline, and quality are a fit, but it’s more difficult to know whether they are going to communicate at the level we need in order to manage the expectations of our clients.”
“I have tried to work with developers in the past, but the biggest hurdle is just that—they are developers, and I am rooted in design and communication. There are typically language and messaging barriers, not to mention the actual design of the site.”
“I need someone who can answer questions clearly, provide progress updates, and clear e-mail communications. Someone who’s willing to jump right in and provide solutions, rather than questions or challenges.”
Most developers are not going to naturally or automatically adapt to the fast-paced agency style, so in order to get their best work, you’ll need to craft their experience to fit a schedule and structure that’s conducive to heads-down, high-quality coding.
This is jarring for a lot of agency owners because we’re so accustomed to agency life that we don’t realize how dramatically different it is from most other types of employment. Ask around and see how many of your friends and family spend half their days pitching strangers for projects worth tens of thousands of dollars, only to transition to intense creative work for a few hours, and then to respond to a dozen e-mails and phone calls to “put out fires” for clients you haven’t talked to in weeks. Most people are simply not trained for this work-style, which is often much more frantic and disjointed than any other job (including a job at a technology company that’s building a single product over the course of many months).
Being able to successfully strike this balance while still delivering high-end development is one of the reasons my business has been successful as a partner to creative agencies. Even so, as I’ve expanded my company, I’ve had to adapt to the fact that many other developers don’t share my unusual combination of background and skills – a formal background in design, advertising and journalism mixed with 20+ years of hands-on technology experience.
This is where most agency owners get stuck. They don’t realize how unusual it is to have the mix of mindset and skillset to be a great agency owner, and they fixate on the idea that everything would be better if “I could just hire another me.”
In order to successfully hire developers, you’ll need to step out of that mindset and instead focus on setting your development team up for success (while still ensuring they meet your communication and deadline goals).
First, you’ll need to step back from minute-by-minute communication and give your developer time and space to do serious, deep work. It’s almost impossible to write quality code in short bursts – unlike your schedule as an owner, a developer’s day can’t be punctuated by phone calls, urgent e-mails, and random interruptions. While you’re likely on what’s called a manager’s schedule in your daily life, you need to do everything in your power to ensure that your developer is on a maker’s schedule, which means long stretches of undisturbed time focusing on a specific goal.
“One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.
There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one-hour intervals. You can block off several hours for a single task if you need to, but by default, you change what you’re doing every hour.
When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.
Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.
When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming in the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.
For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.”
– Paul Graham in Maker’s Schedule, Manager’s Schedule
At Howard Development & Consulting, we solve this dilemma by having three people on a manager’s schedule and five people on a maker’s schedule. This means our managers are always able to quickly respond to client questions, take meetings, and produce new proposals, without slowing down the progress of our makers, who are usually focused on one or two major projects for 20 to 40 hours each week.
If you’re working with a solo developer or a smaller team, you’ll need to take on that manager role – which means getting all your normal work done while explicitly protecting the time of your makers from unnecessary interruptions.
This is where a lot of agency owners start to panic. We’re so accustomed to always-on communication, the idea of a day or two without a check-in spurs immediate anxiety.
Here are three methods we use to protect our makers’ focus and our managers’ sanity at the same time:
Asynchronous Check-ins
This approach uses software to allow you to keep an eye on what your developer is working on without needing to personally touch base. This can come in a number of different forms; here are some of the ones that have worked best for our team:
- Keeping a running checklist in your project management system, so that your team can check off items throughout the day and you’ll be able to see their progress without speaking with them directly. This works best when the checklist items require 1-4 hours of work each, rather than many days of work, so you’ll want to divide your checklists into reasonably sized chunks.
- Subscribe to notifications for the developer’s code repository (for example, on Github or Bitbucket), so you can loosely keep track of progress as the developer commits new changes throughout the day.
- Set up an end-of-day routine – for example, our project management system automatically asks everyone, “Are you blocked on anything?” at 4:30 p.m. each weekday. Everyone on the team can see that response, so if a developer is stuck on something or needs input from a client before they can proceed, we’ll know about it right away. Note, however, that this is a NOT a required end-of-day report – we’ve found that these are far too tedious and distracting, and developers end up just not doing them (and I end up bugging them to do them, which defeats the purpose). Instead, we are only asking you if something has gone wrong, which means on most days, the developer doesn’t need to respond to this prompt at all, and can simply continue in deep-work mode.
Frankly, one of the biggest challenges here is restraint on the part of the manager. It’s hard to transition from an always-on mindset to one where your job is actually to enable others to do deep work. That means never being a bottleneck (where they’re waiting on you for information or instructions), but also giving your developer space they need to do focused work for hours or days at a time.
Consistent Weekly Meetings
For longer-term projects (a month or more) where your developer will be doing 10 or more hours of work each week, I recommend setting up a 30- or 60-minute weekly meeting at the same time each week. This provides both you and your developer with a consistent target – for example, we’re always going to do a demo of this week’s progress on Tuesdays at 2 p.m.
The agenda of each meeting should include a demonstration of work completed in the past week and a planning session where you agree on the exact tasks that will be completed in the coming week. It’s OK if your developer gets a little more or less done in a given week, but they should always have a clear, prioritized list that they’ll work through as fast as possible during their week of focus time.
This is a loose application of the SCRUM methodology, which includes a handful of other weekly meetings for project planning, backlog grooming, and other more advanced techniques. I encourage you to dig deeper into SCRUM when you have time, but for our purposes, we’ve found that we can get the benefits of the system in about an hour a week – as long as that hour includes a demo by the developer, honest feedback from the client, and mutual planning for the coming week’s goals. This also translates well into the asynchronous checklist we discussed above, so you can follow along as your developer accomplishes the goals you’ve agreed upon over the course of the week, then see the full demo during your regular meeting.
Daily Stand-Ups
Some teams also find that they benefit from very short, very frequent “stand-up” meetings – meaning they’re so quick (10 to 15 minutes) that you can do the whole thing without needing to sit down. This is usually a very brief check-in with a manager and multiple developers, where everyone will share what they’re working on if they’re stuck on anything, and what their goals are for their next work session. Some teams do these every day, others a few times a week, and they can replace or supplement a weekly meeting like the one described above.
I know a lot of developers for whom this works well, but we find that this level of scheduling is disruptive for our team’s flow, particularly because we have a very strong focus on location and time flexibility. A stand-up at 9 a.m. Pacific may allow our developers in California to start the day fresh, but it breaks up the deep work of our team members in New York, who are already three hours into their day. It also puts constraints on people to be in the office at a certain time of day, which we want to avoid – you should be able to drop your kids off at school, run an errand, or get some exercise without having to play Calendar Tetris to work around your check-in meetings. Our approach is always evolving, but right now we’ve found that asynchronous project management and weekly meetings for long-term projects are our sweet spot.
“Within a semester dedicated to research, he alternates between periods where his door is open to students and colleagues, and periods where he isolates himself to focus completely and without distraction on a single research task. During these periods, which can last up to three or four days, he’ll often put an out-of-office auto-responder on his e-mail so correspondents will know not to expect a response.
‘It sometimes confuses my colleagues,’ he told me. ‘They say, “You’re not out of office, I see you in your office right now!”’ But to him, it’s important to enforce strict isolation until he completes the task at hand.
By consolidating his work into intense and uninterrupted pulses, he’s leveraging the following law of productivity:
High-Quality Work Produced = (Time Spent) x (Intensity of Focus)”
– Cal Newport in Deep Work
