The last few years have been excellent for the words pivot, unprecedented and transition throughout the world as we’ve battled through the COVID-19 pandemic. The last years have forced us – and many others – to evaluate what worked and what didn’t. We’ve conducted a major shift in what kind of work we want to take on, and how we can help make a difference in the world with the projects we do – you can read more about this here. Stepping back from the blue sky thinking of saving the world one line of code at a time, how do we actually achieve it? We achieve it by actively listening to our clients. 

A new way of quoting projects

Historically, whenever we had a client come to us with a problem, we’d quote up the job thinking about just the technical side of things, and not consider the actual logistics of running the system from the client's perspective. We were tech first – only thinking about what we needed to know and what we thought would work best, not how we could improve our clients' lives. This resulted in us building systems that were technically sound, but often didn’t meet the full requirements of the client's organisation, because we hadn’t thought to ask about how the system will integrate with their workplace, what other problems are faced when trying to get good data, and what the technical skill level of the team members is. This led to us not having the best post-release relationships with our clients, despite the software meeting the technical spec and being on par with the industry standard. 

You might be thinking, ‘were you just selective listening?’, which may have been the case, but often our clients will come to us with not much information regarding what they need because they can’t quite name the whole problem. We often see our clients burnt out, frustrated, confused and overwhelmed by the sheer complexity and frequency of their reporting requirements. Coupled with staff shortages due to the high barrier of entry to work in these spaces, it’s a tricky place to be in. We often get clients who have been referred to us, or are at the point where they’ve run out of cells in their corrupted Microsoft Excel spreadsheets. Our clients are the experts in their fields, tackling big problems like unemployment, youth development and environment sustainability. They’re not experts in understanding what can be automated and how that should be designed, they just know there has to be another way.

When these clients come to us, they often come to us asking for an alternative to Microsoft Excel, and haven’t thought about all of the other ways they can do things. We used to overload them with a bunch of questions on the spot, and produce a quote straight after the meeting that would (probably) fulfill the needs we heard them say in the space of a 30 minute long meeting. Sometimes we’d get the work, sometimes we wouldn’t, but every single time, we would finish a project and think, ‘I wish we thought about that at the start, it would’ve made things even easier for the client’. This frankly wasn’t good enough in the democratisation of services, and in a world where listening and expressing empathy continues to be held in high regard.

Sharing is caring

So how could we improve our customer experience levels and ship even better software? 

Asking questions and actively listening to our clients.

The IT/software industry isn’t well known for being great with people. If you think of good customer service, industries like hospitality, retail and professional services will likely spring to mind – not a bunch of IT nerds. This was the case for us up until 2021, when we decided to make an active shift to look at our clients and projects from a holistic perspective. The message sunk in that, when we’re all working remotely, you don’t get to have those conversations with people in person to learn more about what they value, prioritise and are impacted by. Therefore, we need to actively seek that information out ourselves, to ensure we’re building software that meets not just the technological, but the organisational needs of our clients.

Computer says no

So how do you make this happen in the real world? We decided to not try and make a square peg fill a round hole. We don’t force our creative team to code, so why would we force our engineering team to investigate people's motives? 

To combat this, we’ve decided to expand our team. We are currently a team of engineers, with two people filling the project management space, to help maximise our output. Instead of hiring trained consultants, we’ve decided to hire a team of journalists. Why would we pick a journalist over a trained consultant? It’s simple really, we wanted to hire people who are professionally trained to build a story. To be patient with people who might never have spoken to someone in our field before, and to not be threatened by the prospect of traveling remotely to learn more about the organisation. We’re starting with the core characteristics of how we want this team to relate to our clients and training to add the technical elements from there.

Our team of journalists spend the time with the client on site to learn about the story of the organisation, how everything they do intersects – or doesn’t, and the logistical challenges of the organisation that they face every day.

This story is formulated into a document that outlines the organisation's needs, challenges and limitations. Only then, do we pass it over to our technical team to analyse and propose a technical solution that would help to solve the problem. Once we’ve got a plan of attack for the technical component, we collate everything into one big scoping document, supported by images/footage we shot on the ground too where applicable, and share it with our client. We chat through our thinking, and the best options to move forward with a system that meets all of their requirements – supported by a quote for us to undertake the work. From there, the client can choose to stick with us to undertake the work, or they can head out to market with an in-depth spec that will result in a system that meets their exact requirements once it’s completed.

Is this the death of the engineer?

Expanding our team into a multi-disciplinary group of engineers, journalists and project managers is the best way for us to ensure that we deliver systems that actually work on release. It is also much more meaningful work. We’ve been doing things this way for almost six months at the time of writing, and it is so rewarding to know that our clients are on board with the way we do things and we’re on board with the way they do things right from the get go. 

Communicating these clear expectations from the start allows us to work on projects that lead to successful outcomes for both us and our clients. We used to be quite stressed that we were missing something when we were developing, because we didn’t allow for the time to properly spec out the project with the client to learn about all of the potential edge cases that might crop up once they got to use it. As somewhat of a young software company, we’ve learnt that this is not best practice, and we’re changing that. We’ve learnt that proper scoping is actually an integral part of all software projects.

Not only is the quality of the software greatly improved, but we are able to operate in a space where we can wear our critical thinking glasses, and look at a problem from all angles. As the technical component of our industry continues to change, we know that AI will never be able to automate or replace empathy. So we’re able to apply the human element to our clients' problems, spending time thinking about a problem before we get to the ‘doing’ part of the problem. The software industry moves in leaps and bounds that progress much faster than many other industries.

Prepping a solid spec before each phase of a major project also means we’re becoming much more in line with the Agile methodology that we love to practice. Having a customer-focused development approach is important to initiate from the start. Since we’ve moved to this style of working, we’ve been able to bring our clients into our Jira environments, and deliver cycles of software faster, because everyone’s on the same page.

We will always have our development team, who bring an important skill set to the table, and continue to develop software that is readily available and meets the requirements of our clients each and every time. Our development team can now breathe easy, focusing on the work they are excellent at, and leave the communication to the trained professionals.