The right DevOps Structure

Once your company has decided to adopt DevOps, that’s when the hard work actually begins. Typically Development and IT-Operations are separated organizationally. How do you bring the two together? What’s the best approach for your company and how do the different approaches compare to each other?

All those questions are non-trivial to figure out. For me, the work of Matthew Skelton and Manuel Pais really helped me to bring order to the various patterns and anti-patterns that exist.

I highly recommend you take a look at their work:


Focus more – multitask less

The ability to multitask is often looked at as a positive characteristic of an employee or of a team. I’m often impressed myself with people who are able to keep several balls up in the air. However, what everyone should keep in mind when asking anyone to multitask is the cost that is associated with it.

The cost of Multitasking

In „Quality Software Management: System Thinking“ Gerald Weinberg suggests a rule of thumb to calculate the cost of context switching when working on several projects at the same time. When a team is working only on one project they can dedicate 100% of their time on that one project. According to Weinberg, once you add one project 20% of the team’s time is wasted with context switching. When adding a third project only 60% of the time is used on projects. By adding a 4th and 5th project you are wasting more time than you are focusing on actual projects. Jeff Atwood wrote an article in 2006 referencing several studies about the problem: The Multitasking Myth

Dead Time

From the above one can easily think that focusing on one project is something that everyone should aspire to. Personally, I don’t think that is realistic or even pragmatic. First, the requirements for your business will almost never comfort you with the luxury of only focusing on one thing. Secondly, there is such thing as dead time in projects. So periods of time in which you are waiting on something in order to progress with your project. No matter how hard you try to align everything in order to avoid dead time, you will have some.

Knowing there will be dead time you can use this to your advantage by pipelining a certain amount of projects. If project A is blocked people can progress on project B, etc. The cost of context switching is still there, but it is mitigated by the ability to work on something highly prioritized during dead time of another project.

Don’t plan with 100% of your team’s time

Another false belief is when running only one project 100% of a team’s time will actually be used for working on this project. I’m doing that mistake myself a couple of paragraphs up in this post. You will not be able to spend 100% of your time on a project hence it is wrong to assume it. There are a couple of reasons for this.

One reason is, everyone will do something unrelated to work throughout their day. Several studies have been conducted and on average it seems that out of an 8 hour work day only 7 hours are effectively used for work.

Also, urgent things will interrupt the day. Especially if the development team is also responsible for maintaining an application in production systems. How much of a team’s time goes into solving production issues highly depends on the quality of your software. In any case, things will happen and you need to be aware of that when thinking about how much time can actually be spent on a project.

Thirdly, teams will spend time in meetings, will receive training, will have to monitor production services, etc. Again, how much time goes into that is probably individual for each team, but it needs to be accounted for when thinking of how much time can be dedicated to a project.

So what does that all lead us to?

Just being aware of all the above already helps. Teams and organizations need to find the right balance between multitasking and focus. Finding that balance requires work from everybody involved in the process including the leadership team. Also embracing agile methodologies will help prevent over-committing and account for the fact that your team is able to spend all their time on a specific project.

What are your thoughts on this topic?


My most hated word in Business

My most hated word in business is „escalation„. It’s often an artifact of unhealthiness. Unhealthy process, unhealthy organizations, worst case an unhealthy culture. No surprise it makes you feel sick over time.

Also, before I start… This is not meant to be a highly scientific or well-researched article. Just my very own thoughts on the subject that I came to over the last couple of years. Let’s look at some reasons that I’m seeing regularly when an escalation reaches my inbox.

An escalation often happens if you don’t take enough time for planning. Whatever it is that you want to do… did you plan it through properly? Did you consider risks and potential changes? Did you take requirements for granted that really you shouldn’t? Did you have a solution in my mind before understanding the problem? Did you validate data and information that you needed?

The second reason for an escalation often is enough communication or no communication at all. Especially paired with not enough planning things can become really hairy. Did you talk your project through with other teams and organizations within your company that you need to be successful? Did you talk to the right people on the customer side? Did you set expectations appropriately?

Very often escalations can be prevented if the right amount of planning happened and once a plan is put in place, the plan is communicated properly to all parties involved. Also, communication is not a one-time thing. Expect that you need to do it frequently throughout a project.

Sometimes you receive similar escalations within a short period of time. That might be a sign of a missing process within your company. As there is no process the only chance people see to be heart is to escalate their issue higher and higher throughout the hierarchy.

If things are really bad, your company is on its way to developing a „not my problem„-syndrome. That’s a cultural problem and very hard to fix, so try hard to prevent this culture from coming up in the first place. This behavior is often caused by every team and every single individual being overloaded with top priorities. Nobody has the room to breath to offer help. Everybody is worried not delivering on their top priorities when helping others. Eventually, of course, this will mean that nobody wins. Better alignment and focus across the company’s organizations can help, but it really is a culture that needs to be driven from top to down.

Last but not least escalations cannot be prevented completely and it is good to have one or more policies in place which describe how to escalate based on what needs to be escalated.

What do you think are the main reasons for escalations and how do you think most of them could be prevented?

Situational Leadership

For a very long time, I deeply believed that treating everybody equally is the most unfair thing one could do. Instead, in order to treat everybody fair, you need to adjust your approach, you need to deal with situations differently. In everyday live, this can become a challenge especially if you lead a team that is diverse in culture, experience, expectations, and age.

Hence I was glad when I heard of the Situational Leadership approach. It gave me a framework for the believe that I have. Sometimes frameworks help to work in a structured way with difficult situations. There are various books about Situational Leadership. The one I read (though in German) is the following:

There are much more though, and also Youtube is a good source for shorter and longer clips about the topic.

In essence, Situational Leadership is differentiating between four development levels and four leadership styles.

Throughout D1 to D4 competence of employees in this group will grow. Their commitment or engagement, however, will fluctuate.

Someone new on a job might be very engaged, but not very competent yet. On the other end of the scale, a professional working in a field already for many years is highly committed and highly competent. In between, employees in D2 and D3 have a certain level of competence but either low (D2) or variable (D3) engagement. The reasons for this can be manifold, but it often comes from the realization that you know something and you have overcome the initial hurdles, but you also know that there is so much more that you are not familiar with. This may seem frightening and overwhelming.

The related four leadership styles differentiate from each other by the amount of direction and support an individual gets from their manager and in who is going to take a decision.

For an inexperienced D1, the S1 leadership style fits well. The person knows very little it needs to be directed a lot in order to learn. You will take all decisions. With growing competence of the employee, you will decrease the blunt direction and instead coach and support the employee so he can grow further by himself. You will talk through decisions with a D2, but you are the one that takes the decisions.

Finally, with S3 and S4 you are delegating the decision-making to the employee. Over time the employee will become more competent and confident and hence can make a decision; at first still consulting with you (S3) but ultimately completely independent from you (S4).

Some important additional points:

  • Assume everybody has potential and the willingness to use it.
  • Tell people that you are using situational leadership otherwise, people will be surprised by your change in behavior.
  • For the situational leadership model to be successful (and in my opinion any leadership model to be successful) it is key to agree on goals and to measure and rate them.
  • You can use more than one style on one person. Someone might be very experienced in one area, but very inexperienced in an area he just entered. Imagine a Senior Engineer with 15+ years of engineering experience who makes his first step into management. Those can be complex situations in day to day work live…

As usually, my goal with this article is not to dive into every detail of situational leadership, but just to give an overview and note down some key takeaways for my own purpose. There are plenty of resources on the internet as well as books that you consult for a lot more detail.

The 5 Dysfunctions of a Team

Recently I came across a book that I read a couple of years ago: The 5 Dysfunctions of a Team by Patrick Lencioni.

As it usually is, you are excited about a book and then as time passes by you forget again. So it is always good to go back and remind yourself.




The book is really about the 5 dysfunctions listed in the left triangle. All dysfunctions are somewhat related with each other, hence the representation as a pyramid. It starts with the absence of trust meaning teams are not open with each other. This results in fear of conflict during discussions. Honest opinions will be held back and instead, everyone will just voice opinions that seem acceptable by everyone. Fear of conflict leads to lack of commitment. If you haven’t voiced your opinion you will not buy into the decision. If you haven’t bought into a decision you will avoid any accountability which ultimately results to inattention to results.

On the other hand, truly cohesive teams, trust each other and hence engage in conflict around ideas. As all team members participated in the discussion they are able to commit to decisions and speak with one voice. As they agreed to a decision as a group they hold each other accountable for delivering on the decided plans. By holding each other accountable they focus on the achievement of collective results.

While this probably makes sense to most people who are reading this, reality is often much more complicated. Sometimes it is difficult to recognize the dysfunctions and it is even harder to fix them in order to build a functional team.

For those who want to learn more about the topic, I’m highly recommending buying the book or you watch this video:

Open Positions On My Team

Over the last 1.5 years, my teams have been growing a lot. From only 6 developers in Europe, we present now about half of the global Concur Travel Development team. We are a very international team with 10+ nationalities from across the world and we are working on some of the most exciting functionalities within Concur Travel. We use a multitude of technologies. .NET, Go, Docker and Kubernetes being among them.

If you want to be part of a growing and successful team, if you want to create a career and if you are interested in solving technical challenges in order to create business value these are the right positions for you:


Natural Project Planning

Allen’s Getting Things Done is a resourceful book in many ways. If someone asked me for the two most valuable / interesting passages of the booking I’d probably point out the „Getting Things Done“ diagram which I wrote about here and the „Natural Project Planning“ which I want to write about in this post.

Natural Project Planning consists out of five steps:

  1. Defining purpose and principles
  2. Outcome visioning
  3. Brainstorming
  4. Organizing
  5. Identifying next actions

If you’re like me you will probably read over that list and think „yep, that’s how it should be, so what’s the big deal here“. Well, the big deal is, that while this model is very natural it won’t be followed most of the time.

Think back to your last kickstart meeting for the latest and greatest project. For sure someone said, „let’s brainstorm“. That just sounds right and very actionable. The problem: If you didn’t talk about the purpose of the new project yet and if you have no idea about possible desired outcomes for the project the brainstorming will lead to absolutely nothing constructive. Without knowing the purpose of the project and without any vision you won’t be able to separate the good ideas from the bad ones. So next time someone says „Let’s brainstorm“ make sure everybody is clear about the purpose, principles and outcome visions.

Once these are defined and you successfully brainstormed the new project everybody leaves the room and now what? If you?were lucky someone took a photo of the whiteboard with all the good and bad results of the brainstorming on it. Since most teams don’t have the luxury of working on one project at a time it is fairly certain that other things come up and get prioritized. After a week nobody will understand anymore what all the words in the photo of the whiteboard are really about and we have to start the process all over again.
Brainstorming is important but it will be for nothing if you don’t take the time and organize all the unordered ideas into actionable items. Start writing a project plan. I don’t have to be a huge formal document. Simply make a list of „next actions“. Prioritize them and assign them to concrete people.

Following these five easy steps helps to get projects started and keep them going. It works for small and big projects, however, for big projects, you’ll likely need more formal approaches…