Random Thoughts on Leadership


one of my audio books is all about leadership, another book I just read is on Design Thinking. So – as a reminder to myself – here are some random thoughts on leadership:

What do leaders do? They produce certainty in ambiguity.

This is for me the major thing. As soon as there is no more ambiguity there is no leader needed. But in today’s world we have more change than ever thus more ambiguity than ever. Producing certainty also means to make decisions and to rely on them. It does not mean to never change a decision but it does mean, not to change frequently. Also, a coach is not a leader. A coach might instrumentalize people (by “coaching in the ´right direction’) but in the end another person decides what the right thing is to do. So, who’s the leader?? Another direct implication is that leaders try to be predictable and therefor trustworthy.

Leaders can be team members but know when to differentiate.

It is totally nonsense that leaders need to distinguish themselves from their teams to show their willing to lead. They do but it is a timing thing. Most of the times it is necessary to hand over the leadership to others that are more skilled in a current phase. This kind of leadership is borrowed and will be taken back as soon as necessary.

Leaders lead in all directions.

Everybody can be a leader and sometimes will be in the position to do so. Manage your manager, lead your peers. If you do it right and they feel a benefit they will accept it and next time give you more room to lead.

Leaders and managers are not the same.

Managers are organizers and orchestrators. They are necessary setup projects and make them successful. Leaders on the other hand define a vision. So, managers need leaders and vice versa. The leader define a broad vision and builds trust. The manager helps organizing the steps to go there.

Don’t join the leader personality cult.

Certainly the leaders that are remembered the most are charismatic speakers, visionary geniuses, open and respectful…bla bla bla (as Steve Ballmer would say). There is no such leader, sorry to say. Certainly Cesar was a good leader but certainly not respectful and open as we would like to see it today. Or Napoleon, or Bismarck… So trying to copy somebody will result in a bad copy, no more. Better: Try to learn and adopt what makes sense and accept what you will never accomplish. Knowing your disabilities is at least as useful as knowing your abilities. Try to find people that help you out here and you are fine.

Never try to be larger than the frontline.

This was a great learning from my residency with Walden University. Who knows the best about the daily situation your company is in? Well, the guys who fight in the front line every day, right?? You need to stay in contact with those guys, you need to speak and understand their language. You need to have empathy for your customer. How trustworthy is a leader of a excavator production who never tried driving an excavator? I do not mean being an expert but being empathic. Otherwise you will soon sound academic and disconnected.

Teach people to criticize you open and respectful.

For me fair comments given as feedback is the highest form of respect I can have. That is something I also recall before going into tough discussions. If you lose the ability to hear critical feedback, the end is near. But what does this mean? In the end it means that you treat people fair and open yourself. Even if there are information that should stay within a certain group, share it with the group and rely on them to handle it carefully. It adds to the trust you receive and builds a team spirit. On the other side if you force people to accept a lie (which will be discovered to be one sooner or later) you lose all the credibility and respect. People will build Potemkin villages because they fear being punished for the truth.

Again: Open and true feedback (good and bad) is the highest form of respect you can give and receive.





The two kinds of Developers


have you ever thought about the two fundamental types of developers?? OK, let me introduce my model to you:

Product Group versus Laboratory

Let us start with Lab guys first:

The laboratory developer:

* Short winded, things need to show quick results

* No care about architecture

* No care about security or performance

* Lots of ideas, very creative, thinks out of the box

* Willing to take risks

* Fails often but quick

* Typical work cycle: Idea – Prototype – Evangelize Prototype for broad usage

* Work cycle breaks on any position regularly because product fails

* Language of choice: Ruby, Python, Visual Basic, Expression SketchFlow was made for them


The product group developer:

* Stamina

* Cares a lot about architecture, security, quality, documentation

* Lots of ideas but within the box

* Failure is no option

* Risk avoidance

* Typical Workcycle is defined by a software development process

* If the workcycle breaks something severe has happened

* Language of choice: C#, C++, Java, UML


To bring it down to one word: Product Developers are all about engineering, Laboratory Developers are all about design. I went through my team and found good examples for both groups.

The better developer – product or lab? Both.

The answer is: You need both!! The lab guy helps you to be really creative and innovative but will hardly be able to deliver a profound quality product. While the product guy will struggle down any idea reaching to far beyond what we have today, those guys are able to build, deliver and maintain a quality product. Funny enough the lab guys normally take well build (product group) stuff and build on top. A shaky tower needs a strong basement.

More innovation – product or lab? Both.

Here again the answer is that both are innovative but on different types. While a product group does innovation in baby steps (start from the good that we have and extend a bit – not too risky – in a certain direction), the lab makes huge jumps but does not care on steady increase (I mean over several product releases).

Product and Lab – never mix!

Interestingly enough I heard a guy from a lab within Microsoft telling me that he normally tries not to hire somebody from product teams. In his opinion those guys are poisoned in their thinking (hey, he is a lab guy, ok?). He also told me that lab guys normally cannot switch to product groups because they tend to kill the process.

It is all about the handover. A company that is able to hand over ideas from the labs into the product groups is a killer…