I’ve been working as a technology professional for a little while now. For a long time, I chased the stick of “this or that tool,” and held this notion that the “next thing” would somehow “fix” whatever problem I was trying to solve (real or perceived). Over time, my perspective has changed quite a bit. This post outlines my current thinking, and describes a model I’ve come to refer to as “People, Process, Tools.”

If you’re reading my blog, I assume you probably work in technology. Given my focus on topics spanning things like programming languages, I also believe that’s a fair and safe assumption. Like me, you probably at some point, or even at this point, think “we need to implement technology X for reasons.” In an extraordinary number of cases, I would likely agree with you about it. Consider the following, hypothetical (but not altogether unrealistic) monologue:

My team is using SVN, but I think we should move to Git. Everybody’s using it. By switching, we would gain access to more advanced tools, capabilities, workflows, and every candidate we interview cites us not using Git as a reason for why they didn’t accept a position with us. It’s also the most popular version control system for Open Source Software (OSS). Angular even comes with a pre-built .gitignore file when I create a new project!

Many of these things are real motiviations to adopt Git. A lot of University students use Git for their software projects in school. As a professional, I always ask what version control system is being used, and if it is not Git, ask if the company has plans to move to it. I really love Git, and really don’t like the other tools I used to use after using it!

Here’s the problem: Git is a tool, albeit a very powerful one. Let’s change our scenario: instead of the company using SVN, let’s assume they’re not using any version control system. Instead, let’s pretend that they clone an entire folder to make a version increment. Let’s further suppose that changes are never propagated back to the original folder. If a fix needs to make it’s way into multiple versions, then the entire process is difficult to manage, because it’s difficult to assess where the actual problem exists in the system. In this scenario, you can say you want to adopt Git, but your version control process is either only loosely defined, or is altogether undefined. “All the cool kids are using it” is not, by itself, a great reason for making a change, because at this point, you’re dealing with a process problem.

To be sure we’re all on the same page about where I’m at, and where I’m going here, let’s agree to settle on two things:

  1. Git is a revision control tool
  2. Revision control is a process

In the first scenario, where the team already has a process, they’re expressing the desire to use a different tool. In the second, there are several things the team ought to consider:

  • Is our revision history valuable?
  • Is there any aspect of our existing workflow that will be broken by this change?
  • Perhaps the change will not break our workflow, but as a result, we need to change parts of the technology implementation to maintain compatibility.
  • Are the benefits of changing valuable enough to justify their costs?
  • Do we have time to do this right now? If we make a change, are we abandoning other more valuable work?

In some cases, there are clear answers to the questions posed above:

  • Yes, there is other work that is objectively more important than this. The reason we can afford to put it aside is because making a change will increase our productivity (by increasing speed, or reducing errors).
  • After assessing the changes that need to be made to our tools, it’s clear that our process will be more stable.
  • By standardizing our toolset, we will decrease the cost of onboarding, and eliminate activities that are not core to our business (distractions), and close a knowledge gap in the process.

Often, answering the original questions brings about additional considerations:

  • Yes, we can maintain compatibility with the workflow, but our documentation will need to be updated so the team can continue to function.
  • Yes, we can update the documentation, but some members of the team may need specific training, because some aspect of the process will be different following the implementation.

The but in the two points above highlights that we probably need to do better planning, to ensure we can maintain some degree of steady state in the team.

The second point touches on the most important part of the team: people. As a rule of thumb, I believe that technology is easy, and people are (sometimes) difficult. In general, people don’t like change. It makes us uncomfortable. On several occassions, I’ve heard people ask me, “what’s wrong with the way we do this now?” I’ve also asked this question of other members of the organization several times. I think a significant aspect of our resistance to change is due to experience, and recognition of the fact that change requires work. This also requires commitment: people must believe that change is not only necessary, but also that the right changes are being made.

The people part of this “People, Process, Tools” model is by far the most challenging to me. People, in this model, refers to the culture of the organization, all of it’s individual sub-cultures (a person’s experience in the organization will change, depending on the team they’re on), and the individuals. To make change successful, you’ve got to start at the top of the model with people. A process will not change itself without external influence, which requires people. People will not change something if they don’t believe there is a need to do so. Once you’ve engaged your people, you can start to make progress on your process. Without proper engagement of the right stakeholders, you run the risk of your process altogether failing.

I’m sure I’ll write more about this whole model in the future. For the time being, I can distill it into three points:

  • People are the most important part of the organization. No organizational pursuit can succeed without commitment from people at all levels.
  • Processes enable teams to manage chaos. If a process is not effective or valuable, it should be either improved, or abandoned.
  • Tools enable processes to become more efficient and more effective. Tools are components of the process, but they are not your process.

I would never set out to say that what I’ve outlined above is the only way to think, that this idea is unique, or that organizations everywhere should immediately change their operating mode. The content of this article is a distilled version of the mental model I apply to organizations. When I want to change something, I try to start here. I may have a great idea for how to achieve something for a team, but it may not make sense when switching between contexts (teams, companies).

Closing Notes

I consider myself to have arrived at this mental model “on my own,” in that nobody has ever attempted to pitch it to me in the past. With that said, a quick internet search yielded an article on Medium, a page on a site called Managed Agile, and a whole heap of other articles using the same tagline of People, Process, Tools. The idea is hardly unique or original. I most likely arrived at it through osmosis. For how many articles I immediately found discussing it, I have to assume it is valuable.

Anyway, that does it for this post. I hope the ideas are relevant to you and your team, and I’d love to hear your feedback! Feel free to contact me on LinkedIn, Twitter, or any of the other contact methods I’ve listed on the site.

Thanks for reading!

- Brian