Paul Wright
I spend a lot of my time talking to kdb+ engineers, over coffee, on calls and at community events. It’s one of the best parts of my job. When I bring up consultancy with developers who have 3-5 years’ experience though, I often get a similar response: “I’m happy where I am” or “consultancy isn’t really for me.”
When we talk it through, it’s rarely the work itself that puts people off. More often, their idea of consultancy is a few years out of date. The part people most underestimate is the training and development.
Learning on the job
Most of the engineers I speak to at this stage learned q on the job. They picked it up from the codebase they inherited, from colleagues who had time to help and through plenty of trial and error. Very few have been through a formal training path. That’s how a lot of people come into kdb+, so there’s nothing wrong with it, but it does leave gaps.
The typical picture is one organisation, one project and one asset class. You’ll know that system very well, every schema and every workaround. But in a large bank tech team you may be one of only a handful of kdb+ people, with limited opportunity to learn from others. Over time, more and more of what you know becomes ‘how we do it here’. Three to five years in is when being a specialist can quietly turn into being pigeonholed.
The misconception
The biggest misconception I hear is that consultancy means less development. People picture being billed out to clients and left to get on with it. For many engineers it’s the opposite. Consultancy is where they finally get proper training, mentoring and a structured way to learn, surrounded by people who do exactly what they do.
That’s certainly true at Data Intellect, and it’s something I’m proud of. We’re the world’s largest kdb consulting team, and the culture is much closer to a software house than a traditional consultancy. We have a global network of experienced kdb+ engineers working across many domains and projects, and what one team learns on a client project is shared across the business. If you’re used to being one of three kdb+ people in the building, that makes a big difference.
The range of work
The variety of work is another big draw. At the moment we have greenfield application development, core optimisation projects, AI work (both research and client deployment) and a lot of Python and PyKX adoption, all alongside a close partnership with KX. The work spans a wide range of asset classes and domains. That’s a very different couple of years from staying on the same platform, and your CV will look very different at the end of it.
Why 3-5 years is the right time
For me, 3-5 years is the sweet spot for making the move. You have enough production experience to be credible with clients from day one, and you’re early enough in your career that your habits aren’t fixed. It’s the ideal time to fill in the training gaps and broaden your experience.
So if you’ve always ruled consultancy out, it’s worth asking whether that decision is based on what consultancy looks like today.
Let's talk
If you’re a kdb+ developer, perm or contract, and you’d like to find out more about what’s happening at Data Intellect, just drop me a message. It’s a ‘no pressure’ conversation and I’d be glad to have a chat.
I’d also love to hear from others: what’s the one area of kdb+ you wish you’d been properly trained in?
Reach out or find out more below!
Share this:
