My observations since joining Tecton as VP of Engineering

I joined Tecton 4 months ago and would like to share my impressions while they are still fresh! I have spent almost 2 decades in various startups. In seven of them I was Director of Engineering and later VPE in quickly growing startups such as Mulesoft (IPOed and later got acquired by Salesforce) and CoreOS (acquired by Red Hat). I also spent 3 years as a VPE at Red Hat, a large public company, as well as the granddaddy of enterprise open source, so I figure I have enough comparison points. 🙂

While every person I met at Tecton absolutely impressed me, my observations are focused on what’s near and dear to my heart: the Tecton engineering team.

I could talk about how I am impressed with the caliber of the team, how they are solving a very complex problem with an elegant set of approaches and no extra complexity, or how nice and friendly everyone is. But to be honest, the top three things that amazed me the most were something else:

• Mature operational setup (especially considering the age of the company)
• Attention to customers with a strong focus on user experience and general empathy towards the users
• The sense of a team, rather than just a group of very talented individuals (a situation I have observed very often in tech companies, especially startups)

Mature operational setup

Tecton is a managed service targeted at enterprises. Being a feature store for production applications such as recommendation engines or fraud detection systems is not for the faint-hearted. Not only do we have to maintain strict uptime SLOs, customers also expect low latency guarantees. Tecton consumes data from multiple sources, some of them with lower reliability than the SLOs we provide, at volumes that at their peak stretch underlying hyperscalers’ infrastructure to their limit (not kidding). We are also a series B startup which is less than 3 years old. In my past I often observed much more mature organizations, with vastly greater resources, being stretched to their limits with less stringent requirements. Software developers and DevOps engineers would dread being on call, constantly fight fires in production, hesitate to deploy new releases, and have endless discussions on how to improve operations.

So it is very impressive that the team built the software with strong operational requirements in mind from the start and that’s definitely paying off. By no means are we perfect, but we do release multiple times per week, which is easier said than done in the enterprise world. We released a major update to our backend and migrated all of our customers with zero downtime and no maintenance windows, with the whole engineering team oncall and no one dreading their shifts. Our monitoring is transparent and relevant metrics are embedded into the user facing UI. Does it mean we are “done” – no, there is a lot of exciting work ahead of us, our customers will always want a faster, more efficient solution, supported on a variety of public clouds. And internally we can always improve our build pipelines, release processes, production monitoring, but I am excited to see that we are building on such a great foundation!

Attention to customers

Every engineer at Tecton has one or more strategic customers that they are helping from the customer’s day 1 and are deeply aware about their use case, staging and production setup, what features they are using, the names of the users, you get the point. Yes, we have a customer success team, and they are very knowledgeable, helpful and involved, but I can’t underscore how important it is that every Tecton engineer has a direct connection with product users. I often saw in prior companies that engineers would only get involved when something is crashing and burning. They usually have very little context of what’s going on, have no idea of a customer’s use cases, and as soon as they fix the problem, they may never talk or hear about that customer again. That leads to the engineering team commenting on how users “do not understand the product”, dreading being reached out by support, and general misunderstanding of user experience and product lifecycle in the real world.

So how does it work in practice? Each software engineer is a part of the engineering point of contact (EPOC) rotation. It does not matter if they are very senior or recent graduates, after a few months engineers start shadowing solution architects and support team, and once they reach a certain level of experience answering support questions, they join EPOC rotation. As a result, anyone who joins Tecton engineering is guaranteed to become a highly visible EPOC to an actual life customer and start learning how they use our platform. I find this approach very empowering to the engineering team, since every member of a team can contribute to product discussions not only from a technical standpoint but also by relying on a very concrete use case they understand intimately. I often heard “product ownership” words applied to engineering teams, and what can give more feeling of being a product owner than actually directly supporting the customer using your product? It also teaches engineers and managers the importance of balancing between helping customers, fixing bugs and shipping features. As I observed the process, I came to a conclusion that EPOC serves as a self regulating mechanism that ensures the quality and reliability of our offering in addition to being a valuable personal development tool. We apply a similar approach to Feast, our highly successful open source project, but it’s a topic for a separate blog.

It’s all about the team.

Tecton’s engineering team is incredibly talented. The team includes past winners of Olympiads in Informatics and Math, graduates from top technical universities, and ex-engineers from Google, Uber, and a variety of other highly successful public companies and startups. But what impresses me the most is the sense of camaraderie and desire to help each other. Folks rolling their sleeves up and fixing build failures, backend engineers helping with UI development, helping to train support, writing documentation, fixing code in our examples, and of course venturing to try a new Boba place together. 🙂 A lot of engineers invested their time to improve the onboarding process, not only for engineering but for the whole company. Our weekly demos are amazing but it’s also so great to see the level of engagement and support for one another at those demos. Some of the most senior engineers volunteer to help not only with coding tasks but to help train new folks how to conduct interviews. It’s no surprise that the moment we were able to partially reopen our offices, a large portion of the team enthusiastically started showing up to hang out together (COVID safe of course). And no, there is no requirement to be in the office, but I strongly believe the trust team has in each other extended to knowing that your team members won’t be risking the health of others. Of course it’s not only about work, we also run marathons and triathlons, play beach volleyball, have BBQs, go sailing, and even plan to learn synchronized skating. 🙂

So in conclusion, I can honestly say that I am very excited by technology and the team that we are building, and what a great group of humans we have here at Tecton. We have a lot of open positions and are always looking for amazing team members to join us!