From Individual Teams to Competitive Engineering Organization - TrustYou

TrustYou is the largest feedback platform in the world. We analyze hundreds of millions of hotel reviews, we do it for more than half a million hotels, and we have tens of thousands of hotels using directly our platform as the company’s customers. We have achieved this without ever receiving considerable funding and although this is something that we are proud of, this has also affected our engineering journey in a way that, well, we are not always that happy about. To get where we are, there were often times when we had to cut corners to deliver our products faster than the competition.

Around the year 2016, our growth speed increased and within two years we have doubled the size of our engineering department. It became clear that we not only needed to make sure we follow industry best practices in our teams but we also needed to start paying our technical debt aggressively. After some easier or more difficult discussions, we got buy-in from the management, we got buy-in from our product team, and … nothing really changed, at least initially.

It turns out that introducing such a fundamental change like adjusting the balance between delivering new features and paying the technical debt cannot be achieved merely by hinting product owners and team leads. It turns out that there are engineering specific changes that require the whole organization to adapt. If you don’t explain top-down why we introduce the change, how the planning and prioritization rules change, there will be friction between departments that will either stop the change or will make parts of the organization inefficient.

In our case, I think, it was the pressure from sales and key account management that stopped us. There was always this next important customer whose new feature seemed to be more important than a technical improvement. You cannot blame these guys for that because their job is to sell and “refactoring of our data processing pipeline” will never ever sound more important than winning the next customer. And as mentioned above, we didn’t really try to explain to anyone what that thing about the technical debt was. We have spent quite a while turning circles in this dead-lock, experimented with different management techniques, e.g. enforcing technical debt dedicated capacity on a team level, trying things out with the dedicated task forces but in the end, a systematic and sustainable solution came from an unexpected direction.

In 2018, we decided to introduce OKRs to improve the visibility of our work and alignment between management and the teams. We defined technical improvement goals for every development team for an upcoming quarter but … we didn’t even get to the point where we reviewed the achievements, not mentioning defining the new goals for the next season. The same thing happened as before — we were so busy delivering new features and working around our technical problems, that we didn’t find time to start fixing them. From the perspective of time, I believe I can indicate pretty clearly the mistakes that we made back then:

• We didn’t go full in with the OKRs. We decided to cover only engineering topics with them and leave the product prioritization the way it was. And I think introducing the OKRs requires not only the alignment between product and engineering but it is also critical to make such a change visible to the whole organization.
• We didn’t define the consistent and iterative process for OKRs tracking and renewals. That’s true that our teams were busy delivering yet another feature but we didn’t really have a clear process telling us, e.g. that “this is a day when all the teams need to start drafting their OKRs for the next season”.
• We decided to introduce OKRs both for the teams and for individuals which seems to be too much to achieve in one go. I don’t think it was a killer for our change but it is always better to focus on one thing when introducing a deeper change in how your organization functions.

Looking back at this first attempt, I wouldn’t say though that it was lost work. People at TrustYou learned what OKRs were, the idea got instilled in our minds and we got the foundation for our later success.

Two years later, at the beginning of 2020, we were struggling with some other problem: we were discussing how to improve the visibility of our midterm plans to our engineers. It doesn’t sound like the main promise that you get from OKRs proponents, but yes, our thoughts went back again to quarterly goals-setting for our teams. This time we did a little bit better than before. We took some time to describe the process, from the very beginning we worked on this change together with our product team, we clearly explained the change to the whole organization.

We are now in the third iteration of our OKRs process and we still have a long way to go to stabilize and improve but this time, the attempt seems to have been successful. What did we change comparing to the first attempt? I have very shortly indicated this already above but let’s take a look closer at it:

• We decided to go all-in and cover both product and technical work with OKRs, giving this way a consistent set of priorities to our development teams. Honestly, this sounds now like the only way to go but we didn’t do it this way the first time so apparently you can go wrong about it.
• From the very beginning, we created a document describing how we understand OKRs at TrustYou and the actual procedure to set up and renew OKRs quarter by quarter. I admit that the first version of the document was not that great and we improved it a lot over this year but yes, having such a thing was the way to go.
• We invested more time in reading about OKRs, finding good resources, and sharing them with our engineers. Again, we started with a limited set of learning materials but we improved over subsequent iterations.
• We decided to keep it as light as possible. We understand that all the teams have their processes already in place so the OKRs needed to be organized as a thin layer above these processes giving focus points to the teams, affecting their priorities, but not affecting the way they have already worked.
• We decided not to introduce personal OKRs for our engineers. But we didn’t ban them — our team managers can phrase growth goals for their team members the way they like but personal OKRs were not our focus and we decided not to regulate this.
• We decided to apply the continuous process improvement principle. Every quarter we try to gather feedback about the OKRs process from all the team members using a dedicated survey, we analyze the results and discuss how we can adjust the process. This way we made the document describing the actual process clearer and simpler, and we are now experimenting with the coordination of the cross-team OKRs.

The most prominent effect of introducing OKRs is the improvement that we didn’t even think about when kicking things off and this is the improved steerability of our engineering department. Suddenly, it turned out that we have in our hands a single tool that makes it possible to pass both product and technical strategy directly to the teams, get feedback about the strategy from the teams, and coordinate cross-team efforts in the execution phase of OKRs.

As we became nicely steerable and transparent some things turned out to be easier than before. It didn’t really take us a lot until we decided to use our new weapon against our old good friend — the technical debt. We started asking all our development teams for technical debt related OKRs and suddenly we found ourselves in the third quarter in a row where all our engineering teams beautifully dedicate an important part of their capacity to clearly defined technical challenges.

Yes, sure, our codebase didn’t change that much yet but we are pretty early in the process. We still have sometimes and will probably have forever the heated discussions about priorities. But the strategy is transparent, the prioritization rules and plans are visible. Within minutes, everyone who is interested can understand how all the teams contribute to the strategy, and we are talking here about more than 10 software development teams.

On the other hand, we are not fully done with the process yet but actually, we never want to be, so let me explain shortly things that we are looking into these days and want to improve in the upcoming iterations:

• Helping the teams with defining cross-team OKRs. We originally assumed that the teams need to talk to each other to understand if they want to work together on shared goals or not. We learned over time that some kind of basic support in this area will be helpful.
• Helping the teams with the execution of cross-team OKRs. We are experimenting with a very light project management structure for such initiatives but it is supposed to work, again, as a super-thin layer above the processes that the teams already follow, completing these processes with cross-team communication and coordination instead of changing them.
• Last but not least, we need to improve how we define company goals that our engineering teams would be aligning with. We have had them already in the previous iterations but we need to look into it again as we learned from our quarterly survey that the direction was not clear so we either didn’t do it well with the communication or the actual goals were not phrased that well.

In the end, I am pretty much convinced that our case with two attempts of introducing OKRs makes our story a little bit more interesting because I believe we know pretty well why we failed in the first attempt and why we succeeded in the second one. Taking these into account, these would be the points that I suggest to keep in mind when introducing OKRs in your organization:

• Make sure that the OKRs process is the only mechanism defining priorities for your teams.
• Educate yourself and educate your people about what OKRs are. Prepare a presentation, collect resources, choose a book — whatever feels best in your organization.
• Prepare a document explaining how your organization understands OKRs and a document explaining step by step your process for the OKRs renewal process.
• Focus on repeatability in the first iterations. Sure, the OKRs are super important from the very beginning but repeatability is the key to your success.
• Make it transparent. Make sure that both OKRs and the actual achievements are visible to whoever is interested in them in your organization.
• Keep it light and make sure people know that you want it this way! As mentioned already earlier, the teams have already their processes in place, and adding heavy things on top will not win you your people for the idea.
• Think explicitly about how you want to address cross-team OKRs, detecting them, and then coordinating work on them.
• And last but least, necessarily introduce some kind of continuous process improvement mechanism, e.g. quarterly survey for bigger teams, retrospective sessions for smaller ones.

Summarizing, the OKRs may seem like yet another management buzzword but for us, at TrustYou it was a game-changer. We got improved steerability, improved transparency, and better horizontal and vertical alignment. Sounds great but well, keep also in mind that the OKRs are not a silver bullet. Your capacity will not magically increase, your priorities will not get magically resolved, your engineering challenges will still be on your engineers to solve. But I dare to say that there is some kind of magic touch that you get and this is increased motivation of your people who will be happier once they get all the good things that I indicated above. And I hope that with this article I am helping you bringing this tiny piece of magic to your organization too. Enjoy the ride!

For more behind-the-scenes insight into the TrustYou team projects, read this article on how we approach product development as users – and travellers – ourselves!