Tuesday, April 12, 2016

Leading by good looks



“… you don't get trusted positions just because of your ability. You also have to attract the notice of superior[s…]. You have to be liked. You have to fit in with the system. You have to look like what the officers above you think that [leaders] should look like. You have to think in ways that they are comfortable with.
The result was that you ended up with a command structure that was top-heavy with guys who looked good […] and talked right and did well enough not to embarrass themselves, while the really good ones quietly did all the serious work and bailed out their superiors and got blamed for errors they had advised against until they eventually got out.”

Ender's Shadow, by Orson Scott Card @1999


Likable people that fit within the system do a decent job advancing the system toward success. The kind of success that is easy to imagine, easy to prognosticate, and mostly means being ahead of the competition that does the same thing.

However, if one wants to shoot for the stars, to change the paradigm, to redefine success – expecting good-looking people who think in ways that are approved by the existing system to lead us there is doomed to fail. Occasionally, success is not so much ‘the same thing, just more and better’, but rather a long shot that could turn out to become something different, powerful and amazing. And then there is a need for a different kind of leadership, the leadership that does not work as hard to look presentable, to say the expected thing, to be liked by the superiors.

There have always been unlikeable leaders who changed the world in big and small ways. A few went against the system, and others simply disregarded the system and built their own way. The society at large considered most of them failures during a significant portion, if not the entirety, of their journeys. Others have reached the official definition of success, and occasionally even became liked and popular. Still, leading for change is a risky proposition with high potential for failure.

So when picking a leader, or aspiring to lead, put some thought into what kind of leader you want to follow, or to become. Good looks may not be required. 

Thursday, February 18, 2016

Following Plato Dialogues: conversation about estimates


-            So, why do we need estimates?


-          Well, as a customer, I want to have estimates.

-          Great! In what ways are estimates useful to you?

-          Say, I order from Amazon, and if my purchase does not arrive on the estimated day, I get to request a refund.

-          Huh, so you are rooting for the sender to fail, and that’s why you need estimates?

-          I guess so.

-          Any other reason to want estimates or tracking?

-          Well, if as a customer I was promised a certain delivery, and it is getting really close, but the work is less than half done, I can make a determination that I am not getting that delivery.

-          So, the reason you want estimates is to feel reassured that work is being done? To make you more comfortable with the delivery that you do not trust?


What are good and useful reasons to want estimates? 





Sunday, February 14, 2016

99 little bugs in the code...


A lot of developers I work with are very good, and many are very productive.  Surprisingly, those are not necessarily the same people. Unfortunately, it is not always easy to tell the difference. 

Once upon a time, the management at the company* where I worked decided that there were too many bugs in our code base, and an effort must be made to deal with those bugs.  So, the team was asked to come in on a Saturday, and work on resolving bugs. The deal included a significant bonus for the developer who closed the most bugs by the end of the day.

Lo and behold, on Monday the winner was announced: the person who got the bonus apparently fixed 27 recorded bugs. He also introduced many new ones, so that the next couple of weeks ended up being devoted to resolving the problems introduced on that bug-fixing Saturday. The team did not dare to record any more bugs, though, for fear of being called in to work on a Saturday again.

The developer who fixed the 27 bugs on that memorable Saturday was getting praised by the management as the most productive employee, while the rest of the team grudgingly worked to resolve the errors he (and, undoubtedly, other people too) has introduced, while the productivity of new feature development came to a stand-still. Since the new bugs were not being recorded, the situation virtually guaranteed that knowledge will be lost as time went on.


* The names have been omitted to protect the innocent and the guilty.