The concept of a Tiger Team is not new. But it might be just the approach you need in order to solve a problem that is severely detrimental to:

• Your customers
• Your ability to deliver services
• Your company’s reputation and wallet

Let’s take a look at how to use tiger teams successfully.

(This article is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

What is a tiger team?

A tiger team is a group of cross-functional experts brought together to solve a specific problem or critical issues.

According to a 1964 definition, a tiger team consists of:

‘A team of undomesticated and uninhibited technical specialists, selected for their experience, energy, and imagination, and assigned to track down relentlessly every possible source of failure in a spacecraft subsystem.’

These teams had been pulled together in military and other settings for many years but came to public attention dramatically in 1970 when NASA brought together a tiger team who were charged with bringing the astronauts aboard the crippled Apollo 13 spacecraft back to earth alive.

Mission Control during final 24 hours of Apollo 13 mission. April 16, 1970 (Source)

How tiger teams work

You don’t have a pre-determined tiger team that you call together every time you have a critical issue you are struggling to solve. The team that solves one issue is very unlikely to be the same team—with the same skillsets—that solves the next issue.

Instead, a tiger team will be handpicked for the situation you are facing at that time. Participants in a tiger team might include any mix of:

• Internal staff
• Vendors
• Subject matter experts who are not connected to your organisation

Tiger teams will be assigned to investigate possible solutions to unique situations or problems. Any team will be populated with mature experts who:

• Appreciate the criticality of the task they are facing
• Understand what needs to be done
• Work well with others
• Demonstrate strengths including a diversity of knowledge, a single focus/purpose, and organizational agility

Crucially, the people in your tiger team must be removed from the grind of business as usual. You cannot afford for them to be distracted by their day jobs. Their full attention needs to be applied to resolving the issue at hand. (This ensures full focus and maximum efficiency, saving time and money in the long run.)

Once the tiger team completes the assigned task—solving the issue—the team will be disbanded. Its members will go back to their normal roles.

(Explore IT teams you might draw upon for your tiger team.)

Considerations for building a tiger team

It is possible that one tiger team may not be enough. Highly complex problems may require more than one team to resolve.

Using the principles of best practice in problem management, each team should only be looking at one problem—a single object and a single fault. If you discover during your investigations that you are looking at multiple contributing issues, then either:

• Split your tiger team
• Build a new one to investigate each separate cause

(Look at reactive & proactive problem management.)

It is essential that a tiger team can concentrate on their specialist area and not be distracted by other, potentially conflicting, issues.

You must clearly define the result you expect your tiger team to deliver, defining and understanding what “done” looks like. (Remember, done is a relative term.) Tiger teams are expensive resources, so you don’t want them to be wasting time on non-critical issues. Make sure reach tiger teammate understands the boundaries of the problem you are asking them to solve.

At the onset, clearly state the expectations, rules of engagement, and team and project boundaries. If you do not, you may encounter several risks:

• Team members understood the issue differently. This murkiness will hinder any issue resolution before it gets underway.
• The team may start applying short-term fixes, and sometimes multiple fixes at the same time. A common refrain is “Just a second…try it now.” The danger here is that you no longer understand your starting point—the true problem you’re trying to solve, not work around.
• The team gets confused. Every time the team meets, they look at a different symptom, with no strategic direction.
• Lack of resolution. Once the initial emergency is over, people stop attending meetings and the team isn’t always sure what fixed the issue
• The team skips final determinations and lessons learned. The risk here is that if you don’t allow time to document lessons learned or understand the root cause, the issue might not be as resolved as you think it is.
• Scope creep. Scope creep is a real danger. When discussion wanders to other topics, beyond the team’s original purpose, the tiger team will fail to be productive.

(Discover the #1 success factor in any lessons learned or portmortem report.)

Tiger team best practices

Of course, tiger teams aren’t only about defining the boundaries to solve the problem—they require logistics and management.

Some housekeeping tasks that need to be considered when assembling your team:

• Isolate the team in a dedicated space. War rooms are specific spaces for dedicated events and problem-solving (not routine meetings), and it might be just what you need for a tiger team. Of course, make sure everyone in the team has the appropriate access to your war room.
• Cancel all other work obligations. Block off all team members’ calendars with individual all-day appointments so no other meetings sneak in.
• Ensure sufficient wall space for collaboration.
• Allow for breakout spaces for small groups to work together.
• Arrange catering. Keeping your team together during breaks increases collaboration time.
• Locate and have access to all technology requirements, like test environments, additional hardware, smart screens, etc.
• Communicate clearly and with the entire team. Create a team on your messaging app (Teams, Slack, etc.) and add everyone to it. Create an email distribution list, a Jira or Trello board or similar, and a shared documents folder.

When to form a tiger team

One thing that I would urge is to create a tiger team sooner rather than later. Weigh up the cost vs. benefit equation.

How much is the issue you are dealing with costing the business each day—not just financially, but reputationally as well? If you are getting close to the promised resolution time and are not well on the way to restoring service, it is time to get the experts to work.

Of course, not every incident or issue should have a tiger team. But certainly some will require it.

I have worked in an organization that refused to form a dedicated team to work on a major issue…until the pain experienced by the organization and its customers had reached the top levels of management. By that time, so many attempts to fix the issue had been made, further complicating the situation, that it took weeks of concentrated, and very expensive, effort to restore full service.

The entire time this was happening, the organization’s reputation was suffering, and we were being featured regularly in the media as a result. If a tiger team had come together as soon as it was obvious that we didn’t understand the root cause, the path to resolution would have been much easier and faster.

Bringing top internal and external experts together to resolve a difficult issue is not a cheap option. It’s certainly not one that needs to happen for every situation that is proving difficult to resolve.

But, if your organizational reputation is being damaged, or the viability of the business is threatened, do not hold back. The cost, while often high, will be justified.

Related reading

• BMC Service Management Blog
• Incident Management vs Problem Management: Differences Explained
• The Incident Commander (IC) Role Explained
• Roles & Responsibilities in Change Management
• What Is an IT Steering Committee?
• How Service, Business Relationship & Product Management Work Together

Transformational Leadership is a concept for leaders to transform the workplace by inspiring team members to create change. Transformational leadership comes naturally to very few people—which means you can learn to become a transformational leader.

Let’s take a look at transformational leadership and how it works within the enterprise.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

What is Transformational Leadership?

Transformational leadership is a style of leadership in which leaders encourage, inspire, and motivate employees to create change that overall helps to grow and shape the future success of a company. The executive level sets examples that contribute to three enterprise characteristics:

• Influential company culture
• Employee ownership
• An independent workplace without a level of micromanagement

Transformational Leaders lead with a level of trust to create a healthy work environment. This style trains staff members to take authority over decisions within their assigned jobs. This leadership style allows employees to:

• Be more creative
• Plan for future success
• Discover new solutions for problems that arise within their duties

Though Transformational Leadership might begin with the leader directly, it does not end there. Employees trained within this leadership style are also preparing to become transformational leaders themselves through company mentorship and training.

Thanks to its very nature—developing and delivering a team vision to change the culture of the company for the better—transformational leadership can be used especially in:

• Change Management
• Strategic Planning

A brief history of Transformational Leadership

Transformational leadership was first conceptualized by James V. Downton, an American sociologist, in 1973. However, the leadership style was not fully developed until 1978, when American historian and political scientist James MacGregor Burns wrote Leadership. Burns studied various political leaders, including both Franklin D. Roosevelt and John F Kennedy. During this time, he developed his theory of Transformational Leadership.

This leadership concept was expanded further during the 1980s by Bernard M. Bass, an American scholar in leadership studies and organizational behavior. Bass noted that the transformational leadership model inspired followers to:

• Reach a higher level on the consciousness towards the company’s goals
• Rise above their self-interest for the organization
• Approach a higher level of needs

Transformational leadership is also associated with the Servant Leadership philosophy notably embraced by Mahatma Gandhi, Nelson Mandela, and other historical figures.

The 4 I’s of Transformational Leadership

Bass suggests that transformational leadership involves four different elements, known today as the 4 I’s. These factors are crucial for any leader who wants to inspire, nurture, and develop their employees.

Let’s take a look at each factor.

Idealized Influence

Character: Promoting trust to earn respect

Idealized influence refers to how Transformational Leaders exert their weight within a group. A transformational leader must serve as a role model for their followers. Instilling trust and respect of the leader evokes the followers to emulate this individual and internalize the leader’s ideals.

Their team exceptionally respects these leaders because of the example they set forth for others. This type of leader also provides a clear vision and a sense of belonging, which encourages individuals to follow long-term objectives and drives them to achieve their own goals within the organization.

This leader is a powerful role model, and based on the example set, their team of followers will imitate this leader an aspire to become the leader.

Intellectual Stimulation

Character: Challenging the status quo

Intellectual stimulation means creating a diverse and open environment within the Transformation Leader’s organization. The setting is a space open to innovation and forming new ideas both for the company and for themselves.

The Transformational Leadership style challenges the status quo, encouraging team members to think outside of the box to reach their creative potential. This type of lead galvanizes their team to explore new ways of doing things and seek new opportunities to learn and grow within the organization.

This leadership style can play an influential role by openly pushing their followers to challenge their own beliefs and values (as well as those of the company) to stray from the norm.

Inspirational Motivation

Character: Encouraging, motivating, and inspiring others

Performance is a vital component of the Transformation Leadership style. A Transformational Leader must be able to motivate and inspire their team. This leadership plays the role of improving performance by encouraging their team’s morale through motivational techniques and presenting themselves as inspirational forces that drive their organization’s team members.

A Transformational Lead is a positive communicator of their high expectations to individual followers and encourages them on a solo level to gain their trust and commitment to the shared vision of the company’s goals and beliefs.

Instilling a clear vision that the Transformational Leader can voice to their team allows the leader to foster passion and motivation to meet their team member’s individual and the company’s goals.

Individualized Consideration

Character: Communicating openly to support all team members

Together with fostering an open environment, a Transformational Leader is actively seeking to create a diverse and supportive space. In this workspace, all individuals and their differences are respected and celebrated.

A leader of the Transformational leadership style offers support and encouragement to their team. Creating this growing supportive relationship involves a leader that keeps an open line of communication so that:

• Team members feel comfortable sharing ideas.
• Leaders can offer direct recognition of team member contributions.

Open communication allows for the lead to act as a mentor and coach for the team members continuing to work towards developing, empowering, and inspiring their team to achieve more.

This leader is always happy to listen to other’s concerns or needs of their team. Individual consideration is key to creating future leaders.

Benefits of Transformational Leadership

Both the leaders and the team members of Transformational Leadership experience many positive outcomes, including:

• Self-motivation
• Active engagement
• Higher productivity
• Personal and professional satisfaction
• Positive attitude
• Lower stress

How to become a Transformational Leader

Becoming a Transformational Leader is something you work at; it’s not something you either have—or don’t. Transformational Leaders actively embrace and commit to the 4 I’s to become a Transformational Leader.

To move towards Transformational Leadership, start by assessing your current leadership style. Consider how your strengths can benefit the team you are leading. Acknowledge your weaknesses and gaps and consider ways that you can overcome or limit these.

Some steps to developing your leadership style include:

• Understanding your own strengths and weaknesses
• Developing an inspiring vision for the future
• Motivating everyone around you
• Involving yourself in the Transformational Leadership concept
• Building trust and loyalty with your team members

Developing these tools of transformational leadership and working to improve you and your team’s areas of weakness to reach your overall goals can put you on a path to becoming a transformational leader.

Transformational leadership for the enterprise

The transformational leadership style can be hugely affected when used appropriately in a company or organization setting.

Every working environment is different. In some cases, a team or certain individuals may require a leadership style with more management that involves a closer eye and more significant direction, especially in a situation where team members may be less skilled or newer to the company.

Additional resources

For more on business leadership, explore these resources:

• BMC Business of IT Blog
• Guide to IT Leadership & Best Practices, with 10+ articles
• Guide to IT Careers
• What Is a Chief Service Officer (CSO)?
• CIO Leadership Styles
• Must-Read Emotional Intelligence Books for CIOs and IT Leaders

The role of a Chief Information Officer (CIO) was once understood to be that of an executive focused mainly on IT. Now that technology is an essential component for companies both great and small, the role has been evolving. All organizations rely on IT, whether they are multi-national conglomerates, small family businesses, or municipal holdings such as schools or libraries. Technology is integral to maintaining daily operations; it is no longer a niche contained within tech start-ups or software companies.

In the current climate, CIOs are not only tasked with leading technological initiatives, but are integral, valuable participants at the top of the organizational ladder. In addition to being knowledgeable and strategic in the tech space, it is vital for a CIO be a proficient businessperson. Successful CIOs must balance the goals and objectives of an organization while also making sure their teams remain supported, motivated, happy, and successful. CIOs are called upon to be decision makers, leaders, and anticipators.

Not to be confused with the Chief Technology Officer (CTO), the CIO’s focus is on streamlining operations: increasing efficiency, productivity, and adapting to changes as they come. You’ll need to be aware of needs and pain points and able to direct your teams to anticipate and react to those needs. As CIO, you’re an invaluable member of the C-suite, as you’re as a cross-functional leader and conduit between departments.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

1. Be an Effective Communicator

Communication skills are vital for any manager, but this is especially true for the CIO. This role is simultaneously responsible for leading their own teams as well as facilitating dialogue between multiple parties across the organization.

As a CIO, you must be able to effectively exchange information with those who report to you. This includes:

• Clearly and succinctly explaining the scope of a project
• Outlining business goals and objectives
• Adequately handling miscommunications

A CIO must be comfortable tackling difficult or sensitive topics as they come up; avoiding these conversations does a disservice to the whole team.

A leader who remains approachable will experience a more robust and, ultimately, successful relationship with their team, which will also keep them informed on what’s going on in those departments. Transparency between the CIO and the rest of the team makes it much easier to communicate with other departments in the organization.

Another vital component of the CIO’s skill set is the ability to convey how the work of their team connects to the overall needs of the business. The CIO acts as the conduit between the executives in the C-suite and their team members on the frontlines. It is the CIO’s responsibility to take the interests of various stakeholders into consideration and make sure all parties feel heard.

2. Be a Champion of Creativity and Innovation

It is no secret that technology evolves daily. CIOs need not only anticipate advances in technology, but stay flexible and ready to respond to new developments at a moment’s notice. The willingness to take risks and embrace new ideas is imperative for the health of the entire organization, and a leader who embodies these qualities will inspire team members to do the same.

As CIO, it is vital that you promote a culture of innovation from day one. Furthermore, you need both to manage the response to external change and to lead it by being the catalysts for change yourself. This sort of forward thinking prevents stagnation and, worse, being outpaced by competitors.

Now, more than ever, it is crucial that a CIO be a disrupter. You need to be ahead of the game and versatile in the face of unexpected adjustments. Simultaneously, a CIO should be supporting current and future business demands. You cannot be risk-averse, as embracing risk is the way to true innovation.

3. Be Emotionally Intelligent

Once considered a soft skill, emotional intelligence is front and center in discussions regarding competent managers. It is very difficult to manage a team if one is unable to recognize and, ultimately, appreciate the differences between staff members. A true leader understands that each colleague has unique strengths and areas for improvement, and is able to use these to the team’s advantage.

Emotional intelligence is a much more important component in a CIO’s toolbox today than it was even a decade ago. Whereas CIOs of the past favored a “command and control” leadership style, these days “guide and support” is proving to be more successful, especially when it comes to fostering inspiration and innovation. It is imperative for executives to be self-aware while also understanding their people and how to respond to their needs. A good CIO provides direction while empowering others.

Instead of micromanaging or trying to control every aspect of operations, the best CIOs trust their teams, acknowledging that since they deal with changes and updates in real time, they may have more intimate knowledge of the inner workings of each system. In this role, it is just as important to display cultural competence as it is competence in technology or business.

4. Be a Data Strategist

Data can be a powerful tool in informing best practices and business operations. A CIO needs to understand each step in the data collection process so they can better lead their team and make sure the right people are collecting and synthesizing the data. If a CIO provides this crucial support to data scientists, data from all facets of the organization can be utilized to inform decisions and inspire growth.

While it is important for CIOs to be willing to meet risks head-on, they need to be able to utilize data to calculate exactly how risky a move will be. Data does nothing as an entity on its own, it needs people trained to appropriately analyze it and draw the proper conclusions, turning those findings into something actionable and informative. A CIO needs to understand both where data comes from and how to use it.

No longer solely relegated to the tech space, today’s CIOs must wear multiple hats. In addition to managing and optimizing IT teams, a successful CIO must maintain a head for business, improving the customer experience by streamlining operations and staying on top of new technological developments. Furthermore, they must be consistent and transparent communicators, appreciating the nuances of their teams while clearly and succinctly transmitting information to and from the rest of the organization. The CIO must both anticipate and encourage change, propelling their organization forward.

Stuff happens! Our IT systems are incredibly complex. Inevitably, things will break and customers will experience the consequences of these failures. You will feel stressed, angry, frustrated, and pressured to get it fixed ASAP. Once you have the problem fixed and major systems restored, you probably want to forget the whole thing ever happened. Don’t.

When we have experienced a major loss or degradation of our IT services, it is essential that we learn from what happened. A learning approach ensures either that the incident doesn’t happen again, or that we can remedy the situation more expediently than the first time around.

Of course, our learning is no use if we can’t remember what we learned. Thanks to how our brains work, we tend to forget the specific highs and lows of a project, especially when trying to recall them months or years later. And that’s why we must document our lessons learned—in a document often known as a postmortem.

Major incident reviews, or incident postmortems, form an important part of any continual improvement program. These reviews are opportunities to improve both our IT infrastructure and, possibly more importantly, our processes for dealing with these events. A mature organization will see these events as valuable learning opportunities, rather than apportioning blame for errors.

Let’s explore incident postmortems, including the #1 factor for their success. Then, we’ll cover the benefits, rules, and best practices for creating your incident reviews.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

What is a postmortem?

Performing a postmortem may sound a bit dark and depressing—it literally translates to “after death”—but it’s actually meant to shed light on a significant problem. A postmortem process comes at the end of a project and helps you both determine and analyze successes, non-successes, and failures. The outcome of this process is a document or report that aims to inform best practices and mitigate risks in the future.

Postmortems, or lessons learned reports, can be performed after anything:

• The completion of a project
• The end of an event
• The close of a sales season
• The end of a sprint

In IT, most postmortems tackle incidents: a severe problem, downtime, or outage that has an immediate impact on users. The postmortem should document detailed information regarding every aspect of the incident: from the root cause to the successful resolution, and all the lessons you might glean from the whole thing.

Postmortems that fail

Perhaps you’ve been involved in an incident postmortem, but decided to scrap it for more “important” work. Maybe you filed the report but, now that it’s hidden away, the recommendations therein haven’t been adopted.

These are the two biggest problems with creating IT postmortems: people dismiss them as non-essential, so the reports aren’t always read, let alone adopted, by the people who can affect change. Because of this, many people immediately see postmortems as an unworthy investment of time and resources.

A few reasons point to why we might dismiss documenting these lessons learned:

• We think our memory is better than it really is, that we’ll remember what happened and change your actions accordingly.
• It feels like a blame game: determining who did something incorrectly at a moment of significance. Better to avoid that game altogether.

For a postmortem to be useful, it must provide specific recommendations for changes, such as policy or processes. If it’s just documenting for documenting sake, it’s a waste of everyone’s time.

#1 factor for incident postmortems to succeed

In my opinion, the most critical success factor for incident reviews is that they are blameless.

To use a popular phrase: do not make your incident postmortem a witch hunt. ‘Blamestorming’ sessions do not benefit anyone. If your company culture seeks out the person who may have caused, through error or omission, a major outage, it is extremely unlikely that you will get truthful answers during the review. (Besides, most incidents are more nuanced than one person failing at their duties.) In this culture, no smart person would be willing to raise their hand and admit a mistake. When that happens, your postmortem has failed before its begun.

Consider a company culture that rewards honesty rather than demonizing mistakes. People will put up their hand willingly to flag an error they may have made. Then, real and useful changes can be made to prevent it being made again in the future.

Benefits of incident reviews

A successful postmortem goes well beyond reviewing how you handled its resolution—the best ones indicate unknown system problems and highlight areas you can improve or automate to reduce risk. A well-run postmortem allows your team to come together in a less stressful environment to achieve several goals:

• Work through what happened
• Discover previously unknown system vulnerabilities
• Mitigate the possibility of repeat incidents
• Uncover any potential process improvements that could speed up resolution of the next major incident

Of course, incident reviews aren’t just for internal stakeholders. Ultimately, your incident reviews show your customers two important characteristics about your company, which provides invaluable benefits:

• Your willingness to learn from mistakes. Reporting the findings of your review back to your key customers, owning any errors or omissions and giving them a roadmap showing what you are doing to improve the reliability of your services will build your reputation as a valued business partner.
• Your ability to create new processes that ensure your customers aren’t impacted by the same issue again. Showing that you understand and take seriously the impact of IT outages on the wider business is essential to growing a relationship based on mutual respect.

How to conduct incident postmortems

Like many things in IT, incident postmortems run much more smoothly (and take significantly less time) if you have a process and some basic rules in place. So, let’s set a few:

1. Have a template. Create a template that you will work off for each review. This ensures you don’t miss anything. A template also provides the basis for the reporting, that goes to your management team, and the communications that goes out to affected customers and stakeholders.
2. Define roles and owners. The owner of the review is responsible for managing the meeting and producing the subsequent report. The owner(s) should be someone who has sufficient understanding of the technical details, familiarity with the incident, and an understanding of the business impact.
3. Set rules around which incidents need reviews. You must have clear, well defined rules about which incidents will trigger the postmortem process. A good rule of thumb is any incident that has been given a severity one rating. There may be other incidents where a review may be useful. Consider establishing a process whereby service owners can request reviews of incidents that do not meet the severity criteria but that may have severely impacted their services and customers
4. Act timely. A critical incident will almost always require some downtime for your team; do not delay any longer than necessary. Procrastinating too long means that important details are forgotten. So, when a critical incident occurs, convene within 24-48 hours, and certainly do not delay more than a week.

Create a postmortem template

The responsibility to research, write, and publish a postmortem report lies with the project manager or the person most responsible for a particular outage or data loss. (By responsible for, we mean the person who immediately begins fixing it, not the person who caused it—as many times, these outages occur without human interference.)

An IT postmortem report need not be complicated. In fact, its simplicity encourages us to complete them and others to actually read them. Include specific information that focuses on the key factors of the incident without bogging the reader down with unnecessary details. Here are the core components of a successful post-mortem report:

Summary

First, create a brief summary of the incident. This part of the document should be short, just 1-2 sentences that answers the question “What happened?” This lets readers determine if this report applies to them. Also include details like a relevant, easy to understand title; authors and date; most recent status.

Background

Next, include any supporting information that’s necessary for understanding the incident should be provided immediately after the brief summary. This information offers supplementary (but still concise!) details to help the reader understand the context of the incident.

Incident

Now you’re into the body of the postmortem report. Include a description of the events that’s detailed enough so that someone who wasn’t involved in the incident can understand what occurred. Use timestamps to provide insight into how and when everything unfolded. Use these questions to guide your writing:

• What was the problem?
  • How incident was detected
  • Size and time of event
  • Software used
  • Impact
• Why it happened? How was it resolved?
  • Identify major events
  • Isolate root causes, if possible
  • Look at technical pieces: Were design, process, poor maintenance the underlying cause that lead to a technical failure?
  • Looking at non-technical pieces: How did organization, management, and team environment improve or detract from the problem and its resolution?
  • What about the effect of things like culture, time crunches, and budget pressures?
  • Include who worked on the incident
• How did the team respond?

Detail any decisions that were made and the steps that were tried, both successfully and unsuccessful, towards incident resolution—and timestamp these, too. This is important for informing the resolution of future similar incidents as well as tracking important metrics like response times and service outage times.

Timeline

This section should provide readers with a bullet point-style reference for every event and action during the incident and its resolution. A simple graphic and short descriptions is plenty. If your timeline is too long, move it to the end of your report so it doesn’t bog down the reader.

Takeaways

This section can be broken into three parts:

• What went well. Detail where your systems or actors performed well and helped to reduce the impact of the incident. Don’t be modest! It’s important to understand what systems and decisions had a positive effect.
• What went poorly. Admit where systems broke down or decisions were wrong. Discovering areas for improvement is essential for ensuring that future incidents can be mitigated or avoided better in the future.
• What to do in the future. Analyze the incident details and outline your learnings from the experience. Then—and this is essential—make recommendations for changes that should be made, both in the short- and longer-term. Acknowledging your learnings without suggesting change is a failed opportunity.

Best practices for incident reviews

Even with rules in place, an incident postmortem can go all over the place. Consider these best practices as you embark on your next incident review, and then revisit them with each postmortem iteration.

Conduct a review for every incident classified as ‘major’. Every major incident! Even if it’s too hard. Even if you already know the root cause or you’ve developed a permanent fix. Don’t skip any major incident review. Remember that not everyone is aware of the final resolution or the steps that were taken. The review is as much about reviewing how well your process performs as it is about finding the technical or true root cause.

Do it right away! The time for a postmortem is immediately after you’ve wrapped the project or as soon after the triggering incident as possible, especially if it had an immediate impact on users, such as an outage, downtime, or data loss. The postmortem process should be built into your scheduling. If not, you lose precious recall around exactly what happened and how good or bad something was. We tend to remember really bad things, gloss over other things, and forget our successes

Choose a moderator. Ensure that one person controls the room, so that it stays on track and doesn’t become a “blamestorming” session. Typically, the moderator is the owner of the incident review, whom you’ve already designated. If not, perhaps rely on a person who can command a room. The moderator is responsible for maintaining order and giving every participant the chance to speak.

Involve many people. Most major incidents involve many players from internal and vendor teams. The review gives everyone a chance to contribute their views and learn from the experience. Beyond this specific incident, being inclusive helps build trust and resiliency in the team, creating relationships that will help the next major incident war room run more smoothly.

Lay the ground rules at the start of your meeting. No finger pointing, no dismissing anyone’s ideas. Treat everyone with respect.

Single out no one. Successful postmortems are blameless postmortems. Do not single out any individuals as being responsible for the incident: it’s negative and it wastes time. Instead, you must concentrate on actions, results, and impact.

Use “The 5 Whys” technique. I like this technique and promote it often. First, make sure everyone is on the same page about the original problem and its details. Then, ask why that happened. As you get that answer, ask why again. Keep asking “Why?” at least five times. This ensures you uncover all the underlying factors that contributed to the incident. The information obtained from this exercise will also form the basis for the ongoing problem investigation.

Don’t let participants shy away from uncomfortable truths. In group settings, it’s easy for participants to choose the truth of least resistant, or come to an easy or convenient consensus on cause. The owner/moderator should prevent this from happening.

Do not skimp on time. Your incident review is all about detail—things that did not seem important during the heat of the incident may provide valuable insights that could help with understanding the root cause. Give everyone a chance to contribute, and consider each and every one of those contributions, no matter how far-fetched they may seem.

Use a tried and true template. You’re not writing award-winning stuff here, it’s the recommendations that matter. A good template means you don’t have to worry about how well you write—and that you don’t waste hours or days on the effort. (A quick online search turns up dozens of templates; experiment to find what works best for your team.)

Track positives and negatives. Not all postmortems have to be gloom and doom – some can highlight positives in a process that you may not have been aware of. In that case, perhaps your recommendation is to rollout these positives more widely.

Publish the report. Postmortems don’t have to lurk in a basement storage area, among old files. In fact, you don’t even have to print it out – simply share the findings with the team, the department, or the company and decision makers as whole, whatever makes sense for your work environment. A bonus: publishing will help you keep things short and concise, too!

Review your postmortems. The last thing I will leave you with: reviewing your incident reviews encourages you to do better next time, and there will be a next time. For continual improvement, everything we do contributes.

Good incident management reinforces problem management

The outcome of (and attitude around) IT postmortems won’t improve if you continue to minimize the importance of IT postmortems. Next time you create a postmortem, consider following a reliable template and commit to implementing the changes.

Of course, postmortems should be seen for all their positives: finding good processes that can apply to other teams and functions, improving processes iteratively so it’s easier to implement and maintain, and supporting problem management.

Additional resources

For more on incident management, see the BMC Service Management Blog, or check out these articles:

• Incident Management vs Problem Management for 2020
• Incident Management: A Beginner’s Guide
• Incident Management in ITIL 4
• How To Map the Incident Management Process
• 5 Ways to Improve Incident Management with Decision Support
• How and Why to Run Incident Drills

Successful mentoring relationships can be a boon in both personal and professional life. You may have been mentored by a teacher at school who helped you understand different careers, or a sports coach who assisted you in building your teamwork skills, or even a colleague/manager at work who helped you identify your true areas of interest. These fundamental relationships helped determine or refine your passions and strengths.

While the purpose of mentoring may seem like a simple concept, it is surprising to know how beneficial mentoring relationships can be, especially in the workplace.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

Why Workplace Mentoring?

According to Forbes,

• Almost all Fortune 500^® companies engage in active mentoring
• In fact, companies with under 5,000 employees have recorded a 200%-300% increase in interest in mentorship
• In 2019 and forward, mentoring-led approaches by leadership are perceived as smart investments

In the workplace, mentoring is an effective way to help people identify their true interests, practice time-management, and/or facilitate progression on their chosen career path. Moreover, strategically developing an individual’s talent not only contributes to the company’s growth and innovation, but also lets him/her succeed in their career and life goals.

In my opinion, mentoring adds value, irrespective of where you are in your career. We can all use help and guidance from those we trust. In fact, the mentoring cycle comes full circle when your mentees start passing on the lessons learned to their mentees.

How Does It Work?

Many young, up-and-coming leaders desire mentorship in the workplace. When you talk to great leaders and thriving individuals, you learn that behind their journey towards their goals, stands a mentor (or maybe a few) who helped them get there. If you’re lucky, you will find mentors who may last throughout your career. An effective mentor encourages the mentee to venture down a path that was otherwise closed or unknown, and achieve something they thought was unachievable, or never really thought about. Mentors inculcate habits or good practices that many-a-times stick with the mentee for the rest of his/her career.

In turn, learning to serve as a mentor is a personal and professional development experience, challenging you to reflect on your own actions and shortcomings over time.

Moreover, the mentors must share sincere, constructive feedback that outlines the benefit/outcomes and ensure the feedback is shaped in a way that suits the individual (for example, celebrate wins, correct quietly, etc.). Mentors need to keep in mind that whenever something goes wrong, they must encourage the mentee to analyze and fix it and learn from the experience. While such situations may lead to difficult conversations, these are imperative to the learning process.

As a mentor, I remember once one of my mentees and I spoke about the next steps in his career. A few weeks later, this person called me to let me know he was leaving the company, and why. He had quickly acted upon our conversation and made a move that was right for him. While he left my team and I was disappointed to lose a top performer, the role he selected has paid huge dividends for him professionally and filled multiple skill gaps. We continue to talk frequently and provide each other advice.

In another scenario, an individual and I spoke regularly and he shared that he was tired of doing the same job and felt bored in his role. We discussed his true passion and the type of work he wanted to do. While it took time and we had multiple conversations, he eventually found the right role and today, has taken on significantly more responsibility. Sometimes your role as a mentor is just to listen and let your mentee work through the process on their own. In this case, patience won over making a short-term decision simply to change roles.

As a mentee myself, I have been lucky to have multiple mentors in my career, who have helped me identify my strengths and weaknesses. Each has provided me with sage advice that has impacted me both professionally and personally. Each of my mentors has challenged me to step outside of my comfort zone and take calculated risks. Without their guidance, I would not have achieved what I have, nor been able to serve as a mentor to others.

But Does Mentoring Really Matter That Much?

Mentors can help mentees learn the culture of the company and develop relationships across the group. For new employees, these difference-makers can prove to be a crucial resource during their learning curve. Given that mentors have the experience and battle-scars young employees have not yet cultivated, they can very well come up with concrete strategies and decision logic to educate and enrich others.

Mentoring significantly improves employee retention as mentees feel more engaged, leading to a happier and more committed workforce. Most importantly, it helps the company identify future leaders at an early stage.

Once you have cultivated your employees into key, confident, sought-after team players, it is easier to transition them in larger, more strategic positions.

When an employee feels like they have had time invested in them, they will be more likely to invest their time back in the company. The more engagement and investment employees have in a company, the more likely it is that they will stay with the company longer.

Relationship building requires time, but mentor/mentee interactions are some of the best times at the workplace and often the highlight of your day—or career!

Read this another interesting post from Mike – ‘The Center of Excellence: Necessity or Fad?’, to understand how many organizations are establishing corporate Centers of Excellence (CoE) to provide best practices and drive innovation.’

If strong leadership is based on open and frequent communication, one-on-one meetings can be one of the most powerful tools managers have. Unfortunately, many leaders don’t correctly utilize one-on-one meetings, often known as 1:1s, wasting valuable potential to connect individually with direct reports. Frequent cancellations, lack of structure, and a focus solely on status updates are common mistakes that managers make during 1:1 meetings. If you’re not getting value and action from your 1:1 meetings (you’ll know if you aren’t), the difference is usually in your fundamentals.

One-on-one meetings do require a bit of preparation, but once you and your employees understand the structure and the expectations, just a few minutes of prep is all you’ll need to make these meetings valuable. In this article, we will:

• Define the purpose of 1:1 meetings
• Share the benefits
• Provide simple best practices
• Include additional resources to streamline your changes

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

The basics of a one-on-one meeting

A one-on-one meeting is a private conversation between an employee and their manager or team lead. The meeting should take place regularly, typically weekly or biweekly—schedule them in advance and on a recurring basis. In a traditional office setting, 1:1 meetings should occur face-to-face, in an office or small conference room that affords privacy. In more open office settings, you can meet on a set of couches, but make sure it’s far enough away from your team or other employees that eavesdropping isn’t easy. If your employees are remote, set up phone calls or video chats.

So, what’s the purpose of a 1:1 meeting? One-on-ones are crucial in all companies as they are designed to check-in with employees about day-to-day basics, responsibilities, questions, long-term goals, and general job satisfaction. (That might sound like a lot, but we’ll help make it easy.) The 1:1 is the best way for managers and those who report to them to develop a strong relationship, connect on pressing issues, and ensure that employees feel like they’re working toward their goals.

These are not the same as evaluations, which are more structured and provide a formal performance assessment.

Benefits of 1:1 meetings

Managers and employees alike may dread 1:1 meetings. Employees may be annoyed that the manager is ill-prepared or cancelled the meeting several times, or they may fear the manager will be overly critical. Managers may feel awkward, unsure of what to talk about or how to “check in” without micromanaging. But the positives of one-on-one meetings far outweigh these feelings. Once you establish a routine and structure for your 1:1s, both parties can feel satisfied and valued.

Common benefits of 1:1 meetings include:

• Better employee engagement. The manager shows that each employee is worth some of the manager’s time; in return, employees will come to meetings better prepared.
• Increased productivity. Talking about challenges, upcoming projects, or long-term goals can help refocus each employee.
• Reduced turnover. When employees know they have a safe space to ask questions and seek feedback, they can be more satisfied with their job, reducing their likelihood of leaving the company.
• Proactive problem management. Direct reports will feel more comfortable asking questions or sharing their challenges, and the manager can offer regular feedback on projects. This helps catch small issues, whether work or personnel related, before they snowball into large problems.
• Real-time, two-way feedback. One-on-one meetings should be more conversational, less dictatorial. Managers can give quick feedback and celebrate employee wins, and the employee should feel comfortable to do the same.
• Improved performance. This is a culmination of all the other benefits: both employees and managers will work more productively and successfully—which results in improved performance evaluations for both of you.

Best practices for 1:1 meetings

A variety of best practices and leadership tactics can improve your 1:1 meetings. Let’s start with the fundamentals—master these practices and your 1:1 meetings will benefit both you as the manager and your direct reports.

Stay consistent

Successful 1:1 meetings are consistent ones. Meetings should have a regular cadence, whether weekly or biweekly, and be treated with top priority. Canceling 1:1 meetings should only occur in pressing circumstances; frequent cancellations or rescheduling result in employees feeling unworthy of their manager’s time. This consistency applies to the meeting structure, too, so both you and your employee know what to expect from week to week. This consistency is particularly vital when your workers are remote.

Prepare

A prepared agenda is crucial for efficient, successful meetings. Both you and your direct reports should come prepared to share status, ask and answer questions, etc. You certainly can share your agenda ahead of time, though simply bringing it to the meeting is useful, too. The better prepared you are as manager, the better prepared your employees will learn to be. Eventually, your employees may start dictating the meeting’s agenda.

Maintain privacy

Although 1:1s won’t always involve confidential information, ensuring privacy lets employees get comfortable and build trust. That privacy is essential when it’s time to talk about feedback or long-term career moves. Seek a private office or conference space for face-to-face meetings and close the door to your home office when meeting remotely.

Minimize distractions

Conducting your meeting in privacy and with minimal to no distractions shows that you value what your employees have to say—that nothing is more important.

• For in-person meetings, turn off your computer and phone to avoid notifications, and use pen and paper to keep any notes.
• For remote/virtual 1:1s, use a quiet place with stable internet access, limiting noise (like coffee shops) and wearing headsets if that improves the connection. Use pen and paper to keep notes to avoid interruptions.

Have a conversation

Unlike a team or department meeting where one person is conveying information to a group of workers, a 1:1 is a conversation. Though you’re the manager, you should not talk the entire time. Do equal parts talking and listening, and let the employee steer the conversation. Some weeks, your employee may talk more than you do—and that’s good!

Take notes

The act of taking notes is vital to 1:1 meetings, signaling that you’re serious, you’re listening, and you’ll follow up. Try using pen and paper for your note taking. Studies show that taking notes more slowly is precisely what makes them useful. If you do need your laptop or device, use it solely for notes.

Create tasks & follow up

End each 1:1 meeting with five minutes dedicated to creating an action plan. Realistically, both the manager and the employee will have tasks—following up with colleagues, clients, or each other; tracking down an answer to a question; trying a new sales or work technique. When creating your action plan, agree to a timeline for each task. You may be able to handle for the next 1:1, though some may take only a day and others a week or longer. After the meeting, the manager can summarize these next steps by email.

Creating a few key habits in your one-on-one meetings will get you big wins. With the right topics and strong fundamentals, your 1:1s will quickly go from time wasted to time well spent.

Additional resources

Review these supervisor FAQs and best practices about 1:1 meetings.

Get inspiration or build your ideal 1:1 agenda with these free templates:

• DIY questions and best practices checklist
• Microsoft Word template
• Asana template
• Project management template

Managers will benefit from this slideshow:

Share this related slideshow with your direct reports, so you’re all starting with the same expectations:

The term “war room” seems to pair perfectly with end-of-the-world movies. Picture the president, sitting in a bunker-like room, surrounded by aides and Cabinet members who are providing up-to-the-minute details on the given world threat. The president must make the right decision, with no time to spare.

For most companies, this war room might seem a bit out of touch. Still, many companies deploy war rooms to solve specific problems, and IT is no exception. In this article, we’ll define the business use and benefits of an IT war room, help you determine whether a war room is for you, and provide war room best practices.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

What is an IT war room?

Unlike a traditional office environment, war rooms are spaces where key people get together to solve a difficult problem. Also known as situation rooms, control rooms, or command centers, war rooms should always have the goal of solving a difficult or specific problem via clear communication and improved workflows.

• Improving project communication
• Solving one or more problems
• Mitigating risk
• Updating everyone’s status

IT war rooms, specifically, often aim to pinpoint a tech problem’s root cause. For example, a war room with an IT focus might have goals like how to solve slowdowns or outages, improve network inefficiencies, or contribute to a development project. IT war rooms can be particularly useful in agile environments, where you may need inter-scrum communication.

So, who should be involved in a war room? It’s essential to bring together both subject matter experts and key stakeholders, like project decision makers and even executives.

War rooms vs meetings

War rooms and meetings aren’t the same. Unlike a normal meeting, a war room should mix people together who might not otherwise collaborate. War rooms also last longer; meetings might go 30 minutes or one hour. The best war rooms are located in a dedicated space for one or more full days or for a few hours over a week.

Most importantly, war rooms should feel different from meetings. Whereas a meeting might have one or two leaders sharing specific information, war rooms should encourage all attendees to speak up, move around, ask questions, and seek solutions. Generally, a war room feels more casual but also more engaging than a typical meeting.

Benefits of an IT war room

Proponents of IT war rooms tout many benefits. Perhaps the biggest benefit is the increased productivity. Scientists at the University of Michigan compared groups of software developers working in war rooms versus employees in a more traditional office environment. Their research illustrated an increase in productivity—some were four times more productive than their solo counterparts. Another bonus? The war room workers liked their new environment better than they initially anticipated.

That productivity increase may be attributable to several benefits of working in a war room:

• Communicate quickly and directly. Verbal communication is quicker than emails or DMs.
• Promote teamwork. Research shows that positive feelings around your team and collaboration results in increased commitment, responsibility, and accountability.
• Simplify transitions. Whether bringing in new employees or introducing major changes to your project, a war room offers a single stream of information that smooths the transition and ensures all players have correct, up-to-date information.
• Resolve issues promptly. The goal for IT war rooms is to reach decisions quickly—if you can’t or don’t, table them for the next session.
• Easily document lessons learned. This information can speed up or improve future projects.

Even if your IT war room doesn’t realize every single one of these benefits, collaborative face-to-face time among employees is valuable, especially in today’s remote workforce.

Is an IT war room always worth it?

If you’ve ever left a war room with warm, fuzzy feelings about your colleagues but without hard decisions and actionable solutions, that war room was not successful. Like any project management approach, IT war rooms aren’t always all they’re cracked up to be. In fact, some IT professionals believe that companies can overuse war rooms, which results in inefficiencies—exactly what the war room is meant to fix.

A variety of factors can make it difficult to solve IT issues: hybrid environments, multi-vendor deployments, and growing complexity and scale within enterprise infrastructure. Plus, companies still require control and security similar to on-premises infrastructure, and many departments are siloed even in terms of their technology. This decentralized technology approach may not befit a traditional war room.

If IT war rooms are meant to pinpoint a tech problem’s root cause, such decentralized technology makes it difficult for two main reasons:

• Tech problems often have many causes, not a single cause.
• The root cause of a problem is often completely unrelated to the problem itself.

In these cases, a war room results not in a quick solve but in wasted time, money, and resources. A war room that creates more problems—blamed employees, mismanaged time, sunk costs—is no war room at all.

Is an IT war room for you?

Do you need an IT war room? Consider these factors when determining if a war room is the right fit for your problem.

• The size, scale, and importance of a problem or project
• The likelihood that a complicated problem has a single solution
• The feeling that you could be doing more with your situation, but you don’t know how
• The competition is closing in and you must retain your competitive edge

IT war room best practices

Whether you’re convinced your company or project needs a war room or you’re looking to freshen up your worn-out war room ways, here are some best practices for creating a war room.

First, there are best practices on how to setup your war room:

• Dedicate the room. Do everything you can to make that war room specific to that given project. Don’t share it with normal meeting or conference space. You may even rent an off-site location to underscore your particular focus.
• Lock the door. The war room is for working on one single project only. Locking the door makes sure non-related employees aren’t looking for someone and prevents assistants from stealing executives away for something else. (Of course, war room attendees can leave whenever they need.)
• Let there be space. War rooms should have plenty of workable space. Walls and windows become makeshift displays for post-its, charts, and projections, and whiteboards and tables facilitate visual and collaborative learning.
• Stock the room. Have all the supplies you need: whiteboards and working markers in a variety of colors, post-its, extra notebooks and pens, and even snacks and refreshments. Anything that might prevent an attendee from rushing off in search of an item.
• Stay flexible. Choose chairs and tables on wheels instead of heavy conference tables and couches. This encourages attendees to break into groups and facilitates new conversations and collaborations–which result in new ways of thinking.

Once you’ve optimized your war room setup, use these best practices to establish the right protocol and attitudes for everyone inside the war room:

• Engage a variety of perspectives. Even if you’re working on an IT problem, you may be surprised at the unique perspectives that some seemingly distant employee—sales, finance, marketing—may bring to the problem. (This also breaks down silos common to most companies.)
• Create and build trust. Bringing together different business units might feel contentious. It shouldn’t. You all have a single shared goal for the war room. No matter your different backgrounds, you’re all there to solve the same problem. Stating this upfront when introducing everyone, then reiterating it through talk and nonverbal communication helps build trust among the attendees.
• Encourage subject matter expertise. All attendees are there to contribute to the problem and have been chosen for their unique perspectives and expertise. Encourage this by engaging people who may not be talking as much.
• Avoid blaming. You are looking to solve a problem, not create new ones. Acknowledge when something didn’t work, but stick to the facts, not to who may have caused the problem. If an attendee heads plays the blame game, quickly put an end to it and reroute the conversation.
• Make sure everyone can see and hear. At times, one person will lead the war room in describing the problem or summarizing data or solutions. Ensure all attendees can see and hear this information to create accountability and equality among the attendees. (If you do break into smaller groups, this is less necessary.)
• Use the same data. Streamline the data and metrics you rely on, so that all business units can understand the information. This ensures that everyone is coming from the same place.
• Visualize. Remember that everyone learns differently—some attendees may be verbal learners, relying on stories, but other attendees might need visuals of data, budgets, and timelines. Diversifying how you show and brainstorm the problem promotes creativity and new approaches.
• Avoid interruptions. Each interruption is another step away from a solution, so minimize interruptions as much as possible.
• Make decisions rapidly. Once data and perspectives are shared, make decisions quickly. If you can’t, there is some hold up that may require more time or information, so table that for next time and move to the next topic.
• Rely on people, not technology. Always remember that technology is the tool, but your people together are the solution.

Cutting edge AIOps technologies like AI and machine learning might offer a solution to failed IT war rooms. Tools like real-time infrastructure monitoring and automation can go hand-in-hand with what us humans excel at: providing accurate insight of more sophisticated situations. With customized, up-to-date tools and the smarts of your best colleagues, IT war rooms can go back to what makes them successful—resolving infrastructure slowdowns, outages, and other problems in no time at all.

Related reading

• BMC Service Management Blog
• BMC Business of IT Blog
• Tiger Teams: How To Solve Critical Problems
• What Is An IT Steering Committee?
• Types of IT Teams
• IT Best Practices

Tired of nightmare war rooms? Check out this webinar.

Even after a decade of trying, apparently IT still isn’t on the same page with other teams, often working around or at odds with one another on digital transformation initiatives. BMC offers fresh insights into how IT teams can improve collaboration and alignment across business operations. But what about teamwork and alignment within IT teams?

After all, it’s hard to convince other stakeholders of the value of collaboration if your own team isn’t in good working order. Here are five questions you can ask to evaluate whether your IT team operations are in sync or the source of problems.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

1. Are team roles integrated or siloed?

If you answered “siloed”, this is your starting point. Silos are a root cause of out-of-sync IT departments. They hinder more agile decision-making and processes, which are must-haves in an era when IT and the business as a whole are constantly under pressure to do more, faster.

The functions these silos typically represent—development, operations, QA, security, and so forth—are still critically important. But these roles need to be more explicitly comingled to improve internal communication and collaboration. Invisible walls must be torn down: developers handing off their code to operations and never thinking about it again; operations existing as a separate team in a different part of the building; security only as a final check before a deployment.

2. Are team members’ performance metrics at odds with one another?

Align your teams with shared incentives. You can direct developers and infrastructure engineers and security analysts to work together more closely than before, for example, but that will only go so far if their job performance is measured in conflicting ways. If devs are given incentives to ship code as frequently as possible, but ops or security pros are only measured by uptime or production incidents, they’re less likely to be in sync. Give people shared responsibility for your overall goals that are measured in standardized ways, regardless of job title or functional role.

3. Does friction exist in one or more key processes?

Out-of-whack performance metrics can be a source of conflict among teams, but there are plenty of other places to look for friction. Consider your software development and delivery pipeline, for example: Which stages and processes cause the most headaches? Where do things get bogged down by inefficiencies? Odds are that any pain points you discover in asking this question will lead to opportunities to reduce inefficiencies and bring the broader team into closer alignment.

4. Do people point fingers when things go wrong?

When things don’t go as planned, do people start playing the blame game? This is a sure-fire sign of an out-of-sync team. Instead of allowing blame to take root, opt for blameless postmortems to capture learning after an IT incident or failure. This practice can also be productive after any significant deployment or project phase, even when things are going well.

5. Above all, are you fostering a healthy team culture?

Out-of-sync IT teams often boil down to a dysfunctional culture born from all of the above issues and more: Too many silos, too much friction between people and processes, and so on. This is why DevOps culture has flourished. Its iterative focus on people, process, and tools aligns well with the demands placed on modern IT, and research shows it correlates with higher-performing teams.

Whether you label it “DevOps” or not, you can take cues from the culture the term represents. Key questions (and their answers) above speak to this, such as eliminating functional silos and encouraging shared responsibility across roles with better-aligned performance incentives and metrics. Also consider processes and technologies commonly associated with DevOps, such as continuous integration/continuous delivery (CI/CD) and a “shift left” mindset for areas like testing and security.

Wrestling with these five questions is a great start to improving your IT team’s internal collaboration. When you can resolve these process, structural, and cultural issues, your team will perform better work, make greater contributions to business goals, and employee satisfaction will get a boost along the way.

You probably associate the terms “offensive strategy” and “defensive strategy” with sports more quickly than you would with leadership in the workplace.

You might also wonder whether leadership in IT is any different from general leadership. The short answer is yes, but the better answer is both yes and no. Working in IT, whether you manage the help desk or oversee teams of developers, one thing is clear: IT-inclined employees rely on logic, not nuanced emotional responses, to get through their work.

That means that leading IT folks can require some tweaks or changes from standard leadership tenets, but a good leader is often a good leader regardless of the team or the product, especially when offensive leadership strategies are involved.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

What’s defensive leadership?

Defensive leadership is what it sounds like: leading from a place of defense. Being defensive, or defending, is using a close-minded approach to management. Close-minded leadership can result in failing to hear others when they offer feedback or challenge you, even if they aren’t confrontational. Defending can also rear its head when you blame other people or factors when you or your team fails or makes a mistake. (Other than in sports, when is being defensive ever a compliment?)

This approach, or lack of approach, hurts your professional life by impeding your vision and ability to learn from mistakes, accept and benefit from accountability as well as varied perspectives, and build strong relationships.

Defensive leadership also hurts your team, who want to be led successfully and positively. If you’re leading from a defensive place, you’re detracting from “learning agility”, a mindset that anyone can use to improve the way they approach problems, both professionally and personally. Learning agility includes practices like striving for improvement, questioning the normal way of things, and evaluating your experiences. Combine these with adopting new skills and taking on challenging projects where success isn’t assumed, and you’ve reached a new level of open-mindedness.

Research indicates that leaders who are learning-agile are demonstrably more successful, both in contributing to company revenue and their overall employee/manager ratings. Leaders who aren’t so agile fared worse, as direct reports rates them less effective in several categories including communication, adaptability, ability to meet business goals, and overall self-awareness.

Being defensive also obscures the reality of what you’re doing, making opaque both your goals and transparency within your team – which are particularly unhelpful when working in IT, where clarity is essential.

Is offensive leadership the opposite of defensive leadership?

While we can pinpoint closed-mindedness as a keystone of defensive leadership, offensive leadership goes far beyond simply relying on, and promoting, open-mindedness. Time and again, employees indicate what they value in their leaders: the desire to seek feedback and the challenge of learning from past experiences. Leaders who show both these tendencies were rated more effective at managing teams and implementing change.

Change is particularly useful in IT because information technology never stays in one place. While leadership of any discipline relies heavily on people management, leading IT teams is particularly tricky for two reasons: IT changes so rapidly and managing IT is nothing like it used to be. As such, special skills for IT leadership may be necessary.

Responding to change, let alone promoting change, is a difficult mindset to cultivate, but it can be done with intention and practice. Here are some tips on switching from defensive leadership towards offensive leadership:

• Embrace self-awareness. As your former defensive traits try to emerge, pay attention to the accompanying physiological signs, like sweaty palms, increased heart rate, or narrowed vision or hearing. Manage your emotions by asking yourself if you are communicating exactly what needs to be communicated or if you’re expressing a lot more than that.
• Promote an environment where failure is inevitable. This does not mean you won’t succeed; instead, by recognizing that failure, especially in development, is part of the process, you can focus more on how you and your team respond to mistakes. Using inclusive pronouns, like we and us, helps people see that you don’t seek to accuse or blame, but that the success of a product is incumbent on the entire team.
• Cultivate reflection. You can do this yourself by speaking less: when someone comes to you with a problem, listen more, ask questions to understand the problem (ask what happened and why instead of seeing a scapegoat), and then let them know you’ll respond soon once you’ve thought about the problem. You can also cultivate reflection in your employees by pausing before responding to feedback and thanking people for their insights, even if you disagree or feel uncomfortable. Letting people know that you hear them is vital.

Offensive leadership in IT

Of course, IT leadership isn’t simply about being positive and tuned into your emotions. A fast, pressure-full IT environment often relies on quick decision making and tactical approaches. Here are additional ways to improve leadership specifically in IT.

Know your people. It’s unlikely that your direct reports have the exact same interests or career goals. For some, they may want to stay on the cutting edge of every technology, while others might prefer to specialize in a particular language and framework. While you will certainly need flexibility from every employee, knowing what they prefer individually will help your team respect you and trust that you know them.

Know your customers. In this case, your customers are both the company’s end uses as well as anyone in the company who uses IT (hint: it’s everyone). Non-IT employees are often skeptical of IT folks, so taking the time to understand each department’s individual needs creates an overall feeling of trust towards IT. Whether it’s sales, marketing, finance, or HR, prioritize time to know your customers and encourage your engineers, devs, and help desk to get to know them as well

Hone your IT knowledge. As a leader, you should never be so far-removed from IT skills, frameworks, and emerging technologies that you don’t know what your team is doing day to day. As systems change, cybersecurity grows, and automation succeeds, IT managers must have working knowledge of these shifts, and this requires a pro-active approach.

Promote collaboration. You’re collaborating with your team and other SMEs and other managers, so promoting that among your team is beneficial. This is especially hard with IT folks, who are often opposed to working with other people because it can feel inefficient

Get creative. IT is about solving problems, so it’s rare that you’ll fight the same issue over and over again. That’s good, but it also means that each problem requires its own unique solution. This is scary, sure, but it’s also fun because people can be creative and it’s likely that your employees welcome this challenge.

Make your decisions clear. Because IT is the engine for the business, there are times when a speedy decision is necessary, even if you want more time to make the right decision. Make your decision, make it clearly, and make it logically. If decisions don’t make sense logically, your employees will figure it out.

I’ve yet to see an IT group that is 100% happy with the level of communication it has with the rest of the organization. To help improve communications, many groups try and produce a regular newsletter to provide the boarder organization with more information about what’s going on in IT. If you are thinking about doing this in your organization, consider these tips to help make it worth the time invested.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

Make a Commitment

The need for a newsletter often comes as a reaction to some specific event. After all, how many times have you said, “if a user just knew x, we could have avoided this whole situation”? As IT professionals we are often predisposed to be a “fixer”. We see that end users don’t know something they should, so we immediately go into fix-it mode and try to blast out our vast amount of IT knowledge to the rest of the organization. The problem with the reactionary approach is that it is very difficult to maintain the initial motivation and momentum that comes from trying to fix a problem. A newsletter (or regular communication) is not a service desk ticket that must be resolved and forgotten. It is a commitment to providing communication to end users on a regular interval that will help them be more successful. Know this at the beginning and make a real commitment to publish on a regular basis. This means assigning specific tasks to specific people due on a certain date. Working on a newsletter “as time permits” will rarely lead to a successful outcome.

Help Don’t Tell

In order to create interest, you must be in the mindset of helping your end users. If you want end users to get better at password management, you must approach it from their point of view. Instead of writing about “password requirements for organization x”, put yourself in their shoes. Approach the situation from their point of view. If you need to, talk to a few people about why they are having trouble understanding the requirements that they need to follow. Then, you’ll be able to come up with a newsletter article similar to “Having trouble resetting your password, here’s three tips make it easier”

One other way you can approach this is to pretend that you are reading a newsletter from another group. As an IT professional, why would you read a newsletter from the finance department? Personally, I would only read it if I thought there was something relevant that would help me get my job done. I might actually read an article titled “5 tips for submitting your departmental budget.” Make sure you write to draw the attention of non-IT staff.

Have a Content Strategy

Your newsletter may ultimately fail or reach a narrow audience if you don’t plan your content well. Know what’s going on in the larger organization and line up your newsletter content to match. For instance, if you are going through an audit, include information that is relevant to helping end users meet audit requirements. If there are quarterly financial reports due, create articles like “how to leverage the company intranet to submit your reports on time”

When developing your content strategy, it can also be useful to vary your content throughout the newsletter. While you may follow a general theme “like meeting audit requirements” consider what types of articles can help meet compliance. You could have one article that is a “how-to”, one article that is a story about “how jane used data analytics to meet quarterly results”, and one that explains an audit requirement like “5 things you need to know about audit control 3.4.5.”

Use Imagery and Multimedia

I’ve seen so many IT groups try and create newsletters that were plain text (and boring), because the sysadmins and security don’t like HTML emails. If you want your IT newsletter to be read and be helpful it needs to be enticing and visually appealing. Include an image with each article that provides a visual representation of what the article is about. If possible, include imagery from inside your organization. For any how-to articles, include a short video clip walking users through doing something.

Don’t Make it too Long

Creating an IT Newsletter can seem very overwhelming at first. Start off small and build from there. It’s perfectly acceptable to release your first email newsletter with only 3 articles and a few helpful links. Get on a regular schedule of producing content, even if its small. Then, you can see if it’s too much or too little and adjust accordingly. Remember, you are making a commitment to regularly providing information to the organization. Build the habit within your team first. Then if you want to add more you always can. Creating a newsletter is a marathon, not a sprint. Don’t burn your team out early in the process and cause the newsletter to fail after just a few publications. It will take months to get your readership up.

Show Personality

Whether you realize it or not, your IT organization has a personality. If you don’t know what it is, ask around see how people categorize your group. Are you the “IT Overlords” or “The Nerds in the Basement” or the group that “Gets things done”? If you have a positive image, embrace it, an incorporate it as a theme in your newsletter. If you have a negative image use the newsletter as a chance to create a new image of what you want to be known for. For example, if your group is known as the IT Overlords name the newsletter something like “The facilitator” If you group likes to go out for lunch, you can even include a quick article at the end of your newsletter titled something like “We went to restaurant “x” for our lunch meeting…here’s what we thought.

The main point here is to let the organization get to know the IT group a little bit. Create a positive persona for your group. After all, IT groups are service providers, and enablers of business. It’s much easier to trust someone you know rather than trusting the “basement dwelling overlords”.

Talk About the Future

Include in your newsletter something about future projects or events that the IT group is providing. Business / IT alignment can be challenging in any organization. By talking about the future in the newsletter you enable a conversation about alignment. You might even have a VP stop by and say, “I saw your article in the newsletter about project X. I’m excited about the project and would like to hear what it does for our area” You might also hear “I read about project X and I’m not sure what its in line with what we are doing in sales. If you did project Y instead that would really help us out.

The newsletter won’t solve all your alignment issues, but it can play a vital role in creating the conversations that lead to better business alignment.