Build the Team with 100+ New Team Hacks 2019
As the leader of the team, it is your responsibility to set the tone and to collect people around you to reinforce it and Build the world-class team. Decide what your team’s personality is going to be, and recruit to shape the team into that personality. This blog explains the 100+ New Team Hacks in 2019.
Your actions have an outsized impact on team dynamics. Keep in mind that the primary reason most people leave a job is that they don’t like their immediate supervisor.
This doesn’t mean you have to be everyone’s buddy; that would be counterproductive. Be professional. Be fair. Have clear expectations. Recognize excellence. And then think about how to structure your team to support the personality you want it to have.
Your team members can be characterized in one of the following ways:
Key player Keep these people where they are.
Development project This person isn’t quite there but shows potential. Work out a plan to develop it.
Move. This person might fit better in a different role.
Observe. You aren’t going to figure out everyone right away. Give yourself space to watch and think if you aren’t sure.
Replace eventually. This person should be replaced, but it can be done at the right time.
Replace immediately. Find a way to move this person out. This can either be someone who has an attitude problem that can’t be resolved or someone who is irredeemably incompetent.
In your evaluation, look at more than the technical competence of the person in question. Sometimes a person is contributing more to the team than you see at first glance.
Include things like the energy the person brings to the team, the judgment shown during team meetings, or the relationships the person has with other peer groups. Also, make sure to think about whether you can trust that person to help you implement the changes you need.
By the end of the 90 days, you have had plenty of time to observe your team in action. You should know who is staying, who is going, and who is moving. Communicate that information to your boss, and eventually to the other key stakeholders. By the end of 6 months, you should have the people in place that you need to run your team.
The difficulty is that some of the people to be replaced have critical knowledge and skills. You need to identify a plan for doing this with as little disruption as possible.
Temporary help can be hired during the transition, or maybe a more junior person is ready to step into the opening. In any case, a plan needs to be approved and implemented.
Recruiting is expensive, so you need to make sure to do it the right way. Understand which qualifications are actually necessary, and which are nice to have. Take into account the skill profile of the other team members, so that you know where you can compromise and where you can’t.
Also, take into account how the team members would work together. Try to assemble a group of people whose strengths are complementary, and who will work together well.
Hold out for high-character applicants. Hiring the wrong person is expensive in both time and money. Reassure the people you want to keep. When good people see churn in the team, they may start looking at other opportunities themselves.
Speak to HR about the constraints you have on what you can and cannot say. There are ways to signal your appreciation to people you want to keep without crossing any legal or ethical boundaries.
When you post a job opening, you need to identify what the requirements for the job actually are:
Primary and secondary responsibilities for the role.
Education and experience required.
Personal characteristics and skills (e.g., strong organizational skills, able to work independently)
A personality match with the team and organizational culture and with your managerial style. (Note that issues in this category cannot be used to discriminate against several protected classes.)
A job posting is a good chance to rethink what that position should be, as opposed to what the former employee’s characteristics were. Maybe it makes more sense to shift responsibilities differently within the team and to redefine the role.
Note If you can hire someone with industry or business experience that can also be a big benefit. Every industry has its own rhythm, and it helps to get someone who already understands the unspoken expectations. And when it comes time to gather requirements, someone who understands the business has a huge advantage.
Once you have the requirements in mind, you can write up a job description. This will need to be vetted by HR to verify that you are not impinging on any legal requirements.
Organization and business unit name.
Hiring and reporting managers (identify both, if they are not the same).
Expected work schedule and location.
Educational and experience requirements. Distinguish between hard requirements and “nice to have.”
A lot of technical people can’t write a well-structured Resume to save themselves. I have found some gems by being a little forgiving on the Resume and depending on a phone screening to weed out people whose Resume reflects more experience than the candidate actually has.
It depends on the nature of the team and the opening you are trying to fill.
Note A well-written Resume is definitely a good indicator to look for. The ability to express yourself well in writing in a business context is a terrific qualification. Most technical teams have a shortage of people who can communicate well with the business side.
Resume RED FLAGS
There are some things to watch out for when reviewing résumés:
Emphasis on education and training classes over experience. This may indicate a weakness in real-world experience. Gaps in service or lots of short-term jobs. This may just indicate someone who has been doing consulting, but you need to find out.
Either too much or not enough variety in job descriptions between different positions. I’ve spoken with several candidates who seem to have repeated the same one year of experience five or eight times.
Descriptions of positions, with no descriptions of interesting projects or accomplishments.
My preference is to make notes on résumés listing topics I want to investigate further. Then I set up short phone screenings. Based on the phone screenings, I call back a small number of in-person interviews and hire from there after checking references.
You want to make sure that all applicants respond to a core set of questions so you can make fair comparisons without being prejudiced either for or against a candidate. In addition to the core questions, ask questions raised by oddities in their résumé, and let the candidate speak about his or her strengths.
The interviewer needs to keep control of the pace of the interview. Some candidates are particularly good at snowing interviewers. They entertain the interviewer and avoid the tough questions by playing out the clock.
No more than 10% of the interview time should be taken by a brief, scripted introduction to the organization and what the position entails. If there is a serious, potentially disqualifying question that needs to be asked, ask it up front.
Then roll into your core interview questions. Finally, finish up with other questions. It is your responsibility to keep control of the pace of the interview.
There are a number of questions that cannot be asked, such as questions about race, ethnicity, sexual preference, family situation, health conditions, age, weight, or religion. Your HR department should be able to provide guidance on questions to avoid. They also may want to review your core set of questions.
Leave time for the interviewee to speak about what makes him or her the ideal candidate for the job. Sometimes that can be the most interesting part of the interview.
Note If you can get the candidates to tell you stories about their proudest accomplishments, you can learn a lot. Listen to how they speak about their roles in the projects they worked on. Did they lead? Or just follow instructions? Drill down on special accomplishments to make sure that they are not reflecting someone else’s victory.
Leave about 10% of the interview time in the end to wrap up and allow the candidate to ask questions about the position. Shake hands, make eye contact, and walk the candidate out.
In the end, write down notes about your impressions. When there is a long time between interviews, or when there are a lot of interviews together, it is easy to get impressions confused between interviewees. You can use your notes to keep people straight.
Check references when you are close to a decision before you extend an offer. Most people who have been around IT for a while know horror stories about people who can talk a much better game than they can execute. Reference checks are one of the few safeguards you have against this problem.
Bruce Tuckman developed a model of team formation in the 1960s and 1970s. The stages he described seem ubiquitous to team formations in different circumstances:
Forming. New team members are introduced, and people learn about each other.
Storming. Conflicts emerge between different ways of doing things.
Norming. Team members develop ways of cooperating and working together.
Performing. Team members have developed trust and understanding, and are able to work together effectively.
Adjourning. The team breaks up.
Some amount of conflict is inevitable when people start working together. The team’s leader should understand that this is natural but should work to accelerate the development of ways for team members to work together productively.
Pay particular attention to people who are in different geographic locations, and especially in different time zones. You need to schedule extra time to interact with them and to draw them into the team dynamic.
Geographic and time differences will slow down their interaction with the rest of the team and will delay their ability to move into the norming and performing stages. You can’t afford to lose part of your team like this; make a conscious effort to draw them in and keep them involved.
Large teams also can slow down the norming process because there are more interpersonal connections for the storming phase to operate over. You can work around this to some extent by breaking the larger team into work groups of three to seven.
In some cases, team-building activities can help. In my experience, the best way to move from the storming to the norming phase is to go after some early wins. Shared success builds team working relationships faster than anything else I know.
A goal-setting exercise allows you to work one-on-one with your direct report to identify specific ways he or she can help the company move forward.
It is usually ineffective for a manager to specify goals, and it is almost meaningless if the employee sets goals without input. A functional goal-setting process will involve input from both the employee and the manager.
To be effective, goals need to be
Written down in a permanent location.
Specific criteria and time.
Challenging but achievable.
Recognized as important and aligned with the organizational strategy.
If a goal’s objectives are not measurable, the goal becomes meaningless. The specific goal needs to have a specific measurement associated with success. “Learn Java” is not measurable. “Pass the Java exam with a score of 80% or higher” is.
As a manager, you should mentor your direct reports on how to meet their goals, once you have agreed on a set of important, measurable, and specific goals. Each goal should be broken into tasks, each of which will have a timeline.
As a manager, it is your job to ensure that the employee has the resources necessary to execute the agreed-on plan.
Your job does not stop there. You need to review each employee’s progress toward their goals periodically, and you will need to write up their employee review for their file with the outcome of the goals at the end of the review period.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Different employees are motivated differently.
Money is important, of course. Compensation is a raw measure of how much someone is valued by the employer; make sure your people are fairly compensated or you will lose them. Beyond monetary compensation, there are a lot of other incentives you as a manager can use to help motivate your team members.
Incentives may include money and bonuses. If they do, establish clear and objective criteria, even if these are not shared with team members. (You don’t want them gaming the system.)
Technical professionals like to make things work, and they like to be part of a successful team. Provide growth opportunities, and recognize people within the team when they contribute.
Track each person’s contributions to the team, and report on them regularly. Personalized year-end summaries of accomplishments for team members demonstrate that you really are paying attention to what they are contributing.
A “thank you” goes a long way. When someone from your team stays up late or works a weekend to resolve a problem, send them a detailed thank you email, and cc your boss.
Save those thank you emails in a folder for each employee. When annual review time rolls around, you’ll have some specific accomplishments you can reference.
The main reasons people will stay in a job are
The main reasons people leave are
Pride in contributing to a respected organization.
Respect for an immediate supervisor.
Fair market-rate compensation. This can include intangible compensation, such as opportunities to learn new technologies.
Friendships and respect for colleagues.
Meaningful, challenging work.
The shift in organizational leadership.
Conflict with an immediate supervisor.
Shifts in responsibilities to something less desirable.
Unfavorable work-life balance.
Money is important, but there are a lot of intangible things that you can use to help retain employees. Most of all, try not to be a jerk. You don’t have to be a buddy; you just have to be fair and reasonable. Here are some things you can do to improve retention without hitting the bottom line:
Start people off right. Make sure to get them up and running as quickly as possible. This means some prep work on your part before the employee arrives.
If you can get them through orientation, and get their computer, phone, and email working right away, it will make a big difference to the new employee’s mindset about your organization and your team.
Be demanding but fair. People expect to come to work to get things done. Be explicit about your expectations, and make sure that the expectations are reasonable.
Share information. People like to understand how their efforts contribute to the larger whole.
Give people autonomy. Set expectations, follow up to check status, but don’t micromanage.
Give your employees a chance to stretch. Good employees like to accomplish new and challenging things. If you can’t find something challenging for them to accomplish, you aren’t trying very hard.
Be as flexible as possible. You have to cover the responsibilities, but there are a lot of reasonable requests you can grant that don’t impact your ability to deliver. Pay attention to results, not to how, where, or when the work gets done.
Structure responsibilities around the employees. Try to assign people to work they are interested in.
Be alert for hints that people are unhappy. Discuss it with them. There may be an answer that is a win all the way around.
Most managers have very little say in monetary compensation, but there are a lot of intangible things that are under the direct control of the immediate supervisor. Of the different types of power under the manager’s control, money is far from the most important.
The Power of “Thank You”
Techies are just like everyone else. We want to feel like we’re part of something bigger than ourselves. Find a way to present a vision of a successful team. Then, every time you have a success, send a thank you message to the responsible team members stressing what made it a success.
Successful teams are dedicated, professional, intelligent, resourceful, and resilient. “Thank you for your work on the xyz project. Your dedication and hard work were key elements to our success.
When you suggested using method ABC, you saved the company money and improved our customers’ experience. You are a huge part of our team’s success.”
Define your team as successful. Message relentlessly about what that means. Find your team members’ successes and recognize them.
Cc your own manager on these “thank you” messages; your boss needs to know what your team is doing, and employees need to understand that their contribution is seen and appreciated within the larger organization.
Awards provide a more formal way to express thanks to team members. Some successful programs allow employees to nominate each other for certificates of thanks, trophies, or even nominal cash awards.
These can be presented in meetings, or even during a team lunch—how much does it cost to order in pizza, anyway?
Let your boss present the awards. That way your team members know that not only do you appreciate their contributions; they are getting visibility in the organization for their accomplishments.
Recognize success, and create a culture where people recognize each other’s contributions.
There are five different ways that power can be exercised within an organization:
Coercive power. This is the type of power exercised by using threats or punishment to try to push the other person into doing what you want. Overuse of coercive power causes resentment and is generally less effective than other ways of exercising power.
Legitimate power. Getting people to do things for you from a position of authority within the organization.
Expert power. Using personal expertise or knowledge to persuade people to do what you are requesting.
Reward power. This is when incentives are used to get people to do what you are asking. Studies show that certain types of reward, such as interesting work assignments or recognition, are really effective at changing behavior.
Referent power. This is when people are willing to do things for you because they like you. Some charismatic leaders have been effective using referent power, but they are few and far between.
Legitimate power extends only so far. People understand that you are the boss, so you have a legitimate right to ask them to perform reasonable work. To really motivate people, you need to look further.
Proper use of rewards (such as interesting work assignments, recognition, or the opportunity to learn a new skill) can be great motivators for solid performers. Combine that with the expertise you have built up over your career, and you have an enviable ability to motivate your team.
Legitimate power (sometimes also known as “executive” power) is the most effective way to deal with certain types of emergency situations. Sometimes there just is not the time to reach a consensus on the way forward.
But if you end up issuing orders too frequently, you will lose your team. They may go elsewhere. Or they may do something worse. They may stop using their own initiative and rely on you to issue orders on exactly what you need them to do. If you get to that point, your effectiveness as a team leader drops significantly.
Processes for Success
How do you track progress? How do you communicate with each person’s contribution to the rest of the team?
Ticketing systems, project tracking processes, team meetings, and staff schedules are all examples of processes that should be examined to see if they can be improved.
Make sure that peoples’ contributions to the team are visible. Some managers post visible lists or updates of what every team member is working on and their progress toward completion. Depending on the nature of the workplace, this can be on a visible bulletin board, or on a SharePoint dashboard.
This has several benefits. It recognizes the contributions of each team member. It provides your boss a way to see what your team is doing. And it provides an incentive for people to execute their responsibilities quickly and well because everyone knows who was responsible for a particular activity.
You also need to consider the decision-making process you are going to put in place.
Consult-and-decide means that you ask for information and input from the team and then make a decision. This is an alternative to building a consensus. In general, it is worth the time to try to build a consensus if the decision is going to require enthusiastic support by your team.
In situations where either the team is inexperienced or the decision needs to be made quickly, consult-and-decide is going to be the more appropriate decision-making process.
Establish a feedback process early in your tenure. Feedback should flow both ways, from you to the team, and from the team to you.
When you provide feedback to your team, at least 75% of your feedback should be positive. If you aren’t able to come up with that many nice things to say, you may need to engage in some self-examination. Very few people are that bad; most people want to learn, improve, and do a good job.
Note If you have a team member who does not pull their weight, or who consistently makes mistakes, you need to address the situation before team morale suffers. In some cases, you may decide that this person’s behavior cannot be corrected, and you may need to replace this team member immediately.
More frequently, a minor correction can be couched in the middle of positive feedback on the bulk of the work that the team member is doing right.
Make sure that your expectations are clear. Usually, when things aren’t done the way you want, it is because your team members don’t understand your expectations. If you haven’t made your expectations clear or communicated them effectively, that is on you. Don’t take it out on your team members.
Provide opportunities for your teammates to give you feedback. Usually, my only requests are that team members address me respectfully and in private when they need to provide me with negative feedback.
If there are resentments within the team, it is better to get them out into the open and discuss them honestly. If the resentments fester in the dark, they are guaranteed to emerge in a time and place when you are least able to deal with them.
When a team member brings an issue like this to your attention, take a deep breath. If you can’t deal calmly with the issue right now, thank the team member for bringing the issue to your attention, tell him or her that you want more time to think about it and schedule a meeting for later.
Think about how you want your team member to react when he or she has negative feedback coming from you. That is how you need to react. Your people are knowledgeable professionals, and they deserve the same sort of treatment that you demand yourself.
Stephen Robbins defined several axes that can be used to define an organization’s culture:
Member identity. How closely people associate with the organization, rather than with subgroups within the organization.
Group emphasis. Is work assigned to groups or individuals?
People focus. How much weight is given to the impact of decisions on people?
Unit integration. How much are units encouraged to cooperate?
Control. How much do rules and policies govern behavior?
Risk tolerance. Are employees encouraged to take risks to innovate?
Reward criteria. What sort of behavior is rewarded? Are rewards based on behavior or criteria such as seniority or popularity?
Conflict tolerance. Are employees encouraged to air conflict and disagreement openly?
Means-end orientation. Does management focus on means or outcomes? Organizations with a balanced approach tend to be more successful in executing complex projects.
Open systems focus. Does the organization monitor and adjust to changes in the external environment?
Think about where your organization falls on these axes, and look into what type of environment your new team members come from.
You will live in the atmosphere of the larger organizational culture, but you can define an organizational culture for your team. Think about what type of team you want to lead, then think about how to get there.
Messaging from the manager can help set a tone. Think about an aspect of team culture that you want to create or emphasize, then talk about it when you discuss the team environment with each of the team members. Persuade them how the world should be, and show your team members that it is within their power to create it.
Techies tend to have very sensitive BS detectors. Don’t say things that you don’t mean. It is okay to explicitly tell your team members that you are messaging about something, but follow it up by explaining why you see that characteristic as important.
Use your powers of persuasion, backed by a sincere commitment on your part to foster that characteristic. Your team members will respect you for it, and they will follow your lead.
Find room in the budget for staff training. But beyond paid coursework, encourage team members to stretch to learn from each other. Cross-training increases the value of each team member.
Training needs to take into account the strengths, weaknesses, and career goals of each person on the team. For technical people, learning new skills is a valuable reward.
To the extent possible, try to structure training on a just-in-time basis. If you have someone train on something six months before they get to touch it, they are guaranteed to have forgotten everything they learned.
When someone is trained (either in the classroom or by cross-training with a teammate), provide them with an immediate opportunity to exercise their new knowledge.
In one place I worked, there was a budget that allowed for one offsite training course per person per year. The team members coordinated who would go to each class.
When that person returned, they were expected to spend their first few days back documenting what they had learned and transferred the knowledge to their teammates who had been covering the environment.
This saved the organization money, improved teamwork, and allowed the team members to learn far more than they would have been able to cover by hoarding knowledge.
Make sure you do not have any skills or knowledge that are limited to just one person. Where you find this, consider it to be a gap. Schedule time for the specialist to bring teammates up to speed and write documentation.
Technologists like to learn new skills. This should be a road that is traveled in both directions. Everyone on the team should be both a teacher and a student in cross-training sessions. It makes it easier to provide vacation support, and it protects the organization in case someone is sick or leaves.
The most powerful tool you will have as a manager is your own credibility. It will take time to win your team’s trust. It can take you only a moment’s lapse to lose it entirely.
When times get tough, credibility is going to be what gets you through. You will be able to acknowledge the problem to your team and ask for their freely given assistance in resolving it. Your credibility will be what makes the difference between getting the support you need and getting a cold shoulder.
The key to earning credibility is to keep your commitments. Try to make your commitments in writing so that you don’t run into a problem with each side remembering something slightly different.
Sometimes you will make a commitment that you are prevented from keeping by circumstances beyond your control.
When you discover that you will not be able to meet a commitment, come clean and renegotiate the commitment as appropriate. If things are just not going to work out, apologize. People will be upset, but they will respect you for dealing straight with them.
Commitments should not be made lightly. Other commitments will need to be taken into account. If you are making assumptions, try to state them explicitly. (I’ll deliver the server next week, assuming that the hardware is delivered to me as scheduled.)
If there are things that can be done to mitigate possible problems with the assumptions, it doesn’t hurt to make those actions explicit as well.
You are the heart of your team. If your team can’t trust you to deliver reliably, your team will not be able to deliver for you.
Do not neglect your own education and training. I started my MS program knowing that I could only take one or two classes a year because of my workload. When I started the program, it seemed like it would take forever to finish up the program, but five years later, I had my degree.
Take a long view of your development. Think about where you want to be in five years. If you were interviewing someone for that job today, what would you look for? What would you ask? That is the information and experience you need to pursue.
It is up to you to set the tone for your team. Make your team into a learning organization. It will make your team more flexible, and it will make your team members happier.
Read blogs. Find some substantive blogs to follow. Take classes. Attend lectures. And think about going after that degree you meant to finish, even if you can only take one or two classes at a time. You will be better for it. It will make you a better manager—and a better-rounded person—over time.
Describe the characteristics you want your team to embody. Does your team have those characteristics now? How would you go about fostering those characteristics?
List some interview questions that would be good for finding out a candidate’s technical expertise. Now list some questions that would be good for assessing the candidate’s character.
Visible tracking of each person’s progress on assigned work is both a good reward and a good motivator. What method would work well in your environment? A weekly report? A bulletin or whiteboard? A web-based dashboard?
Every manager should have a personal education plan. There are technical certifications or diplomas that you can work toward. What are your educational goals? What concrete actions are you taking to achieve them?
One of the less pleasant aspects of being in charge of the team is that you will need to step in to make sure that conflicts do not get in the way of the team’s progress. This blog includes some information and techniques that will be useful in dealing with conflicts.
Conflicts are not necessarily negative. People see different pieces of the entire system, and there are likely to be legitimate conflicts of interest between them. When handled properly, conflicts can lead to positive change.
DESTRUCTIVE VS. CONSTRUCTIVE CONFLICT
Destructive conflict is characterized by tension and argument. An atmosphere of antagonism and anger is likely to emerge during the destructive conflict.
Constructive conflict is characterized by mutual respect and consideration. The people engaged in the conflict hear each other out and consider the alternative point of view. Constructive conflicts may not always end in agreement, but at least alternative points of view were seriously considered.
Methods of Conflict Management
There are several different ways to handle a conflict. Blake and Mouton1 characterized them as
Confrontation. In this problem-solving mode, the affected people directly confront the conflict and try to work it through. (Confrontation refers to confronting the problem, and it is not meant to indicate that the manager picks a fight with a team member.)
Compromise. This is a give-and-take approach that tries to give each of the parties some of what they are looking for.
Smoothing. This approach emphasizes areas of agreement and de-emphasizes areas of disagreement.
Forcing. A “solution” is imposed from higher up the hierarchy. If this method is overused, a manager will be seen as autocratic, which may have an impact on team members being willing to exercise independent judgment.
Withdrawal. The problem is ignored. This is the least desirable tactic because the problem will just fester and re-appear again.
These five methods of dealing with a problem are listed in order of effectiveness. Effective managers use confrontation and compromise most frequently. Weaker managers tend to use the other three methods of dealing with conflict.
Conflicts between Team Members
You can’t live your team members’ lives for them, and you can’t force them to engage in constructive rather than destructive conflict. But you can create an environment of trust, respect, and compassion.
There are a few techniques you can use to deal with an interpersonal conflict:
Interview the people involved to try to identify the core issues.
Separate these issues into needs and wants.
It will not be effective for you to simply pick winners and losers. (You may have to make a decision to move forward, but listen to both sides first.)
Provide individual coaching for the people involved. Ask them to restate the other person’s point of view.
Encourage both team members to have an open mindset and try to build a fresh relationship based on tolerance and respect. They don’t have to agree, just work together.
Conflicts between Teams
Conflicts sometimes emerge between teams. Sometimes these are proxy battles between the team leaders. If you are engaged in one of these, it is your responsibility to sort it out.
More frequently, there are issues associated with work allocation and scheduling. It is up to management to assign responsibilities. Negotiate with the other team leaders, and engage the next level of management if there is a genuine disagreement about task ownership.
Scheduling can be more difficult. Teams need to consider how things look from the other team’s point of view.
Provide as much advance notice as possible.
Work on the procedure collaboratively.
Specify formats in which standard requests should be submitted. That will help avoid the problem where someone mentions something to someone else at lunch, which is inevitably either misunderstood or forgotten.
Sometimes there are members of each team who are friendly. To the extent possible, leverage these personal relationships to foster trust and cooperation between the groups.
The fact is that the teams have to work together. It is in everyone’s best interest to develop compatible work habits.
The most common way to characterize personality types is the Myers–Briggs Type Indicator. There are four axes used to measure a person’s personality:
Extrovert/Introvert (E/I): Do you draw energy by interacting with other people (E)? Or by thinking and studying during your private time (I)?
Sensation/Intuition (S/N): Do you gather information by direct observation (S)? Or are you more intuitive and conceptual (N)?
Thinking/Feeling (T/F): Do you reach decisions by thinking and logic (T)? Or do you use more subjective and personal criteria to reach decisions (F)?
Judgment/Perception (J/P): Do you value completion, deadlines, and closure (J)? Or do you see things as more of an ongoing process, with deadlines being flexible and fungible goals (P)?
When psychologists run population studies of personality types, some interesting patterns occur. It turns out that there are differences between techies and the general population, and even between different types of techies.
There was no significant difference between IS people and the general population on the J/P axis. About half of each group falls onto each end of the axis. But there are significant differences on the other three axes.
Among IS developers 75% were introverts, 80% were on the thinking end of the spectrum, and 55% were classified as intuitive. That contrasts with 25%, 50%, and 25%, respectively, for the general population. (That helps explain part of the communication gap between implementation teams and the end-user community.)
If you think about the people you are dealing with, you might see where some communication disconnects can occur.
If you are an “N,” but you are working with someone who is an “S,” you need to present information to that person differently than you would want it presented to yourself. Perhaps something more concrete, such as a prototype or mock-up, would work better than a conceptual overview.
There are other ways to look at how people interact. Psychologist David Merrill (a co-developer of the Wilson Learning Social Styles Profile) characterizes social styles as being defined along axes of assertiveness (proactive/ reactive) and responsiveness (task oriented/people oriented).
The four social styles in this classification are Drivers are proactive and task oriented. They tend to be rooted in the present and look at actions over words. They can be viewed as pushy or dominating.
Expressives are proactive and people oriented. They look to the future and try to find new perspectives and approaches to problems. They can be viewed as manipulating or ambitious.
Analytics are reactive and task oriented. They are thinkers and tend to look to the past for lessons. They can be viewed as critical and indecisive.
Amiables are reactive and people oriented. They are strong relationship driven. They can be viewed as conforming and ingratiating.
Thinking about the social styles of the people you are dealing with can help you to approach them more successfully. The strongest team will be made up of people of different styles because a team of similar people is likely to overlook something important.
Dealing with Difficult People
There are a few keys to dealing with a difficult person:
Identify what you feel. Your feelings will cause you to think and perceive things a certain way, which may or may not be entirely accurate. If you identify what you feel, you can correct for your emotional filter and make sure your perceptions are correct.
In what ways are you contributing to the conflict? It takes two to tango. Think about the ways in which the conflict is partly your fault. Do you sometimes behave in a manipulative way to force the issue? Or gossip about the other person?
What assumptions are you making about the other person? These may be coloring your perceptions and may be contributing to the conflict.
To what extent are you causing the problem?
This doesn’t mean that you have to be a patsy. Don’t let anyone take your power away from you. That will just cause resentment and keep the conflict going anyway. Just don’t feed into it, and do your best to make the situation work.
If you can remove the emotion from the conflict, you can get closer to addressing the actual problem. Try considering some questions to define the problem:
What is the problem? State it in the simplest, least emotional way possible.
Whose feelings are upset? What are they feeling? Why?
Who raised the issue? Why?
Once you have defined the problem, you are that much closer to being able to work with the other person to resolve it. Examine the issue unemotionally, and try to view the issue from the other person’s point of view to find some possible workarounds.
Don’t Be a Difficult Person
We have been discussing how you should shape your communication to fit the other person’s personality and social style better. Do you get prickly if people are communicating with you in other than your preferred style?
To some extent, you need to get over it. You are a leader, and part of being a leader is sucking it up and not sweating the small stuff.
Now that we’ve got that out of the way, maybe we can find ways to structure communication in a way that is more comfortable for you.
If you clearly communicate how different requests should come to you (what information you need, what format you need it in, and how you would like it delivered), you can control some of the communication, and you can get the information you need in a format that is comfortable for you.
When there is no communication, progress ceases. In fact, the problems will get worse if the communications breakdown is not addressed.
Communication problems can be addressed by following some good habits:
Clarify assumptions. Make sure that you are both talking about the same thing.
Set ground rules. You are not going to be able to solve every problem immediately. Pick a problem and work on it.
Share information. If you have information that is relevant to the subject at hand, make sure that everyone involved in the conflict understands what is at stake.
Listen. Hear what the other person is saying. Ask clarifying questions as needed. Make sure you understand the key points being made by the other person.
Avoid personal attacks. Stick to the business problem at hand.
You may not become best friends with the other person, but you have to find a way to work together. Don’t allow communications to break down. Use every tool at your disposal to find a way to work together.
Nobody wants to be a jerk. Issuing reprimands stink. But sometimes it has to be done. The key is that it should be done quickly, clearly, privately, and personally. Don’t repeat yourself ad nauseam, and prepare what you need to say before-hand. The key elements of an effective reprimand are
Make sure you have the correct information beforehand. This includes the instructions you had previously issued on the subject.
The team member should know beforehand that you will be discussing this particular incident.
Reprimand the team member immediately, at the beginning of the session. Be specific about what the team member did wrong, and how it should have been handled. Be brief, but be specific.
Tell the team member how you feel about the situation. Again, be brief, but be specific.
Pause so that it sinks in.
Make it clear that the reprimand is over. Shake hands or make contact in an appropriate way. Tell the team member how much you value them, just not their behavior in this particular case.
After the reprimand is done, you need to let the matter go. No snarky comments later, no discussion with other team members, nothing.
Keep in mind that most of what your team member provides for the team is excellent work. (If that is not true, I’m not sure why you haven’t removed this person from the team already.) You may need to remind the team member about the general quality of his or her work at the end of the session.
The One Minute Manager has an excellent blog on issuing reprimands. I highly recommend picking the blog up and reading it for ideas on how to motivate your team members.
Resolving conflicts is not a type of leadership that comes easily to most technical people. A lot of technical managers avoid conflicts rather than confronting them and pushing through to a resolution.
Don’t fall into the trap of allowing conflicts to manage you. Manage the environment. Deal with the conflicts directly and with integrity.
Think about a workplace conflict that you were engaged in. What do you think the personality type of the other person was? (Remember that “J” does not stand for “Jerk.”) What is yours? How did that contribute to the conflict?
What are some positive ways to deal with a constructive conflict?
Nobody likes writing up budgets. It is a lot less fun than learning a new technology or architecting a new service. But the organization you work for needs to bring in more money than it sends out, or it is in trouble.
In IT, we are usually on the cost side of the ledger. That means that we have to be sensitive to the business cycles of the organization, and we may need to adjust our spending over the course of the year to match the business’s cash flow.
Work closely with the finance department to find out what the business needs, and try to structure spending to match what the company needs.
If you develop a good working relationship with the finance department, it will pay off both for the business and also for your flexibility in managing your department.
Purpose of a Budget
Budgets allow the organization to plan for large expenditures. They can be used to identify where money is being spent, which is useful when planning priorities.
No matter what type of organization you work for, I can guarantee that it wants to spend less money. By identifying where money is being spent, we can start selecting targets for closer examination. The easiest place to start is on the larger budget items.
A lot of times, those costs are viewed as “fixed,” but maybe the situation needs to be looked at closer. If you’re spending a lot of money on hardware support, for example, maybe you should look at whether you can propose an upgrade or consolidation that could result in a net reduction in those costs.
(When you’re dealing with older gear, the cost of support can actually be larger than the cost of payments on new or leased equipment on an annualized basis.)
It can help to try to be creative. Perhaps you can look at moving something to the cloud or virtualizing on a smaller number of servers.
The whole process starts by identifying where you are spending your money. When Willie Sutton, the famous bank robber, was asked why he robbed banks, he said: “because that’s where the money is.” When we find out where the money is flowing out of the organization, we know which areas to target first.
Usually, we can use the current year’s expenditures as a baseline for our initial budget. There are some obvious problems with this because some costs change from year to year.
But you have to start somewhere, and at least the current year’s expenditures will give us a list of costs that need to be examined.
Costs should be estimated for as far forward as possible, not just for the current budget cycle. If there will be a significant increase in costs next year (due to warranty expiration or an End of Service Life (EOSL) component, for example), the plans for dealing with that issue should be put in place now.
When projects or changes are proposed, the savings, profits, and costs should all be estimated for the lifetime of the project.
Different types of estimates are expected to have different margins of error:
Rough order of magnitude (ROM) estimate.
This is sometimes referred to as a “ballpark estimate” or a “wild-ass guess” (WAG). These are frequently provided to give management an idea of whether to proceed with scoping out a project before the details of the project have been determined.
The expected accuracy of a ROM estimate is usually from 25% below to 75% above the provided estimate.
This type of estimate is made after the project’s preliminary scope is known, but before the full scope and detailed budget, the analysis is complete. The purpose of this type of estimate is to provide numbers for long-term budget planning. A budgetary estimate is expected to be within 25% of the final number.
Definitive estimate. This type of estimate is expected to be accurate to within 10% and is made after a full budgetary analysis.
Three different ways to perform a budgetary analysis are to
An estimate by analogy. Use other similar projects as a baseline for cost estimates. These estimates rely on the project manager to understand the approximate costs of the differences between the projects.
Bottom-up estimate. Find the cost for all the components and add the costs together. Assuming that everything is accounted for, this should yield the most accurate result.
Parametric estimate. These estimates are based on another estimated parameter, frequently lines of code or function points. These estimates can be surprisingly accurate, assuming that the estimate for the lines of code was correct and that the baseline information is accurate.
It is common for project managers to use a combination of these techniques as a confidence-building measure that the estimates are in the right neighborhood.
The obvious danger of a cost estimate is that human beings are prone to underestimate because we are wired to want to please management. On the one hand, we have to protect against this by being as complete as possible and allowing an adequate cushion for contingencies.
On the other hand, inflating cost estimates too far can lead to a job being overbid and lost, or can result in a project being canceled when the ROI (return on investment) analysis is unfavorable.
Defects are disproportionately expensive. If defects can be eliminated, it helps reduce overall costs. Quality management can be an important part of cost management.
Quality management also applies to cost estimates that are provided to the business. The way to improve the quality of those estimates is to track the variance between estimates and reality over time and use postmortems to identify where the variances come from.
As with most other things you manage, you will get results in areas that you measure. Measure quality, track it, set your team’s goals in terms of quality, and you will be able to improve it.
Negotiating Your Team’s Budget
There are several things you should do to improve your success in negotiating an adequate budget for your team:
Find out about the organization’s budget cycles and process. Identify the guidelines and deadlines you are expected to follow. Your peers and your boss are good people to find this information from.
Find out if there are cash flow issues and spending timing issues that you need to be sensitive to.
Get to know the finance people who are responsible for your team’s budget. Find out from them what their concerns are, and see if there is a better way to communicate your requirements, or to address their requirements.
What are the real concerns underlying the budget cycle?
Who are the decision makers? Make sure they understand what you are doing to control costs and improve efficiency.
Understand every line item of your team’s budget. If you don’t, follow up with your team members who manage that facility. Every expense should be associated with a particular facility that you are responsible for.
Start gathering the information well in advance of the deadlines. Ask for quotes from your vendors, and assign team members to compare the renewal quotes to the current inventory of facilities you are responsible for.
If they discover big savings, keep track of them, and give that staff member credit in a thank you email with your boss cc’d. Keep track of that information for their annual review. If you show your staff that you value cost savings, they will respond.
As actual numbers and estimates start coming in, compare them to what you expected. Understand the differences.
Push back on vendors who seem out of line; some vendors view a new manager as an easy mark. Get alternate quotes, and let the vendors know that there is a new sheriff in town.
Organizing the Information You Need
Everything starts with inventories of systems and software. Once you have those in place, estimate the costs associated with each system and each software license.
Then look for low-hanging fruit where reorganization or retirement can have significant cost savings.
Make sure that your team members understand that they are responsible for keeping their part of the inventory up to date. Also ask them to look for cost savings opportunities by decommissioning old facilities, and make sure that they get credit when they find them.
When your staff members look good, it makes you look good. Make it worth their while to make you look good by giving them credit for what they do right.
Tracking Costs and Benefits
The methods your finance team uses to track costs and benefits will be different from organization to organization. Work with your finance team to provide them the information in the format that is most useful for them.
Total Cost of Ownership (TCO)
The total cost of a system needs to be estimated for the entire lifetime of the system. If this number is not reported accurately and included in planning, management will not have planned properly for large increases in maintenance or licensing costs that may appear in the out-years.
By looking at the total cost, you also avoid problems with sales reps shifting costs into the out-years of a contract. That may help you look like a hero in the short term, but it will be very costly to the company over the long haul.
When I compare the costs of two solutions, I try to nail down all the hardware, software, support, environmental, training, and intangible costs.
The total package for each of the proposed solutions should be compared over the lifetime of the project. (In my experience, five years is a good time window, if the lifetime of the system hasn’t been specified elsewhere.)
I frequently find that the solution with the smallest upfront costs is among the more expensive once you consider the support and environmental costs in the fourth and fifth year of the contract.
Cash Flow Analysis
A cash flow analysis looks at the current benefits the organization gets from a system versus the costs of keeping it running. This sort of analysis does not take into account the sunk costs (what has already been spent) involved in bringing the system online.
Tangible costs and benefits are those that are easily counted in monetary terms. Accounting for intangible costs and benefits is obviously much harder.
Intangible benefits may be something like prestige, publicity, or ease of use. Some of these can be estimated as dollar amounts, but the analysis will necessarily be more subjective than with tangible costs and benefits.
Depending on the reason why you are running the analysis, intangible costs and benefits may or may not need to be reported or estimated. When you are asked to perform an analysis, try to pin down how intangible costs and benefits should be accounted for.
Direct and Indirect Costs and Benefits
There will also be direct and indirect costs and benefits to account for. An example of an indirect cost would be the electric bill to run air conditioning to the server room.
These costs could be significant, and some effort should be made to include them in cost analyses. (One way of estimating the cost is to find out what the annual electric bill is for the data center, and estimate what percentage of the equipment in the data center is associated with a particular system.
You can use a somewhat naïve estimate, for example, dividing by the total number of racks in the data center or something similar, but at least you will have a magnitude estimate.)
Sales representatives will usually follow your lead. Make sure they know what will get your business, and make sure that your criteria make sense for the business. Some things I look for from sales reps are
Accurate, timely information.
Solid project knowledge (usually from the sales rep’s engineering staff).
Tries to understand the challenges my organization faces.
Presents alternatives when appropriate.
Offers engineering assistance as needed to help size or scope the environment properly.
Interested in a long-term rather than a short-term relationship.
Recognizes that a reliable customer who provides references is worth a significant discount.
Some suppliers do not want to provide a quote for five years of support, or cannot provide solid quotes for the costs of expected upgrades three years in the future. In those cases, I try to insist on the rider to the purchase contract with “not-to-exceed” pricing in the out-years.
I’m not the only one who does this, and most vendors understand what I am after once I raise the issue. Sometimes the sales rep has to escalate the issue to a regional manager to get approval for these riders, but they are not usually a problem once they understand that you are serious about them.
Examine the stability of your suppliers when you make purchases. Check out their financials as if you were buying their stock. In practice, your company is making an investment in the supplier company.
If the supplier goes out of business, who is going to provide patches, service, and upgrades? Get a handle on whether the company is stable, and whether they are a likely acquisition target by someone who will abandon the product line you are purchasing.
When you make recommendations for a large purchase, there is a lot of money on the table. Sometimes you will be felt out to see if you would be more sympathetic if some of that money fell into your pocket. Don’t do it. It is illegal. More important, it is wrong.
I know people who have been offered a golf vacation in Bermuda or a new sports car to help a vendor land a seven-figure contract. In these cases, the offers were reported to their management, were discussed between the legal teams for the two companies, and negotiations suddenly involved some extra safeguards and concessions by the vendor.
Your organization has a policy for dealing with gifts from vendors, and a procedure for reporting bribe attempts. If you are put in this position, follow that procedure to the letter. Do not allow your good name and career to be destroyed for a few baubles.
Budgeting is not something that most technology people like to do. It is one of the tasks that tend to be procrastinated until the last minute. This results in sloppy results, which lead to lots of midyear groveling to get “extra” money for that service contract renewal you forgot about.
The place to start is with an accurate inventory, including systems, software, ongoing projects, and expected projects. Once you have a good understanding of where your money is going, you can both provide accurate estimates for the coming year as well as finding opportunities for saving your organization’s money.
What is the budget cycle for your organization? When do you need to hand in your preliminary budget? When is the final budget approved?
What method does your organization use to estimate costs and benefits?
Does your organization use charge-backs? How are they tracked? Is your inventory being charged back to the right departments?
One tactic for improving budget quality is to “finish” the budget two weeks before it is due, then review it again shortly before submission. What advantages do you see to this tactic?
Root Cause Analysis
Troubleshooting refers to the methods used to resolve problems. People who troubleshoot a lot come up with a set of habits, methods, and tools to help with the process. These provide a standard approach for gathering the necessary information to zero in on the cause of a problem. This standard approach is known as a methodology.
Methodologies save time while troubleshooting. They allow us to organize our efforts to devote every available resource to resolving the problem.
But a methodology only saves time when applied intelligently. It is possible to become so devoted to the process that we forget the purpose of the whole exercise—fixing the problem. It makes no sense to spend all our time writing logs and no time testing hypotheses.
Good methodologies contain tools for coordinating efforts and organizing the troubleshooting process. The key is to focus our time and resources, minimize the cost of the problem, and find and fix the root cause.
Unfortunately, many otherwise good technical people try to minimize the time spent resolving a problem by ignoring the process structure and documentation.
Structure keeps us from going in circles. Documentation provides useful information for avoiding wasted effort, fixing future problems, or evolving the design of our data environment.
Proper documentation also allows less experienced staff members to duplicate our methods and procedures. This is a key concern where these junior staff members are the primary support staff for vacation coverage or disaster recovery operations. (Who wants to get called off a beach in Florida to resolve a problem in the home office?
Some short-sighted administrators regard this scenario as job security. More mature admins regard it as a nuisance.)
Our techniques need to be seen as tools to be used to solve a problem. Not every home repair involves a wrecking bar and sledgehammer, and not every problem requires a full Ishikawa diagram and formal set of probability calculations.
With experience and maturity comes the judgment to decide which tools are appropriate for a particular problem. We have to practice the techniques so that we know how and where they will be most useful. Short-cutting the process unduly just causes problems in the long run.
In broad outline, troubleshooting consists of three phases: Investigation, Analysis, and Implementation. Presentations of troubleshooting methodologies sometimes present these steps with slightly different names or emphasize slightly different aspects of the process.
In this blog, the examples will be centered around troubleshooting computer system errors, which is something that technical teams need to do fairly often. The same techniques can be used to troubleshoot any type of problem, including organizational problems.
The Investigation phase consists of steps to identify the nature of the problem, gather information describing it and find distinctions between working and nonworking states of the system. The defining characteristic of the Investigation phase is the collection of facts, not opinions.
For nontrivial problems, we save time over the long run by not jumping immediately to Analysis or Implementation. There is usually a lot of pressure to “just do something.”
Unfortunately, that is not the most effective use of time or resources. There is a universe of harmful or irrelevant actions that we can take, and only very few actions that will improve or fix the situation.
At the beginning of the process, we need to name the problem. A good problem statement defines the problem in a broad enough way that it accurately portrays the effects of the problem, but is narrow enough to focus our problem analysis.
Value judgments have no place in a problem statement. The goal of a problem statement is to produce a concise, correct, high-level description of the problem. To do this, focus on what did happen versus what should have happened.
Ideally, the problem statement will specify a defect in a particular object or service. The problem statement should answer the questions, “Where is the problem?” and “What is wrong?”
Once we have named the problem, we need to list as many symptoms as possible without becoming redundant. In particular, we should list dissimilar symptoms—their juxtaposition allows us to look at common threads between them.
It may even be helpful to list the things that are working fine, as contrasted with items that do not work.
The start and end times of an outage should be nailed down as accurately as possible. This allows us to ask “What changed?” on a precise time window. We need this information for the next stage of the troubleshooting process.
We also need to get a handle on the scope and importance of the problem. Although these might not be directly related to the root cause of the problem, they will determine the types of tests and resolutions that we might consider to resolve the problem.
The importance of the problem will also determine how many resources we can spend on troubleshooting it. IT abounds with problems too expensive or too trivial to resolve.
The role of IT is usually to notify the decision makers with appropriate estimates of costs and consequences of a problem or its resolution. Business requirements and resources will determine which of the universe of problems will get our full attention.
Identify Differences and Changes
If we can compare the broken system to one that is not broken, we can see what is different. If we can identify what changed just before it became broken, that is important information too.
The Analysis phase is focused on taking the facts from the Investigation phase and explaining them. In this phase, we generate hypotheses from the information we have gathered, test the hypotheses, and report the results.
This stage of the troubleshooting process is all about the scientific method. Intuition and experience focus the investigation by identifying which possibilities are most likely to provide a solution.
Brainstorm: Gather Hypotheses
The Brainstorming step is where we try to identify all possible causes of the problem. We use the facts from the Investigation phase to generate hypotheses about the cause of the problem.
The symptoms and problem statement can be turned around to provide hypotheses. We ask ourselves questions such as “How can this item have caused this problem?” The answers can be added to our list of hypotheses.
It is sometimes useful to have a system diagram or other mental model of the system before thinking about possible causes. Each component of the system should be considered as a possible cause.