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.
Wednesday, February 26, 2014
Thursday, February 20, 2014
Got Leaders?
Have you got enough leaders on your team?
It seems that many organizations have a surplus of managers - people of authority, and a surplus of complainers - those that see change is needed but don't act on it.
Unlike managers, it seems that we never have enough leaders. What defines leaders?
Leaders are people that initiate change and drive themselves and others to action.
Leaders are the people that bring energy to your organization and as such, it is easy to see that you almost never have enough.
Leadership can happen at any level, from top level senior employees to the most junior of the juniors. You may see that the bathroom always runs out of toilet paper half way through the day and you ask the cleaning crew to put some extra toilet paper. Leadership could be asking your co-worker to add a test after they introduce a defect in the product. Leadership could be emailing two people who may be unknowingly working on the same feature and suggesting they coordinate.
Activation Energy
Leaders provide the necessary activation energy, a catalyst or trigger, for action to happen.
A while ago, we had family visit our house. My wife left on some errands and all the adults were neglecting the kids and chatting in the living room. My wife returned home as it was time for dinner. She give everyone a quick look that clearly stated "rest time is over" and asked us to take care of dinner. A minute later we had several adults setting the table, warming up dinner and getting the kids to eat.
For the hard-core developers among us, I like to think of leaders as threads in a computer system. If all you have is a data structures, nothing really happens. Your program does nothing. But, introduce threads into the system and suddenly the program is active. Add more threads and you can do more things.
Nurturing Leadership
As managers, and even more so as leaders, there is a lot we can do to increase the leadership on our teams. While different people have different leadership abilities, we can influence almost everyone around us and help them unlock and/or increase their leadership.
Enable Leadership - With hierarchical reporting structure, we often create an environment that naturally suppresses leadership with junior staff members. There is a hidden message in how we operate that leadership equals authority or managerial title. However, by providing day to day examples we can show people that leadership can happen all the time and by everyone.
On one of my teams, we had several senior developers and one junior developer. The senior developers were very strong technically but were not very organized. They were often late to meetings, forgetting some tasks. The junior developer was a very organized and methodical person. We presented the developer with a challenge - "you may be junior and inexperienced but you're on time and organized. Could you help keep the rest of the team on track?". The developer took on the challenge - he would setup the conference room 5 minutes early and call the team in. He would send reminder emails on upcoming tasks. In addition, after having a positive experience influencing his team, the developer found other ways in which he could help the team despite being junior.
Protect Leadership - As people discover and explore leadership, it is important to provide a positive experience. Failed attempts at driving change can quickly lead someone to decide to give up on leadership. When we lead and try to drive change, we inevitably put our self at risk of failure and criticism. It is important that the environment is accepting of failures and mishaps.
Example: My son wanted to be helpful - "Dad, you forgot to lock the car so I locked it for you." Only problem is that I left the keys in the car when I went to get something from the house. I can still talk to my son about verifying that the keys are with us before locking the car next time but perhaps more important is to avoid instilling fear in him of taking action. He probably already felt bad when we had to go and find the spare keys, no need for any extra pressure on him.
Another example: working at a start-up, a lot of people put extra hours. People often work in the evening and even on weekends. Every so often, a developer has a pet project that they want to drive. They care about it enough that they're willing to do it on their own time. However, given that they already put extra hours on their regular work it means that picking up a pet project will actually influence their regular work. In addition, introducing new functionality means others will have to help with testing, perhaps new bugs / defects will be introduced. Gut reaction is to often persuade the developer to focus on current priorities. But, before we kill their enthusiasm we may want to think about how this will impact someone that has enough excitement about the company and the product that they're willing to put extra time to make it better.
Caring
At the end of the day, people don't drive change if they don't care. This means that a) you want foster good relationship and create a positive atmosphere so that people will care and b) you want to have the right people who care about the right things.
Looking at this from another angle - if people do not seem to drive improvements in your organization or team you may want to find out why. Wrong set of people? Wrong culture and atmosphere? Lack of leadership nurturing?
The right people - Some people care because they have a sense of professionalism and of doing their job well. Other people care about the users of their software and want to make sure they have the best product. Some people love other people and enjoy driving positive change. For each person on your team, you may want to identify their main drivers and motivators and ensure their motivation is not suppressed.
Building a strong team
Leadership is a critical element of building a strong team - a team that can operate independently, that is self motivated and improves on its own. We build good leadership by getting the right people and nurturing them to lead.
You know you're there when you sit at your chair, drinking your coffee and things are just happening.
It seems that many organizations have a surplus of managers - people of authority, and a surplus of complainers - those that see change is needed but don't act on it.
Unlike managers, it seems that we never have enough leaders. What defines leaders?
Leaders are people that initiate change and drive themselves and others to action.
Leaders are the people that bring energy to your organization and as such, it is easy to see that you almost never have enough.
Leadership can happen at any level, from top level senior employees to the most junior of the juniors. You may see that the bathroom always runs out of toilet paper half way through the day and you ask the cleaning crew to put some extra toilet paper. Leadership could be asking your co-worker to add a test after they introduce a defect in the product. Leadership could be emailing two people who may be unknowingly working on the same feature and suggesting they coordinate.
Activation Energy
Leaders provide the necessary activation energy, a catalyst or trigger, for action to happen.
A while ago, we had family visit our house. My wife left on some errands and all the adults were neglecting the kids and chatting in the living room. My wife returned home as it was time for dinner. She give everyone a quick look that clearly stated "rest time is over" and asked us to take care of dinner. A minute later we had several adults setting the table, warming up dinner and getting the kids to eat.
For the hard-core developers among us, I like to think of leaders as threads in a computer system. If all you have is a data structures, nothing really happens. Your program does nothing. But, introduce threads into the system and suddenly the program is active. Add more threads and you can do more things.
Nurturing Leadership
As managers, and even more so as leaders, there is a lot we can do to increase the leadership on our teams. While different people have different leadership abilities, we can influence almost everyone around us and help them unlock and/or increase their leadership.
Enable Leadership - With hierarchical reporting structure, we often create an environment that naturally suppresses leadership with junior staff members. There is a hidden message in how we operate that leadership equals authority or managerial title. However, by providing day to day examples we can show people that leadership can happen all the time and by everyone.
On one of my teams, we had several senior developers and one junior developer. The senior developers were very strong technically but were not very organized. They were often late to meetings, forgetting some tasks. The junior developer was a very organized and methodical person. We presented the developer with a challenge - "you may be junior and inexperienced but you're on time and organized. Could you help keep the rest of the team on track?". The developer took on the challenge - he would setup the conference room 5 minutes early and call the team in. He would send reminder emails on upcoming tasks. In addition, after having a positive experience influencing his team, the developer found other ways in which he could help the team despite being junior.
Protect Leadership - As people discover and explore leadership, it is important to provide a positive experience. Failed attempts at driving change can quickly lead someone to decide to give up on leadership. When we lead and try to drive change, we inevitably put our self at risk of failure and criticism. It is important that the environment is accepting of failures and mishaps.
Example: My son wanted to be helpful - "Dad, you forgot to lock the car so I locked it for you." Only problem is that I left the keys in the car when I went to get something from the house. I can still talk to my son about verifying that the keys are with us before locking the car next time but perhaps more important is to avoid instilling fear in him of taking action. He probably already felt bad when we had to go and find the spare keys, no need for any extra pressure on him.
Another example: working at a start-up, a lot of people put extra hours. People often work in the evening and even on weekends. Every so often, a developer has a pet project that they want to drive. They care about it enough that they're willing to do it on their own time. However, given that they already put extra hours on their regular work it means that picking up a pet project will actually influence their regular work. In addition, introducing new functionality means others will have to help with testing, perhaps new bugs / defects will be introduced. Gut reaction is to often persuade the developer to focus on current priorities. But, before we kill their enthusiasm we may want to think about how this will impact someone that has enough excitement about the company and the product that they're willing to put extra time to make it better.
Caring
At the end of the day, people don't drive change if they don't care. This means that a) you want foster good relationship and create a positive atmosphere so that people will care and b) you want to have the right people who care about the right things.
Looking at this from another angle - if people do not seem to drive improvements in your organization or team you may want to find out why. Wrong set of people? Wrong culture and atmosphere? Lack of leadership nurturing?
The right people - Some people care because they have a sense of professionalism and of doing their job well. Other people care about the users of their software and want to make sure they have the best product. Some people love other people and enjoy driving positive change. For each person on your team, you may want to identify their main drivers and motivators and ensure their motivation is not suppressed.
Building a strong team
Leadership is a critical element of building a strong team - a team that can operate independently, that is self motivated and improves on its own. We build good leadership by getting the right people and nurturing them to lead.
You know you're there when you sit at your chair, drinking your coffee and things are just happening.
Monday, February 17, 2014
The Evil Nameless Ones
Aaahh.. those evil ones!
They always get in our way.
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:
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.
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.
Sunday, February 16, 2014
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:
The "Personal Map" Venn diagram shows the intersection of three key areas:
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.
Skills ↔ Desires
1 - 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.
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.The concept of a "Personal Map"1 can help explore various scenarios.
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?
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.
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.
- 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.
- 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.
1 - 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.
Subscribe to:
Comments (Atom)