Designed by Freepik

Sometimes when I tell my friends what we have built in a short span of time, I see there eyes going wide in disbelief. One candidate I was talking to about SquadRun thought we had 10–12 developers in the team, judging by what all we had built.

But we are not a team of 10–12. At the moment, we are just 5, really committed, developers.

And we get asked this often, how do we do it? Let me try and answer that. Two axes in the development plane have to be:

Quality

How and how well is the problem being solved.

We generally keep these things in mind while designing solutions for problems:

1. The problem should get solved, of course, taking the right tradeoffs
2. All practical failure cases are handled
3. Most importantly, the design “FEELS” right

Once the design is done and reviewed, we get down to implementing it. This means less time taken for the actual code to be written since the process is carefully thought of, and less time spent on fixing bugs.

Speed

Always be shipping.

You will never find a Squad member whiling away his time. The kind of people we hire, they get frustrated with themselves if they are not achieving the best that they can.

Some of the things that we have done to maintain speed are:

1. Our deployment method, although still far from being perfect, enables devs to deploy fast! 2 minutes average deployment time to all servers, with the longer ones taking around 6 minutes.
2. Encouraged to ship as soon as a story gets done and not wait for the deployments to get larger.
3. Pull requests are cleared at higher priority so code can be shipped ASAP.
4. Do the right thing. If a particular feature doesn’t need optimisations, don’t spend time on it. Premature optimisations are a no-no.

Speed and Quality are like position and momentum in Heisenberg’s Uncertainty Principle. You can’t achieve best levels of both at the same time (I know that is not exactly what the principle says, scientists). But SquadRun has managed to strike a healthy balance between the two.

A lot of this has been possible by giving more emphasis on why we need to build something, what to build and how to build (in that order), that is:

1. Why do we even need to solve this problem? Questioning with ‘why’ always helps ensure we are aligned with higher level goals. Best code is no code.
2. Out of N problems, what needs solving before others. (What has the most ‘leverage’).
3. What is the best way to solve the problem?

It would be wrong to say that we don’t make mistakes. But we do our best to not make the same one twice. We learn from them and are constantly experimenting with our development process, and division of work among the team members. We share feedback openly, call out what didn’t work (no matter whose suggestion it was), and do more of what worked.

But at the end, more than the process, a team of engineers who are passionate about growing and solving problems are the key to doing a lot with little.

We still have a long way to go and much to learn, if you’d like to join us in building a product which we believe is going to change the world, reach out to us!

(Originally posted on my Medium account)