DEV Community: Monta Engineering

Engineering Culture at Monta

Christian Weinberger — Wed, 26 Apr 2023 13:24:43 +0000

At Monta, 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" test posted on The Pragmatic Engineer, written by Gergely Orosz.

✅ 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.

✅ 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.

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.

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.

✅ 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.

✅ 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.

✅ 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.

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)

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.

References

My TOP 23 tips for engineers

Christian Weinberger — Thu, 02 Mar 2023 08:02:56 +0000

Find below my personal and subjective (!) tips for engineers - regardless of their level of “seniority”💡 (unordered)

🎙️ Expectation management is key to success. It’s totally fine to deliver late. But make sure to inform stakeholders on a regular basis and not the day of delivery. Come up with workarounds (reduced feature set etc) and be solution oriented.

💭 Think before you build. Create diagrams, notes or tests before diving into implementation. This helps you to understand the full magnitude of a feature and identify potential edge cases early.

❤️ Do what you love, love what you do. Solving puzzles can be tough sometimes (as any other job); if you like doing it, it makes your life a lot easier. Also make sure that you have a healthy out-of-work life and spend time with family, friends and your side projects.

🧹 Leave the world (code) a better place. No need to refactor all at once. Fix code smells, add missing tests or documentation and refactor that tiny part that you are working on. The next engineer will be happy to continue from there.

😎 Be pragmatic, not dogmatic. Most of the times you’ll get to 90% of the result with 20% of the efforts. Consider if the last 10% of automation, features, etc are worth the efforts.

👑 Prioritization is king (queen). A task is never equally important to another one. Make sure to prioritize accordingly. If you are lacking information to do this, involve your manager and make your problem their problem. You only can do so much on a day so make sure you’re doing the important things first.

👥 Reviews are not just a formality. Review each others code and thoughts regularly and provide meaningful feedback. Nitpicky and code style comments are OK but don’t lose the big picture over it. Having a passing test doesn’t mean the solution is correct. Fact-check the test to ensure it’s validating the right thing.

💬 Communicate. Whether it is with clients or colleagues, communication is key. Talk with your team, share your intentions, ask questions, offer up solutions when asked for help, say when you don’t know the answer and say “thank you “.
(Guest-tip from Heidi Puk Hermann Schwartz)

👻 Be visible. I know, some are more introvert or extrovert than others. Try to take part in discussions (can be written as well) to make your opinion count. A nice little hack is also to do a written summary of what you did today (post-day daily) in slack. This will give you visibility within your team and company, create some structure for yourself and serve you as a summary for the next mornings’ standup.

🤖 Automate as much as possible to get rid of repetitive tasks (also: be pragmatic about it). If something requires your action multiple times a week try to automate it. Build tools to enable others, non-engineers, to configure your solutions (eg Admin Panel or similar). This allows you to focus on your work while product managers or others can react to configuration changes.

📚 Keep learning. Follow blogs, read books or discuss different approaches and extend your knowledge with new techniques. You don’t need to „use“ it right away, but knowing various approaches will help you to put anything you build into perspective. But watch out that you don’t fall for hype-driven development scheme. There’s no silver bullet out there.

👩🏫 Onboarding is super important. Try to join your company for an onboarding week in their headquarter. It’s not only about getting onboarded to tech stack and engineering practices. The magic happens when you get in touch with all people from various departments and a motivational and visionary onboarding from the founders. This gives you insights into their daily work and struggles as well as the big picture for the company and it’s mission. That’s why we do this a full week every month at Monta.

☎️ If there is a significant imbalance between people joining a meeting on-site vs remote, make sure to treat remote people as first-class citizens. If you are sitting in a meeting room use best-in-class microphone and camera to make the experience seamless. My favorite “hack” to make everyone feel included is to join meetings individually - instead of sitting in a meeting room, just dial in separately so everyone is participating “remote”.

🏋️ Find perk equivalents in other countries you’re operating in. Headquarter has a nice gym in their building that can be used by employees? Give your remote people access to Urban Sports Club or similar. Also bring people together as often as possible (and reasonable). For important kick offs, off-site days, company trips and engineering workshops. Being able to putting a person behind a slack avatar can make a hell of a difference for productivity and communication.

✅ Write reasonable tests and make them part of your routine. This will not only give you some extra assurance but also force you to craft code that can be abstracted and tested. You’ll learn how to deal with mocks, interfaces and repositories and your code will get more maintainable and extendable. Don’t aim for 100% coverage unless it is a super business critical service, but do the tests that make sense. Isn’t it satisfactory to see the green check marks after running them?

📝 Structure your pull requests using pull request templates. Add some hygiene check marks as a reminder for any created PR, eg:

Did you add tests?
Did you update relevant documentation and api specs?
What kind of change is this? (breaking change, bug fix, new feature, …)
Reference to ticket system etc.

GitHub’s pull request template is easy to set up and you’ll get confronted with these questions / reminders for every PR you create. They also serve as a todo list for the reviewer.

📊 Add monitoring and alerts to your services. It’s super easy to write prometheus metrics which can be visualized by grafana or similar. Super useful to get insights into server and service metrics and KPIs or to visualize potential errors. Example: in our data forecast service we track how much data ahead we have (eg 33 hours) and send alerts when we reach the minimum threshold (eg 12 hours). This allows us to act before missing data becomes a problem for consuming services.

💚 Be a role model for our society. Odds are that you earn more in engineering than the average person out there. Use that luxury of not needing to think what to buy from the supermarket to do the right things. Donations are nice, but there are other things too that have a huge impact:

Volunteer to help at school of your kids
Study reasons and benefits of the vegan movement and eventually apply this to your life style to safe animals, the planet or just eat and life healthier
Support people that haven’t had the luck or prerequisites that you had; help serving food to people in need or check out what you can do within your community / neighborhood
Mentor people from underrepresented groups

You’ll be excited and surprised how much you can contribute and how fulfilling it is. 🤩

💼 Think twice before pursuing this new fancy “head of”, “engineering manager” or “tech lead” position. There are so many different tracks in engineering (individual contributor, tech advocate, people management) - finding the one that suits you best should be your priority over hunting a career path or title that might not make your happy. Also salary wise you can stay out of people management or lead positions and get a great result. At Monta we created a career and salary framework that treats individual contributors on par with manager tracks.

👩‍🔬 Add some extra juice when programming commands, jobs or migrations. Especially if they are irreversible or have huge impact (eg sending out emails) make sure to add flags to simulate the output. This takes away the fear from running these and makes your live easier when you’ve to apply updates at some point in time. I also encourage you to add logs and relevant statistics to them, eg number of changed entities, number of skipped entities or failed entities.

🏗️ Your Dev Ops and infrastructure team is always under heavy demand. To mitigate, you can do a couple of things, just as Jonas Hermann Schwartz did at Monta:

Educate the team on infrastructure and tooling
Make use of IaC (Infrastructure as Code) and give developers access to it via GitHub / Pull requests
Have a dedicated support channel to avoid ad-hoc requests in DMs or all over the place
Build tools that allow developers to change simple things (like environment variables) or run commands

🗣️ Provide feedback - and this goes both ways: make sure to give immediate feedback to your managers and team members. No need wait for the next feedback meeting, bring it up with context when it happens. Of course this requires a good feedback culture, but you are part of this :). Take feedback in, don’t be defensive but constructive and use it to improve yourself, processes or the company.

🤗 Soft skills are important! Continue improving them continuously and never stop. This includes communication skills - how you talk with other people, colleagues or customers or how you convey information within the team - but also many other skills such as time management, problem-solving skills, reliability and so on.