Manage a Team
Geographically dispersed teams have become a reality in most large workplaces. Organizations pressed to reduce costs are shifting work from high-cost locations to lower-cost locations. The challenges for dealing with all these types of team distributions are similar. In all cases, you are communicating and trying to forge a cohesive team across boundaries of space, time, and culture. This blog is about challenges faced by managers to manage a team.
Outsourcing is when work that was previously done in-house is done by an employee of a different company.
Offshoring is when work previously done in one country is moved to people in another country.
Nearshoring is a type of offshoring that uses people in nearby time zones to increase overlap between peoples’ work schedules.
Outsourcing and offshoring have caused a tremendous change in the way that information technology work is done. Coordination must be done across geographical and organizational boundaries. Cultural differences between people in different companies, regions, and countries have to be overcome. The challenges faced by IT managers today are different in scope and flavor from the challenges that were faced by previous generations.
The most difficult challenge is making a team out of this diverse group of people, separated by language, geography, time zone, and culture.
Is Offshoring More Efficient?
A lot of the analysis done by companies focuses strictly on the cost of salaries and benefits for comparable professionals in different locations. This sort of analysis is naïve and incomplete.
There are increased transaction and efficiency costs associated with both offshoring and outsourcing. These include increased travel and communication costs associated with managing the remote team members, as well as risk mitigation costs associated with doing business in a country with a different regulatory structure.
In some cases, companies have found that these additional costs outweigh the savings in salaries and benefits, and they are reversing the process (commonly known as onshoring or insourcing.)
Advantages and Risks of Global Teams
Executive management tends to overstate the economic benefits associated with offshoring to lower-cost locations. To someone who is not directly on the firing line, one system administrator looks like another system administrator, and the primary difference is the salary.
For people who have spent their careers managing technology directly, this type of thinking glosses over a lot of the bigger issues. There are a lot of advantages to having the technology staff closer to their internal customers.
In-person communication is simply more efficient than remote communication. Eighty percent of the content of a conversation is non-verbal. Video conferencing and telephones allow some of the nuanced nonverbal information to come through but not all of it. Some functions, such as requirements gathering, are much more efficiently gathered face-to-face.
Informal conversations allow back-channel communications to occur that can improve efficiency. It is much easier to request a small clarification, or for an improvement to come out of a quick conversation.
When you are in a different time zone than the requester, where you lose a business day to ask a question, you are more likely to just proceed based on your best judgment.
Local control. It is never as easy to manage people remotely as locally. Management by walking around becomes impossible when you manage people in remote locations.
Cultural norms. Cultural differences are less likely to garble communications or implicit assumptions about requirements.
Cohesion. A sense of teamwork is easier to foster when people are closer together.
Local responsiveness. It is easier to perform troubleshooting and product enhancement exercises with local people.
Uneven workload expectations. If all the escalations go to the remaining small group of employees at the home office, those people end up having to resolve all of the hard problems with a reduced staff.
Loss of core competencies. If outsourcing is done too aggressively, an organization runs the risk of giving away its strategic advantage to a competitor or supplier, rather than bidding out commodity work. Managers need to have an understanding of which functions are strategic advantages to the organization, and which tasks can be outsourced without losing a core competency.
Having said that, there are some legitimate advantages to dispersing the team globally:
Avoid groupthink. People from different locations and cultures bring different assumptions to the table. This can help avoid groupthink, as assumptions are challenged by having a more diverse group of team members.
Standardized, documented processes. Pressure increases to improve documentation of procedures. This can result in lowered defect rates if handled properly.
More work hours in a day. “Follow the sun” scheduling has the potential to allow teammates to have better work-life balance. Once processes are set up, and a culture of trust is in place, project teams can continue to work problems around the clock.
Agreements to outsource or offshore functions usually include stringent SLAs (Service Level Agreements), which are going to have to be met. If you can get the distributed parts of your team working together smoothly, it will make a big difference in your ability to comply with your SLAs.
Time and Distance
Coordinating efforts across time zone boundaries can be difficult. Com communications and responses are delayed. IT people are used to being able to ask clarifying questions to nail down requirements. But with time zone differences, a few rounds of clarifying questions and waiting for answers can mean delays of days or weeks.
In the next the following sections, I discuss several techniques that can help reduce the impact of this problem:
Create a project rhythm.
Set an expectation of synchronization.
Create a place for people to introduce themselves.
Standardize the format for common requests.
Standardize the process used to execute common requests.
Have some team members adjust their schedules to overlap. These employees can bridge information to the rest of the team.
Schedule team status meetings with team members from different regions.
Schedule travel to remote locations to allow in-person contact.
You won’t have the advantage of the natural rhythms of meal and break times when you are dealing with remote team members. Artificial rhythms will need to be built into project schedules and team formalisms such as staff meetings. Create a place where it is natural for your team members to collaborate. Chat rooms, conference bridges, scheduled calls, and project milestones are all tools that you can use to create these rhythms.
Your team members need to learn that you expect them to synchronize regularly with their remote colleagues. Ask explicit questions about what the conversation was like the last time they touched base. You may need to ask to be cc’d on emails initially so that you can make sure your team members are getting into the habit of synchronizing with remote team members regularly.
Team members need a space where they can express their individuality to the rest of the team. Social media tools offer a number of different ways for people to create profiles or personal summaries that other team members can view.
These introductions should include information about team members’ professional histories and expertise. That way people know who might be able to help them with a question they have about the XYZ protocol.
You do have to keep an eye on how much time is spent on this social media. As with a lot of things in life, there is a balance between making use of the tool and wasting project time.
There are quite a few technologies available to make it easier to collaborate over distance:
Voice mail (or video mail).
Groupware packages. (These allow collaborative authoring.)
Whiteboarding and desktop sharing. (These frequently have a facility to record sessions for people in other time zones.)
Calendaring and scheduling applications.
Richer applications, such as video conferencing, allow for a broader bandwidth communication, but at the cost of additional time and effort. The appropriate technology needs to be matched to the goal behind the communication.
Standard Formats for Requests
For common requests, your team members probably find themselves asking for the same information over and over. Generate a template that requesters need to fill out for these types of requests. This may be a web form, it could be a questionnaire, or it could be a spreadsheet. When a request arrives without the template information, push it back to the requester to fill out the form.
Compliance benefits everyone: the requesters are more likely to get what they want faster; your team is able to get its work done better, and the defect rate drops way down. Mention these benefits to your peers in the requesting teams when you introduce these templates; there is no reason you should not be able to get buy-in as long as your template is reasonable.
Ask for exactly what you need. Questions may need to be reworked a few times until the customer base understands them.
Get feedback from your customer community on the initial drafts of the template. Clarify points that need clarifying.
Do not ask for information that the customer is unlikely to have. If it is information that your team can figure out, find a way to script or standardize that process to reduce the time and effort your team spends on research while also reducing the defect rate.
If the team becomes disciplined about using standard processes, it will be easier for tasks to be handed back and forth between team members in different time zones. For example, if Fred in the United States is building a system, he can tell Samir in India that he is up to step 16 in the standard build process, and he can point him at the system request template for the needed information. After his shift, Samir can hand the build back to Fred for completion, and let him know that he is up to step 23.
It can take a while to get all the common processes documented and standardized. This is a lot of work, so team members will need to see some early wins to see the benefits of organizing things this way. Pick some early win processes to be documented and standardized. Ideally, these should have the following characteristics:
Common requests are going to give the most return on the investment of time and effort.
The requests need to have a lot of commonality in how they would be executed. If they do not, you need to rethink how you are characterizing requests. If you have a good procedure in place already, that will save some of the up-front preparation time.
Multistep procedures are the easiest to transfer across time zones.
If people are resistant to transferring tickets mid-execution, it may take some extra sales and mentor time on your part to get things jumpstarted. Once it gets going, team members will start to see the benefits for themselves.
They don’t have to stay late as often to finish a high-priority request; the ticket can be completed by someone on the next shift. Issues get resolved quicker, which makes the requesters happier.
It demonstrates the value of the team members in all the different regions. This helps deal with questions about whether the rest of the jobs are going to be offshored.
Make sure that the master company retains control and ownership of these standard operating procedures. In the event that a contract with an outsourcer comes to an end, the last thing the organization needs is to have to redraft operating procedures at the same time a team transition is taking place.
Some team members can be allowed to move their schedules earlier or later in the day to overlap with their colleagues in other time zones. This overlap allows more time for communications and handovers. It helps avoid the problem with questions not being able to be answered until the beginning of the next shift.
Bridge employees also help build trust relationships between people in the different regions. Having familiar people in the other locations helps to break down cultural barriers, and it helps to create a dynamic of trust and teamwork across the different employee populations.
Because the reasons for offshoring and outsourcing are frequently to achieve cost savings, it may be difficult to get a travel budget, and you will lose time when you are traveling. Even with all that, there is no real replacement for face-to-face contact when building a team.
Your team will really come together when they see substantive things that were accomplished by the team. Technical people like to get things done. When they succeed, find ways of celebrating. Here are a few ideas:
A congratulatory email from someone high up the organizational food chain.
Individual awards or certificates for each person’s part in the project.
A web page touting the accomplishment to the world, with specifics.
Arrange for an edible treat to be delivered to team members in each site on the same day.
Staff meetings across the regions allow team members to see what other team members are doing. This helps reduce resentments about workload, and it can help bring different perspectives to bear on common problems.
These will need to be scheduled at the beginning of one team’s work day and at the end of another team’s shift. There is no convenient way to schedule them; everyone will need to give a little for these to work.
Language and cultural differences can interfere with how effectively a team is able to work together. Misunderstandings can sap a team’s energy. Different people from different cultures communicate in radically different ways. These are not always clear to people who are not used to working with people from the other countries in question.
These differences include differences in etiquette (dos and don’ts), values, beliefs, patterns of thinking, patterns of communication, among others.
It is easy to find lists of these differences. Here are a few frequently observed differences between Indian workers and their western colleagues:
Indians engage in small talk less easily than their western counterparts. In some cases, technical training courses actually discourage students from engaging in small talk to avoid embarrassing exchanges.
Inquiries about time schedules get different responses from different cultures. Indian respondents typically do not include time to deal with any difficulties. Managers can work around this by probing to find out which if any project issues have been included in the time estimate.
People from the southern part of India use what is sometimes called the “Indian wiggle” in which the head is shaken side to side. This is frequently misinterpreted by westerners as indicating “no” (i.e., as in a western “head shake”), when it really indicates anything from “I agree” to “I hear you.”
Indians frequently use a “wobbly yes” rather than saying “no.” Western managers need to watch a less-than-firm “yes” and drill down if necessary. All of these are examples of differences in cultural norms. Unfortunately, it is all too easy to fall into the pattern of expecting that everyone else communicates the same way you do—after all, isn’t that what makes “sense?”
There are no rights and wrongs here, just differences. Managers need to learn to understand and value different team members from different cultures. And they need to set a tone within the group where people are not meant to feel bad about who they are or where they live. Folks are just folks. Technical people are, by and large, hard-working, dedicated people. It is not easy for anyone to achieve technical competence. Value your people, no matter what their background is.
There have been several different efforts to characterize cultural differences in measurable ways. One of the more effective ways of breaking things down was put forward by Geert Hofstede and Edward Hall. Some of the axes of cultural orientation that they proposed to include the following:
This refers to the emotional distance between subordinates and superiors. Most Asian cultures and Russia tend to have more autocratic leadership cultures, while the United States, Israel, and most European countries tend toward more participatory cultures. When working across these cultural norms, someone from a more participatory culture may need to put forward extra effort to get input or constructive criticism from someone whose cultural leadership norm is less participatory.
This can be expressed as individualism vs. collectivism. In general, wealthier cultures tend to be more individualistic than less wealthy cultures. This is true even within specific countries or even regions of particular countries. Managers need to be particularly sensitive when criticizing employees in a group. Reprimands should be handled individually.
This axis has to do with a comfort with ambiguity, and a preference for rules and expectations to be set out explicitly.
Cultures with a high future orientation value delaying gratification to improve the situation in the future. East Asian cultures, such as China, Japan, and Korea all have very high future orientation scores.
Low-context cultures listen more to what is said rather than considering the tonal and peripheral information about the communication. High-context cultures like to consider the context of a communication, which may not be apparent in an email. Northern European and US cultures are generally considered low-context cultures, whereas southern European, Latin American, and Asian cultures are high-context cultures.
This is sometimes called fatalism and reflects the extent to which someone believes they can control the future.
This is the extent to which people believe that the same rules apply to everyone.
Information processing orientation.
Richard Nisbett performed research showing that Asians are more likely to see relationships and context, while westerners are more likely to see categories and taxonomies.3 Different people are going to see the same situation differently.
These observations are generalizations, of course. Any time you are dealing with human beings, you need to get to know them as individuals to understand how they think and how they will react. But the cultural orientation axes are useful to help you think about how people are different, and how best to communicate with different people.
Even when English is used as the standard language, there are significant differences between how people from different cultures will understand the same set of English words.
Sometimes, this is a result of how the English word translates back to the speaker’s native language. Sometimes, it is a result of words having a different connotation in different places. For example, the word contractor can be understood in India to mean a janitor, and a vendor is someone who sells things in the market. The consultant is a more appropriate word to use in India for someone who is providing services to your team.
For another example, consider what someone from Latin America means when they say now. Depending on the context, it may mean right away, or it could mean by the end of the business day. Spanish has more than one word that translates to now, so this is not a matter of a cultural difference so much as an incorrect translation of intent.
Beyond what words mean, many Americans have difficulty understanding the accents of people from other countries, even of native English speakers from countries like India. Written communications can help bridge the gap while the American ear becomes accustomed to the different accent.
Avoid slang and idioms. Use international English, with no sports metaphors.
Be aware of words that may have different meanings for different cultures.
Be explicit about expectations. State requirements and dates clearly and concisely.
Break up long messages into paragraphs and bullet points. Keep sentences short and simple.
Repeat urgent requests through multiple channels (e.g., email and phone conference).
Request feedback to try to track down questions.
Follow up verbal requests with something in writing.
Above all, clarify and follow up. Even when you think something is clear, it may not be understood on the receiving end.
Managing Software Development Teams
In most ways, managing a software team is just like managing any other type of technical team. Technical teams are all made of talented experts. The manager’s job is to enable these experts to improve the organization’s business capability.
But managing a software development team is also different than managing another type of team. Tools change and languages change, but software development is a profoundly creative enterprise. The widgets, libraries, and other primitives grow in size and complexity, but there are a nearly infinite number of possible ways to accomplish a particular task. A member of a software development team can put a personal stamp on his or her contribution in a way that most other technical people can’t.
Note A primitive is one of the basic building blocks that is assembled into a program.
With that nearly infinite number of ways to get from A to B comes a need for judgment and intuition. A good programmer will consistently identify efficient and easily communicated ways to accomplish a given task with the tools at hand.
It is probably impossible to come up with a definitive procedure for producing good code. That is why writing code is a human enterprise, and the talented humans who write code need both skill and intuition to do it well.
Defensive coding should be your foundation. Good programs should be resilient, easy to troubleshoot and allow for graceful recovery from errors.
The fault-tolerant code will anticipate the possibility of problems and will recover without causing data corruption. Error handling is an under-appreciated, critical part of good coding practices.
When evaluating your team members’ work product, emphasize error handling, logging, and recoverability. As with any other value that you define as being important for your team, message relentlessly. Recognize excellence. Require dependability. If you measure and reward reliability, your team will produce reliable software.
Software that is big enough to really be useful is seldom written by one programmer. Most software is a collaboration between people and across time. As new capabilities are added or bugs fixed, the new code is incorporated into a software package.
Maintaining software written by someone else is not usually a programmer’s favorite task, but it has to be done. The same discipline and attention to detail that goes into a new development project have to be applied to software maintenance.
If your software development team understands the importance of maintainability, they will implement it. Make sure that they think of the development not as just a cool technical puzzle to solve, but as writing a block of code that can stand for generations.
Use code reviews and other techniques to make sure that the code coming from your team is clean, well-structured, and easily understood. That may mean in-line comments, or it may mean external documentation. Whatever method you use, make sure that your team’s code will live well past the time when the team members have moved on to their next big jobs.
The maintainable code can achieve its own sort of immortality. If the code is maintainable, the business has an incentive to keep the existing package (with enhancements) rather than undergo a painful migration. Help your developers develop a vision of their software as something that will help solve problems that they haven’t even thought about yet. And then help them to follow disciplined documentation and structural practices that will help them achieve that goal.
If the software is not written with operations in mind, it will fail in its primary mission: bringing value to the organization. Finicky, unreliable software consumes operational resources, creates resentments, and destroys the reputation of a software development group.
Operational excellence is built on attention to detail. Little things, such as disk housekeeping, log rotation, configurability, and security of temporary files all are hallmarks of excellent software. It doesn’t take the that much extra effort to be thoughtful. But the payoffs to the organization can be huge. And what helps the organization helps the development team.
When designing software, consider how it will operate in a disaster recovery context. If the software cannot recover gracefully in your organization’s business continuity environment, it will be a liability to the organization’s disaster readiness.
How well does the code deal with an interruption in the plumbing connections to the database and other programs? How difficult is it to point it to new data sources in a new context, such as a disaster recovery?
If continuity is not built in at the beginning, the code will be a monster to recover. Nobody appreciates spending time and money developing an infrastructure to recover an application that was not developed with continuity in mind.
Your team’s software also needs to be able to operate in the context of your organization’s job scheduling environment.
Environment-variable settings should be addressed within the program context, from configuration files, rather than requiring that the execution environment have certain variables set in certain ways.
Status codes should be clearly defined and discrete so that the scheduler can branch execution paths depending on the outcome of the program.
It all boils down to understanding your team’s code in a broader environmental context, rather than focusing on a narrow piece of functionality.
Another type of software immortality is reuse. If a module is useful, well-documented, and maintainable, why write another module that does the same thing?
Objects created by developers should be organized into libraries that can be tapped by other developers. Recognize the tool builders within your team for the valuable contributions they make. And also recognize the people who increase the efficiency and velocity of your development process by reusing code from the repository.
Obviously, not every piece of code is suitable for reuse. Some problems are too specific for their solution to usefully be applied elsewhere. Experienced developers should be able to identify modules that are suitable for sharing in the repository.
There are some obvious obstacles to implementing an infrastructure that supports code reuse:
Organizing the repository in a way that will be useful is nontrivial.
The code in the repository needs to be maintained as bugs are fixed.
The mindset of the developers needs to be changed to look in the repository.
There needs to be enough useful material in the repository for developers to have an incentive to look there.
The organization’s development mindset needs to become more product-centric and less project centric.
These obstacles are significant, and that is why so few companies have an organized code reuse system. Especially in organizations where project managers are brought on for a short-term project, there is little incentive for a project manager to invest resources from a limited budget into a code repository that will mostly benefit other project managers in the future.
If your organization hires project managers on a per-project basis, someone outside the project management infrastructure may need to take on the challenge of making the changes necessary to encourage code reuse.
Project Management Challenges
A common challenge for software development managers is that they need to pull in team members who actually report to someone else. There are some challenges involved with managing a team whose members’ primary loyalty is to someone else.
When you don’t have direct executive authority over someone, you still have a lot of things that you can offer as a project manager.
Access to new technologies.
The excitement of being part of a team making something new.
Leadership opportunities within the project team.
Project work looks good on resumes. Especially if it comes with a good recommendation from a project manager.
A chance to get away from the daily grind.
Obviously, everything gets harder if the team member’s regular manager is not enthusiastic about his or her participation. You may need to exercise some of the skills we discussed in blog 10 to encourage the manager to see the importance of the project. Or you may need to engage the project champion to reinforce the priority of the project.
Keep in mind that your project schedule depends on the availability of the resources you demanded when your project schedule was approved. If the resources available to you change, that also will mean that your project schedule is impacted. Make sure that this message is passed along to the project sponsors so that they understand how important it is to reinforce your authority over the resources you have been promised.
Maybe the nature of creating something out of nothing excites people and fires their imagination. Maybe the inputs are largely invisible to the end-user, so they assume that their requests are cheap. Whatever the reason, scope creep will strangle your software project if you don’t tame the monster first.
Change management is your friend. Establish a process to examine the cost of every change before it is considered for approval. Cost may come as time, it may come as money, and usually, it comes as both. If costs are inflexible (as they usually are), approvals may require a trade-off of another requirement.
A common problem is that people think that a feature that is easy to describe is easy to implement. This is obviously not true. It is nice to have a clear statement of a requirement, but that doesn’t mean that the feature is easily implemented.
Sometimes complexity can be explained by showing the design that will be necessary to implement the feature. It is management’s job to push on you to make sure the company’s resources are not being wasted by too relaxed a project schedule. It is your job to push back with information and facts to demonstrate that you are making wise use of your project budget.
The Importance of Testing
When people want to push a schedule, the first place that is considered for cuts is testing. Professionals understand just how important it is to have a complete test cycle. Issues are much more easily addressed when they are discovered during testing than if they are only discovered after the product’s release into production.
Your team may also be a part of this dynamic. Programming tends to attract personalities who are eager to move on to the next challenge, not look back to fix minor errors in what they did yesterday. Preach the importance of quality within your team, and the importance of testing to achieving that quality.
Leave adequate time for testing. Push back on management or even your own team when necessary. If a schedule change is needed, it would be better to postpone a feature or bring on more people than to eliminate testing.
Testing As a Way to Measure Quality
One of the main benefits of a good testing program is that it will provide a solid quality metric. Once you get a handle on which team members need help to meet your quality goals, you will know where to focus your time and efforts. As with many other things in the workplace, you get more of what you measure. If you measure quality, you will get more quality.
Every Requirement Gets a Test Suite
Every listed requirement needs a defined test suite to verify that the end product meets the requirement. Some methodologies even specify requirements in terms of the tests that are used to validate them.
Software engineering maps user requirements to functional requirements to code to tests. Every line of code should be able to be mapped back to the user requirements that demand it, as well as being able to be mapped forward to the test suites that validate those user requirements.
Programmers are optimistic people. They need to be that way to believe that they can create something out of nothing. Software developers believe that what they write works, otherwise they would never have written it.
Just as management can sabotage a testing program by starving it of time and resources, developers can kill a testing program by neglect.
The importance of thorough testing needs to become engraved in your team’s DNA. Testing is part of your overall emphasis on quality from start to finish. Poorly written tests are a sign of laziness or inattention. Mentor team members who tend to be more prone to skipping “unneeded” testing. Teach them how to test thoroughly, and then measure their quality directly. Pride is a powerful motivator, and measuring and recording defects will encourage more careful testing during the development process.
Many other technology teams manage or build tangible capital assets. Unfair it may be, but senior management can view their contribution as being more valuable than a software team’s contributions because it is easier to list those contributions on a balance sheet.
A software team’s contributions are only valuable if they deliver more tangible value to the organization than the cost of running the team. Make sure that you have a business case to support your activities. Then make sure your business cases are in a well-publicized share that is available to management.
Document Your Progress
Unlike your peers in other technology areas, the products of a software development team are not visible until they are available for testing. For management, a software development team looks like a black box that consumes cash with no tangible output.
Make sure that management understands your project plan, and that they have a way to measure your progress toward completion. Communicate out your testing results, for unit tests, integration tests, and acceptance tests. These test results can be a way to demonstrate tangible progress toward the end goal.
For projects using prototyping methodologies, prototypes can also be tangible reminders to the project sponsors of why they are spending money on the project. One of the advantages of prototyping models is that management is less likely to lose faith in the project because they have a way to view tangible work products that show a clear progression toward the project goals.
If your team is using a diverse set of tools, team members will not be able to help each other out when questions about those tools arise. And when they are troubleshooting a problem, it may be harder for different team members to reproduce the problem in the same way.
There is always some space for personal preference, but a software development team needs to be using a standard toolset. If one does not exist for your organization, part of your challenge will be to define one for your team.
Make sure to get the best tools you can arrange. Cost is always an issue, but skimping on tools is a false efficiency. Figure out how much more quickly your people can work on good tools versus crappy tools, and figure how much it will cost the company to have the software delivered that much later.
As with any other management challenge, discuss the issue with your team. Explain the problems that can arise from having different people using different toolsets. Foster a discussion of the pros and cons of the different tool choices. Then make a decision what the standard will be and get on with building the piece of software.
There are some processes that you will revisit over and over throughout the development process. The code builds, deployments to a higher environment, database refreshes, and ETL (Extract, Transform, Load) tests are all examples of such processes. These should be handled in a defined, repeatable way.
If you take the time and thought to build the tools to support these processes, it will save you time on any project of significant size. If you look at the amount of time to do a database refresh, multiply by the number of times you have to do it, and then multiply by the number of developers idled by a database refresh, you will understand just how much it is worth your while to nail these processes down.
And if you can script and standardize your code deployment process, you will eliminate entire classes of problems, such as the problems caused by failing to upgrade a single module during the upgrade process.
If you don’t have a standard naming convention for objects, you are likely to end up with multiple distinct objects having the same name, or with team members spending more time than you would like trying to resolve problems resulting from an incompatible naming scheme.
Come up with a standard and conventions. Circulate these for feedback from the project team, and take the feedback into account. Then publish the naming standard and insist on its use.
Backups and Version Control
Define a version control standard, and make sure there is a way to roll back to a previous version when a new bug is accidentally introduced in a new version. If there is an organizational standard for these capabilities, use that. But don’t let the project get underway without these capabilities being used by your development team.
Bug Tracking System
Track bugs and reported issues in a standard shared way. People on the project need to be able to examine bug reports and resolutions. It is your job to make sure that they have a standard tool and process for reporting and tracking bugs and issues.
There are a ton of software methodologies on the market, and each has its adherents. Each methodology solves the age-old problems of software development in a slightly different way. The core problem is to deliver useful tools to the organization in a timely way.
It is important to pick a standard approach so that you can take advantage of tools and templates that are available to support that approach. If the organization has a standard, the tools and templates are probably already in place and should be able to be adapted to your circumstances.
Standard software development methodologies include training, tools, and templates that would be hard for you to reproduce. You may not want to use every tool or template for every project, but having a well-defined, well-known methodology can give you a leg up on creating a rhythm within the team.
A lot of the new Agile software development techniques are focused around delivering prototypes quickly. The Agile conceptual framework uses iterative cycles within defined time windows to promote the interactions between the end-user and development communities in a structured way. By treating software as an evolutionary process rather than a large, monolithic development waterfall, Agile methods aim to accelerate a software lifecycle process that is sometimes too slow to keep up with the shifting demands of an ever-changing user community.
The pace and the order of operations may be different, but the end goal is always the same. Deliver useful capability to the business in time for the business to be able to take advantage of it.
No two software development situations are the same. An organization needs to develop a rhythm that fits the organization itself, not the organization that spawned the methodology.
From a management point of view, the key is to have a methodology that works in this organization. Pick a methodology that works for your environment and your project. Use ideas that work in your environment, and don’t be afraid to apply different rules to different projects if the extra overhead makes sense.
Managing software teams is both the same as and different from managing other technical teams. A lot of the challenges are the same.
But there are also important differences. Software development is a profoundly creative enterprise. Management’s challenge is to unleash the creativity while at the same time steering it in a direction that will maximize business value.
Do not allow your development projects to be hijacked. If the effort is redirected, make sure it is only after a clear-eyed assessment of the benefits and costs of the change, and with buy-in from an established change control process.
Emphasize quality, and measure quality directly with a rigorous testing regime based on a clear understanding of requirements. Use your quality measurements to find ways to improve your team’s contribution to your organization’s bottom line.
Integrating Third-Party Software
In some ways, integrating an externally produced software product is more challenging than building a homegrown product. Even if the product is designed specifically for your industry niche, there will be features that you wish that you had, and you also will be paying for features you don’t need.
You are going to have to pay software development money to customize and configure the software for your environment. And your organization will need to invest in time and training to reshape its processes to fit the paradigm and limitations of the new software platform.
A good software integration project can save the company huge amounts of money and dramatically improve the company’s efficiency and competitive profile. A bad integration project can bleed a company dry. Do everything in your power to make your integration project a success.
Note A package that is intended to fill a core business requirement should not be selected by the technology staff. The decision to seek a solution and the selection of a third-party vendor must be driven by business needs. The evaluation and selection process needs to be owned by a key business stakeholder, and the process must include input from representatives of the directly affected groups.
Research and Vendor Selection
Before you invest in a supplier’s product, examine what is in the marketplace. Search the web for review articles about the type of software you are interested in. Then search the web for each of the software vendors mentioned in the review articles. At each step, look at each vendor’s information to see which other vendors they compare themselves to. Then search out those vendors’ information too.
During this information search, you will be deluged with information. You need to structure the information you gather, otherwise, you will start confusing which vendor has what feature set and what type of reviews. For each vendor, track the following information in your research documents:
Vendor name and product name.
Links to the company and product web pages.
Sales representative and sales engineer contact information.
The feature set, especially the features relevant to your organization.
Summarize the sense of the online reviews and comments you find about the software.
Links to the most relevant or interesting online reviews.
Pricing information (including maintenance cost information, preferably going out at least five years).
Information about the frequency of updates and patches.
Information about the amount of effort required to upgrade or patch the software.
Training information and links. Are there free online courses? Are training credits offered with the purchase?
People within your organization who have experience or expertise with the software.
People in your community (including online contacts) who have information or experience with the software.
Information about and introductions to vendor user groups. These groups are good forums for learning about new product developments, as well as advocating for new features or fixes to issues.
As part of the evaluation process, create a scorecard. The scorecard should include entries for significant areas such as purchase and maintenance costs, as well as key business and functional requirements.
These requirements should include information security, audit, or compliance requirements.
The software should be considered as a part of your business’s ecosystem, existing processes, and culture, and should be scored accordingly.
Each requirement should be weighted according to its importance, as specified by the key stakeholders, and scores should be assigned. This scorecard will be an important part of getting key stakeholders to coalesce around a consensus solution.
A rookie mistake is to assume that you can keep all this information in your head, or that you can easily search the information out on the web as needed. Don’t fall into this trap. I can guarantee that there will be some crisis that will emerge when you are in the middle of the search, and when you come back to the search, you will kick yourself for not collecting and organizing your previous search results.
One decision you will need to make is whether your solution will be implemented in-house, or in the cloud.
The “cloud ” is a generic term describing solutions that are housed by a vendor and accessed over a remote network connection. There are several different varieties of cloud-based solutions:
IAAS: Infrastructure As A Service. This sort of vendor provides a location where virtual servers and storage are available to run the customer’s applications.
PAAS: Platform As A Service. Platform vendors typically go one step beyond IAAS vendors. With a PAAS vendor, you will typically get an operating system and program execution environment. Frequently, this will include a database, web server, and application layer environments available for running custom-written code.
SAAS: Software As A Service: SAAS vendors typically provide the entire software environment to customers. The advantage is speed to deployment and ease of administration, but vendor lock-in is much more of a concern than it is with IAAS or PAAS.
(Some definitions also include Network As A Service (NAAS), which outsources the responsibility for the network connections between different components in the cloud.)
The main advantages of a cloud model are:
Cost: Cloud solutions are typically much cheaper than traditional alternatives.
Speed: It is almost always faster to deploy to a dedicated cloud environment than to build out your own system.
Flexibility: Because the deployment costs are usually lower, there are fewer sunk costs and lower barriers to entry to consider for new upgrades.
Easier maintenance: Maintenance belongs to the cloud vendor, removing an important distraction that you would otherwise have to plan around.
There are some disadvantages to a cloud model as well:
Loss of control: You can have any flavor you want, as long as it is vanilla. Your vendor decides what options to make available.
Integration: Integrating the vendor’s software into your environment may be challenging, in part because a lot of vendors’ products aren’t designed to be interoperable.
Lock-in: Your future becomes tied to the future of your vendor. Especially with SAAS, migrations become difficult.
Performance: Depending on the solution, the performance may or may not be better, but it will certainly depend on the quality of your network connection.
Security: Similarly, the level of security available is determined by what your vendor makes available.
In the end, you have to weigh your options and do what is right for your employer.
Proof of Concept
Research alone will not give you enough information to select a third-party software vendor. If this is a large investment or is a strategic component of your company’s business operation, then you will need to go further to ensure that you are making the correct decision.
You can sometimes use the application for a period of time in a “lab”- type setting. This approach is often referred to as a proof of concept (POC) or a proof of implementation (POI). You will need to create a short list of vendors based on the research, demos, and the results of reviewing the responses to requests for information (RFI) and requests for proposal (RFP).
You will need to plan and work with each vendor to engage in a small but meaningful proof of concept. The goals of the POC should consider all aspects of the vendor package that is relevant to your company, which may include the following:
Use cases that are important to your business users.
Validation of all integration points with your technology and applications. The vendor may offer several ways to integrate with your internal applications, so you will want to try to use and compare each method.
Agreement on how the vendor package will be deployed to your production environment to ensure compliance with your company’s release management and deployment process.
Verification that the package will not conflict with your company’s information security or data center policies.
Specifications for how the vendor package should be monitored, and what tools and mechanisms are available to do troubleshooting.
Experience using the vendor’s customer service and support.
When you select a third-party software vendor, you are making an investment in that company. You will invest significant amounts of money deploying and customizing the software to your organization. Then the people in your organization will spend significant amounts of time adapting their daily work-flows and processes to use the software. If the software company or product line disappears, you will have an expensive piece of legacy software that will be difficult to replace.
Investigate the company as if you were going to buy stock in it. Look up financial reports and online analyses of the health of the company. Search the web for information about the company and its place in the competitive marketplace.
Who are the company’s main competitors? Is there some likelihood that the company will be acquired? If it is, how likely is your target software package to survive the merger? What are the track records of likely merger partners?
Do the same for the software package. Sometimes companies end up with two or more software packages that play in the same marketplaces. Look into the possibility that your target software package might disappear from the marketplace. If that happens, what would you do for support? Patches? User communities? Consultants and experts?
More than one company has invested in integrating a software package, only to have the software package become an orphan. Do whatever you can to avoid becoming a statistic.
Negotiate to price relentlessly. Point out the features that you don’t plan on using, and ask why you should pay for them. And point out the features gap. Ask when that feature will be implemented. Ask what the process is for requests for enhancement (RFEs). If possible, get it in writing. And then bargain the price down based on the risk you are taking on the vendor.
Secure proposals from more than one company in the marketplace. Look at the strengths and weaknesses of each proposal. Then discuss these strengths and weaknesses with each of the vendors. Make them sell you their product; part of that is to get the best possible pricing for your company.
The top-line price is not the only cost you should take into account. Take into account the costs of integrating the software, supporting it, updating it, training your staff, and deploying it to your user community.
Frequently you can get credits from the vendor for many of these costs. Look for training credits or hours from the vendor’s consulting arm. Negotiate for years of maintenance bundled in, or at least for not-to-exceed pricing for support at the original discount rate. You will never have as much leverage as you will have prior to signing the deal; you owe it to your employer to extract maximum value. And get everything in writing.
Don’t let yourself be swayed by personal attachments to sales reps. Judge the product on the technical merits, including the costs and opportunities at all stages of the product’s lifecycle.
Another way to fund the purchase of a vendor package and support is to negotiate a revenue sharing arrangement. This is not always an option depending on your business, but it has many benefits. In this scenario, you are offering the vendor to put “skin in the game” in return for sharing in the revenue achieved with a successful implementation and long-term stability and performance of the application.
It is important to make sure that the service level agreement (SLA) includes penalties in which revenue sharing payments are held back for breaches of the SLA. In this arrangement, it is in the vendor’s best interest to deliver versions of their application on time and with high quality.
No matter how friendly the sales reps and sales engineers are, they are in business to take as much of your company’s money as possible. Your job is to maximize value for every dollar of your company’s money.
Your legal agreement with the vendor should include penalties for failure to perform. Use your leverage to add enforcement language to the agreements with the vendor to deal with nonperformance or failure to meet agreed-on targets.
When there are problems, raise them with your vendor. Be clear. Be definite. Pull out the paperwork and emails, and show them where the vendor has failed to meet its commitments. Negotiate to have the problems fixed, promised features added, and to get compensation for shortcomings in the vendor’s deliverables.
You don’t have to be a jerk, and you don’t have to get angry. In fact, you will be more effective if you keep your temper and stay businesslike. State your case clearly, cogently, and effectively. And demand that the vendor produce the results you thought you were getting when you purchased the software.
There are several types of support you need from your vendor. At a bare minimum, you need the ability to find out about the product and get help fixing the problems that emerge. Here is a quick list of some types of support you need from your vendor:
Information on new products and features.
Methods for communicating problems and enhancement requests to engineering.
Links to experts or consultants.
Access to a user community.
Some vendors spend significant resources developing an ecosystem surrounding a product. These communities of users and vendors can be invaluable in resolving problems, recruiting support staff, and identifying consultants for short-term projects.
Have a phone number of a specific person at the vendor whose job it is to keep your company happy. Then be clear about your expectations and demand excellence.
Before bringing a software product into the environment, you need a clear understanding of how the product will fit into your environment. What value do you expect to see? What functions will it fill?
Talk to other customers, and verify that the software is capable of what you need. Find out how much effort is required to customize the software for your environment, then estimate the costs associated with that effort. The development costs are part of the project budget for the overall integration, so they have to be included in your proposal to management.
Once you start integration, treat it like any other software development project.
Success starts with your sponsor’s buy-in on clear requirement statements. Translate the requirements to clear functional specifications, and develop a test suite to validate the results.
The fundamentals of a software integration project are the same as for a blank-slate development project. Identify the business need, design a way to fill the need, and then execute the design in a timely, professional way.
The business needs to own the selection process and be a key part of specifying, procuring, and testing the application during the deployment process. That will help avoid a mentality where there is an expectation will be that a purchased software product will just work. For anything more complicated than an office productivity suite, that expectation is poison.
The conversion from the existing application to the new package needs to anticipate the following:
What existing data needs to be transferred (and often transformed) to the new platform? This data may come from anywhere in the organization. Some applications calculate data on the fly without storing it in the database. You will need to figure out how this data will be seeded in the new platform since it may not actually be stored in the legacy platform.
How will users validate that the new platform is correct when the cutover is performed? This is often an after-thought that usually requires the application development team to provide (build) onetime utilities. Typical issues include automating and streamlining validation by the users, frequently by comparing outputs/data between the old and new platforms.
Any large implementation should plan to include several mock or trial conversions. This is needed to fine-tune the detailed steps leading up to the actual conversion/ cutover. Understand and optimize the time needed to execute the detailed steps in this process. Remember, you will need to be able to complete the deployment and conversion (usually on a weekend) and have time to do the checkout and failback in the event the cutover or conversion fails.
The team needs to start planning early on the approach to be used for implementing the new platform. Will, it be a big bang or be done in phases? Will there be a pilot period in which a small set of business groups and users process a subset of the business in production prior to cutting over the rest of the business?
If the stakeholder communities have been intimately involved in the selection, proof of concept, deployment, and testing process, a lot of issues around end-user training will be apparent long before cutover day. Track issues that appear during testing, and keep them in mind for the rollout of the application. The more people you can involve in the POC and testing phases, the less of an issue this will be.
The user-training program is an essential part of a deployment. If people don’t use the product because they don’t know how you have wasted your time and your employer’s money.
Appropriate training will depend on the nature of the software. It may include documentation with step-by-step instructions and screenshots, it may include presentations, and it may include formal classroom training.
The success of your training program will be measured by your target audience, not your developers. Test your training program on a small group of end-users, and find out whether it was effective. Have them explain the material back to you.
Eventually, a software product will need to be replaced. It may be that the package has reached the end of its support life. Sometimes an old package no longer fits in an ecosystem dominated by another product. And sometimes a package has been a complete disappointment.
When it comes time to replace a product, first understand what valuable functions it is fulfilling in the environment. If the proposed replacement products do not share all the required functionality, find ways to fill the gaps.
The entrenched product has the advantage of familiarity, whatever its disadvantages. Your training program will be the key to overcoming this advantage as far as possible. Planning the resources for training is more important in a replacement situation than in a blank-slate situation.
When selecting the replacement, take a clear-eyed look at the strengths and weaknesses of the proposed packages, including the integration costs. You may find that the best alternative is the software package that is already in place.
Know What You Don’t Know
Technical people are used to being the smartest person in the room. Now you are managing a room of people who know a lot more than you do.
Don’t try to fake it. You know how easy it is to spot a poser in your own technical specialty. What makes you think it is harder for someone in a different specialty?
When you speak to your team, you can still pull out your old war stories to demonstrate the importance of the values you are trying to instill in the team. (The time the change went bad to demonstrate the importance of testing, for example.) Technical people are similar enough in the mindset that we all appreciate each other’s stories.
But when it comes time to discuss approaches to a problem or the guts of a technical issue, your job shifts. You are no longer the senior guy who can propose solutions. Now you are the facilitator to make sure that all the technical experts in the room have a chance to be heard and have their ideas considered.
I had a bit of fun at the expense of nontechnical managers in the Introduction. When a technical person takes over leadership of a team in a different specialty, that person is effectively a nontechnical manager. Not only that, the new manager has some distinct disadvantages over his or her nontechnical colleagues:
Habits of a professional lifetime. Suddenly, your reflex to just fix what is broken is problematic. Your job is no longer to propose or implement solutions. Your job is to facilitate conversation and to get your team the resources to resolve the problem.
Lack of training. A lot of nontechnical managers have training or degrees specifically about how to manage effectively. Most technical people have focused their attention on technical training, not people management training.
Public reputation and persona. Your nontechnical counterparts are used to dealing with you as the person who knows the answers and can provide solutions at the drop of a hat. If you try to keep this up in a specialty where you don’t have the answers, you will just get yourself into trouble.
These are all barriers, but you also bring some significant advantages to the table:
Experience managing technical people. Usually, by the time you manage people in another specialty, you will have been supervising people in your own specialty. A lot of the same skills will translate.
Street credibility. As long as you don’t claim to be an expert where you are not, your expertise in another specialty will be viewed with respect by your team. They know that you have paid your dues with late night troubleshooting calls and that you understand the rhythms and organizational challenges they have to deal with.
Credibility with management. Since they know you have been in the trenches, management will expect you to be able to translate between the technical and nontechnical people in the organization. This may be the most important role of a technical manager at any level.
Maturity. You may not be older than the people you are managing, but you may have a more mature view of how IT works than a lot of your subordinates. (Not all of them, of course. You will rely on the seasoned experts in your team to help you steer clear of pitfalls.)
Throughout your management career, you have needed to develop skills in listening to your team members. As you have matured, you have recognized that you can’t carry the entire load on your own and have come to rely more and more on your team members.
Now listening is the skill that will make or break your success in managing your new team. If you try to carry your team based on your own expertise and experience, you will fail. You need the input of your technical people more than ever before.
You will need your credibility more than ever. You will only earn it by listening to your team, identifying the roadblocks, and helping shift those obstacles out of the way.
You are not going to learn anything while your mouth is running. Shut your mouth and open your ears.
Communication demands two participants. Your job will be to listen. Your staff member’s job will be to present the information in a way that you can understand it.
If you don’t understand, ask clarifying questions. This doesn’t mean that you need to understand every detail of every change request. But you do need to understand some things:
What is the business impact?
What are the risks (in business terms)?
Are we mitigating the risks?
Have the service owners signed off on the risks?
Have we done thorough preparation?
Are the right people involved?
What obstacles stand in the way?
What does your staff need from you?
Teach your team members the skill of communicating technical information to a nontechnical audience. It is sometimes painful for technical people to shift gears and “dumb down” a presentation, but it is a necessary professional skill. Your team members need to understand that developing communication skills will help them to be more effective. Nontechnical people are more likely to give your staff the resources they need if the requirements and consequences of the request are communicated clearly.
There are times when your team will be eager to move ahead with a solution before testing is complete. Since this is not your specialty, you will need to ask probing questions before giving the green light to changes.
This is a balancing act. Your team may view this as “interference” in an area where you don’t know what you are talking about. Be careful about this dynamic, but you need to start as you mean to continue. Emphasize the importance of planning and testing. If you need to trot out some of your war stories to explain why the process is important, do that. But politely and respectfully insist that the process is followed.
You are no longer in the position of being able to accurately characterize the risks of a change. Over time, you will get a feel for who on the team is a cowboy, and whose judgment you can trust on risk estimates. In the beginning, insist on the process. The process is not just your friend. It is theirs too, even if they don’t recognize that yet.
Your team’s ability to work together smoothly will be a major predictor of your success. Do what you can to foster a team spirit. This may mean bringing in bagels and beverages from time to time, or it may involve some team playtime.
When you are developing a team spirit, make sure that you keep the focus on the work the team will be executing. It is nice to have a great group of people who like to paintball together on the weekend, but your job and theirs depends on your ability to deliver as a team.
But the ability for people to relax and let their hair down in a trusting environment can sometimes bring deep issues out for discussion. Project meetings can sometimes be so fraught and tense that people don’t want to be the messenger who speaks to a serious underlying problem. When people are able to relax and trust, they are more willing to discuss issues in a nonjudgmental, casual atmosphere. And a relaxed atmosphere can also help foster the sort of nonlinear thinking that can point the way to a resolution for an intractable problem.
Blame and Responsibility
Because you really don’t quite know what you are talking about, you can be subject to manipulation by team members who are trying to shift the blame for a problem onto someone else.
The best way to avoid falling into this trap is to foster an environment where blame is unimportant. Make sure people are responsible for particular requirements, and that they have agreed to objective criteria for validating those requirements.
But hear out any reservations the person has on accepting responsibility for a particular area. There may be assumptions or interactions that you are not aware of. This is all part of your learning curve as a manager of a new technical area.
You’re a smart person. You have a demonstrated ability to learn technical subjects.
Ask your team members for resources to learn about what they do for a living. They will respect that you are putting in the extra effort to understand what they do.
Don’t assume that you will be able to become an expert in something that other people have spent years learning how to do.
As you learn, you will be better able to represent your team’s concerns to your own peers and management.
Taking Care of Yourself
Work responsibilities can be overwhelming, but you have a responsibility to take care of yourself.
Arranging Time Off
You are responsible for scheduling time off for yourself. In order to take time off, you need to train your team to run without you.
There are sometimes when you need to be present. In particular, high-stress, politically fraught deployments need you to make the decisions you will have to live with. It is not fair to expect your staff to make a decision in a situation like this. Any decision they make might expose them to criticism from two or three levels above themselves in the hierarchy.
During long projects of this sort, you should be able to schedule time around the rhythm of the overall project. Let people know when you will be away, well in advance. Look for decisions that are going to have to be made, and provide guidance (and cover) to your team beforehand. Enable your team to postpone decisions that people bring up while you are away, and make yourself available by cell phone in the event that people start pressuring them.
Learn to Trust Your Staff
A lot of managers get into the rut of having to be present in order for the team to function. Sometimes this is because the manager does not trust them to execute tasks without direct supervision. More frequently, the manager is unwilling to delegate any decision-making authority to the team members.
If you are in this situation, you need to fix it.
It is possible that your staff is unworthy of trust. In that case, you can train them, or you can release them and hire someone else. (It is very expensive to fire and replace someone, and should not be done without serious consideration.)
Is your staff really unworthy of trust? Or are you being a control freak?
The fact is that other people will make decisions different than the ones you would make, or do things differently than you would. That is okay, as long as the decisions and procedures fall within the clearly defined boundaries you set up for your environment.
The key to managing an effective team is leverage. If you have to be personally involved in every decision, you will be a bottleneck, and your team will be ineffective. It would be better to have your team empowered to make some decisions without you, as long as they are good (but maybe not perfect) decisions.
And if they make bad decisions, you can (calmly) use those cases to teach them a better way to do things. Don’t hector them. Don’t nag. Explain how you want things done, and provide clear instructions to your staff so that they can make the decisions you would like them to make.
As you empower your team, you need to set reasonable expectations for yourself, and for them. If you drive your team mercilessly with long, inflexible hours, you will have high turnover and will be less effective in the long run. If you drive yourself mercilessly, you will also be less effective. If you are lying in a hospital bed, your effectiveness is near zero.
Training your team to operate smoothly in your absence and to cover for each other will allow you to all have better balance. Documentation and cross-training are ways to allow everyone on the team to take time off. In a well-documented environment, the on-call person can cover the environment so that people can take time off when they need it.
When you plan schedules, make sure you are making allowances for people to take time off. Part of that may be requesting that your team members get you the information about their expected time off in advance. If they see that it is benefiting them, they will get you the information you need.
Your Physical Health
Take the time and effort to exercise and eat well. Ours is a sedentary profession. You need to make sure you are developing habits that will keep yourself as healthy as possible. This should include at least 30 minutes of exercise every day, as well as making sure your diet is well balanced.
Some suggestions that have worked for some of your fellow technical people include:
Take stairs instead of the elevator
Schedule your exercise for a particular time of day. If your office is in a walking-friendly location, your lunch break may be a great time to get out of your desk chair and outside for a walk.
Schedule a particular time for visiting a gym or other exercise location. If you don’t schedule it, you won’t go.
Use tracking software to track your diet and exercise. There are quite a few free websites that will allow you to track your health information. And there are nifty cell phone apps to track the amount of exercise you get over the course of the day.
Find an exercise buddy who can help keep you motivated on days when you just don’t feel up to it.
Participate in office weight-loss challenges or fitness activities. These can be good team-building activities as well as helping you keep yourself in good shape.
Your mind will only be as good as the engine that fuels it. Make sure to keep your engine in good running order.
If your soul needs feeding, you will not be able to lend strength to your team when they need it.
Just to be clear, I am not recommending that you proselytize for your religion in the workplace. That is probably against company policy and may even be illegal. It is certainly unwise and counterproductive.
If you are a member of a church that feeds your soul, that is great for you. But your staff cannot feel like their boss is pressuring them to adopt his or her particular beliefs. If it comes up in casual conversation, mention where your religious community is, and that you feel at home there. Don’t go any further than that.
For that matter, spirituality may not have much to do with an organized religion. A lot of people feel that their soul is fed by meditation or study or walking on the beach. If organized religion is not your thing, find something that is.
Think about where you want to be in five years. What sorts of experience, education, and expertise do you need to develop to get there? Who can mentor you to get you closer to your goal?
In particular, think about the following things you can do to prepare yourself to go where you want to go:
Formal education. If you never start working on that degree, you are guaranteed never to finish it. Does your employer offer tuition reimbursement? You should be taking advantage of this benefit.
Technical courses and certifications. Is there expertise that you have that is not well-reflected on your resume? If the expertise is important to your career goals, a certification exam can be a good way to bring your expertise out where employers can see it.
Job responsibilities. Work can provide you with a lot of unique experiences. Seek out opportunities to work on project teams where you can learn new, useful skills.
Job titles. Is there a particular title you need to have held as a stepping stone on your development plan? Talk to your boss to see if you can get there internally. If not, you may need to start looking outside your organization.
Personal skills and experiences. Look for volunteer opportunities to pick up skills and experiences that may not be available to you at work.
Discuss your career goals with your manager, and with other people in your industry. They will be able to provide you with pointers and opportunities for development.
Sometimes you have to think outside the box to get the sort of experience you need. Nonprofit organizations frequently need help with technology projects. You can submit proposals to conferences to speak. You can write up and submit magazine and journal articles on subjects that you know well.
As a manager, your focus should be on your team members. Your concern for their welfare is what will keep them motivated and produce value for your organization. Part of that is making sure that you are doing what you need to do for your own well-being. Don’t be the IT Hero. Be a manager. Manage yourself as well as your team.
Responsibility without Authority
In almost any environment, workers will find themselves in situations in which they are expected to produce results, even when not all of the factors are under their control. There are several different types of influence you might be able to exercise to get the job done:
Authority. This is when you have direct hierarchical authority over the other person.
Assignment. This is the extent to which you can affect the other person’s future work assignments.
Budget. The extent to which you can authorize (or get authorization for) discretionary expenditures.
Promotion. The control or input you might have into the other person’s potential promotions in the workplace.
Compensation. Your influence on the other person’s pay or benefits.
Penalty. Your ability to cause the other person to be punished.
Challenging work. Your ability to involve the other person in work perceived to be challenging or interesting.
Expertise. The special expertise that you have that makes you attractive to work with.
Friendship. Personal relations between you and the other person.
When H. J. Thamhain and D. L. Wilemon investigated how effective these different methods were, they found that coercive methods (such as authority, assignment, compensation, or penalty) were much less effective than methods such as providing opportunities to learn through challenging, interesting work with people with a special expertise.
One thing to take away from this is that you don’t need hierarchical authority to get things done. Engage people on a level other than the strictly hierarchical, and you may even get better results.
Reciprocity is the understanding that when you do something for someone else, they “owe” you something of similar value. Usually, this is not stated quite so baldly in day-to-day interactions. (Sometimes it is, as when someone “calls in a favor.”) Most of the time, people like to work in an environment where when they provide a useful service, the other person will eventually feel obligated to provide a service of similar value.
Note 80/20 rule: 80% of the work is done by 20% of the people. A corollary to the 80/20 rule: If you don’t know who the 20% are, you are one of the 80%.
No influencing tactic will work unless the other person feels that they are getting some value from providing the service. It could be something concrete, in the form of an immediate tradeoff. It could be a feeling of worth and accomplishment from contributing to a larger success. Or it could be an obligation that can be called in later. (“I’ll owe you one.”)
When you develop a good working relationship with someone, it is full of little day-to-day reciprocities of different types. Eventually, you develop a trust relationship where you help each other out without even thinking about it or “keeping score,” because you know that the other person is “good for it.”
Everyone Is a Potential Ally
When you run up against someone who is in your way, it is natural to think of that person as an adversary. If you turn it around and think of them as a potential ally, things change.
If you think of someone as an adversary, you lock down and become defensive. Rather than looking for ways to convince the other person to help you, you are more likely to try to use coercive means to get what you want. Over the long haul, coercion does not work.
What Is It That You Want, Anyway?
An important part of getting what you need is to identify what your own needs and wants are. Which of those are actually necessary? And which of them are merely nice-to-haves? What is your bottom line?
Now, think about what the other person needs or wants. If you can provide them something of value, you are part of the way to set up a relationship of reciprocity with them.
In IT, a lot of the things that we need are things that we will need again tomorrow and the day after that. It is in your best interest to find a way to build a reciprocal relationship of trust with the other person.
What Do I Have to Trade?
There are a lot of different types of currencies that you may have access to when trying to build a reciprocal relationship:
Inspiration. Don’t underestimate the power of motivating someone to help you because it is the right thing to do. Explain why it is good for the organization, why it is the right thing to do, or why this task gives them a chance to demonstrate excellence.
Resources. Perhaps your project has budget resources that can be assigned. Or maybe you have access to equipment, expertise, or space that the other person would find useful.
Learning opportunities. Technology people value the chance to learn a new skill above almost everything else.
Faster response. Can you arrange for something to be expedited for the other person?
Information. Can you provide the other person with the needed information?
Recognition. It costs nothing to send an email to the person's boss explaining what an awesome job he or she did.
Visibility. Is this something that management is watching?
Contacts. Can the task lead to valued contacts with other people?
Team membership. Perhaps the task is a way to become part of a successful team.
Relationship. Don’t underestimate the power of personal connections.
Ownership. Can the other person be provided ownership of an important facility?
There also are negative currencies, many of which are withholding something from the above list. Wherever possible, lean to the positive. The value of each of these currencies may be different from person to person. Try to select a currency that works for the person you are dealing with. Just because one particular currency is more valuable to you, that doesn’t mean that the other person feels the same way.
Sometimes the key to getting things done is just not to give up.
Sometimes you will have to retrench or take a different tack to get where you need to go. Stay pleasant. Stay professional. Organize the facts, and make sure that the facts are on your side.
People will rethink their assumptions if you can approach things the right way. Sometimes you are turned down because it is easier to say no. Make it easier to say yes.
You may need to lobby decision makers one-on-one to get forward motion. When you do, present your case in a way that makes it easier for them to agree with you.
Find the places where you agree. This may require some research on your part, but there are interests that the other person has that will be best served by moving forward.
Work past personality conflicts. You may have a personality conflict with the other person, but don’t let it become a contest. Everyone is best served by solving the problem. Make that your focus.
Think about areas where you can be flexible.
Demonstrating flexibility on noncore issues can make it easier for the other person to be flexible where it matters most for you.
Make sure you are talking to the decision maker.
If the other person is just reflecting a decision made by someone else, you need to find a way to speak with the decision maker. Use an appropriate communication style. Different people react differently to different communication styles. This can include things such as the mode of communication (email? phone? personal contact?) as well as the tone and the types and presentation of evidence that will be most convincing.
Which people are effective at implementing changes within the environment? Can you emulate their approach? Or can you lobby some of them to help you?
Work out issues person-to-person. When an issue is getting in the way, it is frequently more effective to negotiate a resolution one-on-one.
Hunt the other person down. If you aren’t getting a response, you may need to stake out someone’s office or look for them in the break room. If it is important, find a way to have the conversation.
Lobby the people around the decision maker. If you can win some of the decision-makers allies to your point of view, it will make a difference.
If success was easy, everyone would be successful. If you want to be known as the manager who gets things done, is tenacious.
When you are younger, it seems self-evident that people higher on the organizational chart have more freedom to make decisions. As you become more experienced, you start to see that everyone is constrained, just in different ways.
Part of being an effective manager is your ability to influence changes in a way that will benefit the overall organization. Sometimes you have a clearer view of the situation than someone higher in the organization, and you need to find a way to make a positive change take place.
Frequently you can make requests at the time that you and your manager set your goals. You can use that opportunity to adjust your boss’s expectations if you can present a better alternative. You can also use that opportunity to explain to your boss what you need to achieve the goals being set for you.
Identify What You Need
Before making a request (especially a controversial request) of management, make sure you understand what you actually need.
Resources. This can be something such as money, staff time, access to an expert, etc.
Authority. Usually, the authorization from upper management to make a key decision.
Influence. This may be a request to weigh in on your behalf on a decision being made by someone else.
Advice or information. Sometimes you need more information to make sure what you are doing is aligned with the organization’s goals.
Try to understand what your core requirements are before you make your request. That way you will have room to negotiate and maybe bring up a new approach to achieve your end goal. Keep in mind that your ultimate goal is to move the organization forward and that what you are requesting is just a means to that end.
Find an Approach
The first step is to identify who has the power to make the decision you need to be made. Then decide what type of approaches might be successful.
What is the decision maker's perspective? Try to think through the priorities and viewpoints that might be relevant to the decision you need to be made.
Are there people that the decision maker trusts and respects? You may be able to ask them for help. This is not deceptive or manipulative. Keep in mind that your motivation is what is best for the organization. The decision-makers allies may be able to provide some insight about how best to pitch your proposal, and what priorities should be emphasized. They also may help you tweak your proposal to make it more likely to succeed.
If the decision maker is a group, tackle the people in that group. Figure out what motivates them and what concerns they are likely to raise. Most concerns and objections to your proposal are entirely predictable; make sure that you have answers that will resonate with the people in the group.
Sometimes you may need to divide your proposal into pieces to make each part more palatable, or to make the parts fit into the organizational structure better. If you do that, make sure the parts will be able to stand on their own as well as part of a larger proposal.
Some common approaches are
Direct approach. Ask the decision maker directly for what you need.
Conversation. If you and someone else are competing for a resource or have incompatible ideas about how to proceed that you can’t resolve, ask the decision maker to meet with the two of you to negotiate a resolution.
Use influence. You can use your influence to have other people express support for your proposal or even propose it directly themselves.
Group meeting. Group meetings can be unpredictable. Try to get a line on the views of the other people in the meeting, including objections they might raise. The better you prepare, the more likely you will be successful.
You might have to mix and match these approaches. And you might be turned down and need to recast your proposal in a way that is more likely to be successful. Frequently a rejection will include information that you were not aware of. Sometimes this information will make you rethink your proposal or come up with a way to deal with the new information.
However, things work out, make sure to ask yourself honestly what your motivations are. As long as you are working for the best interest of the organization, keep looking for a way to help the organization improve.
HOW TO BE A GOOD TEAMMATE
Treat other people right. When people come to you for help with a proposal that has merit, see if you can help them.
Shield your subordinates from unreasonable requests, but make sure that your team is doing everything it can to improve the organization’s position in the competitive landscape.
Encourage your subordinates and peers. Celebrate their accomplishments. Just as you want to be recognized for your good work, make sure to recognize the people around you.
Stay positive. When there are problems, be the person who looks for a solution.
Technical people love to solve puzzles. The world is full of puzzles; enjoy them.
Communicate. Make sure that people around you know what you are doing, and why you are doing it. Make them aware of what you will need from them in advance, and ask them what they will need from you going forward.
You will frequently face situations where you are responsible, but where you do not directly control the resources needed to succeed. Part of being an effective leader is being able to work with other people in the environment to accomplish your goals.