Coding for impact

Software development can get dreary if you’re 17 layers deep in an organisational chart, toiling away in the office basement to complete projects with no clue whether the outside world is ever going to know about your work. How can you tell you’re making an impact as a software developer?

The business

With some of our projects, our coworkers are our customers. That means that we can collaborate directly on deciding exactly what problems to address, explore different ways to solve them, and check the outcomes together.

Over time, we’ve gotten better at this type of collaboration. Before, we would do our best to implement what we thought was a great idea — only to sometimes get lukewarm reactions from our coworkers once we had our big “ta-dah!” moment at the end of the project. These days, you’ll often find developers with compliance officers and underwriters and sales staff behind whiteboards, busy with coloured markers and post-it notes. We get our first release in the first or second week of the project, and then iterate from there.

It’s asking quite a bit from both our developers and our coworkers. We need to learn to speak each others’ languages and really understand what’s going on. But there’s no talk of development teams and “the business” — we’re all “the business”.

Driving work with customers

Although some projects are purely for internal customers only, many directly affect Floryn’s own customers. We want to help them as much as we can, within the time we have. That means we need to understand what our customers want and need.

First, our relationship management team is invaluable in that regard. In their continued contact with customers they hear a lot of feedback, which they relay back to developers. That includes both complaints about something being confusing, but also appreciation for a delightful experience.

Second, we also measure how our product is used. By analysing user activity and conducting experiments, we can test our ideas and adjust course accordingly.

Third, for some projects we use a beta-testing period with selected customers. Sometimes we shadow-launch new functionality to a limited set of customers to collect feedback; other times, we explicitly invite customers to test new features with us — which most are more than happy to do. A notable example is the Floryn mobile app. During its development we invited customers to give our new app a try before launching it publicly and let us know their thoughts — and that helped us catch some issues.

And when we designed the financial dashboard feature, we set up a video call to hear from customers directly, and observe them using our product. From such direct conversations we learned things we could not have easily learned from measurements or second-hand reports alone.

Some manual labour required

Hearing from customers how they’re experiencing the products we have built is one thing. But sometimes, we drive new features before we implement all the automation required. That means rolling up your sleeves and going through some manual steps yourself in order to help the customer.

It’s a great learning experience to use your own product like your customers do. It helps you discover minor annoyances and interesting opportunities for improvement that you would never have realised had you merely looked at numbers and customers’ own stories. And in terms of designing the next feature to build, nothing beats some elbow grease to understand exactly what problem we’re solving and how best to approach that.

Get started

If you want to reduce the gap between your code and the end customer, there are a few steps that can help get you started:

1. Set up a chat with coworkers who are in direct contact with customers, and ask them about what they hear from customers. They will most likely be happy to tell you.
2. When starting new projects, reserve some time to discuss what all the different stakeholders hope to get from the project, and how they will tell it was a success. Even if you cannot accomodate everyone and everything, the shared understanding that is created this way is helpful.
3. Together with your team, design a feedback strategy up front. Discuss what kind of feedback your project needs, how you would come by it, and what technical changes will be required. This could range from extra logging to user mouse tracking to customer interviews.

Challenge accepted

The life of a software developer involves a bunch more activities than writing code. We share the responsibilities for project management, product design, and, ultimately, customer success across the team. That means that sometimes, you spend several days in a row with headphones on writing the perfect bit of code. But sometimes, it’s analysis, video interviews and whiteboards session. That’s asking a lot. But you get to make a real impact. And that’s the kind of challenge we need to find meaning in our work as software engineers.