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.

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:

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.

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.

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

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.” ¹ 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.

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.

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.

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.

Discovery

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.

Test

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.

Plan

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.