Mews tech principles

In the year 2019, Mews tech team grew from 20 to 70 people. Leading such a big group of people (at least for me as a first time manager) brings lot of challenges, especially when the growth is as rapid as in our case. During this phase, I realized that we’re becoming a big unit within the company that could almost be considered a company on its own and therefore I started gathering resources on how to be a CEO. Of course my ambition isn’t to become one, but I find it really inspiring to dive deep in their responsibilities, goals, motivations, strategies and tactics. And learn from that.

I’m a programmer at heart and there it is very natural to look outside the box and apply principles from other programming languages or libraries into your ecosystem. The best example is evolution of programming languages where e.g. functional programming concepts are slowly creeping into all major “traditional” programming languages. So as a manager or team lead, I find it natural to look outside of the narrow bounds of your role. Think of yourself as a mini-CEO of a mini-company and try porting reasonable stuff which full-blown CEO does on the company level to your scope.

Some of the important things that every company should have are vision, mission and values. Those are especially important in times of growth when new people join because for them, it might not be clear where the company goes. Mews obviously has its vision, mission and values, but I realized that within tech team, similar level of clarity was lacking. So on top of company-wide principles, we, the tech department, introduced our own vision and principles more specific for us that we try to follow. Here they are.

Vision

Achieve technical excellence.

‌We want to build world class systems and applications, no matter the industry. We want to become one of the renown companies like Netflix, Uber, Twitter or StackOverflow when it comes to quality, architecture, performance, processes, user experience etc. Hospitality industry is the context for us where we are able to try achieving technical excellence. And it’s the context where we try enabling great service from the product perspective which is our company vision.

‌What we care about is contributing to and building something that other developers can look up to and say: “Wow, they’re really professionals, we should do it like them”. In longer run, that means we want to be thought leaders in several directions of software development. And it also requires everybody to constantly keep learning and pushing the technical and product boundaries further.

Minimalism

‌A line of code added now is a future liability. ‌That nicely summarizes our philosophy from the perspective of code. But it applies to other things as well, for example infrastructure. If a problem can be solved with no code, great! If there are two solutions, one taking 1000 lines of code, another one 100 lines of code, even if there is some qualitative advantage of the bigger one, try pushing for the smaller one. If there is a service that can accomplish what we need, consider using that over building the infrastructure in-house.

‌Time is the important resource, not money. Everything you add now will have to be maintained in the future, which will cost us time. That’s why we love pull requests that have more deletions than additions. And that’s why we love services like NewRelic, Sentry, Rapid7, SendGrid or PCI proxy. If the cost becomes an issue eventually, we can implement it in house. The important thing though is, that you push this decision to future, so that now we can fully focus on our product.

‌Check out Talking Architecture With Kevlin Henney which nicely elaborates on this topic.

Pragmatism

‌We understand that the world is not an ideal place and very often, there have to be compromises. That means we’ll sometimes do a hack or break some rule, but that should not be the standard, that should be an exception. But always, try to do it in a way, that it is a step towards the ideal solution, not step away from it. And ensure that it won’t close doors towards the ideal solution. We are also very pragmatic when it comes to processes, methodologies etc. We don’t do anything by the book, we rather inspire and adopt it to our purposes using common sense. Together with that, nothing is set in stone and it can change every day.

‌Good example is functional programming again. We’re huge fans of it, but we don’t go fully down the functional programming rabbit hole. We consciously choose limited subset of easy-to-understand principles that we adopt and reject some of the more complicated ones like abstractions from category theory. Functional programming design patterns by Scott Wlaschin is great introduction into FP while keeping it pragmatic.

Another example might be automation and especially overautomation. Do not automate everything by default, always start with manual procedures and only if it is not worth doing it manually anymore, automate it. But always have return on investment in mind, do not spend 2 days automating a process, that takes 10 minutes once a month.

Improvement

‌Always strive for continuous improvement of whatever you do or whatever others do. Do not be afraid to challenge anybody, provide feedback, even outside of our department. If a random person from the company comes and comments e.g. on your code, it is completely valid. You, as an expert should either be able to argument against it or accept it if the feedback is valid. By this logic, it is completely fine to challenge other people in tech, challenge designers, product managers, commercial, operations, anybody. They should either refute your feedback with arguments (based on their expertise) or accept it.

‌Sometimes it is not easy to accept the feedback, especially when it’s soon after you produced the “best code of your life”. Everybody has been there, the easiest solution is to sleep on it for a while and then the feedback suddenly makes sense and you can take something from it.

‌Our focus on improvement is reflected in some of the processes and principles:

• ‌Postmortems ensure that we always learn from our mistakes. We do them formally for big problems, but you can do similar thing in your head for smaller problems that you encounter.
• Code reviews are integral part of development process and have same importance as coding itself. Providing feedback promptly is crucial, so rather pause your long ongoing task.
• Refactoring is again really important, always try to leave the code that you touch or modify in better state than you’ve found it in. This is nicely summarized in https://deviq.com/boy-scout-rule/. Keep in mind that technically, unless it’s very small improvement, rather split it into separate pull request.

Responsibility

‌We treat everybody as responsible adult by default. We don’t want to micromanage anybody and if you are a people-manager, we don’t want you to spend your time micromanaging others, chasing other people to finish something etc. We believe your time is much more valuable and it shouldn’t be wasted on things like this.

‌So if there is an agreement or a request, we expect you’ll deliver it on your own, without anyone else needed. If you don’t understand it, ask, do not ignore it. If you do not like it, challenge it, we’re happy to hear any feedback or suggestion for improvement.

However responsibility does not mean being dry and grumpy. Nature of our work does not require us to be extremely serious all the time, most of us do our work for fun, so having fun is part of it.

This article was originally published on the MewsDevs blog, in December 2019.