Monthly Archives: August 2017

Myth of Management With No Hierarchy


Leaders exist; therefore, hierarchy exists. A flat organization is not truly flat, it is made of many leaders. Those leaders have the responsibility to train others to replace them. The company has the responsibility to help those leaders be successful and be diligent on keeping things safe.

A flat organization is not truly flat, it is made of many leaders. Click To Tweet

Leaders are Essential

‘The Harvard Business Review’ has the article: Hierarchy is Overrated. This article paints a very favorable view point of flat hierarchy, but does not address the need for leadership at all. People will become leaders. This is an essential and natural process.

However, much of what needs to be accomplished by leaders, functioning in a flat hierarchy, is not natural. One of the main responsibilities of these leaders, is to move to stop being a leader, the sooner the better.

The way a leader stops being a leader is to train and inspire. Say that someone feels passionate about team building. They take up the reins, figure out ways to start building team communication and unity. They start the ball rolling. Now they need to look for someone else who cares about team building. They will collaborate, train, and inspire them to both take over and train someone else.

Potential Problems

There are a host of potential problems. Everything from dissatisfied employees to locus of control. Most problems will stem from one of these three root causes:

  • Denying the existence of leaders
  • Team not trained in essential leadership skills
  • Organization not really being flat

Leaders Exist

Leadership needs to be recognized, and its existence acknowledged. This allows an organization to better define how leaders behave and what it means to be passionate about some aspect of the organization. Don’t deny them, embrace them, try to understand them.

Everyone Trained as a leader

Train everyone to be leader. This is a lot of work, but it pays off as people can step up and handle issues and opportunities that they feel passionate about. Leadership can be more easily distributed and handed off from one leader to another. Everyone is capable in guiding and supporting leaders as they venture into new ideas and interests.

Here are a few sources I recommend:

A Flat Organization

Having an organization that has a distributed hierarchy can be challenging. The leadership, the people with the titles, needs to support it. They must trust people to do the job, and enable everyone to be trained. The highest paid people in the room have the greatest potential to do harm with the simplest word.

So, there is a need to prevent their hidden biases from polluting down into an unintentional hierarchy with certain people being ‘more equal’ than others. This can be done by really paying attention to building a safe environment. By encouraging those beneath them, in title at least, to contradict them and actively stepping back, these biases become smaller.

Giving up Control

The goal of every leader, should be, to eventually not be the leader. Each person should be looking at passing the torch, and ensuring multiple people can replace them. If this is not done they become the bottle neck and get in the way of success. The idea is that everyone can take a vacation and nothing stops working.

Each leader finds someone else who is passionate about the task at hand. They share responsibility, and train as needed. Eventually they will stand back and give their protégé or partner a chance to run things.

In Conclusion

A truly flat hierarchy does not exist. This is a good thing. What real world flat hierarchies enable is everyone with the inclination can be a leader. There are difficulties which can be overcome with hard work and trust. It is rewarding to work in one of these organizations and they can be more effective if you acknowledge the existence of leadership, train for it, and upper management supports it.

The Power of a New Voice


Too often the person with the least experience is ignored. This is a shame because they are often the person who can lead us to the most significant insights. They will see things we overlook or have become accustomed to. They can help us question the things we have started to not question. They are a powerful voice for improvement.

A new perspective can help us question the things we have started to not question. Click To Tweet

Question Everything

Like @WoodyZuil says: “Any method or practice we use without question should be questioned.”

The problem is if we are practicing something without question, we can often be blind to the fact that we are practicing it without question. A new set of eyes can see these things, but we must encourage them to point them out. If not, we risk that they too will become accustomed before we have gained benefit from their newness.


The problem with capturing input from someone who is new, is that most people do not feel comfortable giving feedback while they are new. This means that we must be extra careful to foster that feedback. It is something that must be intentional.

The first step is listening. When a new person offers input, listen. Use both Active Listening and Comprehensive Listening. Do not interrupt, and take a moment before replying. This shows respect for what they have to say, and consideration of their point.

The next is to treat the comment and question as if it is valid, and wanted feedback. They may not understand all the context to the thing they are questioning. That is the point. Do not explain to them how they are wrong, instead explain to them how they are right. That does not mean that you do not explain your context, but instead use it understand what they offer.

What if they are wrong?

They will often be wrong. The suggestion, or question, will be wrongly worded. They will most likely not understand what it is that made them feel the way they felt. Don’t let the fact that what they say is wrong stop you from learning. Instead, examine the situation. There will be truth there, and that truth will lead to improvement.

At the worst case, if they are utterly wrong then you will have provided the opportunity to learn in a way that makes them feel appreciated. This learning will be retained longer. It will encourage them to voice more, and thereby learn more. Eventually they will teach you something, because they are willing to voice what they don’t understand.

The Warning of a Silent Voice

Pay attention to what is happening regarding the new voice. If that voice is silent, this is a waring. It means that there is something that is causing that person to fall silent. It means that the team is not welcoming that person’s insights, and not listening and accepting of what the new voice offers.

This is the loudest indicator you will often get to small problems on a team. These problems can- not always, but definitely often enough- grow into big noisy, and explosive problems if not handled at this point.

In Closing

It is hard to listen to the point of view of a new person. That person may not know the social norms, or the current environment. It is easy to just brush off what they say, as they do not know better. However, when we do ignore the “new voice” we lose a lot of valuable insight.

Listening to the new perspective is not always natural but it is crucial. Click To Tweet

The Things We Say

I want to retire certain phrases from programmer parlance.


We are not clear in what we say. We use incorrect metaphor. We choose vague terms instead of better ones. Let us trim some of the excess terminology and jargon.

We use incorrect metaphor. We choose vague terms instead of better ones. Click To Tweet

Technical Excellence

This terms vagueness is its undoing. Almost everyone I meet has a different definition of what Technical Excellence means. To some it is a synonym for Extreme Programming. To others it is learning design patterns or continuous improvement.

The above assumes that the person saying the term has good intentions. I have also heard this term used as a passive aggressive way of saying that someone is a poor programmer, by telling them to strive for technical excellence without specific feedback. Calling someone a poor programmer without giving guidance on what needs improvement is useless at best, discouraging and defeating at worst.

Instead of using technical excellence, let’s say what we mean. If that is Extreme Programming, let’s say Extreme Programming. If it is adherence to corporate coding standards, then document the standards and talk about the standards document. If we want to critique someone, take the time to critique them in a way that is helpful. Encourage growth and improvement rather than attacking.


Again, simple is an extremely vague term. What is worse is that we acknowledge how vague this term is by modifying it with: Simple isn’t easy. As if this sound byte could explain what we mean. This suffers from all the problems of “Technical Excellence” and really doesn’t say anything useful.

We spend so much time talking about making things simple and then engaging in a long conversation quantifying what we mean. Why do we do this? The term “simple” just causes confusion, debate and eventually is shortly forgotten.

It is amazing to me how much energy we spend saying nothing rather than what we mean. If we could talk specifically about the types of complexity we want to avoid, we allow for improvement. We start the conversation that moves us into a better place.

Remove confusion, add clarity and forget simple.

Technical Debt

Technical debt was a good metaphor. Past tense. It was created for a specific reason, it was to explain the causal effect of decisions to bankers. It was not created to discuss the state of the code between developers. So, let’s stop using it for such communications!

Instead of technical debt, let’s talk about Anti-patterns or Code Smells. Both have names for specific things that can be addressed. They can be researched and understood. Better yet, there are know ways to move from these potential problems to good patterns.

Lastly if we are talking about the state of code caused by a ignoring problems over a long time, then even the team “Code Rot” is better at describing what needs to be said. There is real meat in using directed language to discuss the state of a codebase between developers.

In Short

Stop being vague right now. Don’t mix your metaphors. Be clear and intentional. If there is better language that can be used to describe what you want to say, then use it. Increase your ability to be understood by thinking about what you are saying.

Stop using 'Technical Excellence', 'Simple', and 'Technical Debt'. Start communicating effectively. Click To Tweet

#NoEstimates Story Sizing

A way to determine if a story is small enough without estimating it.


“No Estimates” is a modern movement in software development that focuses on eliminating wasteful estimates. However how do you know if a story is small enough to be accomplished without estimating its size? There are a series of rules that when followed guarantees a bite size bit of work.

There are a series of rules that when followed guarantees a bite size bit of work. #NoEstimates Click To Tweet


“No Estimates” is built on continuous delivery of valuable product. That means that the business must be able to measure the output of a development team in near real time. If releases are regularly weeks or months away, then you leave the business with few tools to measure with. Faster the delivery the better they can measure. Stories need to be small enough to complete daily.

How do guarantee that the average story is small enough to be completed in a day without estimating?

The Rules

There are three rules that can be followed to ensure that a story is as small as possible. In all three rules, the word team means much more than the development team. It means the whole project team including the developers, the product owners, testers, management, executive management and anyone else who has a stakes in the product being delivered.

  1. Does everyone on the team have the same understanding of what the story delivers, and what need it addresses?
  2. Does everyone on the team have the same understanding of when the story is completed?
  3. Is the story free of any known preconditions?
Three simple rules for sizing stories in #NoEstimates Click To Tweet


Gaining understanding about a story that crosses skill and role boundaries is difficult. To better communicate intention, we must be communicating simpler ideas. The first two rules do a lot to limit the size and scope of a story.

The first two rules also ensure that the right thing is done. A shared understanding means a shared vision and shared responsibility. If we understand what is to be done, and when it is done then we do not mistakenly build the wrong thing.


Once everyone understands what is to be done, and when it can be considered complete then we have a certain level of understanding about the story. If at that time anyone can think of a precondition that must be done before the story is complete, then the story is too big to be worked on. Maybe it is time to work on the precondition, or something else entirely.

The operative word in the last rule is “known”. We could spend an infinite amount of time looking for and understanding preconditions. It also goes without saying that we may find new preconditions as we start working. The important thing is that no preconditions are discovered in the process of gaining group understanding.

During the doing of the work, if we do discover a precondition we then need to decide if we continue or abandon the current story? Most often we can continue, especially if the precondition that was discovered meets the 3 rules, which means we must communicate our progress effectively.


In short, by following the three rules we can ensure work is taken in bite size chunks, even without estimating.