Each quarter goes faster than the last

An obvious statement, but one often forgotten early on in the year: every quarter feels like it goes faster than the last.

The start of the year starts slow. People have a break over Christmas and the new year, and new projects are yet to start. In some cases performance review cycles further take minds off “real” work. It can take a month or two for new projects to get properly under way, and for people to get in the swing of things.

Time starts to move faster once projects are at full pace, and after a bit of a slog you find yourself in Q2. Often less holiday is taken over the first two quarters of the year too, helping to make them feel longer.

Now we reach July. It’s the start of a new half, but things often don’t reset as much as at the start of the year. Early on in Q3 summer holidays begin. When everybody is back, in-progress projects get back into swing. They most likely need to ship by the end of the year, and deadlines become tighter. Being more heads down, the time starts to run away with you.

That leads us on to Q4. Q4 is the fastest and most hectic of them all. In October people start to think they haven’t done enough in the year yet, or worse start to realise what they have planned can’t be finished on time. Things get frantic, and the time flies by. Before you know it code freezes arrive, the first being Thanksgiving if in an American company. Then the Christmas parties begin, and lots of people take a break over Christmas itself. The year is over before you know it.

So what, isn’t this obvious? Maybe it is, but it’s easily forgotten when planning at earlier stages of the year. If a project is particularly complicated and will make the largest leaps forward only when everyone is at work at the same time, try to avoid the summer months. If a project is likely to have a risky rollout, avoid the end of the year when code freezes hit. If you have some cleanup to do, remember there’s often a quieter time at the start of January.

And repeat.

Scratching the startup itch

Earlier in my career I attempted to try as many of the employment options in tech as possible – being an employee in a startup, founding a startup, contracting/freelancing, and working in big tech. It was 2015-17 when I had a go at starting a startup with a friend. It didn’t take off, but I don’t regret trying – I scratched the itch and learned a lot.

Over the past year, through the period of tech layoffs, I’ve had more conversations with friends who are interested in startups than I’d had in the preceding 5 years. While I can’t necessarily say I know how to build a successful startup, I do know what I wouldn’t do the next time in the early stages. Given all my recent conversations, it seems like a good time to put them in writing.

Motivation

Building a startup requires a lot of motivation and energy. Aside from enjoying working with your co-founder/team  (the most important thing), the product you’re building needs to keep you engaged.

The best way to validate startup ideas is often to build them as side projects first. The most obvious reason behind this, often spoken about, is that it allows you to see if anyone wants to use it before going too far. Just as important though is that it helps you see what you’re motivated by. If you’re spending a large amount of your spare time building something, and constantly feeling like you don’t have enough time, that’s a good sign. If you’re lucky to get one to a point it’s getting so much use you just don’t physically have enough time to keep up, that’s a good time to jump in full time.

If you’re struggling to get your side project built, it’s worth thinking about if you’d really want to be spending all of your time trying to build it – maybe it’s just not interesting or fun enough? From my side, I’ve never had much of a problem motivating myself to work, so I actually didn’t feel a massive difference here between startups and bigger companies. I did enjoy the freedom to try out new ideas or technology without having to worry about how others would see it though when in the startup world.

Aim for regular use

Especially for first-time founders, I think the best startup ideas are those which users will use regularly over a long period of time. Ideally they’re something you’ll use yourself regularly too.

When I was working on a startup we were building a better way of searching for apartments – you could filter by your commute time, see travel times to your favourite locations right on the listing without having to jump to maps, and book viewings directly through the site. Unfortunately, at least for rentals, these kinds of services have very high retention for short bursts of time, and then people move apartments and you don’t see them again for a year or more. As a founder, you’re also not moving apartments regularly. This makes it hard to see if you’re improving things for particular users over time.

If you have a product where people come back once a month over a very long period of time, that’s something you can work with. You could run A/B tests for improvements and see if you could make the product useful enough they want to use it every week instead, and then maybe every few days. If the product has a natural ending, this is very hard.

Another trap I fell into here was trying to build a marketplace. Property websites need both the apartments (landlords), and the tenants. Marketplaces are sticky when they work, but can be hard to get off the ground – usually you need to build up the supply side before there is any demand, which can be a tough sell. For a first-time founder this can be particularly difficult.

The startup idea often isn’t the most important thing – things like the team and timings play a big role. Some ideas can definitely make your life much more difficult though, especially as a first-time founder.

Tech choices

Tech choices rarely change whether a startup is successful, but I think it’s worth picking languages or frameworks you know well, you are fast at building with, and you know will be stable.

The startups who succeed are often the ones who build new features the fastest. If your tech stack allows you to do this, either by design or just because you know it well, that’s a big advantage – even if it’s not the latest-and-greatest. Some of the biggest websites were built with PHP, after all. You want to be improving what users see and use, and not fighting with something being unstable behind the scenes. Boring is probably good in that sense.

I used Node.js, React, and AWS when building our website. These are battle-tested technologies, so we had no problems there. I also enjoyed the freedom to be able to learn new things like this. In big tech we tend to stay more specialised, for better or for worse, as I have done with iOS.

An exception to this rule is if the technology is the startup itself, but that’s the less common case.

Being in control

This one is less a lesson, and more an observation. Being in control of your own destiny is one of the biggest pulls of being a founder. There are tradeoffs with all different kinds of jobs though. It’s not as clear cut as it first may seem.

As an employee you’re likely to have much more control over your time than as a founder. If you’re a founder and something goes wrong, technical or otherwise, you’re probably going to have to fix it whatever the time. As an employee in a larger company that’s less likely to be the case. In effect, you’re always oncall as a founder.

As an employee you have one manager, and maybe some reports. As a founder you are more likely answerable to a board, investors, and all of the employees under you questioning your decisions. That’s ignoring your users too! In many ways that’s even more people to please. On the other hand, you can make decisions that you wouldn’t be able to make as an employee.

Financially there are obvious tradeoffs too. As an employee you can depend on a salary. As a founder you might feel less control here – you’ll be the one forgoing pay when times get tough. The reward can be much higher if your startup is a success though.

Often I see these tradeoffs as similar to owning vs renting a house. If something goes wrong in your house, whether you own or rent, you still have to live with the problem before it’s fixed, arrange for somebody to come and fix it, and be in when they come. If you own you have to pay, but you also get the choice of who fixes it. If you rent, somebody else will decide how it’s fixed, but you don’t have to pay. There’s no right or wrong here. Which is best is different for everyone. For me both are good in different ways – I sometimes get tired of one and probably need to switch to the other to keep it interesting (until something sticks!)

In summary

Being a startup founder is hard, and definitely isn’t for everyone. You do learn a lot though, and you won’t necessarily know if it’s for you until you try. That is unless you’re somebody who really can’t work for somebody else! In either case, I found it worthwhile trying. Start with side projects, and see where that takes you.

Split oncalls by platform, not project

In a product team that is shipping a product across many platforms, oncalls should be split by platform, and not just be a single rotation.

Oncall rotations are important – they both mean there’s always someone around to fix problems as they happen, and also usually keep things fair by ensuring each person is oncall for an equal amount of time.

When a new team ships their new product, and sets up the oncall, there’s often a tendency to try and create a single oncall rotation. The discussion goes something like this: “we only have 3 backend engineers, 2 iOS engineers, and 2 Android engineers. If we split, we’ll be oncall every 2 weeks”. That is true, but realistically it’s not as simple as that.

Imagine a serious problem happens on iOS while a backend engineer is oncall, or a backend problem happens while an iOS engineer is oncall. More often than not, what actually happens in that situation is they message a person from the relevant platform – it could be the most senior person, or someone they know best, or just the one who appears awake/active. If not, the entire team might receive a message asking who can help, and many people might be disturbed. Worst case somebody else has to be woken up – we now have two people awake in the middle of the night, rather than one. This creates a situation where anyone is in effect “oncall” at any time, rather than it being clear who should be responding to problems. I don’t think this is a fair approach to take.

Another argument is often “my platform will have a very busy oncall, and the others will be quiet”. Unfortunately that might be true as well, but it has the same problems I describe above. These tasks will still find their way back to an engineer from the platform in question, in most cases, without a clear system of who should receive tasks about their platform in a particular week. It’s possible things will look like they’re working well for a while, but a particular member of a platform might be taking the vast majority of the load, which again is an unfair situation.

To play devil’s advocate, I don’t think splitting by platform is an ideal solution if indeed the team is too small. The ideal would be that everyone has sufficient knowledge of all platforms that they can fix most problems themselves, and only pass things on to a person with more knowledge when absolutely needed. This feels more doable in smaller companies/ startups, but harder in big ones where engineers typically only have time to work on one (maybe two) platforms.

There are some other solutions. Firstly the team could be grown, to reduce how often each member is oncall. Smaller teams usually work more efficiently though. Secondly the oncall could be shared with another team, with two or more products being supported by the combination of those engineers. This can work, but it’s usually too hard for everyone to have sufficient knowledge across that much surface area. Finally an oncall could be created purely for triage. That person can check it’s a real problem, check which platform it’s on, and pass on to another hidden oncall for the particular platform. While this can work, it’s pretty unwieldy to manage, and isn’t much fun for the person only triaging.

I’ve tried all of these approaches, and I believe splitting by platform is the best answer. If nothing else it keeps things fair, and reduces how many people are woken up in the middle of the night. Now to decide whether it starts on a Monday or a Friday…

When Rules Rule Too Much

More processes being the answer to every problem often only causes more problems and an unhappy team. This is particularly prevalent in large companies, where there’s a natural tendency to create processes for every problem. Think of things like meetings, checklists, and being required to update documents or wikis. Individually they can make total sense, and no process at all can lead to problems too. However, it’s very easy to inadvertently accumulate too many of them, resulting in not enough real work getting done.

Imagine a situation where a small oversight by one person in a single project leads to the introduction of a checklist that every person must follow for future launches. Next, there’s a perception that people aren’t spending enough time on oncall, so they’re asked to post a summary of what they’ve done at the end of their oncall weeks and have a handover meeting. A few days later, a leader in the company reports a bug, and the team is asked to prevent it in future by having an extremely high level of test coverage before enabling anything. Continue this for a few more months, and you get the idea. On their own, every one of these decisions and processes can make sense. But the team has now evolved to have a complex web of guidelines, rules, meetings, and tasks that must be navigated before any real work gets done, diminishing productivity and just making people not enjoy their work.

A significant problem is the reaction to individual mistakes. Instead of first working with them to make improvements,  entire groups are often burdened with more bureaucracy. Performance review systems can exacerbate this problem. Senior members of the team are expected to implement things that improve it, often receiving rewards for creating them. Resisting them doesn’t get you anything (“didn’t organise a meeting” doesn’t sound great) – people may even get negative feedback for resisting such changes, even if it’s in the team’s best interests.

Noticing when things have become overly burdensome can be challenging, as it slowly creeps up on you. A good approach is taking time off. When you return after a break, you’re generally thinking about the actual projects you’re getting back too. Instead you often find yourself wading through procedures like attending meetings, writing reports, and completing training, realising that you’re not much further forward at the end of the first few days back than when you started. Another effective method is to just ask members of a team what percentage of their time they spend doing these kinds of tasks. If it trends too high, determine which processes are genuinely useful, and remove the unnecessary ones.

As is often the case there is a big exception to this idea – that is where having a process for people to blame is useful, deflecting their blame away from individuals. For example, you could design a process where every severe outage has a review. The team gets together to decide how a similar problem can be prevented in future. The review isn’t anything out of the ordinary, or aimed at them in particular – it’s just everyone working through the process. Another exception is where things are legal requirements. The point here is to identify which are important, and remove or avoid the ones that aren’t.

Process paralysis isn’t fun for anyone. While any individual decision to add a new piece of process can make sense, it’s important to be cautious about the cumulative effect. When things go too far, find out which processes are valuable and either remove or make changes to the rest. And remember to reward people for the things they don’t do, not only for things they do.