Learning and Development with Hannes Lowette

Satisfying Software – Hannes Lowette

How learning and development works at Axxes

Gien: Not many companies have a dedicated learning and development function. What does your role actually involve?

Hannes: Learning and development is the industry term for anything related to training your people. I ended up in this role because I've always been passionate about sharing what I've learned — explaining something to someone else forces you to understand it better yourself. If I kind of know a topic but have to present it to others, the pressure of that pushes me to dive deeper. That's always been a great trigger for me.

At Axxes, one of our core values is growth — not just as a company, but for every individual who works here. We noticed that employee-triggered learning moments generate real engagement: people learn from one another, and actual field expertise gets shared. That's what gradually turned this from something I was doing on the side into an official job title.

Gien: How do you set up the knowledge sharing in practice?

Hannes: When I joined Axxes — 14 and a half years ago now — what drew me in was an active knowledge-sharing culture. Back then we called them competence centres: one or two presenters sharing something in the evening after work, with the company providing food and drinks. Beer and pizza originally, though we've since moved to healthier options. It was simply a way to get people together to learn from each other.

Over time I started noticing we were always reaching roughly the same group of people. So I started asking: is it that these topics aren't relevant to others, or is it just that Tuesday evenings don't work for people with families or other commitments? Those are very different problems. That investigation led us to diversify the formats — lunch sessions during the workday, evening sessions, consultant-led workshops, half-day and full-day programs. We reach a lot more people now as a result.

There's always a budget question too. Sessions during the workday have an implicit cost because that's time we can't invoice customers. So we try to offer a mix — some during hours, some after — because we've found that some people genuinely crave extra learning opportunities and are willing to invest their own time, while others aren't, and both are fine.

Nine-to-five is a valid choice

Gien: When I started out there was an unspoken rule that developers had to learn on their own time. No budget, no opportunities — I did it all myself for years. But it gets exhausting.

Hannes: I struggled with this myself. When I joined Axxes I was incredibly motivated, always learning in my free time. I have three kids now — things have changed. And I quickly realised not everyone is like me. When I became a coach, my first instinct was to get everybody up to my speed, which is completely wrong. I hit that wall fast.

People have different ambitions and different expectations of work-life balance. There's nothing wrong with treating software development as mostly a nine-to-five job. And there are people — like younger versions of us — who want to push hard and advance fast. Our responsibility as an employer is to facilitate both.

The only thing I always say is: if you choose the nine-to-five path, we won't hold it against you, and you can take all your training during work hours. Just know that the person next to you who does invest a bit more of their own time will probably accelerate faster in their career. That's a completely fair trade-off, and it's entirely in their own hands.

Training budgets, points, and making it concrete

Gien: Are there limits on the training budget, or is it open-ended?

Hannes: We've always had a decent budget — not unlimited, but we've worked hard to maximise it. What makes us a bit different is that we've built our own tooling around it. The budget has two components: the time missed from being billable at a customer, and the direct cost of the training itself — conference tickets, hotels, transport. We've made that abstract through a points system, not to hide the cost from people, but to keep the value consistent as prices around us change over time.

People can see in the tool how many points they have left and spend them on things we've already listed — conferences, public workshops, online resources, sessions we run ourselves. If they want something that isn't in the tool, they reach out to their team captain and we just add it, which means other people see it too and it can spark interest. The main motivator has never been to save money — it's always been to maximise how much learning we can get for the budget we have.

We've found that open-roster classroom training is often expensive and disappointing if the trainer studied the curriculum but has no practical experience. So where there's a cluster of interest in a topic, we'll bring in an actual industry expert to teach a larger group ourselves. Or better still, we enable someone inside the company who already has the expertise to teach it — which is the cheapest and often the most impactful option.

What graduates are missing

Gien: You've seen a lot of people join fresh from graduation. What are the biggest gaps in their knowledge?

Hannes: I was at a college in Antwerp recently where we were trying to answer exactly that question. I think education still focuses heavily on hard technical skills, and not nearly enough on two things: understanding the business domain, and working with legacy codebases. When you arrive somewhere, there's almost always a bunch of existing code generating business value that you can't just throw away — you have to evolve it. And fitting new requirements into that existing reality is typically what fresh starters struggle with most, not the technical stuff they were taught.

What's strange is that practices like DDD and CQRS — which try to get code much closer to the business domain — have been around for decades. But colleges are still largely teaching CRUD with normalised relational databases. Graduates are getting new layers on top — containerisation, pipelines — but the part of software development I care most about isn't getting covered much.

Gien: That matches my experience graduating 16 or 17 years ago. It doesn't seem to have changed all that much.

How to keep learning after you graduate

Gien: The gap for me was also: how do I keep learning? Companies say you need to do it your whole life, but nobody tells you how. What's your advice for someone who's just graduated?

Hannes: The first thing is to figure out how you prefer to learn, because people learn in very different ways. Some love books, some prefer videos or blog posts, some need a classroom with exercises, some learn best by pairing or teaching. If you try to learn the way your colleague does and it doesn't suit you, it's always going to feel like friction. So start there.

The second thing is to get a mentor — someone who has a stake in you succeeding. It's also really useful to have a career soundboard who isn't your direct manager: someone you can go to with questions about learning and career direction without the hierarchical dynamic getting in the way. Juniors especially tend to try to learn everything at once and end up all over the place, which is fine early on — it's how you discover what you actually like. But a few years in, it helps to have someone ask: where do you really want to go? And to check whether the training you're signing up for actually points in that direction.

Gien: I tried to learn functional programming by simultaneously picking up a new language, a new database, a new toolchain — and I just gave up because it was too much. Eventually I got a mentor for F# specifically, and it's still one of the best learning experiences of my life. We're still close friends ten years later.

Hannes: That's exactly the stakeholder dynamic — having somebody who has a genuine interest in you succeeding makes all the difference, whichever way you look at it.

AI as a learning tool

Gien: How do you think AI can help learning and growth for software developers?

Hannes: I have conflicting views on this. On the positive side: having an AI assistant inside your IDE — not just code completion but a real chat experience — means you can learn things on the fly without breaking your flow to go and research something in a browser. That's a genuinely great evolution, especially for productivity. It's what JetBrains tooling used to do for me in a more modest way — suggesting a more elegant way to write something — and what we're seeing now with AI coding assistants is that on steroids.

The concern is that anything AI-generated is based on the code and practices of the past. It may reinforce bad habits that have been widespread in our industry, and it's less likely to reflect newer, better practices simply because the training data isn't there yet. Relying solely on AI-generated content as your source of learning probably isn't the best path.

What's sometimes missing is context — the critical thinking about whether a suggested pattern is actually the right one for the problem you're solving. But that's not a new problem. People have always applied patterns they want to put on their CV whether or not they fit. I call it RDD: Resume Driven Development. It always comes from good intentions — someone learns something, feels it's the right thing to do, and applies it regardless of whether it suits the problem domain. AI is probably speeding that up, just as it speeds up a lot of things.

The rant: learning management systems

Gien: What still frustrates you about learning and development?

Hannes: As soon as you have anything L&D-related on your LinkedIn, you get approached by companies trying to sell you learning management systems — platforms where you push training to your entire organisation and measure whether people watched the videos or completed the multiple-choice quiz. All of that tooling is now AI-assisted, so you can generate the content you're pushing to people. And they always give you the feeling that if you don't have one of these systems, you're doing it wrong.

I genuinely believe they are often a very expensive way to achieve very little — especially in our industry, where people need to train on skills they're actually passionate about, not a standardised curriculum pushed to everyone at once. The cheapest and most impactful thing you can do is put one of your own people in front of their colleagues. The presenter has to go deeper to prepare. Their colleagues learn from someone with real field experience. You bring people together, give someone recognition for their expertise, and trigger others to want to do the same. It feeds into end-of-year development conversations. The cost is often just time — or if it's after hours, pizza and drinks. That's it.

Learning management systems are often the most expensive and least effective tool in the L&D space, and I think right now they're one of the most toxic forces in the industry. Thankfully there are leaders who think differently, and those are the people I'm trying to connect with.

What does satisfying software mean to you?

Hannes: I'm still a developer at heart, so for me it comes down to two things working together. The first is a genuine focus on the actual business need — having the whole product reflect the purpose it's meant to serve, for the users doing their jobs with it. The second is developer ergonomics: it should be easy and frictionless to evolve the system over time, to add or modify functionality without a cascade of side effects and regressions.

If you can put in place an architecture and a team culture that holds both of those things together — clear goals and low-friction evolution — that to me is a satisfying product to work on.