HEXR

HEXR is unlike other companies you might typically associate with a cycling helmet manufacturer. While we have got big things in the works, what we offer to customers boils down to a physical product, so why do we have such a strong record of innovation in software?

I have gathered a few thoughts on how I learnt to be a CTO on the fly and how I am applying the same process during COVID-induced evenings at home to be a better CTO.

Behind the scenes at HEXR, we are pioneering on-demand, scaled, custom manufacturing. A bit of a mouthful but that might explain why it is so hard. Through innovation, we have now brought the lengthy fulfilment process down from 6 weeks to just 8 days in some cases.

While a lot of those improvements are credited to our partners and logistics team, the biggest fulfilment speed increase has come from our tech innovations in capturing custom 3D data and generating the custom structures for printing. When we launched, data capture was carried out using specialised hardware clipped onto the back of an iPad. These were either used in our retail locations or posted around the world (absurd to think this was an option but we really had no choice at the time).

With an incredible team of software developers, we took under a year to take an eclectic mix of 3D data processing methods, user testing insight and a slew of trial and error to package up our own sub-millimetric scanning technology into a user-friendly interface.

Now we reach the crux of this piece. When I co-founded HEXR, I was a mechanical engineer through and through. At university I learnt MATLAB and Fortran in limited capacity, however my founding expertise at HEXR was working with Jamie tweaking the parameters of honeycomb structures to best absorb energy. Out of the two of us, I knew more tech and so the CTO title stuck.

Very quickly the need to automate the CAD became apparent, so I learnt Python… Over 3 years later, my very first Python script is still sitting in the core of our software stack, calculating the fundamental parameters needed for the thousands of custom fit helmets we have made. It has been cleaned up by “real” software engineers since, but I can still find some embarrassingly green nuggets of code.

As the technical needs at HEXR have grown, the hard skills I have learnt came most prominently from scrambling to make sure I knew what my team was working on. When new methods, operations or even entire products have been needed, I have learnt on the job the resource and ramifications associated. For example, in the early days we had issues with data being lost during transit due to unpredictable internet. Naivety would have led me to say “it’s just uploading, how hard can this be to fix?”, but rolling up my sleeves, learning about redundancy-based uploads, caching and race conditions, helped me put together a proper plan for the team to solve it.

I now feel confident in my abilities as a technology lead just as much as my mechanical engineering. With spare time on my hands I wanted to dive deeper into our core server, the one that processes more traditional customer data, not the unique 3D data that I already feel comfortable with.

From what I have learnt, I felt the best way to do this was to think of an end project and learn on the job, while trying to build it. That is why I have been working on my own JavaScript project for the past few months. A full-meaty-stack app, from elegant backend logic to a zippy React frontend. While it is not related to HEXR in any way and it is certainly nothing I would want to link to from this piece, it is exposing me to all the same tools and logical processes my team go through as part of their daily job.

I have already brought back a few ideas from this personal project to work. I now have a much greater appreciation for what my team is working on - how I can best divide resources, and talk through real solutions not just high level lingo. I am of course enjoying learning something new. And finally, I might end up with an app that is actually useful!