How a developer’s work directly impacts the end user

A spending request takes on average 1 minute to be approved in Spendesk. It’s important that it’s fast, because each second counts when you’re waiting on funds to do your job. Most companies still don’t really get this.

At Spendesk, we’re building a platform to make spending company money easy, safe, and trackable. You spend the company’s money — not yours — and you don’t have to wait forever for delayed reimbursements.

As a developer, I build the tools that make this a reality. My role isn’t customer-facing per se, but my work is worthless if it doesn’t help our clients.

The goal of this article is to provide an insight into the relationship Spendesk engineers have with our customers, and how our daily work impacts them. And you might learn a few simple tips that will give your users a smoother experience with no coding at all!

I’ve broken these into three key ideas:

1. Impactful customer relationships

In most companies, software engineers may think their job is somehow removed from the end customer, compared to operational teams. You might start to believe that your actual impact on customers is low.

This may come from a few common factors, such as:

• Long development time: You work on a huge feature or project that might take months to be finished - “let’s rewrite project X,Y,Z.”
• Long release time: You did the work, but it will only be released later, when all the other pieces of the project fit together. Like an engineer at Apple whose work may only make it into customers’ hands with the latest iPhone or the new iOS version.
• Long feedback loops: You shipped, and customers are using it, but there is a lack of analytics in the product. You may only have positive or negative reviews as feedback.
• No relationship with what you build: Sometimes you build something that you can’t use yourself, you don’t know anyone that would, and you’re honestly not sure how it will be used in the wild.

Some developers prefer being removed from customers. I don’t.

I love my job because I build features that actually get used and have a positive net impact on other people’s daily lives. For Spendesk’s users, it’s their daily work life. This is why Spendesk fits me — our software saves a huge amount of time for our customers (up to 2 days per month for an accountant!). So my work is valuable and impactful.

One of our key operating principles is to always act in the best interest of our customers, which directly shapes how we imagine our product and how we make decisions. We’re crucial in some customers’ daily job (just like Github is key for software engineers). For this reason, they rely heavily on us and we can’t let them down. We must strive to make sure they have the best and most efficient experience with the platform.

And we actually use our own product. This helps us tremendously to understand our customers’ pains and problems, as well as feeling the significance of our work. We have colleagues praise us for solving a bug they encountered, or a new feature that saves them a lot of time. That’s very gratifying.

It also leads to quick improvements for pain points we encounter ourselves, and we’re encouraged to implement them. We receive frequent updates from product managers and our data team about product usage, plus direct feedback from customers. All of this helps to identify potential improvements.

Even the smallest improvement or quick-win can have a huge impact on the daily experience. Sending a mobile push notification when a new card payment is made — instead of an email — lets the user to snap a picture of the payment receipt very quickly. This one small change led to a big decrease in missing/lost receipts, and brought peace of mind to our users (no one wants to get into trouble over company money).

In the end, Spendesk improves the trust a company has in its employees, which ultimately leads to increased product usage within Spendesk. (Win/win.)

2. Planning for actual usage

Spendesk aims to strike the perfect balance between control over spending and trust in employees. Finance teams choose Spendesk because it helps them first, and then consider the time it saves for the rest of the company.

Put ultra-tight processes in place, and you risk employees not using the platform. So you end up wasting even more time than before, juggling multiple systems and processes.

Make the rules too lenient, and you run the risk of having a few bad apples not uploading receipts or adding mandatory information to payments, forcing you to chase receipts or info and lose tons of time in the process.

To solve this, we introduced a feature called Play By the Rules. Finance managers define how long you have to add all mandatory information and receipts, and how many late items you’re allowed before your Spendesk usage gets restricted.

Planning and developing this feature was no easy task. It impacted every part of our platform (Product, Design, Mobile, Web, Backend), and multiple teams. But the cornerstone to make this project succeed was our customers, and the fact we build the platform for them. Too restrictive or too fast, and you risk legit users getting blocked during their workflow and hindering any benefit the platform has for them. Too relaxed or too slow, and you risk some bad apples ignoring the system and the finance managers lose trust in Spendesk.

As a software engineer, my opinion is valued by peers, product managers, and designers. This is why I make sure to provide the most exhaustive feedback I can.

Here’s how I prepared and worked on this feature to make sure we were building what I thought was the right thing:

• Gather a list of all the user personas you will impact. Include the new user who never used the platform before, the power user who knows all its quirks, the “bad apple” persona you want gone, and the standard goodwill user that does their best to help the company.
  Review the proposed changes and make sure the impact will be correct for every persona: it isn’t a good idea to degrade the user experience for 80% of your user base to solve an issue caused by 0.4% of it.
• Will this make the product better for the user? You should always ask yourself this. And sometimes the answer might not be “yes,” so you’d better have a solid reason for it.
• An often forgotten topic is data and behavior migrations. What behavior should happen for data generated before the changes? Should the previous behavior apply? Should both of them cohabitate for a bit? More than a product question, it could be a technically critical one for engineers trying to architecture this feature.
• Identify edge cases as soon as possible. Quantify them and either solve them or provide a sane migration path for your users. A big one for us on this feature was: how should we handle payments and restrictions when the supplier (third party) is the one who hasn’t sent the receipt yet, or if they provide receipts in a delayed manner. (Some aggregate receipts monthly, for example).
  We can’t put the burden of the supplier behavior on the employee trying to do their work! A simple solution is to create a whitelist of suppliers we know have this kind of behavior, and create different rules for them.
• Find the regressions. What could your users do before, but won’t be able to after the changes? Was it expected? Make sure all teams are synced on this topic — there’s nothing worse than a feature not available anymore on a platform, but present somewhere else. Our customers rely on us as a work tool, and we can’t break or disable a feature even temporarily because we lacked foresight.
• During the design review and implementation phase, try to think about usability, accessibility and user-base diversity. Does the interface work well with bigger fonts for someone with eye issues, and is it simple enough for a brand new user? We want our product to look good, but more importantly, we want it to be usable as a work tool.
• Quality: Don’t settle for good enough. If you noticed a small bug during development but didn’t fix it, you can be sure a customer will notice it and their trust or opinion in your product may drop.

All those topics are really important to tackle if you want your work to have a positive impact on your customers. A new feature is like a house of cards: one missing or weak card, and everything can fall apart, even if the rest is perfect.

After a few months’ hard work, we shipped Play By the Rules in May 2020, and it’s currently one of the most successful and loved features Spendesk launched this year. I’m very proud to have contributed to it.

3. Codeless improvements

As software engineers, a big part of our job is to produce code, but not only. We can have an impact on customers’ daily experience without shipping new code at all.

Here are a few steps I’ve added to my daily routine:

• Checking mobile app performance and stability monitoring (crashes, errors, network calls success rates)
• Monitoring backend logs of mobile network calls: look closely at unexpected usage evolution and the volume of unexpected errors. Compare production and staging environment logs to see if new issues could have not been detected yet during the development of new features
• Read changelogs of new releases for other components of the platform (web frontend, backend, android app) to keep up to date with overall changes. An important change might go live without your team being aware.
• Once in a while, use the app or a feature as a normal or new user would do. It might be challenging for some products where you’re not a targeted user, but it can lead to the discovery that sometimes the burden of knowledge for using a feature becomes too high. This means new users don’t understand how to use it properly without external help from someone more experienced with the platform and its concepts.

Applying these tips will help you proactively prevent issues your customers might face, and will improve the experience they have with a product without producing a single line of code.

Overall, making a positive impact is what I’m looking for in my work. In a world where you might ask yourself if what you build is meaningful or useful to others, knowing that people depend on you every day can really brighten it.