The joy of caretaking

Leave a comment
Photo by Verne Ho on Unsplash.

The jar of life

There have been umpteen articles written on the “jar of life”.

The story is attributed to a mythical philosophy professor, giving a life lesson to his students. Now, this isn’t going to be another one of those articles, so don’t worry. But for those unfamiliar with the concept, here’s a quick summary.

Your life is a jar (of course!). You fill it with golf balls, which represent the big important things, and it looks full.

Except it isn’t, because you can pour a whole load of pebbles in too, which take up the space around the golf balls. Now it looks full.

Except it isn’t yet, since you can then pour in a whole load of sand which fills the remaining space. Then – and you can see where this is going – it looks full again, but then you can pour liquid in there to make it legitimately full.

Aside from producing a jar full of wet objects that will be a pain to separate and clean, it follows that if you put them in the jar starting with the smallest first, then they wouldn’t have been able to fit.

Instead you need to put them in biggest first, so that the smaller things can fill the gaps. The metaphor is that you should focus on the big, critical facets of your life first, then the less critical things will naturally fill the gaps around them.

Right, pop-philosophy lesson over. Onward…

Reusing the idea

I had a conversation with a colleague at work that reused this metaphor in a way which I quite liked.

Let’s go back to the full jar. There are objects in there of all sizes.

Except this time it’s not your life, it’s your Engineering department (of course!) and the objects are the projects going on (right…) and their size denotes their importance to the rest of the company.

For example, mapping those objects to types of project:

  • Golf balls: These are big ticket features and new products. They encompass anything that is going to have a significant marketing splash, or a new revenue stream, or both. They are the projects that your commercial staff and clients are hounding you about. They are the publicly visible deadlines.
  • Pebbles: These are bugs, speed improvements, workflow tweaks and UX refinements. They encompass anything that gets a reaction of “nice” rather than “wow”. Yet, cumulatively they are impactful.
  • Sand: This is everything that doesn’t concern the rest of the company. Developer tooling, deployment processes, infrastructure automation, “keeping the lights on”, and so on. Essential work, but mostly invisible, unless it breaks and causes bigger issues.

Reapply the metaphor and it still makes sense. You need to get all of these things done, all of the time. The big ticket items need fitting in first, but you can’t be successful without accounting for everything else.

However, I don’t want to use this article to convince you that you need to account for all of these things; I should hope that as a diligent engineering manager or developer you are managing to juggle the differently sized objects in order to deliver a good level of service to your users and the rest of the business.

Instead, I’d like to challenge the preconception that the best engineers are only drawn towards the golf balls. There are plenty of engineers that thrive, grow and enjoy their work even more when the correct space is created for the pebbles and sand involved in running a technology platform.

The curse of the high ticket features

Sometimes, high ticket features and products, it seems, are the only thing that the company cares about. You might have the fastest storage, the best uptime, no major incidents in months, but it doesn’t really matter; the company only cares about the next big thing and guess what? They want it yesterday.

Naturally, your most talented, career-focused engineers will be drawn to these projects because of the importance that the company puts on them.

If they want to continually make a case for more responsibility in their roles, more interesting work, and faster track towards promotion, then they’ll be clambering to get on next important high ticket project.

But, these projects can often become the breeding ground of the worst cultural aspects of our industry:

  • Tight and arbitrary deadlines, often dictated by a noisy client or market pressure, creating stress, crunch and compromise.
  • The highest value projects often attract the highest-paid stakeholders, thus creating an occasionally uncomfortable high stakes environment to complete the work in.
  • Sometimes the big ticket item itself isn’t the most important thing: it may be the marketing message that goes along with it, the shift in company positioning, or the proverbial middle finger that is raised to a competitor. The usefulness of the feature can suffer as a result of timeliness, leaving people unsatisfied with what they’ve achieved.

The key issue here is that the work that is perceived externally to be most valuable is often the work with the highest stress attached to it. Your best engineers could be exposed to higher risk of burning out or getting fed up and leaving.

Is there another way for them to be happy, grow and progress?

Pebbles and sand

Your challenge is to make sure that – at least within your Engineering department – that the pebbles and sand projects are also perceived to be extremely valuable and career defining, even if the communication of that perception only reaches the boundaries of your department.

After all, the invisible parts of your infrastructure are the ones that make the highly visible ones really shine. They’re the parts that when they’re working, nobody cares, but when they’re not working, they’re the only part that the company is begging you to fix.

The challenge is to nurture the joy of caretaking in your platform. Caretakers traditionally look after existing buildings. They are invisible, but they make sure that the building is tidy, running efficiently, that broken parts are replaced and upgraded, that the electricity and water are flowing, that any problems are swept up and taken care of. That’s exactly what you want your caretaker engineers doing in your platform.

In fact, I’ll take that further: you should fully embrace, praise and reward caretaker roles, caretaker projects and even caretaker teams, and you should do so just as generously as those shipping the latest and greatest whizzbangs that get announced on stage to rapturous applause and whooping.

Caretaker engineers keep the wheels turning. They are absolutely essential.

Elevating caretakers

If you want your department to be successful, you need to identify the need, and elevate the collective worth, of caretakers.

This fundamentally comes down to some simple steps that you need to consider:

  • Changing the perception of caretaking work. This is both the internal perception that motivates staff to work on these work streams, and the external perception that – just because it isn’t the latest high ticket feature – it isn’t as valuable to be well resourced.
  • Prioritizing and measuring. Given that your Product teams will be less involved in defining exactly what this work is, how can you do so? You need to work out how to capture requirements, set goals and measure success.
  • Ensuring that success is celebrated. Given that high ticket features often get a marketing splash, you need to ensure that your caretaking streams have something to celebrate at regular intervals.

Let’s look at these in turn.

Changing the perception of caretaking

There have been times in my career where I have been worried about having to staff a seemingly unexciting project, making an incorrect assumption that it will be met with resistance when I raise it with my teams.

It turns out that there are a number of benefits to caretaking projects. Framed correctly, the work can actually be very rewarding:

  • Less pressure from commercial deadlines. This alone can be extremely attractive to your engineers. In the same way that the janitor sweeps the halls after hours in relative silence, the increased distance from commercial staff in caretaking work can mean it can unfold in its own time.
  • Less interruptions and pivots. Typically caretaking work is more clearly defined than product work. Your infrastructure may need upgrading. You may have a giant backlog of bugs to work through. Less glitzy, yes, but also more of a chance for uninterrupted flow within deep work.
  • Increased self-directedness in solving problems. Caretaking projects by their nature are inherently technical, so those closest to the problem – the engineers working on it – can work out the best way to do it for themselves. Autonomy is happiness.
  • A chance for mastery. Autonomy and deep work breed mastery. A seemingly unexciting caretaking project could create specialists in particular areas of your stack. That works well out for both your engineers and yourself.

So, if you have a project to update the major version of HBase, don’t assume that your engineers will run away screaming. You may find that it is a welcome break from the rollercoaster of high ticket work, and a chance to build expertise and specialism.

Just pitch it right.

Prioritizing and measuring

Since caretaking projects are lead by engineers, you’ll need to think about how to measure them to see progress. There’s no definitive answer here, but there are some scenarios:

  • Boolean: get it done. Ah, simple! If you did need to upgrade the major version of HBase, you’ll know it’s done when you’ve done it. Easily measured.
  • Hit a number. Let’s say you’ve amassed 300 bugs by neglecting the platform during a period of crunch (been there, done that). 50 of them are high priority and a killer 10 are critical. You can set achievement checkpoints as you clear the critical ones, then the high ones, and so on. Define the state that you want that area of the system to get in, then work towards it. Reassess whether it should continue when you get there. Measurably hack away at that long tail in checkpoint intervals.
  • Reduce variance. Maybe your uptime has been suffering recently. Creating a caretaking project to address the root causes could continue until stability has been reached in the measurement over a period of time, say +/- 0.05% over three months.

Although these suggestions are pretty basic, it’s important to set success criteria, both so you can know when to stop working on them and also so that you can celebrate when you achieve them.

Ensuring that success is celebrated

Since high ticket features often get a marketing launch to shout about their completion, you need to ensure that you create a similar culture within your department for your caretaking projects.

When those projects reach milestones, shout about it. Let everyone know what has been achieved and by whom, and how important that is to your users, platform and engineers. Maybe do a technical talk or broadcast the achievement via email. Elevate the success of the engineers.

300 bugs cleared? Fantastic. The system is more stable than ever? Brilliant. Technical debt has been greatly reduced in the primary storage system? Great. That’s a big achievement.

The joy of caretaking

There’s a pleasure to be had in looking after the less glamorous parts of your application. It is meaningful work, and it can be extremely rewarding. It’s a chance for self-directed engineers to plot their course and succeed on their own terms.

If you are a smaller company, then you may feel it is too difficult to make your case for moving staff away from the frenetic high ticket items towards longer plays on your architecture, tooling and engineer efficiency. However, every time we’ve done so, we’ve wondered how we got by without it.

Here’s some things that we did:

  • Attacking an extremely large bugs backlog with a whole team. A rapid period of growth left a lot of things on the floor. Deciding to put a whole team on it was a bold move, but it dramatically improved the quality of the application, and with time, the team progressed to work on many smaller enhancements for our users. The engineers that were on this team now have an incredible breadth of knowledge about our platform, and it was a fantastic place for graduate developers to land.
  • Committing permanent staff towards engineering efficiency. This small team has built tooling that automates our workflows for deploying containers on to our cloud environment, including a GUI to check builds and do one-click deploys. Our other teams are deploying code faster and more regularly as a result. We’ve also created some Kubernetes domain experts on the side.
  • Committing to reusing components for consistent look and feel. Our pattern library, Axiom, grew out of one team that built our most recent product – Audiences – but subsequent time was devoted to making those new components reusable across our other products. Axiom has since graduated to a permanent project that is staffed to help other teams reuse and expand the pattern library.

So what’s the take-home message? Never assume that the pebbles and sand are boring to engineers.

They’re a learning opportunity that benefits the skills of your staff and your departmental output; they are work that unfolds at a more controlled pace; they are an opportunity for autonomy and mastery, and they can create domain experts.

Sweeping the halls isn’t as bad after all.

Towards remote working

comments 4
Photo by Ali Yahya on Unsplash´╗┐

Stages of remoteness

In the last article I wrote about how flexibility in the time and location of work is the greatest perk that you can give your staff. It costs pretty much nothing to the company, yet the life benefits are numerous.

Naturally, flexibility should be given within bounds that work for both yourself and your staff.

Senior, self-directed staff can probably work entirely to their own schedule and location, whereas less experienced staff require more planning to ensure that they are getting the mentorship and guidance that they need in the form in which they prefer (e.g. in-person pair programming versus remote screen sharing).

Conversations about flexible working, which incorporates frequent working from home, can lead into conversations about permanent remote working. This is a natural progression, but it is one that starts to bring into question the company’s work culture and processes. It’s not as easy to change an on-site company into a more remote friendly company as you may think.

To begin with, the term remote working can mean different things to different people, so I’ve attempted to define different stages that a company can exist in with regards to the location of their employees:

  1. On-site only. This is a traditional company where all of the work is done on-site, requiring employees to be in the building within their contracted hours. People get in and go home at about the same time. There may be staff taking occasional days to work from home, but it is not seen as a regular occurrence; typically it is for a special reason such as a medical appointment or a parents afternoon at school.
  2. Flexible working. This is an evolution of on-site working where both the beginning and end of the day are more loosely defined, perhaps with a reduced set of core hours specified. Employees may regularly work from home on their terms as part of their standard working week, but are still culturally attached to their physical office hub, and are expected to be there for a reasonable amount of time during the week.
  3. Remote friendly. This stage means that the company is willing to have staff that work completely remotely. Those staff could be anywhere in the world. The company has the culture and tools in place so that remote staff feel as part of the team as possible. However, most staff still are physically present in the offices a majority of the time.
  4. Remote only. The company has no physical offices, aside from perhaps some co-working spaces in cities that contain a lot of its staff. Culture, process and tools require digital communication over physical communication.

It is common for a company to progress from stage 1 through to stage 3 as they grow, often fueled by difficulty hiring talented staff solely in the cities in which they have offices. It can also occur when highly valued staff change location for personal reasons, forcing the company to progress their ways of working.

However – and I would love to be proved wrong – I have heard very little of established companies of a reasonable size progressing fully to the fourth stage. Being a remote only company is a serious whole-company cultural decision; one that involves closing offices and potentially alienating many people who enjoy being physically present with their colleagues.

What do the people want?

Here’s a poll from the Product Hunt CEO, Ryan Hoover.

Recently, a number of people have read the excellent It Doesn’t Have To Be Crazy At Work, which describes conditions at Basecamp, a company creating eponymous project management software. Basecamp is a remote only company; albeit with one “library” office for focus. Most employees work from home or from co-working spaces.

You may find that your staff will point to this as to where your company should be going. They will say it is the future. Perhaps it is, but building the cultural scaffolding for being remote only takes a lot of time, and perhaps may not even happen. It’s also worth remembering that not everyone will want it to happen.

Numerous articles and threads exist on the darker side of remote only working:

Remote working is not for everybody. It takes a particular type of person to thrive in an environment where they never see their colleagues physically.  

I believe that working along points 1 to 3 on the scale above towards being remote friendly is a much better path to take for existing companies.

Towards remote friendly working

Moving along the path from being an on-site only company to remote friendly means facing numerous technological and cultural issues. However, I believe that facing these issues head on benefit everyone, and strengthen a company growing globally.

As an example, I’ve compiled a list of some of them. It is by no means extensive, but it should hopefully highlight some of those issues:

  • The company must ensure that information is broadcast regularly and in an archival way, such as email, so that nobody misses out on important updates because of their location.
  • The company needs to ensure that product development can happen anywhere in the world and is not tied to office networking or firewalls, and that anyone can get up and running easily. This requires good documentation, automation, and most importantly, people available to help round the clock.
  • Good text chat and video call systems need to be the norm and staff must practice being inclusive to remote participants both in meetings and in informal discussions.
  • Culturally the company must embrace trust of its employees despite decreasing visibility of those staff, creating better ways of measuring progress than bottoms-on-seats for a set number of hours a day in the office.
  • By incorporating people on different timezones, companies automatically face the challenges of working around flexitime individuals. When are the windows in the day in which teams can collaborate in real time? Do expectations need to be changed as to the responsiveness of staff via DM and email? Is it acceptable that decisions take longer?

Advice to existing on-site companies

My advice would be to work towards being remote friendly. Even if only 1% of staff end up being remote, there are plentiful benefits for everyone by being able to support remote staff: better communication processes, a demonstrable move towards flexible working, more reliable development environments, slower and more considered decisions, and so on.

If your company is reluctant to change, then the previous article outlined a way of running a trial of flexible working within a team that could demonstrate that it can contribute greatly to employee productivity and happiness.

I’d love to hear how it goes.

Flexibility is the greatest perk

comments 2
Photo by Avi Richards on Unsplash.

Where we are

Given that technology talent is in significant demand, and given that salaries can only go so high before they fail to become a meaningful differentiator, companies need to find new ways to attract and retain staff.

As a manager of engineers, aside from making sure that I am paying market rate, I’ve found that the most impactful workplace perk that I can give staff is flexibility over the time and location of their work.

Typically this means:

  • The ability for my staff to work from home (or elsewhere) when they need, either for productivity reasons or for any other life reason.
  • No strict start and end of the day, since we’re not a factory.

This perk costs you pretty much nothing, but the effect on employee happiness can be something quite special.

It can give someone the ability to do all of their children’s school runs. It can save thousands on peak time public transport costs. It can allow someone to care better for a dependent in need. It can take the pressure off of a partner working full-time with no flexibility of their own. It can allow someone to visit their family for two weeks whilst also getting their work done remotely and not using any vacation time.

Doubling your salary will not allow you to buy these freedoms.

We’ve come a long way from free Coke

Ten years ago, a Google-esque perks list that included foosball, free snacks and drinks and a quirky office on top of interesting work will have been unique enough to attract staff away from duller corporate environments.

However, I would argue that these benefits have become a hygiene factor for most technology companies. My cynical side could point out that companies that try to make their office “cool”, whilst still being in the cultural and technological dark ages, have a lot to fix before worrying about where to optimally place their Kegerator.

A positive shift happening in our industry is a move towards increased trust and flexibility in the full-time contract between the employer and the employee.

In my experience, senior staff couldn’t give a damn about how good your table tennis table is. They want to do meaningful work, for a decent wage, but most importantly, they want to be trusted, autonomous, and be able to manage their time like an adult.

This means working from home when they feel that it makes them more productive, leaving early each day so that they can do the school run, and having a flexible vacation policy so that they don’t have to sacrifice time off this year so they can carry over enough days into the following year to go and see their family for a meaningful amount of time in another continent.

I am a fervent supporter of this flexibility for all of my employees. It makes a vast difference, especially with the cost and unreliability of transport.

Age as a catalyst of change

In the early stages of my career, most of my time and energy was channeled into my work and self-development. I worked obsessively hard on my Ph.D. and in my first few years of work. I certainly do not regret this. There is a time and a place for blinkered laser-focus, but it is certainly not all of the time.

The most important thing in life to my current self isn’t my job. (Sorry folks.) It’s everything else as well. It’s my family, dog, friends, mental and physical health, my hobbies, and also my job. I want to bring my best state of mind to all of those aspects of my brief existence without one being detrimental to the other.

If my job is leaving me so tired and time poor that I don’t want to cook and enjoy a nice meal as a family, or it makes me unable to read or watch a movie without falling asleep, nor leaves me with the creative energy to engage in my hobbies, then what’s the point of doing it in the first place? I could easily get a different job. Work should support and enable lives, rather than claim them.

Given that we don’t need to clock in and clock out of a building to operate machinery to build software, I want the flexibility to be able to manage my time as appropriate, work from my nice desk at home to birdsong when it is most beneficial for my productivity and my home life, and generally feel like an autonomous, trusted adult. If you give me that, interesting work and a decent salary, I’ll give you my best.

I’ve managed to arrive at this position over the years, but I appreciate that not everybody else in the technology world has, for a variety of reasons. Sometimes workplaces simply do not allow it and require bums to be on seats between 8:30 AM and 5:30 PM regardless of the tendency of employees to converge towards sinecure to pad the time, or sometimes there are hurdles of internal, anxious social workplace pressure to conform.

“I must be in the office early! What will they think of me if I am not?”

But why not?

If you are a manager and your workplace does not offer this kind of flexibility, then do not immediately lose hope. You could make it happen. You can look to pitch it to your own manager as an experiment. You could light the fire that begins to spread.

It obviously helps if you and your team are already performing well in the first place, but I have the feeling that if you’re actively researching how to introduce more flexibility, then you’re a few steps ahead of most managers out there.

So, assuming that your team performs well, and assuming that offering more flexibility is something that both you and your staff will benefit from, pitch the following to your own manager:

  • That you are going to allow more flexibility in working hours and office presence from this point onwards. You may want to define this more formally, or just let it unfold naturally. If your team isn’t used to this, then I’d recommend starting with perhaps 1 or 2 days maximum working from home a week, and defining some core office hours, such as 10 AM to 3 PM for those physically present in the office.
  • That you will run flexible working as a trial for a fixed period of time. 90 days is a good timeframe to start with, as that can coincide with a decent amount of work being done that you can collectively measure.
  • That, as a reminder, you are ultimately responsible for your team’s performance. You will grant and revoke more or less flexibility if it is or isn’t working out for individuals on your terms, based on the productivity and team harmony that you see, rather than what outside observers may think.
  • That it will be done privately and without wider announcement. In order to cause as little disruption – and potentially jealousy – in other areas of the company, the trial will be done in stealth and not publicized. After all, if increased flexibility is beneficial to employee happiness and productivity, then the quality of work and interactions with the team should remain at least as good as it was before.
  • That you’ll all report back after the trial. Collect the opinions of the team and of those that regularly work with them. Did any aspect of the team’s work suffer as a result of this increased flexibility, or did morale and productivity improve? Did those that interact frequently with the team find them harder to get hold of, or did it not matter?

If the trial goes well, you can probably extend it indefinitely. If your manager is supportive, you could use it as a vehicle to start the conversation with the wider company about flexible working, which could bring meaningful change for everybody.

Flexible working will prevent your staff from leaving. Get them off of the rails. You won’t regret it.