Notes to an Agency - Time

Hello world. Welcome to my first weblog post, which is written from the perspective of the curious, magical creature sometimes referred to as the “developer”.

There are other posts in the pipeline that will explore different aspects of working for a software development business, from the viewpoint of a developer. This particular post will be looking at the use of time in the workplace.

The impetus of this series is that a large part of a developer’s job is in continuous learning and improving. I’m interested in opening that up to the organisations within which we work, too.

You may be here because you've followed a link from my About page, at the end of the paragraph that concludes with:

...I'd rather avoid working to a schedule that demands that I work on several codebases every day as standard business practice — sporadic client emergencies notwithstanding.Me - Via "About"

I wanted to expand on that one quoted paragraph because, whilst I know every software business will sometimes need to scramble, and that’s OK, not every agency needs to exist in a constant state of scrambling.

The normalising and perpetuity of developers having to constantly fight development “fires” is what concerns me, and is something I've had negative experience with in the past.

Where to Begin

To start with, and to provide an overall picture of what can occur, here’s two anonymised examples of agencies I’ve had experience with that sit at the polar extremes of project scheduling approaches:

• Agency A, where you'd work on one main project from start to finish in a continuous block of time. Sometimes the need to move to a different client's codebase arose, but this was rare, and always temporary. Once you'd finished with the “emergency”, you'd be back to your main project:

• Agency Z, where day-in, day-out, you’d have to jump into multiple projects/codebases throughout each day:

Agency A provides close to an ideal scheduling situation — working a single project as standard drastically simplifies development when you’re simply asked to show up, plug in, and get building on a single codebase. The ideal skedge sitch (a term I promise to never use again) being no permanent interruptions from your active project until your active project is finished, and long runs of time each day/week within which to complete your work.

For Agency Z, the mental overhead of having to off-load and in-load different codebases, client needs, build tools and pipelines, differing technologies, and other context switching elements in a short amount of time, multiple times a day, is mentally exhausting. If this time management approach is sustained, exhaustion will accumulate until the developer arrives at chronic exhaustion, otherwise known as burnout.

The Mayo Clinic lists the symptoms of job burnout as:

• Excessive stress
• Fatigue
• Insomnia
• Sadness, anger or irritability
• Alcohol or substance misuse
• Heart disease
• High blood pressure
• Type 2 diabetes
• Vulnerability to illnesses

The consequences of burnout can be dramatic, sometimes debilitating, for a person, and if a dysfunctional agency persists with the same burnout-causing methodologies, this can result in staff turnover.

Once staff start to leave, this may compound to create a climate where no one can find the time to do anything pro-active or assertive because everyone ends up hampered and side-lined by the emergency of the moment.

Lead devs are tasked with onboarding new hires. New hires are busy getting up to speed. Decisions are not given enough time because everyone is spread too thin. Quality is lost. Best practice is corner-cut. Tech debt starts to creep in. Job satisfaction tanks. Morale plummets.

Unfortunately, this is an all too accurate representation of what happened at the real-life Agency Z — it bled all of its development staff away to the very last person because it insisted on keeping the same strategies in place that were stripping it’s staff of morale. Precisely everyone in the design and development team, front-end and back, as well as a couple of managers, left the company. It wasn't sustainable, and the agency didn’t react.

Certainly, the quality of the surrounding organisation, codebase consistency, project structure, management styles, and many other factors therein may contribute to a more manageable working situation. If this might be the case with your agency, I would expect that a portion of the problems with these reactionary practices are somewhat buffered, as other aspects may help ease these strains.

Even with all other lengths being taken, no other characteristic within an agency is as important as how it’s staff are scheduled, because time management scaffolds the day into blocks within which work is possible.

The word “possible” here is important, and when I wrote it I was directly thinking about distraction in the workplace being the counterpoint to what is possible. To keep this post lean I’ll tackle the subject of distraction in a separate post, but for a TL;DR of how developer distraction can affect a developer’s output, here’s a scary quote for you:

One workplace study found an average of almost 87 interruptions per day (an average of 22 external interruptions and 65 triggered by the person himself)...but 18% percent of the time the interrupted task isn’t revisited that day.Harvard Business Review, via Help your employees find flow

Without getting too distracted by the subject of distractions, what else can time management affect?

Entering the Flow Zone

If developer productivity and code quality are to be of a high standard (and when are they not, dear reader?), the agency should strive to promote deep work via cognitive flow, colloquially known as being “in the zone” — which allows an individual to engage with tasks to their full capacity — by removing all possible cognitive roadblocks, mental overheads, stress, and distraction from the workplace.

In the agency schedule charts above, each block represents a period of possible work. Between each block is where context switching happens — imagine that each block requires a “warming up” period in order for the developer to enter into a flow state. Entering flow will usually begin to happen after the developer understands what goals need to be achieved, how the codebase functions, and which part/s of it need to be modified in order to fulfill the goals specified.

Once the developer gains enough understanding of these hurdles, and everything else being well, they begin the work and start to enter into a flow state. Work can happen outside of a flow state, but progress is generally quicker, of higher quality, and more satisfying for the developer to complete if it happens within. Flow state is where you want your developers to be.

The duration of the context switching period can take various amounts of time depending on several elements, including a developer’s:

• Cognitive capacity: generally lowers as mental energy is spent, and as each work day progresses. This can vary depending on how difficult a dev’s tasks have been in relation to their skill level, and how much focus they’ve had to employ to overcome distraction. Context switching involves storing a range of new bits of information in order to tackle the next task, which increases mental fatigue and lowers cognitive capacity.
• Level of codebase familiarity: an individual’s familiarity with a codebase will increase the longer they have worked on it in its current state, along with exposure to the agency’s coding practices/style, and the individual’s level of programming skill/knowledge. The work schedule directly dictates the duration of this exposure. It’s worth it to note that no two codebases are ever the same, and each generally comes with it’s own selection of gotchas and difficulties to discover.
• Frequency of workplace distractions: the most obvious time-based workplace distraction is that of the meeting. A meeting will directly pull a developer away from their desk, and their work. A meeting that’s fast-approaching can weigh on a developer. Discussions of meetings can often bleed back out into the office space. A meeting is just one example of a distraction based upon scheduling — agile standups, task blockers, 1-on-1’s, reviews, agency celebrations, interactions with other colleagues who have their own schedules — whilst none of these are inherently negative or devised to throw spanners in the works, if they happen at an inopportune time they have the potential to be a distraction for developers.

All Right! What’s the Take Away?

If any of these issues have surfaced in your agency, fear not. All is not lost. However, you may want to consider making some changes in order to avoid some of these issues mounting up into substantial problems.

Oftentimes, lifes’ complications can be dealt with via simple communication. That’s where this journey should start. Talk to your developers, take notes, then take action. Each developer may have different preferences that you can steer your agency towards. Get a sense of when in a day they might be more productive, and in what kind of environment they do their best work.

For instance, if I’m programming, I:

• like working on projects in their entirety, with no detours to other projects unless it’s for the short-term (E.G. for a client emergency, or helping out a colleague, etc)
• am partial to a relaxed but work-focussed environment that isn’t library-silent, but isn’t so noisy that I have to live with my headphones on
• usually do my best work in the hours between 10am and 1pm
• prefer to manage my own time and tickets
• sometimes favour working from my home office when I need minimum distractions

A Flexible Work/Life Balance

Consider offering flexible working hours. Your agency can offer core hours that your staff have to be present for (their 8 hours per day have to include times between 10am to 3pm, say, but the rest can be flexible either side of that period). An hour, or a few hours, of flexible starting time can contribute to staff being less stressed by providing them with more options to tweak their ideal work/life balance.

If they need to go home early once in a while, have a system that allows for this, with the agreement that they make the hours up at some point that month.

For part of the 2020 Stack Overflow survey, respondents were asked to pick their top three most important points for picking one agency over another. The top five results included “Office environment or company culture” (44.5%), “Flex time or a flexible schedule” (43.9%), and “Remote work options” (33.3%). In the “Job Hunt Factors” section, 48.3% of respondents noted “Better work/life balance” to be important to them when looking for a new job.

Workload

Try not to load your developers with too many difficult tasks in succession. Pace tickets so that one difficult task, followed by some lighter tasks, can help balance out cognitive expenditure and keep your developer/s from exhaustion. Better yet, think about working agile, and allow your developers to set their own tickets per sprint, and let them tackle their tickets in the order they see fit.

Utilise your developers’ preferences to plan meetings, office events, and client emergency responses accordingly, and allow your devs to use the longest possible stretches of time per day for active work.

Distraction

Think about how notifications from communications and management software can disrupt the flow of a developer, and avoid the expectation that sending them a message requires an immediate reply. I often turn off my notifications, or the apps themselves, in order to be able to concentrate on tasks that require that little bit extra.

When working in the office, placing your developers in an area of your building away from staff that don’t require extended periods of concentration may be a difference maker. Offer remote working where possible, to ensure that a developer spends time working in an environment of their choosing, often tailor-made to their own ideals.

It may help to train your surrounding agency about interruptions, music, chatter, online messaging and other elements that might develop into a cognitive burden. This extends to helping managers understand how to respect flow, and introduce methods to deal with this; perhaps a code where, if a developer is wearing headphones or they’re using a “do not disturb” mode, they should be left alone for everything but the most hair-on-fire emergencies.

Onboarding

Have a solid onboarding process in place so that everyone coming into the agency will be trained for integration within it. Every agency is different, sometimes in unexpected ways. To smooth this out, you can use onboarding to:

• set new developer expectations
• introduce new developers to your company values, goals, current clients
• set up payroll and contracts
• meet colleagues, their mentor/buddy, line manager, and lead
• introduce agency-specific processes and workflows
• help new hires into actively writing intermediate-level code in your agency style and tech stack
• evaluate both your onboarding process and your new hire at the conclusion of their onboarding

One nice thing to have all ready for new hires is a workspace, along with a workstation set up and ready to go. Let them choose their own editor and terminal/git client, too. These things matter to developers, and can help new staff find familiarity in a new environment.

Getting new hires up to speed is par for the course, and having a streamlined onboarding process saves significant time whilst reducing disruption to the wider agency.

In Closing

An agency is a construct built from the people within it. Know the strengths of the people you hire, and make efforts to clear the way for them to thrive. Empower your staff by aligning your agency’s practices to them, rather than by forcing them to work in an environment that works for you. The two instances may not be all that similar.

A happy developer is a productive developer, who is motivated to finish projects and who wants to learn, improve, and help push the business forwards. They will contribute to more efficient, more consistent workflows, and will help support a healthier agency culture.

If well supported, your developers will go the extra mile to bring your agency better returns on your client contracts, whose high-quality work will attract stronger clients and better projects.

Taking the time to sort out issues you may have in your agency will inevitably improve your bottom line, along with the retainability of staff within your company.