Tag Archives: Management

“Decisions should be made at the lowest possible level”

When watching this video about The Origins of Hewlett-Packard, one of the statements that really struck me (at time code 16:25) was “Decisions should be made at the lowest possible level”.

I have had the privilege to work for Hewlett-Packard as my first job after graduating from university. It was a turbulent time then in 2001, when the dot-com hype was just “exploding”. But it was also a period, when many colleagues were still around, who had been with the company for a very long time. So the HP way was still alive and kicking, at least in my personal environment. Sadly though, ever since, my personal opinion has been that the company is in a downward spiral. It was certainly not a good sign, when under Carly Fiorina as CEO the founders’ names were officially removed from the company name and the latter reduced to their initials. I have left HP in 2005 but still feel connected. Therefore it really hurts to see what has happened to the company. And I always look back at those early years of my career with a lot of fondness!

But I should come back to the subject of this post. Having read, experienced, executed, and thought quite a bit about management, I really do think this is one of the (!!!) core aspects: Where should decisions happen? And especially in today’s times, when everybody is talking about “the quick eating the big”, it should be a no-brainer that the right level for decisions is one of the most critical components for success in business. Why is it then that we still see so many organizations where mid- to high-level executives lead with a micro-management style?

One fundamental question here is how people act in their professional environment. Do they try to avoid mistakes? Or do they work to achieve a common goal? I daresay the former behavior breeds micro-management as a strategy to mitigate risk. Of course, the result is local optimization, at best. But overall the organization will fall back in the market, perhaps live from its past for a while, and eventually disappear.

My hypothesis is that trust, or lack thereof, is the major driving force behind this. And it is usually the top management that sets the example here. The good thing, though, is that they can also change it. In his famous book “Turn the Ship Around!: A True Story of Turning Followers into Leaders” L. David Marquet does this on a nuclear submarine. And if it works for what is probably one of the most dangerous working environments on earth, it works everywhere. (The book is a must-read in my opinion for everybody who has only the slightest interest in things like management, corporate culture etc.)

I do expect that we will see many traditional organizations moving away gradually from a pure top-down management style. Partly because of market pressure for agility, and partly because employees simply demand it. So we have interesting times ahead of us!

Choosing a Technology

I recently started a new hobby project (it is still in stealth mode, so no details yet) and went through the exercise to really carefully think about what technology to use for it. On a very high level the requirements are fairly standard: Web UI, persistence layer, API focus, cross-platform, cloud-ready, continuous delivery, test automation, logging, user and role management, and all the other things.

Initially I was wondering about the programming language, but quickly settled for Java. I have reasonable experience with other languages, but Java is definitely where most of my knowledge lies these days. So much for the easy part, because the next question proved to be “slightly” more difficult to answer.

Looking at my requirements it was obvious that developing everything from the ground up would be nonsense. The world does not need yet another persistence framework and I would not see any tangible result for years to come, thus loosing interest to soon. So I started looking around and first went to Spring. There is a plethora of tutorials out there and they show impressive results really quickly. Java EE was not really on my screen then, probably because I still hear some former colleagues complain about J2EE 1.4 in the back of my mind. More importantly, though, my concern was more with agility (Spring) over standards (JEE). My perception with too many Java standards is that they never outgrow infancy, simply because they lack adoption in the real world. On the other hand Spring was created to solve real-world problems in the first place.

But then, when answering a colleague’s question about something totally different, I made the following statement:

I tend to avoid convenience layers, unless I am 100% certain that they can cope with all future requirements.

All to often I have seen that some first quick results were paid for later, when the framework proved not to be flexible enough (I call this the 4GL trap). So this cautioned myself and I more or less went back to the drawing board: What are the driving questions for technology selection?

  • Requirements: At the beginning of any non-trivial software project the requirements are never understood in detail. So unless your project falls into a specific category, for which there is proven standard set of technology, you must keep your options open.
  • Future proof: This is a bit like crystal ball gazing, but you can limit the risks. The chances are bigger that a tier-3 Apache project dies than an established (!) Java standard to disappear. And of course this means that any somewhat new and fancy piece must undergo extreme scrutiny before selecting it; and you better have a migration strategy, just in case.
  • Body of knowledge: Sooner or later you will need help, because the documentation (you had checked what is available, right?) does not cover it. Having a wealth of information available, typically by means of your favorite search engine, will make all the difference. Of course proper commercial support from a vendor is also critical for non-hobby projects.
  • Environment: Related to the last aspect is how the “landscape” surrounding your project looks like. This entails technology but even more importantly the organization which has evolved around that technology. The synergies from staying with what is established will often outweigh the benefits that something new might have when looked at in isolation.

On a strategic level these are the critical questions in my opinion. Yes, there are quite a few others, but they are more concerned with specifics.

Leadership Lesson from a Nuclear Submarine

The video linked below is a quick summary of how the captain of a US Navy nuclear submarine turned his crew into the best evaluated ever. It is a remarkable story and reiterates in a very comprehensive and compact way what I have experienced myself many times (on the giving as well as the receiving end).

I was made aware of this video by a post from Torsten Bittlingmaier. Thorsten, thanks a lot!

Eric Ries: “The Lean Startup”

I stumbled over this when reading a German article about the Visual Studio ALM Days 2011. Eric Ries basically makes the argument that startups, like any company, need management; you cannot expect to succeed without it. The key point, though, is that a special flavor of management is needed, which is tailored to the specifics of startup companies.

When looking at the reviews at Amazon, it becomes apparent that the author has hit a nerve. Although not all of them are really enthusiastic, already their sheer number (142 as of this writing) is interesting. I will not repeat things here but provide a few of my thoughts:

  • First of all, I was reading this not from the perspective of someone who works for a startup or wants to create one any time soon. Instead my background is on distributed systems working for a well-established software company. So the aspect of how to change innovation within an existing organization was the interesting part for me.
  • The key aspect I took away was that in many, many cases it is better to start building something quickly, fully accepting that the initial solution is far from perfect, and get feedback fast. This also coincides with my observation that most people have great difficulty to really grasp and understand something really new. Instead of spending much time on slides, just do a mock-up or prototype and some screenshots and all your discussions will be much smoother.
  • If you expect checklists and concrete advice for your particular situation, you will probably be disappointed. I would argue, however, that the book’s approach to tell you how to think is certainly better than to have a one-size-fits-all list of things to check off.

Overall I enjoyed the reading and fell that it has expanded my way of thinking. Also, I found quite a few parallels (e.g. with agile software development) and this reiteration has helped to “persist” things in my mind.

Getting Someone’s Buy-In

Recently, I came across a very interesting post on Harward Business Review’s blogs. The article from Peter Bregman is called “How to Counter Resistance to Change” and I recommend you read it and also scan the other posts from the author. The part that will probably create a few raised eyebrows is when it advises against getting buy-ins. Well, at least in the dumb way this is usually done: In most cases I have personally experienced, what people effectively did, was try to persuade me (or even talk me to death). Folks, this is not getting a buy-in, this is talking someone to death.

In my view getting someone else’s buy-in usually means that the other party needs to change, at least partly, a position they had taken before. To make matters more difficult, in many cases the incumbent position has also been communicated to others, so we add the not-loosing-face factor to the equation. Variations of the latter are things like being seen in control by superiors as well as subordinates. But also the impact on relative strength perceived, compared to the person that gets his or her own view through, plays a role. So all in all this is quite a minefield and careful handling is required from a short as well as a long-term perspective.

What I found particularly interesting, or rather amusing, is that the author’s approach is something I also heard about in a TV series where it was called the “horse dealer’s approach”. So nothing really new, but still very relevant to many situations. Also, you can look at it as identifying a given pattern in as many different scenarios as possible. I am very much someone thinking in patterns and always find that one gets tremendous insight into the core of something following this approach.

Processes and Process Orientation: Introduction (Part 1)

This post is the first of a series aimed to give a general overview on processes and how they have affected the way we look at how organizations achieve their goals. The text is somewhat academic in nature but I still encourage you to read it. Understanding the basics and (theoretical) concepts is always helpful when it comes to practically dealing with specific challenges.

The series is based on a paper I wrote during my time at university in 1999/2000. (For those who don’t know, I read business management and not computer science or some kind of engineering.) While the paper itself was done purely out of interest for the subject and not for any course, it was triggered by a seminar for which I had to look at processes in the context of the Balanced Scorecard (BSC). I then added a few more things and made it a separate text. So here we go …


The process-oriented approach became mainstream in management theory in the 1990s. This was a move away from a mainly functional view that had been the predominant paradigm for many decades. A functional touch can largely still be found when you look at the orgchart: Purchasing, marketing, HR, etc. are all functions and will probably be around for quite some time. But instead of focusing on those functions, nowadays people realize that cooperation across the board is necessary to deliver something useful for the customer.

The old, functional approach with its clear separation of responsibilities was, in a way, a consequence of the work done by Frederic W. Taylor on scientific management. This mainly focused on  improving efficiency by splitting up work in many discrete steps. First steps towards a more process-oriented way of doing things came from these areas:

There were a few points that triggered this re-thinking which I would like to mention here.

  1. A functional approach severely limits the organization’s capabilities to be customer-driven (see above)
  2. A process-oriented organization increases flexibility
  3. Processes, or more precisely the thoughts required to define them, greatly improve the understanding of complex commercial activities
  4. Overhead costs need better distribution

As with so many things, this re-thinking was mostly triggered by difficult economic circumstances.

Part 2 will give a definition of what a process actually is.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is a pretty well-known tool for managing projects. It is a formalized way to split a complex task into many small (and by that more easily manageable) parts. So instead of “install computers in rack” you have list with e.g. check availability of rack space, request network and SAN connection, arrange date/time with computer center, etc. This is probably a bit simplified, but you get the point.

I use the WBS a lot as soon as things become a bit more complicated. May favourite tool are spreadsheets, which have the following advantages:

  • Everbody can use them
  • You can send them around via email very easily
  • Versioning is easy (via naming convention or use of a proper version control system)

What attributes should be maintained per task? I have the following:

  • Task ID: Never use the lines from Excel. A simple re-sorting and you are screwed
  • Status: green, yellow, red
  • Progress: open, done, wip (work in progress)
  • Area: Whatever makes sense to you. Examples: architecture, infrastructure, project management
  • Owner: The person responsible for the task towards management. Please note that this guy is not necessarily the one who does (all) the work.
  • Due date
  • Description
  • Activity log: Whenever something happens for the task, make a note with the date and your initials (you may not be the owner)
  • Task ID cross-reference: Relationship to other task(s)
  • External cross-reference: E.g. task relates to specific section of document

Depending on your requirements you may need additional information. You can also leave out some of the things from above, although I would discourage that if you don’t really know what you are doing. This list has been developed over a number of projects and sooner or later I was always thankful to have them.

So what is the relationship of the WBS to a project plan? The latter is generally more high-level, contains explicit dependencies, is more used to communicate with management. In many cases one line item in a project plan is basically detailed out by a WBS

How to Give a Presentation

“Everybody who loves attending presentations, raise your hand! No one? Hey, come on.  ……  Still nobody?”

Ok, so why is it that you may get this kind of reaction (although probably not so extreme)? In my view the simple reason is that the majority of presentations is just absolutely poorly done. People prepare at the last minute, if at all, execute lousy on that already weak preparation and then get the appropriate reaction from the audience.  Well, perhaps I am exaggerating a bit here, but I am convinced that most presentations fall short of what would have been possible with just a little bit of extra effort.

So here are the absolute basics:

  • Know your audience in advance: If you have no clue who will be attending the session you are pretty much screwed. If you have prepared a presentation for techies and business people show up, there will obviously be a mismatch between them and what you say. So for those case where you are not sure, have a “plan B” right in your pocket. In practice that means that you have to prepare not one presentation but lets say 1.7. For the case of techies vs. business guys this means that you should also have some business-related content. How much backup you need, depends on the individual scenario.
  • A presentation is not primarily about slides: These days many guys out there seem to think “presentation = power point slides”. That’s just plain wrong. A presentation is about conveying content (a “message”) to the audience. The slides are a means to facilitate and support that – nothing more, nothing less. You probably know the design principle “form follows function”. For presentations it is “slides follow story line”. Because that’s what you are doing, you are telling a story.
  • The story line is crucial: All too often we end up in sessions where the presenter is going through a bunch of slides with no “big picture” behind them. This is when the story line is missing and the net-result is just poor. You especially see this when someone is giving a presentation where the slides were created by someone else. They basically tell one slide after another (or even worse just read them) and in the end you don’t know what the overall message was.
    I have had a particular experience when the presenter was showing a mixture of self-made and “external” slides. The start was with the external ones and I almost left the room after 10 minutes. Then came a self-made one and I thought “Wow!”. Things immediately improved dramatically and my overall rating went from “This is an insult to the audience” to neutral. With just a little bit of in-advance thinking it would have been a really good session and it’s sad that the opportunity was missed.
  • People want to be entertained: Think about what makes the difference for you between a good and an outstanding presentation. What was special when you last left the room and thought “This was really good, I’m looking forward to the next session of this guys”. For me the main differentiator has always been humour. Nobody is interested in “content only”. Of course content is really important, but people also want a good show. Don’t be mislead: You are not expected to be a comedian and crack one joke after another. But something amusing at the beginning (a so-called icebreaker) makes all the difference.
    What you choose depends very much on your personality because you want to be “authentic” here. It is also important to find a topic that allows you to smoothly proceed to the content side of things. Example: I was once looking for an icebreaker for a presentation about increased agility. A British colleague came up with a fantastic one about formula 1. So both parts were about speed and the transition from icebreaker to content went just naturally.
  • Not everything on the slides: Sometimes people think that everything they tell must be on the slides. I must confess to you that I once thought so as well and it’s just dead-wrong. The only job the slides have is to support your story line. Now you often want/need  to give something to people, either for later reference or because they missed the presentation. That’s a good thing to do but should not cause you to put everything into the slides. The right place for those details are the speaker notes.
  • A short presentation does not mean little preparation effort: In many cases it is just the opposite. The simple reason is that the less time you have for presenting, the more you must try to come to the point quickly and at the same time avoid loosing the audience because of leaving out a critical detail. My personal record is a 10 minute presentation that took a full four man-days to prepare.
  • The right level of animation: No animation at all during a presentation is probably just as wrong as having loads of them. To determine where it makes sense to hide things when the slide first comes up, think about the story line again. As it unfolds, so should the elements of the slide. If both sides go hand-in-hand you have the right mixture.
  • Text on slides: Be very careful with text on your slides because it tends to distract the audience from you. They can easily look at a diagram that supports what you just say and still follow your speech. But as soon as they start reading their focus is on the slide and not you any more. The two reasons why I put text  on slides are
    • quotes (e.g. from analysts) and
    • visualization for a line of arguments
  • Face your audience: There is no reason to look at the slides and not towards the people in the room. If you do, you either didn’t prepare well enough and need to look at the slide for remembering what to say; or you put too much text on the slides and even with lots of exercising were not able to memorize things.
  • Move around: Don’t stand next to your notebook all the time. For switching between slides mankind has invented cordless presenters; get yourself one.
  • Involve the audience: This is not always possible but makes the whole thing more interactive. Don’t ask people to do things that might “expose” them too much. Unless you know the audience well enough the best thing is probably to ask questions like “Who has done XYZ before, please raise your hand”.
  • Know thy time: You were (hopefully) given a slot with a certain length. Don’t exceed that time! It is unprofessional and unfair to the other presenters, because you steal their time. A couple of points here:
    • Practice upfront to get a feeling how much time you need; a rule of thumb is 5 minutes per slide.
    • Plan in a way that allows you to either leave out things or add some. Your advance planning of time will never be 100% accurate and this buffer will make you much more relaxed.
    • Take into account that people might ask questions.

There is certainly more but I think if you follow those points you already do a much better job than most people I have seen out there. Good luck!