Person working on laptop being productive

A lot of teams have an ineffective team workstructure that is not beneficial to their needs or productivity. How do you modernize and improve your way of working? In this blog, I will share my insights and tips to establish a lean meeting structure.  

As a consultant, you see a lot of different companies, all of them with other challenges. When you arrive, there is usually a reason that they lack technical know-how or staffing. But these are just symptoms of an underlying issue related to how you manage and work as a team to complete the business goals set out by higher management. So how do you modernize and improve your way of working?

More than just a technical assignment

Most of the time, the request that starts the assignment of a cloud consultant is technical. But these technical questions are primarily rooted in the team's need to modernize and improve their way of working.

The potential symptoms of a team that's not working properly are the following:

  1. Team members work on tasks as individuals
  2. Lack of information sharing
  3. People do lots of shadow work
  4. People are directly contacted by other teams because it is faster

 One of the first things I do as a DevOps engineer is to ask the following questions.

  1. What do you want to achieve with your team and infrastructure?
  2. Why did you set those as your goals?
  3. What changed when I finished the assignment?

These might not always be the literal questions asked; the point is to get a clear image of what the customer wants to achieve and their reason for hiring a Cloud/DevOps consultant.

The answers you get are usually a desire to improve team performance and skill so they can provide service to internal/external customers or improve any technical platform or service.  For both, you need a team that works together and owns its product or service.

Before any significant technical improvement can be made, you need to make sure there is a team that is capable of carrying it into the future.

Lean meetings in practice (use case)

My current assignment was no different, a team that involved us because they wanted to improve the product they were delivering. This team consisted of 3 people and is now 5 people. The added challenge is that two are located outside of the country, with two different time zones... At the time of joining, they only had one weekly meeting planned where they talked about the team's goals and the work status. This limited contact results in a group of people doing some work for some project, instead of a team owning a product or service.

Setting up new meeting structures

LeanIT and scrum have a daily meeting called "Daily" or " Standup", which is held at the start of the day. To plan this with people in different time zones is complex. Because when one part of the team was starting their day, the others ended theirs. 

So what did we do? We renamed it!  A daily Handoff was born and we planned it during the team's overlapping working hours. The meeting contained what was done and what problems arose during the day, informing the people who just started their new day. This usually lead to a discussion on these issues, meaning the goal of 15 minutes, was often not reached. But these discussions are valuable and need to be allowed.

The handoff ensures that the team stays in sync across timezones, with the occasional social water cooler talk and fun.


Handoff will not cover the incoming work from the business and changing priorities that are affected by outside team factors. For this, we have a weekly meeting called "the weekly". This meeting is specifically for the product owner to inform the team about incoming work from the business and to discuss the list of priorities. At the core of this weekly is the alignment of the team with the business.

This meeting can also be used to talk about issues or other team goals more deeply as the intention is for it to be a 30 min to 1-hour session, depending on the content. Directly after the weekly, you would then do the handoff, to update the team on the latest work status.

Kanban board

The tools used in the meetings depend on what is available, but a form of Kanban board is advised as it can give the team a visual insight into what is happening with the work. Keep this board simple and to the point.

The goal of a Kanban board is to visualize work and its current state in the process. For most teams in the IT field, it can be distilled down into the following stages:

  • Backlog (Incoming, un-planned work that still needs to be reviewed and refined)
  • ToDo (Planned by the team to be picked up in an upcoming time period set by the team)
  • Doing/InProgress (Work currently being worked on by someone)
  • Done (work that has been completed)

If the team has a lot of work that gets stuck, for example, because they're waiting on external factors, adding a Blocking stage to the Kanban board is valuable. It gives the product owner insight into what deliverables are not finished and why, so he can communicate this back to the business owners waiting for them. It also makes stuck work visible and motivates team members to unblock the work by reaching out or reviewing code with a colleague.

If the quality of the delivered work is low, adding a Review stage might be valuable. Because if another person reviews the work, it will increase the quality over time.

Take your time

Ultimately, it all depends on whether the team is motivated and open to making the above changes work, and the devil is in the details that differ for each team.

The use case I wrote about resulted in a team that tackles its problems by working together.
Changing from working on whatever was most important that day to working on team goals and building solutions with a long-term vision in mind.
This change took almost a year to fully embed itself within the team, but the rewards are worth it.

Remember, good changes take time, don't rush them. Make it the new standard in the team before adding additional improvements.

Are you facing the same problems, or have you found alternative ways to solve them? I love to learn about the stories of other people and their solutions/problems. Leave them all in the comments!

A passionate DevOps engineer with experience from the media world. In the past trained as an interactive designer, now a terminal warrior. Believes that a good IT infrastructure starts with good working teams that work with passion and strive to be better every day.
May 07, 2024 | BLOG | 6 MINUTES

8 questions you were afraid to ask about Talos answerd

Talos is a minimal Kubernetes OS that's quickly gaining popularity because of its ease of use and strong focus on security by default. It has already been …

April 30, 2024 | BLOG | 9 MINUTES

12 Factor: 13 years later

How can we make applications easy to operate? The 12-factor methodology is about 13 years old. How did it age in the cloud-native era? Do we need a 13th …

April 25, 2024 | BLOG | 5 MINUTES

Build your own Python Kubernetes Operator

Yes, you read it right – build a K8s operator in Python! I often get reactions like, "But doesn't it have to be in Golang?" Fortunately, that's not …