Engineering Culture at Monta
Tags: engineering, culture, pragmaticengineer
Published: 2023-04-26 13:24:43

At [Monta](https://www.monta.com), we **value a healthy engineering culture**. Therefore we invest a lot in driving the engineering experience and improving the engineering org - since day 1.

In this post I want to share with you how we work and what you can expect when working at Monta. I'm using this amazing "[12 Questions on Engineering Culture](https://blog.pragmaticengineer.com/pragmatic-engineer-test/)" test posted on **The Pragmatic Engineer**, written by [Gergely Orosz](http://www.linkedin.com/in/gergelyorosz).

## ✅ Equity or profit sharing

At Monta everyone who is joining the company will receive warrants. It's built into our engineering and salary framework and part of "the package". From what we know (e.g. from investors) our packages are ~5x more attractive than what other companies at our size and scale are usually giving.

We are also super transparent: you can track your vested warrants as well as their value at any point in time using [Ledgy](https://ledgy.com).

![Ledgy Dashboard](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mtinnwxhr4q89k92qdk6.png)

## ✅ Roadmap/backlog that engineers contribute to

We are running a Product & Engineering department, split up into several divisions and squads. Within each division, our teams are responsible for their roadmaps and contributions - the same is true for our teams. The teams are run by a Product Manager and an Engineering Manager to ensure that both, Product and Engineering, has a voice when it comes to roadmap planning and prioritization.

## ✅ Engineers directly working with other ICs

Although we have created some structure within Product & Engineering our teams consists of Monteers from all disciplines: Product, QA, Frontend, Backend, UX, Design, Devops, what-not.

![Product & Engineering Org](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/voiebfandvbwalds2zvd.png)

We not only encourage direct communication within the teams and divisions but also direct cross-division communication. Introducing critical paths or bottleneck is in nobody's interest.

## ✅ Code reviews and testing

Yes, we do! It's baked into our CI/CD pipeline and in general no code is going into an integration branch before a code owner has approved it.

![Code Review Process](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4sri7myw88dbfy814j9d.png)

When it comes to testing we are following a pragmatic approach: the more serious it gets, the more test coverage we expect. But we are not religious about numbers: we want good quality and relevant tests, not a meaningless number.

![Pragmatic Approach to Testing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tlzj0vys9tb9jr6wr6pl.png)

## ✅ CI and engineers pushing to prod

We are using automated checks (via GitHub Actions) and deploys. Deployments to Development and Staging happen automatically after the respective integration branch has been updated. Deploying to Production involves going into ArgoCD and hitting a button - just as an extra layer of control.

![ArgoCD](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9e5syalzbqxct6mddk9x.png)

## ✅ Internal open source

All our private GitHub repositories are available to the Product & Engineering org. Any engineer can go in and create a PR.

## ✅ Healthy oncall as a priority

Certain teams (e.g. SRE/DevOps) have on-call schedules. Otherwise we don't have them per-se. However, we expect from our engineers to take ownership of their services. This means if something goes south, go in and fix it. At the same time they are the ones judging when a service goes to production. Of course if it happens off-hours we are happy to give this time back.

When it comes to general support we account for it by estimating ~25% of our efforts being dedicated to support-related issues (bug-fixes, improvements, refactorings). Before a developer has to deal with a support ticket it gets properly reviewed and prioritized so they know if they need to jump on it *right now* or it can be done during this or next cycle.

## ✅ Technical managers

We want managers to know what they are talking about. Any engineer in our org has an Engineering Manager to talk to. And we also expect from our Engineering Managers to keep up with the trends and spend 30-60% on actively contributing to our code bases.

## ✅ Career ladder (when above 10 engineers)

We have defined a career ladder with all kind of information around requirements, code % and progression (and salary) for our IC and management tracks.

![Career ladder](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c5fgm407m12ugdy00j9h.png)

## ✅ Parallel IC & manager tracks (when above 30 engineers)

At Monta we find it important to offer equal career opportunities for both, IC and management track. We don't want to incentivize becoming a manager if that's not what you really want to do - mostly to avoid [The Peter Principle](https://en.wikipedia.org/wiki/Peter_principle).

![Parallel tracks for IC/Management](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rvibff8139ngpe9mqg5n.png)

Both tracks are also on the same salary band. So it doesn't matter if you aim for becoming Senior II or Engineering Manager.

## ✅ Feedback culture

Feedback is super important for personal and professional growth. While we have formalized feedback sessions (Annual Performance Meeting) we encourage everyone to provide feedback immediately or in the weeklies.

Additionally we collect company-wide feedback using CultureAmp - monthly surveys touching on Happyness, Values, Culture as well as Diversity.

## ✅ Investing in professional growth

We started several initiatives to ensure everyone is able to grow and develop:

- An excessive onboarding week where new-joiners are taken through all our departments
- A mentor/buddy program, to especially help new-joiners within their first 6 months
- A dedicated education budget which can be spend on conferences, trainings, books, language classes, you-name-it
- Friday Tech Innovation - an initiative to foster innovation, giving an opportunity to break out of your project or implement something you think is great for the company (or just a coffee machine automation)

![Friday Innovation Time](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ypn8wo6y9etij5mfwc1f.png)

## Conclusion

I hope that gives you some valuable insights into how we work at Monta. Despite being only a little more than 2 years old we are a tech-driven company led by experienced tech people.

If you are interesting in working with us, check out our open positions at [Monta](https://monta.com/uk/careers/engineering/).

## References

- [The Pragmatic Engineer Test: 12 Questions on Engineering Culture](https://blog.pragmaticengineer.com/pragmatic-engineer-test/)
- [A Software Engineering Culture Test](https://blog.pragmaticengineer.com/the-developer-culture-test/)