How to Maximize Impact and Future-Proof Your Business in an Ever-Changing World

At Robots & Pencils, I have the amazing privilege of supporting leaders on everything from bringing game-changing new ideas to market to optimizing products and services that have been at the heart of companies for decades. Over the last few years, together, we’ve navigated everything from lockdown, to an influx of customer spending and “growth at any cost” strategies, to preserving cash as we brace for a looming recession. In financial services, education, travel, healthcare, and so much more, my team and I have helped to shape tech and business strategy for everyone from fledgling startups to F500 companies amidst a sea of constant change. With no end in sight–and even more acceleration of technology and societal shifts on the horizon, I wanted to highlight the business and tech trends influencing decisions today–and call attention to 4 strategic areas with the biggest opportunity for organizational impact.

The State of the Marketplace and Technology

Let’s start with what business and tech trends I’m seeing and hearing from friends and clients on the front lines.

Limited Funding

Money is increasingly hard to access. Consumer spending is down. Interest rates are up. With boards and investors focused on operating margin and profitability, every initiative needs a strong business case and clear ROI. Guaranteeing growth through better and more customer engagement is extra challenging right now. As a result, securing funding for those projects has become trickier. Internal efficiency gains are easier to justify investment due to perceived greater ability to control the levers that are needed for impact.

Rapid Change

The speed of change is daunting, and companies are subsequently struggling to select future proof strategies and technology. Further, many companies rapidly selected dozens or more tools during the pandemic to keep business going. Now they aren’t sure what to keep, what to cut, or where to reassess the solution space.

Increasing Need for Flexibility

To provide a runway for innovation, businesses need iterative approaches that flexibly adapt to change. It’s easier to swap out a small thing than a big one–and only make big changes after something is proven to work. Whether for technical architectures, business processes, key partnerships, workforce and talent management (think the gig economy), and even stackable education credentials that may add up to a degree, or not, the desire for flexibility is pervasive.

AI Acceleration

AI is a rapidly emerging tech that has been in the periphery, but suddenly everyone has questions about it thanks first to the release of ChatGPT and now new tools launching literally on a daily basis. Wherever you look, both uncertainty and excitement about its potential are high. (We’ll get into this more in coming blogs!)

Top Business Priorities for Maximizing Outcomes & ROI

Given these business and tech trends, there are 4 areas that I think leaders need to focus on today and into the future to maximize ROI. I’ll intro them here, and, in the coming weeks, expand on each one.

1. Digital Modernization

Companies have launched new tools left and right in recent years, but too often projects are happening in isolation. Leaders need to take a step back to improve the underlying infrastructure and address fragmented data, tools, and processes. But it’s not easy! Getting everything in one place and systems working seamlessly won’t be a walk in the park. However, the payoff is the ability to effectively extract business insights and keep pace with the latest tech advancements.

2. Cost Reduction & Efficiency

Good luck finding a leader not thinking about efficiency right now! Everyone’s looking to automate processes, decrease internal costs, and hit targets without over taxing our teams or budgets. A huge opportunity lies in designing employee tools based on a deep understanding of their experiences and on-the-job needs (and perhaps backed by AI-human partnerships!). These efforts will help you both boost productivity and shift focus to the highest value activities.

3. Personalization & Engagement

It’s all about the user! To meet customer expectations and boost loyalty, companies need more unified and personalized experiences across platforms and touchpoints. To succeed, these initiatives must stem from an understanding of the user and have clear ties to revenue and business outcomes. In a similar vein, schools need better, more connected tools to attract students. From there, they have to keep them engaged with personalized content throughout their educational journey, and turn them into lifelong learners and active alumni.

4. Expertise & Guidance

With so much moving at lightning speed, it’s tough to plan for the future while avoiding costly short-term mistakes. From keeping up with user trends to prioritizing tech investments to maximizing ROI on new products, maintaining the expertise to make all these high-value decisions and plans alone just isn’t feasible. Leaders who seek guidance and support at crucial moments will be better equipped to stay ahead of market change and disruption.

Stay tuned for a deeper dive into these tech trends and strategic priorities — and join the discussion at an upcoming executive digital roundtable!

In my next blog post, I’ll explore how fellow leaders are approaching digital modernization–and the proven methods I’ve seen to navigate the roadblocks along the way. Later in the series, I’ll talk about internal cost reduction & efficiency strategies, approaches to product personalization & engagement, and where organizations are finding outside expertise and guidance most useful.

Sign up to be notified about upcoming posts on tech trends and related topics.

Technical debt 🏦 is often accumulated and ignored in software projects that are struggling with quality, timelines, and expectations. Instead, teams focus on fixing bugs, adding new features, and building quickly. Ignored tech debt is like a monster 👹 that the business knows exists but that it is afraid to talk about 🫣. This monster only becomes a priority when it becomes a blocker or costs more money. Until then, the business assumes that the team will simply learn to live with it.

In the meantime, the engineering team 🤹 has to work on a superficially stable 😵‍💫 product. They patch up 🩹 and build new features 🏗️ on an already leaky product. The team may say technical debt is stopping them from building features X, Y, and Z. They can only deliver X1 and Y1. Some Product Owners (POs) may find an alternative path to squeeze the feature set into the release. They think they’ve achieved the impossible 🥳. In reality, ignoring team feedback is a 🧨 mistake that lowers morale and trust. Over time, you end up with an unhappy, 😖 less motivated team.

Prioritizing a Collaborative Product Experience

As POs, we prioritize the customer experience. But our responsibility extends beyond users 🧑 and the business. We must include our engineering team 🤹 and other stakeholders. Once you consider everyone, you will notice the rough edges and gaps. We must assess the gaps in our process, discuss, and create a plan 📝. We need to focus on the immediate and larger gaps, and set timelines to address others. The earlier we resolve these problems, the better.

I have come to realize by focusing on the collaborative product experience, including all primary stakeholders, and not just the customer experience, we can create a better outcome 📈 for all. We must set aside time on our roadmap 🌎 to review and address technical debt. Give time between releases for teams to recharge themselves 🏖️, reflect on their work, and come up with ways to improve the collaborative product experience 💡. It’s possible that tech debt is not the monster 👻 we always thought it was. Or, perhaps worse, we’ll find that by ignoring tech debt for so long that it was us who made it into a monster 👹. You will never know until you look.

Understanding Ignored Tech Debt

If you want to know the type of monster you are dealing with, keep reading. Here are some steps I suggest to deal with ignored tech debt.

Allow the development team to conduct a technical audit to identify and compile a list of tech debt items. 

This process can be time-consuming, especially for teams that work on legacy infrastructure, unstable products, or systems where tech has not not been actively managed. Product owners can focus the team’s efforts by providing specific goals for the next few releases or for the year ahead, allowing the development team to review connected pieces and identify potential blockers.

Work together to understand the business impact, development impact, and cost of fixing each item. 

Use a simple scale, such as small, medium, large, and extra large, to categorize the ignored tech debt. Development impact refers to the effect of tech debt on the product from a technical point of view, the development team’s job satisfaction, and the team’s morale. You may also consider other factors relevant to your development team.

Map tech debt items on a chart against business and development impact. 

The size of the circle should correspond to the cost of fixing. This will help you to prioritize which tech debt items to address first.

Address debt with high business and high development impact first. 

For example, this could be a mobile app or site that not only frustrates users and leads to lost revenue, but also slows down development. Everyone should be motivated to eliminate small and medium-size circles within the current development cycle, but larger circles may require a conversation. Collaborate with the business and development teams to understand tech debt impact and if larger circles can be split into smaller ones. Resolve as much tech debt as possible while meeting release goals, and ensure everyone understands the cost of delaying or not fixing tech debt. Develop an action plan and timeline for revisiting remaining debt and make space for these items on the product roadmap.

Prioritize items with low development impact but high business impact based on potential impact on the user experience or business goals. 

An outdated payment processing system is an example of such tech debt. It may not directly affect the development team but can cause users and the business to suffer. These items may surface in the future as feature requests, so it’s crucial to address them sooner when the impact is smaller rather than later. Categorize and prioritize these items based on their impact on the business and development, and create an action plan to address them.

Next, focus on tech debt with high development impact but low business impact. 

While these items may not directly affect the business goals, they can have a significant impact on the development team’s ability to deliver quality products. Examples of such tech debt include code refactoring, code optimization, and writing unit tests. To prioritize these items, work with the development team to understand their impact and estimate the cost of fixing them. Then, identify a use case or scenario that demonstrates the value of addressing the tech debt, and present it to the business stakeholders.

For example, you can show how refactoring a piece of code can improve performance and reduce risk in future releases. It’s important to approach these conversations with empathy and understanding. Your goal is to help the business stakeholders see the long-term benefits of addressing the tech debt. By investing in the development team’s productivity and morale, you can help them deliver better products faster with higher quality and confidence.

Save low development and low business impact debt to address last. 

While these items may seem trivial, they can still add up. For example, the unused code or feature in the product clutters the codebase and might make it difficult to maintain over time. In this category, evaluate each item and consider its long-term impact on the product. Start with those that are strongly connected to the product roadmap and goals for the year. For the remaining items, analyze and understand what happens if these tech debts are not fixed in a year. If the answer is little to no change in size and impact, carry them over to the next year. But if ignoring the debt increases its impact, prioritize and create an action plan.

Long-Term Benefits for All

Remember, it’s important to regularly review and address tech debt during your product development process. This helps maintain the health and stability of your product. It also ensures that the development team can work efficiently and effectively. By prioritizing and addressing previously ignored tech debt, you can create a culture of continuous improvement and quality. As a result, you’ll deliver a better collaborative product experience. Ultimately, a positive and motivated team is essential for the success 🌟 of any project, and it is our responsibility as POs to ensure this. Do the right thing for your people and product.

This post was contributed by Rushi Pol, the Product Owner Craft Steward at Robots & Pencils.

This article describes my strategy for learning new technology, refined over the decade or so that I’ve been working in tech. As with any advice based on one developer’s experience, you may find that it’s obvious or that it doesn’t apply to you, but I hope it’s useful as a guide, a checklist, or even just a starting point for reflecting on your own learning process.

When I talk about learning a technology, I mean something pretty concrete. I would apply this approach to:

• programming languages
• data stores
• libraries and frameworks
• tools (git, Docker, Regex, etc.)
• platforms (Linux, AWS Lambda, Google AppEngine etc.)

I wouldn’t apply it to:

• methodologies (TDD, agile, effective writing, etc.)
• high-level concepts (parsing, ML, IoT, serverless, etc.)
• low-level details (virtual memory, garbage collection, etc.)

A 3-Part Strategy for Learning New Technology

Here’s an overview of my strategy: when I’ve got a new technology to learn, I think about going through three broad phases:

1. Consuming documentation
2. A learning project
3. Application

Phase 1: Consuming documentation

My first stop when approaching any new technology is documentation, especially intro docs or tutorials. I do love a technology that comes with good documentation! This phase might also include courses, blog posts, or other third party material.

Beyond actually learning the technology, in this phase I’m looking for:

• Points of comparison: Is this technology similar to something I already know?
• Unique features: What are the ways this technology is different or surprising? Where might I apply it instead of something I already know?
• Integration points: What kind of projects could I use this technology for? Will it let me leverage things I already know, or does it require me to discard my usual toolbox?

The objective is obviously not to learn everything there is to know, but to create connections to my existing knowledge so that I can start using the technology and find my way to answers in the future.

Some examples of great material for this phase:

• A Tour of Go
• Clojure Programming
• Execute Program

Phase 2: A learning project

Once I read the introductory documentation, I try a little project using the new technology. I aim for something small but not trivial. I want something where I can safely apply the skills I’ve just (supposedly) learned but also something that will challenge me and expose any gaps in my understanding.

Note that this isn’t learning on the job or building tools to scratch your own itch (though those are important skills in their own right). It’s a project that’s conceived, planned, and executed with learning as a primary goal.

I try to find a project that:

• Highlights the new technology: I won’t learn much about a new database if I’m struggling to get my front-end code just right. If I want to try out that auto-documentation feature, I should make something that I’d want to document.
• Is just beyond what’s comfortable: Getting frustrated with advanced features isn’t productive, but neither is retreading material from the tutorial.
• Doesn’t have too much instrumental value: If I set out to build something, I might overlook a new technology’s failings if I want the thing badly enough.
• I can put some polish on: The point is to learn a technology well; it’s good to have some time to polish, review, or get feedback.
• Above all, I want a project that’s small: A tight scope helps me keep focus and leaves me free to fail fast if the project isn’t working.

The objective is to discover all the things that the new technology’s documentation didn’t address:

• How difficult is it to install/build/operate?
• Can I integrate it with my existing tools (languages, editors, source control, packaging and deployment, etc.)?
• Does it still feel elegant and useful when I’m using it on an original problem (and not a carefully chosen example)?
• Did I actually learn it well enough to turn an idea into a reality?
• Am I confident that I’m using this tool correctly? Idiomatically? Sustainably?

My experience has been that these kinds of questions aren’t always addressed very well in documentation or are addressed more with hype than with facts. If, after putting in a genuine effort, I can’t get a new technology to work for me, it’s an indication that the tech might be immature. Alternatively, my understanding might be flawed or the technology might not be a good fit for what I’m after.

Some examples of projects that I’ve done in this space:

• What Tide is it Right Now.com
• The Prettygood Passphrase Generator
• Mondriandroid

I also find it helpful to write up a little experience report when I’m finished. This helps me capture and clarify my impressions of the new technology and have something to share with others.

Phase 3: Application

Once I’ve done my learning project, I’ve hopefully got a good sense of where a new technology fits and whether or not I want to keep working with it. At this point, it stops being a target for deliberate learning. If I’m trying to further develop my expertise, I look for:

• Opportunities to use it professionally: Perhaps I have a work project where the new tech is a good fit or is already a going concern.
• Side projects: This can be bigger and more instrumental than a learning project while still being a safe place to experiment.
• Complementary technologies: Sometimes it might be appropriate to start this process over with a related technology. (For example, you might learn Elixir then Phoenix, or Rust then WASM).

Naturally, I’m always looking for opportunities to go deep on a technology (heck, I’m still learning things about Python after nearly 10 years!) but I’ve found that further expertise comes much easier with study and experience than it does from studying alone.

This post was contributed by Nat Knight, one of the principal developers who supports our clients and projects at Robots & Pencils.