How to Build Tech with Less 

As the co-founder and engineering lead of a fast-growth tech company, I’ve had no choice but to do a lot with a little. As layoffs and cutbacks continue to plague the tech universe, I’m sure many founders are in a position where they need to squeeze everything they can out of their engineering teams. I’m lucky enough to have these technical skills as a founder, but for those who aren’t as well-versed in the world of software development, here’s how I’ve crushed our growth with just a team of four.

Hire Creatively

Aside from the typical filters like no assholes, someone who’s technically competent, communicates well, etc., we look for engineers who genuinely love to code. None of our engineers have what you would consider a traditional Silicon Valley background where they studied at Stanford/MIT (or even studied computer science at all in undergrad, for that matter) and spent time at Google or Meta. However, through other avenues, our engineers have shown a strong desire to learn and a passion for coding. For example, someone on our team is in the top 1% of stackoverflow respondents. This passion and curiosity help us sharpen each other’s thinking during discussion and allows us to get through difficult technical problems. Plus, it’s fun to work with people that love what you love to do.

Here are a few signals we look for to help identify candidates who don’t just like but love coding:

1. Side hustle - Do they build things on the side outside of school and work?
2. Community focused - Are they active and do they contribute in open source communities?
3. Self taught - Have they taught themselves new skills?

Pair Programming

Pair programming is a pivotal part of our engineering culture. Especially when we hire a new engineer, we try to pair program as much as possible. We believe pairing is the best and fastest way to onboard someone and familiarize them with the code base and team culture. It’s also a great way to get a fresh pair of eyes on our existing codebase. Furthermore, pair programming allows engineers to work across projects as knowledge is spread across the team, so almost anyone can hop in to implement a new feature or fix a bug. As a result, this allows us to minimize bottlenecks and protect engineering time as people don’t have to get dragged away from their current project and continuously context switch.

Let Engineers Code

Even though we are a calendar company, we do everything we can to minimize meetings and create as many focus blocks for deep work as possible. When we went through YC in 2018, YC’s president Michael Sibels gave us a framework for sprint planning that we still follow to this day. The basic summary is that you have one meeting a week, that is, as long as it needs to be for review and discussion, and at the end, everyone commits to a set of things to complete for the week. This is our one and only dedicated meeting for the week for the engineering team. An additional benefit is that engineers can work on a schedule that’s most comfortable for them. We have someone on the team who’s a total night owl, and as a result, he’s able to work when he feels productive while not slowing the rest of the team down.

Share Feedback/Bug Reports

While we don’t expect engineers to read through every single customer email, everyone on the team receives them in a shared inbox. As a result, everyone has a sense of what needs to be built and what needs to be fixed. This does three things:

1. Aligns the team, and no one feels like they’re doing unimportant work.
2. Sharpens product discussions as everyone has their own read of customer emails - this is especially true for feature requests.
3. Allows for faster response times as someone on the engineering team will often see a relevant ticket and can put a fix in that day without having to wait until the next sprint cycle.

This also helps us avoid losing track of emails and raise overall user satisfaction.

Final Thoughts

Building a tech product requires great grit, passion, and determination from all involved, which is table stakes for success. Outside of that, the above is what’s helped us at Vimcal scale our product to meet the demand and issues associated with thousands of new users in a short period of time. It doesn’t take a coding genius to know that tech will probably need to run lean for the foreseeable future, so I hope the above can be a helpful guide to getting more done with less as a tech founder.