Engineering Principles at Devengo

How does the Devengo engineering team choose a particular approach between multiple viable solutions?

Dec 14, 2023

In the last three years, we have developed a particular way to tackle the challenges we face developing Devengo’s technology and have synthesised them in a few principles aligned with the company’s values. I’d like to introduce these principles we use within the engineering team at Devengo as they provide daily inspiration and guidance for conducting the practice of software development at the company.

Why set up principles at all?

When setting up a company, there are always so many things to do that it is not strange to find many companies lacking the definition of their core commitments: mission, vision and values. These commitments are usually misunderstood as mostly aspirational, under the lens of “How I’d like my company to be (in an ideal world)?” or simply considered unimportant because they are not “the thing” we want to do.

However, the real goodness behind these concepts is that they can act as a beacon of light on the stormy waters of uncertainty. Every day, we are forced to make decisions in a frame of uncertainty where there are multiple valid choices. If there were always only one sane, logical way out of a problem, we would never need values because we would have our decisions made up for us.

Reality constantly demonstrates to us, though, that life is mostly grey, not black and white. What to do then? Well, the core commitments provide a solution to this conundrum: pick the option that best aligns with your values. When adequately framed, this problem-values-solution cycle will reinforce itself and will, over time, create a brand and a way to do things in a company.

But how does that apply to engineering? Well, those principles are nothing but the specialisation of the values to a particular area of the company, in our case, the organisation that develops Devengo’s technology. While values are high-level alignment, principles are function-specific interpretations of the values.

If principles are honest and aligned with the company’s values, they create a dev culture in the company that is, in my opinion, one of the most exceptional examples of intangible value and soft power in tech startups. They also create another virtuous cycle, where the company values promote the team principles and those, in return, when exercised, further fortify the values of the company.

For those reasons, identifying, synthesising, establishing and promoting those values is one of the main tasks for any CTO, and one I try to apply vehemently in all the companies I work for/with.

How to define good engineering principles

One of the main attributes that an engineering principle should have is that it is applicable, and for that reason, we apply those principles as often as possible to ensure we keep them honest and real and to reevaluate them if, at some point, they fail to stay that way.

Here are a few ways in which we apply those principles:

  • We include them in our hiring process so candidates know in advance if they will fit in Devengo.
  • We use them as a guide for designing features and subsystems (e.g. we exercise Finesse when working hard to improve fractions of a percentage point on behalf of our customers).
  • We leverage them to describe how a problem should be solved quickly.
  • We invoke them often in our daily work as part of everyday lingo to condense big thoughts on small interactions.

For each principle, we have not only a definition of how we interpret it but also what practices we introduce in our daily work that reflect it, what red flags indicate deviation from it and how to self-evaluate our work under its lens.

Our 6 Principles:

1. Finesse

Finesse is defined as “refinement and delicacy of performance, execution or artisanship”. We are aware that there is a non-negligible number of companies out there that can do what we do. So what makes us different? It’s how we do it, the finesse of our work, and the way everything is taken care of down to the smallest detail, with impressive thoroughness, effectiveness, and rigour. This is, of course, a transversal principle we can find in many crafts, but it’s especially observed in haute cuisine and gastronomy, a field I’ve always found profoundly mirroring software development, where the best chefs obsess about it and, in some cases, like Thomas Keller, make it their main motto.

Japanese also have the very closely connected concept of Kodawari (こだわり ). Working with Kodawari implies humble attention to detail, professional pride, and personal commitment to society. Kodawari is honesty in the process and satisfaction with the result. We stay faithful to the high standards we set for ourselves even if the customers may not be immediately aware of the extra lengths we would go to make our service as perfect as possible. We do kodawari anyway. We may sometimes talk in Slack about doing something just because it is Kodawari, and everybody can immediately appreciate what we are talking about.

Supporting practices

  • Continuous refinement of the DX
  • Failing gracefully on unexpected scenarios
  • Continuous improvement of features
  • Continuous learning
  • Expansive testing

Red flags

  • Quality defects reaching production.
  • Small known bugs are present for too long.
  • Unexpected collaterals.

Self-evaluation

  • Does this piece of work represent my best shot at the problem?
  • Have I thought deeply about the consequences of this implementation?
  • How can I make this better without making it more complex?

2. Zen Pragmatism

Buddhist monks and practitioners are instructed to ponder this question: “Since death alone is certain, and the time of death uncertain, what should I do?” There will always be infinite scenarios, features, projects, and ideas worth pursuing… and our resources, time, and energy to do it will inevitably be finite. It’s our task to deal with this fact gracefully and pragmatically.

This is one of the principles we use more often because, as a tech startup, we are constantly making tradeoffs between fast shipping, building quality foundations for the future, and the inherently uncertain nature of that future. Let me give an example. When Devengo was a player in the Salary Advance field, we had to integrate with our customers’ data pipelines. Some could provide real-time APIs, others would leave files on an S3 bucket we provided them… some could only let us connect to their FTP to read a CSV once per month!

To deal with all this complexity, we created some basic abstractions that will provide a staged common general flow (pre-process, process, post-process, etc.), but we firmly resisted the temptation of creating a whole system to meta-define pipelines and manage them with complex tools. A few months after our last extensive integration, we pivoted. Suddenly, all the work done in these integrations was thrown into the garbage bin! But by building just the right amount of software for the context and moment where we were, we saved hundreds of hours of development from being wasted.

Finding the right balance when making these tradeoffs is one of the hardest things in software development and one of the reasons why software economics is a topic that should be far more common in tech conferences.

Supporting practices

Red Flags

  • Projects agonising for months
  • Under-used, overly complex implementations
  • Premature optimisation
  • Yak-shaving

Self-evaluation

  • Is this the most cost-effective way to solve our problems?
  • Am I building the core part of the problem’s solution first?
  • Is the chosen approach reversible and flexible?

3. Do The Right Thing

Every time Devengo interacts with the world, we should hold ourselves to the highest standards. We will methodically destroy the expectation of “just another company” when it comes to candour. We will systematically demolish the idea of “but everybody does that” when the topic at hand is equity.

When all these things turn to dust, we will sweep them away and replace them with fairness and empathy. And our customers will never deserve or receive less help and understanding than our neighbours or friends. We will not always be able to say yes, but we will never fail to evaluate and lend a hand when possible.

This is another principle that we confront pretty frequently when developing software. There are always moments as developers where putting yourself in the customers’ shoes seems unnecessary or may look like it’s “a lot of work” just to cover some small edge case. We work hard at Devengo to always prioritise doing the right thing for our customers, even if that forces us to go the extra mile and invest more resources.

Supporting practices

  • Thinking like a customer
  • Cross-org transparency
  • Frequent interactions with support

Red flags

  • “Not my problem” mentality
  • Customers feeling unheard.
  • Slow reaction times.

Self-evaluation

  • Are we doing this just because it is easy?
  • Are we doing this just because “everybody does it”?
  • Is this the best thing for our customers?

4. Managers Of One

Devengo employs great people, and they deserve the freedom and autonomy to act on their own. We long for coworkers capable of holding on to their minds the idea that team-player and self-management are not antonyms. Don’t wait for permission, just state what you’re going to do, evaluate any given feedback from your perspective and expertise, and then do it.

We hire high-agency developers who can see a problem and have the resolution to determine how it should be handled and gather the resources needed to solve it. This means fewer meetings, less red-taping and less micro-management.

Supporting practices

  • Proof of Concept
  • Designs open to feedback
  • Developer-led initiatives
  • Praising dev success stories

Red flags

Self-evaluation

  • Do I have all the information to act on this?
  • If not, do I know how to get it?
  • Do I feel confident to commit to this solution?

5. Trust, But Verify

Or as they say in Russian: doveryay, no proveryay (доверяй, но проверяй ). Connected with the previous principle, we introduce this one. By empowering Managers Of One, we grant them the autonomy to make decisions and act independently. In turn, the verification process ensures that they demonstrate the competence necessary to handle the responsibility given to them.

The financial world is a sector where trust is everything. If our service fails to meet the high standards we have set up for ourselves, a few balances may be affected, but what is far more damaging is that the trust of our customers is eroded. With such high stakes at risk, we hammer this idea of “Trust, But Verify” into our developers’ minds. Far from being rooted in a lack of trust, it’s grounded in appreciating how critical our service is for our customers. With that spirit, we welcome many of the practices we embrace, like testing, double-checking, etc.

Supporting practices

Red flags

  • “No deploys on Friday” attitude
  • Manual processes
  • Siloed knowledge

Self-evaluation

  • Do I feel confident about this proposal?
  • Do I understand the ramifications of my work?
  • If this implementation fails, what is the worst-case scenario?

6. Taking Care Of Business

Popularised by Elvis in the sixties, this expression is usually defined as “To do whatever is necessary to resolve something, make progress, get by, cope with one’s circumstances, etc.” In our context, we insist on this principle to highlight how software development is -at least when executed professionally- a means to an end: articulating the company’s mission.

In software development, we have all crossed paths with people who have a purely technical view of their craft, wishing it could just happen in the void. You know the vibe: see sales as a team that does no real work, disregards customers’ feedback because it’s not a technical problem, and wants to create the most sophisticated architecture ever, even if it doesn’t fit the real needs of the company in its current form, etc.

We pride ourselves on understanding our craft as a people problem. We recognise that we are just one of the parts Devengo needs to succeed. Sometimes, that involves working in a field that may be slightly out of your comfort zone, hearing different perspectives and seeing the world through customers’ eyes… even if that doesn’t feel like “development”.

Supporting practices

  • Shared, cross-org language
  • Direct, frequent communication with OPS and customers
  • Everybody rotates to on-call
  • Prioritise boring technology
  • Provide tooling to other orgs. in Devengo
  • Buy vs Build evaluations

Red flags

Self-Evaluation

  • Is there a no-coding solution to this problem?
  • Do I understand the point of view of the other parties?
  • Can I serve the mission in other ways?

And that’s it! I hope these principles inspire other teams and companies to reflect on their daily practices and find their own ones.

Suscribe to our newsletter

Receive periodic updates on new posts and features and monthly release notes.