Another behind-the-scenes story from LearnLinq – this time from the IT corner!
Hi, I’m Jason Payne, Principal Engineer at Infinitas Learning, the parent company of Noordhoff. In my role I oversee the development of LearnLinq and other software products. I’m originally from the UK, hence this blog being in English.
For anyone not familiar with software product development, I can imagine the job title ‘Principal Engineer’ (PE) doesn’t mean much to you. So I’ll start by explaining a bit about my role. I work very closely with Martin Seegers (Product Manager) and Martijn Luijks (Proposition Manager) to ensure timely and accurate development and delivery of the features and functionalities that are on our roadmap. One might say we are sparring partners, coming from different angles.
As a PE, I am tech driven – that’s my area of expertise. My preferred outcome is the highest quality code possible, which meets the requirements of the user. But striking a balance between gold-plated code and timely delivery is an important element of my job. As a PE, I don’t get to code as much as my team does, but I must admit that writing code and automating things is really my passion. Which is great because that means my hobby is my work! So you can imagine that it’s only healthy to have Martin and Martijn as my sparring partners to challenge me from time to time (and vice versa!) as we are not here to build the most beautiful digital Lego 😉 but to develop the best, reliable features in the shortest possible time frame – to help our customers. So, together we negotiate on, for example, the requirements needed, priorities, time spent on technical debt and bug fixing as opposed to new feature development, etc.
In my role I direct the development team as their tech lead. At the moment, this means streamlining processes and introducing the ‘DevOps’ way of working. (DevOps, as the name suggests, is a marriage of development and operations, but also product management; and makes the development process more structured and creates a better overview.) In addition, I work closely with UX on the design of new features and functionalities. And a big part of my job is to educate my team of software engineers how to define user stories: the journey a user goes through when they use the application. It’s important that they keep seeing the wider picture, and not just the tasks they’re working on.
The user story
As a customer, I am sure you’re familiar with our roadmap on Productboard. Those are what we call ‘epics’: although they seem like tangible and concrete functionalities to you, we need to break them down further and further until we get to a ‘user story’ level. And often, even when we think we’re there, a user story can be broken down even further into even smaller user stories!
To give you an example: as part of a feature we’d like to create an ‘enroll’ button. The user story is: a customer wants to enroll on a course. But button is just the tip of the iceberg; beneath the surface is a lot of code that does everything necessary to enroll the user on the course, which goes way beyond just placing a button on the user interface – generally, the easier we make something for the user, the more complex it is behind the scenes, which can be counterintuitive. This is why customers (and even our own non-technical colleagues) can often underestimate the work that goes into developing software.
Martin and I help the team build the backlog of user stories through scheduled feature chopping or story mapping sessions, refinement meetings, and other Agile ceremonies. After all, the goal is for us to make it as easy as possible for a customer to enroll on that course. Some questions we continuously ask ourselves: Are there gaps? Have we missed part of the user story? What could be a user story that would follow this particular story? In this case, you could think about: How do I get approval from my manager for this course? How do I find the course in the system, easily and quickly? So you see, one epic easily expands into all these different user journeys that form a backbone of new user stories.
Fail to prepare, prepare to fail
This is one of the things I learned early in my career: preparation is key. If we don’t prepare well enough, sharpen our user stories, delve deep into what the user needs and wants, then we won’t succeed in providing our customers with the best possible system. It could result in unexpected bugs or, even worse, outages – which is of course something we want to prevent at all costs. So we work in a cycle of continuous improvement where we constantly evaluate and reflect on our performance as a team, through regular meetings we call ‘retrospectives’, but also through open and frank discussion on a daily basis.
It is important for me to make responsibility for quality the lifeblood of our development teams. This means, ‘you build it, you run it’. No more throwing code over the fence and expecting it to be the support team’s “problem” if it goes wrong. Developers are incentivized to feel responsibility for the code they write on the front line. This leads to quick resolution of problems, and a shorter line between end users and the engineering team.
Despite loving software and believing in the power of technology, one of the most valuable things I learned in my career is that technology is 100% about the people. The human factor is so important and often underestimated. Therefore, my main goal is to cultivate a team culture and environment where personal development, learning leading edge technologies, team inspiration, transparency and involvement at all levels, and loving coming to work, are the modi operandi.
And this is why I’m excited to be at Infinitas where this human factor is a big part of my role, while also having my feet in the mud, as they say in the Netherlands. 😊