When people get paid to write software, we very often find some form of friction between the people that build the software and those that pay to have it built.

The company I joined three years ago was no exception. When I joined, they had just launched three months ago, weren’t seeing any return on investment and prospects weren’t too bright either.

I won’t lie, that first year was quite stressful. The business model sucked, the code was even worse. That first year, I wouldn’t have been too surprised if the whole team had been let go. In that situation, I could have played it safe, but to be fair, there was something quite exciting about actually having skin in the game and trying to make something out of nothing.

The best thing to come out of this situation, is that each and every engineer acquired a high sense of ownership. When you’re a team of only a few people, you have to carry your weight and make an impact. And the only impact that mattered was coming up with changes that would make customers return to us instead of to our competitors. A product without customers, isn’t a product at all.

Being extremely customer-focussed, we did set aside many of our own concerns. Both from a personal and technical perspective. We spent too much time at the office, putting in more hours than ideal. We were lucky to have a young team, that didn’t have a large day-to-day personal workload though. Since we were also the ones running the operational side of things in the early days, the tooling that was built covered the bare minimum, in a very crude way. On the technical side of things, we played the hand we were dealt. We tried not to make things worse - like treating a slowly healing wound. Improving things when constraints allowed it, still taking the rare short cut when our hand was forced. I still believe today that had we invested in the large technical overhaul the code base deserved - putting ourselves in a position where we would have shipped less features and changes - we would have found ourselves completely pushed out of the market and without a job six months later.

Once things started to turn around for the better, we acquired more and more return customers, but we also acquired a set of customers we didn’t anticipate.

When we were still small, we would handle customer tickets ourselves. The owners didn’t think the workload warranted another hire. After we threw away the homegrown, not very inviting to use, ticket system, we switched to an off-the-shelf live chat system. This gave us a lot more customer feedback - more than we could manage. Where tickets can be processed in batch, chats are expected to be replied to in real time. Nothing you can juggle in-between programming work, giving us a good reason to hire extra people. For these people to be productive, and actually able to help customers, they also needed access to those crude tools we built earlier. Turns out, those tools didn’t really cut it. We needed to listen to their feedback and work towards building tooling that’s obvious and easy to use. And there you have it, an extra type of “customer” we needed to satisfy.

But it didn’t stop right there. Like a scurry of squirrels after a bird feeder, there was more and more pressure from within the organization to provide more sophisticated tools for the expanding operational needs, like invoicing, content management, customer segmentation, localization and so much more.

So far, we had always put the end customer above all. We had always been very conservative with our technical budgets. We did refactor aggressively, but only changing the inside doesn’t always cut it. Larger structural, organizational changes require you to move mountains. Well, more like small hills. We knew the domain and its characteristics well enough to have a pretty good idea where we wanted to go, but the clock had always kept us from making big technical leaps forward.

One could ask: if we have been able to postpone these changes for so long, are they necessary at all? If you would ask non-technical stakeholders, they would probably prioritize the next “one more feature”. Hell, they would probably only start caring when the system comes down crashing every few days. Who we should really be asking however is those maintaining the system. If they feel as if they’re operating a system that’s headed toward needing life support, we should probably pay attention. Eventually something has to give. Eventually you might see your software become a serious liability, or you might see people jump ship even before the tipping point. Engineers are just as much of a customer as your end customer - code is a product too. Engineers also have certain needs you want to satisfy to turn them into happy return customers, who like spending their time, energy and creativity on your product.

It might sound backwards, but even the people you’re paying at the end of the month, are very much customers of your product. A monthly pay check might buy you a higher pain barrier, but it’s not unbounded either. You might even see some of the most passionate people succumb early on. People on the payroll are as much a vital part of the ecosystem as the end customer. If they don’t like being a customer, chances are, your end customer won’t either. Highly contagious. While the end customer is still King in this story, to build something truly sustainable for the future, you need to reckon with each and every entity that interacts with the software.