Category Archives: Management

Anecdotes on Trust and Management Interference

Companies today place huge efforts and resources into hiring. Hiring the right people is important in the short term, but retaining them is an important long-term goal. Getting this wrong means that we are stuck in an expensive hiring loop, and that a good chunk of our people’s productivity is lost as the newcomers have to get up to speed, and the resident employees have to train them.

Note: The idea for this article resulted from a visit to Greenwich, where the columns of the Queen’s House were reminiscent of the story of Sir Christopher Wren and the Windsor Guildhall. It has nothing to do with any particular work experience I’ve had.

Trust

An ideal scenario for building a successful team could look something like this:

  • “Get the right people.
  • Make them happy so they don’t want to leave.
  • Turn them loose.”

— Peopleware: Productive Projects and Teams (page 91), Third Edition. DeMarco & Lister. Addison-Wesley, 2003.

If you are not hiring the right people, then you are getting yourself into a long-term problem that is very hard to fix. Conversely, if you are hiring the right people, then you should be able to trust them to do their work.

“Creating a pool of autonomous teams and letting them loose without leadership is a recipe for disaster.”

— The Pragmatic Programmer: From Journeyman to Master. Hunt and Thomas. Addison-Wesley, 1999.

Trust has nothing to do with absence of leadership, supervision, or direction. It simply means taking a step back and letting the people do what they are good at, and pitching in to give direction and support, but not getting involved in the little details of how they do their work (micromanagement).

“The most obvious defensive management ploys are prescriptive Methodologies (“My people are too dumb to build systems without them.”) and technical interference by the manager. Both are doomed to fail in the long run. In addition, they make for efficient teamicide. People who feel untrusted have little inclination to bond together into a cooperative team.”

— Peopleware: Productive Projects and Teams (page 145), Third Edition. DeMarco & Lister. Addison-Wesley, 2003.

There really is no point in hiring great people if we don’t trust them to do what they are good at. This means that great resources are being underutilitised. They will often notice this themselves, and leave for companies that can better realize their potential.

Methodologies

The previous quote from Peopleware says a lot about the way we work today, especially in the context of agile methodologies. I have already written how standups are excessively childish and counterproductive, and that important management responsibilities are being delegated to “Scrum masters” or “agile coaches” who are neither personally invested nor have the right abilities to give direction to the team.

“The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn’t it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier–all we need is (trumpet fanfare, please) a Methodology.

“A Methodology is a general systems theory of how a whole class of thought-intensive work ought to be conducted. It comes in the form of a fat book that specifies in detail exactly what steps to take at any time, regardless of who’s doing the work, regardless of where or when. The people who write the Methodology are smart. The people who carry it out can be dumb. They never have to turn their brains to the ON position. All they do is start on page one and follow the Yellow Brick Road, like happy little Munchkins, all the way from the start of the job to its successful completion. The Methodology makes all the decisions; the people make none. The organization becomes entirely deterministic.”

— Peopleware: Productive Projects and Teams (page 176), Third Edition. DeMarco & Lister. Addison-Wesley, 2003.

It is a real shame how the Agile Manifesto, a simple set of guidlines focused on reducing bureaucracy, adopting flexibility and enhancing productivity, is often corrupted into a set of dogmatic rites. People are encouraged to follow procedure rather than to think, communicate and work effectively. That’s the exact opposite of what the Agile Manifesto suggests.

And why else would people not be encouraged to think of their own accord, and take initiative, if not due to a lack of trust?

In the next sections, we’ll look at some historical stories relating to the problem of trust. In each of these stories, experts were commissioned to carry out a piece of work for which they were renowned. Each story shows how these experts cleverly defied silly orders (resulting from lack of trust and/or incompetence) in order to prove a point.

The Columns at the Windsor Guildhall

Image credit: taken from here.

There are four columns inside the Windsor Guildhall that seem to be there just for decoration: there is a gap between the top of the column, and the ceiling.

As the story goes, Sir Christopher Wren, the architect responsible for the Guildhall, was 100% confident in his design for an open space. However, the councillors insisted that he add some more columns on the inside of the building in order to support its weight.

“[Sir Christopher Wren] said the columns were unnecessary. Eventually, however, he relented, and built the columns.

“But to prove he was right, the columns were constructed so they did not touch the ceiling, and were merely decoration.”

— “Is this an architect’s 300-year-old hoax?“, Deceptology

While doubts have been cast on the veracity of this story and on Sir Christopher Wren’s role in the Windsor Guildhall’s design, it serves as an illustration of how an experienced professional alienates authority in order to prove a point.

David by Michelangelo

There is a similar story about how Michelangelo, satisfied with his work on the statue of David, dealt with criticism from the man who commissioned the project.

“There were no detractors, although the sponsor of the project, Piero Soderini did make a suggestion that was slyly dealt with by Michelangelo. Soderini, commented that David’s nose was too thick so Michelangelo climbed the scaffolding to attend to the problem.
The young sculptor pretended to alter the nose and even sprinkled marble dust to complete the effect. Michelangelo then asked Soderini’s for his opinion of the ‘new’ nose. ‘Ah, that’s much better,’, said Soderini. ‘Now you’ve really brought it to life.’

— “Michelangelo’s David“, Italy Magazine

If this story is true, Michelangelo took advantage of the fact that Soderini was artistically incompetent, and would not notice any difference in detail. This is very much like how errors in live performances often go unnoticed by those who are not musically trained.

The point is that Michelangelo was cunning enough to appease the man who commissioned his work, without compromising its quality. In the software development world, this problem often manifests itself in the form of client requirements which are in conflict with the nature of the product, and require radical changes while adding negligible value. Because of this, a very important aspect of the software professional’s work is to negotiate requirements, rather than just accepting them as-is.

The Queen’s Duck

This last story is much closer to the software development world, and is probably true.

“This started as a piece of Interplay corporate lore. It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.

“The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.

“Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “that looks great. Just one thing – get rid of the duck.”

— “New Programming Jargon“, Coding Horror

The producer always wanted something removed, just to show that his role had a purpose. Thus, the developers had to choose the lesser evil between compromising the project’s quality, and wasting time on something extra that would serve as a decoy. This shows how incompetent managers can have a detrimental effect on a project, whether it is on quality, productivity, or morale.

Conclusion

Give developers direction, but trust them to do their work. That’s why you hire good people. Good developers take pride in their work, and will not stick around an environment that stifles their creativity rather than empowering them.

On Daily Standup Meetings

Agile development methodologies such as Scrum, Kanban and XP have taken the software development industry by storm. By now, most companies have drunk the kool-aid – first the decision-makers, then the developers – and follow it with a manner of religious zeal.

It seems like this exciting new “agile” way of working has made traditional hierarchical management and reporting lines obsolete. Agile has by now entrenched itself deeply within the fabric of software companies, and it seems like we’ve forgotten the old ways.

We are now faced with the conflict of fixed-backlog sprints and shifting requirements, burndown charts that never converge, armies of full-time scrum masters babysitting developers to death, and the progression (or regression) of the Daily Scrum into… the Daily Standup Meeting.

While I understand this article may be controversial and may touch a nerve in a large number of people, I find it much more important to work efficiently and to challenge harmful norms than to mindlessly conform to them. My hope is that at least some people might read this article with an open mind, break out of their stupor, and start questioning these established practices. In order to improve, it is necessary to first acknowledge problems, and then take active steps towards addressing them.

What is the Daily Standup Meeting?

Image credit: taken from here

The Daily Standup Meeting is a “ritual” (quoting Jason Yip’s comprehensive article on the topic) in which the development team (and possibly other stakeholders) gathers to report on the progress of each individual member. They must in turn answer three questions:

  • What did you do yesterday?
  • What are you going to do today?
  • Are there any obstacles hindering your progress?

Let’s take a look at the meaning of each word, aside from “Meeting” which is obvious enough. As a “Daily” meeting, this happens routinely every day at a specific time. All those involved must stop what they are doing and participate, whether it is productive or not.

What I have just described is nothing new: I have participated in Daily Scrum meetings of this nature for years, and I’m pretty sure this goes back much father than my personal experience can account for.

A more recent twist, though, is the Daily “Standup” Meeting. The idea is to force people to stand up in order to keep meetings short, by having the physical discomfort as a disincentive to letting the meetings drag on unnecessarily.

Standing Up

This factor, on its own, speaks volumes. Rather than solving the problem of pointless meetings that are a complete waste of time, we choose to make people feel uncomfortable in the hope that the meetings will be kept short.

The first problem with this is how ridiculous and humiliating it is. Not even in church are you obliged to stand up, and perhaps at school there may have been instances where some posture was enforced in punishment (a practice that is probably considered barbaric by today’s standards).

But no. We are fully grown adults, who have been working for several years in the industry, and there is a perfectly comfortable sofa behind us, but we cannot use it, under pain of menacing glares from everybody in the room.

This also has no regard for any physical issues that the participants may be undergoing that may make this practice more uncomfortable than for the average human being. Such people should not have to disclose their personal problems to the team in order to waive the enforcement of a certain posture on the job, something that nobody has the right to enforce in the first place.

The second problem is that, well, it doesn’t work. Standing up or not, the tendency to ramble on is a lot more powerful than the discomfort (which most people can just as well get used to). Which brings us to the next section.

Excessively Long Standups

Do you remember what we’re supposed to do in standups? Basically, answer the following three questions, and then get on with our work:

  • What did you do yesterday?
  • What are you going to do today?
  • Are there any obstacles hindering your progress?

It is much harder than you would think, to stick to the plan. Despite having been brainwashed into enthusiastic and excited participation in this drudgery, people’s overexcitement tends to take over. There are many different scenarios which result in deviation from this template, and in turn cause Daily Standup Meetings to drag on. These are just a few of the most common I’ve encountered:

  • People want to justify their job and show that they are doing something, so they read out a whole list of every little detail they worked on since the last Daily Standup Meeting.
  • Stakeholders ask a lot of questions to the development team. They have a right to be answered, but the Daily Standup Meeting is not the right place.
  • Developers going off on a tangent and having a technical (or other) discussion between two or three people, but keeping everyone in the room.
  • Lots of people in the room, so it takes a while to go through what everyone has to report. This is mainly a problem when developer teams are large, but it can also be a result of participation of a lot of stakeholders who join the Standup. With 20 people in the room, it’s hard to keep meetings efficient.

Broadcasting Information

The format of the Daily Standup Meeting is such that the development team and any other stakeholders are present (whether physically or otherwise). It allows everybody in the room to be kept up to date with progress (in theory) and to be able to help remove any obstacles (again, in theory).

Personally, I believe that this is one of those cases where too much transparency is a bad thing. The main reason for this is that there is no reason why each person should need to broadcast their progress to so many people in the room. Typically, you work with one or two direct colleagues, and report to your manager. There is no need to keep a whole crowd in the loop.

Rather than focusing on what each of us needs to do, we instead feel the urge to get involved in what the whole team is up to. A consequence of this is that it becomes necessary to involve everybody in the team in order to take the slightest technical decision, which is really the opposite of the empowerment that should be enabled by giving developers such autonomy.

In practice, keeping everyone on the team updated has no real benefit. They may know you’re working on something, but they would not understand the business or technical decisions, and as a result, they would not be able to take up the task you are working on, in your absence.

Another problem is the direct access to the development team from higher-up stakeholders. Part of a manager’s job is to manage expectations, both to his superiors and to his subordinates. And yet, higher-level stakeholders and members now suddenly have full access to the fine details of what the development team is working on.

A real problem here is when members of the development team are cornered into publicly answering uncomfortable questions, possibly by external stakeholders or maybe even by members of their own team. Such things should really go through a manager or scrum master rather than being laid out in a public shit show. It is not uncommon for such meetings to degrade into blame games.

Even in the absence of such situations, it is often uncomfortable for developers to speak (let alone report their progress) in front of a small crowd, even if it consists of their own direct colleagues. While the stereotype of anti-social developers may be questionable, in my experience I have observed that most developers feel intimidated when speaking in front of people, just as they feel uncomfortable when someone (even a direct colleague) sits next to them while they work. It is thus quite easy for developers to go on the defensive if challenged about their work during the Daily Standup Meeting.

And this, of course, is something that should be completely avoided. As any manager worth his salt would know, you should never, ever reprimand someone in front of other people. This is also a fundamental flaw of retrospective meetings, although that is beyond the scope of this article.

Finally, the routine of the Daily Standup Meeting makes it convenient for people to provide updates and feedback during the meeting itself, rather than spontaneously as needed. Communication should be spontaneous and immediate; that is what keeps things efficient.

A trend I have seen is for companies with poor communication to turn to agile ceremonies to try to resolve the problem. Little do they realise that they are making it worse by adding more ritual baggage and introducing more middlemen. There is no substitute for real and effective communication.

What Alternative is There?

Honestly, what was so terrible about the good old system of hierarchical reporting lines? Think about it:

  • You talk directly to your manager when you’ve finished your work and need to work on something new.
  • Your manager can ping you periodically for progress, but otherwise you can focus on your work.
  • If there are impediments, the manager can bring the right people on board.
  • If you need to talk to some direct colleagues (e.g. to integrate with their API), just do so. No need to have the whole team in a meeting for that.
  • Requirements and other outside interferences go through the manager first.
  • Feedback and criticism take place one-on-one with the manager.
  • Each manager reports to their manager. No need for crowds.

That just about solves all the problems I’ve described earlier: notice the contrast of involving only the people who are necessary, as opposed to everyone. The important factors to make this work are having a manager who is organised and has excellent people skills, and that everybody on the team is able to communicate efficiently and effectively.

Agile methodologies will remain a reality for many years to come. But are they really an improvement?

Update 11th September 2017: Here are some reactions to this article on social media (might require login):

Elements of Football Management in Software

My recent return to playing Sensible World of Soccer is not just fun. After all, team management has been happening in the football scene for far longer than the software industry has even existed. There is some serious stuff we can learn there.

So after three successful seasons that turned Hibernians (a local team that most people have never even heard of) into a winner of all the major football leagues, I decided to take up managing Partizani Tirana, the team that won the Albanian Premier Division, but that is similarly crap on an international level (at least in the game).

I could have remained managing Hibernians, now a stellar team, for the fourth season. But while it is enjoyable to win, the real challenge (and fun) is in watching people grow; learning their strengths and weaknesses, and putting them in the right formation so that they can work together with synergy. As for the old team, it is my aspiration in all aspects of life to leave things better than I found them, and my old boss certainly didn’t mind decorating his shelves with the trophies I won:

english_001

This funny guy is my new boss in the game:

english_002

And this is my new team:

english_003

I don’t know these guys, and I don’t know how they play. So how can I effectively manage them?

The first thing you need to do to manage a team is to learn their strengths and weaknesses, i.e. what they’re good at, and what they need to improve. So after playing a few matches with this team, I can learn about their skills: who are the fast guys, who have the best ball control, etc.

Everyone can be useful. If one of the attackers is not great at finishing, for instance, he can have a supporting role for the other attacker. The trick is in finding the right role for each team member so that they can be useful to the team.

While you can often make adjustments within the team to address weaknesses, sometimes this is not enough. For instance, with Hibernians, buying a fast midfielder with great ball control gave a great boost to the team. He would support attackers in offensive strategy, run back to help defenders by intercepting opponents, and basically go everywhere to support the functioning of the team.

This midfielder is an example of a playmaker. The playmaker is essentially a visionary, a strategist, and a catalyst for the team to achieve its goals. The playmaker is not necessarily in a leading role. But he is respected because he makes things happen; he brings the team towards success, and also helps it get through the tougher situations.

Software teams are not very different. Developers come from all sorts of backgrounds, and have different skills and comfort zones. The manager who takes the time to learn about their abilities will be in a strong position to allocate his resources where they are best focused.

Playmakers in software are sometimes called catalysts (as in the wonderful anecdote in the Peopleware book). Whether they have a leadership role or not, they play an important part in helping teams to gel, solving complex problems, working on essential infrastructure, and formulating the technological vision of the team.

Managing software teams may be something that appeared over the past few decades, but in many ways it’s not very different from team management in general. Looking at older disciplines such as football allows us to gain insight into management as a whole, and they can very well serve as analogies for what we do in software.