MARCH 16, 2023

BRAID’S TEAM

<aside> 💡 Welcome to the first article in our series of Tech Team Profiles!

Here, we’ll introduce you to the team building Braid’s automated engineering design technology. We’ll start the series by interviewing Máté Kovacs, Engineer #1 at Braid.

</aside>

Give a 1-minute elevator pitch of your career in tech so far.

Mate : I got into computing because of video games, which is funny because I have never worked on video games professionally. I specifically remember being inspired by Wolfenstein 3D and Doom. They were the first 3D games, at least that I can remember.

After studying autonomous intelligent systems in university, I worked at a startup in Budapest called Prezi. I got the job there because I was actively answering questions about Haskell on Quora. The CTO of Prezi saw my answers on Quora and cold-called me. He said, “Why don’t you come work with us?”

Mate working on early prototypes of Braid’s core software

During my time in university, I had internships on the West Coast. At the end of my first internship with Google in Seattle, I already knew that I was interested in startups. The people I asked all recommended going straight to the source: Silicon Valley. I ended up working at several startups in Silicon Valley for many years, including Sumo Logic, Quora, Sourcegraph, and Coursera.

Silicon Valley felt magical: it was full of like-minded people and imbued with glorious history. I lived in the neighborhood where Steve Jobs grew up, just a few minutes bike ride away from the legendary “HP garage.” I used to get my groceries from a supermarket next to what was once General Magic. And to top it all off, I made a ton of great friends. However, the more it felt like home, the more it made me hungry for new experiences. I became restless to join building something new that had a chance of becoming similar to the early years of Silicon Valley.

I joined Ascent Robotics in Japan in 2018, where I worked on mostly simulations for self-driving. It’s also where Guido, Ivo, and I first met. After the self-driving effort at Ascent Robotics was shut down, I went to Woven Alpha to continue working on that. Many of the people I liked at Ascent Robotics had already left to go to Woven Alpha. It was a big company; I didn’t understand how much I would miss the startup environment that I was used to. Eventually, Guido and Ivo approached me and I ended up at Braid.

Briefly describe your role at Braid.

I’m Engineer #1, which means that I am responsible for shaping the engineering culture, the initial prototyping work, and figuring out exactly what makes our work difficult. From experience, I know that my personality is well-suited for these kinds of problems.

I like difficult, open-ended problems where nobody is going to come and help you. Maybe nobody knows the right answer. I like that because you have the opportunity to do something new.

Part of shaping the engineering culture involves managing the pace of technology development. On the one hand, it is important to “measure twice, cut once,” which in this context means thinking critically about the problem prior to actually coding to minimize wasted time and effort. On the other hand, you also have to work within the constraints of a startup with a limited runway. How are you establishing the right pace with Braid’s growing team?

“Measure twice, cut once” is a good mindset, but in practice, it ends up being “make a lot of small cuts that are not the full cut at once.” When I first started at Braid, I and the founders started by working on things we thought would be blocking obstacles.

In my experience, success or failure at a startup comes down to whether you find the problems that you absolutely have to solve to reach a larger solution. Early on, it’s not even about finding solutions, but figuring out what the problems are.

I’ve seen quite a few trainwrecks throughout my career. I think it’s actually a good experience to witness these kinds of trainwrecks when you’re a junior because they teach you what not to do. I’ve often observed that, after building solutions for the low-hanging fruit, the team discovers that there is an unforeseen obstacle that ultimately leads to project failure. Had they considered that problem earlier, they may have been successful.

At Braid, some of our early prototypes didn’t go anywhere. We often realized that, while we could implement something, it would cost so much in terms of time, labor, infrastructure, and code maintenance. Some of the early prototypes, however, had salient properties that we discovered by testing hypotheses. After building a few of the larger prototypes, we eventually had a working pipeline.

Mate and Guido celebrate the holidays at the old office

Working at a startup, you have to deal with uncertainty. When you’re managing a team whose working on projects that lie on a spectrum between relevant prototype and pet project that’s doomed to fail, how do you as Engineer #1 guide your team towards success?