Fuckups and sustainability: how (not) to make mistakes?

Sustainability in project management

Our mission is to be the go-to partner for sustainable digitalisation. By that, each of the teams at Ackee can imagine something a little different. For example, developers look at sustainability as writing code in technologies that are currently rising in popularity but are already proven enough to know they will last. Designers, on the other hand, see it as a necessity to create a sufficiently robust and flexible design system in which the UI of the entire application can be designed, and where the individual components make sense individually and as a whole.

In the case of project management, I see sustainability as the ability to leverage knowledge and existing solutions or approaches from other projects, to minimize the amount of things that need to be redone (whatever the reason), and to make projects that can work in the long run. We don't want to just hand off projects and walk away from them, we want to stay with the products, continue to develop and maintain them.

How can we as designers influence this? For example, by motivating and directing the team to solve the problem in a way that meets the previous points as much as possible, or by discussing the need for change with the client and quite possibly coming to the conclusion together that it is not necessary. What helps us? Learning from previous mistakes - and not just our own.

Sharing culture

Everyone makes mistakes. And it's normal to make mistakes. What matters is what happens afterward. Because we should eliminate the number of them, and especially the repetition, as much as possible. That's why I try to foster a culture of sharing mistakes on projects so that we have the opportunity to learn about them with each other, discuss them in detail, and discuss different approaches and ideas on how to avoid them next time. Therefore, we have a 10-15 minute window at each team meeting called "Fuck-up academy" to remind ourselves of what went wrong in the last 14 days and to discuss it with others.

Besides mistakes, it is of course good to share successes, but I personally believe that fuckups are more valuable because they show how to get into and out of problems. Moreover, they also contain the part of the right solution and subsequent success. Just with more context.

But enough theory, now some practice. Let's take a look at a few fuckups that have happened to me over the last while.

Fuckup 1: Too friendly approach to exposed API for partners

Project context:

This fuckup concerns the BOX NOW project, which you can think of as a parcel service in Greece with box delivery. The process works by the customer making a purchase on the e-shop and choosing which box they want the goods delivered to when they pay. The e-shop creates the order via the partner API in the BOX NOW system and then the goods are delivered.

Problem description:

During the design of the partner API, we brainstormed with the client about what features partners might want and use. In addition to creating orders, it includes features such as:

• download available boxes for delivery
• generating and downloading a label for one or several packages
• retrieving the status of a shipment, or several shipments, including all sorts of filters and searches such as customer name, phone, email, or any text string appearing in the various items of the order, so that it is easy to find the order

We didn't foresee any major problems because the e-shops that will integrate with us will have their own quality IT department. Most of the bigger ones are basically IT companies. However, this assumption of ours melted away before our eyes as the number of partners grew. Integrations are often created in the simplest way possible, so most companies use just that general search, even though they know they are searching by phone number, for example, and that is computationally much more complex for our system.

And this is where the problem arises. It is almost impossible to force companies to fix the integrations because there are thousands of them and the system works from their point of view, so why change anything. But for the service, it means unnecessary extra resources spent on infrastructure and optimizing functions to be faster and not burden the system.

Lesson learned:

If we had been tougher in our service design from the start and not given companies features they don't really need but might like, we probably wouldn't have had to deal with this problem at all.

Another lesson I take away is to think ahead. What would happen to the system if features started to be used significantly more than we anticipated? And doesn't the feature bring risk rather than added value? These are good questions to ask in advance.

Fuckup 2: Changing brand identity

Context:

This fuckup involves a longer-term client for whom we are continuously developing a back office application, including a mobile app. At a time when all parts of the system were already in place, the client decided to rebrand and another agency was put in charge. Once that was completed, the new brand identity began to be applied to the systems we were creating.

Problem:

While implementing the new identity into the mobile app, we discovered that it contained a different font. This wouldn't have been such a problem, however, if the font wasn't paid for. After requesting the font from the client, we discovered that they were hearing the information about the font being paid for for the first time from us. Taking a closer look at the price of the font, we calculated that it could cost up to 1/4 million crowns for use in a mobile app. And that was not in the budget. But the new rebranding was already in process and it was not so easy to change everything again, because the cost could be even higher.

For the time being, we bought the font and applied it only to the necessary parts, which reduced the cost to 80 thousand crowns and in the future we will try to arrange custom pricing or switch to another, similar font.

Lessons learned:

The lesson for us is not to assume that the client has a license to all the resources they need, even if the identity was developed by a professional agency. On our end, check the font licenses for the different platforms and devices within the project we will be creating before starting the design. And to be especially careful about these things in case the project includes some things in the physical world. Because swapping might not be as easy as in the case of software.

Conclusion

If I keep my fuckups to myself and don't share them within the company and the team, it's more likely that someone will do them again. And we would be moving hard towards sustainable app development. Personally, I see it as far better to try to foster a culture of sharing within the team, to talk about what went wrong, and to improve together in project management. If you're interested in more fuckups, check out our blog for more insights, or other talks in our meetup series on sustainable digitalization.