People, skills and culture in transformation

Every transformation is, in the end, many people changing what they do every day. Larchmont's operating model, platform and AI governance will deliver nothing if service desk analysts do not trust the new workflows, if infrastructure engineers resist moving into a platform team, if managers keep demanding status reports in the old format, or if staff hide problems because they fear blame. This lesson covers how people experience change, how to lead it, how to build the skills a digital and AI-enabled organization needs, and how culture shapes whether any of it lasts.

How people experience change

People do not resist change as such; they resist loss, uncertainty and being changed without a say. A service desk analyst told that a virtual agent will handle a third of contacts may hear 'your job is at risk', even if leaders intend to redeploy people to more interesting work. An infrastructure engineer moving into a platform team may lose a familiar role and status. Understanding these reactions, rather than labelling them as resistance, is the starting point for leading change well.

William Bridges distinguished change (the external event, such as a reorganization) from transition (the internal psychological process people go through). Transition has three phases: an ending, in which people let go of the old way; a neutral zone of confusion and experimentation; and a new beginning, in which they commit to the new way. Leaders often announce the new beginning while people are still processing the ending. Acknowledging what is being lost, and supporting people through the neutral zone, makes adoption faster.

These models complement each other. Larchmont used Kotter's steps to structure leadership activity, ADKAR to diagnose why particular teams were slow to adopt new practices, and Bridges to plan support for people whose roles were changing most. For example, ADKAR surveys showed that warehouse IT staff had awareness and desire but lacked knowledge of the new pipeline, so training, not more persuasion, was the fix.

Leading change

Leaders shape transformation more through what they do than through what they announce. People watch whether leaders use the new reports, attend product reviews, protect teams from old-style demands, and react calmly when experiments fail. A leader who praises 'fail fast' but punishes the first failed release teaches everyone to hide risk.

Communication must be frequent, two-way and honest. People want to know why the change is happening, what it means for them, what will stay the same, what is still undecided and how they can contribute. Communicating uncertainty openly ('we have not decided how the service desk will be organized in year three; here is how we will decide and when') builds more trust than false certainty. Larchmont's CIO held monthly open sessions with LTS staff, published every steering group decision within a week, and ran an anonymous question channel whose answers were posted publicly.

Skills for a digital and AI-enabled organization

The skills a service organization needs are shifting. Routine tasks are increasingly automated, while demand grows for product thinking, user research, data literacy, automation and scripting, cloud and platform engineering, security, and the ability to work with AI tools critically and safely. So-called durable skills, such as communication, collaboration, problem solving and adaptability, matter more as technical tools change faster.

AI literacy deserves special mention. Staff who use AI need to understand what it can and cannot do, how to check its outputs, what data must not be shared and when to escalate. The EU AI Act includes an obligation, applying since February 2025, for providers and deployers of AI systems to take measures to ensure a sufficient level of AI literacy among staff dealing with those systems. Even where no law requires it, AI literacy is a practical control against the risks covered in lessons 7 to 9.

# Skills gap analysis for LTS (invented ratings on a 0-4 scale)
required = {"workflow automation": 3, "infrastructure as code": 3, "observability and SLOs": 3,
            "product and UX thinking": 2, "data literacy": 3, "AI literacy": 3, "coaching": 2}
teams = {
    "service desk":   {"workflow automation": 1, "infrastructure as code": 0, "observability and SLOs": 1,
                       "product and UX thinking": 2, "data literacy": 1, "AI literacy": 1, "coaching": 1},
    "infrastructure": {"workflow automation": 2, "infrastructure as code": 2, "observability and SLOs": 2,
                       "product and UX thinking": 0, "data literacy": 2, "AI literacy": 1, "coaching": 1},
    "app support":    {"workflow automation": 1, "infrastructure as code": 1, "observability and SLOs": 2,
                       "product and UX thinking": 1, "data literacy": 2, "AI literacy": 1, "coaching": 1},
}
for team, have in teams.items():
    gaps = {s: max(0, required[s] - have[s]) for s in required}
    total = sum(gaps.values())
    top = sorted(gaps.items(), key=lambda kv: -kv[1])[:3]
    print(f"{team:<15} total gap {total:>2}  biggest: " + ", ".join(f"{s} ({g})" for s, g in top))
overall = {s: sum(max(0, required[s] - t[s]) for t in teams.values()) for s in required}
print("organization-wide priority:", max(overall, key=overall.get))

service desk    total gap 12  biggest: infrastructure as code (3), workflow automation (2), observability and SLOs (2)
infrastructure  total gap  9  biggest: product and UX thinking (2), AI literacy (2), workflow automation (1)
app support     total gap 10  biggest: workflow automation (2), infrastructure as code (2), AI literacy (2)
organization-wide priority: infrastructure as code

The gap analysis, with invented ratings, suggests AI literacy and workflow automation as organization-wide priorities, with infrastructure as code concentrated in the service desk and product thinking in infrastructure. Larchmont turned this into learning paths: a mandatory two-hour AI literacy course for all staff, a six-week automation academy for service desk analysts, and pairing infrastructure engineers with designers during platform discovery.

Building capability, not just training

Courses alone rarely change practice. People learn most by doing real work with support. Effective approaches include learning on the job with coaching, pairing and rotation between teams, communities of practice where people with a shared skill meet to share methods, internal champions who help colleagues, and time explicitly protected for learning. Enabling teams, described in lesson 10, exist precisely to build capability in other teams and then step back.

Larchmont reserved 10 % of every team's capacity for learning and improvement, created communities of practice for automation, observability and product management, and trained 24 AI champions across the company who answered colleagues' questions and fed common problems back to the AI governance group. Champions were chosen for credibility with peers, not seniority.

Culture

Culture is the shared assumptions, values and habits that shape how people behave when nobody is telling them what to do. It is hard to change directly; it changes as people repeatedly experience new behaviours working. The sociologist Ron Westrum described three organizational cultures by how they handle information: pathological (power-oriented, information is hoarded, messengers are punished), bureaucratic (rule-oriented, information flows through channels) and generative (performance-oriented, information flows freely, failures lead to inquiry). DORA research has found generative cultures associated with better delivery and organizational performance.

Psychological safety, a concept developed by Amy Edmondson, is the shared belief that a team is safe for interpersonal risk-taking: people can ask questions, admit mistakes and raise concerns without fear of humiliation or punishment. It is essential for learning from incidents, for reporting AI problems and for honest measurement. Blameless post-incident reviews, which focus on how the system allowed a failure rather than who to blame, are one of the most practical ways to build it.

Change fatigue and wellbeing

Transformations ask people to learn new ways of working while still delivering the old ones. Too many simultaneous changes cause change fatigue: cynicism, disengagement and burnout. Signs include falling survey scores, rising sick leave and turnover, and passive compliance. Leaders can limit the number of concurrent changes for any one team, sequence changes thoughtfully, stop initiatives that are not working, and recognize the extra effort people are making.

Larchmont tracked a simple 'change load' for each team: the number of significant changes affecting it in a quarter. Teams with more than three were flagged, and the steering group delayed or dropped lower-priority changes for them. In wave two this meant delaying the new time-tracking tool for the service desk, which was already absorbing the virtual agent and the automation academy.

Collecting data about employees during a transformation, such as device telemetry, AI usage logs or productivity measures, raises privacy and employment questions. In Ontario, employers with 25 or more employees must have a written policy on electronic monitoring of employees, describing whether and how they monitor and for what purposes. Federally regulated employers and private sector employers in provinces such as British Columbia, Alberta and Quebec are subject to privacy laws that cover employee personal information. Transparency, proportionality and limiting use to stated purposes are the common thread.

Career paths in a changing organization

People commit more readily to change when they can see a future for themselves in it. Larchmont published career paths for the new roles: service desk analyst to automation specialist or knowledge lead; infrastructure engineer to platform engineer or site reliability engineer; application support to product engineer; change manager to control designer or risk analyst. Each path listed the skills needed, the learning available and examples of people who had already made the move.

The service desk illustrates the shift. As self-service and the virtual agent absorbed routine contacts, the desk's volume fell by about a fifth in the first year, but the remaining contacts were more complex and took longer. Analysts who joined the automation academy built 37 workflows in their first six months, from scanner re-provisioning to new-starter setup, and two became full-time members of the platform team. Others specialized in high-value customer accounts. No analyst lost their job, and voluntary turnover on the desk fell from 24 % to 15 %, which leaders attributed partly to the visible career paths.

Managers' roles change too. In a product model, many decisions move to teams, and managers spend more time coaching, removing obstacles, developing people and connecting teams to strategy. Larchmont ran a leadership program for its 40 IT managers covering outcome-based management, coaching conversations, running blameless reviews and supporting people through transition. Some managers chose to return to specialist roles, which the company treated as a respected choice rather than a demotion.