It sat in a box right outside the closet in his bedroom for months. One day, I noticed that he had cut the packing tape on the box, and I knew it was almost time. I’d be able to use this computer ANY minute now! This was exciting, because I had been programming on my Atari 800 since 1982, and I was tired of the 2-hour spinup process, I had to load the operating system from tape every time I turned it on, and after programming for a while (and enjoying the fruits of my labors), everything would disappear – because I had no media to store any of my programs on.

The Apple IIe was liberation. The future. I watched that box every single day, yearning for the moment I’d be able to sit at the console. But the box never opened, and every request I made (please… can I open the box and set it up today??) was met with a stern admonition and a firm “no, you’re too young for that.”

One afternoon, when both of my parents were out of the house or at work or god knows where (this was the mid 80s, so it was perfectly reasonable for an 8 year old to not know these basic facts) I saw my opening: I was going to disobey and set that darn computer up. I wanted it. I needed it. How would I ever get a decent job if I didn’t know how to use an Apple IIe? (Yes, that’s what went through my mind.) I unpacked the box, got it set up in a half hour or so, and reverberated in the opium of Applesoft Basic AND a fresh new box of actual floppy disks that let me save my work and keep going the next day.

Strangely, neither parent complained when they got home. In fact, no words were spoken at all. My dad broke the box down and moved it into the garage. We had dinner. Fearing consequences, I didn’t mention my feat at all – and I just figured I’d use the computer when no was one home. It felt like a win.

In those days, my dad ran an import business stocking local restaurants with German sausage. He was the only distributor in our region, and his days were spent meeting shipments at the airport and ferrying them around to restaurants. Bratwurst, knockwurst, weisswurst, schinkenspeck, landjaeger, you name it. We were the singular source for German sausage in the southeast.

A couple months after I got the computer set up (and still, no words from either parent) my fears were activated. Over dinner, my dad said “Nicole, we need to talk about the computer.”

I was silent. Surely I was about to be taken care of for my blatant disregard of my parents’ order NOT to touch that computer.

“I need you to write me a Sausage Program.”

Now reader, in those days, I had no idea about requirements or design or even what it meant to write a program for someone else. I did not know what a Sausage Program was. What it would do. Who would use it. When it would be used. Whether these people could use a computer, and where they would get access to the computer. Would I have to set the new computer up at my dad’s office? This wouldn’t work either, because the customers never visited him there.

I tried to ask some of these questions, but he got irritated. “Just write me a Sausage Program. I need to have a Sausage Program.”

Every few days he’d ask me about the status of the Sausage Program. “It’s in progress,” I’d say. Meanwhile, I’d sit in front of the terminal, the lonely green cursor blinking against the deep dark blackness, hoping that I’d somehow figure out how to write a Sausage Program. I prayed for divine inspiration.

Soon, it was fall. “I do need that Sausage Program as soon as you can provide it.” He said it three times in the course of a week. I don’t know what I was afraid of if I didn’t deliver, but I knew it didn’t feel good. I still didn’t know what a Sausage Program should do.

Finally, I just guessed. When you typed sausage.exe, you’d be asked five questions about tastes you liked and didn’t like, and the setting you were trying to cook for (like school lunch, picnic, holiday dinner). The Sausage Program would tell you what kind of German sausage was best for you.

Nervously, I tried hundreds of combinations of answers. I made sure they were as good as they could be. I wrote the file onto the disk, and fed some sticky labels into the IBM Selectric typewriter. I typed “SAUSAGE PROGRAM” and “(c) 1984” because it felt like the professional thing to do. I was sure to type the label before putting it on the disk, because typing onto the label on the disk would damage it.

That night, I handed my dad the disk. “Oh! Thank you. My Sausage Program.” From that point forward he told all of his customers that he was using computers in his business. He did not provide any additional detail about this assertion. His customers were impressed, and bought more sausage.

The disk sat on the end table next to his living room chair for a week. Then a month. Then it was 1985. I’m not sure he even knew it was a disk, or what it did, or how to make the disk do something in the computer. But it didn’t matter. Sometime in the spring, the disk disappeared. “I put it in with the photos,” my mom said. “In case he wants it later.”

I was forlorn. My Sausage Program would never reach a real user.

I didn’t realize then how this situation would repeat, over and over, in my career. It’s happening again now that everyone wants to incorporate AI into their business processes.

Everyone wants a Sausage Program. They might not know what it does, but they know they need it. They know how much it will mean to their customers, even though they can’t always explain what it will do, or for whom.

But they need it this week. And you, software people, might have to figure out what that means. May the force be with you all.

I really like this approach because it shows how you can combine the findings in his book and my 2024 book Data, Strategy, Culture & Power (which overwhelmingly focuses on how people can be the problem)! This weekend, I spent some time extracting some restraining forces to consider if you’re doing a Force Field Analysis to assist with change management around data in your company:

Psychological Forces

• Overconfidence in the quality of data and the systems that produce it, or the belief that if data comes from enterprise SaaS software, it must be good. This can lead to complacency, and a lack of attention to detail. This can result in missed opportunities for improvement, ultimately eroding data quality.  
• Conviction in one’s beliefs and biases. This can lead to a failure to consider alternative perspectives or interpretations, and ultimately, to decisions based on incomplete or inaccurate information.  
• Apathy stemming from a lack of engagement or a “box-checking” culture. Apathy can lead to a tolerance for deviations and a lack of attention to detail, which can compromise data quality.  
• Fear stemming from the power dynamics in the workplace. Fear can lead to a lack of transparency, where employees may hesitate to report data errors or inconsistencies due to fear of repercussions.
• Ignorance of the complexities and challenges of data management. Not understanding how easy it is for data to degrade can lead to poor data practices and a failure to allocate appropriate resources for data management.  

Interpersonal and Social Forces

• The pressure to conform to a company’s culture or leadership’s expectations. This can lead to a lack of independent thought and a willingness to address issues from inaccurate or incomplete data.
• Psychological manipulation. Subtle pressure, “kissing the ring” cultures, and the threat of consequences like layoffs can be used to control employees and discourage them from raising concerns about data quality.  

Organizational and Systemic Forces

• Unrealistic expectations and a culture of urgency. When employees are constantly under pressure to deliver results, they may prioritize speed over data integrity.
• Perverse incentives that reward the wrong behaviors. When employees are incentivized to produce quantity over quality, data quality can suffer.  
• Lack of alignment between different departments or teams. This can lead to inconsistencies in data definitions and practices, making it difficult to maintain data quality. On a force field diagram, you’d want to include one restraining forces arrow for every

Environmental and Contextual Forces

• A chaotic and complex data ecosystem. A fragmented and disorganized data infrastructure can make it difficult to track data lineage and ensure data quality. The more components that are in your data stack, the more complex and potentially chaotic you’re likely to be.
• The natural tendency towards entropy. Without proper maintenance and governance, data quality will degrade over time.

One of the most insidious ways data loses value is through the loss of context and institutional knowledge. As team members move on or memories fade, the subtle understanding of how data was collected, what various fields truly represent, and why certain methodological choices were made begins to evaporate. What seemed obvious when data was fresh becomes increasingly opaque, leaving future analysts to make educated guesses about critical details.

Data integrity also degrades over time. Storage systems fail, file formats become obsolete, and meanings transmogrify. While modern systems typically include safeguards, the probability of some form of corruption increases with each passing year. More importantly, the ability to verify data accuracy can often depend on now-unavailable source systems or contemporaneous records that don’t exist.

The relationship between data and decision making is time-sensitive. Business conditions evolve rapidly, and data from six months ago may reflect a market reality that no longer exists. Customer preferences shift, competitors enter and exit, and regulatory landscapes transform. The insights derived from older data can become not just less valuable, but potentially misleading if applied without careful consideration of changed circumstances.

Quick access to relevant data enables organizations to make decisions based on current conditions rather than historical snapshots. When data pipelines introduce significant delays, decision-makers must either act on stale information or proceed without data support. Neither option is ideal, and both can lead to suboptimal outcomes.

The temporal value decay of data underscores the importance of robust documentation, automated testing, and careful consideration of data retention policies. Organizations must balance the costs of maintaining historical data against its diminishing utility. While some data remains valuable for long-term trend analysis or compliance requirements, much of it becomes progressively less useful for operational decision making. Understanding this depreciation helps inform both technical architecture and business strategy.

What can you do about it?

• Make documentation mandatory: Don’t let anyone add or change data without explaining what it means. Think of it like labeling containers in your fridge – if you don’t write what’s inside and when it’s from, it becomes mystery food that nobody will trust.
• Do regular data checkups: Every few months, review your important data and ask basic questions like “Do we still know what this means?” and “Who understands this stuff?” It’s like checking your pantry for expired items before they become unusable.
• Label data with expiration dates: Decide how long different types of data stay useful. Some data (like sales numbers) might be crucial for a month but less important after a year. This helps you know what to focus on keeping fresh and what can be archived.

While it might be tempting to hold on to data, we also have to be practical: when are you really going to revisit that report from 1997? By being realistic and starting from the premise of depreciating data, we can save ourselves and others time, money, and stress for years to come.

You may have experienced something similar. Ever found yourself sitting in yet another sprint planning meeting, wondering if you’re just going through the motions? Time and time again, I’ve seen teams dutifully checking off their agile boxes – daily standups, refinement sessions, retrospectives – while somehow missing the forest for the trees.

Here’s the thing: these ceremonies aren’t meant to be corporate ritual theater. They’re actually powerful tools designed to build the foundation of successful delivery. Think of them as the scaffolding that supports what really matters: creating value for your users and clients.

The real magic happens when teams understand that processes like Agile aren’t about rigidly following a playbook. They’re about establishing the relationships, trust, and communication patterns that enable teams to consistently identify and deliver value.

Let me share three examples where teams got this right:

• A dev team at a bank noticed their daily standups were becoming monotonous status updates. Instead of abandoning them completely, they transformed their standups into collaborative problem-solving sessions. Team members now rally around one challenge a day, and actively seek each other’s input, resulting in faster resolution of blockers and more innovative solutions.
• A product team realized they weren’t capturing real user needs – just imagining what they thought users might want. They started inviting customer service representatives to share recent user feedback once a week, leading to a dramatic shift in prioritization and ultimately a 40% increase in feature adoption.
• An enterprise development team found their retrospectives weren’t driving meaningful change. They switched from a cookie cutter “airing of grievances” format to focused discussion around one key challenge per session, and each person left the session with a small but actionable commitment that would shift their individual behavior or expectations. This collective action led to concrete improvements to their deployment process and team collaboration.

Whether your process revolves around a project charter, agile ceremonies, or just writing tickets and delivering incremental work… the process is NOT the point. All processes are in place to achieve an outcome. If the outcome isn’t happening, don’t pat yourself on the back because you’re following the process well.

All process must be in service of authentic value. When teams understand this, they can adapt frameworks to build stronger relationships, maintain clearer communication, and actually do valuable things for their users.

2024 proved what quality management pioneers knew decades ago: Great AI depends on good data, good data depends on solid processes, and solid processes depend on PEOPLE collaborating in healthy ways.

As organizations rushed to implement AI, the ones that demonstrated early success have focused first on understanding human dynamics. 

2025 will be about RESULTS – and while AI agents will eventually become “just part of the team” – for the foreseeable future PEOPLE making the decisions about how and when to use AI’s results. That means your TEAMS need to be functioning – with as little personal and interpersonal “baggage” as possible.

That’s why we spent 2024 piloting Team-X.AI for over 500 people at 15+ companies – it’s AIaaS (AI as a Service) that helps teams overcome personal and interpersonal challenges to level up performance. The best part is: it doesn’t require anyone to disclose specific weaknesses, fears, or pain points. Our early adopters have used the results to answer burning “people side” questions like “How should we curate our Return to Office policies to balance company needs and individual flexibility needs?” and “What do we need to know about each other to ensure effective GenAI adoption?” (DM and I’ll put you in contact with our customer team.)

In addition, this year I advised 8 new CXOs about how to make informed technical decisions – including how to plan, scope, and design quality into data and AI intensive projects. Through 9 keynotes, I shared how quality management enables successful AI implementation. My collaborators and I also:

• Published our model for GenAI adoption in Harvard Business Review (Link: https://hbr.org/2024/12/how-to-create-value-systematically-with-gen-ai?ab=HP-hero-latest-text-1&giftToken=19365702901733499421436)

• Advanced frameworks for responsible AI implementation by applying Deming’s System of Profound Knowledge to modern data in “Data, Strategy, Culture & Power” — exploring how relationships, office dynamics, and personal motivations shape data integrity throughout its lifecycle – check it out on Amazon at https://amzn.to/4gF0GpQ or eBook at https://www.dxquality.com/offers/9ADWCLCy/checkout (Audiobook & short course coming in January!)

• Shared a vision for how AI will change the way we define quality at an International Academy of Quality (IAQ) meeting at the Japanese Union of Scientists and Engineers (JUSE) in Shinjuku, Tokyo, Japan

• Continued Qzuku with multiple fractional leadership engagements in tech & automotive

Three insights that particularly resonated:

1. “Data, analytics & AI can be objective tools, or personal and political weapons!” On why data initiatives require understanding power dynamics and motivated reasoning.

https://www.linkedin.com/feed/update/urn:li:activity:7201405507679453184/

2. “Who would ever think I would enjoy a book about data?” On making complex concepts accessible and engaging by focusing on human factors.

https://www.linkedin.com/feed/update/urn:li:activity:7217268690721927169/

3. “The insights from Connected, Intelligent, Automated are even MORE relevant today” On applying timeless quality principles to emerging technologies.

https://www.linkedin.com/feed/update/urn:li:activity:7250185386595872769/

The pattern is clear: Organizations achieve extraordinary results when they prioritize quality management principles and healthy human skills over short-term technical wins.

Looking ahead to 2025: Booking keynotes, workshops, and engagements focused on helping organizations implement AI responsibly through quality management frameworks. Whether you’re dealing with data quality, AI implementation, or organizational transformation – success starts by understanding the human system.

Remember: Speed is seductive, but sustainable success comes from building trust, transparency, and quality into every process. Let’s create systems that serve human needs while maintaining the highest standards of excellence.

Note: The ASQ lecture video mentioned in post #3 is now available at quality.org/videos [if you’re a member]

—

Get your 2024 LinkedIn Rewind at https://coauthor.studio/rewind

But you know what’s REALLY scary? Not understanding distributions!

While individual metrics on your Power BI or Tableau dashboards show performance at a specific point in time or space, distributions give you a quick way to see LOTS of values over time or space.

Not looking at distributions means you MISS important signals… because sometimes means just aren’t as meaningful!!

For example:

Customer Lifetime Value

• Point metric: Our customers have an average CLV of $1000
• Distribution reveals: Two bumps on the distribution, like a camel! That means we’ve got two distinct groups of customers… maybe casual customers have a CLV of $200, but our really REALLY loyal customers have $1800 CLV
• Business impact: If we know the distribution, we can formulate targeted retention strategies for each segment. Or maybe just focus our effort on pushing the center of the bigger bump to the right.

Delivery Times

• Point metric: 30-minute average delivery
• Distribution reveals: A long tail. Our most egregious deliveries show up 12 hours after they’re promised… customer satisfaction suffers. Those customers get LOUD on social media.
• Business impact: The distribution can help identify systematic issues causing delays

Product Ratings

• Point metric: We’ve got a 4.2/5 average rating… YAY! Right?
• Distribution reveals: No. you could have polarized reviews, suggesting product controversy. Studying one group will reveal what delights customers, and studying the other group will reveal dissatisfiers.
• Business impact: Makes it possible to address specific customer concerns instead of ignoring them because you’re happy you got all those stars

Employee Performance

• Point metric: Average sales per employee is $20K a month… excellent!
• Distribution reveals: Top performers bring in $200K a month. Struggling staff may not sell anything.
• Business impact: Better targeting of training and support resources. You can help your top performers soar, while helping those who are struggling grow (or find a better role to play).

Web Site Load Times

• Point metric: Average 2-second load time. That’s great… right?!
• Distribution reveals: Spikes during peak hours or specific pages. Between 9am and 11am ET on Mondays, load time is 3 minutes and there are lots of timeouts. You’re losing customers because your competitor’s web site worked when they needed it to.
• Business impact: Identifies specific technical problems and makes it possible to repair them in a cost effective way. If you’d told your software engineers to “go fix this bug” – they’d spend ages on it and still not solve the problem. There’s probably no bug… but rather, an infrastructure issue.

Customer Support Response Times

• Point metric: Average 30 minute response time across the whole team. Fantastic!
• Distribution reveals: Time-of-day variations and outliers. Your staff is providing quick responses during business hours, but customers who have to wait overnight for answers are upset.
• Business impact: Helps optimize staff scheduling & customer sat.

Frequency of Online Product Usage

• Point metric: Average 10 uses per week
• Distribution reveals: Super-users vs occasional users. Some people are staying online all the time.
• Business impact: Guides feature development priorities & helps you discover a bug that’s keeping people logged in, artificially decreasing the frequency metric.

Purchase Order Values

• Point metric: Average order is $500!
• Distribution reveals: Bulk buyers vs individual purchasers. Individuals are only only buying $20, on average.
• Business impact: Influences inventory policies, ricing strategies, and helps you decide which part of the business to focus your effort.

Customer Churn

• Point metric: 15% monthly churn
• Distribution reveals: Early vs late-stage customer departure patterns. Some people are getting irritated fast, but we don’t know why (yet).
• Business impact: Enables proactive retention efforts.

Marketing Campaign Response

• Point metric: 2% conversion rate. That seems low!
• Distribution reveals: Demographic-specific response patterns, or maybe a campaign or three where you didn’t set your conversion tracking up right and you’re showing 0% conversions when in fact you ARE getting customers through those channels.
• Business impact: Allows for more targeted campaign optimization. Helps you catch technical problems that have a material impact on your metrics.

Remember, MEANS are not always MEANINGFUL. You’ve got to look under the surface for patterns revealed by distributions – or guaranteed, you will have ghosts in your data. (And not fun ones.)

[If you need to amplify data literacy at your org so your staff has ghost-vision, contact me by DM at https://www.linkedin.com/in/nicoleradziwill/. We can get you started on a path to progress.)

I can usually get to IMPRESSIVE PROOF OF CONCEPT (POC) in under a day. Sadly, getting a system that embeds genAI to solve practical business problems to production quality is… not as fast.

Getting LLMs to do practical business stuff in production is not easy. Why?

• It’s TOO EASY to generate responses that initially sound good.
• It’s TOO HARD to generate accurate and meaningful responses.
• It’s nearly IMPOSSIBLE to generate sufficiently accurate and meaningful responses with acceptable variation. I might be able to generate 10 options and pick which one fits the best with my clunky human brain, but my genAI agent will struggle to consistently do the same. I’m not giving up. But it’s a slog.

While I wanted to write a synopsis of my experiences over the past few quarters, a LinkedIn article yesterday titled “GenAI POCs are Dumb” written by Steve Jones (and shared via Roman Stanek) hits all the issues I’ve been confronting – so instead, I’ll share some of Steve’s observations.

For example: the time (and uncertainty) around bringing a Proof of Concept (POC) into production is different for genAI than it is for other types of machine learning, and both are different than the path from POC to production most of us are used to. Years ago, there was an understanding that a POC was a POC: upon successful completion, weeks or months would still be needed to make the new capability generally available.

But when companies started to adopt machine learning more broadly, people quickly realized that the POC was the hard part: once you’d built and validated the model, you had constrained the problem and learned how to reduce risk. It was actually easier to get ML POCs into production because you’d already hashed through the hardest parts of the implementation.

Then genAI comes along, where you can whip up a truly magical feeling POC in minutes:

The problem, though, is that a magical genAI POC doesn’t mean a production solution is near. In fact, general availability can be even farther away than we were used to years ago, when we were fundamentally patient people with reasonable expectations about how long reliable tech solutions take to build (charts cobbled together from Steve’s article):

PRODUCTIVITY does not imply QUALITY. Quality takes time and understanding. We need to be far more cognizant of the risks associated with turning up genAI that looks and feels great on the surface, but is plagued with deeper quality issues that only make themselves known over time.