Salv engineering key principles

I was asked recently what Salv’s “key principles” in engineering were. For starters, I thought: why are you asking me? Things like values, culture - these do not work like waterfall engineering - they come from the team. They are established by the people who live them every day. So, I shared this question with the team - we discussed, we debated.

As a young company and small engineering team, this remains a dynamic process - nothing is set in stone that can’t be challenged or improved (principle four). Plus we don’t like over-architecting at Salv (principle two). Still, this is what we came up with.

We solve real problems

I will write a separate blog about “mission” - so I won’t go into that here. But this is very important to us at Salv. We are on a mission to “beat financial crime”. This drives everything we as engineers build as well.

So what are “real problems”? Well straight away, we mean problems that:

a) have a real-world effect - like stopping a criminal network involved in human trafficking; or

b) that bring a real, tangible benefit to somebody - ie our customers.

Every engineer knows how to build. Every engineer knows how to problem solve. But not every engineer knows how to stay customer-focused. Which is the key to building and problem solving.

The problems we are solving are not easy, but all the more important. Why should we care? Because if we can dream it, we can do it. Besides, we have everything we need: an incredible team and a meaningful mission.

Has this solution brought the value the customer expected? Is the customer even 100% clear on what the best solutions for them might be? To answer questions like these, an engineer needs to work closely with customers.

As one of our team, Raido, explained previously - as an engineer you expect to learn new tools, new code - but when he joined Salv he needed to first learn about money laundering! Because that’s our customers’ biggest concern - and understanding their world is how you understand their problems. And that’s how you come up with the best solutions.

Build small, build fast

When you keep the customer close in your mind then the way you build, becomes a process of dialogue, not monologue. You can’t map out a grand masterpiece and then expect to be left alone to finish it.

Reality is much messier. And better outcomes are produced through consultation and cooperation. There’s no point laying the foundations for your perfect Alhambra, if it’s a) not what the customer actually wants; b) not what solves a real problem.

Instead, our team prefers to build small, build fast, and to constantly challenge ourselves and each other to improve. Of course, any project requires clear conceptualisation - this is a key stage of development. But we don’t fixate on the architecture, we focus on the iterations. The tiny, incremental improvements that move us towards better solutions.

There will always be differences between a customer and an engineer’s vision, so when you build small the feedback loops are faster and you minimise the risks of major misalignments. Like a long-distance runner, big strides might feel like bigger progress, but lots of tiny steps at a faster cadence ultimately lead to better outcomes.

No solo gunslingers

Some engineers like to imagine they’re the Clint Eastwood type. Men of few words, they do it “their way”, they keep themselves to themselves.

As you can already guess, it would be tough for this guy to thrive at Salv.

We prefer engineers who work together. Who know when they’re in a firefight that’s too hot for them and know when to ask for help.

Ego can be a good thing. Taking personal pride in your work and wanting to “crack” something yourself are good traits. But “going down shooting” helps nobody. And it’s a waste of the talent around you.

Each of our engineers has a different skill set, distinct background and experience. Taking time to cooperate doesn’t slow engineers down, it actually speeds them along.

Think of reading somebody else’s code as like a trip to the library. When you pick up a book, you encounter somebody else’s thoughts. You either think: wow - that’s amazing, I hadn’t thought of that - and the experience improves you. Or you think: this is pretty good, but there’s a way it could be even better, and then you help the other engineer grow.

There’s a place for the gunslinger. But if I learned anything from The Magnificent Seven, it’s that solo operators are a whole lot more impactful when they band together!

You own your work, failure belongs to the team

Ownership is a big word in engineering. In more traditional structures it’s very black and white. You got given a task, if it’s not done right - it’s your fault.

But as anyone will tell you in a startup environment, there are plenty of unknowns - the landscape is constantly shifting. What seemed a great idea a few months ago, suddenly won’t work. Or the goalposts have moved.

Taking ownership of your work is the bedrock of engineering - we don’t hire people who don’t take ownership. But if something goes wrong - who wins from assigning individual blame? If the engineer didn’t have enough time, could the team have supported? If there was a skillset failing, could somebody else have mentored?

At Salv - we’re big fans of blameless post-mortems. It’s not accepting excuses. It’s not sweeping problems under the carpet. It’s frankly acknowledging as a team that, collectively, we could have done things better. Which is a great learning.

There’s also another big part to ownership. In Company X you own your little piece of work. But who asks the big questions? Is it just the boss’s role? Or should anyone from the team be able to raise concerns, clarify a project’s direction at any stage along the way? Caring about the team’s output, not just your own coding: now that’s real ownership.

Freedom to learn

Because you own your work, you also have freedom when it comes to problem solving. Bring your own perspectives, your own code or languages - we’re not proscriptive.

Freedom also extends to your physical workspace. Your hours. Work from where you want, when you want. As long as you get it done. And that’s where the responsibility part of freedom comes in.

Underpinning everything we do at Salv is trust. Trust you’ll get your work done (or know when to call in the cavalry). Trust that the team has the customer strongly in mind as it builds, as well as the focus on delivering outcomes that solve real problems.

At Salv, we are building a culture of freedom and trust. The culture that helps you grow and develop your skills at the same speed as our startup grows and scales. We’re just entering the hyper growth phase where you’ll grow fastest.

But with a foundation of trust, we return again to freedom. At Salv we are trying to create a learning environment. An environment where you can raise questions, make suggestions - it doesn’t matter if you’ve been here two minutes or two years. Our team still has a flat structure. There is no “boss”, no senior engineers, no pecking order.

We trust each other to allow ourselves to grow. If you don’t take risks, you won’t ever face failures. But you’ll also never develop. And you’ll not solve the problems of tomorrow.

So that’s a glimpse into what drives our engineers at Salv!

If you’ve read this far, no doubt, there was something that you just couldn’t let go of. Something that kept you reading, transfixed. Was it our mission, or startup culture, or our engineering principles? Or maybe all of them together?

By now, you must be wondering how does this really work. That’s easy enough to find out. Get in touch with us, book a lunch with our engineers in Tallinn or Tartu. Let’s set up a short call, if that helps. If you can help us speed up our mission, we’d really like to get to know you.