Moving On: Reflections on My Journey at BRINC

After a whirlwind of a year at BRINC, where I founded the web app team and built the first version of LiveOps, I’m moving on to a new role at PostHog. It has been a transformative year filled with valuable lessons, both enjoyable and challenging. As I transition, I want to reflect on my experiences–what worked, what didn’t, and what I learned in the process. Finally, I’ll share a bit about what I’m looking forward to at PostHog.

Reflecting on my goals

When I first joined BRINC, I had a few key goals in mind:

  1. Build a product from scratch and scale it to bring in revenue
  2. Build a product that I’m proud of
  3. Stand up an engineering team and build a world-class engineering culture

Looking back, I had mixed success in achieving these goals.

Building a Product from Scratch

This was the biggest goal I had for myself; a personal itch that I’ve wanted to scratch for years. And this is the goal that I am happiest about accomplishing – while at BRINC, I was able to both build a 0 -> 1 product in less than a year, and by the time I left this product was doing 6 figures in ARR. It was an indescribably special feeling to see my first ever users in my production DB.

I learned a lot about tying together managed AWS services into a cohesive product (BRINC is heavily leveraged into AWS, and at times I felt more like a solutions architect than a software engineer). I had a codebase that had 100% test coverage, fully automated deployments in dev, staging, and production environments, fast deployments, and excellent typing, linting and documentation (which IMO are force multipliers; having a codebase that you can trust makes rapidly prototyping new features much easier).

However, while I was happy with how the product was made, I think I struggled to really figure out what to make. I didn’t really build a strong intuition on what the right things to build were, and I didn’t push back on the opinions from external forces (CEO, other engineering leadership) on what the products we needed to make were. I think I made the mistake of blindly following user inputs too much; in my goal to listen to my users, I ended up building more things than I think the product needed, and I felt like I didn’t spend enough time stepping back from (what ended up being a pretty robust) product and focusing more on ironing out core functionality and defining explicit CTAs on the website. By the end of my time at BRINC, I felt like my team was becoming a feature factory.

Building a World-Class Engineering Culture

This is the area where I think I struggled the most. On one hand, I had the pleasure to hire some excellent engineers, and working with them will be the thing I miss the most about my time at BRINC. The team I assembled is humble, motivated, thoughtful, and kind. I was lucky to work with them.

However, I never really figured out how to build this team into a juggernaut. I think I was doomed from the beginning: one of things I learned about myself during my time at BRINC was that my ideal workplace environment is remote, async, transparent, and biased towards written communication with an intentional focus on minimizing meetings and maximizing focus time.

BRINC, on the other hand, had an existing engineering culture of in-person work with many alignment meetings, a focus on synchronous decision-making, and no real support for the remote flexibility. To its credit, this was an artifact of its original DNA: BRINC is a hardware company first and foremost, and many of the ways that I know about effectively building software don’t translate to the hardware front. But my regret was that I never got the company to understand that different types of product development can (and maybe should) introduce different modalities of working.

Lessons Learned

I learned a lot while working at BRINC. Here’s the stuff that stuck with me; some of it was about technology, but most of it was about myself.



This might sound cliche or banal, but the biggest positive thing I learned about myself was: I can do this. I am capable of building things from scratch, and with the power of managed AWS products, an intentional focus on DX, the glut of very good AI-assisted tools, and time to really focus and grind – it turns out I was capable of building a lot, just by myself. I never thought I could really do this until I actually did.

I also learned (or re-learned) a bunch of things that ultimately made me want to depart:

What’s next

I’ll always be grateful for what I learned while at BRINC. I achieved my most meaningful goals, I learned a lot, and I genuinely enjoyed working alongside my teammates there. But, I am really excited for my new role at PostHog; I’m only a week in, but it feels like the kind of place where I can do my best work, and I’m so excited to continue to sink my teeth into the work. Before I wrap up, though, I wanted to reflect on a few factors that stood out to me while I was interviewing that strongly contributed to my belief that PostHog was the right next step for me.

Closing thoughts

Moving on from BRINC is bittersweet. The experiences and lessons learned there have shaped my professional journey significantly. As I step into my new role at PostHog, I carry these learnings with me, ready to contribute, learn, and grow further.

  1. I understand why BRINC was a sales-driven company and why products were largely motivated by who was willing to pay, and what they wanted. And I think it makes sense for BRINC to follow this strategy; their primary customers of governments, which, in their long and convoluted sales cycles, oftentimes turn into a discussion of feature parity, so making sure that your product has the feature oftentimes felt more important than if that feature worked well. Furthermore, because the lead time between signing a contract and actually shipping users their drones was so long, it led to a lot of “building the engines while the airplane was in the air” type of development, which can feel exhausting if not carefully managed. Again, these attributes are not necessarily inherently bad, and I think BRINC following this strategy makes sense for them. However, I learned that I find much more value and meaning in my work when the focus is on building excellent products that could “sell themselves”, rather than pushing out seemingly arbitrary features to comply with an RFP. 

  2. While I’m a proponent of remote work, I think that the best remote jobs mix in a healthy amount of in-person socializing to help foster camaraderie and team-building. To this point, I’m a big fan of in-person onboarding, even for jobs that are primarily remote. PostHog does this for every new hire, I’m just the lucky guy who got to do his in-person onboarding during the company offsite.