This page outlines our values. As we've covered already, this stuff is hard to capture! We've had a strong sense of our values since the founding of hx (they were one of the first things Amrit wrote up on Day 1!). After three years, we've had the chance to reflect on, and refine them to better capture the spirit within the letters.
You'll notice that this section differs from that of most companies (and also, for some hxers, from our previous values wording). We care far more about actions than talk at hx; our values are now shaped as such!
For potential hxers, we've embedded some questions to help you frame yourself within the context of our values. It's important to honestly answer these from the perspective "am I this sort of person?" rather than "could I be this sort of person"? If it's going to be a massive shift for you, against your natural temperament, then hx probably isn't the right place for you. On the other hand, if you find yourself saying "finally - a place where I can be myself!" then we'd love to hear from you.
Help move hx forward without being told
Initiative is essential in any high-growth business, but we look for more than that - hxers actively look to improve hx in ways that we may not have collectively thought about before. We are a very bottom-up organisation in our execution (and even in parts of our strategy) - we prefer autonomy and accountability over micromanagement and task-lists (this doesn't mean we don't have lists - it's that you set what goes in, as long as it helps you get the job done and works for your teammates). hx has been shaped by this "owner mindset" and it drives many aspects of our success.
So, while hx does have "lanes", they are not barriers. We encourage you to push the boundaries - as long as you do so in the right way, with the buy-in and collaboration of your team. Many of our most impactful teammates are those who have operated at the periphery of their role, whether that's bridging parts of our engineering stack, or connecting functions together.
The flipside of this is that you should expect your role and purview to change, possibly significantly, over the course your career at hx. This applies even if you are very senior, and not making "level-based progression". It's been said that high growth businesses regularly reincarnate themselves in an almost completely new form - the faster the growth, the more this happens. This is part of the fun - embrace it!
- Are never without work because you can always see things to improve/push forward
- Are confident managing your own work autonomously and with a strong sense of accountability
- Do something about issues that frustrate you rather than use them as excuses
- Bring new ideas from your own learning to the table with an eye to their application at hx
- Identify, and set the highest possible bar for yourself in your work
However, you don't
- Push your own agenda through stubbornly
- Go rogue on a project by yourself with the expectation of pushing it straight to production (note the word production; experimental hacking is highly encouraged!)
- Maintain lots of "stealth projects" for extended periods of time
What did you deliver at your previous team/company that materially changed the way it operated? When you found yourself in a situation where you were easily a top performer, did you find ways of continuously raising the bar?
Keep going, when most people would stop
hx wants to make a material change to the way one of the largest financial industries in the world uses data to make decisions. This is a difficult challenge! hxers are accordingly fussy about doing things exceptionally well (and this tends to apply to all walks of their life). We used to describe this as "excellence" but this doesn't quite capture it - it's better described as a hunger to do what it takes to be at the top of our game. To do this consistently, even when things get tough, requires intrinsic commitment and drive.
- Obsess over the details that lead to exceptional work, but most don't see
- Aren't happy with "good"
- Don't rest on your laurels after we've delivered, and celebrated, great work
- Step up and dig deep when it's needed to get the job done
However, you don't
- Let the pursuit of perfection stop you from shipping exceptional work
- Cling on to work when it's better for that work to be delegated
What have you done in your past work that people have said made you stand out above your peers? Why did you do what you did? When was the last time you worked feverishly and deeply on a hard problem? What are the circumstances/environment that created the situation? How often has this happened?
Learn deeply, by making things
We do a lot of learning at hx. It's a necessary precondition for lots of the creative, boundary pushing work we do, and a key reason many people join us - one of our aphorisms is that we perennially have more interesting, hard problems to solve than we have brains to throw at them!
hx isn't an R&D lab however. We learn by making something tangible and useful, reflecting what works by listening to clients, partners and each other, and going again. This desire to try things, see what works and change what doesn't also regularly surfaces as part of our approach to personal development and fun, e.g. in hackathons or side projects.
While many hxers have extensive formal educations in their areas of expertise, it's by no means a must-have, and some of our highest performers don't have degrees or formal professional qualifications. We value practical, experienced-based, prowess over book-learning every time.
- Focus on shipping/delivering rather than building for the sake of it
- Enjoy working on ambiguous, complex problems where exploration and iteration is a key part of finding the best solution
- Are comfortable learning as you go, efficiently and with a focus on practical useful skills
- Usually learn independently, and always try to tackle a problem yourself first
However, you don't
- Knowingly ship hacky or incomplete work
- Need to spend extended time away from work on course-based learning in order to do your job
- Shy away from bringing the team to help with problem you find very hard or novel
When picking up a project/codebase/problem from someone else, did you prefer to learn by reading the docs, experimenting with it and trying to solve it yourself, or did you prefer to be taught? What was the most unspecified problem you've ever had to solve? How did you work it through?
Apply a thoughtful and customer-centric mindset to everything we do
This is arguably the value that has served hx best to date. hxers are unusually good at assessing and analysing the universe of possibilities opened up by decisions we make and how they map to current and future customer requirements. This has been a key factor in how we've outpaced many of our competitors.
Thoughtful doesn't mean needlessly complicated or heavy-handed! hxers care much more about thinking deeply and rigorously about the audience, priorities and time-horizon that applies to the work we are doing. We also invest time upfront to reason about the complexity, trade-offs and one-way doors that are inherent in any solutions we create.
Lastly, we aren't afraid to take on feedback and criticism. This can be hard for a business and product that feels like our baby to many of us! However we are incredibly focused on making hx the best that it can be - and we are grateful to our clients and competitors for shining a light on areas which we can improve, or assumptions that we need to update.
- Always prioritise the customers' needs over any given solution
- Strive to be open-minded and balanced, setting your opinion in context of the broader environment and perspectives
- Base your decisions on what the right thing to do is, not what is best for you individually
- Know the difference between best-in-class and optimal
- Can disagree and commit
- Embrace feedback, even if it hurts - you can reflect and revert with positive steps forward
However, you don't
- Have to work everything out yourself before you can take someone's word for it
- Build everything from scratch - you know when to build and when to reuse
- Put the tech/maths/process above our obligations to our customers, and their needs
Can you recall one of the biggest one-way door decisions you've ever had to make "on-the-job"? How did you work out what to deliver? What did you learn from how it played out? When were you last "proved wrong" in a discussion/debate? How did it feel? How did you deal with the situation?
Are usually nice, never disrespectful, and always kind
At hx, the way we engage with each other matters as much as the work we do. This is an important baseline for an enterprise technology company, but that's not the root cause of why we care - we believe kindness has a leveraged impact on team effectiveness by reducing friction, increasing the safety of less confident team members and creating an environment where collaboration and serendipitous interactions are more likely. It's also inherently the right way to treat people!
It's important to note that we make a clear distinction between nice and kind:
- Niceness is making someone feel good by doing something for them or to them - the effects of these acts is often short-lived
- Kindness is about giving people the resources, opportunity and accountability to feel good about themselves
Both are important, but kindness has a long-term uplifting effect and we prioritise it at hx - even if sometimes being kind means not being so nice (for example, in giving someone constructive, but tough, feedback, we can help them understand where they can learn and improve).
However, even in such circumstances, we are never disrespectful to anyone that we engage with at hx, inside the team or out. One of the nicest complements we've ever received was from an early customer: "we've never met such a bunch of amazingly smart people who are also really enjoyable to work with". This summarises our attitude succinctly - we don't believe that intelligence/capability has to come at the expense of respect and empathy. We are always conscious of our teammates' time, energy and wellbeing, whether this is in a code review, sales pitch, or "watercooler" conversation.
- Step up to help your teammates when they need you, and don't take for granted when others do the same
- You look for opportunities to lift people up and avoid opportunities to push them down
- You respect the feelings, skill-sets and circumstances of those around you, even if they differ significantly from yours
- Communicate openly and transparently, while assuming positive intent
However, you don't
- Use politics to get your way
- Shy away from giving honest, clear feedback if it will help your teammates/hx improve (we know this is as difficult as it is important, so we dedicate lots of training and development resource to this)
When was the last time you made a conscious effort to "return the favour" to a teammate who helped you out in a time of need? Have you been the one to speak up and say what needs to be said if it helps resolve a situation, even if it's been uncomfortable?