LeanIX Engineering Values

Why?

When we started our journey over 10 years ago LeanIX Product Engineering was one person: Our co-founder André. Five years later all of engineering fit into a medium-sized office space and we could directly talk to each other. Another five years later, which is more or less today, our Product Engineering grew to more than 120 engineers spread across the world with engineers working both on-site and remotely. One year ago we joined forces with Cleanshelf and their engineering team and we are glad to be joined by more talent every month.

Growing as an Engineering department has been an exciting and of course challenging journey. But we also believe that throughout this time we could maintain fundamental characteristics in the way we do things. Those things make our engineering lives rewarding and fun and they're also exciting to talk about in conversations with new talent, people we meet at meet-ups or conferences or when we talk about work with our friends and family.

So we set out to write down what we think we're doing really well, what makes us special among other teams, and maybe in some cases also write down what is important to us while we're trying to strive for excellence. Working towards them collaboratively exposed us to insightful discussions within the Engineering department. We also do not expect them to be carved into stone for all eternity. Values are a result of a group of people interacting with each other. Therefore they are subject to change with the people being part of our group. This is expected.

How do we use them?

The main purpose is to scale the mentality we have in engineering and help guide the teams with their decisions and showing the north star of where we want to go.

We use them in onboarding, to easily and quickly explain to new joiners what we're all about. Even before they join, we can already talk about the values during the interview process and discuss whether this organization is a good fit for them. And even before we get to the interviewing process if people can easily see what we're about and how we work it can attract some people, but of course detract others, so we have better chances of talking to the people that are excited to join.

Besides the whole hiring pipeline we use them to guide teams and individuals. Before we start planning a project, or a new team, or when a person needs to make a decision, the values should guide them taking the most optimal next step. For example, do I keep in mind when planning a feature what the actual outcome that we're trying to achieve is, or do I just focus that I'll somehow deliver that code in production? Is what I'm working on really the most important thing I could be working on right now? Etc..

For team organization, we can look at what we're striving towards and adjust - does my team really own what we build, do we control our destiny, are we keeping the quality high, if not we can start the discussion and start changing how we do things, we can keep the management honest and make sure we're aligned on how we want to work.

The values

These are the high level values we agreed on after thoughtful debates throughout all of engineering and we'll do a bit of a deep dive into each one of them to understand it better.

• Valuing customer outcomes over output
• Autonomous Product Teams
• Continuous Improvement
• Collaborative software development
• Craftsmanship

Valuing customer outcomes over output

The short of it is - if we didn't have our customers none of us would be here. Because we treated our customers well in the past we ended up as leaders on the Gartner's magic quadrant, we have industry-leading customer satisfaction, and a massive global conference where a long list of happy customers come up and present all the cool ways how they use our software! We definitely want to make sure we keep our focus squarely on them. These are the guidelines that we include along with the values that explain what we mean:

• Measuring the outcomes of our work keeps us focused on the right things
• We celebrate when the outcome is achieved
• Learn to say no and keep focus on only the important things
• Data driven decision making, always focused on the customers, understand what they are actually trying to solve, not just what they’re saying
• We’re building code for the customers, not ourselves
• Iterate as fast as possible to find the right solution. (go for small development cycles, high release automation, independence and low process overhead)
• Prioritize impact - a solution that will last a year, and be built in a week, is often better than a solution that will last three years and be built in a month

Autonomous product teams

The goal of every organization is of course to move as fast as possible, and we believe that as we scale we need to be really careful. We believe autonomous teams with a low number of dependencies that own what they build and can decide what they prioritize according to customer and internal needs should get us there. Here are more details:

• Cross functional teams that own what they build, with minimal dependencies on other teams
• We live by the “You build it, you run it” principle
• Teams have visibility and can make actions throughout the technical stack
• It’s OK to use the autonomy to take risks and try things out, experiment, but learn from the process
• We take advantage of the shared infrastructure when it makes sense

Continuous improvement

I believe this is one of the simplest, but also the most effective values that we have. The goal is simply to try and be better than you were. No matter where you're starting from, over time you should see massive improvement. The problem with continuous improvement is that you rarely see a huge jump forward, but it's an incremental process with small adjustments every week. So one of the most satisfying things for us is to go and look back at the retrospectives that we did a year ago, or two years, or 6 months and see what kinds of problems we were dealing with back then and then think about where we are now. Over time it's a huge difference, and sounds pretty much like a different team! Our guidelines should paint the picture:

• Improving our process, knowledge and framework every day
• Retrospectives to figure out how we can do better next time
• Not afraid to remove redundant meetings, and improve the processes we’re running
• Innovative: We do not shy away from the new but rather embrace the adventure
• Strong growth and learning plans for individuals
• Learning from released features
• Always welcome critical feedback
• Continuously improving towards our values

Collaborative software development

We saw some of our best ideas stem from talking through multiple potential solutions as a team, rehashing them, and challenging them. We saw that junior engineers soak up knowledge like sponges if they collaborate with more senior engineers, figured out that everyone can learn something from each other even if they collaborate just for a few hours, and we figured out working together is just a lot of fun! Internal learning sessions, workshops, pair programming, we saw amazing effects on our teams throughout the years. Collaboration is also so much more than just our internal teams, there is a whole network of engineers we want to help, grow and educate communities even outside of LeanIX:

• Do pair programming, share knowledge, grow together, keep the bus factor high, especially for remote work
• We take time to get to know each other and have fun together
• Open communication over private conversations
• Fix problems, even when they’re not yours - don’t stop at the boundary if you’re being blocked, you can unblock yourself - you should be empowered to do good
• Communicate early and often on the state of projects, personal progress, etc..
• Share our knowledge internally and externally
  • blogs, mentoring
  • talks at meet-ups, conferences
  • organizing meet-ups, conferences
• Give back to open source
• Be open to changes from others on your code
• We give honest constructive opinion to each other so we can grow

Craftsmanship

As engineers, we want to hone our craft, and like a professional athlete, we're interested in high performance and being proud of what we achieve. Most of us got into this profession not just because the market is good for engineers right now, but we felt the passion for engineering, building something from scratch, improving it, learning all the new paradigms, exploring what's possible with machines and pushing the envelope.

• Our work is not just checking off tickets but it is our passion
• Good scout rule - leave the code you touch in a better state than you found it
• We want to be proud of what we build
• We want to keep moving fast even with more code and a larger team
• Automate
• Code that is not used should not exist
• We want to have a high bar for quality but where it matters, not over optimizing
• We keep performance in mind
• We test our code
• User interfaces respect web accessibility guidelines
• Security is very important to us, if there’s a major security issue we drop everything and fix it.
• Implement as generic as necessary, but as specific as possible (KISS)
• You aren’t gonna need it (YAGNI)
• Don’t always go for DRY
• Buy rather than build - Don’t build your own things if they’re not in our core domain

Acknowledgements

These values are a result of an open conversation between all engineers and we'd like to thank everyone for their contributions and insightful conversations, it's just one more way how we live the "Collaborative software development" value.

Published by...

Jost Novljan

Visit author page

Basti Tee

Visit author page