Category: Leadership

Managing people

Who Funds the Learner?

The Vanishing Entry Level

Empress of Balance – Colored Pencil – Richard Lee (2012)

New Stanford/ADP dashboard data shows entry-level roles contracting 3.8% per year in AI-exposed occupations, while older cohorts (35-50) hold steady. 

Once upon a time, junior designers earned their stripes on the slow and steady path. Depending on their date of entry, that might have been designing websites that didn’t convert, or building flows that confused users. Then they were shown how performance metrics suffered, or they sat behind the glass during usability testing while a senior designer traced the confusion back to decisions the fledgling designer made three sprints earlier.

Junior developers earned it in similar fashion. Maybe it was an accidental reveal of not-ready-for-release site content, or perhaps a 2 a.m. troubleshooting session that traced a production breakdown back to their front-end framework implementation choices. Different rooms, but the same mechanism. The lessons we learned before AI was on the scene? They cost us something, yes.   But it’s that sting that made them stick, and with enough mistakes under our belt and the learning that lies therein, we develop judgment. 

Of course, precisely how that pipeline was configured was never sacred. Just familiar and commonplace. You might even go so far as to call it common sense. 

Calculators erased the requirement to do math in one’s head. Digital layout tools led to no more hand lettering.  CAD erased the bottleneck of hand drafting.

Each time these changes landed on our doorstep, a chorus of practitioners insisted the new abstraction layer would produce generations that couldn’t really do the work, and could only operate the machines that were doing the work. But each time, judgment reconstituted itself one layer up. The “entry-level pipeline” was never a fixed pathway, it’s always been whatever the current domain, team and process kept at the bottom rung.

Why is this time different? I believe that AI advancements and adoption are so visible and widespread, this time we can watch the abstraction layer shifting around. We’ll either see the pipeline reform or see it fade away completely.  We’ll see it clearly in the data, which no one’s arguing we have more of than say, when calculators first rolled out. 

The Fork In the Data

In August 2025, a Stanford Digital Economy Lab team led by Erik Brynjolfsson published a finding that has since grown into a live-time dashboard built with ADP Research, covering roughly 4.6 million workers across more than 730 occupations.

The data’s headline is that employment for AI-exposed workers ages 22 to 25 is contracting at roughly 3.8% per year as of the most recent data, and that the decline has accelerated since the first year of measurement. Workers 35 to 40 in the same occupations are growing at about 2% annually. The squeeze reaches past new grads, as well. The 31-to-34 cohort is down about 1.7% year over year. 

Across all workers, at any age, in any domain and context, AI-exposed occupations are down just 0.2%. Generally, jobs are holding on.

Within the same firm, entry-level hiring in the most AI-exposed roles fell about 13% relative to less-exposed roles. 

It’s the On-Ramp That’s Collapsing

The Fortune piece covering the dashboard put it plainly: AI “absorbs tasks before it absorbs jobs.” It reaches first for retrieving, summarizing, scheduling, formatting. The tasks junior people have always been handed, because those tasks never required years in the seat. 

It’s worth noting that the Stanford team thankfully ran some controls on the research, taking interest rates, pandemic overhiring corrections, and the pervading sense of global despair mostly off the table as competing explanations for this collapse of the entry level pipeline.

ADP’s chief economist, Nela Richardson, points at the operative variable: whether an organization deploys AI primarily as automation or as augmentation. Occupations where AI is brought in and augments human work show durable employment growth. Occupations where AI is introduced and automates tasks outright? Those are shrinking. 

Same Tech, Very Different Outcome

The difference lives in an organization’s collective mindset and in the decisions that company’s leadership makes across several factors (talent training & retention, AI deployment and the usual build/rent/buy decisions). These decisions typically roll out without the “talent strategy” label, though that’s where it appears things are headed. 

Hold that thought, because it’s the crux of everything that follows. Why? Because supervising AI output requires exactly the judgment we are quietly ceasing to train when AI is deployed primarily to automate entry level work vs augmenting those occupations in a sustainable fashion.

A Strong Counterargument

I want to hand over the mic for an optimistic read on this debate, because I believe it has strengths, and a potentially viable path forward. 

A principal designer I respect at a mid-size HR-tech company pushed back on an earlier piece of mine, one arguing that AI adoption orchestration is becoming a dedicated role. Her stance on the ‘emerging role’ question, in her own words: 

“I’m not entirely convinced this is a dedicated role. If the company creates a culture of knowledge sharing, it’s a great way to surface workflows that may benefit others… I think each person should be empowered to build what works for them specifically, share when appropriate, and adopt builds from others if useful.” 

Her org runs on that model today. A dedicated channel, with people sharing AI workflows and skills proactively. No gatekeepers required. Having spent time in the very culture and org this approach is working in, I wasn’t surprised to hear it appeared to be effective in mitigating some of the worst aspects of AI Onboarding Debt.

But beyond a thoughtful, transparent culture where folks share with intention and strategy,  there’s an even stronger case to be made for saving the entry-level judgment pipeline itself.

Judgment Comes from Decision Cycles, Not Keystrokes

The grunt work (design critiques, code reviews, support ticket triage) was never the point. Rather, it’s been the fee those early in their career had to pay to move up, to take on more responsibility and be given more power.

If AI waives that fee, a junior designer who once would have owned five flows across two years can now learn fifty lessons vs. five. They see dozens of cycles go from project to shipped to results in the same span of time. A junior developer sees the same shift, from five branches full of hard-won wisdom to fifty shipped-and-broken cycles. More repetitions, not fewer.

The traditional pipeline wasn’t the most ideal filter in the first place. It selected for who could (and was willing to) endure years of low-leverage work, and for who had the pedigree to get hired into the pipeline at all. Neither is a great predictor of judgment.

The Fork Itself Is an Optimist’s Best Evidence

The Stanford/ADP finding doesn’t say “AI destroys entry-level work, full stop”. It says entry-level work contracts where AI is deployed as automation, vs how entry-level work holds on just fine where AI gets rolled out as augmentation. That’s proof that a viable, extensible path is live right now, and visible in the same data-driven dashboard. An org that deliberately pairs their junior staff with AI as a force multiplier (versus cutting staff and trusting that shiny new agent) is running the augmentation condition, even if they don’t frame it that way.

Where the Counter Doesn’t Hold Up

The verification bootstrap

Today’s design and development veterans catch bad AI-generated decisions because they made enough bad decisions of their own to spot them before they cascade. The next cohort will inherit that verification mantle, but sans the specific quality of cycles that make recognition possible for those who’ve been around the block a few times. Those fifty watched cycles,  blissfully absent of grunt-work and guaranteed sting-free? They don’t have the same stressors, and don’t dish out the pain that spurs judgment the way that five lived-cycles do, at least not in most domains.

A newbie pilot’s required flight-simulation hours compile into judgment because the feedback is fast and unambiguous. Either the plane crashed or it didn’t.  

Design work rarely offers that, and neither does most engineering above the unit-test level. When a junior designer’s flow gets shipped and the confusion it causes surfaces as a slow bleed in adoption metrics three quarters later, attribution is hard because it’s tangled with someone else’s redesign and a rebrand marketing swore was crucial for their Q4 goals. A junior dev’s architecture calls look fine until it’s load-bearing under features they hadn’t scoped and didn’t have the experience to proactively account for.   

Delayed, diffuse, and hard-to-attribute feedback doesn’t write to long-term judgment the same way a simulated stall warning does for that newbie pilot in training.

What the Data Reveals About Choice

Even if we grant the augmentation model everything it appears to offer, that path still has to be chosen.  The ADP Research dashboard is the record of what’s actually being chosen at scale: role contraction is concentrated in the same place as automation-mode AI deployment, with the net effect growing month over month by roughly half a percentage point. 

It’s not a data artifact, it’s the result of deployment decisions by thousands of firms, made mostly by default. A junior IC navigating cycles with judgment-producing stressors (the  augmentation model)  built in is a cost center without a plainly visible, near-term payoff. 

Nobody is budgeting for the learner, and four years of data have revealed the preference for the vast majority: nobody is about to.

Even If Augmentation Wins, There’s a Cost

Say augmentation wins outright and judgment keeps forming. It’s still worth naming what that victory actually costs, because the maturation process isn’t instant.

The advancement of digital layout tools produced designers whose judgment formed differently, yes. However, it formed no less rigorously than those who did hand lettering and used rubylith.  It also resulted in a period where the in-between cohort absorbed the digital disruption, without a playbook and with a dual learning-and-practice load. They carried both digital and analog knowledge and techniques, without any extra for the trouble. 

The 2023–2030 workplace entrants are in that awkward phase right now, whether you fall on the pessimistic or optimistic side of this topic.  And while I don’t have a confident estimate for how long this phase will run,  5-7 years would be my guess based on prior precedents and the degree to which AI seems to confound precedent entirely.

The Category Error

Here’s where the real question and the designer’s sharpest observation come together. Her sharpest observation wasn’t the culture argument, but a question she raised in passing about the hard part of AI deployment and adoption. 

“The socialization, governance & trust that comes along with it… whose responsibility is it?”

Organic knowledge-sharing culture solves for process and tooling diffusion. In an org doing things right, relevant and effective workflows built by one person quickly reach the rest of the org, even without a dedicated role driving that outcome. That’s a real problem, a real source of pain I’ve had several seniors convey to me, and one that the model her org practices addresses well.

That said, formation of judgment is a different problem wearing similar clothes. A shared channel of AI workflows may tell a junior how to build something, or perhaps even what to build. 

But it doesn’t put them through the cycle of thinking, building and shipping, then watching the consequences land. It doesn’t knock them down, make them wince and then clamber up and step back to the drawing board. 

We need to find new ways of building in the reps the verification bootstrap shows us are nonnegotiable. While conscious diffusion can move artifacts between people who already have judgment, it doesn’t manufacture judgment in people who don’t yet have it. An org can run a flawless sharing culture and still have zero judgment formation happening underneath it. 

In this scenario the collapse just happens quietly, even inside companies with excellent knowledge sharing. A few years on, there won’t be any juniors capable of exercising judgment and independently making calls that require it.

I’m not claiming my designer friend’s model is wrong, and it answers the diffusion question well. But her own “whose responsibility is it?” still sits on the stack one layer down, where the artifacts stop and the judgment has to kick in.

Who funds the learner

If the fork is real, and the data says it is, simply naming your org’s AI deployment strategy as “augmentative” doesn’t mean the judgment-formation pathway will build itself, even inside the best sharing cultures in the industry. Someone has to figure out what a junior must do across those fifty watched cycles so that watching turns into judgment.

The apprenticeship cannot consist solely of watching fifty data points of exposure. There must be real stakes. There have to be consequences a junior human gets to feel, and real accountability for catching what the AI gets wrong. 

Someone has to build the structured apprenticeship interlaced with using AI to speed up and automate what doesn’t contribute to building judgment. That’s a role missing from most headcount plans, and the revealed-preference data says it’s losing the budget argument every quarter the dashboard reports.

So the age-old mechanism survives: entry-level to senior decision maker. Judgment can still form on the far side of this AI transition, the same way it formed on the far side of every transition before it. But it won’t form by default, and the question every org is answering right now, whether by strategy or by default, is the one this piece can’t answer for them: 

Who funds the learner?

UX Had to Beg. AI Didn’t Even Knock

A Long, Long Time Ago

It’s 2013 in beautiful Knoxville, Tennessee and I’ve just been hired by a healthcare software company to build up a UX design team. The focus? Physician-facing and care team facing  applications and workflows. The kind of context where deep knowledge of how clinical users actually think and work isn’t a nice-to-have, it’s a requirement. 

Except that’s not quite what happened. Over the following months, through a series of smaller decisions and quieter conversations, the picture changed. The team never materialized and the role drifted. What they actually needed, it turned out, was someone to evaluate vendors and manage design relationships. An art director, something I had done before, pretty extensively. And yet…

The contextual knowledge that healthcare UX requires, the kind you build through research and iteration and repeated proximity to actual users? It got treated as a secondary consideration. Engineering was the center of gravity. Design just orbited it. I trained my replacement and left exactly one year after I started.

Two years later

At Siemens Healthineers, I’m sitting across from an engineering manager who has politely but clearly already decided this meeting is a formality.

We’re talking about PET scanner workflow software. The screens that a nuclear medicine technician uses to dial in radiation sensitivity, read radiological event data and confirm what’s been captured and what’s still pending. Heady stuff. 

The screens are all in black and white. Dense gray scale without much visual hierarchy. No color cues and no summary of present state. Just numbers and toggles that the technicians had been memorizing for years, because the alternative was slower.

I had some questions, and with tech constraints onboarded, I soon had upgrade proposals:  better resolution, colors to encode and depict radiation sensitivity ranges, a progress summary surfaced where it was actually needed and changes that would reduce the cognitive load in workflows where errors had real consequences.

The engineering manager looked at the mockups, and then at me, then back again at the mockups. “We’ll think about it,” he said.   That quarter, I ate a lot of catered lunches at my own brown bag events talking to engineers, clinicians and physicians as well as product managers, sales and marketing. 

Doing Reps – UX Adoption

Here’s what UX adoption actually looked like in that era, from the inside. 


Perhaps you were in a new practice trying to earn a seat at a table that had been set without you. Engineers and executives didn’t dismiss UX because they had evaluated it and found it wanting, but because it looked decorative. Soft and touchy-feely. The frou-frou department, one executive at another company once called us. (I’m not making that up.)

The resistance lived at the top and in the middle and the people with institutional authority were the skeptics. Which meant that one of the most promising paths forward was bottom-up proof. 

Meaning what? Patient, persistent and high-quality work that kept raising the bar. Usability testing session videos where engineers sat and watched real users struggle with interfaces they had built. HCI fundamentals explained in terms of sensory memory and visual processing, in the language of people who thought in systems. Brown bag lunches and hallway conversations. Prototypes that were better than anything anyone had seen before from a design function.

One full quarter of pursuing this at Siemens Healthineers and then…Then a YES.

Two companies, two shapes

They both circled the same problem: UX climbing uphill against institutional skepticism, converting the powerful through evidence they couldn’t easily dismiss.

There’s a documented failure mode worth naming here, one which Debbie Levitt wrote about in 2022 in UX Magazine: UX practitioners who responded to that skepticism by democratizing their work, running design sprints and workshops that invited everyone to “do UX,” inadvertently taught organizations that UX was something anyone could do. The tactics designed to build buy-in ended up hollowing out the credibility they were meant to establish. 

The ones who navigated it well held the line on expertise while still opening the door. Proof positive rather than participatory theater.

AI arrived differently

It didn’t send a calendar invite. It didn’t ask for a pilot program. The budget showed up first, and then the mandate. Then the all-hands where leadership explained that we were going to be an AI-forward organization, effective immediately, and wasn’t that exciting?

The resistance to this new influence flipped from technical and leadership to creatives and engineers in the trenches. 

We’re talking Design and Development, the people closest to the craft. Everyday users who had been handed tools they didn’t ask for and told to use them. These are the skeptics now. Not the executives, and not much engineering leadership. The people with institutional authority are already sold while the unconvinced are the practitioners.

Same adoption problem, with an opposing polarity.  So what does that reticence actually look like up close? Some of it is displacement anxiety, which is real and reasonable. Some of it is quality concern, also real. Some of it is ethical unease about training data, authorship, environmental cost. Some of it is something harder to name: the feeling that something is being done TO you rather than WITH you. That the conversation started without you and ended before you arrived. That last one sucks, doesn’t it?

Resistance Vectors

Here’s what I keep returning to… That the tactics that worked in 2013 were designed for a specific direction of resistance.

Brown bag lunches work when the VP needs convincing. They don’t work when the VP is already sold and your creative director is the holdout. You can’t mandate your way to bottom-up trust. And you can’t run a workshop that teaches skeptical practitioners that “AI is good, actually” without recreating the exact failure mode Levitt described. You’d be running AI evangelism theater, basically going through motions that signal organizational enthusiasm while building neither genuine capability nor genuine confidence in the people you most need to reach.

So what does the reverse playbook look like? I don’t think we have a settled answer yet, but some hypotheses are worth examining.

Proof by invitation, not assignment. Let skeptics choose their own first use cases rather than handing them one. The brown bag that worked at Siemens wasn’t mandatory. It was catered, which is different. People showed up because they wanted to, and left having seen something they hadn’t expected.

Honest failure visibility. Show where AI breaks, not just where it succeeds. Calibrated trust is more durable than converted enthusiasm. The usability testing videos that moved engineers at Siemens weren’t highlight reels. They were uncomfortable to watch, and that was a big part of the point.

Craft preservation framing over craft replacement framing. What does AI protect practitioners from, rather than what does it take? That reframe isn’t just spin, and more often than not it’s a more accurate description of what’s happening in the workflows where AI is genuinely working well.

Peer signal over executive signal. Who in the skeptic community is actually using these tools well, and are they visible? In 2015, the practitioner who moved me forward with engineering management wasn’t the VP. It was a senior engineer who had sat through a usability session and couldn’t stop talking about it afterward. Credibility traveled laterally before it traveled up.

None of these are prescriptions, and obviously the playbook for these tactics is still being written.

Next Generation Adoption Attitudes

One more layer of this problem is being built right now, and it’s further out than many folks are looking.

On a recent road trip, my teenager told me about AI at school. Compulsory exposure. Tools introduced without much context for why. Classmates who had concluded, from their first extended contact with AI, that it was something to be skeptical of or dismissed. Not because they’d evaluated it carefully, but because their introduction felt like something being done to them.

Sound familiar? The adoption problem isn’t just in current workplaces. It’s being reproduced downstream in a generation whose first impressions are forming right now. That’s a longer conversation and it deserves its own article. But it’s worth naming here: we’re not just behind on the current adoption curve. We may be behind on the next one too.

Wrapping Up

In 2013 the question was: how do you convince the people with power that this practice has value?  Well, we figured that out. Imperfectly and slowly, with more catered lunches than anyone should have to sit through. But we figured it out.

The question now is different. How do you build genuine trust with the people doing the work, when the people with power already believe?

I don’t think we’ve found the answer yet, but I’d love to talk with the bright minds working on it.

—–

#AIAdoption #AIAdoptionDebt #DesignOps #UX #Leadership #ProductManagement #EngineeringLeadership #FutureOfWork #NextGenerationTalent

The 30-Point Sprint: How Leaders Hoard Capability Instead of Building It

A staff engineer at a scaling tech company told me about their managing director — someone with organizational authority, access to the best AI tools, and apparently a lot of enthusiasm for using them. The director had assigned themselves 30 development story points in a single sprint. The rest of the team was carrying 6 to 16 each.

“They vibe code everything,” the engineer said, shaking their head. Their team was left babysitting that output.

I’m not here to cast shade, and I’ve seen enough versions of this pattern to know it’s rarely malice — it’s excitement without governance. Glee without the long view. AI makes execution feel effortless, and when that feeling hits someone with organizational authority, the natural instinct is to run with it and stay in motion.

But I keep thinking about what a different story that could have been.

Imagine the same director, the same tools, and the same gap in formal coding skill. Instead of assigning themselves 30 points, they walk into a team standup and say:

“Here’s the problem I was trying to solve, and this is how I approached it with AI. Show me how you would do it the traditional way — and then show me how you would do it with the AI tooling we’ve implemented. Let’s talk through the strengths, drawbacks, and leverage opportunities for all three approaches.”

How different would that be for the team? For that leader? For the org’s health as a whole?

That’s not a weak play. That’s one of the highest-leverage moves a leader can make — using their own ignorance as an opportunity to build a structured learning platform. The team gets to teach. The leader gets to learn. The org gets a three-way comparison that surfaces assumptions, tradeoffs, and best practices that would otherwise stay locked in individual heads — or leave entirely when those people move on.

It becomes a running growth exercise. It compounds, to the good, for a change.

Instead, the reality

30 story points for someone who should be focused on meta-level engineering concerns. A team stuck babysitting their leader’s output. And an opportunity for something genuinely great quietly wasted.

AI gives leaders without deep technical chops a real reason to lean in — not for the first time, but never has it been so readily accessible. The question is whether they use that access to hoard capability or to build it.

The answer is what separates a manager from a leader.

Originally shared on LinkedIn.

A New Job Is Lurking Inside Your Design/Product Org

AI capability inside a design org doesn’t distribute itself.

Enthusiasts will adopt it, of course. They build their own local workflows and see some gains. They may hoard the knowledge — not out of malice, but because nobody’s asked them to share it around. Everyone else keeps working in more traditional fashion, often quietly ashamed of their (self-diagnosed) ignorance.

This is AI Adoption Debt. And it’s not a training problem. Training can build knowledge, but it doesn’t build systems.

The role that builds those systems is forming right now inside mature design and product organizations. It doesn’t have a consensus title yet, and in most orgs, it doesn’t exist at all. Many don’t even know they need it.

What the role is not

It’s not a prompt engineer. It’s not an AI evangelist. It’s not a design technologist in the traditional sense, and it’s not a product manager for your AI tooling budget. Those roles exist and they matter — but they’re not this.

What the role actually is

The role’s primary responsibility is managing organizational AI adoption infrastructure — ensuring that knowledge compounds across teams rather than concentrating among early adopters. It sits at the intersection of DesignOps, systems-level organizational thinking, change management, and technical depth (without requiring engineering-level skills).

AI doesn’t speed up decision-making. Decision-making is still the bottleneck. This role builds the systems that distribute AI leverage equitably across the org so that the bottleneck doesn’t also become a single point of failure.

Building that infrastructure calls for a specific mix of skills

    • Deep familiarity with design practice
    • Systems-level organizational thinking
    • Change management expertise
    • Technical depth (not engineering-level, but fluent)
    • Accumulated judgment and pattern recognition

The 5th dimension: A foundation of judgment

The first four are table stakes. The fifth — judgment — is what separates someone who can describe this role from someone who can actually do it. It’s the ability to read an organization’s readiness, sequence interventions correctly, and know when to push and when to wait. It accrues slowly, can’t be hired in from scratch, and is what makes this role genuinely hard to fill.

Where the role is “beaming in” right now

It’s appearing most visibly inside organizations that have already built mature DesignOps functions. Those teams have the operational muscle memory. They know how to run programs, own shared infrastructure, and manage change at scale. The AI layer is new; the organizational pattern is not.

It’s also showing up in product orgs — particularly in companies where product operations has developed enough structural maturity to absorb a new domain.

Why it doesn’t yet exist

Because most organizations are still in the tool-buying phase. Leadership approves the budget. Individuals experiment. Ninety days later there are a dozen parallel workflows that don’t talk to each other, and one or two enthusiasts burning out trying to carry everyone else toward the goal post.

Nobody paused to ask: who owns the system?

What to do if you’re building a design or product org right now

    1. Audit honestly. Map who’s using AI tools, how, and what’s been shared beyond their immediate team. The gaps will be obvious.
    2. Assign ownership. Not enthusiast ownership — organizational ownership. Someone with design knowledge, organizational authority, and an operational orientation.
    3. Start with vocabulary. Shared vocabulary is what makes it possible for a new hire to be productive in weeks instead of months. It’s the cheapest, highest-leverage infrastructure investment you can make before building anything else.

The organizations that recognize this structural gap early will have a compounding advantage over those waiting for the formal job title to arrive before they act.

The role is forming. The question is whether it forms intentionally inside your org, or by accident.

Originally published on LinkedIn on June 2, 2026.

Thoughts On Medical Decision Making

Original article by Jerome Groopman

We all fall victim to habitual behaviors, and more so when we are unable to focus sufficient attention on tasks at hand, believing (consciously or unconsciously) that we can accomplish some process or task without conscious thought, instead thinking about ‘more pressing’ matters.

What is more difficult to detect are those biases not based on habit, but instead on other factors. Groopman’s article on medical decision making explored this issue in the light of decisions made every day by physicians in practices and hospitals across the world.

Several types of errors were explored, including Representativeness error (thinking that is overly influenced by what is typically true), Availability error (the tendency to judge likelihood of an event by how easy relevant examples come to mind), confirmation bias error (cognitive cherry picking – confirming what you expect to find by selectively accepting or ignoring information) and affective error (making decisions based on what you wish to be true).

The stories he shared demonstrate how a very skilled and educated doctor can make incredibly dangerous mistakes, due in some cases to the fast-paced world of medicine but in other in reaction to common human urges such as the desire to be merciful and spare a patient embarrassment or further fatiguing tests.

At my workplace we are tasked with making medical industry communication more secure and much more efficient – resulting in better patient care and increased physician and clinician satisfaction. After reading this article and having learned a great deal about how complex the communication needs of a hospital or practice have become, I have to wonder how many mistakes are made due to the very real problems of workflow dissolution and workplace communication breakdowns. How many errors of the classes described by Groopman could be avoided or reduced in severity through more frequent and higher quality peer-to-peer interactions in the medical industry?

GapMinder Data Analysis

In my HCI cognitive science class we’ve been studying visualization and how a given interface can enhance our mental processing power, bringing more of our wits to bear on a challenge. Here’s a look at comparing a few layers of data as reported by two very different nations.

Denmark vs. USA – Charitable giving related to income & life expectancy

I chose to compare the nations of Denmark and the United States, examining their respective records of charitable giving and comparing that to each nations’ income per person and their life expectancy. The data available ran from 1960 to 2008, and so it’s worth noting that the period studied spanned several wars with worldwide impact, numerous financial recessions and a gradual but accelerating trend of climate change.

The United States
The United States in 1960 was quite a charitable one, donating 0.54% of the gross national income (GNI) while only reporting $18,175 in income per person. We had a change of heart it would seem, as the % of GNI given to charity fell steadily for 37 years before finally ending at 0.18% of GNI in 2008.

During this period, while our incomes rose by $24k and our life expectancy by 8 years we gave 0.54% less to charities.

Denmark
Denmark in 1960 was a hard place, donating only 0.09% of their GNI while reporting only $11,569 in income per person. They seem to have buckled down and gotten industrious, as the % of GNI given to charity rose for 21 years to 1.03%, with a high of 1.06% before finally ending at 0.82% of GNI in 2008.

During this period, their incomes rose by $20k and their life expectancy by 6 years. In the end Danes increased their charitable giving by a staggering 0.97% over the period.

Reflections
An interesting measure to add to this comparison would be an index of reported happiness & contentment – does charity or income have a greater effect on happiness?

I would also have enjoyed seeing an overlay of world events across political, economic and climate scopes, relating those factors into the changes in life expectancy, income and charitable giving.

The animation was quite helpful, and illustrated the rate of change between compared parameters over the lengthy collection of data ranging over 48 years, clearly calling out the rapid rise of Denmark’s charity while the USA gave away less and less each year.

It’s purely correlative, but it appears that given the much larger percentage they gave to charity (from their noticeably lower income) the Danish were not overly burdened and lived to nearly the same age. Many factors could have been at play, but I’m given to lean towards the old adage that money CAN bring happiness as long as you spend it on others.

Reorgs: Rocky or Righteous (Designing the Experience of Company Transition)

As designers, we grapple every day with challenging projects. This of course is part of what keeps us coming back. Some challenges, although not directly related to project work, can still be looked at through a UX lens. In this case, I’m talking about a phenomenon you’re likely familiar with: company reorganization.

If you’ve been through a reorg (that’s ‘Reorganization’ in water cooler parlance)you’ve probably experienced your share of the whispers, closed-door meetings and mixed messages that seem to be par for the course when an organization goes through major changes in size, scope, staffing, or management.

I’ve been through a number of these shuffled decks myself, across several companies, and for a variety of reasons. It’s fair to claim that each one is different, but there’s enough overlap to identify patterns and form some baseline recommendations.

If you’re in a role with decision-making authority, then you’re ideally positioned to ensure that the reorg will be designed as an intentional experience with its actual user base in mind.

However, if you’re like the majority of us who aren’t in a position to make decisions about the reorg, you’re probably still reasonably close to the folks who are. Why not take the initiative and lay out some scenarios and recommendations for how the reorg can be designed for optimal reception and impact on your organization?

The users

Whether it’s planned or not, the scope of the reorg will have an audience far larger than the group of people seemingly affected on paper. The experience of these groups throughout the reorg should be purposefully designed by whomever is running the change management show.

Let’s take a look at who your users are.

  • The folks who are officially part of the reorg. Their status is changing in some way, be it their actual role, reporting structure, and the like.
  • Coworkers/teams who have direct or dotted-line dependencies with anyone or any team directly involved in the change.
  • Coworkers/teams whose only connection is physical or cultural proximity or who ultimately report to the same upper management.
  • Third party vendors who communicate with or provide services to reorg-affected parties.

Here’s what you need to realize: These groups will be getting bits and pieces of news about the reorg whether or not you craft that message explicitly.

With that in mind, you should ensure the messaging supports the business strategy, is accurate, and speaks to each party’s specific concerns.

This is the difference between an unplanned, unpredictable experience and an intentional, designed experience. It’s a golden opportunity to show your stakeholders they are a valued part of the organization, and you’ve got your arms firmly around managing the changes. If the right preparation goes into the reorg, you can nip in the bud any misinformation and unnecessary stress, building confidence in your team’s leadership and capability as a whole.

The alternative is to risk spending what trust currency you’ve accrued to date.

The message

Now that you know who you’re talking to, what do you say? It’s idealistic to think that you’ll know all the details when you begin planning the reorganization–but you do need to initiate your communications plan as close to the start of planning as you can.

Start by crafting general messaging that indicates the why–the logic being the necessity and desired benefits of the reorg. This should be high level until more details are known. If you know enough about the how to paint a low-res picture, do it.

A little bit of information that’s transparent and honest will go a long way–but take care not to make promises you can’t keep. Things can and will change, so own up to the reality that dates and other details are very much in flux to help you avoid having to take back your words when deadlines shift down the road.

As you approach major milestones in the reorg process and as the details solidify, provide appropriate communications to your audience groups–and do so again once the changes have been rolled out. This may seem like a lot of effort, but rest assured your people are asking questions. It’s up to you to address them proactively.

If a milestone date changes–and it will–the audience who’s been paying attention will still be looking to that date unless you update your wayfinding (in the form of project timeline communications). Without this careful attention to detail, you’re sharing bad information–perhaps more damaging than no information at all.

When the rubber meets the road

Inevitably, one question that will come up repeatedly throughout a reorg is “When does all this actually happen?” In other words, when do we start following the new processes, change how we route requests, start doing this and stop doing that?

For both logistical and psychological reasons, knowing how and when transitions will take place is vital. Often the difference between a stakeholder being stressed out

(perhaps becoming a vocal opponent of the changes) versus being calm and confident is the company’s honest commitment to consciously bridging the transition with trained, capable support.

This could be as simple as a window of time during which existing persons or processes can continue to be called upon for support or as complex as an official schedule that shows specifically how and when both the responsibilities AND expectations of the audience segments will change.

Usability research

It’s not like you can do A:B testing with a reorg. You can, however, do some polling when the initial reorg information is shared, then midstream, and again after the reorg is complete.

Why do this research? As with any project, from your first person perspective, reorg elements might seem obvious–or you may have overlooked some pretty big pieces. Talking with your ‘users’ can be illuminating and also sends the message that their input is desired and valued.

While some reorgs are expressly designed to reduce overhead/staff, reorgs are not always about cutting heads. Often-times it’s a shuffle of resources (people), and if the right discussions happen you can guide that process to a win win.

Using a handy list written by a gentleman you may know of, here are some dimensions co-opted for our use. Employ these as you see fit to generate interview material and discover how well your company reorg experience has been crafted.

Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?

We can ask our participants what they took away from the reorg communications they were sent. This includes actual group or 1:1 meetings, formal documents, emails, etc.

Find out if the materials conveyed the message so the transition was easy to understand. Did they grasp both the high-level view and the granular details? (In other words, overall strategy and the specific impact to them.)

Efficiency: Once users have learned the design, how quickly can they perform tasks?

If the folks you’re polling have been assigned specific assignments in the reorg, ask early on if they fully understand their instructions and if they could have added any insight that might have decreased task costs or durations. Midstream or late in the game you can follow up to see if those instructions turned out to be clear and accurate enough for the tasks to have been carried out efficiently.

Did task instructions have the most time-saving sequence? Were there steps left out of the tasking communications that had to be discovered and completed?

Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?

Remember the telephone game? Someone makes up a story and then each player passes the story on to the next by whispering. When the story makes it back to the author, the details have changed–it’s a different story.

When those involved in a reorg talk with others, they’ll pass along what they know. The simpler the story and the more they’ve understood it, the less you’ll lose in translation.

Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?

A successful reorg requires a lot of work and collaboration between groups. Mistakes tend to be costly and have a ripple effect, becoming harder to correct as time goes on. The critical path of these big projects is placed at risk due to missteps due in large part to (wait for it) learnability and memorability, or due to errors introduced by people who have been put off by the lack of efficiency of the reorg process and attempt to forge their own path.

Another source of error is in failing to communicate enough timely information about role changes to employees and contractors. Major change breeds anxiety, and in a job market where workers have the power and employers are constantly on the prowl for good (and hard to find) talent, it’s a mistake to risk wholesale attrition.

Avoid this error by honestly and accurately communicating dates and the likelihood of roles continuing as is or with changes. If roles are going away, be transparent about that too. Better to maintain trust and respect with clear messaging about terminations than to leave folks in doubt and unable to plan for their future.

Satisfaction: How pleasant is it to use the design?

If the reorg does NOT leave a bad taste in everyone’s mouth, and if the stated project goals have been met, you’re doing it right. Reorgs happen for a reason, typically because something’s suboptimal or simply broken. Ultimately, everyone should pull together and work towards a positive outcome resulting in better workflow, lowered cost of doing business, increased job satisfaction, and, of course, $$$.

Moving on

Regardless of your role in the company and the reorg, consider whether or not you can use your UX superpowers to make the entire process less painful, easier to understand, and more likely to succeed.

Note: Also published at Boxesandarrows.com