RSS Feed

Latest Entries

First time here?


Two Techniques to Avoid the Bus Factor In your Teams: Push and Pull

I spoke before on this blog about BUS FACTORS and how to get rid of them. A bus factor is calculated the the amount of people on your team or project who need to get hit by a bus before the project comes to a halt. There is something that only THEY know how to do.

I am revisiting this because there are many ways to get rid of it. Today I cover a couple. But first, a true story.

The Robot

In one of the projects I was consulting for a few years back, we had four teams and many bus factors relating to many things. One of them was related to the search technology the project was using at the time (sharepoint search…shudder!)

One day I saw the architect* running around like a headless chicken trying to figure out how to fix a problem. I asked him what’s wrong and he said “the search guy is out on vacation this week and not answering his phone. I have no idea how to fix this”.

It took a couple of hours until he found an external company that once provided these services to the project, and got them on the phone to ask if they knew how to fix this problem. Of course they did. They coached him on the phone what to type to reset some indexes.

I was sitting in the next seat listening to him typing word by word into the terminal, pressing enter, and then saying “ok now it works thanks”.

Then he hung up.

What a great loss of knowledge! Instead of using the opportunity to LEARN something about the problem, its causes and WHY what he typed fixed it, he simply made himself a remote controlled robot for the person on the other side of the phone.

I coached him to do the following next time:

When you find the situation has been solved, ask the following questions on the phone:

    • What exactly was the problem? (tag this type of problem in your mind. like a design patterns, we can have “problem patterns”)
    • What made you realize that was the problem? if you indeed realized it. (learn their thought process. learn to think like them)
    • What did the actions we just took mean? where can I learn the full syntax of those commands? (learn the solution pattern)
    • Who else around me knows what you just told me? (see how bad the bus factor really is. Maybe you just did not know who to ask? maybe you are the ONLY one who does not know how to do this?)


Pull Based Learning

What I coached him to do was what I call “PULL Based Learning”. Before I discuss that, let’s talk about why it is important to learn this pattern.

One of the best ways to remove bus factors, is by pairing. Pairing is an act of active learning where knowledge is constantly back and forth. A person asks a question “How did you do that?” . that is an act of deliberate learning.

But pairing is also hard to achieve in a culture where pairing was never a “thing” people do.  If you cannot get enough people to pair, or the bus factor is happening when a person from a DIFFERENT team knows something that your team replies on, it’s time to start encouraging active knowledge gathering, or active learning.

Active learning comes in two forms, or two directions:

  • Pull Based Learning: The person who does not know X asks another person who knows X to teach them about X in some way. They initiate a PULL of the information from the other person.
  • Push Based Learning: The person who knows about X asks a person who does not know about X to join them to learn about X. They initiate a PUSH of information towards the other person.


So pulling or pushing depends on who initiated the knowledge transfer. If you find that you have many bus factors, it is important that you teach and coach people how to work in BOTH directions:

  • When people who need to learn are too shy to ask for help, coach the more experienced people how to PUSH knowledge by asking others to join them in a task that will teach that person something new.
  • When the people who are the bus factors do not have many opportunities to share knowledge** coach the people with less experience to jump in when they see the bus factor doing something the less experienced person does not know how to do that affects them, and ask to join in for a few minutes to see how things are done.

Get Permission

This also means you might need to get an upper level manager to send an email or have a group meeting letting all developers know that “it is OK to do pairing,  ask for help, request someone to join you to learn new things – even if it means tasks take longer than estimated. it is OK to estimate tasks longer because you want to build these things into your iterations”.

In cultures where hierarchy matters a lot, this could be the beginning of the breakthrough you might be looking for – giving people permission to learn and teach is usually the thing most cited (by people I ask) as the reason why they are not doing it.

Bi-Directional Knowledge Handshake

Having only a single direction knowledge sharing culture is very ineffective.

In a project full of consultants, who love teaching, but also full of people who hate learning, knowledge will not be shared very often, and if so, with a tea spoon instead of a fire hose (which is usually what you need to start with in extreme cases)

In a project full of people wanting to learn, but having all the people with the knowledge be in a different building, company or country, mostly unavailable, knowledge will not be shared.

There has to be a knowledge HANDSHAKE for knowledge to actually flow through. otherwise we are talking about tear drops in the ocean.



* Remember that having a non coaching architect is having a bottleneck

** Maybe you should think about increasing the amount of opportunities?


What's your Position, Velocity, and Acceleration? by Neal Tibrewala

About Neal: Neal Tibrewala is the head of software development at L5 Software Group in Austin, TX

As a software consultant for 25 years, the thing that I've found the most useful is measuring to figure out where you are and where you're going as a team.

Let's take something like the number of known defects in a product. Most software projects track their defects using some kind of defect management tool.  Therefore, a team could know that they have, say 100 known issues with a certain product.   This is their "position".

Is this good?  Is this bad?  Is action required to address this fact? Often, someone will make a gut call at this point and say that it is either "fine" or "bad" and try to make a change.  I would argue that change is premature at this point.  As a team, having 10 defects or 100 doesn't tell you if you're in trouble.

Smarter teams will say:

"Aha!  We should track our defect rate instead!"  

Indeed, tracking your defect rate is the next step.  Take a certain fixed time period, say a scrum iteration, and track the number of defects fixed and new ones discovered to see the total number of open defects at the end of each iteration.  This is called the team's velocity.  In the example above, the team with only 10 defects could be accumulating new ones at a rate of 10 per iteration, and the team with 100 could be decreasing them at a rate of 10 per iteration.

Clearly that means the team that's bringing defects down instead of up is the team on the better course, right?   Maybe not.

The final step is to track your acceleration.  This is looking how the defect rate changes over time.  The team with a defect rate of +10 per iteration could be learning, thus, the following iteration be at +8 defects, then only +6, etc.  While the team at -10 per iteration could be slowing down, thus be fixing 8, then only 6, then -4, etc.  

This number is either plus or minus 2 defects per iteration per iteration (2 defects/iteration^2).  This is the team's acceleration, and this is the number that should be looked at most by the team's leader.

Learning will always impact position and velocity.  Spending time learning will slow a team down in the short term, but acceleration, measured over a long period of time, is the surest sign of a team that's learning or not.

A team that's not only able to adjust their position, but also control their velocity, is the kind of team that you most want to encourage. Changes that affect acceleration are powerful tools as they can have drastic impact on velocities over time.  Likewise, they can serve as early warning indicators as slowing velocity can be seen far before a project gets into visible trouble.


Audio Book - Notes to a Software Team Leader, Now Available

Good news everyone !

After more than a year in the making, the text version of my book for team leaders is in final production stages, and the audio version is now already available.

You can purchase the audio book in this link, or on 

I had it professionally narrated, and I think this book has some sound advice that will actually help you at work.

The Audio book contains 4 hours of professionally narrated audio in 31 chapters. Here`s a sample from chapter 1:



The audio will be available in several formats:

  1. Separate Chapter Based mp3s
  2. An .m4b file playable as an ITunes Audio Book

All these will be included in the zip file that you get upon purchase if you get it at (audible has their own format which is not DRM free I'm afraid).

I hope you enjoy it. I know I never have enough time to read all the books I want, so I`m happy that this book`s content lends itself to an audio format, that one can listen to in the car or in a gym.

If you have any comments or feedback, please let me know in the comments :)




Be a Book Reviewer for 'Notes to a Software Team Leader'

Want a free book? Willing to review it on Amazon when it is published? Willing to give me valuable feedback?

Fill out this form.


Audio: Preface–Notes to a Software Team Leader

Here is a little experiment. Below is the audio version of the Preface of my upcoming book “Notes to a Software Team Leader”.


I am thinking of turning this into a saleable audio book. How much should I charge for the entire book, with each chapter being an mp3 (book is about 110 pages)

and where should I sell it? (I do not live in the US, so cannot use Stripe)