Some time ago, Gergely Orosz published the Pragmatic Engineer Test, a set of 12 questions to get a sense of what a tech company is like from the engineering culture perspective. It captures another angle or lens you can use when assessing a tech company as a potential employer. If I were a software engineer nowadays, I’d surely want to know how the company I’m about to join stands in this test. We participated in the survey, but it might be valuable to elaborate on our answers and give more details so that it is not just a single number. However, if you’re here just for the score, it’s 11/12. 🙂
1. Equity or profit-sharing: YES
All Mews employees, not just engineers, get depositary receipts (an equivalent of restricted stock units in NL, where our mother company is based). The amount depends on job grade; the employee doesn’t have to pay for it and receives additional when promoted. Our legal team Eldison also built an app where everyone can see the real-time estimate of their value based on company financial results.
2. Roadmap/backlog that engineers contribute to: YES
We maintain both product and technical roadmaps, items from both of them are subject to planning. Usually, the ratio of time we spend on those items is 2:1 (product vs technical). We have cross-functional teams, so engineers are also involved in the product discovery process, and product managers are involved in tech initiatives.
3. Engineers directly working with other ICs: YES
Our teams usually consist of engineers, a tech lead, a product manager, a product designer, a QA engineer and sometimes a data analyst or a product researcher. We aim for empowered, independent teams while minimizing dependencies on others.
4. Code reviews and testing: YES
Every change has to go through a 2-level code review process. Everyone can participate in the first round. The second round is the responsibility of a senior engineer who’s familiar with the affected area. Engineers are in charge of unit and integration tests, QA engineers own manual testing and automated end-to-end tests. Our philosophy is that everyone can challenge anyone else, no matter their job title or role. And it’s up to the author to either accept the feedback or refute it with arguments.
5. CI and engineers pushing to prod: YES
All changes are continuously integrated and deployed to the development environment. Although we have automated daily deployments to staging and production environments, we’re working on continuous delivery of every single pull request to production as soon as it’s merged. Deployments can also be triggered manually by some team members, simply by merging to the production branch.
6. Internal open source: YES
Engineers and other tech team members have access to all repositories and thus to the whole codebase. And they can open pull requests there if they like to.
7. Healthy oncall as a priority: NO
Our oncall is currently pretty simple, with tech leads being the primary recipients of PagerDuty alerts and escalation through directors up until the CTO (me). While there aren’t too many incidents, approximately one per team per 3 months, we want to improve this going forward. Mainly to ensure that the responsibility rotates and decrease mean time to recovery when an incident happens.
8. Technical managers: YES
Due to our fast growth, many managers were initially developers who demonstrated skills and passion for leadership. At the moment, all of our engineering managers have prior engineering experience. However, since this is one of the most complex career transitions, some people have struggled with it. That’s why we’re working on internal learning paths to aid with the transition.
9. Career ladder: YES
We’ve actually open-sourced our career framework. It serves not only our needs but also several other companies took inspiration from it.
10. Parallel IC & manager tracks: YES
We have two main career paths for engineering roles: technical (engineer, technical leader) and management/leadership (team lead, family lead, etc.). This applies to both product engineering and platform engineering divisions. Additionally, we’re planning to do something similar for other roles like data scientists or QA engineers when we reach that growth stage.
11. Feedback culture: YES
Continuous improvement is essential for us, so we gather feedback via multiple channels: OfficeVibe, annual 360s, internal surveys on various topics etc. Our performance review process is open-sourced as well. In addition, all platform teams maintain a ProductBoard portal with technical initiatives and process improvements, where team members can suggest new ideas.
12. Investing in professional growth: YES
Learning and knowledge sharing is embedded in our company values. For more junior members of the team, we offer PluralSight, Udemy and internal mentorship opportunities. For senior engineers and leads, we use Plato as a mentorship platform. Every function (backend, frontend, data, etc.) hosts bi-weekly meetings with presentations on their respective topics. Last but not least, people are allowed to expense their conference visits or book purchases and plan personal development tasks into regular sprints to protect time for that.
Future
Even though we tick 11 out of the 12 questions, that’s not the end of the story. When building the Mews engineering organization, we think of it as a product with all the engineers being the “customers”. And modern products are never done. We continuously improve them to address the current needs of the users. There should be a fast feedback loop allowing us to verify that the improvements are helpful. Product discovery should be running parallel to the delivery so that we invest in the most valuable things, etc. We try to apply the same principles when building our engineering organization, so I believe the answers presented above are not definitive. Hopefully, we’ll keep continuously improving all those areas in the years to come.
