Hi, I'm Chris.

Why Hybrid Work Works

As someone who lives an hour and a half from my London office, I love working from home. I can help my teenagers out of the door in the morning, and I am present when the family comes home. I can have coffee with my wife Ellie before we start work. I prepare dinner during my lunch break, and receive deliveries. I can contribute more effort during my day to Cherrypick, free from distractions, interruptions and the long commute. I would struggle to work effectively five days a week in London.

I also love working from the office. It is an opportunity to spend real time with the people I work with. Communication is easier and I spend less time on screens. I can train less experienced colleagues much more efficiently than video chat. I can ask for and give advice and help in person, cutting down long feedback cycles. I would struggle to work effectively five days a week from home.

Much of the debate around hybrid working appears to be a zero sum argument about why working from home is “better” or “worse”, and why working in the office is “more” or “less” productive.

One is not better than the other; they are just different. I think we need both for a balanced life.

Here are some pointers for how to have a productive conversation about hybrid in your team.

The Job Is Not To Build

Startup CTOs or founding developers are the first technical people in the business. It is natural to think your job is to write code and build software. This is backwards.

Your first job is not to build software. Your role is to use your technical expertise to help the startup figure out fast if you have a valid solution to a compelling problem, and then a valid product for a big enough market.

You might do this through building software, but you might not need to.

Here is a story of how I did this wrong, and how you can do it right.

Your Code Is A Liability

Every chunk of code you commit is more for someone else to read, digest and understand.

Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.

Every line you add limits your project’s responsiveness to change.

Your code is a liability. Never forget this.