All posts by Josef Dietl

Leadership, Management

Image and Reality

Leave a comment

La Trahision des Images
The Treachery of Images as an example for the mis-match between the actual staus and the reflection of the status.
One frequent mishap in larger organizations is exaggerated confidence in KPIs.

It is interesting to note that the literature on management, spends little to no attention on the accuracy of the measurement, while the literature on leadership barely mentions such KPIs at all. When discussing topics that are easy to measure, like manufacturing, taking the accuracy of KPI measurements for granted may make sense – however, the business of software is so far largely resisting meaningful, repeatable measurement. KPIs are so important because, often, KPIs are tied to people’s bonuses, which immediately invites, encourages … tuning of KPI actuals.
Continue reading Image and Reality →

Distributed Teams, Leadership

Anecdotes for Project Managers: Cargo Cult

Leave a comment

Another anecdote that is really working miracles is Richard Feynman’s story about Cargo Cult. I have to admit that I’m telling my own version. I’ve researched it on my own and massaged it a little bit to focus on the point I’m trying to make.

The situation where this anecdote works best is at milestone meetings, at larger companies: large companies have processes, even for project management. Project management processes typically focus on special milestones with special deliverables and a range of bored senior managers who have to take the decision.

The other day, I started one such meeting by telling the following story:
Continue reading Anecdotes for Project Managers: Cargo Cult →

Distributed Teams, Leadership, Management

HDWKTWD – a User Story for Tasks

Leave a comment

Have you ever experienced that a task has been agreed, and half-way through somebody comes back beaming with the statement “it’s done!”?

Every once in a while, this happens, and it happens more often in distributed teams than in localized ones. The point is: there was no real agreement about when the task is done. I’ve started a new experiment in my teams, I’m starting to add to every task a little “HDWKTWD” section.

What’s “HDWKTWD”? – It’s short for “How Do We Know That We’re Done”. A good task assignment already does that implicitly (compare “discuss the schedule for XYZ” to “agree on a schedule and inform everybody in an email.”), but sometimes it helps to be even more explicit šŸ™‚

User stories deal with the user observable behavior of a system. Who says that this characterization of user stories should apply purely to programming? The trick is: If I’d make a movie – would an outsider be able to judge whether the goal has been reached or not?

In the example: “discuss the schedule”, everybody would be able to see that a discussion has happened – but that’s not the desired outcome. The desired outcome is an agreement. However, the agreement is not visible to an outsider until it’s documented in an email. Hence the re-worded HDWKTWD…

My first impression is that “user observable behavior” ‘s doing good for project management, too.

Leadership, Management

Decision Analysis III

Leave a comment

It’s already a while ago that I presented my Influence Diagram to our sponsors (one may remember the Decision Analysis II article). The main value of the presentation was – as so often – in its preparation:

  • I’ve had my own mind clear on what I suggest and why
  • In the preparation meetings, peers and sponsors had to wrap their head around the entire topic.

So, eventually we had an engaged discussion about a situation most people had pretty well understood. While we didn’t really go through the presentation, we still arrived at – from my point of view – the right conclusions.

And a few days after the meetings, I received an email with four words: “good meeting – unlike most”.

It works.

Distributed Teams

Anecdotes for Project Managers: Looking for the key

Leave a comment

Lately, I started to realize that a lot of the project management I do has to do with anecdotes.

I likeĀ using anecdotes, it matches my mentality for managing projects, especially larger projects: I believe that problems should be solved as close to the actual work as possible, and I believe that I am in charge to helpĀ the teams toĀ leverage their own full potential. Anecdotes have proven a valuable means to unlock successes, like in the following example:Ā Lately, IĀ realized that I’m using the following joke over and over again with different people:
Continue reading Anecdotes for Project Managers: Looking for the key →

Management

Decision Analysis II

1 Comment

Getting an objective decision straight despite the Decision Analysis quote from the pervious article has kept me thinking since mid-December.
Meanwhile, I have drawn an Influence Diagram for one of the more tricky questions on the job. First and foremost, drawing the chart has significantly helped clarify my own thoughts, so even if I dump it here and now, it was attention well spent. Analyzing the ~5 decisions, ~25 random variables and ~5 goals that contribute to this one set of decisions was quite enlightening.

To my own surprise, the other day I managed to transform the diagram so that I could actually present it without major unwanted political implications. The breakthrough came when I was about to give up and draw separate diagrams reflecting the assumed preferences of my main stakeholders.
Continue reading Decision Analysis II →

Management

Decision Analysis

1 Comment

Just before Christmas, I had a looong discussion with a friend who just entered Decision Analysis studies – a field I wasn’t even aware of until then.
Given that life for a project manager is full of decisions, studying how to do that well (both the preparation and the eventual commitment of resources) sounded like a treasure trove.
The next day, I told my boss about this discovery. He already knew what this was all about and started raving about applied maths from the lectures during his MBA. Then he quoted from his lectures:

Decision analysis serves to create transparency over actual preferences. That’s why it is rarely used in practice.

Software

Three types of bad design decisions

Leave a comment

A long time ago, I had to think about architecture trade-offs and design decisions when building widely adopted frameworks. Surely you’d tell me that one just shouldn’t do such trade-offs, but in a corporate world that may or may not be an option.
At that time, it appeared to me that there are three types of bad design decisions (also known as work-arounds), and they mostly differ in their cost, and how that cost scales. So far, in every discussion I was told that it’s trivial. Still, it’s usually not observed.
Continue reading Three types of bad design decisions →

Distributed Teams, Leadership, Software

The importance of respect in the business of software

Leave a comment

I found a reference to the article “Opinion: The unspoken truth about managing geeks“.

The reference is from Awasu’s “Anti-stupidity“. Thanks for drawing my attention to it!

Thanks to both your articles, I have nothing to add.

Hmmm… there’s always something to add, so how about this: The IT geniuses I’ve had the good fortune to meet all behave like that. But with IT becoming more of a profession and less of a vocation, I see first signs of IT pros turning “normal”. I don’t like it. Respect is – for all people involved – a better currency than credit.

I’ve been fiddling with the notion of trust, especially in distributed teams, for quite a while now, but respect is something that matters as much. I guess that – keeping honest respect in mind – even the quote “Unlike in many industries, the fight in most IT groups is in how to get things done, not how to avoid work. IT pros will self-organize, disrupt and subvert in the name of accomplishing work…” is not correct: I believe where mutual, honest respect is handled well, it will lead anybody to accomplishing their best and a little more. Which in turn tells us a bit about “most industries”.

Leadership

… and nothing is going to happen

Leave a comment

Today, I had an interesting discussion about empowerment, especially in a weak matrix organization. Eventually, the discussion reminded me of the Obituary of Richard Neustadt, the adviser to several presidents ($) of the USA, in The Economist (November 2003). The central part is (quoted from memory):

ā€œHe’ll sit here,ā€ he [Truman] said [about Eisenhower], drumming his fingers on the desk, ā€œand he’ll say, “Do this! Do that! – and nothing is going to happen! – it won’t be a bit like in the army!”

Well… if this is the amount of empowerment the most powerful man on this planet can command – how could I as a project manager as a project manager ask for more?

I think that project management is a lot about convincing and only a little about “empowerment”, and this means that there are three potential problems:

  1. First, it so happens every once in a while that somebody confuses “empowerment” with “veto right”. Such cases are particularly frequent among so-called internal governance bodies. Yes, this is empowerment in a sense… but it’s “wrong-way-round”. Real empowerment is the power to make things happen, not the power to stop.
  2. Second, the power to influence or convince actually means that the project manager can build a “bridge” between the project member’s personal goals and the project goals. Clear, aligned, specific goals within the company are a fairly obvious prerequisite to make that work.
  3. Third (or actually “2b”), incompatibilities of interests between different organizations that contribute to a project obviously break the “empowerment” of the project manager.

So what?

Upon closer inspection, the so-called line managers are often not more empowered: They can’t fire (at least not in Germany), and at least now in the financial crisis, they may have only very little financial freedom likeĀ over salaries etc. Don’t tell anybody, though šŸ™‚

Eventually, what it all boils down to is, provocatively exaggerated:

There Ā is no empowerment!

There is dis-empowerment.
There is an illusion of empowerment, and a good project manager knows how to sustain that.