While traveling recently, I've had a fellow passenger who apologized for not talking enough only to then continue and talk non-stop. A few days later, the same thing happened with a taxi driver. It seems that often when people say sorry for not talking much (or other behavior) then it is a good indication they will talk more than you expect or want.
Who's scale are we using?
We each have our own scale and often don't check the other person's scale.
Junior developers coming out of college think they are experts at programming because they got A+ on their course work. During interviews, we often ask new developers to rank themselves from 1 to 10 on their expertise in some programming language they learned - and almost always getting somewhere around 8 or 9. (10 is being avoided by the candidate out of minimal modesty).
Why even use a scale?
Do we really need to place ourselves on a scale? It seems that we too often, and in an unsolicited manner, like to grade ourselves and perhaps even talk about ourselves in general. Usually in self boasting. Also, in general, our scale does not matter. We may be talking less than some but if our conversation partner is a monk, perhaps our few words may be considered as too much.
In some cases we are being asked to asses ourselves, as in the case of job interviews. If we grade ourselves, should it be our scale or our listener's scale?
When interacting with others we may be better off not putting ourselves on any scale or if asked, at least use our listener's scale. Modesty is often a good policy. Self delusion and disregard for our conversation partner is definitely not a good policy.
On a side note - we can and should feel good about ourselves when we're good. We just need to remember that there is no need to brag about it and that there are others out there that are even better.
Monday, May 26, 2014
Tuesday, March 4, 2014
Plan the People Not the Work
You can't plan the work, only the people
A strong team is able to meet business needs and deliver on its obligations. As we organize the team, we try to consider current business needs and perhaps look at the road map to adjust the team based on future work.
However, in today's environment, the team's responsibilities may change from month to month and even from week to week. In addition, the number of different skills required for almost any decent project is big, and definitely bigger than the number of people on our team.
Having people that are versatile in what they can and are willing to do provides us with flexibility to react to changing conditions.
Similar to chess, it is pretty much impossible to plan all the moves from start to finish. Instead, we want to play strategically in order to put ourself in good position. Having a versatile team puts us in that strategically advantageous position. Only in the end phase of the game can we look at move by move - this is similar to our tactical plans for short term execution.
Versatile team members are critical
Delays and Costs for missing skills
When a project requires a skill that is not present in the team we need to look for that skill set either in other teams or outside the organization. Getting a contractor to do the work means delay in work, time spent on finding contractors, often lower quality and high cost for the contract work.
When the skill set is present in the organization but with a different team it means delays as different teams may have conflicting priorities and schedules. Team A may need to wait for Team B to finish what they're working before they can pick up Team A's work.
In addition, moving team from team creates queues which inherently create inefficiencies. Queues are a large topic worth discussing on its own but a few inefficiencies worth mentioning here are: communication overhead, rework on miscommunication, irrelevancy to end user by the time work is done.
Delays due to mismatch in quantity of skills
Wrong quantity of skills will also lead to delays.
Have you run into a case where some team members are working on low priority items? Have you heard the explanation that "there is nothing critical in their area at the moment"?
For example - we may have a team of two, one developer is a back-end developer building server side (back-end) functionality and the second developer is a web developer familiar with graphical interface (front-end) functionality. We know that we need to build both the back-end functionality as well as the front-end functionality in order to deliver the business needs so that team feels balanced.
But is the work really divided equally among these two developers? What if one developer is faster? Do we have some weeks where more front-end work is required and others where more server work is required?
Some weeks we have to tackle a complicated algorithm or performance issue on the back-end which creates more work for the back-end developer. Other times, we may have an elaborate interface we want to create but is simple to support on the back-end.
If the back-end developer can do some front-end work and if the front-end developer can do some back-end work we can adapt more easily to change in needs. Not every front-end or back-end task requires olympic skill to execute. It is possible that people can help with easier tasks in areas they are less familiar.
The above example showed just two skills and two team members. In real life, with more members and more skills involves, having (or lacking) versatility leads to a much bigger impact on the team.
Impact of fixed roles
When lack of versatility leads us to use fixed roles for people we may have several problems:
One of the biggest issues with lack of versatility is its possible impact on company culture and overall structure.
As companies grow, you see a large number of dedicated teams organized based on skills set. Database architects (DBA), general architects, operations, IT, installer team, QA team, sustaining team.
At first, it may seem that having dedicated teams is great -
While the above reasons look great, they are fundamentally risky. In scrum, there is an expression "watch the baton, not the runners". An HR manager looking at a relay race may not see a winning team, instead they'll see 3 people idle at each moment.
Dedicated teams inevitably lead to local optimization - teams have their own goals that are no longer directly tied to business success. Any given user deliverable may be spread across multiple teams. As such, it makes it hard to set goals based on user deliverables as for specific teams. What usually happens is functional-based goals. QA may want to limit number of bugs and will slow releases. IT may want to reduce costs and will limit the amount of test servers.
In addition, separate teams often leads to increase in process overhead. The DBA team wants to approve database changes. QA wants to approve test plans, developers may test their code even less because it is not their role, we may need larger planning meetings, etc. Suddenly we need project managers and organizers to facilitate work across team boundaries. We increase dependencies and through that organizational complexity.
It's not my problem
Last but not least, by creating separation of responsibilities into teams we take away from ownership. Instead, we create a system that allows a problem to "not belong to me". "They are responsible for this". As managers, we set ourself up with playing judge. Should the development team have caught the bug in automated test or was QA responsible for running a regression test?
Scrum teams
Scrum - one of the most popular development processes - suggests that engineering groups are divided into small cross-functional and independent teams of 4 to 7 people. The team has all the skills to deliver end-to-end functionality for the user. The team focuses on the user needs and not on internal functional structure within engineering.
Having small dedicated teams negates some of the issues mentioned above. However, to be successful, the team needs to be able to tackle the various tasks given to it which means it needs to have a wide-enough range of skills and be versatile.
Not everyone needs to be versatile
While versatility is important, it does not mean that every team member must be versatile. In some cases, we need a guru in specific areas. Someone who is a super star in some difficult aspect of our product. In other cases, we have enough dedicated work in specific area of skill set that makes it OK (not great) to have some less versatile players.
From a practical perspective, finding great people is hard and not everyone can be a superstar in all areas. We also have a limited budget.
Not Limited to Development
The examples here focus on development teams but versatility applies to many other areas. Sales, marketing and even outside of high tech.
For example - American Football teams highly regard versatility as a way to compensate for limited budget (due to salary cap), limited number of players on the team (due to rules) and large number of positional skills.
A strong team is able to meet business needs and deliver on its obligations. As we organize the team, we try to consider current business needs and perhaps look at the road map to adjust the team based on future work.
However, in today's environment, the team's responsibilities may change from month to month and even from week to week. In addition, the number of different skills required for almost any decent project is big, and definitely bigger than the number of people on our team.
Having people that are versatile in what they can and are willing to do provides us with flexibility to react to changing conditions.
Similar to chess, it is pretty much impossible to plan all the moves from start to finish. Instead, we want to play strategically in order to put ourself in good position. Having a versatile team puts us in that strategically advantageous position. Only in the end phase of the game can we look at move by move - this is similar to our tactical plans for short term execution.
Versatile team members are critical
Let's define versatile team members as people who either have a wide variety of skills and/or have the ability to acquire new skills. In addition, these people need to be happy and excited about either doing what is needed to build a product or excited about learning and developing new skills.
From a Personal Map perspective - we're looking for people with large circles for skills and desires.
So why are versatile team members critical?
When a project requires a skill that is not present in the team we need to look for that skill set either in other teams or outside the organization. Getting a contractor to do the work means delay in work, time spent on finding contractors, often lower quality and high cost for the contract work.
When the skill set is present in the organization but with a different team it means delays as different teams may have conflicting priorities and schedules. Team A may need to wait for Team B to finish what they're working before they can pick up Team A's work.
In addition, moving team from team creates queues which inherently create inefficiencies. Queues are a large topic worth discussing on its own but a few inefficiencies worth mentioning here are: communication overhead, rework on miscommunication, irrelevancy to end user by the time work is done.
Delays due to mismatch in quantity of skills
Wrong quantity of skills will also lead to delays.
Have you run into a case where some team members are working on low priority items? Have you heard the explanation that "there is nothing critical in their area at the moment"?
For example - we may have a team of two, one developer is a back-end developer building server side (back-end) functionality and the second developer is a web developer familiar with graphical interface (front-end) functionality. We know that we need to build both the back-end functionality as well as the front-end functionality in order to deliver the business needs so that team feels balanced.
But is the work really divided equally among these two developers? What if one developer is faster? Do we have some weeks where more front-end work is required and others where more server work is required?
Some weeks we have to tackle a complicated algorithm or performance issue on the back-end which creates more work for the back-end developer. Other times, we may have an elaborate interface we want to create but is simple to support on the back-end.
If the back-end developer can do some front-end work and if the front-end developer can do some back-end work we can adapt more easily to change in needs. Not every front-end or back-end task requires olympic skill to execute. It is possible that people can help with easier tasks in areas they are less familiar.
The above example showed just two skills and two team members. In real life, with more members and more skills involves, having (or lacking) versatility leads to a much bigger impact on the team.
Impact of fixed roles
When lack of versatility leads us to use fixed roles for people we may have several problems:
- We adapt the work to the skills that we have instead of to the priorities of the business
- Personnel changes leave a void which is hard to fill.
- Attitude and focus on role vs. customer - we may hear the reply from team members "this is not my job".
Organizational & Cultural Problem
One of the biggest issues with lack of versatility is its possible impact on company culture and overall structure.
As companies grow, you see a large number of dedicated teams organized based on skills set. Database architects (DBA), general architects, operations, IT, installer team, QA team, sustaining team.
At first, it may seem that having dedicated teams is great -
- Dedicated qualified people / resources that can better service the needs of other teams.
- It also makes human resources happy - we can optimize our resources. Having a database architect (DBA) on each team may mean their expensive skills are not fully utilized 100% of the time. Instead, having a smaller and dedicated DBA team allow for better utilization.
While the above reasons look great, they are fundamentally risky. In scrum, there is an expression "watch the baton, not the runners". An HR manager looking at a relay race may not see a winning team, instead they'll see 3 people idle at each moment.
Dedicated teams inevitably lead to local optimization - teams have their own goals that are no longer directly tied to business success. Any given user deliverable may be spread across multiple teams. As such, it makes it hard to set goals based on user deliverables as for specific teams. What usually happens is functional-based goals. QA may want to limit number of bugs and will slow releases. IT may want to reduce costs and will limit the amount of test servers.
In addition, separate teams often leads to increase in process overhead. The DBA team wants to approve database changes. QA wants to approve test plans, developers may test their code even less because it is not their role, we may need larger planning meetings, etc. Suddenly we need project managers and organizers to facilitate work across team boundaries. We increase dependencies and through that organizational complexity.
It's not my problem
Last but not least, by creating separation of responsibilities into teams we take away from ownership. Instead, we create a system that allows a problem to "not belong to me". "They are responsible for this". As managers, we set ourself up with playing judge. Should the development team have caught the bug in automated test or was QA responsible for running a regression test?
Scrum teams
Scrum - one of the most popular development processes - suggests that engineering groups are divided into small cross-functional and independent teams of 4 to 7 people. The team has all the skills to deliver end-to-end functionality for the user. The team focuses on the user needs and not on internal functional structure within engineering.
Having small dedicated teams negates some of the issues mentioned above. However, to be successful, the team needs to be able to tackle the various tasks given to it which means it needs to have a wide-enough range of skills and be versatile.
Not everyone needs to be versatile
While versatility is important, it does not mean that every team member must be versatile. In some cases, we need a guru in specific areas. Someone who is a super star in some difficult aspect of our product. In other cases, we have enough dedicated work in specific area of skill set that makes it OK (not great) to have some less versatile players.
From a practical perspective, finding great people is hard and not everyone can be a superstar in all areas. We also have a limited budget.
Not Limited to Development
The examples here focus on development teams but versatility applies to many other areas. Sales, marketing and even outside of high tech.
For example - American Football teams highly regard versatility as a way to compensate for limited budget (due to salary cap), limited number of players on the team (due to rules) and large number of positional skills.
Wednesday, February 26, 2014
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.
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.
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)