What is Tech Debt and why you need to pay it down

As an executive, you know to keep a close eye on company finances, including whether, when and how much debt the company can handle yet remain fiscally healthy.

Unfortunately, most businesses do not track tech debt and the negative impacts it has to their business. As a result – many businesses make the mistake of believing that managing their technical debt is a simple matter of good housekeeping – a “keep the lights on” operation isolated to their IT departments.

Nothing could be further from the truth.

Technical debt is anything and everything that slows down or hinders development.

Hindered development will lead to problem that cascade through entire company while it slows down improvements in every part of the business with a stake in that development. This often means the *entire* company. Tech debt will delay the delivery of all new features.

That’s not the worst of it.

Like other kinds of debt, tech debt accrues interest and the problems it causes compound over time. It’s like a tax that’s added to everything. Companies with an unacceptable level of tech debt pay the price with slower time to market, bloated production costs, higher IT support costs, and a high level of complexity that draws IT’s time away from more transformative work. Companies with a lot of tech debt also experience high churn rates among its developers, who face frustrating limits on the work they can do because of that tech debt.

Such companies often add more developers, erroneously thinking that if they just turn out more code, they can keep pace with the new features and functions they need to compete. Or they spend increasing amounts of time and IT budget in a game of Whack-A-Mole as they try to fix all the problems that keep popping up.

To help explain the issue, we sometimes equate tech debt to old factory equipment with broken bits that aren’t ever replaced. The factory owner can add more workers to the production line and tack on more pieces to the equipment, but neither approach fixes the underlying mechanical problems. Neither approach makes the equipment run right, and neither will help the factory produce more or better widgets. Ultimately, the only way to make that factory efficient and agile is to fix the broken parts.

It’s the same with technical debt.

But here’s the other challenge with technical debt: In most organizations, it’s something that’s invisible, unmeasured and unquantified. As a result, it typically remains unaddressed.

In fact, most organizations don’t have the slightest idea how much debt they carry. That’s why both young and old companies can see product and engineering costs way above what’s optimal: They have more technical debt than they even know.

As an executive, you may think it’s time to clear the technical books and get rid of all the tech debt that exists within your company. That, though, isn’t the goal. The reality is that there’s always going to be some amount of it.

Instead, here at Strive, we recommend that you tackle the problem by first understanding how much tech debt you have and then whether it’s an acceptable amount or whether it’s so much it’s slowing you down.

Tech debt fits into the overall methodologies to invest in and borrow against in order to be agile and move quickly. We’ve been developing the complex model to quantify tech debt. This allows us to identify and measure its financial impact, considering opportunities that get taken off the table and business risks introduced due to that debt

This approach helps everyone on the executive team and the board understand the importance of paying down its technical debt.

In addition to offering this standardized model for assessing and measuring the ongoing cost of technical debt, we advise clients on ways to pay down that debt and how to design, build and implement debt-free alternatives moving forward.

We know this approach is effective. We worked with one client, a services company, to measure its tech debt and quantify how it was impacting its agility. Executives there were able to see how resolving software bugs and other problems in existing code would unblock product teams and make them both faster and more responsive to evolving market needs. So instead of accumulating more debt, they actually saw better returns.

Companies that have paid down their tech debt and now have a good credit score are well positioned to compete against any upstarts that enter their market. They also require fewer resources to produce superior outcomes and to produce them quickly.

That’s a message the board and your shareholders will want to act on – especially now, as companies increasingly feel the pressure to be as efficient as possible in the face of a constricting economy.

Do you have Tech Debt?

Here at Strive, we take pride in our Technology Enablement practice, where we can assist you in understanding and mitigating your organizations tech debt. Our subject matter experts team up with you to understand your core business needs, while taking a deeper dive into your organization’s growth strategy. Click to learn more about our Technology Enablement capabilities and how we can help.

What is the Spatial Web and why should your company care?

First things first. What is the Spatial Web?    

Technically it is a three-dimensional computing environment that can seamlessly combine layers of information gathered from countless geo-located connected devices to create seamless immersive experiences. If that sounds a lot like the Metaverse, you’re right. The two terms are often used interchangeably. However, I prefer to use the name Spatial Web instead of Metaverse, believing the former is both more accurate and descriptive.  

Whichever term you use, the best way to understand it is to experience it. The good news is you can do that right now with your smartphone!  

Head outside for a short walk using Google Maps with Live View enabled. What you will see is an Augmented Reality (AR) view of your walking path. The traditional map view will be on the bottom the screen, and the main screen area is using the camera and placing icons and directional information intelligently on top of the real-world camera view.   

This is the Spatial Web! It’s cool on the smartphone, but imagine if all sunglasses magically projected this as a layer and you did not have to hold the phone at arm’s length as you walk. This is a great way to start imagining what the Spatial Web will be in the near future as new devices seamlessly integrate into our lives. 

Ok, so why should your company care? 

The Spatial Web is coming. There’s no question about that. In fact, many of the component elements such as AR, VR, and the Internet of Things are already in use across multiple sectors. 

The gaming industry and the entertainment sector are the most visible leaders in harnessing the Spatial Web. And Facebook (now Meta) has become, perhaps, the most well-known proponent of it. 

But forward-thinking organizations in many other industries are piloting Spatial Web projects that demonstrate the expanse of potential use cases. 

There are good reasons for pursuing those use cases, too, with pilots already delivering benefits and good returns on investments. 

Let’s take an example where a complex critical system is down, say a Wind Turbine, and a mechanic working on it. The mechanic could use AR-enabled goggles to pull up instructions to guide on-site repairs. Or that mechanic could use the goggles to see design schematics that, using artificial intelligence programs, help pinpoint problems. The mechanic could also use those AR-enabled and internet-connected goggles to collaborate with an engineer from the manufacturer, with the engineer being able to see in real-time exactly what the mechanic sees and does on the machine. 

Such capabilities are already here and improving all the time, giving us a glimpse of what’s on the horizon.  

So, what’s ahead? A future where the Spatial Web will simply be part of how we live, work and engage. 

When that day arrives, these metaverse-type technologies will feel like an extension of yourself, just as smartphones have become ever-present ubiquitous tools that constantly inform, guide and connect us.  

And when that time comes, seeing someone wearing smart glasses will be the norm, not the exception. 

The timeline for that future state is years away. Gartner, a tech research firm, has predicted that widescale adoption of metaverse technologies is a decade away

There are, for sure, technical hurdles that need to be overcome on this Spatial Web journey. 

There have been concerns, for example, about the heat generated from the compute processing in smart glasses, the battery life in connected devices and the vertigo some suffer when using virtual reality. 

But tech companies are working on those issues, and it’s only a matter of time before they have them worked out. After all, they have the incentive to do so as there’s existing market demand for these technologies. 

And we’re already seeing tech companies deliver big advances. They are developing audio technologies to ensure immersive audio experiences. They’re maturing haptic technology, or 3D touch, so you’ll be able to actually feel those actions happening in a virtual world. Some companies are trying to do the same thing with smell. 

These technologies will work with existing ones, such as geolocational tech, sensors, artificial intelligence, 5G and eventually 6G, to instantaneously deliver layers of information to users. 

While a fully-realized Spatial Web is still years away, you shouldn’t wait to start making plans for how you will harness its potential; you can’t wait to think about your strategy until everybody starts buying connected glasses. 

If you do, then you’ll already be behind. And if you wait too long, you’ll miss out. 

The reality today, right now, is that you will have to respond to the Spatial Web as it evolves and as it delivers new ways for organizations and individuals to interact. 

This new technology-driven realm will enable increasingly frictionless services to consumers, seamless B-to-B services and new potential applications that some are already starting to imagine. 

Here at Strive, we are exploring the component technologies that collectively make up the emerging Spatial Web. 

And we’re partnering with clients to envision their Spatial Web strategies, outline the infrastructure and skills they’ll need, and devise the optimal business cases to pursue – all so they’re ready to move as the technologies mature and the Spatial Web moves into the mainstream.

Connect with Strive! 

Here at Strive Consulting, our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your organization’s growth strategy. Whether you’re interested in the Spatial Web or an overall Technology Enablement assessment, Strive Consulting is dedicated to being your partner, committed to success.  

Contact Us


Migration to the Cloud Needs Experienced Help

Executives are already sold on the benefits of moving to the cloud. They know that they need cloud computing to be agile, fast, and flexible; they know cloud allows them to successfully compete in this digital era.

Yet, many enterprise leaders struggle to advance their cloud strategies, with plenty of companies still working to migrate away from on-premise applications and out of their own data centers.

Here at Strive Consulting, we aren’t surprised by such reports: We know that cloud migration comes with numerous significant challenges…. and research backs that up.

Consider the figures from the 2022 State of the Cloud Report from the software company Flexera.

It found that understanding application dependencies is the no. 1 challenge to cloud migrations, with 53% of respondents listing this as a pain point.

Other top challenges include assessing technical feasibility, assessing on-premise vs. cloud costs, right-sizing/selecting best instance, selecting the right cloud provider, and prioritizing the applications to migrate.

Such challenges deter and derail many cloud migration plans.

Many companies don’t have the technical skills they need to address those specific challenges to move their cloud strategies forward, as their staff has, understandably, been trained and focused on supporting their on-premise and legacy systems.

On a similar note, organizations don’t have in-house workers with the experience required to analyze and assess all the available cloud options and to select the best architecture for current and future needs.

As a result, companies slow-walk – or outright put off – their cloud migrations. Or they move forward as best they can, only to realize that they need to redo their work when their new cloud infrastructure fails to yield the financial or transformational benefits they expected.

Those scenarios demonstrate why companies need an experienced hand when they migrate to the cloud and why they need people who can advise them on the right architecture for their own specific environment and their industry’s unique needs.

At Strive, we understand the myriad cloud options – from serverless, containers and virtual machines to infrastructure-as-a-service, platform-as-a-service, and software-as-a-service. We understand the nuances and requirements associated with each choice, the strategic reasons that would make one better than another, how they work together, and the supporting pieces needed to optimize each one’s performance.

Take virtual machines, for example. Going that route requires the creation of automation scripts to spin up and turn off based on use. Companies without much experience or expertise in virtual machines may overlook this critical component and, thus, end up with infrastructure that doesn’t deliver on its objectives.

Companies find that this is often the case, particularly when they’re embarking on their own.

In fact, selecting the wrong cloud option and implementing suboptimal cloud infrastructure are two of the leading reasons for poor outcomes and failed initiatives.

When we partner with companies to advance their cloud adoption, we start by understanding their own unique environment, their enterprise needs, and any industry-specific requirements that could impact their choices around cloud.

We work with our clients to determine whether, for example, they want to modernize by re-architecting their systems and using platform-as-a-service.

Whether the right move is shifting everything as is to the cloud.

Whether going with IaaS or SaaS provides the features, functions, and cost benefits they’re looking for.

Whether and when to go with hybrid, multi-cloud, multitenant, private, or public cloud.

Or whether it’s better to go the serverless route, leveraging features like containers, so they’re not paying for consumption when apps aren’t in use.

We help clients understand the financial implications of their cloud strategy decisions, and we build monitoring tools to track both performance and consumption, so they can detail what they’re using and how much that usage costs. We know from experience that finance departments are particularly interested in that information. But we also see how it benefits IT leaders, who want to allow their developers the freedom to innovate, but still want visibility into the resources being used and at what cost.

We also know from experience the importance of building a cloud environment that’s both secure and scalable, with automation in place to build that infrastructure over and over so organizations can easily build up and tear down as often as needed.

Furthermore, we advise companies on the change management that’s required to successfully migrate to the cloud. As such, we work with developers and engineers to understand new processes and to support them as they develop the expertise they’ll need to maintain, manage, and eventually mature an organizations cloud strategy.

There’s one more point I want to address: Strive knows that a cloud migration plan is not just about technology, that it’s also – and, in fact, more so – about what the technology can do for the business.

The right cloud environment enables companies to pivot quickly. Companies can rapidly and cost effectively create or adopt new functions or test and tweak proof of concepts because they can spin up and wind down computing resources.

All of this enables faster time to market with products and services and an overall more responsive organization.

Our experienced teams help clients achieve that kind of transformation by helping them design and implement the right cloud infrastructure to support those bigger objectives.

Thinking about Migrating to the Cloud? Strive can help!

We take pride in our Technology Enablement practice, where we can assist your organization with all of your cloud enablement needs. Our subject matter experts team up with you to understand your core business needs, while taking a deeper dive into Platform Assessment, Platform Migration, and even Platform Modernization.

Contact Us

The Importance of Design Language Systems and Auto Layout

Most of us know Design Language Systems (DLS) as a collection of tech used to build apps for Android, iOS, or Salesforce. It’s the catalog of components where we get the iOS drawer, android buttons, salesforce cards, etc. However, too few of us have thought about how we can create engaging and efficient DLS for our clients. Tackling problems like the evolution of a catalog of components to a DLS that has efficiencies built in could speed up design process, cut down on redundancies, and provide value impact to organizations and designers alike.

In addition to creating DLS components, designers should also look into incorporating Figma’s Auto Layout components as an easy way to maintain alignment as components change size. Building Auto Layout into DLS cuts production time in half and yields high-fidelity mockups. Strive’s Technology Enablement experts and team of UX/UI designers come in doing just that, spending less time on production work and more time problem solving. Remember, the more time designers spend designing mockups, the more money and resources companies are paying.

Greater speed also means having the ability to quickly adjust to new requirements or iterating based on feedback. These changes are usually setbacks, not just for the designer, but for developers and other downstream teammates that depend on the mockups.

Lets take a look at how DLS + Auto Layout can speed up your design process:

Design Language Systems

How many times have you had to take out a component and then detach it, resize it, and then measure it to make sure it fits the grid? For those that don’t have a DLS at all, it’s even more nuanced. So, instead of doing either, we simply click on the text ‘label’ and type in the new label, ‘addresses’. Thanks to Auto Layout, the component resizes to fit the bigger text.

Design Language System

What if we want to change the state to make it look like ‘addresses’ has been selected? Well, with a set of prebuilt components, we can easily swap the unhighlighted, default navigation bar with the highlighted version. Note that even with swapping the components, the Auto Layout ensures that the text, padding, position, styling etc. are kept intact.

The next four GIF’s are an example of true time saving potential and how Strive partners with our clients to provide value.

Design Language Systems

Design Language Systems

Design Language SystemsDesign Language Systems

Design Language SystemsDesign Language Systems

If you work with data-heavy applications, you’re used to the extraneous work that revolves around creating or updating tables. Generally, this means resizing, measuring, and aligning every column, just to update a single table! Not to mention dealing with tables that are particularly long and take hours of your time. Instead, Strive has developed a component that allows designers to simply bring a table component out, edit a column to fit the styling using switches, and then copy & paste to create a table. In some of our even more advanced tables, we have developed columns where placeholders like currency, data, etc. has been prefilled.

It took us less than a minute to create… Can your DLS do that?

Interested in learning more?

Here at Strive, we take pride in our Technology Enablement practice, where we can assist you in your UX/UI needs. Our subject matter experts team up with you to understand your core business needs, while taking a deeper dive into your organization’s growth strategy. Click to learn more about our digital experience capabilities and how we can help.

Authored by Strive Technology Enablement Practice

Practical Microservices: User Authentication

Unless you’re explicitly in the identity management or security industry – you probably shouldn’t bother building your own user management tools.

We’ve seen a growing interest in microservice architecture from our clients over the past few years. Likewise, we find ourselves recommending a microservice approach for an ever expanding list of categories. Seeing this shift as an opportunity, a number of products and services have emerged that seek to bootstrap development in a microservice context.

The benefits of a microservice approach are myriad. Today, I’d like to talk about one of those benefits that product managers ought to consider – the flexibility to let third-party services fill in your requirements. We’ll examine a typical development roadmap for user management support and compare that to using a services such as Okta or Auth0 to fill those needs.

Common Requirements

Let’s say you’re the product owner tasked with planning the roadmap for a new product. As usual, a user management feature is among the epics. For a fairly straightforward user management workflow, your team might be given base requirements approximately along these lines.

  • Safely store and manage a list of users.
  • Ability to manage, edit and admin that user list.
  • Access control and/or user roles.
  • Secure method for storing password data.
  • Reliable method of generating new passwords.
  • Enforcement of password complexity rules.
  • Credential reset workflow via email / SMS / push notifications.
  • Regulatory compliance (HIPAA, KYC)
  • Login forms / Authentication workflows
  • SSO not included (budget)
  • 2FA not included (budget)

Some Shaky Deliverables

Experienced scrum master or product owner may already be feeling uneasy. Here we have a set of base requirements that – depending on team size and capability – can eat up large portions of your timeline. What may have felt like a simple ask becomes weeks or months of work. If all goes well, you are left with these burdens:

  • Security and maintenance overhead for all of the above.
  • Liability for all of the above, potential civil/legal liability. 
  • Repetitional and fiduciary  risks from all of the above.
  • Limited ability to evaluate actuary risk from the above.
  • Inconsistent user experience. 
  • Lower conversion rates as a result.
  • Increased developer costs.

Oh, and don’t forget that users need to learn the nuance of your system… and that’s a great way to shed users before they ever become active.

Tweet from @_jayphelps: "It should be illegal to prevent pasting into a password input field."
Don’t set yourself up for this kind of user feedback.

A Practical Alternative

Unless you’re explicitly in the identity management or security industry – or your application architecture prohibits it – you probably shouldn’t be building your own user management tools. As I mentioned at the top; it might better to forego all of this and instead implement a low-code solution from a third party.

Enter Auth0

In March of 2021, Okta announced they would acquire Auth0 for $6.5 billion – expanding their suite of enterprise identity tools. At its core, Auth0 calls itself “a user authentication and authorization platform”. They provide an extensive set of functionality that allows you to integrate with hundreds of identity and access management providers. What’s more, Auth0 offers an excellent set of SDKs developer APIs which make integrating all these features into your app dead simple.

“Simple documentation about how to integrate – 15-minutes and we were up and running with a proof of concept.”

It’s true, I can testify from personal experience. When I first tried working with Auth0 – I was able to establish a new account, skim the documentation, integrate with Strive’s internal directory and implement full user support in a React application without breaking a sweat. It was just as straightforward to do this in iOS with Swift and in Spring Boot. In just an afternoon I was able to put together prototypes on all three of these platforms.

Just think about that for a moment. There’s a version of this timeline where an entire scrum team takes multiple sprints to implement user management for a single platform. With Auth0 it took about 45 minutes!

Building A Business Cases

At this point, you may already have a clear picture of the business case for using a provider like Auth0 rather than rolling your own user management. We understand that it can be difficult to gain support from fellow stakeholders for even the strongest ideas. With that in mind, here are a few bullet points you can steal:

  • Faster time to market
  • Reduced cost of development
  • Reduced complexity of development
  • Reduced fixed operating overhead
  • Reduced likelihood of defects / liability therein
  • Increased user registration / conversion

Wrapping Up

Ultimately this is about creating as much value as possible from limited resources. Engineering work is expensive, and developers are a finite resource. Since software companies often live and die by the efficacy of their developers, it’s critical that you allocate their efforts effectively.

Based on decades of combined experience while serving startups, Fortune 500 and everywhere in between. Generally, Strive believes that user authentication is a solved problem. Rather than dedicate resources to re-solve it, we find that it’s often wisest to instead stand on the shoulders of giants.

Further Reading


Emphasizing the U in UX

Whenever reviewing the current state of a system, it’s important to ask, “what is the UX (User Experience)?” Although a vague question, or almost naïve, the answer should provide a good perspective into whether the experience is focused on helping a user complete tasks or is focused on building out a system to complete tasks. Albeit small, there is a difference in the two and it is worth paying attention to! Helping a user complete tasks show investment towards their job and makes it easier for them to complete, while building out a system creates an application to do a job, and typically adds to a person’s daily responsibilities.

Sometimes it is best to create systems, taking into consideration organizational priorities like budget and time resources, but there is always a case to be made that focusing on the user provides internal value and ease of use with minimal effort.

So, where to start? How do you start shifting focus from the system to the user? How can you emphasize the U in UX? To start building a solution that caters to your user, it helps to break down the process into 3 components: The Users, The Job, and The Solution.

The User

Organizations need to identify the users, so they can successfully cater to their needs. This identification is critical in creating a persona – defined as “a representation of the goals and behavior of a hypothesized group of uses.” 1 We group users into personas to avoid generalizing the need of a feature for a broader group. If you were to create a persona for a web application, you might think customers or administrators, but what about sales, customer reps, account reps, or even IT support? Each user persona has a specific need from the system, and a great UX starts with identifying each one and understanding the needs and their ability to perform their job functions.

In large systems, there will be a lot of personas to develop. There’s a mixture of surveys, observations, and interviews to conduct and there is the analysis on that data to determine a final persona list. Remember, this list should also evolve as your organization and people evolve.

The Job

Now that the data has been gathered around the users, one of the additional outputs may be their job functions. Not all job functions are relevant to the UX, but it is helpful to understand what a ‘day in the life’ looks like for some of the personas. Particularly, where along their day do they interact, or have the potential to interact, with technology. This is more of an art than a defined process, as not everything should be solved with a technical solution. The output at this stage should be creating a user workflow, which can be tied back to a job function. When mapping this flow out, you can determine the areas which are prime for optimization. Typically, it helps if organizations speak to users and identify the pain points which must be focused on.

Optimization of workflows involve removing steps, which can allow a user to move faster with tweaks to their workflow. Sometimes this means removing the step entirely and replacing it with a feature within an application. It can also be as simple as refining the application workflow, so that a few steps can be done concurrently or automatically. At the end of this, we’ve created potential workflows which will improve how the users do their job.

The Solution

Finally, we’ve arrived at the solutioning stage, which is typically an easier phase of the process, with determining the users and identifying their workflow pain points taking up most of the effort. Now organizations can start designing new processes, which could include building or buying software.

Most importantly, we’ve reached the solution stage by focusing on the user of the system, instead of the system as a whole. We took the time to learn about user needs and job functions and understood how those job functions could be improved. You also learned that there is more than one persona working with a system and that persona should be included in the design of an optimized process. Here at Strive, we take pride in our Technology Enablement practice, where we can assist you in your UX/UI needs. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your organization’s growth strategy.

Preparing Your Digital Product Teams for the Hybrid Workplace

Like it or not, the hybrid workplace is likely the new normal for companies. Numerous articles have been written on the topic of people and culture management in this operating model, along with their benefits and challenges.

Most of the articles focus on the individual impacts to workers and the larger impacts to business that this shift will make.  What I’d like to focus on are the impacts I’ve seen this shift make to teams, particularly the ones responsible for delivering digital products to customers.

The challenge (and subsequent opportunity) to this dynamic revolves around the limited amount of natural human interaction that occurs to collaborate on solving problems. I call this dynamic “water coolers and delivery heroes (WC/DH)”. It’s when your delivery heroes have impromptu interactions with key team members and stakeholders to figure out a way to move forward through problems…it’s why job descriptions include language like: “must be able to work in complex environments and influence/collaborate with key stakeholders across multiple areas”… that’s code for “need people who can figure things out as a team and execute”. These interactions happen regularly and naturally when everyone is under one roof, but these blockers tend to become more problematic when handled in a hybrid model.

There are two types of problems the WC/DH dynamic typically addresses: novel and systemic.

The novel problems are the ones you want your delivery heroes working on. They are the ones they want to work on. They are the interesting, and often high-value, problems where they should focus their time. They will find a way to address these in any work environment.

It’s the systemic problems that need more attention: “It’s not the mountain to climb that exhausts you. It’s the pebble in your shoe.”

The systemic problems are the avoidable, yet all too common, shoe pebbles. You might be surprised how much time your delivery heroes spend on those, as opposed to climbing novel mountains. It’s our job as delivery leaders to improve our systems and processes to proactively remove these nagging blockers to keep our valuable resources working on valuable problems. It was important before, but it’s imperative in a hybrid model.

Here are some common systemic problems to explore:

Poor Enterprise Technology Standards, Design Patterns, and Conventions

Delivery heroes are mentors to junior and mid-level teammates. When there’s uncertainty around how to move forward with a technical solution, instead of being paralyzed with how to move forward, they turn to their respected voice of experience for guidance.

I actually often find that delivery heroes enjoy these activities, so the shoe pebble metaphor doesn’t exactly fit. But it is a hindrance to the team’s ability to performance and scale in a hybrid model when the same lessons need to be re-taught over and over.

Mitigating Strategy: Document and govern architecture, design, and solutioning standards. There should be a living repository of standards, patterns, and reference implementations. It should be the first source of information when a delivery resource is blocked. It should be the standard for code quality at scale.

Murky Story Requirements

How much times does your delivery team spend chasing down requirements or understanding an unclear backlog? I was on a project with a large financial institution where the team re-wrote features several times over before they were given clarity on the actual intent of the requirements. This would happen repeatedly causing delays in production code and delivery team frustration.

After some time, the delivery hero gained a sense of how to interpret what was being requested versus what the business stakeholders actually wanted. This resulted in a boost in efficiency until this person found a new job that did not require large time investments as a requirements interpreter.

This is a difficult ask when sharing space with the relevant stakeholders. It becomes untenable in a hybrid environment.

Mitigating Strategy: Hold your user story and backlog quality to the highest possible standards and rigor. Get feedback and constantly retro how well the requirements are understood by the delivery team. Your delivery heroes aren’t going to be as accessible as they once were.

No Buried Bodies

How many times have we heard that expression? “We can’t lose X. She knows where the bodies are buried.”It reveals a fragility to the delivery process and development environment. Often, the symptom is the reliance on someone’s institutional knowledge in order for a larger system to operate. There have been a number of times I’ve been asked to come in and evaluate a process because someone was nearing the retirement age. Not a great place for a company to be. This becomes more problematic when the physical proximity isn’t there anymore. There’s too much at risk with people who are no longer enabled because they don’t have physical access to a person who holds the key to a manual process.

This person spends way too much time “pushing buttons”. In a hybrid world, this gets even slower and backs up all of the people dependent on the pushed button to do work.

Mitigating Strategy: Automate where you can. Understand areas that are manual dependencies to driving a process and invest in automation. Rule of thumb: if it needs to be done more than twice, or is a critical dependency for others, invest in automating it.

In Conclusion

The global pandemic and resultant cultural shift in workplace dynamics to a hybrid model has introduced challenges to effective digital delivery. Relying on delivery heroes to save the day becomes less tenable without the benefit of physical proximity.

The good news is that once the crutch of these key resources has been removed, it starts to surface process issues that were likely masked by their presence. It’s painful now, but addressing these issues will improve your company’s ability to deliver quality digital products to your customer in a more scaled and dependable fashion.

Document, train, and automate your processes to enable your delivery teams and free your delivery heroes to work on high-value problems that are deserving of their focus.

But I Need Help Now!

Ok – I get it. These recommendations require investments in time, money, and effort. The improvements will be slow and costly at first. But if delivering quality digital product value to your customers is important to your business, these investments will pay off in the long-term – but here’s something you can do in the short-term: Create A Virtual Water Cooler.

I’ve seen success where key delivery heroes open up a virtual gathering place or office hours to invite other team members to ask questions of the delivery hero, anyone else in the room, or just hangout to be closer to the group. People can come and go as they please, but the idea is that it is a virtual collaboration space.

It won’t scale or be a long-term solve, but it’s not a bad intermediate best practice to keep the train rolling.

Are Your Project Managers Prepared for the Cloud?

The previous year has brought about new changes to many work environments, while accelerating other planned changes such as Cloud deployments. According to the July 2020 Forbes article “Why Enterprises Are Accelerating Cloud Adoption: The swift move to working remotely has meant a spike in the number of companies moving to the Cloud.”, companies like Microsoft and AWS have shown significant increases in their Cloud products in recent months. Consequently, more and more projects will be green-lighted to move systems to the Cloud, which increases the need for Project Managers who understand the unique challenges such projects require. Organizations need to ask themselves…are your Project Managers prepared?

Vendor Management Experience

Cloud projects are inherently different than onsite projects that use local and internal resources. Organizations are now managing systems through remote, third parties, so strong vendor management skills are a must for Project Managers. Instead of resources that are dedicated to the company, Cloud resources serve another master. Project Managers need to ensure the Cloud vendor understands the company’s needs and priorities. Stakeholder desired timelines should be reviewed with the vendor to identify any concerns with any challenges addressed early in the project.

Additionally, the Project Manager needs to identify any processes or restrictions varying vendors may have, such as lead time for equipment delivery or holiday freezes. The Cloud vendor standards will drive most of the processes and need to be clearly understood. For example, if a vendor only does quarterly releases for all clients, then a planned delivery date outside of these standards cannot happen. Flexibility for delivery dates will be more limited in the Cloud, so all parties need to understand expectations.

Deeper Software Understanding

Companies have been installing software onsite for years and have become accustomed to making software adjustments to fit very specific needs. When companies select shared Cloud environments to assist with budget restrictions, this flexibility can be greatly reduced. A Project Manager should ensure restrictions are clearly understood or delivery can be disappointing.

A good example is how sign-on’s are managed. Can single sign-on (SSO) be used? If possible, what exactly does that mean? If a software can maintain data from multiple customers of a company, does a corporate resource have to have multiple logins to access each different customer data set or can they access all via single log-in? If able to access via a single login, does that mean customers could potentially see each other?

Do not assume the answers to the questions. In a previous project, this exact scenario occurred. The Cloud vendor said SSO was possible. Internal resources managed many different clients. When the situation was drilled into, clients were able to see each other via a pop-up menu. The onsite version of the software had the capability to block this view, but the Cloud version did not because a software change would impact all clients of the vendor. The only way to prevent the viewing was for each client to be in another “Cloud instance” that further required a separate login for each client. That meant the internal resource needed a different log-in for each supported client. Does that sound like traditional SSO? No, but from the vendor’s side, it was possible as a pass-off from the company to the vendor, but using the SSO, would have created an insurmountable issue.

Gap Analysis Skills

Many companies choose Cloud offerings to allow for focus on core capabilities. Moving hosting and release management to a vendor can provide significant cost benefits. This often means that companies decide to transition on-site versions of software to the Cloud. The challenge is, even when the software is moving to the Cloud version of itself, there is often a gap. These versions differ for various reasons. One of the most common is they are constructed separately. One version is created for flexibility onsite and based on a single company’s requirements. The other is developed to work with multiple companies in a shared infrastructure. Although the product is the same brand, the software codes are developed separately. These differences are usually discussed at a high-level during sales meetings, but when the project kicks-off, the Project Manager and team need to understand differences at a detailed level. Understanding differences in menus or terminology, as well as infrastructure and outputs.

A good example is how is data handled? When moving programs to the Cloud there is almost always data that must be moved for historic reasons. A Project Manager should not assume it is a one-to-one transfer. It is not unusual for two programs to be developed in totally different teams who may never talk to each other. Knowing that data mapping is critical to the success of any Cloud product, some vendors will provide processes for easy transfer if the data infrastructure is different, but others will place that work on the client. Clarification on these types of organizational pitfalls is crucial before kick-off or before schedule baselining.

The skills above are a good start to identifying stronger Project Management skills needed for Cloud environment projects. Overall, when running Cloud projects, Project Managers need to increase diligence in several areas to ensure quality performance as more and more projects will involve Cloud implementations. Strive prides themselves on not only excellent project management experience, but first-hand knowledge when it comes to Cloud adoption and enablement. With our successful and extensive channel partner relationships, with companies like Microsoft and Snowflake, and our robust in-house Management Consulting and Technology Enablement practice areas, our subject matter experts make navigating the Cloud easier and more efficient.

Continuous Integration and Continuous Delivery (CI/CD): Delivering High Quality Software to Your Customers Quickly

Prior to COVID, consumers had already been relentlessly engaging with brands through digital platforms, products, and services. The abrupt change that came as a result of early lockdowns, and then continued (physical) social distancing during the past nine months, have dramatically accelerated the shift to interacting with friends, colleagues, and brands through digital interfaces. This, along with the continuing evolution of customer expectations has made it even more imperative to deliver new experiences and products even more quickly while maintaining both high quality interactions and software in general. It is crucial for companies to develop software at a rapid pace that can immediately run effectively and generate value to adhere to market demands.

Companies of all industries varying from retail to financial services have incorporated software as a means of interacting with their clients or customers through digital products and services. Whether an organization has a website, mobile application, or full-blown digital products, it is vital for the company to provide their consumers with a compelling user experience that ultimately adds value to both the consumer and the company.  With the market demands today, developers need to be capable of building software quickly to both introduce and test new products and enhance existing products, services, and applications. DevOps paved the way for these capabilities by allowing for infrastructure and operations to be delivered as code as opposed to hardware, thus significantly shortening the lifecycle from idea to consumable product. However, while DevOps is foundational, it alone doesn’t allow for the speed to market necessitated by today’s landscape – this is where CI/CD comes into play.

Continuous Integration and Continuous Delivery (CI/CD) is a practice that makes it possible for companies to drastically improve their software development lifecycle to meet the demands of consumers. A CI/CD pipeline builds upon agile framework and DevOps concepts, where organizations can automate many steps within the software development process to more quickly build, test, and deploy new code to customers. CI and CD are both development approaches that are usually executed in sequence – however, these practices have differentiating purposes.

Continuous Integration

Continuous Integration (CI) is the practice of development teams combining their code and submitting it into a repository; this usually occurs multiple times a day. In this process, developers run automated tests to detect any issues immediately upon each potential code change. Conducting tests at this point prior to integration of code allows for early detection and resolution of bugs and programmatically not allowing that code into higher risk environments without the bug being resolved – ultimately, saving the company time and money by identifying and resolving conflicts before any further developments are made to the software.

Continuous Delivery

Continuous Delivery is a continuation of CI that extends the automation process to more effectively deploy software. With the CD approach, product and development teams have the ability to more quickly adjust software as user feedback is generated or as the business strategy evolves. Various functions across an organization including product, development, support, testing, and operations collaborate throughout the software development lifecycle to make improvements to the end-product. The collaboration between these individuals allows for more consistency in updates to a product that are not only operational but also effective. This practice allows for organizations to rapidly release any changes and updates to their software on a frequent basis.

Benefits of Implementing Successful Continuous Integration and Continuous Delivery 

CI/CD offers a number of benefits to organizations if it is implemented successfully. First and foremost, companies have the ability to release software at an accelerated rate leading to faster delivery to consumers.  This allows for quicker feedback loops to better understand what changes are adding value to both customers and the organization so Product Managers can better understand what to prioritize next.  While the deployment process is shortened, the chance of bugs is also reduced, due to the frequent testing during CI. The transparency of CI/CD gives teams visibility into which part of the software has issues further encouraging collaboration among colleagues to improve. Ultimately, the benefits provided by CI/CD pipelines lead to better end-products for organizations and more value for end-users. However, it’s crucial for organizations to avoid pitfalls in leveraging CI/CD to realize the potential value it can create; below we dive deeper into guidelines to follow throughout the CI/CD pipeline process.

Guidelines to follow in successfully leveraging Continuous Integration and Continuous Delivery Pipelines:

Focus on Small Changes

In the past, developers had been accustomed to creating code for weeks on end and conducting testing afterwards. Moving to agile frameworks began the transition to smaller, incremental changes. While practicing CI, it’s crucial that developers submit smaller amounts of code and run automated tests to pinpoint any issues within the software development process. By running tests on smaller pieces of code, teams minimize any arising issues by detecting problems immediately more quickly determining root cause.

Peer Review upon checking in Code

Code reviews are a necessary part of CI/CD. By leveraging others to evaluate the code being introduced, organizations can stop bugs before they happen. This also enables better consistency in how code is written, commented on, and unit tested to allow for better maintainability over the long term.  Developers can also learn from others through this process. Once code is reviewed and approved, a new build can be created, and tests can be run immediately.

Unit Testing

It is best practice for organizations to partake in unit testing. Conducting unit testing is the first line of defense to curtail the introduction of escaped defects into a production environment by having developers add code to test each function that they build. This tests that the specific intended function is working correctly and can be augmented by additional tests that can provide a broader perspective on the quality of the software.

Variety of Automated Tests

Automated testing is a crucial component within CI/CD pipeline; to properly test software it’s important for an organization to have an array of tests to ensure the solution is operational from an end user’s perspective. These include integration tests, functional tests, UI tests, etc.  Running a variety of these tests provides clear insights into any defects in the code, but it is important to determine what tests need to be automated to get the most return.  Although some organizations automate all testing, a mix of automated testing for the most critical use cases with additional manual testing on lower priority areas of software can suffice.

CI/CD Delivery Pipeline

Continuous Delivery (CD) should only be executed once Continuous Integration (CI) has been hardened and confidence in the processes have been built. While CI allows for code changes to be introduced to test environments more quickly, in order to realize the added value that these changes provide, those changes must also be deployed quickly to customers. However, without first building confidence in the CI aspect of the process, organizations can run the risk of introducing changes to customers that haven’t been properly vetted, thus adding escaped defects and risking a quality customer experience. Once confidence is built in the quality of code being produced through CI, organizations can begin shift to CD in an incremental fashion.

Team up with Strive to begin your CI/CD Journey!

Here at Strive, we take pride in our 3 main practice areas, Management Consulting, Technology Enablement, and Data & Analytics. Within these areas, we can help you discover and navigate if the CI/CD practice is right for your organization. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your company’s growth strategy.

3 Key Concepts to Building a Successful Digital Product

When organizations think of building digital products, the need for a large product focused team is assumed. Many turn to third party options, as the plausible approach is to use third party software built upon the learnings of businesses who have solved similar issues. However, this may not provide the complete solution needed. Years of learning have allowed companies to build digital product tools to tackle problems surrounding customer relationship management, product inventory management, or even enterprise resource planning. Building on the historical education of successful companies has showed that the best products are the ones that are constantly innovating to provide new features.

So, how can organizations create their own innovative products, and in turn, create better solutions for their customers? Most importantly, how can companies build a product and continue to innovate without potentially overspending on ideas that may or may not be useful to their customers. The good news… all organizations can do this, and with the right tools, can do it well!

It all starts with finding the right value proposition as to why something needs to be built. From there, businesses can clarify and refine their vision to turn it into reality. In order to start, we’ll walk through three key concepts that just might provide a compelling reason to invest in building a successful digital product.


Whether you’re ready to move forward with the build or you’re still exploring, the ‘Discovery’ stage is a must. Align with the business and make sure that key parties and stakeholders know what problems will be solved by building the product. Ideally, one should look at the current state to understand how things have been done in the past to help business processes as a whole. Investigating standard technologies within the organization will be beneficial when taking stock on what will be the most valuable. Don’t forget to create long-term goals, specifically related to how a potential new product will be valuable to the organization.

Develop a business process which will be optimized to reduce the number of interactions, handoffs, and steps throughout the process. Next, convert that business process into a user experience and map, so that stakeholders can envision how their users will interact with a new system.

Discovery is an important stage as it helps answer two simple questions: ‘Do we really need to build this product?’ and ‘Why should this product be built?’ When done successfully, one should come out of Discovery with a few concepts to further explore.


Now that concepts are created, use the new business workflows to create and test interactive prototypes. This prototype serves as a bridge between understanding what NEEDS to be improved all the way, to HOW it can be improved.

Plan key interactions that stakeholders would like to see within a working prototype. This will allow the solicitation of feedback from stakeholders and end users. Example questions to ask can include… Is product usable? Is product useful? Obviously, lines  of questioning can be altered depending on motivation for product.

Hopefully, when coming out of your Testing phase there is a functioning prototype which is built around key concepts learned in Discovery and validated directly with users. Now a plan can be built around an MVP solution of the product to achieve the goals solidified in beginning stages.


The initial concepts developed during Discovery and further refined within prototypes during Testing are now ready to be the core features for a new product. Create a plan to show the type of team needed to build the product. Typically, this will involve User Experience, Solution Architecture, and Product Ownership to start, and will grow into a larger team based upon needs for the product.

Creating a product backlog shows features needed for implementation and the high-level stories which drive development. When done correctly, the product backlog will also show value to others as to why this new product matters.

Building a new digital product is never easy, but it can be created in a structured and limited fashion to prove out its value early on. An accelerated approach for Product is what’s needed to identify the business concepts, test out the hypothesis with users, and plan for the initial product MVP.

Looking for more information? Let’s talk!

Here at Strive, we take pride in our Technology Enablement practice, where we can assist you in your initial digital product development needs, all the way through to completion. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your organization’s growth strategy.