Chasing deadlines: How to turn a crisis into a success 

Full-Stack JS developer, unfulfilled bus driver, bigos lover and father of 3 years old AI.

Authors:
Jana Kalfařová, Naomi Voet,  Daria Doronina, Václav Šír, Honza Hrubý, Users & Productivity teams. 

Discover how effective teamwork can leverage your project objectives. 

You have probably faced this situation before – someone from another team comes to you and asks the famous question: “Do you have some capacity?”. From that moment on, all the following answers define you and the environment you will work in. We (the Frontend Core team) have tackled bigger and smaller projects during our professional careers, and what differentiates Mews from our previous employers is an enthusiastic attitude that helps us successfully achieve our project goals, no matter what. So, let’s talk about the “Mews approach”

The case 

As you might have heard, Mews booked $185M for our SaaS (software as a service) hotel management platform last year. That means a lot of new responsibilities but also the chance to address a range of our customers’ requests. One of the most frequently asked-for features was the ability to quickly create a portfolio of hotels fully staffed with employees from the application dashboard (global view). Sounds funny, right? Not for our customers, who spent considerable time creating everything based on existing (and sometimes hidden) functionalities. 

Our data analysts calculated that, for a typical Mews client, the new feature would lead to approximately 1800 hours (!) of data upload time and 180k clicks saved when creating a new hotel portfolio. You see, it was definitely worth the effort. We called this feature Mews Multi Property (MMP), introducing it to multiple customers immediately after its release – and to great success! But it wasn’t all smooth sailing from the start.

The problem 

Usually, the three key ingredients for starting a project are scope, resources, and deadlines. In January 2023, we knew only one of them – the deadline, set at the end of June. We didn’t know what we would work on, the tools we would use, or the desired shape of the solution. 

Our introductory meeting with the team involved in the project didn’t bring much value to help us understand the project goals. There were a lot of questions, general and more detailed, which gave the impression that everything around this project was chaotic. We discovered many undefined areas and missing solutions that needed to be implemented to make it work, and no responsibilities had been shared across the teams yet. 

At this point, you may need to know something about the Mews Tech teams’ structure. We have multiple teams responsible for different areas of the product (users, reservations, payments, etc.). But as you might expect, some functionalities may have multiple owners within this structure. When it comes to creating new features, this complicates the entire process because any change demands the cooperation of several teams, each with its own priorities. When our team joined the project, it already had three other teams to sync with (product managers, frontend/backend developers, QA, etc.), and it was still not the end of the story as we needed to engage our designers. 

You can imagine the ridiculousness of this situation – about 20 (mostly) senior people realising the seriousness of the problem and facing potential defeat. But here at Mews, we don’t like to be defeated, so we decided to tackle the problem our way – at the end of the day, this is our shared responsibility. 

The key players 

If you were a chef at a restaurant and just found out you have an important guest tonight, you wouldn’t start with peeling potatoes but rather think about the menu, right? In our case, the roles of “chefs” were assigned to our Product and Engineering Directors, who, during the next two months: 

  • Clearly defined our technical environment with all known debts (awareness of potential problems streamlined the creation of the roadmap without bottlenecks).
  • Created a delivery plan (what must be done and what is nice to have for now, split into a measurable timeframe so we could track the progress).
  • Fairly and reasonably shared the responsibilities (so teams knew exactly what they were meant to be doing and were not exhausted or overwhelmed by tasks).

With a menu ready, we allocated our Product Designer as the chef’s assistant. This person became responsible for the ingredients – the shape of the solution. In the end, this role was a game-changer. Not only did they gather all the tools necessary for creating UX/UI mocks, but they also served as a hub for developers when it came to resolving user journey problems during development. It’s worth mentioning that a big part of being successful in this role requires a specific attitude, where key factors should be enthusiasm, willingness to help and proactivity. We’re lucky to have such people here at Mews. 

For making an unforgettable dinner, you will also need cooks. That’s where we (Developers, QA Engineers) can showcase our skills. We assembled a team with diverse experiences, which helped us create and smoothly check necessary code (we realised some time ago that having too many experts in the team does not necessarily mean your solution will be perfect). 

And finally, the Team Leads, who acted as our gatekeepers and cleared the whole foreground for development – isolating us from the outside so no one was allowed to contact us regarding other issues. We also knew they were our first point of contact for solving higher-level problems, saving time and allowing us to focus entirely on our part. 

With these characters in play and a set of simple actions, our work became much more manageable and, most of all, predictable, which is key to success. But time was running out; we only had three months left and still almost 0% progress in development. 

The solution 

If you made it this far, you’re probably still wondering what helped us achieve our goals. Let’s examine the things that worked for us during this three-month adventure. 

Solutioning freedom. MMP is not only meant to be a new feature but also a brand-new user experience (including new UI and redesigned UX based on our customers’ feedback). This allowed us to play more with the tools we usually use in the code base. We also decided to give a couple of new ideas a try and reduce our tech debt: 1) Implementing React Query on the front end, which helped systematize our fetch functionality and guard the code with proper typing, and 2) Upgrading the process of generating customer reports, which had been a bottleneck for months. 

Mission teams – less is more. As confirmed several years ago, smaller teams can be a much more effective solution for solving problems. We tried that in practice, and it worked really well. It’s worth mentioning that we don’t only have senior people in our teams, and we all have different backgrounds (check out our stories as well!). What makes our work even more interesting is when we can learn from each other. 

No to GitHub novels. It’s common practice to document your code-related thoughts in pull request comments. While it’s still valuable in many cases (it gives others an image of what has been modified and why), it might also be a waste of time when it comes to changes that are already known to the creator and reviewers. In our case, it was much faster to either discuss the change on Slack or have a quick call to solve any doubts. 

Shortening response times. This time, it wasn’t about accelerating APIs but enhancing internal communication. With a shared roadmap and tasks split between multiple team members (when someone’s work depends on others), it’s easy to create bottlenecks and delays. Communication between team members became one of our priorities, so we created multi-level channels (from individual discussions and small group channels to global team ones). This approach shortened the time for finding answers/getting help in particular cases as we didn’t unnecessarily spam main threads. 

Thinking beyond. One of Mews’s biggest strengths is its ability to attract highly motivated people who don’t just want to “do their job”. Thanks to the team’s commitment (especially our QA engineers), we could identify and patch important problems with UX flow before it was delivered to end customers. Figma. We used the well-known, interactive design platform as a UX/UI mock-up provider and, more importantly, as a communication platform. We found it incredibly helpful for collecting our ideas around user flows and as a “notification centre” for communicating the latest design changes. It is also dev-friendly – with the latest “Dev mode”, it can significantly shorten the time needed to create components.

Do you have some other tips on turning a crisis into a success?

Don’t keep us waiting! We’re all ears.

The outcomes 

What have we learned from our story?

  • DO NOT leave your colleagues without help. The golden rule of the special forces, “You don’t leave comrades on the battlefield”, fits here. So, treat the project as a common challenge. Not only does it help to complete tasks before the deadline, but possibly more importantly, it helps the company build a sense of confidence between teams – and that’s the base for creating a healthy company culture. 
  • Treat crisis as an opportunity. This attitude can turn the tide of your project as it stops blocking you from making important (sometimes hard) decisions. On the other hand, there’s always something new to learn from such cases (new technology, new approaches, new colleagues, etc.). Even this blog post can be a great example! Eventually, it will make you feel that you do your work because you want to and not because someone told you to. 
  • Create communication channels. The faster you can get the necessary information, the better your solution will be. Implementing this simple rule is one of the most common problems when running projects, as it usually contradicts a company’s internal processes. But if you break existing schemes, properly share responsibilities and let people do their job, you will be surprised just how effective cooperation can be. We were working individually, in pairs, and ad-hoc sub-teams. It was always a great experience, as we were free to choose communication tools and ways of collaborating. 
  • Use tools that boost productivity. There’s no golden set of tools/software/rules that can give you an advantage in managing projects, but these kinds of projects are a great opportunity to experiment in that field. One of our most useful discoveries is Figma, which provides a great combination of design tooling, communication channel features and dev add-ons. We also love using Slack or Guru as knowledge-sharing platforms. 
  • Know the complexity of the change. A common mistake when preparing new concepts is that the people responsible for a product don’t know how much effort it takes to make the change on an infrastructure level. This becomes even more important in the context of financial/time estimates for the change. 
  • Redefine your goals. When creating new teams around a problem, remember to redefine the context of the change, as it won’t be familiar to everyone. Describing the background, goals, and timeline again is good practice. 
  • Focus on the intro meeting. Collect as much valuable data as possible but present it in a condensed manner (too many details at the beginning only make a mess when it comes to understanding the core of the problem). 
  • Don’t overlook your people resources. Having too few staff (even if it’s very ambitious) for a short-deadline project will cost you more than finding help before beginning. 
  • Constantly check your progress. Don’t wait for retrospectives and check the current stage of your project continuously (even at intervals of 2-3 days is adequate) – the sooner you reveal bottlenecks, the better your response will be. 
  • Don’t stop after completing “your part”. That’s convenient, without a doubt. But the sooner you realise your behaviour impacts others, the better results you achieve as a team – success is the sum of the efforts of the individuals. 
  • Engage in discussions. Don’t let the environment decide for you. The best ideas come from people with fresh perspectives, especially those joining the team from the outside. 
  • Ask, ask, ask. There are no stupid questions in these kinds of projects. It’s better to repeat an answer than stay uncertain, as there might be no time to make changes in case of failure. 
  • Don’t work over your limits. Working after-hours is generally not a good idea, but in the context of such a short-deadline project, it can be even more dangerous than you think. These projects need creativity and engagement, which is nearly impossible when you’re tired or burnt out. 

The takeaway

This story is a perfect example of the “Mews approach” – despite the challenges, failure wasn’t an option. We made it work. Our journey of turning a crisis into a success at Mews highlights the power of effective teamwork, underscoring the importance of shared responsibility, open communication, and a willingness to adapt. Ultimately, we attribute this success to the collective effort of our team members. We navigated challenges together, built strong relationships, and learned valuable lessons along the way.

The team’s voice 

Alex (Frontend Developer): If you ask me what the most positive thing I got from this case was, it’s definitely the reconnection among team members. We usually spend a lot of time working on individual issues, but this time, we could succeed only by working together. I enjoyed the atmosphere around this case a lot. I think we were able to build a super friendly and safe environment for everyone, so none of us felt like we were doing our tasks as a punishment. I’m also glad I could see the other parts of the system from different perspectives – it means a lot in my current position to be up to date with problems other teams face daily. 

Honza (Frontend Developer): As a platform team member, it was great to work closely with a product team and discover their ways of working and pain points. At the same time, we had an opportunity to figure out some best practices to leverage in our future work. I really enjoyed the collaboration because the host team welcomed us with open arms and treated us like full-blown members even after the project ended. 

Vašek (Frontend Developer): If I had read this story before joining Mews, I’m not sure I would have joined. Especially the beginning of the project, what a mess: they didn’t know the requirements (only very, very vaguely), but somehow knew how many resources it would take (how many people they needed to borrow from other teams) to meet the deadline (set by who knows who). Does that make any sense? If I didn’t know the people, this would make me doubt their competence in project management. 

Luckily, we somehow pulled it together and learned valuable lessons, as already outlined by Alex and Honza. But in my opinion, the main lesson from this should be to avoid these situations at all costs in the future. 

Daria (Frontend Developer): This project was a lot of fun. Every day, we had new challenges to solve while striving to avoid miscommunication. It was very intense, and it felt as if we were working in a start-up within a start-up. I always knew we’d achieve success in the end, though, so I wasn’t worried and just enjoyed the roller coaster ride 🎢 

Jana (Frontend Developer): Working with temporary teammates was a great learning experience. Their guidance, code reviews and just plain encouragement were invaluable. I’m happy to say we became friends, and even now, when I get stuck or unsure about a piece of code I’m writing, I know I can go to them for advice. 

Naomi (Translation Manager): On the practical side, daily standups, a shared Slack channel, and quick code reviews were the most integral elements of success.

Full-Stack JS developer, unfulfilled bus driver, bigos lover and father of 3 years old AI.
Share:

More About