Running Podular Teams
One of the things that has brought happiness from the Connected Company book being out for nearly three years (now in paperback), is getting the idea of podular teams and organization out there for a wider understanding. From 2001 onward I ran my product and project teams in a podular manner. Since then I have helped many organizations I have worked with as clients adopt this approach so to be more nimble, efficient, productive, and keeps the teams members happy as well as management.
This works well where there are a diversity of projects that have different cycles that need different skills for a duration, or are short to mid-range in length (less than 6 to 9 months). This does work well for longer projects as it helps with staffing when their is any turnover in the pod.
What is Podular?
When I started running my teams I had a fixed set of people working under me in my program area and a wider set of projects. The team members had a wide variety of skills and various depths of strength and experience in those skills. The simple overview is, to stay on top of my team and project needs I set up a simple spreadsheet with the names of team members on the horizontal rows and skills running along the top of the columns. In each cell I put a 1 to 5 ranking (5 being the highest) for that person’s skill and expertise level. To build a project team I would assess the skill needs of the project and the project timeline and review the program’s team to right fit a team to each project.
Other program managers and my upper management called this matrixed team management, but outside of this the term matrixed organizations had a very different meaning. When working with Dave Gray on the Connected Company book he brought up the conflict with the term matrix (matrixed organizations were in the “bad thing cycle”) and started calling them podular teams, which worked well as that is how they functioned, as a self-sustained pod.
The teams when set up could mostly run themselves autonomously, mostly because of the people I had in the program team. But, often there was a person senior enough that could keep an eye on how things were progressing. If things were not running well I would get a heads up as a manager and help sort out a solution. Many times I was on the team, not as a manager, but taking one of the roles that needed depth of a skill set for a duration.
How to Set It Up
Setting up podular teams can be done in a spread sheet, but a couple times I have built quick web applications to serve the purpose. The assessment of skills (all of them) is essential. This can be through professional assessments, team review by peers, and / or a managers assessment. Keep in mind that over time the skills ratings will change. It is best not to work off of job descriptions as those are most often very off target. It can be good to sit with each person and run their assessment by them. Keeping to a 1 to 5 rating makes the reviewing with people a little easier. Don’t assess the top rating for a skill based on their being the best in the pool of talent as there may be a need for somebody with deeper skill and experience at some point.
When you have the individuals rated on their skills and you are sure you have all the skills listed (keeping to relatively broad categories can be helpful) it is good to color code the ratings and look to make it easier to see the gaps or potentially thin areas in the pool.
Next take a couple projects that are have been running and map the people to the the team and look at what sort of skills are needed. Look at the make-up of the teams as well as the pool of candidates. Look at where there may be weaknesses in the pods at times based on cyclical needs. You may find that there is two days of work for a skill at a level 5 each quarter, so starting to map the pod over various durations of time is helpful, from weeks, months, and quarters.
Next Steps
There are a few of things that running a podular team environment needs that make it a little more complicated. The first is maturity cycles of a project. Projects have three distinct stages: 1) Creation; 2) Iteration; and 3) Maintenance. Initially when I added this I kept it as a column in the spreadsheet for each person, but I found it really applies to each skill. The skills and capability to fit into the stages is essential as each stages takes very different mindsets and approaches, as well as personality type / temperament to handle that stage well. Shifting somebody with a “4” skill rank that has only done maintenance to a creation stage role is often a quick way to start trigger problems in the pod on a project.
The second is growing skills. One of the things that quickly jumps out when running teams in podular environments is overlap of skills, as well as gaps at various levels. Another thing over time is the skill levels for individuals change, which changes the make-up of the podular teams and the pool of people over time. I started keeping a second sub-column in each ranking to track this change over time. At one point I turned the second column into the individual’s goal column, which was set during formal reviews and casual reviews to learn what the skills that person had a desire in improving. Eventually, this turned into a third column and I brought back the rating change column. This meant I had a “Last Review”, “Current”, and “Goal” column for each person’s skill ranking. The “Goal” column really helped with setting podular teams to take somebody with a high skill ranking and pair them with someone wanting to improve their skills in that area. The person there to shadow and get some hands on experience form someone with more skill and experience nearly always was in that pod because of some skill they had a skill match for on that project.
Tracking things in this way also means traditional reviews are relatively easy to do as progress can be tracked as well as contributions. In working with other organizations, those that have team members providing feedback across a project makes review and assessment easier as well.
The third is hiring into the pool. Running any group over time leads to hiring people. This can be to replace somebody who is leaving or for newly created roles / positions. Running things in a podular manner and keeping track of projects, pods, people, and their skills means there is a really good view into what skills are needed at what level to fill that new opening. With monitoring people’s growing skills (as well as atrophy) looking at a pool of people, their skills, and the needs on projects means seeing the needs of the new hire is rather clear. This can be difficult in organizations with strict job descriptions and roles that are only updated every two to five years. But, most often it means the role is easy to write and right fill, if skill levels and other fit can be determined well.
Building Pods
When the framework is set the next is taking projects and teams and converting them to pods. The big shift is going to be the pods most likely are going to be a little more fluid than they were prior, so to match changing skill needs over the life cycle of a project or team needs at various points. Turning them into pods often means these pods will run a little more autonomously over time.
This means the role of the person managing, if they are are not a contributing member at all, is going to change. Their role is going to be less managing what happens in the pod and focussing on clearing the way for the people in the pods to do their work. The manager will openly check with the project owner as well as those in the pod to ensure things are running smoothly and assess upcoming needs or smooth out any bumps that arise. Often the number of people and projects that are being managed will rise. The manager is often the person who will work to help get resources and answers to needs as they arise. The manager is also the one keeping an eye on budgets and burn rates, which becomes essential when bringing people in and out of the pod to get the best skills mix as needed.
The pods will need a really good platform for team communication, coordination, and collaboration. This needs to be open to the person managing as well as fully open to people that drop into the pod to fill in roles. Email doesn’t work as a part of podular environments. Getting a tool that works well can be a less than easy task, but it is an important task to ensure the right fit. The client or project owner may or may not have full access to the tool, but a good view into progress, deliverables, needs, and probability of completion is a good view to offer.
Putting a pod together can be done in a self-selected manner, in a curated approach, or one that is mixed. While many organizations find success with self-selection, where the pod has the opportunity to self assemble, the downside is this only works with some skill sets, personality types, and work environments. Where self selection really falls flat, if not fails spectacularly is skills that are often strong with people who are introverts and needing those skills in the pod. In many organizations this can be more than 70 percent of the teams and pods that are needed to be assembled. Self-selection also tends to favor those who have working knowledge of others, which makes new hires and others that don’t have experience in the pool on the outside, with pods often choosing a known, but poor fit, rather than a better fit that is unknown. The upside of self-selection is pods get built with people who tend to work well together.
The curated approach where a manager or pod builder works to assemble a pod with the right skills, levels, and availability. The availability is often tricky and can take some negotiation to get a key role filled with the right person for a duration that is needed. The curation approach mixed with some self-selection can work well also, and is often a really good way to do things over time.
Really Understanding Needs
The biggest hurdle to this is deeply understanding needs. This is understanding all the roles needed and skills. One thing that becomes quickly clear is there are often skills needed beyond what traditionally has been considered. With podular environments the ability to bring in people with skills that fill these gaps becomes second hand and seems natural. This leads to the pod looking to optimize their output and try to understand things that are less than optimal. This short fall in skills and gap in skills continually arises when implementing and deploying social / collaboration / communication platforms in organizations as there are 14 essential roles needed and most are trying to cover it with 2 or three of these skills roles.
Over time the skills needed in the pods becomes clearer, but often bringing in a consultant with experience in podular environments and the domain areas becomes a huge time saver to get things running smoothly early in this transition.