Deutsch oder English als Blog-Sprache?

See for English language below….

Deutsch

Dem wiederkehrenden Besucher wird auffallen, dass manche Artikel in Englisch, andere wiederum auf Deutsch veröffentlicht werden.

Warum?

Der Hauptgrund ist meine eigene Faulheit die Optimierung meiner eigenen Zeit. Ich schreibe in der Sprache, in der ich am besten über das gegebene Thema schreiben kann. Für Themen die sich auf irgendeine Weise auf meinen Beruf beziehen, fällt es mir leichter auf Englisch zu schreiben, da das die Sprache ich die ich beruflich zu 95% einsetze. Artikel über Hobbies fallen mir leichter auf Deutsch. Darüber hinaus ergibt es auch wenig Sinn über z.B. MyPoster.de auf Englisch zu schreiben.

Wird sich das unter Umständen ändern? Vielleicht… „Nothing is as constant as change“. Das aktuelle Ziel ist zunächst einmal jede Woche einen Artikel zu veröffentlichen und ein paar Besucher zu bekommen.

Vielen Dank fürs Lesen!

English

The returning visitor might have noticed that some articles are published in English and some are published in German.

Why?

The main reason is my laziness my attempt to optimize my own time. I always write in the language in which I can express myself the best on a given topic. On topics that are somehow related to my job I’ll always use English as that is the language that I use 95% in my day to day job. Posts about my hobbies are easier for me to write in German. Furthermore it doesn’t make a lot of sense to write an article about MyPoster.de in English.

Will this change eventually? Maybe… „Nothing is as constant as change“. The current goal is to publish a post per week and to get actually some visitors.

So thanks for reading this!

 

Advertisements

What really motivates us

My Development teams at Concur are currently all working on complex, high profile projects. Things are challenging and stressful.

In times like that it is important to remember what really drives motivation of a highly skilled workforce. As probably everybody knows by now: it is not money. Money is important and we need to pay people fairly, but it is not what ultimately motivates them long term. As I said, not a new thought, but in times like these, it is easy to forget.

What really motivates us can be distilled in three words:

  • autonomy: have the autonomy to do solve problems the way you think is best. We hire smart people, why not let them take the decisions they need to take in order to do a good job?
  • mastery: enable your people to become really really good at something.
  • purpose: answer the question why we are doing what we are doing.

Read all about it in „Drive“ by Daniel H. Pink. Or just watch this video:

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:

devopswebsite

http://web.devopstopologies.com/

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 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.

 

image3831

 

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: