The Case of the Missing Galvanizer: Unblocking Project Flow with the Working Genius Model
The 6 Types of Working Genius model was created and is owned by Patrick Lencioni and his consulting firm The Table Group. It is not my own, nor do I work for them.
We had everything laid out, every step along the way for updating the application's architecture. Incrementally implement new features in the new system while systematically removing the old. But when it came down to it, we continued getting the standard "but it would be faster to implement in the old system" argument at standup. We were going nowhere.
Then I discovered it. A model which provided a potential answer, 6 stages of project flow, 1 of which we missed. What the heck is "Galvanizing"? Well, let's try it.
It worked. I got a call from the tech lead who was in shock when his manager said "Why are you not working in the new architecture?" The project moved for the first time in months.
The 6 Stages of Project Flow in Software
For those not familiar with The 6 Types of Working Genius, here is my overview of it from a software development perspectives.
For each one, I'm defining what it is from an individual and how it builds energy, and also a quick line towards how it affects project flow within the software development lifecycle.
Wonder
The Genius of Wonder is the natural gift of pondering the possibility of greater potential and opportunity in a given situation.
From a software flow perspective, this is the user story or sometimes epic, the technical issue, the problem to be solved looking for a solution through UX to implementation.
Invention
The Genius of Invention is the natural gift of creating original and novel ideas and solutions.
From a software flow perspective, the team is coming up with a solution to implement the story provided by the wonder.
Discernment
The Genius of Discernment is the natural gift of intuitively and instinctively evaluating ideas and situations.
From a software flow perspective, this is the validation and transformation of the solution provided by invention. We often consider this "refinement" of the stories and tickets.
Galvanizing
The Genius of Galvanizing is the natural gift of rallying, inspiring, and organizing others to take action.
From a software flow perspective, this is getting all of your stakeholders on board. This means your product owners/managers, scrum masters/agile leads, developers, managers, and everyone else who may have some concern on the project. If it's within a peron's the circle of concern, add them to the train!
Enablement
The Genius of Enablement is the natural gift of providing encouragement and assistance for an idea or project.
From a software flow perspective, this is making sure you have the resources necessary to provide autonomy for the team to implement it: tools, people, budget, requirements. This is getting that backlog filled with all the work to be done so there is a clear-cut path to completion.
Tenacity
The Genius of Tenacity is the natural gift of pushing projects or tasks to completion to achieve results.
From a software flow perspective, this moving those cards to the done column. Each piece getting done, getting more excited about what is being completed.
Back to the story
In the story above, I noted we skipped the "galvanizing" step, so I will clarify that a bit. We went through months focused on the first 3, and writing up massive amounts of documentation around it.
There were a few problems (wonder) we were tackling, from teams causing massive amount of money stepping on each others toes, legacy technologies harming both the support and room for growth for the engineers, to feature failure rates. The solution (invention) focused on creating team autonomy and incremental changes, and validation of changes (discernment) was done through massive amount of documentation, proof of concepts, and reviews.
The challenge we landed was every developer and tech lead were ready to implement. We planned out and communicated every step on how to do it (enablement), but we couldn't actually start going with it (tenacity).
As I learned about the above model, there were two realizations that happened. First, the directors and managers were not 100% on board with the plan. Second, we had no natural galvanizers, so no one actually desired to do it. In fact, I would argue that in all likelihood, it's sitting on most people's frustrations, including my own. This wasn't just a problem with this project, it was a problem with all of them.
Discovering My Form of Galvanizing
I knew what I had to do, and no idea how to do it, so I experimented. I met with every tech lead, manager, and director one on one, and I listened. Every concern, every potential problem, everything they thought was good to great. All of it. While I gave a little feedback in those meetings, that wasn't the goal, the first was to listen.
After hearing each one I gathered them all in a (virtual) room. I first noted that while some of the problems "might" occur, we have backup solutions written and documented for each one of them. I then made a statement that might have been a bit manipulative (and gusty). I asked them that if we do run into any more problems, to extend trust to their tech leads, that we would find a solution. One of two things occurred: Either they trust their tech leads, or didn't want to admit they do not trust their tech leads. Either way, it worked!
The Case of the Missing Galvanizers
As part of the trainings and discussions for the 6 Types of Working Genius model is that galvanizers come with rather high bursts of energy. When not utilized correctly, it's easy for a galvanizer to frustrate a team, not to mention that within IT we still have a natural bias towards shy introverts, and sadly be considered "not a good fit" even during the interview process. As I give multiple introduction presentations each year within the tech community, I continue to have a lack of galvanizers in my talks (My last one of 50 people had 0).
However, we are also taught that each of us nees to learn to put on "all 6 hats" as needed, preventing turbulence in the project flow.
So, taking a step back: are you seeing blocks in any of your projects? Which step is the problem? What hat can you put on today to make sure that project runs smoothly?
If you are interested in a more thorough overview, you can check out my sessionize profile for upcoming presentations or contact me through it for a free lunch and learn overview for your team.