It’s a common buzzword in the business world, plastered on websites, sales pitches, and company slogans: “creating value for the customer.” But for Codrin Băleanu, Engineering Lead at Levi9, it’s more than just a phrase. It’s a tangible story that happened just a few weeks ago.
When Codrin began working with a new client, he learned that they had a frustrating history of switching development teams. In conversations with the client, Codrin picked up on their repeated complaint: they felt out of the loop. Previous developers had failed to communicate with the client about their work. “The client would simply see chunks of code, without the team explaining the background. A lot of it seemed duplicated.” Codrin quickly realized that this client valued communication and made sure to keep in touch with them, providing some quick wins and updating them on developer’s work. The result? “We just got the green light to increase our team with one more full-time developer, in the span of just a couple of weeks.”
For this particular Levi9 client, “value” meant communication and Codrin Băleanu made sure to deliver that, on top of the features built by Levi9. He recalled this story at Levi9’s Customer Week, during a discussion about how to deliver more value for customers. Guided by Andrei Postolache, Leadership Consultant, our colleagues Codrin Băleanu and Radu Mihai Ciocan had an open discussion about value, what it means to Levi9, our projects, and our customers.
Clients and developers have different values
When it comes to providing value to consumers, developers play a critical role. However, as Radu and Codrin explain, it is crucial to recognize that value may be a complicated and subtle term. “Value has different forms,” says our Senior Delivery Manager, Radu Ciocan. “But it’s not always obvious — it needs to be discovered,” he adds. This implies that rather than assuming they know, developers must take the time to discover what is valuable to their consumers and their business.
One significant difficulty is that engineers sometimes have a different view on value than consumers or the company. “Most of the time, we as engineers value things on a different scale than our clients or the company,” says Codrin. Once they are aware of this gap, they should take the time to learn more about the project, what the company’s goals are, and what KPIs the clients are looking at.
When providing value, you create a win-win situation for everyone. This is how Codrin summarizes it: “Good feedback, good delivery, happy customers, and happy developers.” But sometimes, trade-offs are needed.
Speed or quality?
Delivering value to customers can mean prioritizing either speed or quality, depending on the project at hand. Andrei Postolache uses an example from computer history to make this point: “Back in 1995, Microsoft and IBM were both working on the perfect operating system called OS Two. They were very busy building the perfect operating system. And then Microsoft came out, with Windows 95. It did not have the best quality, technically speaking, and it was barely running, but it captured the market and that was that.”
“Sometimes speed is important, sometimes quality is important,” explains Andrei, adding that it all comes down to having a good relationship with the customer and understanding their needs.
“During COVID, you wanted to have something online as fast as possible. It doesn’t matter if it’s not working perfectly,” continues Radu. Ultimately, it’s not about delivering value but delivering the right one, which means prioritizing speed, quality, or finding the right balance between the two.
However, sometimes there might be competing values and perspectives among various stakeholders within the same company. In this case, Codrin thinks developers must strive to understand each person’s vision, their “North Star,” and the reasoning behind their requests. This understanding is critical to being proactive in refinements and better aligning with the client’s needs. Moreover, Radu points out that it is also important to remember that behind every requirement lies a decision-making process, and sometimes the bigger picture might be lost when focusing on individual requests.
Clients are buying the privilege of not knowing what they want
Sometimes, clients might be indecisive and cannot articulate what they want. At the beginning of his career, Andrei was deeply frustrated with this type of customer. But he later realized that clients are not only buying the service, but they are also “buying the privilege of not having to know completely what they want.” When clients hire a professional, they expect them to provide guidance and expertise in their respective field, whether it’s painting walls or developing software. As Codrin emphasizes, customers are not paying to convince the developer that what they want is feasible or makes sense. They are paying for the service provider to help them figure it out and find a way forward.
But what if the opposite is true? If a client knows precisely what it wants? Codrin Băleanu remembers a case when he received a 500-page book detailing the specifications of a project. He recalls that it included everything, from table names to column sizes and data types for classes and interfaces. The issue was that by the time the team started implementing the project, new technologies had emerged. Codrin explained to the customer that “We can shave six months of development time just moving to this new client-side architecture.” However, it couldn’t be done because it wasn’t in the book.
All too often, specifications can be too detailed and the feedback cycles might be too long. In this case, Andrei’s advice is to open a conversation with the client and not look upon the specification book as a Bible.
Juniors, ask the stupid questions!
Radu stresses the importance of junior developers engaging in conversation, as it allows them to bring fresh insight and a new perspective to the table. He suggests they ask 150 questions, believing that at least 10 of them will be questions that no one else has thought of, demonstrating their value. “I’ve never heard anyone say That’s a really stupid question,” adds Radu.
Andrei agrees. He thinks that junior developers may be the perfect antidote to “groupthink” — a situation where everyone in a group does not ask an important question, assuming the rest of the people already know the answer. Andrei explains that sometimes a “stupid” question can bring clarity to a situation and prevent misunderstandings.
Show, don’t tell
Some years ago, Andrei Postolache spent an entire day working in the customer service of a UK-based company, listening in on complaints and help desk calls. He was a Delivery Unit Manager at the time. He decided to do this after receiving a confounding feedback from the client’s internal team, who complained that the website was not fast enough. As no amount of benchmark speed tests were relevant in convincing them otherwise, he preferred to see the reality on the ground. By spending a day with the client’s internal team, he found out that the customer service representatives were using the public-facing website as their own internal knowledge tool. They used to have a locally-hosted FoxPro application, which they could easily access using a one-hand keyboard only, as they were using the other to take notes during the client call. The new website required them to use a mouse. So for that particular team, everything had changed — an aspect that did not come through the numerous back-and-forth conversations with the client’s stakeholders.
As Andrei’s experience demonstrates, in order to deliver value for customers, it is crucial to “see” and understand the “why” behind their needs and preferences. Codrin resonates with this idea as well: “I hate doing something just because it has to be done. I need to understand the why.” By researching and asking questions, professionals can gain a deeper understanding of their clients’ needs and expectations.
Sometimes, discovering value for the customer is like a journey: you don’t know what you want, but you know when you see it. One of the ways of easily transitioning from an on-paper talk to concrete feedback is to keep an open line with the customer. Codrin advises, “Try to get feedback as soon as you have something working. It doesn’t have to be perfect.” He cautions against falling into the trap of not being transparent or waiting until the end of a sprint to showcase progress.
Open communication and dialogue with the client throughout the journey is key to ensure that value is being discovered and delivered effectively. In this way, both the client and the development team are engaged in the iterative value discovery process, working together to achieve the greater goal.
