Engineering Culture at Toplyne

Mar 23, 2022

min read

Culture is the way people behave or are with each other. The only way to build an enduring company that will pass the test of time is to build and nurture great culture.

Here are the core tenets of the engineering culture at Toplyne:

🛠 Build vs Buy

Software is eating the world, and the reason why it is able to do so is that the incremental cost to serve the next customer is ~ 0. If you are making shoes, each shoe requires the same level of effort. You have to get all the raw materials that go into the shoe in the same quantity and manufacture it. That is not the case with software. Once you build something the incremental cost to serve the next customer is negligible. Sure, you need to take care of scale and performance but they are not the same.

So why reinvent the wheel? Why build something from scratch when it’s readily available? The great thing about software is that you can leverage software built by others and build something really amazing on top of that. Every day we take those things for granted. We all use email every day but it doesn’t occur to any of us that we should rewrite our own e-mail servers and clients.

An interesting framework to analyze the same problem is to build everything that’s core to your business and outsource the rest. So for example, if you were an analytics provider, building your own custom database would make sense as it could be a differentiator that would help you improve performance, reduce costs, and build capabilities that are not available in the market. If you were an e-commerce startup, do you really need to write your own DB given that there is so much off-the-shelf software available? SaaS abstraction has reached a place where you can tick off communications with Twilio, implement RBAC using Auth0, set up operational dashboards with Grafana, and much, much more by standing on the shoulders of giants. So build on top, build for your own business objectives. Writing software is easy, maintaining it, adding features, patching it is very hard.

⏭ Process is not a bad word

Processes, if introduced at the right time, will always result in an increase in productivity. If a process is slowing you down then you probably introduced it too early but most likely did not implement it correctly. Take the example of a process of documenting and verifying your test cases before release. It might seem inefficient at that time to test the cases that seem obvious but every once in a while you will uncover cases that you may have otherwise missed.

Building the reliability of your software is all about following that checklist every single time you deploy. The cost of pushing to production assuming most things would work usually results in spending 3–5x more time finding the bug and then going through another release cycle to cover what you missed. People don’t always factor in the time sink involved therein for (multiple) teams and the damage it does to the perception of your product.

👷‍♀️ High Ownership

There are 2 kinds of people in a company in the early stages: the ones who help build and the ones who help sell. For everyone who is in the build function, it’s very important they realize that the job is not closing tickets on Jira, raising a PR in Github, or deploying code to production. It is to drive a positive outcome and impact for the end-user. That’s it. That’s the job. And yet, most folks are caught in the minutiae of code, PRs, and tasks while missing the bigger picture of end-user outcomes.

They can fall in love with code/design, tweak requirements based on the solution that comes easiest to mind without completely understanding what the customer needs. So it becomes imperative that we align people to the actual impact that they are making via the product. We make sure to involve engineers in customer conversations, Slack groups, support issues so that they develop empathy for the customer needs and the feedback loop that goes into building better products is invaluable.

🎯 Plan

Being a startup is not an excuse to be unplanned. Being a young startup does not mean you have to slog every night or work weekends. Engineers hate it when you change direction every day. We at Toplyne plan sprints and write specs — they don’t have beautiful PRDs but just a description of what needs to be done and why. As recent as last month we have now evolved to a point where we have started writing full-fledged PRDs. Having absolute clarity on what needs to be done saves a lot of time. We plan ahead to grant allowances for feedback from customers and alignment with our vision.

‍

Often, most teams are in a rush to execute, and as a result, spend far too much time rewriting and redoing. Investing in planning hours early paves a clear path forward. Writing/coding becomes very easy once you have complete clarity about the task at hand. Here’s what planning entails at Toplyne:

Document technical approach notes before we start coding
Document decisions — make sure you think through the tools you choose and document in detail why you went with a particular solution/software
Document test cases — Document test cases for each area of the product and make sure to verify the checklist every time you deploy a change in that area of the product.
Blameless postmortems — We have incident management processes in place for major outages and repeated issues to ensure that we are learning from our mistakes. When these outages occur, It’s important to take a step back, zoom out and cure the disease rather than the symptom.

🌱 You don’t need to become a people manager to grow

We at Toplyne firmly believe that we need to encourage people to excel technically to solve the problems of scale & performance we face. We have a culture of promoting learning so we encourage everyone to take any course on Coursera, Udacity, AWS certifications for devs, reforge for PMs completely covered by the company. “People management” shouldn’t be a prerequisite for career progression. Our ecosystem needs more and proficient experienced technical folks to solve challenges as we push the boundaries of scale & performance.

You can of course take more ownership of projects, architecture, and engineering but higher ownership is an independent endeavor. It doesn’t mean you will be paid less than people managers, either. This is why we have created an IC (individual contributor) architect path at Toplyne.

🔂 Iterate

The world is a graveyard of products that don’t have customers and not the other way around.

We’re firm believers of first putting a version out there that works while taking the shortest path to get there, then get a sense of whether customers resonate with the problem statement, and if yes, doubling down.

⏭ Function > Form > Delight

Prioritizing delight over form or function on day 1 may leave you with a sleek UI and interactions but at the cost of extended ship times. Imagine you spent months on an MVP prototype of your product to make it delightful only to realize nobody wants it.

We at Toplyne believe that function needs to resonate first with your initial customers when you launch your MVP. Once you have that you can go for form with the next ~10 customers and focus on delight post that. Caveat it depends on your industry/vertical — building in form and aspects of delight are important for consumer-facing apps and might be something you need to get right on Day 1.

This flips as you scale up, once you are a large org with PMF you can take more time to make sure every feature you roll out is delightful. Startups don’t have the luxury of time and resources hence these tradeoffs are very important and applicable only to early-stage companies.