Building in operational resilience with managed service providers

Which activities do you do today that you should probably delegate? Similarly, which activities does your department own that probably should be delegated?

Hi, I’m Peter Nichol, Data Science CIO.

Today we’re going to talk about managed service providers or MSPs.

Why make the shift to MSPs?

The concept behind a managed service provider is to shift ownership of daily activities to allow your team to focus on more important strategic priorities.

The concept sounds pretty simple. However, telling the team that 90% of what they did yesterday is going to be outsourced is tough. However, if we go back to basics, the principle of leveraging MSPs makes sense.

Consider for a minute what activities in your own life you delegate. Maybe you outsource lawn care to the neighbor kids or hire a cleaning company to keep the vacation property looking amazing. In both cases, you’ve decided that your time is better spent somewhere else—you can add greater value by doing a different type of activity. This is the same business case your organization is making. Your team’s time is better spent on building out core organizational capabilities, not focusing on non-essential organizational capabilities.

The case for MSPs in our business

Similarly, when we perform our organizational duties, we often take ownership of pieces that fall through the cracks over time. We tell ourselves it’s necessary to address the immediate need—for example, a frustrated stakeholder or client. Then, in the light of being a good corporate citizen and helping our peers, we shoulder this additional responsibility. We might have developers take greater ownership of application compliance because security is understaffed, or we might have project managers start architectural models because the architecture review board isn’t mature. In both cases, a team has acquired new responsibilities that, on reflection, shouldn’t be owned by those teams.

When engaging a managed service provider, the objective isn’t to transfer busywork to an outside company. If activities don’t add value, they should be challenged and stopped. However, we do want to transfer activities that can be more effectively done by a third party or by experts.

It’s essential to start identifying activities that your department has picked up ownership of over the last six or nine months. Call out activities, processes, and outputs that your team realizes you shouldn’t own and that need to be transferred back to the original department or group.

Set up a discussion with the department’s leaders for knowledge transfer. Communicate that six months have gone by, and call out the functions that need to be reabsorbed into your peer’s organization.

Focus on the most significant impact on your business

When we engage MSPs, we’re talking about shifting ownership of areas that add value but aren’t core competencies.

  • What are the core competencies of your business?
  • What are the most important things to achieve?
  • What drives the most significant value for your organization?

There will be areas that drive benefits but that aren’t the most important for your organization. Ask yourself, “If we become number one in this capability, will that become a competitive advantage?” Often, what are considered non-essential capabilities depend on your core business model.

  • If you’re a healthcare provider, most likely marketing isn’t your top priority.
  • If you’re a software company, probably billing isn’t your top priority.
  • If you’re an architecture company, you’re probably not focusing on IT support and running a help desk.

Look at your core business model to discover how your business can effectively leverage the benefits of a managed service provider to enhance operational or day-to-day activities. Of course, these operational activities are essential to keep your business running, but you wouldn’t consider them to be core capabilities for your business.

Illustration 1.0 Foundational vs Commodity Capabilities

The benefits of MSPs

There are a lot of benefits when utilizing the services of MSPs.

First, we have the benefit of expertise. In theory, this is going to be a provider who has deeper and broader expertise than your current team.

The second benefit is predictability and, more specifically, financial predictability. Instead of having costs just being incurred, you now have predictable financial spend monthly, quarterly, and annually. As opposed to anticipating all the variable costs, your provider can offer insights into when unplanned expenses are likely to be incurred. The provider can use their expertise to predict the demand ebbs and flows to utilize resources and mitigate risk more efficiently.

Third, you have the benefit of the provider anticipating unknown costs. Because the managed service provider has other clients in various industries and sectors, they can predict changes in market conditions that your internal team might not be familiar with.

Environmental changes or the introduction of new models—such as a change to the licensing fee structure—are something that MSPs can help your team stay ahead of. Here are some additional benefits of leveraging MSPs:

  • Better visibility over contract spend
  • More predictable costs
  • Enhanced service quality
  • Improved automation
  • Great simplicity
  • More demand flexibility
  • Expanded scalability
  • Greater skill and expertise
  • Broader on-call coverage for unplanned events
  • Standardized security models for data
  • OpEx reduction
  • Reduced training
  • Lower break-fix ratio

Which areas benefit the most from MSPs?

Let’s concentrate on three areas in which managed service providers are most likely to be effective.

Application maintenance

Third-party application maintenance is a huge part of IT’s annual operating budgets. By leveraging managed service providers, these costs can typically be decreased anywhere from 25% to 50%. This allows for initial maintenance-cost spend to shift and for the funding of emerging technology and innovation pilots. Without a high-performance team, managing legacy systems can be very costly, often requiring multiple resources, all with specializations.

Network and operations

Network and operations are essential to most businesses. However, they’re also relatively stable once established. The cost to maintain these environments can vary wildly. For example, upgrading the mobile platform for an extended range can be a complex initiative. Yet, once that project has been completed, those resources benefit virtually idle until the next project. This is a great business case for leveraging MSPs to augment existing infrastructure teams.

Usually, network and operations functions operate effectively unless additional capacity is required.

IT help desk

Virtually every business needs standard IT support. This covers things like ordering new laptops and mice for existing and new users. Users want someone to call when their computer doesn’t work or they can’t log in to the VPN. These calls, while important, aren’t strategic. These non-essential functions are great candidates for off-loading to an MSP.

Illustration 2.0 Capabilities Timeline

What metrics matter?

While there’s an almost unlimited combination of metrics that help to drive MSP performance, here are the metrics I’ve found over the years to be most effective:

  • Customer satisfaction score
  • First-call resolution
  • Escalated tickets
  • Resource utilization
  • Newly discovered applications, devices, processes
  • Contract renewals
  • Rate compliance/service level agreement (SLA) compliance rate
  • Churn rate
  • Mean-time to resolve (MTTR)
  • Cost per ticket
  • Effective hourly rate (total cost divided by hours worked)
  • Tickets open by type
  • Average time to acknowledgment
  • Average time to resolution plan/total time to resolution plan over full tickets x100
  • Kill rate of tickets = closed tickets/tickets open

Make sure hard metrics make it into your MSP contract. It’s much easier to discuss metrics versus having a conversation about why folks feel expectations aren’t being met.

How to select the best MSP
Hiring an MSP can be confusing. It’s a huge decision, and if the help desk doesn’t work on day one, the transition can be embarrassingly loud. So, here are the key steps to select the best MSP for your situation:

  1. Confirm domain expertise. Focus on engaging a vendor with domain expertise—not just in your vertical industry but in the space in general. For example, if you’re outsourcing the IT help desk for an energy company, make sure the vendors have experience managing help desks and have knowledge of the energy sector.
  2. Ask for references. Requesting references is a must. We all know references can be manufactured or made up and typically are. However, it’s still important to talk to somebody who was a client of the MSP to gain a better understanding of their quality of service.
  3. Validate an anticipatory culture. Make sure the MSP company culture supports planning ahead rather than having a reactive mindset. The MSP must be capable of staying ahead of changing business conditions and not have a habit of chasing significant changes.
  4. Focus on value over hours. Take time to construct your MSP contract to be framed around outcomes and value realized, not hours billed.
  5. Use performance measures to determine success. When designing the delivery structure, take care to develop service level objectives (SLOs), operational level objectives (OLOs), and business level objectives (BLOs) to measure and validate performance.
  6. Match the organizational structure to demand. Too often, we focus on the contract and the terms and miss the big picture. It’s imperative to ensure that you’re not losing support by shifting to MSPs. For example, if you have 20 top resources supporting a capability, and the MSP suggests aligning four, full-time, equivalent resources, that’s not good. It’s clear this level of support—no matter how good the resource quality—won’t match five times the resource volume. You’re simply not going to get the same level of performance from 20% of the resources you have on the ground today. In this case, either dial up the resource requirements or drastically shift delivery and performance expectations for the new team.

I’m glad to share the different approaches when considering engaging a managed service provider. If you transition effectively, you’ll provide even more efficient and effective services for your business partners.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

Capacity-based funding for the modern product team

How are your teams forecasting work? How do you anticipate a budget when you’re not sure what you’re going to spend in a fiscal period?

Hi, I’m Peter Nichol, Data Science CIO.

Today we’re going to talk about capacity-based funding. This is a concept that many have heard of but few leaders execute effectively.

What is capacity-based funding?

Capacity-based funding is more agile and iterative than project-based funding and uses team size rather than project size to determine funding parameters.

To better understand capacity-based funding, we’ll use project-based funding as a reference. Project-based funding is the funding of a single initiative. You have an annual review cycle in a project-based funding model, almost like an annualized budget cycle. Many leaders would argue that not only is project-based funding inefficient, but it never did work.

There are three main areas where capacity-based funding differs from project base funding. First, it has a more extended period of estimation. In this new model, we’re funding a product team. This is a group that’s focused on a strategic or a multi-year initiative. This funding is also provided for a longer time—typically, 12, 14, or 18 months. Second, you don’t measure the costs, and you’re also not calculating the actual spend over time. Dropping these labor-intensive tasks frees up the team to focus on the actual product work and high-value-added activities. This shifts the focus away from operational tasks toward activities that directly add value to our product. Third, teams operate autonomously. The team members work in their little sphere and are focused on delivering a product. The team doesn’t ask for permission. They don’t escalate questions about the direction or which feature is more important. These teams are decision-makers. They analyze, interpret information, decide, and move on. Operating on their principles and norms removes much of the bureaucratic red tape that traditionally slows down high-performing teams.

The influences that press on capacity-based funding models

As soon as leaders hear that costs aren’t tracked, other questions get raised—mainly, “How do we influence the outcome and performance of teams using a capacity-based funding model?” There are a few different questions to ask to determine this:

  1. How much?—i.e., work volume or total hours
  2. How often?—i.e., work priority
  3. How many? i.e., team size

The first thing to determine is how much. Here we’re talking about the total work covered by the team. Another way to look at “how much?” is to consider the total hours of work (our capacity) over a given period. Often, this period extends over six months or a year. The second thing to know is how often. What’s are the frequency parameters under which the team will operate? Is this a team that meets once a year for three weeks, or is this team funded through the entire year? The concept of frequency is tightly coupled with the idea of priority. What’s the priority for the work the team is expected to deliver? The third determination is how many. This question refers to how large the team is. What’s the size of the team and the number of dedicated resources? What’s in scope (how much) and what’s the priority (how frequent) that will drive the team size (how big)?

What are the challenges with capacity-based funding?

With these benefits, it would be easy to assume that capacity-based funding is a utopian model and that everybody should move to this model. Well, it’s not all roses. There are several reasons why leading product initiatives with capacity-based funding models is difficult for executive leaders. Here are a few of the big hitters:

  • Work delays are easier to hide.
  • Shifts in priorities have a cost.
  • Buckets of funds are harder to see than in a focused project.
  • There may be a shift in portfolio leaders to manage new factors.

First off, it’s tough to identify work delays using this model. If you have project funding, it’s usually funded for a defined scope. However, with capacity-based funding, elements could be in scope, quickly determined out of scope, and then included back into the initiative’s scope. With this scenario, it’s tough to determine the original state of the ask and what the decision-making was to get to our current scope. There’s no way to track changes in a capacity-based funding model, unlike the change management we have in conventional project-based funding. The concept doesn’t exist because we’re not tracking expenses, and we’re not tracking the effort—or, more specifically, the dollars involved in that work product. So not having the specificity can be a big challenge if leadership continues to ask for the deltas; i.e., how we got from there to here.

Second, we aren’t tracking any financial spend. This results in not having a low-level (line-item level) of financial details to explain variances. For example, if leaders want to know how much functionality “A” costs to cost allocate to a business unit, we won’t have that detail. Of course, the team could develop some assumptions, but none of these will be tied to real numbers. Now, if leaders need that information tracked, it can be followed. But, if that’s the case, you’ve chosen the wrong tool for your financial planning. The absolute truth is that you’re not in an agile environment. You’re operating a waterfall methodology and pretending to be agile. I’ve been a leader operating in these types of environments, so take it from me: This makes everyone’s life miserable. This hybrid model is the worst of both approaches. It saps energy from the team and slows down team velocity.

Third, the team must have the autonomy to operate. This requires less—not more—oversight on the team. This also introduces more leadership challenges depending on the team members. This model works great for high-performing teams that gel and work well together, but it creates problems for younger and more immature groups.

How can portfolio leaders get ahead?

As we start to get into the details, we quickly run up against how we lead these opportunities. There are three strategies I want to share to optimize teams using capacity-based funding models.

Time series analysis

Time series analysis helps to analyze how long each segment takes to complete. By using this approach to forecast future performance, you’re able to determine the efficiency of your overall process.

Pipeline analysis

Pipeline analysis brings in the cycle time for all the steps of the process. This analysis offers insights about specific pieces that make it through the pipeline and those that don’t. This step helps to provide a mid-point check of the efficiency of the flow or value stream.

Value leakage

Value leakage identifies where value was lost. Quite often, we’re managing pipeline throughput (outcomes) and interim milestones. This could be process gates or milestones in the middle of our plan. Unfortunately, if we only focus on the end game, we miss areas where value dripped out of our process.

It’s excellent if your process is efficient. However, ultimately, we need to measure the cadence (speed) and outcomes (value delivered) resulting from our process.

Now you’re empowered with new insights and tips for managing a capacity-based funding model.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

A testing paradigm to fast track the availability of business functionality

When you do root-cause analysis, you always discover functionalities missed in testing or defects that were put into production that could have been identified earlier in the process.

Hi, I’m Peter Nichol, Data Science CIO.

What does shift left mean?

Today, we’re going to talk about the concept of “shifting left and shifting right.” Then we’ll cover the “shifting in reverse” theory. All right, I made up the “shifting in reverse” theory. Shifting left and shifting right are what we’ll explore today.

Shifting left is a concept that was introduced within the last 10 years or so, but it originated in the 1950s when IBM introduced the Harvard Mark I supercomputer, also known as the IBM Automatic Sequence Controlled Calculator (ASCC). The level of technological advancement at the time was a huge deal. This computer cost about $5.7 million in today’s dollars, and it weighed 9,445 pounds or 4.7 tons. It also came with over 500 miles of wires, three million connectors, and over 35,000 contacts. This was an extremely complicated computer that took years to design, assemble, and build fully. Nevertheless, the computer was a success, and it was pretty powerful for its time.

How shift left originated

While the computer was powerful, developers didn’t have an easy time working with this massive machine. If developers had a code mistake, they had to rerun their code (cards), and rerunning code was expensive because the cost of computing was expensive. A concept was developed to move testing to earlier in the process to decrease risk and lower costs. Hence, the idea of shift left was coined and began to take hold.

What are the advantages of shift left?

There are three significant benefits in adopting a shift-left technology culture.

The first is early detection of failure points. By testing earlier in the lifecycle, developers can identify defects, code breaks, and problems with logic earlier in the lifecycle. This leads us right into our second benefit, which is cost avoidance. When we test earlier in the process, we reduce the cost of fixing defects and decrease the likelihood of extensive remediation efforts. The third benefit is that we can get functionality into production much more effectively and sooner because we can reduce the lifecycle. Shift-left delivery models also offer benefits such as:

  • Developers test their code
  • Modularized functions
  • Co-location of developers and testers

How does shift right fit into the mix?

This leads us to the concept of shifting right. Shifting left—testing earlier in the process—seems like common sense. It just sounds reasonable.

When we look at shifting right, the logic seems less clear. Why would we shift right when we just put all this time and effort into shifting left? Also, why shift right at all?

The concept of shifting right isn’t mutually exclusive from the idea of shifting left. Surprisingly, the concepts are complementary.

What are some excellent examples of shifting right?

The idea behind shifting right is that once functionality goes into production, no additional testing is performed. That functionality is, in essence, forgotten. From there on, we assume the functionality is working as expected. Then, of course, new functionality is tested immediately post-deployment. However, here we’re talking about a week or two later. Does your IT team continue to test after that two-week window? Doubtful. We assume that there won’t be defects after that point and, if there are, the business users will discover and report them.

Do we want our business partners and customers to find defects and problems with production? Hell, no. We want to fix them proactively before our business partners identify those problems. This is precisely where the shift right mindset adds value. I’ll explain the three main concepts behind shift right briefly, including A/B testing, dark launching, and chaos testing.

  • A/B testing: This concept looks at the initial design requirements and ensures that they work in production.
  • Dark launching: This is the process of unofficially slowly releasing functionality to production. The key here is that the functionality being released isn’t officially announced to users. LinkedIn is well known for leveraging this approach as they release functionality to select groups of influencers. Functionality appears on a page and is immediately available. Members can either leverage the new features or not. However, rarely are they released to all members.
  • Chaos testing: This is the idea of making sure we have unplanned test scenarios as part of our test plan. Chaos testing can involve simulated stress testing or injecting other types of errors or defects into the mix. For example, we might deliberately get the system to throw errors, inject rare scenarios, or run some edge-case scenarios when trying to break a piece of functionality that didn’t handle the exception effectively.

Here are some additional examples of shift-right concepts:

  • Canary testing
  • Continuous quality monitoring (CQM)
  • Code instrumentation
  • Production user monitoring
  • Production testing

As you race into your workweek, ask yourself, “Am I leveraging the shift-left methodology? Am I testing as early in that lifecycle as possible?” Once you have those answers, you secondarily ask, “Am I shifting right? Do I have controls in place to test and retest functionality after it’s in production?”

Save your users the stress of stumbling into production defects. Instead, start finding defects before your business partners do.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

Maximize your CI/CD pipelines to get functionality into the hands of business users faster

Do you lead a technology team? Have you been asked to produce more features in less time? Is your team expected to deliver more functionality to business users at lower cost levels?

Hi, I’m Peter Nichol, Data Science CIO.

What is CI/CD?

Today, I’m going to share some insights on how to do precisely that. The concept is called CI/CD, or continuous integration and either continuous delivery or continuous deployment. There are three steps in this model: continuous integration, continuous delivery, and continuous deployment.

Continuous integration means that multiple developers can work in an environment simultaneously.  Continuous delivery means that when a piece of functionality has been coded, it automatically goes into a registry and is tested immediately, without any extra intervention. Finally, continuous deployment means that releases automatically go into production once they pass a predefined testing threshold.

The intent of designing a CI/CD pipeline is to automate the application-software delivery process to get functionality out quicker, more effectively, and at lower costs. Although there are many reasons to begin a CI/CD initiative, let’s look at the main reasons for driving a CI/CD orchestration and automation business case.

To recap:

  • Continuous integration = multiple developers working together
  • Continuous delivery = changes automatically uploaded and tested
  • Continuous deployment = automatic deployment once code passes testing

How does a CI/CD pipeline benefit business users?

There are a lot of benefits to building a continuous-delivery pipeline.

The first and most apparent benefit is automation. By automating and streamlining your pipeline, you save costs and free up resources to do higher-value work.

The second is continuous testing. Instead of engaging in testing and starting that process, much of the CI/CD environment testing is automated. It happens automatically without human intervention.

The third is accelerated and consistent delivery. It’s essential to make sure that deployments are moving to production as fast as reasonably possible. We have to be careful to remove roadblocks that others might have added. For example, we need to remove extra approvals or any dependencies or hindrances that would prevent functionality from reaching end users once it’s been validated to be working effectively. Once code has passed our defined threshold, we want that functionality immediately available for our user base. This is what’s meant by a continuous CI/CD pipeline. We often hear that almost every environment has a pipeline, and they are fully automated. I don’t believe it. Start asking questions of your engineering teams, and you’ll realize that more of your release—not less—is manually orchestrated.

How does continuous integration work?

One of the most important concepts involved in designing effective CI/CD pipelines is continuous integration.

The idea around continuous integration is to ensure you’re able to release functionality constantly. Continuous-integration environments are designed to support multiple developers working on the same code base at the same time.

This means developers continually update code, merge different code branches, and consolidate and tweak their code. This way, they ensure that all that functionality works at the same time. This process, while tedious, decreases integration testing at the end of the process—in effect, shortening the lifecycle to move code into production (build, test, deploy).

Huge benefits result when this process works seamlessly. The testing process is accelerated, and the time saved ultimately speeds up the overall deployment process. If things are working, that’s great. We quickly move that functionality into production. However, if things aren’t working or appear broken, we’re going to remediate that functionality and codebase immediately. The benefit here is we’re not having a QA test when we know things don’t work. We’re saving end-to-end time in our pipeline.

With continuous delivery, we’re trying to get functionality tested as quickly as possible. We’re not waiting for QA or testing to pick up where developers left off. Instead, the process flows continuously.

Here’s specifically where the work gets done:

  • Continuous integration: build, test, merge
  • Continuous delivery: auto release to repository
  • Continuous deployment: auto deploy to production

What’s the bottom line?

As with continuous-delivery the concept of continuous-deployment, is to get as much functionality live as possible once it’s working. Continuous delivery automatically moves code into a repository and continuous deployment moves it into a production region—a region available to users to consume. That might not be your final destination. It might be a staging location or an interim environment. But it’s trying to get that functionality out as quickly as possible.

There are tons of CI/CD products to explore—from Jenkins to Travis CI. Here are some of the big hitters.

  • CircleCI: rapid software publishing, runs using containers or virtual machines, easy debugging, very customizable.
  • TeamCity: JetBrain’s build-management and continuous-integration server, runs in Java, integrates with Visual Studio and IDEs
  • Bamboo: a continuous-integration server, automates software releases, runs batches of tests in parallel, quick feedback, creates images and pushes it into a registry
  • Codeship: hosted platform, multiple deployments, easy select AWS instances, size, CPUs, and memory
  • Wercker: docker based, microservices, GIT integrations, GitHub, GitLab

As you consider leveraging CI/CD pipelines in your environment, remember, don’t get bogged down in the details. The entire purpose of automating your development pipeline is to get functionality out to your end-users faster, more efficiently, and at a lower cost.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

DevSecOps and the new age of application security testing

Are your operations and security functions automated? Have you eliminated manual processes as you start to tighten up your security and controls?

Hi, I’m Peter Nichol, Data Science CIO.

Today we’re going to talk about DevSecOps. DevSecOps is a simplification of the phrase development, security, and operations.

What is DevSecOps?

Let’s begin with a brief explanation of what DevOps is to ensure we’re clear on the difference between DevOps and DevSecOps. DevOps is focused on development and operations. The development part hones in on automation, building or development, testing, and releasing the functionality into your environment. When we add “Sec” in between “Dev” and “Ops,” that reflects considerations of security—for example, ensuring that security is a part of every role. This means that when we make development and operational automation decisions, we have the potential to make similar decisions about the orchestration and automation of security through the DevOps process.

How do DevOps and DevSecOps differ?

DevSecOps adds security to the DevOps process. Previously, your team may have had one or maybe two big releases per year, so security wasn’t such a big concern. The team had lots of time to tighten those security controls and ensure that security procedures and policies were adhered to prior to deployment. With continuous integration, continuous delivery, and continuous deployment—also known as CI/CD pipelines—the team now has monthly, weekly, or even daily releases. In this new environment of constantly releasing customer features, it becomes much more important to evaluate and measure the security footprint on a more consistent basis. This brings forward the concept of DevSecOps to bring security into the development, operations, and release lifecycle.

Where did DevSecOps start?

The idea of continual security goes back to Dr. Joseph Duran, one of the founders of the quality management movement. He introduced the concept of quality by design (QbD). Duran believed that quality wasn’t an aspect of an output of a product or widget. Quality didn’t just happen, and it wasn’t something that needed to be done once a product was created (or features were developed and completed, in our case). Instead, quality was designed into the product, and quality assurance was performed throughout the entire process. It wasn’t a one-off step at the end of the process. By building quality into products, manufacturing companies started to produce higher-quality products with fewer defects.

DevSecOps is as simple as, “design security into the process” or embracing a “security by design” mindset.

We’re able to leverage the same quality-by-design principles that Duran applied so many years ago into how we plan, design, and deploy features that are wrapped, tightened, or hardened by security procedures. We have to design security into our ecosystem. It’s no longer productive to conduct an assessment after features are deployed to determine if code complies with our security standards and procedures.

What does DevSecOps look like in practice?

DevSecOps integrates security into normal development and operations that, in today’s infrastructures, are largely automated. DevSecOps works, in practice, because security workflows apply the development standards and architecture definitions for the organization. This could be things like validating that there are no security gaps in code before it moves into a region. Another example might be validating that the right infrastructure cloud policies prevent unnecessary exposure to sensitive infrastructure, networks, or parts of the security footprint. Ultimately, DevSecOps established many different elements to make sure that security can be streamlined and orchestrated effectively. The result is that rapid security assessments become a regular part of our development and operational environments.

It’s common for a collection of products to be used for DevSecOps orchestration. Here are some of the most popular.

  • Commit code to repository: JFrog, snyk, Skim dev, Tallisman, git-secrets, HOUND, Vault, AES Secrets Manager
  • Build: Checkmarx, ECG, DerScanner, GitHub, Black Duck
  • Deploy: RAPID, acunetix, VERACODE, clair, anchore, DOCKSCAN, KitchenCI, CHEFINSPEC, Signal Sciences, imperva, walarm, Cloudflare, Nagios, Datadog, Gremlin, ChaosToolkit.

What are the benefits?

We’re looking to remove the manual security processes that occur during the deployment or testing of a release. However, just the introduction of DevSecOps introduces new organizational benefits such as:

  1. The ability to audit
  2. The ability to be compliant
  3. The ability to identify issues right away and take immediate action
  4. Accelerating report compliance
  5. Formalizing documentation of triggers and decisions made by automation agents

There are many software benefits from having a repeatable and durable security approach that’s streamlined to the degree that the process is mainly automated. While seemingly obvious, the removal of the human factor can significantly reduce variance and production issues. For example, many deployments are performed at odd hours, and, during these hours—whether they’re deployed at 9 pm or 2 am—the team is often not at the top of their game. By adding intelligence automation agents, we remove manual steps that can be defined and repeated with overwhelming precision.

How to get started

After leaders hear about DevSecOps, they’re excited. Their next logical question is, “Now what? How do we start?”

First, define the roles and responsibilities. Consider who’s involved or the roles they play.

Second, establish policies. This answers the general question of, “Why is this new process being introduced, and what’s the desired benefit?” Evaluate which standards are mandatory. Take time to define guidelines and elaborate and expand on best practices. Also, be sure to establish procedures that articulate the step-by-step instructions for compliance.

Third, turn up the automations. You’ve defined the processes, procedures, and implementation standards. Now it’s time to reduce human intervention and narrow the pipeline-error variance through automation.

Fourth, collect evidence. Start making a hit list of what’s working and what’s not.

Fifth, design a constant feedback loop to validate that you’re received timely information or decision making. The feedback loop provides you with a method to discuss lessons learned and introduce positive changes into your environment.

As your week begins, consider whether your DevSecOps pipeline is automated and working in your best interest. Evaluate your operational teams. Ask yourself, “How can the team be a little bit more effective by exploring DevSecOps?” Taking time to automate your DevSecOps environment helps you reach your next organizational win!

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

Detect anomalies faster with AIOps

Have you ever been trying to use an application and it went down? Is your organization challenged with keeping applications up? Maybe it’s not just Outlook, but other essential business applications aren’t stable.

Hi, I’m Peter Nichol, Data Science CIO.

Today we’re going to get into some of the benefits of AIOps, also known as artificial information operations. The mean time to fix a production outage is 4.5 hours. Extended outage periods negatively impact your staff productivity and efficiency. Benchmark studies estimate that $21.8 million per company is lost annually due to unexpected downtime.

What is AIOps?

AIOps applies the concepts of machine learning and data science to solve IT operational problems. Often, these problems are solved through the introduction of automation.

One of the fascinating examples of applying AIOps is leveraging this technology to identify network failure points. Operations—or, more specifically, artificial intelligence operations—use predictive technologies to identify the root cause of failures within software-defined networking in vast area networks (SD-WANs). SD-WANs carry mission-critical traffic (transactional, customer, member). These intelligent networks can dynamically partition and protect the network against vulnerabilities in other parts of the technical enterprise topology. These intelligent and predictive network tools are triggered by irregular patterns of behavior and near-instantly change the network’s topology.

AIOps offers benefits in many areas

When technology leaders have challenges with utilization or bandwidth, AI operations can immediately identify when threshold limits have been reached.

Amazingly, through the integration of other technologies, environments can provide auto-scale. Autoscaling is the act of dynamically increasing bandwidth for peak load and then contracting bandwidth when it’s no longer required. This process of ideal usage helps create a highly efficient infrastructure, saving dollars when we least expect it. Automating these processes using thresholds can generate significant benefits when monitored and implemented by experts.

There are numerous areas where AIOps can offer benefits:

  1. IT incidents
  2. Intelligent IT automation
  3. IT service management
  4. Alert management
  5. Automatic anomaly detection
  6. Ability to predict outages
  7. Freeing up expensive human capital
  8. Availability and performance monitoring
  9. Event correlation and analysis
  10. Cloud spend optimization
  11. Identifying the health of customer-facing issues

The growing market for AIOps

AIOps is erupting with potential. It’s forecasted that, by 2023, the market for artificial intelligence for IT operations will blow up to about $11.2 billion. This marks enormous growth in an industry that’s fascinating but relatively unknown.

When we look at the players in this space, the predictive capabilities they can provide are almost unbelievable:

  • Data agnostic tools: Anodot, FixStream, and OpsRamp
  • Legacy platforms: bms, ca technologies, and Micro Focus
  • Logging: elastic, OverOps, and splunk
  • Monitoring: Dynatrace, SignalFx, and ScienceLogic
  • Alerting: pagerduty, OpsRamp, and LogicMonitor

Again, AIOps focuses on taking action based on events that can be predicted through pattern analysis. Taking action based on failures or when things go wrong are typical applications of AIOps.

What applications do you use the most during the day? Which applications, when unavailable, most significantly impact your team’s performance? It’s not just Microsoft Outlook and other core applications that prevent individual users from performing their daily duties when they’re not available. To send that email, you might have to check a report in Tableau. You might have to download SQL Server Management Studio data or ask a team member to pull the data for you. Rarely does the primary business application meet 80% of the business needs.

Autoscaling is likely the most common AIOps application where bandwidth scales up or threat-based events trigger the auto partitioning. These are both examples of AIOps at work.

Has your organization fully leveraged the power of AIOps? For example, has your company defined standard operating procedures for auto-scaling? Are you in agreement with your business partners about those procedures? After all, when those services aren’t available, guess who they’ll affect the most?

The ability to introduce self-healing, self-monitoring, and self-management tools through the design of AIOps environments can transform outcomes for technology leaders.

AIOps offers a great ecosystem of platforms, services, and products when you have information overflow.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

Keep pace with your business partners by introducing advanced Smartsheet features

Are you enabling your business users? Is your team providing business owners the functionality they need to perform business-as-usual operations? Unfortunately, a lot of times, we aren’t.

Hi, I’m Peter Nichol, Data Science CIO.

Today we’re going to get into the specifics of how to enable those business teams. In my prior article, The disruptive idea of low-code platforms, we covered the benefits of low-code, no-code, and full-code platforms. We also expanded on why no-code solutions are powerful for business users.

Today we’ll explore Smartsheet, a no-code platform, and dig into its advanced functionality. This complex functionality holds enormous potential to empower your business users. I’m also going to introduce you to the more complex integration features of Smartsheet that allow you to educate your business users without enabling shadow IT.

Advanced notifications

Let’s begin with advanced notifications. There are a lot of excellent use cases to be made for utilizing notifications within Smartsheet.

Notifications can be triggered based on events or even by entering specific pieces of data into a sheet. For example, if a sheet’s value is updated, notifications can be automatically generated. Here are a few examples of how notifications can be used in Smartsheet:

  • The completion of development can trigger a notification to QA to begin testing.
  • The failure of an issue can trigger a notification for the development team to retest the issue.
  • Adding a record to the business issues list can trigger notification to the business owner.
  • The completion of a release can trigger notification to the leadership of the accomplishment.
  • Entering value realized can be summarized by a value meter to capture value realized across the department.
  • The entry of a new request can trigger the start of a triage process.
  • Users interested in sensitive issues can be added to watch lists to monitor critical pieces of work.

There are tons of ways to add alerts and notifications into existing Smartsheet functionality by designing new workflows.

For example, emails could be triggered to be sent if a test script failed. The QA tester could be immediately notified that a UAT tester failed a test case. This workflow reduces cycle-time delays, a common occurrence in ineffective business lifecycles. The immediate notification encourages resources to be involved more quickly instead of waiting for a status update that might come hours or even days later.

Powerful analytics

There are also powerful analytics and built-in visualizations that can be provided from the data nested in sheets and reports.

By leveraging sheets and reports and rolling the summary data into dashboards, users can access near-real-time data linked to insights. For example, if the team sets up sheets to capture business issues and has tagged them by category, dashboards can ingest this information and build dynamic charts and graphs based on categorization of the data.

Additionally, it’s possible to generate meeting minutes automatically using Ogilvy. The report builder also enables dynamic and customized reporting.

Workflow and process automation

Next, we have workflows. There are many repeatable business activities that we consider business-as-usual. These processes are often repeatable and consume large amounts of our business users’ time to aggregate data, and it takes hours for business owners to review the summarized information.

Many of these processes are manual and, frankly, inefficient. While these processes are generally technically repeatable, repeating the activity requires a significant amount of institutional knowledge.

To make these processes more efficient, we can introduce automation in the form of dynamic workflows. There are several benefits of automating processes with workflows:

  • More efficient execution of business processes
  • Reduction in repetitive tasks
  • Increased customer engagement
  • Minimized errors

How do you onboard or off-board staff? Your team might have a checklist. Many teams have even documented some parts of the process on Confluence or SharePoint. However, it’s unlikely that it’s fully documented.

These processes are primarily manual and require significant effort to hand-hold resources through the onboarding and off-boarding processes. What if the process was automated? Who from your team would be freed up to work on more value-added activities?

From service-ticket oversight to managing change controls, Smartsheet workflows can help streamline work and make processes repeatable and less prone to omitting critical steps.

There are loads of great uses for process automation that leverage the capabilities of Smartsheet. Here are a few areas in which we can introduce automation into business activities:

  • Collecting invoices and sending them to the appropriate processors
  • Monitoring the payment status of each account
  • Maintaining a general ledger
  • Submitting requests for service
  • Setting up new accounts
  • Issuing change requests
  • Onboarding

RPA flow connects Smartsheet data in UiPath Studio

Smartsheet also has integration with more complex pieces of functionality including robotic process automation (RPA).

UiPath Studio has tightly coupled its core capabilities for automation integration. RPA enables low-code application platforms (LCAPs) to engage individuals who aren’t developers and otherwise wouldn’t help build out the functionality. The new paradigm of low-code opens access for employees (non-developers) to build capabilities that previously would only have been accessible to hard-core developers. Moreover, the simplistic drag-and-drop type interfaces allow non-developers to create powerful capabilities for companies. Imagine if your business users could solve 30% of their challenges independently, allowing developers to focus on building more strategic value-added organizational capabilities?

While the integration of RPA can be on the complex side, once integration is achieved, the upside is enormous. Here are some benefits of using agents to automate processes leveraging Smartsheet functionality:

  • UiPath, an RPA platform, offers an easy-to-use platform
  • RPA enables non-developers to create process automation
  • Building an RPA program is just like drawing a diagram
  • With the CData ODBC Driver for Smartsheet, users can embed Smartsheet data into their workflow
  • Dynamically configure connections
  • Connect RPA utilities to Smartsheet data for automation
  • Create, run, and execute RPA functions (queries)

Future areas to explore

Lastly, I want to introduce three features that are more complicated and will require additional research but are great to add to your tool kit!

The first is Data Uploader. This utility helps centralize disparate data and integrate complicated data sets. Providing visibility requires gaining access to multiple systems to drive collaboration. Enabling efficient work execution is where Data Uploader shines.

The second is DataMesh. This utility provides more advanced lookups across sheets and integrates multi-sets of data. When multiple data sets are being combined, it’s essential to have data consistency. DataMesh helps identify and remove duplicates and supports the creation of links between sheets.

This functionality can be further expanded by creating links based on specific lookup values. If you’ve ever tried to replace values or swap values in blank fields, DataMesh will be a time saver. For example, suppose you have a user’s email address in one sheet and want that data displayed in another report. DataMesh can help populate that information into other sheets while maintaining a single source of truth over the data set.

Third, Control Center is a nice add-on to the core functionality of Smartsheet. This is a portfolio- and project-management solution that offers data consistency with better visibility across projects at scale.

A product you might already own

You might be thinking Smartsheet has potential, but what does it cost? Typically, organizations purchase enterprise licenses that cover their entire company. As a bonus, if your company purchases an enterprise license, the Smartsheet Product Certification is FREE for all enterprise users. This is a great offering, and many business users don’t even know they have free access they can leverage. It’s worth exploring if your company already has an enterprise license, because citizen developers may be interested in being product certified on Smartsheet.

Looking toward the week ahead, ask yourself, “How can I be a better business partner?” Begin by introducing technologies to automate existing manual business processes. Ask the questions others aren’t asking. Stop asking for help and start finding solutions.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

Fund innovation with new techniques to harden your existing contracts

Are you responsible for hiring? Do you hire contractors and consultants? Are you trying to determine how to eke out the best discounts and deals as you bring in new contractors while still maintaining a team of high-quality staff? You’re not alone.

Hi, I’m Peter Nichol, Data Science CIO.

Today we’re going to talk about some techniques for contracting more effectively with your partners and your strategic vendors.

You’ve likely heard about server hardening. This is a set of disciplines and techniques that improves the security of an “off the shelf” product, system or device. Here we’re also talking about hardening, but applying it to contracts. Contract hardening is the process of tightening existing contracts to distribute risk more evenly across all parties in the contract versus an uneven distribution of risk.

I’ll walk through several examples of how to specifically modify contracts to provide a more significant advantage to the organization as you start to grow and expand. I’ll also share some contract-hardening techniques that I’ve recently applied to organizational contracts. You might find them useful as your organization expands.

Rebates or discounts

The rebate is a discount based on net spend. This concept is founded on the principle that as the net volume—or value of executed contracts—increases, the client should receive a discount.

This might initially be a small amount; for example, 1% or 5% of the total contract value. The actual percentage will depend on the vendor’s markup and margins. However, essentially, if you, as a client, spend $1 million versus $5 million versus $10 million, you should get back some percentage of that net spend. Over time, it will add up. At first, 2% might only be $100,000, but it will increase with net spend to $400,000 quickly. When multiplying the rebate percentage times a dozen or more vendors, the rebates add up to millions of dollars avoided.

In addition, this rebate clause allows you to have dollars to reinvest in critical business operations; i.e., innovation or pursuing other enabling technologies that were previously unfunded.

Boomerang clause

The boomerang clause prevents contractors from rejoining the organization at a higher bill rate. Often contractors will be engaged for short durations—six or nine months. On occasion, these contractors will leave the organization for new opportunities. When a new opportunity at your organization looks better than their existing engagement, they’ll be rehired six or nine months later at a higher rate. For example, a contractor might have initially joined the team at $150/hour and was later rehired at $180/hour, or they joined at $100/hour and were rehired at $125/hour. In both cases, the company is paying more for the same resource with the same skills and capabilities.

The intent behind the boomerang clause isn’t to prevent rehiring good staff. The objective is to ensure that just because a new consulting or staffing company represents the consultant, we, as the client, aren’t overpaying for services rendered.

This clause prevents consultants from being rehired within six months at a higher rate. It doesn’t matter who’s representing the consultant or contractor; the rate can’t be increased if it’s within those six months. As a client, we don’t care what the margin or markup on the consultant was or will be with the new vendor. This clause prevents the client from increasing budget forecasting for similar resourcing; e.g., to prevent overbilling a contract.

90-day turnover

The 90-day turnover clause ensures that recruiting companies always place the best candidates at the client site. The idea behind this clause is to incentivize strategic partners to provide the best talent possible.

It’s not uncommon for vendors to feel pressure to place candidates and maintain billing tables. As a result, these vendors suggest and eventually place contractors at client sites that aren’t a great fit. Vendors, of course, want those contractors to bill forever. However, because of executive pressure and how contracts are written, they’re indirectly encouraged to place contractors into organizations where they know the fit isn’t ideal. This results in high turnover in those hard-to-place positions.

Who suffers when contracts don’t last more than six to 12 weeks? We, as the client, do.

There’s usually no negative impact or financial penalties for a recruiting or staffing company placing resources that turn over or leave the company. However, as clients, we’re required to pay for new training and the business impact resulting from gaps in resource coverage.

This clause shifts the burden onto the recruiting company to ensure they place resources they believe are the best fit for the organization. This contract states that if a contractor turns over (leaves for any reason) within the first 90 days, the recruiting company must pay for the transition costs. This transition could be two weeks or four weeks. The client is paid in credit for transition-services penalties. This is commonly a credit for total contractor billing (less expenses) through the first 90 days of service. This clause incentivizes recruiting companies and vendors to provide candidates that meet the qualifications and will be a good fit with the organization—not just a temporary fit.

Right-to-hire

The right-to-hire clause removes unnecessary fees when converting contractors to employees. Typically, contracts have clauses specifying that the client will pay either a one-time payment or a percentage of the annual salary for any contractors hired. That one-time fee might be equal to one year’s salary.

Alternatively, the fee can be a percentage—25% to 40% of base salary is standard industry practice. Generally, this is a reasonable vendor ask. However, when companies are experiencing a period of high growth, these fees become excessive.

With this clause unmodified, every time the client converts a contractor to an employee, the client pays a 25% fee. This fee is typically between $25,000 and $75,000 depending on the base salary of the incoming contractor. The occasional conversion fee is high but digestible. However, once you’re converting 10 to 15 resources a year, these fees become ridiculous. Imagine converting 15 resources and paying $600k in fees.

This clause places a cliff on the right to hire. The amended clause states that any resource engaged for longer than six months will have no conversion fee. If the contract is converted between one month and six months, there’s a declining percentage specified by a rate table. For example, if a resource is converted within one month of engagement, the client pays a 15% conversion fee; however, if the resource is converted after five months of engagement, that fee is 5%. Then, of course, after six months, there’s no conversion fee.

Recovery of assets

The recovery-of-assets clause shifts the responsibility for recovery risk from the client to the vendor. The contractor, at the end of the engagement, will have a laptop and additional peripheral devices such as mice or keyboards that must be returned to the client. As a client, it’s challenging to be responsible for chasing down these individuals to recover our assets. So, who’s in the best position to recover those assets? Of course, the vendor is in the best position because they hold the contractor’s last paycheck.

This clause shifts the burden of responsibility to recover borrowed assets from the client to the vendor. If, by some chance, assets aren’t recovered within 15 or 30 days, there’s a penalty assessed to the vendor.

Contract hardening

To capitalize on the growing purchasing power of expanding organizations, leaders must harden their staff-augmentation contracts and strengthen their contracting language. I’ve identified additional examples—which I’ve implemented across organizations—to decrease liability, reduce risk, and lower the total cost of services.

  1. Client rebates: This provides a rebate of 1% to 5% based on annual services billed less tax and travel.
  2. Boomerang rehire programs: This clause prevents resources from leaving the company and being rehired at elevated rates within six months.
  3. 90-day turnover: This clause transfers vendor financial risk for hired resources that leave before 90 days. In this case, the vendor would pay for the markup over the direct rate to the resource and the cost of transition or a new resource.
  4. Rolling off: This clause provides the company with the right to remove resources without cause. This ensures we have the best and brightest at all times.
  5. Right to hire (temp to perm): Previously, companies paid 25% of the base salary to convert a given resource. This starts the conversation at 15% and moves quickly to a cliff at six months, at which time conversion is free. Additionally, I normally cap the max conversion fee at $30k from a previously unlimited value based on salary.
  6. Insurance requirements expanded: Often master service agreements don’t specify insurance terms. However, terms should be specifically articulated to include dollars of coverage for  general liability, professional liability, umbrella policy, worker’s compensation, and a crime policy shifting risk from the company to the agency.
  7. Recovery of assets: This clause transfers risk to the recruiting agency to recover company assets (laptops, mice, keyboards, etc.) because they’re in a better position given that they hold the final paycheck for the resource.
  8. New rate card: This clause shifts rates from blend or average to a rate card to specifically call out service standards and expectations based on rate tiers. For example, if resources are from Eastern Europe, they’ll have different rates than resources sourced from South America.
  9. Contract structure: This is a general cleaning and removal of duplicate references to the final contract not-to-exceed amounts. Duplications of the contract value create the additional risk of signing an error-ridden contract.
  10. Reporting: This is a clause to add mandatory reporting of resource progress to ensure accountability and delivery of services as expected; i.e., reporting out on SLA, BLA, or quantified objectives.
  11. Public announcements of contract: This clause protects the company’s right to privacy by not publicly announcing the granting of staffing contracts while requiring written permission to use the company brand.
  12. Simplified schedules: This combines the billing schedules for multiple resources; i.e., project manager and business analyst. This unified schedule allows greater flexibility to simplify contract invoice processing.
  13. Fixed hours: Normally, contracts include annual hours estimates; e.g., 2,080 hours and the possibility of allowing for overtime. Alternatively, this clause starts with working hours in the year and then removes holidays and two weeks of forced vacation for contractors to recover and recharge during the year. The result is a much more reasonable number of hours estimated to be billed for the current year.

Take time before you recontract to consider how risk is distributed within your contracts.

  • Are you taking on too much risk?
  • Do vendors have the right incentives to perform?
  • Is there an impact if those performance measures aren’t achieved?
  • Do both parties benefit when growth occurs, and are both vulnerable to a negative impact when contractions occur?
  • Is there reasonable coverage in the event actors work the system?

Consider revisiting existing contracts before blindly resigning to existing terms. By putting in place these contract adjustments, you’ll start to optimize your contracts and change the risk to be weighted in your favor.

Then, as your organization grows, make sure your contracts reflect that additional buying power.

If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

A handy leader’s tool for identifying and developing talent

Are you clear who you’re going to invest more time in this year? Are the top performers evident within your team or department?

Hi, I’m Peter Nichol, Data Science CIO.

If you haven’t already subscribed to my newsletter, please check out it at newsletter.datasciencecio.com. This is where I provide custom content to subscribers for FREE.

Are you a business leader trying to figure out how to define your role? You’re in luck. I’ve just designed a course titled, Define Your Role for BRM Success! In this course, you’ll learn how to define your role in the organization and maximize your effectiveness as a BRM.

Why use the 9 blocker model?

Today, we’re going to get a better understanding of how to evaluate members of your team quickly. You might have heard of the Nine Box Talent Review Model, commonly referred to as “9 blocker” (because the model has nine core blocks) or “9 box matrix.” McKinsey created this model in the 1970s to help GE prioritize investments across its nearly 200 business units. They centered the model around industry attractiveness and competitive strength as their two primary dimensions. Our model is an extension of the McKinsey model with a twist. In our model, we’ll use job potential and job behaviors as our two major dimensions.

So, why is this model helpful? First, it provides a simple framework by which to evaluate team members quickly. Whether they’re high-potential or need some additional help, this model offers an efficient classification. Second, it’s a consistent way to quickly assess how an individual is doing and if you should be investing time in them.

Illustration 1.0 Nine Box Talent Review Model Template

How is the 9 blocker interpreted?

So, how does it work? On the x-axis, we evaluate the team member’s job potential, and on the y-axis, we assess the team member’s job behaviors. In the lower-left quadrant, we classify team members with low potential and poor performance. In the upper right quadrant, we have high-potential and excellent performance. And, of course, the quadrants in between have a myriad of different combinations of those two.

Illustration 2.0 Nine Box Talent Review Model Interpreted

How is this model applied in practice?

Many approaches and techniques leverage the 9-blocker model to evaluate staff. I’ll share my process and the steps behind it.

  1. Identify all employees you want to assess.
  2. Choose two dimensions that best represent your environment.
  3. Classify each team member into one of the nine blocks.
  4. Review to assure that team members are actually in the correct box.
  5. Confirm that the categorization aligns with the preferred investment for each team member.

Identify captures a list of all the team members that you believe are in scope for the assessment. For example, if a new team member joined the team just a week prior, it’s too early to evaluate that individual. You’ll have an opportunity to assess their performance during the next round of performance reviews. Choose is one of the most critical steps. It’s essential to think through what dimensions will best represent your initiative. For example, if you’re targeting talent development, focus on “Talent Development” and “Performance.” There are a lot of dimension permutations when applying this model:

  • Ability and performance
  • Employee potential and performance
  • Leadership potential and performance
  • Engagement and performance

Classify simply slots each team member into one of the blocks based on the two dimensions selected. Review asks the assessor to take another look. Oftentimes, single events tend to cloud judgment or introduce confirmation bias. This step ensures that the complete picture of the team member is considered. Confirm is similar to the Review step. However, in the confirm step, it’s vital to look at your categorization based not only on performance but also on how much you want to invest financially in a team member’s growth.

Illustration 3.0 Nine Box Talent Review Model Example

This model can also be leveraged to classify team members into three main buckets:

  1. Lower left – correct or manage out
  2. Middle – core performers
  3. Upper right – ready for the next-level job

Additionally, it’s easier to see the blocks in three main sections using this model. This approach helps quickly classify a team member as performing or not and then narrows down that individual’s performance within that column:

  1. Far-left column – below performance standards
  2. Middle column – meets performance standards
  3. Far-right column – exceeds performance standards

How to manage training budgets using the 9 box matrix?

You ranked your team. You now have a good idea of how each individual performs and how they perform in comparison to other team members.

We’re already at mid-year. Have you even put a dent in your annual training budget? It gets better. We can use this model and start to evaluate how we’ll invest our annual training dollars. It’s easier than you think to use the 9-blocker model to help predict how training and dollars should be allocated. We spend 90% of our time managing the problems, and 10% of our time managing “the good” as leaders. It’s just the nature of the business that those problems consume the majority of our time, leaving little room for investing in those high-potential employees. Budgets should be divided by the number of members on the team. Why force someone to go to training who has zero interest? Additionally, if you reward that individual with paid training, it reinforces the right behaviors.

Illustration 4.0 Nine Box Talent Review Model For Training Investments

I’d like to share a training guide on how to budget for employee training if you have only $100 to spend. I use $100 because it can be easily converted into a percent. Here’s how it works. Let’s assume that you budget $10,000 for each individual on the team. You have 10 team members, which makes up an annual training budget of $100,000. Do you distribute this evenly, irrespective of performance? No.

The upper-right performance (high potential and excellent behaviors) would earn 100% of that budget—in this case, $10,000. However, a team member that’s in lower-left performance (low potential and poor behaviors) would only earn 5% of that budget or $500. This model aligns with a merit-based performance system for training and investment dollars.

As you move through this year and think about distributing your training budget, consider using a 9 blocker to make that job more manageable. Who are your top performers? Are you taking the time today to invest in those resources?

Leaders often get dragged into the weeds and ultimately spend a lot of time with individuals that, unfortunately, need a lot of help or are underperforming. It’s natural to focus on the problems, as that’s required to keep things running smoothly. However, those high performers need to be coached and guided as well. For example, suppose you want to decrease attrition and increase retention. In that case, you need to have a plan to improve training and provide additional opportunities to people who need to be brought up to average as well as to people who are trying to get to that excellent level.

Here are the images in higher quality for download.

If you found this article helpful, that’s great! Check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

How to lead a passive-aggressive employee

How do you encourage good performance and dissuade bad? Are leaders going through the motions but not embracing the heart of the mission? Are you being misled?

Hi, I’m Peter Nichol, Data Science CIO.

If you haven’t already subscribed to my newsletter, please check it out at newsletter.datasciencecio.com. This is where I provide custom content to subscribers for FREE.

Are you a business leader trying to figure out how to define your role? You’re in luck. I’ve just designed a course titled, Define Your Role for BRM Success! In this course, you’ll learn how to define your role in the organization and maximize your effectiveness as a BRM.

Today we’re going to talk about managing behaviors on your team—specifically, passive-aggressive behavior. Rarely do we, as leaders, have challenges we can’t see or face. If the market is shifting, we can feel small tremors and position our organization ahead of the next rumble. If any individual doesn’t please a key stakeholder, we can offer suggestions to mend that social divide. The challenge with managing passive-aggressive behavior is that it’s primarily intangible. You can’t find it. It’s hard to wrestle. It isn’t easy to nail down the source.

Whether you’ve been around for 30 years or you’re new to the leadership or BRM scene, passive-aggressive behaviors are something we all can brush up on.

Passive-aggressive behavior: the definition

What is passive-aggressive behavior? Passive-aggressive behavior is behavior that’s essentially aggressive behind the scenes. Passive-aggressive behaviors are indirectly aggressive rather than directly aggressive. Individuals that display passive-aggressive behavior obey authority in its presence but are positioned to turn their backs at the first chance.

It wasn’t until 1952, in the first edition of the American Psychiatric Association’s Diagnostic and Statistical Manual of Mental Disorders (DSM), that passive-aggressive behavior was explained in detail. The term was coined by an Army psychiatrist named William Menninger. Following the Second World War, Menninger published a document called Medical 203. This was a major overhaul of the existing US classification of mental disorders, and it was within this document that Menninger spelled out passive-aggressive behavior. It originated from a disturbing pattern among soldiers. These soldiers technically obeyed orders but executed them with subtle disobedience. For example, in some cases, they’d execute the orders to the letter but ignore the spirit of the command entirely.

There’s a good quote that sums up passive-aggressive individuals nicely: “Some people are like clouds—when they’re gone, it’s like a beautiful day!”

Why is diagnosis hard?

The greatest challenge is quiet aggression. Many times, you feel something, but you can’t specify what’s actually occurring that disrupts achieving results.

Complex actions

Often, the actions of passive-aggressive individuals are complicated. Their actions might even appear confusing, as they’re mixed with stress, anxiety, or insecurity in the individual.

Mask behavior

Another reason these behaviors go undetected is that they’re hidden from view. These individuals’ behavior is a way to veil their discontent, hostility, or anger. Because they mask their true feelings, detecting and interpreting the emotions of these individuals can prove challenging for leaders. If you’re not familiar with identifying micro-expressions, you’ll enjoy my article titled, Micro Expressions: The Art of a Lie. This article helps you to determine what to look for in mixed-emotion responses.

Quiet Disobedience

A passive-aggressive individual isn’t going to say they disagree with your strategy. They’ll do the very opposite. Their genuine emotions are suppressed. However, they’ll disagree with you offline by sharing their opinion powerfully with other team members, creating a manufactured situation where you, as a leader, can’t defend and justify your rationale for the given course of action.

Denial

People who engage in passive-aggressive behavior won’t admit anything’s wrong. Have you ever wrapped up a discussion and said, “Does anyone have concerns or questions about what we covered?” Passive-aggressive individuals usually won’t speak up against your strategy. However, once that meeting has wrapped, they’ll relive that discussion and talk to others about how your system doesn’t make sense and why the approaches won’t work. You might think, “I want people to challenge the direction.” That’s a good gut feeling to have. However, in this case, you can’t explain any of those decisions because the individual or individuals are exhibiting this passive-aggressive behavior in the organizational shadows.

Resistance to change

Typically, these folks don’t like any change that might pivot them from being an expert. Often these individuals will blanketly disagree with change—any change—presented to them. This resistance is rooted in an inability to communicate effectively.

How do you spot passive-aggressive behavior in action?

Passive-aggressive behavior slowly erodes team unity and cohesion. These are actions and behaviors that take place quietly when most leaders are unaware. To mitigate or stop passive-aggressive behavior, we first need to be able to identify it.

Exclusion from emails

The act of being left off an email seems innocent enough. On occasion, it’s a simple oversight in judgment that’s never repeated. However, it’s also a prevalent example of someone being passive-aggressive. There was a critical communication that a member of your team sent out, and it wasn’t sent to you. Maybe it’s just an omission. Be a good leader and assume good intent. However, if this happens two or three times, it’s not a simple lapse in judgment. It’s deliberate.

Pushing back on reasonable change

Let’s get real. Almost no one loves to change. So, when you’re getting resistance to change, that makes sense. For example, a new executive was hired to mature departmental processes, and the individual doesn’t feel documentation adds value. This is a classic example of passive-aggressive behavior.

Here are some additional signs to look for that may appear to be omissions but, when they occur together, are more likely deliberate:

  1. Intentional procrastination: pushing off tasks because of other “priority” work that’s never initially identified
  2. Disruptive behavior: voicing their opinion at the wrong time
  3. Blaming others: never accepting their communication could be the source of the issue
  4. Gossiping behind colleagues’ backs: oversharing information
  5. Pushing the demands of others: not communicating to them but rather on behalf of others
  6. Intentional mistakes: scheduling a critical stakeholder meeting before your team meeting
  7. Hostile attitude: isolating from other people because of impatience or stubbornness
  8. Disguising criticism with compliments: offering negative opinions wrapped in positivity
  9. Silent treatment: building a culture of disengagement
  10. Sullen attitude: always finding fault in others for delays
  11. Stubborn: lack of interest in change
  12. Leaving things undone: not finishing assignments before taking a vacation (even if one day)
  13. The indirect request: executing the letter but not the intent of a direction or assignment
  14. Sabotage: rarely overt and often designed to make someone go crazy

The good news is that, over time, passive-aggressive behavior makes its way into the light. I enjoy the following quote from Haruki Murakami: “Sometimes, it’s not the people who change, it’s the mask that falls off.” Eventually, all truth is told.

The delay in recognizing passive-aggressive behavior is what makes it challenging to address. Usually, there are soft signs such as childlike behavior designed to keep you, as a leader, submerged.

How do we get ahead of this behavior?

There are three basic approaches for dealing with passive-aggressive behavior:

  1. Establish team norms
  2. Set standard team principles
  3. Define the standard for good

First, establish team norms that set the behavior guidelines for your team. If you need to, brush up on my article, Why team norms transform team dynamics. It provides a great start. Team norms help the team define what’s acceptable behavior and what isn’t. A few good examples of team norms include:

  • Avoid hidden agendas
  • Listen to understand
  • Provide assurance that issues discussed will be kept in confidence
  • Give your colleagues the benefit of the doubt
  • Respect the time and convenience of others

By defining good behaviors, you help to identify unwelcome behaviors. In essence, you’ve clarified how a high-performing team should be operating.

Second, set standard team principles. These principles establish the guiding framework for the team or department. Sometimes, these principles are defined by the organization or company; you need to generate them other times. Good examples of team principles might include a few of the following:

  • An excellent approach to conflict management
  • Effective allocation of resources
  • Stepping in to help before asked
  • Mutual respect for team members
  • Identifying what unites us
  • Respecting the opinions of others
  • Acting as one team

Third, define the standard for good. How do team members know how to perform if performance standards haven’t been established? Short version: they don’t. There are a lot of ways to tackle defining “good.” Here are a few ideas:

  • Define roles and responsibilities for the team
  • Use a rubric based on job function
  • Develop a standard operating procedure (SOP) for the team
  • Establish objective and critical results incorporated into annual performance

How you define the standard isn’t crucial, but making it clear is vital. Team members must know what behavior and associative performance are encouraged and what performance isn’t. If you have an individual who’s not performing, it’s essential to have a standard to measure their actions, behaviors, and outcomes against.

Taking corrective action

What happens if you find yourself in the position of dealing with a passive-aggressive team member?

You might feel the team is starting to gel. Yet, there are undertones indicating that people disagree with the strategy. However, when you inquire individually, you can’t tell where all the noise originated. The excellent news is that usually this intangible noise is being driven by one or two people creating and reinforcing the negative culture. Make no mistake—they’re sabotaging your strategy and how you’re executing that strategy. Where do you start in taking corrective action?

There’s a three-step process that’s failproof:

  1. Clarify the performance standard
  2. Identify the behavior gaps
  3. Explore corrective action

First, you need to sit down with that individual and have a conversation. Discuss what you expect and what good performance looks like. Second, you need to identify behaviors that don’t align with the team norms, principles, (maybe) competencies, or the standard for good. It needs to be made clear which team norm they violated and what behavior was unacceptable. Third, if, at this point, you’ve not seen significant performance gains, or you’ve been made aware of another occurrence of this behavior, it’s time for corrective action. This means the behavior needs to be formally documented. It doesn’t matter if this is shared with the individual or not. However, the documentation must exist in case this situation continues to surface.

It’s challenging to identify the emergence of negative team aspects when they’re not directly presented to you. For example, if somebody doesn’t attend a meeting on time, the performance gap is apparent. If a team member shows up at 10 am—two hours late for work—that’s obviously a performance gap. When a deliverable is delivered two days late, we can immediately explain the performance expected and what was achieved. In each of these examples, it’s obvious what happened. How to correct that behavior is also straightforward.

With leadership, situations are rarely just black and white. What do you do when the team just isn’t working well together? Where do you look when your approach isn’t realizing its goals? Passive-aggressive behavior is subtle. Acts of sabotage or quietly challenging authority don’t occur in the daylight.

Hopefully, this article provides some practical tips on how to get ahead of managing passive-aggressive employees. Here are a few templates to help document your conversation with team members exhibiting passive-aggressive behavior.

If you found this article helpful, that’s great! Check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!

Hi, I’m Peter Nichol, Data Science CIO. Have a great day!

https://youtu.be/ckr5-CPbZ8c