Category: Technology


Bus Factor

How Not To Get Hit By It

By Scott Spratlen, Senior Vice President of Technology

When you hear the term “bus factor,” I imagine a few different images come to mind. Maybe it’s the impending headlights of a bus heading straight for you or a fleet of busses trekking across the country.  In and of itself, the term bus factor doesn’t sound like a negative term. On the contrary, it almost sounds powerful, unless you have already been exposed to it, or have experienced it firsthand.

The term bus factor represents the risk an organization or team takes when only one or a few individuals have key knowledge or skills which are not possessed by others on the team or organization.

To evaluate the bus factor in an organization or team, ask the question, what would happen if this person was no longer available or “hit by a bus” (hence the term)? Would the team be able to survive and at what cost? If the answer to that question results in not being able to operate without that individual, then the bus factor is very high and immediate attention is needed.

In smaller organizations, bus factor is common and almost unavoidable. As growth occurs and teams expand, it is also common for the bus factor to rise. This is because new employees, hired during a reactionary growth period, hit the ground running and pick up new tasks or simple tasks and begin to create their own bus factor while solidifying the bus factor of those already on the team.

Mitigating bus factor is an intentional process and sometimes a difficult one. Many of those holding onto knowledge and skills will feel vulnerable, and even expendable, when approached about passing items off. They will often react defensively and resist the change. As a company grows it is imperative to reduce and even remove bus factor in order to make continued and even exponential growth scalable.

The team I work with was wrought with bus factor, and it was only getting worse. We needed to do something quickly before it devastated our productivity. Our team of developers is a distributed team (not collocated), and essentially made up of two teams, one in each location, making this challenge even more daunting. So we did what seemed counter-intuitive, but necessary, we setup team leads and assigned them team members that are not collocated to them. Each team lead was given specific challenges to rotate the work items and a pair program was developed to share knowledge.

What came of this process was nothing short of miraculous. Efficiencies are skyrocketing, and team morale is continuing to rise. Why?  Because team members get to work on different projects all the time. They are no longer pigeon-holed for the bus factor project only they were stuck on, even if they were the ones intentionally holding on. Queues are shifting and workloads are much more balanced.

Benefits of Removing Bus Factor

– Knowledge and skills that are scalable

– Better leadership that communicates and shares

– Better collaboration and trust among the team

– Employees who provide value instead fearing being expendable

Side Effects of Bus Factor

– Siloed knowledge and skills

– Lack of sharing and trust among team

– Poor collaboration

– Selfish mentality

– Log jams in queue waiting for one person to work on them

It is essential to reduce and even remove bus factor, whenever identified, in order to reduce risk and improve efficiency. It is a difficult challenge to overcome if you are facing it, but one well worth the fight!


7324 GFS-4/24/2017



Service Oriented Software Development

By Scott Spratlen, Senior Vice President, Technology

I have always loved technology.  Even in grade school, I was doing basic (that’s the programming language name) programming on my Atari.  Typing code into the console, with one joystick and one button. Those were the good ol’ days, it took forever for the simplest program.  While I was working toward my Bachelor Degree in Computer Science I took a class that required building a PC from scratch.  Not assembling a PC with parts, but a bread board, wires, and switches.  While this home-built-PC did nothing more than rudimentary math, I became aware of all of the inner workings of what makes a computer actually work.  It boils down to 0s and 1s, continuous on and offs that cycle and combine to make some incredibly complex technology.  If one of those 0s or 1s aren’t set just right, then the instruction execution goes awry, and the computer doesn’t do what we think it should.  All technology professionals have been in that position before.

As we’ve begun this New Year, I have been reminded of that memory and how similar that is to a service-oriented development team.

A traditional development team creates a product that the company then sells.  Therefore, the development team has a certain visibility.  But, at a company like Gemini, our product is essentially the service that’s provided by our amazing people.  And, our Development Team’s job is to make these people as efficient and effective as possible.  With that, we are typically invisible to our clients, and that’s a good thing most of the time.  We are like a sound tech at a large concert: you would only really recognize our existence if there was negative feedback or bad sound, which is not a good thing.

Don’t misunderstand me, we are happy to directly interact with both our internal and external customers.  Our job truly is to provide support and products that best service the company.  The developers of a service-oriented company actually interact a lot more with stakeholders than a traditional development team.  Traditional development teams would typically communicate through an automated ticket system, and deliver to a business analyst or project manager, who in turn would hand over the project and interaction with the stakeholders.  But in our arena, there are lots of requests from clients and new requirements due to changes in regulations. We must be agile and available to interact directly.  There isn’t time to build and deliver in long cycles.

We do this by implementing a version of agility called Kanban.  It was originally developed by Toyota in the 1940s. Toyota’s focus was to eliminate waste (including time) and limit work in progress (WIP) by focusing on efficiencies and linear processes.  It works great for a high volume of small projects.  This process allows us to continually reprioritize and keep up with shifting demands while delivering automation, process, and product improvements in small iterations.

There are some challenges that go with a service- oriented development department.  A stereo-typical developer does not typically enjoy all of the personal interaction and shifting priorities.  It requires a personality type that can communicate clearly with stakeholders and can handle the constant shifting of priorities.  At Gemini, we have some of the best of the best developers that accomplish this on a daily basis!

We like to think of ourselves as that sound tech at a concert, or even the 0s and 1s that make up the computer.  Even when there is that rare occasion of feedback at the concert, or the computer isn’t doing exactly what you want it to do, we learn from those instances and grow as individuals and as a team. We are always working to provide the best possible service (both products and process improvements) needed to enable the amazing product at Gemini (its people) to be the absolute best they can be.