Across every team, no matter the role, the humans behind Onebrief are our superpower. Throughout this new blog series, we'll spotlight Onebrief-ers across the organization and share a behind-the-scenes look at their contributions, their inspiration, and stories of their successes, failures, and most profound professional memories.

‍

Meet Will Wharton.

‍

Q: Tell about yourself!

I'm a senior software engineer on the Data Platform Team at Onebrief. Along with my teammates, I am responsible for ensuring our user’s planning data is secure, reliable, and accessible.

‍

Q: Tell us how you came to Onebrief and why.

About half a year ago I accepted my offer to work at Onebrief. During my job hunt, I knew I wanted to find an organization where I could leverage my whole skill set (more on this shortly), and I decided to hunt for a later stage startup. I believed this would be my best opportunity to find a company that would give me the room to flex and improve my skills and creativity. I always strive to challenge myself as a contributor by tackling meaningful and challenging products, but I also want to grow as a collaborator, helping to inform technical direction and design.

Onebrief stood out to me for several reasons. First, its product is exciting; it is a next generation collaboration tool that solves meaningful, high stakes problems. Second, during the interview process, I was struck by the enthusiasm of the engineers and EMs I interviewed with; people here are mission aligned, intelligent, and motivated. And finally, the job looked challenging and I hoped it would be an opportunity to push myself out of my comfort zone and continue to grow.

Since being hired, I have reflected on how I ended up here. My background is unconventional; when I graduated from University of Michigan with my Honors BA in English, I didn’t go straight into engineering (shocking!) Instead, I worked for several years in a tech-adjacent business development role in the STEM Education industry. There, I invented products, gave talks, signed business distributors, organized and led user training workshops, and ran sales - including building booths and hosting exhibits at dozens of sales exhibits over several years at industry conventions (including the Consumer Electronics Show!)

My career pivot is a longer story, but in brief, I began taking on increasingly technical responsibilities. I leveraged the first year of COVID as a hyperbolic time chamber where I doubled down on engineering, taught myself modern web development, and went through an absolute meat grinder to land my first engineering job. I became a technically competent junior, and I made up for my lack of engineering credentials by demonstrating the technical competency I established on my own and by clearly communicating my value, thanks to my unique early career experiences.

Those early career responsibilities sharpened a wide set of skills that I believe, to this day, make me stand out among other engineers. As I would describe it, those experiences fostered a sense of intrinsic, radical ownership in me. I feel confident taking command of ambiguous work, facilitating communication across different levels of technical and product understanding, and researching, designing, and delivering highly technical solutions. I always imagined startups to be full of other engineers motivated by this kind of ownership, and my time with the team at Onebrief has confirmed this aspiration.

‍

Q: Tell us about a the most interesting challenge you've worked on.

As a successful startup, Onebrief has a growing engineering organization, and every day I get the opportunity to collaborate in small or big ways with intra-disciplinary teammates. I am fortunate to work closely with my teammates, my manager, an embedded product designer and project manager, and other teams to deliver both a stable experience and new features to our users.

My proudest individual accomplishment so far was delivering an optimization which almost totally eliminated a critical performance bottle neck. It was work which was more than just an application coding effort, but required me to work within the constraints of our secured deployment environments and coordinate communications across an interdisciplinary cohort to understand and optimize our collaborative Audit Trail.

Unlike a typical SaaS product where engineers can lean on auto-scaling strategies, our secure network deployments come with fixed resource ceilings. That constraint forces a different design mindset, forcing me to think more critically about design choices.

Previously in my career, a sub-optimal decision was typically a cost benefit analysis, where typically the convenience of auto-scaling wins out over the added time cost of implementing a deeply optimal solution… more pods…more storage…more cores… It’s easy to take these things for granted. Now, I carefully consider every write pattern, query path, and background task for CPU cost, memory pressure, I/O amplification, and vacuum impact.

The Audit Trail came under scrutiny in response to generalized performance issues emerging at scale. (These kinds of problems are the rewards for success!) To address this problem, I led a project and consulted with my teammates to redesign the way we capture and store audit trail records.

Our architecture had previously made the compromise that we could afford to pay for consistency with frequent writes, with the understanding we’d likely have to revisit it later ~ but later came sooner than expected. Under the resource ceilings of our secure network deployments, that tradeoff became unsustainable.

Our original design, suitable for typical auto-scaling infrastructure, relied on a timeout-based change grouping mechanism that maintained a hot head record via UPDATEs to the audit trail table. While this approach ensured quick lookups and real time visibility, the downside was its write pattern yielded costly UPDATEs to the hot head row. This caused significant write amplification, bloated the table with dead tuples, and triggered excessive spikes of CPU utilization during vacuum. This, in turn, introduced latency across core application workloads, degrading user experience. It was a clear signal that our update oriented strategy wasn’t resilient under load and needed to be rethought.

The solution was to implement a trailing head. We continued logging all changes in real time, but instead of updating a "hot" head record with every event, we introduced a delay: head entries are now written after a timeout period and only when a new stable state has clearly emerged (either via timeout or change count.) Additionally, we shifted final materialization of the audit head to query time, which is now generated on-demand when the user views the audit trail. This allowed us to replace expensive UPDATE operations with cheap INSERTs, offset with minor cost to the much less frequent Audit Trail lookup, and drastically reduce write amplification and eliminate head churn under load. The result was a near total elimination of audit trail CPU load, and total elimination of Audit Trail PG autovacuum load, which together were a huge win and a critical improvement for the stability of our application.

Besides tackling challenging and loosely defined engineering initiatives, I have felt Onebrief has great opportunity for engineers who want to own their work: I'm empowered and trusted to act on my instincts to perform my own research spikes.

I am lucky to have had the opportunity to dig in, perform analytics, develop PoCs, and otherwise explore, document, and make recommendations on the changes and improvements that I believe are important for us to succeed. This effort most recently paid off for me personally, as my team has had a directive to focus on improving stability, resiliency, and observability - and my research into the subject was critical in shaping my team’s work for the quarter.

‍

Q: What's next?

After this half year, I feel I am settling in and finding my rhythm here. I feel like I am part of a team and organization with purpose, and I look forward to the future. I participated in my first team offsite just recently and the experience made me feel even more connected to our team, our engineering organization, and inspired me to continue working hard to meet our goals.

I am excited to see Onebrief grow. I think we are uniquely positioned to beat the incumbent technologies on merit and become THE collaborative planning tool of the US and Joint Armed Forces.

We have initiatives underway to tackle unsolved problems in the space, and I am excited to be a part of an engineering team that is facing the exciting consequences of success and growth - a stark contrast to my previous experiences where I faced the consequences of declining shared values and PMF struggles.

There are major challenges and obstacles ahead of us, but I am encouraged and surrounded by other engineers and leaders who welcome the challenge and strive to not just meet, but exceed, expectations.

Onebrief has an objectively more important and critical product than any company I have worked for previously. Our mission is to modernize mission planning, and make planners “superhuman.” Winning here means positive outcomes for the U.S. and Allied Forces. This kind of work has a gravitas to it that I have not previously experienced, having no history in defense nor military service. It is daunting, but I find it a powerful motivator that aligns with my personal growth goals, as I push myself to learn how to understand and implement increasingly complex technical solutions and to be involved in trying to solve new and novel engineering problems. If that is what you are looking for in your engineering career, Onebrief should be at the top of your list of opportunities.

‍

Join Will's team; we're hiring!