Commit and figure it out

comments 4
Alex Honnold’s free solo climb of El Capitan, Yosemite National Park. Free solo means without a rope. Copyright National Geographic.

Down the rabbit hole

I’ve been on a little voyage of discovery recently. Would you like to come with me?

A few weeks ago, I watched Free Solo, which is an excellent – and nerve wracking – documentary about Alex Honnold’s incredible achievement of climbing El Capitan’s 3,000ft Freerider route in Yosemite without a rope.

However, this isn’t an article inspired by Honnold directly, despite there being a wealth of inspiration to absorb from how he dreamed, practiced and mastered this monumental climb. Instead, I was intrigued by the equally fascinating path of the filmmaker, Jimmy Chin.

As I researched the background of the film, I went further down the rabbit hole. This had us watching Meru, another of Chin’s movies, co-directed by his wife Elizabeth Chai Vasarhelyi. Going deeper still, I peeled through Chin’s adventure photography and read about his climbing.

So, with interest piqued, as a Christmas present, we bought a subscription to Masterclass, which hosts his photography course. About ten years ago I was an avid photographer, but the passion had waned over the years. I was curious to rekindle that passion.

The course was excellent. Aside from the functional camera tuition and detailed walkthroughs of his shooting and editing process, there were insights into how he ended up getting paid for shooting mountaineering expeditions.

Humble beginnings

Jimmy Chin in a promotional shoot for Masterclass. Image owned by them.

Growing up in an Chinese immigrant family in America, Chin jokingly remarked that his parents didn’t recognize any career other than a doctor, solicitor or financier. Contrary to their expectations, after he finished studying, he took a year off and lived in a van in Yosemite National Park, living frugally whilst climbing. One year became many years.

After taking some climbing photographs with a friend’s camera that he fortuitously sold to a magazine, he used that money to buy a camera of his own, becoming a journeyman adventure photographer: climbing, shooting, and learning. As the camera transformed into his main passion, he identified his adventure photography idol: Galen Rowell.

Eager to learn from the master, Chin drove across California state to show up unannounced at Rowell’s office. He didn’t come down to meet him. However, he hung around the building lobby doggedly for a week, and as a reward he got a couple of hours of time from his hero. Rowell handed him a picture of an unclimbed rock shard in the Karakoram range. His expedition photography career began.

Through Rowell, Chin got his big break when climbing legend Rick Ridgeway telephoned him. This was because David Breashears – the mountaineer and filmmaker – had dropped out of a National Geographic expedition to document the calving grounds of the Tibetan antelope across the Chang Tang Plateau in Tibet. He needed someone to fill in for David.

Chin had never filmed anything before. All of his work and practice had been in still images. He asked if they were comfortable with letting an amateur filmmaker have such a challenging role. Ridgeway’s reply was surprising considering the magnitude of the task:

“That doesn’t matter. Commit. Figure it out.”

He did.

In addition to filming the expedition, Chin got his first two-page photographic spread in National Geographic magazine. It was a frame of Galen Rowell traversing a snowy ridge. The photograph was printed as a tribute to Rowell, who tragically died in a plane crash a number of weeks later.

Sometimes life comes full circle.

Human ingenuity

There’s a lot to be said about the attitude of committing and figuring it out. It implies trust. It’s a challenge. It’s a chance to do something exciting and new. The mindset doesn’t have to be restricted to lofty challenges such as Chin’s filmmaking expedition to Tibet. There are plenty of times in your life and career, big and small, where it can be the best option. There are times where it might even be the only option.

Think about it on a smaller scale.

I work for a technology company. In our industry we are rarely ever building the same thing twice. We can attempt to plan and estimate each new project ahead of time, but in the same way that Chin hadn’t ever made a movie but knew how to use a camera, we just have to apply what we already know to each new and challenging project whilst hoping for the best, readjusting our course as we go along.

Human ingenuity transcends uncertainty. It’s what has made humans the most successful species on our planet. We just find a way.

Some more work situations: changing careers is a prime example of committing and figuring it out. Who can tell whether that new company or role is right for you? What if you only have your best guess and your gut feeling?

What about deciding whether to retrain, despite being decades into your career, feeling comfortable, financially secure, yet unfilled? Is it wise to risk it all?

What about conceding to your hatred of daily commuting unhappiness and subsequently working for yourself at home, despite not being guaranteed a steady source of income?

Commit and figure it out.

I’m not going in any more

My old school, Sutton Grammar. Photo with credit to Tony Monblat on Flickr.

I faced a commit and figure it out dilemma fairly early on in my life. It was the day that I quit one of the country’s best schools in the middle of my A Levels.

I was fortunate enough to go to Sutton Grammar, which is a wonderful school full of worryingly smart people. One notable recent student discovered an early stage test for Alzheimer’s before he was 15. Sutton was notoriously hard to get into, but I did, and it was also challenging to do well in, but I did. I achieved well in my GSCEs and continued on to the sixth form to study for my A Levels.

I picked the subjects that I was best at. A mixture of science and politics. However, as each day went by, a nagging feeling was surfacing. What did I actually want to do with my life? Was I really sure about what I wanted to study at university? What if this all wasn’t for me?

Despite being in one of the best schools around, and despite the high proportion of students that get accepted to Oxford or Cambridge, my choices were beginning to feel gravely wrong.

I felt like I was on rails and I couldn’t course correct. I was worried that I’d end up at a university I didn’t want to go to, studying something that I didn’t want to do, to end up in a career that I didn’t want, and I would be secretly unhappy ad infinitum. Despite the unhappiness, it would have been extremely foolish to quit such an advantageous situation.

But one night I did.

After being unable to sleep, again, after hours of counting buses rattling past, I looked at the clock. It was after 2AM. I’d had enough. I got out of bed, softly trod out on to the landing, and entered into my parents’ bedroom.


They stirred and my Mum turned over. “Is everything alright?”

“I’m not going in any more. I’m sorry.”

“OK. Let’s talk in the morning.”

I didn’t have a plan. But my parents trusted me. We informed the school and they were sorry to see me go.

I got a part-time retail job to tide me over. I felt liberated.

I spent my free time learning to play some musical instruments, exercising, reading, and began tinkering with programming. The tinkering turned into a passion, and I would often see the sun come up before I realized how long I’d been absorbed in it.

I applied to a college for a fresh start. I went on to study computer science at university. It was hard work, but it felt right. In 2011 I got my Ph.D. I then went to work for a local startup that’s now doing pretty well. I’m still there, because it also feels right.

Sometimes you just have to commit wholeheartedly to the alternate path, and figure it out as you go along. And if I can, so can you.

Fear and the lack of structure

Typically we worry when there is no structure, no plan, no answer. But that’s where the interesting things lie. Jigsaw puzzles can be fun, but they’ve already been worked out for you; all that remains is for you to carefully put the pieces together for an unsurprising result.

The best parts of life and work are where there really isn’t an answer; where there’s no complete picture on the back of the box to replicate. Instead, you need to get inventive. But being inventive is impossible without failing, and creating environments where everyone can regularly fail is important.

When I said to my parents I wasn’t going into school any more, they gave me a space to fail. I did, a lot. But it worked out. I’ve written before about creating environments where failure is encouraged. We owe it to ourselves to fail in work and life.

The safety net

You will often face situations as a manager or leader where you have to acknowledge uncertainty and just commit and figure it out. Being able to help others with this dilemma is even more challenging, but ultimately highly rewarding.

That’s because steering through uncertainty goes beyond working out how to deliver some particular project, or build some new whizzbang that needs shipping for your customers. It is also needed at times where you sense your staff are at an impasse with their careers and have no way out but to quit. Or, even worse, to stick it out whilst feeling deeply unhappy.

There’s often another way.

Instead, you can create opportunities for them to do something completely new within the environment that they already know well, with a safety net that you can build in case it doesn’t work out.

Here’s some ways you can help propel staff into challenging uncertainty whilst keeping them at your company and happy:

  • Create new roles from emergent behavior. We had a number of talented senior engineers who were becoming experts on particular areas, with their knowledge being required from many teams in addition to their own. Rather than allowing them to get overwhelmed by this in combination with their team’s demands, we created the Principal Engineer role and gave them more freedom and autonomy to work with the projects they find most interesting. That works well for us, and for them. And because they’re highly intrinsically motivated, they do brilliant work.
  • Encourage internal promotion as much as possible. Instead of always relying on external hires to fill roles, why not take more chances on those that are already with you, regardless of whether or not they have the exact skills? It’s a challenge and career opportunity for you as much as it is them: you have the responsibility of mentoring, guiding and coaching their way through it.
  • Encourage retraining and sidestepping. Make your company an investor in people rather than an investor in their skill sets. Allow the chance for staff to try out new roles in a safe space. Grow people holistically rather than just their technical acumen. We’ve had application support staff train to be engineers, engineers retrain as data scientists and IT staff move into QA. We’ve even had commercial staff retraining in product design.

With all of these situations you take a shot with someone, commit to it, and figure it out as you go along. There’s no guarantee that it’s going to be a success, which is why you need to install a safety net.

My favorite way of doing it is operating in a 30-60-90 day (and beyond) framework, where you both agree upon milestones to achieve as you approach those time boundaries. You can use both quantitative and qualitative measures; whatever works best for you and your staff.

This framework is used with an important “ejector seat”: if at any point either party feels that it isn’t working out, then they can go back to their old role with no fuss or bother.

That situation is not failure to perform. It was just a hypothesis that you were unable to prove. This time. Whether it works out or not, you’ve given someone a shot at acting upon their desire for change in their life, without risking everything else. That’s a big thing to do.

In summary

Helplessness is an awful feeling. The belief that one’s life is on rails and can’t change; that you want to do something entirely different but can’t take that risk emotionally or financially; the dread that you’re too far down one path to even consider another. It’s hard.

But often it’s not the only way. Human beings are remarkably clever, and when gently nudged into taxing situations with a safety net underneath, they often find ingenious ways of adapting and overcoming the difficulties.

You’re rarely as stuck as you think you are. Take a leap. Do the same for your own staff. Talk to them about their desires. They might not even know that applying for your open senior role is a possibility.

After all, if my parents were able to trust me dropping out of a fantastic school to figure out what I really wanted to do with my life, then I think we owe the same to others.

Commit and figure it out.

The joy of caretaking

comments 2
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.

Engineers who want to make a big impact at the company 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.