Personal Maps for Teams

Working in teams, or at least in good teams is a great privilege. You share a goal with friends and co-workers and get to work on that goal together. You're not alone in your efforts and you're part of something bigger. You get to learn from others and perhaps teach others. 

From an organizational and a personal level, teams also provides more flexibility. Individuals can bring their strengths to the table while have their team members help with their weaknesses. Without a team, an individual must be able to perform all tasks he owns on his own.

But, to get to work in good teams we need to first form / build good teams. And, teams are made of individuals so we need to start with looking at each person that is in the team (or may be in the team).

In previous post [Personal Maps] - we looked at using Personal Maps for evaluating individuals. However, Personal Maps are also important when forming a team. We can create a Personal Map for the team (as a team) - what is the role and what are the responsibilities for the team, what skill set does it need and have. We look at the Personal Maps of the individuals in order to see if the team of individuals satisfies the team's needs.

By working in teams - we get a lot more flexibility compared to having individuals work on their own. When defining the "Role" circle for the team's overall mission or responsibility, we can break the role in more than one way into individual roles to match individual needs and abilities. Also as a team we have the ability to develop new skills in individuals.

Overall, the team environment provides us with flexibility regarding which people we can bring into the team in order to make both the individuals and the team successful and happy.

The "Personal Map" concept can also be used at a higher level - forming teams into larger organizations. As the organization grows, we have even more flexibility - we can look at teams as individuals within larger teams - and continue to do so recursively.

The Evil Nameless Ones

Aaahh.. those evil ones! 
They always get in our way.

Original image was found here

You work at a company, trying to do your job and they keep getting in your way. Putting obstacles, making your life hard while all we want is to do our job and do good for the company.

It is always them - they seem to work for every company - they are soulless and nameless. Perhaps they have a Union too - an evil one.

Working with our enterprise customers I often hear the same complaints:

"The IT department won't let me configure this machine"

"Operations won't reconfigure the firewall"

And even at our little start-up I hear:

"Product Management changed the specs after we already started implementation"

"Management doesn't allow us to do X"

And one of my favorites:

"We're not allowed to deploy to production after 10 am"

In the last example, "they" don't even appear in the sentence. We're not allowed to deploy by some mysterious entity.

We're caged and we're hindered by these rules and there is no one to talk to about it.

What's the problem?

There are several big issues with using titles, tags and labels when talking about others. It may not seem like a big issue but labels and groupings can become a fundamental problem for a company.

They Vs. Us
Using labels creates separation. It is "they" vs. "us". "They" implies separate groups with possibly conflicting priorities.

Finality & Despair
When directives arrive from "them" or even worse, when directives just exist then there is a doomsday feeling, there is no way to argue against the directives. No way to question them or influence them.

Department stores sometimes will put a sign "No discounts". A sales representatives can just point his hand at the sign and tell a customer - "ahh, I wish I could help but you see the sign - It says no discounts."

This kind of finality discourages change and improvements and instead creates a feeling of defeatism and despair. If you think this is a bit too dark ask any friend who works in a big company about their feeling regarding rules set by Human Resources (HR) or IT.

Why is a name so important?
Demystify! A name means a person - it means someone we can talk to, it means someone we can identify with and someone with whom we can create a relationship. A name allows us to see that a decision is not done by some anonymous collective or higher power but by individuals and often just a single individual. We see these individuals as people, we know they have weaknesses and strengths and we realize that perhaps we can help them make better decisions and perhaps they can even teach us a thing or two.

One of the examples I like, and mentioned above, is a rule that was in place at a time I joined an engineering group. The rule said, no promoting/pushing changes to production systems during business hours. One day, we had a bug that was important to fix, and we asked the developers why is no one fixing it. The answer was "we're not allowed to push". Is this a company bylaw? Was the board mandating it? After some asking around, it came down to a decision a senior engineer made a while back. Let's call him Joe. After talking to Joe, he clarified the reasons behind the initial decision - Developers break production too often leading to failed business demos for the sales people. Notice another "they" here - "Developers". We discussed this and decided that instead of disallowing changes to all developers, we'll start tracking success/fail rate of push to production and also see who (names) is breaking production and why.  In some cases, we saw that junior developers didn't get proper coaching. In other cases, we had unstable build scripts. After resolving several issues, our success rate of pushes to production went up to almost 100%.

So, by removing anonymous barriers, we empowered our engineers which made them feel better. We were able to improve our processes and tools and we were able to improve our product quality.  And, along the way we made our rule book a little shorter. We now push to production around the clock.

World Peace
There are definite cases of bad work environments. There are cases of bad individuals and negative company culture. We may find that the person behind the anonymous "they" can actually be a pain in the butt. However, there are many cases in which the creation of personal relationship will lead to a better work environment, improved business results and happier employees.

As managers, leaders and individuals, we may want to continually seek to know more people on a first name basis, especially from other groups. We can grab coffee together. We can use a common love for a dog, or one-off project as an excuse to get to know each other. One on one meetings are a lot more powerful for connection building than social group events such as company meetings and can happen regularly.

Personal Maps

What do we look for when recruiting new members to our team? What makes them successful once they join? Why do some people need constant nudging to do a great job? Why do some people quit on us?

When hiring for software, we often focus on skills. Are they a good developer? Do they have deep understanding of technologies? We give them technical tests, we ask them to describe projects they have worked on before.

Another area of focus during interviews is on relevancy of their skill set. Do they know or can do what we need them to do?  Do they fit the role we have in mind? Obviously, we want to hire the right person for the job.

Of course, we also look to have good personality - nice person, willing to be a good team member.

So, what is the right person for the job? Is it just a good person with matching skills?

One area that sometimes seems to get less focus and direct attention is desires. What does this person want to do? Where does he wants to go with his career, now and later? This is their desires.

One way to visualize a match is using a Venn diagram:

Personal Map

The "Personal Map" Venn diagram shows the intersection of three key areas:

Role - What are our needs? The team's needs. This includes technical and non-technical needs.

Skills - What are the person's abilities and capabilities? Can he program? Can he design software? Can he lead? Is he organized?

Desires - What is  this person interested in doing? What topics cause his eyes to shine with excitement? What do they see themselves doing now? In a year? In 5 years?

The concept of a "Personal Map"¹ can help explore various scenarios.

How do we use a personal map? We want to first collect enough information to be able to describe the three circles and then build a mental image of how these three circles overlap. Perfectly overlapping circles would demonstrate perfect fit. We can then evaluate any misalignment and explore its meaning.

Let's look at a few examples.

Skills ↔ Desires

• Experience - a very common reason for mismatch between skills and desires is lack of experience. Junior developers coming out of school may have the potential / ability but lack experience. In other cases, senior developers may have experience with a different technology stack than the one currently used.
  
  If the person has a strong drive to learn combined with the ability to (quickly) pick up new skills then the mismatch can be overcome. Sometimes, we have a position that has too many requirements and make it hard to find an exact match. In that case, we want to find people that already posses the hard-to-get-by skills and are lacking on skills that are easier to acquire.  For example, picking up a new language may be easier than learning fundamentals of computer science, large scale system design, etc.
  
  When evaluating skills-desires mismatch caused by experience, we will do well to consider the amount of drive, passion and motivation that the person has for overcoming the gap as well as their ability to face adversity and challenges. This requires a strong personality.
• Cultural pressure and Ego - another common reason for mismatch between skills and desires is a perception one may have regarding role or title. In some cultures there is an external pressure to become a manager or a "chief". In other cases, the pressure is self placed by the individual.
  
  When the external pressure or drive matches the individual's skills you get a motivated person with a career path. However, if the external pressure does not match one's skills you get an employee that is hard to satisfy and may not be content. 
• Heart is elsewhere - In some cases, people do the job they do because they can and need the money but their desires just lie elsewhere. Someone may have wanted to be a writer or a painter or a ballroom dancer but happened to get a job in software.

Role ↔ Desires

• Career path - understanding a person's desires can also help us think of a career path. Individuals grow and change and their satisfaction and alignment with the initial role may change. In some cases people need changing their role to keep them interested.
  
  Discussing the intersection of role and desires also creates a stronger relationship and deeper understanding both for the individual and the team. This relationship creates stronger ties, helps retention and provides flexibility for the team as the team changes overtime. The discussion allows creating a shared future.
  
  When looking at career path, we want to take into account the skills set and future possible roles. If a possible future role requires additional skills then we have the opportunity to develop these skills before the need becomes critical. 
• Over-qualification - sometimes, user's desires are just way too big for the current role and even for future roles. If the person also has skills that match his desires then this may mean the person is overqualified for the job.
  
  If we suspect someone is overqualified, we may want to look for external factors that are leading the person to apply for the current job. Are they trying to relocate and use this job as a jumping board? Are the market conditions making it hard for them to find a job that matches their current skills/desires?
  
  In any case, over-qualification may lead to instability and churn. A "negative career path" is a red flag.

Skills ↔ Role

• Do their job - obviously, the most important thing to look for is for the individual's ability to do their job, satisfy their role.
• Versatility - having a wide variety of skills, sometimes beyond the current role's needs can provide the team with flexibility and better adaptability to changing conditions. Perhaps we need someone that can suddenly help with mobile development, or perhaps can help with customer support and partnership. A back-end developer may be able to pitch in and do some extra front-end development.
  
  Having a skill set that is bigger than the role can be a big positive in allowing us to react to varying conditions or it may mean the individual is overqualified for the position. Whether we get flexibility or an unhappy employee depends on their desires and their personality.

The personal map does not help us define what the role is or how to understand a person's desires and skills. However, it can be used as a thought exercise tool in evaluating people and understanding their fit within the team.

¹ - if someone has seen this kind of diagram before in another name please let me know and I'll be happy to attribute it to the right person.