The ultimate goal is extraordinary quality. The synthesis produced by cogworks-encode should be difficult to distinguish from something written by someone with 20 years of domain expertise, and the resulting skill should produce expert-level performance on novel inputs, not just on variations of the training sources.

Reaching acceptable is relatively easy, but reaching extraordinary requires solving the deeper problem of whether the synthesis captures how experts think, not only what they produce.

Although this post focuses on the specific challenges of the cogworks pipeline, it touches a broader question of how to bridge the gap between knowledge and action in AI systems in a way that generalises beyond the training data.

I’m still figuring out how to reliably hit verifiable quality with cogworks. Since context is loaded by the same model doing the synthesis and skill generation, there’s a risk that my tests confirm the implementation rather than the intended behaviour. So, wherever I make claims about quality or generalisation, read them as theoretically grounded but not externally validated. I’m working toward testing cogworks-generated skills against “best-in-class” skills via SkillsBench, but I’m not there yet.

For cogworks, it hinges on quality at both stages of the pipeline:

1. Stage 1 – Knowledge synthesis (cogworks-encode): synthesising diverse sources into a coherent, comprehensive knowledge base.

2. Stage 2 – Skill generation (cogworks-learn): distilling that synthesis into a lean, immediately usable agent skill.

Synthesis captures what’s known and wants to be comprehensive (capture everything, but with no redundancy or unresolved contradictions). On the other hand, skill generation captures what to do and demands ruthless distillation. The second stage depends entirely on the first, but they require almost opposite cognitive operations.

The knowledge structure that works for understanding doesn’t always work for action. You can’t fix a bad synthesis with good skill-writing either; if the synthesis missed something critical or got a contradiction wrong, the skill inherits that flaw, and even a strong synthesis can fail at the skill stage because distillation is inherently lossy (strip away the wrong thing and you remove the mechanism that drives good decisions).

What Makes an Expert an Expert: Tacit Knowledge

So how does expert knowledge differ structurally from novice knowledge?

Explicit knowledge (know-what) can be written down. Tacit knowledge (know-how) is what experts develop through practice and often cannot fully articulate. The expert acts without explicitly reflecting on every principle involved.

AI synthesis extracts explicit knowledge well - facts, relationships, and patterns are all there on the page. But the most valuable layer in many domains is tacit judgment about edge cases, intuitions about when rules apply or break down, and when to ignore them. You can memorise every chess book ever written and still lack Kasparov’s intuitive grasp of the game.

When synthesis captures only explicit patterns, the resulting skill performs well on familiar cases but degrades on edge cases and novel situations that require underlying judgment. This is where a ceiling appears, since document synthesis is constrained by what is expressed or at least defensibly inferable from the available material.

Extraordinary quality here requires moving beyond extracting what experts say, to approximating the structure of their reasoning.

Conceptual Models and Decision Principles

What I’m learning is that the real differentiator is the conceptual model embedded in the source material. Capturing facts and examples isn’t enough, you need the underlying structure of thinking that produces correct decisions.

Experts have internalised conceptual models. In many domains, what drives expert judgment is the conceptual model beneath the rules. When they teach or write, they may describe rules or patterns, but what actually drives good judgment is the underlying model that they subconsciously preserve.

To ensure extraordinary synthesis quality, the focus must shift toward extracting decision principles of the form: “When X, do Y, because Z.” When sources conflict, synthesis must resolve the tension by explaining under what conditions each approach applies, rather than merely flagging disagreement.

Structural Rationale: The Mechanism-Level “Why”

“Standard” synthesis (using an AI agent without the cogworks toolchain) usually extracts surface rationale, i.e. the stated justification (“write tests first because it improves API design”).

Structural rationale captures the mechanism, e.g. “write tests first because otherwise implementation details shape test structure, causing tests to validate structure rather than intended behaviour.”

The structural “why” enables you to correctly identify when the pattern doesn’t apply because you understand what the pattern is protecting against. The surface “why” doesn’t do this.

The distinction matters enormously for agent skill generalisation. A skill built on surface rationale performs well on cases resembling the sources. A skill built on structural rationale should perform better on novel cases because it understands what the rule is defending against. It knows why the rule exists, not just that it exists.

The problem is that structural rationale is often absent from the sources. Authors describe what they do and why it works, but rarely articulate the mechanism by which it prevents failure.

Although synthesis can’t extract what isn’t there, it can probe for it.

The Execution Challenge: From Synthesis to Skill

The cogworks workflow runs synthesis through an 8-phase process that culminates in narrative, then extracts a Decision Skeleton (the bridge between knowledge structure and decision structure), gates on user review, applies skill-writing expertise, and validates the output (see the system deep dive here).

Compared to naive prompting, this scaffolding improves structure and conflict resolution, and this is also where I initially tried to enforce discipline with the “Expert Subtraction Principle” in cogworks-encode:

### The Expert Subtraction Principle

**Core Philosophy:** Experts are systems thinkers who leverage their extensive knowledge and deep understanding to reduce complexity. Novices add. Experts subtract until nothing superfluous remains.

**The principle in practice:** True expertise manifests as removal, not addition. The expert's value is knowing what to leave out. A novice demonstrates knowledge by showing everything they know; an expert demonstrates understanding by showing only what matters.

In hindsight it’s obvious why this alone wasn’t sufficient. The model doing the synthesis isn’t an expert in any of the source reference domains, so it can’t reliably subtract what’s non-essential without additional safeguards, because it doesn’t independently know what matters.

A more deliberate approach was to make subtraction explicit. The pipeline uses a Compression Guard that cross-checks any removed content against a Critical Distinctions Registry (CDR) — a catalogue of non-negotiable distinctions extracted before compression begins — and a Pre-Review Coverage Gate that maps every source capability to the synthesis output before user review. For example, if a source distinguishes between “testing behaviour” and “testing implementation,” that distinction is logged in the CDR and any compression that collapses those into one concept is flagged before it reaches the skill stage.

This reframes subtraction as evaluation rather than “intuition”, which improves the synthesis, but still doesn’t solve the problem of how to make the leap from synthesis to skill since generating a skill is not a simple, additional compression run on the synthesis. Skills must activate at the right moment, apply correctly in context, resist deviation pressure, and generalise beyond the training sources.

The SKILL.md format handles activation and application, but generalisation beyond the source material is where reliability most often degrades.

How cogworks Is Trying to Bridge the Gap

Currently, cogworks attempts three concrete strategies:

1. Explicitly extract the reasoning behind each pattern - why it works and what fails if you ignore it.

2. Capture boundary conditions - when and how experts would deviate from standard rules.

3. Generate adversarial test cases to probe edge cases and structural gaps.

Selection, however, remains a bottleneck. A synthesis may contain ten nuanced patterns, but the Decision Skeleton distils these to the five to seven most important decisions. This by its very nature is “LLM-subjective”. Choosing which rules are load-bearing requires domain judgment that cannot be fully automated.

The best solution I have for this at the moment is to generate hard, edge-case questions before reading the sources. Then, after synthesis, get the agent to check whether those questions are answered convincingly. Gaps often reveal missing tacit knowledge, but this is not a robust solution since guarding against context pollution and drift remain an unsolved problem as I’ve already mentioned.

For skill generation, the key bridging artifact is the Decision Skeleton — a structured extraction of the most important decisions, each with a trigger, options, right call, failure mode, and boundary conditions. The skill is then built around this skeleton, rather than the narrative structure of the synthesis.

Ideally, the skill would then be tested against novel cases not covered in the sources, but proper evaluation requires domain expertise, which creates a bootstrapping problem. As an approximation, we generate novel cases from the synthesis itself and check whether the skill handles them correctly.

Recursive Improvement and the Tacit Ceiling

The cogworks pipeline itself is a single linear pass. There’s no built-in iteration loop, but you can re-run cogworks on the same sources (or feed its output back as a source) to iteratively improve quality. In practice, this manual recursive improvement often surfaces additional explicit structure from the sources (though it can also amplify existing blind spots if not carefully reviewed), but does not break through to tacit knowledge. Once the synthesis stabilises across iterations and the remaining gaps are purely tacit, you hit the wall.

When the synthesis plateaus and what’s missing is the kind of thing you’d need to ask domain experts directly to uncover, that’s when I stop.

On the meta-question of whether recursive improvement actually works, I honestly think so. The first round fixes obvious quality gaps like missing reasoning and poor structure. The second round tightens things up by removing non-essential elements and sharpening the decision rules. Beyond that, returns diminish because the synthesis is now capturing all the explicit knowledge available and what’s left is tacit knowledge that more iterations won’t unlock without better source material.

So, in my experience, 2-3 rounds tend to capture most of the gains. Anything beyond that and you start rephrasing the same content.

Conclusion: Extraordinary Quality and Its Limits

Extraordinary synthesis means capturing the structural reasoning behind decisions, not merely restating documented patterns. Extraordinary skills must enable correct decisions in novel edge cases, and not be confined to familiar ones.

The gap between good and extraordinary comes down to how deeply the synthesis explains the underlying reasoning beyond the surface patterns, how well the decision skeleton identifies what choices the skill needs to enable, and whether the resulting skill generalises beyond the specific cases in the source material.

But there is a ceiling.

In domains where knowledge is highly explicit (API specifications, protocol documentation, well-documented procedures) the ceiling is high. In domains dominated by tacit judgment (system design, architecture decisions, anything where the interesting questions are “when” rather than “how”) the ceiling is lower, and pipeline refinement alone cannot extract what the sources never contained.

And across all of this, the hardest problem by FAR, remains objective, external validation.

I’ll keep working on it.

Attribution: This Post’s Image is Courtesy of Yulia Gapeenko

As I wrote in this LinkedIn post, I’ve become completely enamoured with using AI to build tools for AI so those tools can help AI build better tools for AI.

It all started with two problems. The first problem is that I can’t keep up with the pace of change in the AI space. It’s so rapid that by the time I learn a new technique or best practice, it’s already outdated. The second problem is that I like building tools, but creating AI tools requires up-to-date expertise in the domain, which gets us right back to the first problem.

I’m forever playing catch-up, which meant the only way to scratch my tool-builder itch was to eliminate myself as the weakest link, i.e. substitute myself with AI, and build tools that could keep themselves up to date.

And that’s how I got to AI to build AI tools to improve the AI tools built by AI.

Recursion for the win.

For this, I needed two things: a repeatable mechanism for synthesising knowledge from multiple sources, and another for writing reusable AI skills based on that synthesis. If I could encode this process, I could use those tools to iteratively improve themselves and stay up to date.

My first attempts gave rise to the unusable library tool I wrote about in Complexity Cascades. Starting fresh after that humiliation, I pointed Claude Code at its own documentation on agent skills and asked it to encode the expertise in, well, a skill-writing skill (unimaginative, but practical).

I followed that up by, again using Claude, researching and designing a workflow for comprehensive knowledge synthesis from multiple sources (documents, URLs, whatever), and used skill-writing to create a topic-synthesis skill based on the results.

You can probably see where this is going, but I then ran topic-synthesis over the same documentation used to create skill-writing. This produced a more thorough synthesis of skill-writing expertise, which I then used to assess and improve skill-writing itself. With the improved skill-writing skill, I reviewed and improved topic-synthesis, and so on.

We were off to the races.

At this point there was still too much human-in-the-loop, so cogworks was born. Not only was the name cooler, but I now had an agent that orchestrated the whole process, calling on cogworks-encode (the evolved topic-synthesis) and cogworks-learn (the evolved skill-writing) as its component skills.

Of course, I wasn’t done yet. AI tools are only as good as the prompts that define them, so I needed to check the quality of the cogworks tool definitions. If these were suboptimal, that would have implications for all the tools generated downstream. Naturally, I fed it documentation on prompt engineering, created an advanced-prompting skill and used it to audit the cogworks (v1) tools to see if they themselves followed the prompting principles they encoded in the advanced-prompting skill.

They didn’t.

Which meant the advanced-prompting (v1) skill’s assessment was unreliable output from an unreliable tool that was a product of the unreliable tool kit it had just improved.

And yes, you guessed it.

I regenerated cogworks-encode (v1) with the prompt-improved cogworks-learn (v2) skill, then regenerated the skills creation and advanced prompting synthesis from source using the freshly generated cogworks-encode (v2), then generated cogworks-learn (v3) using cogworks-learn (v2) and the updated skill-writing synthesis, then generated advanced-prompting (v2) with the updated cogworks-learn (v3) skill...

It’s hard to keep typing through the tears...

The Point - Bootstrapping and Dogfooding

The point of all this isn’t to brag about how I suffered through a recursive improvement loop for my AI tools. The point is this:

If your tools can audit themselves, they can improve themselves.1

I wish this was a revolutionary insight, but alas, it’s a well-known principle in software engineering and AI research that has been around for decades.

In compiler design, the concept of self-hosting has long been considered a milestone of maturity in compiler design. Ken Thompson’s 1984 Turing Award lecture, “Reflections on Trusting Trust,” explored the implications of a compiler that compiles itself. If your tool can process its own output, you’ve established a powerful consistency check. Of course, there is a world of difference between a compiler and a prompt-driven AI tool, but the underlying principle of self-application as a quality check is the same.

In software engineering more broadly, the practice is called “eating your own dogfood”. The phrase traces back to Microsoft in 1988, where manager Paul Maritz used it to describe the practice of internal teams using their own pre-release software. Harrison’s analysis in IEEE Software argued that dogfooding creates one of the strongest quality feedback loops available when the people closest to a system’s design become its most demanding users. If you won’t use your own product, why should anyone else?

My Take-Away

AI-assisted software engineering is a strange new world that I find simultaneously fascinating and terrifying. So much of it feels like trying to catch smoke but, for now, I think iterative self-evaluation and self-improvement is the way to go when building AI tools with AI.

One last thing, however, to avoid spiralling into insanity: know when to stop. The recursive improvement loop is powerful, but unlike compiler self-hosting, which has a natural termination point (the compiler either compiles itself or it doesn’t), prompt-driven tools don’t reliably converge to a fixed point. LLMs aren’t deterministic. Each iteration of the improvement loop produces different results, not converging results. The advanced-prompting skill that audits cogworks today will generate different observations than the one that audits it tomorrow, even if nothing else has changed.

Hospedales et al.’s 2022 survey on meta-learning (the study of systems that improve their own learning processes, i.e. learning how to learn better by applying learning principles to the learning process itself) frames the ability to learn how to learn, not just what to learn as a fundamental capability. The challenge is knowing when the meta-learning starts producing diminishing returns.

With each iteration I underwent with cogworks, things genuinely improved. The temptation to keep going is partly because of the impossible pursuit of perfection, but also because I could see how another pass would improve them further.

For now, however, I’ll stop chasing the dopamine hits and use cogworks for what it’s intended.

Happy coding!

Note: This is a personal reflection on a specific experience with AI-assisted software development, but the lessons are broadly applicable to AI collaboration. I’m sharing my (slightly embarrassing) story to highlight, and remind myself once again, of the importance of clarity in our interactions with them.

I asked Claude Code to review an implementation for a library tool I’d built using Claude Code itself. The library was intended to work as a “content retrieval -> synthesis -> information retrieval” layer for use with AI tools (such as Claude Code) when building AI tools (I know), but it was ridiculously over-engineered. 20,000 lines of code to manage content from 11 URLs. Admittedly, the plan was to extend the content source base beyond that, but here we were.

Claude responded with a 79,000-character critique. Sixteen issues across four tiers. Forty-two thousand characters of improvement plans. It was delivering the same mess it was critiquing. The analysis was so thorough it was utterly useless.

It didn’t take me long to realise that I’d created the conditions that got us here in the first place, and which ultimately culminated in this outcome when I asked Claude to “review this library” without constraining what that meant and what I was after.

This got me thinking about how lack of clarity cascades into complexity.

Engaging deeply with vaguely defined goals spiral into chaos as every iteration in an unbounded context leads to ever greater divergence. If you don’t know what you’re trying to achieve, you can’t evaluate whether you’re getting closer to it. If you can’t evaluate whether you’re getting closer to it, you have no choice but to keep going in an attempt to cover every possibility. The only way out is to consciously interrupt the cycle.

The Complexity Cascade in Action

The example here relates to software engineering, but I believe the lessons are generally applicable to AI (and even more generally applicable to leadership and “good” thinking, but let’s keep it tight).

To recap:

1. The system was spectacularly over-engineered. Twenty thousand lines of code. Cache layers, TTL management, scheduled refresh, quality gates. A tonne of infrastructure for a problem that didn’t exist.

2. The analysis inherited the complexity. Claude delivered a 79,000-character tome (great word, thank you Thesaurus) containing code samples for every recommendation, risk assessments, success metrics, a four-tier priority system. It was the stuff of nightmares.

3. The improvement plan compounded it further. Another 42,000 characters detailing how to fix sixteen identified issues. The proposed solution was as impenetrable as the analysis.

At no point did Claude ask if the system should exist at all. And why would it? I never set clear boundaries, expectations, or quality gates. At this point, I realised that the complexity cascade had been set in motion by my own lack of clarity. I asked it to reassess the implementation after I provided it with a set of “expert principles”, starting with realigning on the objective.

Claude was polite enough not to say this, but I knew that it knew it was all my fault: “This library solves the wrong problem. Consider starting fresh.”

That one’s on me, Claude...that one’s on me.

You Get What You Prompt For

Anthropic’s own prompt engineering guidance puts it clearly: “When interacting with Claude, think of it as a brilliant but very new employee (with amnesia) who needs explicit instructions.”

Vague prompts produce vague (or in my case, encyclopedic) output. Specific prompts produce focused output, and you cannot be specific if you don’t know what you want. I’d asked for a “review.” That’s not a constraint, it’s an invitation to demonstrate comprehensiveness. Claude obliged. Word choice matters.

Geoffrey Litt makes a similar point in his work on LLM-assisted development: the medium of your interaction fundamentally changes what the AI produces. Chat is inherently expansive. Constrained requests are inherently focused.

This got me thinking about what differentiates novices from experts, and what I needed to ask for to get expert results.

Howard Marks captures this distinction in his writing on second-order thinking: “First-level thinking is simplistic and superficial... Second-level thinking is deep, complex and convoluted.”

But there’s a trap here. Deep thinking shouldn’t produce convoluted output. The expert’s job is to do the complex analysis internally and deliver the simple conclusion externally. Novices demonstrate knowledge by showing everything they know. Experts demonstrate understanding by showing only what matters.

The same novice/expert distinction applies to us as AI users. With AI, you are the expert w.r.t. the problem you’re trying to solve and in assessing proposed solutions. I’d been acting like a novice user, and Claude happily obliged by giving me novice level results.

The tragedy in all of this is that I already know this from experience. I know and apply the principles of clear communication in my leadership role (and understand how this affects AI. I mean, I was even cheeky enough to write about it here...the shame...). I have significant experience in training and coaching others to become better “doers” (indeed another thing I’ve written about...the shame compounds...).

And yet, it turned out I hadn’t internalised all of this in the context of AI collaboration until I started going really deep and got my ass kicked.

If I have any credibility left at this point, then allow me to share the lesson:

Complexity is contagious, but the infection requires your consent.

When you ask AI to analyse something complex, the analysis will tend toward matching complexity. When you ask it to review something over-engineered, the review will inherit the over-engineering. If you don’t know what you need, there’s no chance (yet) that AI will figure it out for you.

You don’t need to know the solution to your problem, but what you absolutely must work hard at is understanding and communicating the problem you are trying to solve (I can basically hear the ironic chuckles of Product Managers everywhere as I type this).

In this, working with AI is really not that dissimilar from working with people.

Sometimes, you need to relearn the old lessons the hard way.

So, let’s start with something I think most experienced professionals have had some exposure to - leadership development.

Training is the obvious entry point to leadership development programs. The default implementation is to line up a few workshops, the latest and greatest leadership model (ideally with a catchy acronym), chuck in current consultant terminology and a feel-good session at the end of the final day, and you’ve got a program.

And this, of course, is fine as a starting point. Learning terminology and concepts are important (it’s hard to research something if you don’t know what it’s called). There’s nothing wrong with theory and frameworks. But theory rarely survives first contact with the real world. Knowing the “right thing to do” in a textbook situation isn’t the same as knowing how to act in this one, with these people, this history, and this mess of priorities, pressures, and politics.

In theory, there is no difference between theory and practice; but in practice, there is. - Attribution Disputed

Here is a simplistic analogy - when you learn to drive, you can ace the learner’s test after reading the handbook front to back, but all that knowledge disappears the moment you sit behind the wheel, overwhelmed by pedals, knobs and levers. Suddenly the rules aren’t enough. You need awareness, confidence, adaptability. You need practice. And you need someone alongside you while you figure it out.

Stepping back briefly to training. The Kirkpatrick model, widely used to evaluate training, defines four levels of impact: Reaction, Learning, Behaviour, and Results. Most training comfortably ticks off the first two. However, actual behaviour change and measurable outcomes are much harder to achieve.

That’s where coaching steps in.

Coaching isn’t about handing people more models or filling in skill gaps on a competency matrix. It’s about helping people wrestle with the complexity of their own context and apply what they know in ways that work. It bridges the knowing–doing gap:

• Coaching helps leaders connect theoretical learning to practical application by personalising insights and developing concrete action plans for behavioural change.

  • Passmore, J. (2015). Leadership coaching: Working with leaders to develop elite performance. Kogan Page Publishers.

• Coaching enhances self-awareness and challenges existing beliefs, moving unconscious thought patterns to conscious consideration, which is crucial for leaders to understand their impact and adapt their responses.

  • Anthony Grant, S. O. (2019). A Brief Primer for Those New to Coaching Research and Evidence-Based Practice. The Coaching Psychologist, 15(1), 3–10.

• Coaching develops behavioural flexibility by enabling executives to expand their repertoire of thoughts and actions through structured practice and experimentation.

  • Good, D., Yeganeh, B., & Yeganeh, R. (2010). Cognitive Behavioral Executive Coaching: A Structure for Increasing Leadership Flexibility. OD Practitioner, 42(3), 18–23.

• Coaching helps bridge the gap even when there is a time lag in the manifestation of learning and behavioural change, providing ongoing support for the incubation and consolidation of new insights.

  • Spence, G. B., Stout-Rostron, S., Reenen, M. V., & Glashoff, B. (2019). Exploring the delayed effects of leadership coaching: A pilot study. Coaching : An International Journal of Theory, Research & Practice, 12(2), 125–146. https://doi.org/10.1080/17521882.2019.1574308

So, if you’re involved in leadership development and wondering why training isn’t delivering the impact you hoped for, ask this: “Who’s helping these leaders figure out how to apply what they’ve learned in the wild?”

If no one is, coaching might be the missing piece.

It’s worth reading up on.

Or better yet, reach out.

"I keep hearing from executives that they expect that a new generation of "AI natives" will show them how to use AI. I think this is a mistake: 1) Our research shows younger people do not really get AI or how to integrate into work 2) Experienced managers are often good prompters" - link

This got me thinking about how hard good managers work at the wordsmithing required to achieve clarity in the workplace. Particularly prevalent post-pandemic is written communication due to the shift to remote work, part-time or otherwise. Crafting precise instructions, objectives, constraints, or feedback is a skill experienced managers often get to exercise under these conditions as success depends on it. Many of us have learned (or certainly will) the hard way that George Bernard Shaw was 100% correct when he said: "The single biggest problem in communication is the illusion that it has taken place."

Younger employees are often expected to be "AI natives" due to their familiarity with technology and social media platforms. However, while they may know how to use these tools, their understanding of strategically integrating AI into complex work environments is less developed. In contrast, experienced managers have had years to hone their communication skills through trial and error. It is not surprising to me that these written communication skills translate well to AI prompting as I am reminded of a silly poem in one of my undergraduate computer science textbooks that has proven true repeatedly in my software engineering career:

"I really hate this damned machine, I wish that they would sell it,

it never does quite what I want, but only what I tell it!"

This rings especially true with Large Language Models (LLMs), where even slight differences in phrasing can drastically change outcomes. Since these systems are fundamentally probabilistic word prediction engines (a simplification but valid for this discussion), at a basic level, LLMs receive input, tokenise it (breaking it into pieces), and use those pieces to predict the most likely next token to produce the output. In this context, it makes sense then that seasoned managers, who have mastered clear articulation through experience, have an edge in "prompt engineering". However, this advantage might not last as LLMs and AI systems improve in understanding vague or ambiguous inputs.

Of course, integrating AI into the workplace is not solely the domain of any single age group. While experienced managers bring strategic insight and communication expertise, younger employees contribute enthusiasm, adaptability and out-of-the-box thinking. The true disruption of AI in the workplace will only come once we leverage it not merely as an enhancement to our current ways of working but as a means to unlock novel ways of working previously unimagined.

I bet it won't be the experienced managers who figure out the cheat codes.

Additional Reading & References

Google | Overview of Prompting Strategies

Atlassian | The Ultimate Guide to Writing Effective AI Prompts

OpenAI | The Art of AI Prompt Crafting: A Comprehensive Guide for Enthusiasts

I was bored for all of 5 minutes when I noticed the craftsmanship of one of the pencils and suddenly found myself intrigued. The quality of the products and manufacturing far surpassed my expectations. They not only looked good but felt good. I started thinking about the engineering, not just of the products themselves but of the factories that produced them. Before I knew it, I was deeply immersed in the brushes (super soft), paints (probably not called paints), powders (remarkably fine), creams (surprising range of textures) and smells (nice ones). This was unexpected fun.

The real insights, however, arrived when I stepped back from the details and observed my wife, an actual user, operating in this environment. The end-to-end user experience was carefully considered, and the store layout made perfect sense, even to a layman like me. The presentation was beautiful, with the various items and colours complementing each other in an appealing visual display that tempted engagement. Every detail conformed to the overall style of the shop, down to the strategically placed cleaning stations, which were exactly where you needed them, with the exact cleaning items required for the products in that section. You literally didn't even need to speak the local language to explore, assess and make purchasing decisions.

What started as an exercise I was less than excited about turned into an inspirational visit with two valuable takeaways directly applicable to my line of work: (1) every single detail matters to your users' experience, especially the ones they aren't consciously aware of, and (2) hire designers who LOVE their jobs, there's no other way you would achieve this level of elegance.

It was also a reminder that one can often find unexpected value in mundane experiences if you slow down and pay attention. So next time you're bored, challenge yourself to consider your situation and surroundings from a different angle.

I've been trying to do just that at times when I might otherwise grab my phone.

Granted, the phone still wins most of the time, but no longer all of the time.

It's refreshing.

Subscribe now

As a long-time fan of MasterChef, my intrigue began with Gordon Ramsay's American version. However, it was the Australian edition, featuring Gary Mehigan, George Calombaris, and Matt Preston, that caught my attention around the time we discovered our eligibility for Australian work permits. Neither of us had ever been to Australia and we knew little more about the place other than it was riddled with notorious drop bears, we realised we were in for some due diligence. Enter MasterChef.

At the time (around 2015), the American version was all about destroying your opponents, placing obstacles in their path, screwing them at every opportunity. It was a culinary "Game of Thrones" with people teaming up against each other, changing alliances and undermining competition. You had to be a good cook, too, but every opportunity to mess with fellow contestants was gleefully embraced. The Australian version, however, stood in stark contrast. Competition remained fierce, but with a markedly different tone. While eager to win, Australian contestants preferred winning on merit rather than tactical eliminations. The game was on, but camaraderie underscored every aspect of the competition as they frequently aided rivals in times of need.

All of this lead me to wonder if this show was perhaps a microcosm of Australian society. Although the group was self-selected in a way (all the contestants love food and cooking, etc.), they were a vastly diverse group from all over the country; there were lawyers, doctors, plumbers, car detailers (that's a job I didn't know), sparkies, chippies, teachers, the unemployed, young, old, men, women, brown, white, black, and so on and so on. The question I asked myself was if the sampling was good enough to be a fair representation of Australian society. It was a gamble, but we bet on this being the essence of "core" Australia.

Now, as we celebrate our seventh year here, my understanding of Australian culture deepens. The ethos of a "fair go" is pervasive, advocating for equal opportunities but not guaranteed success. Australians value giving a "leg up" to those facing hard times, yet they also appreciate the importance of self-reliance, avoiding a culture of indefinite handouts.

While these principles generally foster a positive environment, they are not without their drawbacks. The tall-poppy syndrome, for instance, is an unintended consequence of this pursuit of fairness. Also, the line between a "leg up" and a "hand-out" can become a political battlefield, often skewed in favor of the affluent.

Returning to our MasterChef-inspired insights, it's clear that Australians are fiercely competitive, and they absolutely will beat you in sports, business, or the MasterChef kitchen if they can. However, their readiness to support each other, especially in times of crisis, is evident in the country's track record of community volunteering in response to natural disasters, showcasing a spirit of community and resilience.

Choosing Australia as our home, influenced partly by a cooking show, might seem unconventional. But as I've learned to navigate the nuances of this culture (while still dodging those infamous drop bears), I can confidently say that living here has been a fulfilling experience, flavoured with unexpected lessons from the most surprising sources.

Although my accent hasn't improved (could you call an Australian accent an improvement?), I am grateful that I'm a citizen of the Lucky Country.

Crippling Debt

Uncontrolled or impulsive spending on your credit card will invariably land you in trouble. Failing to consider the implications of interest obligations on a growing, outstanding credit balance leads to pain and, in the worst cases, lifelong indebtedness (it's really enslavement) or bankruptcy.

Similarly, suppose you keep making bad technical decisions without considering the impact on your solution's architecture. As a result, you're racking up maintainability, performance and extensibility debt with no regard to the future, soon finding yourself in a position where you can no longer service the interest, let alone pay back the capital. Your architecture calcifies, and the fear of disastrous regression impacts accompanies even the most conceptually minor feature requests or changes to existing functionality.

This is the category I believe most people automatically assign to technical debt and rightfully fear, but it does not have to be this way.

Debt as Leverage

Another type of debt is a calculated, considered loan that serves your interests. Of course, there is still a risk that the debt can lead to an unfavourable outcome, but you consciously engage with the problem and judge the risk acceptable for the potential gains you foresee.

For example, very few of us have the means to buy a property outright. However, assuming you do your due diligence and consider your ability to service the interest, weather rate hikes, etc., a mortgage could ultimately lead to owning your own property while providing accommodation in the process. Another example is a revolving credit facility you can lean on when cash flow is undesirable. Of course, the preference would be not to dip into the credit. Still, a potentially far more significant loss would be your employees walking out the door when their salaries don't arrive on time (hopefully it's also apparent that paying people on time is the right thing to do).

Analogously, in the software business, there are scenarios where taking a hit w.r.t. technical debt could be beneficial. In my experience, most of these scenarios relate to time to market.

Shortcuts, duct tape, “swamp donkey hacks”, call it what you will. You don't need to like it, and should always strive to be debt free, but the option to take on considered debt to get to an ROI faster should always be on the table.

First, by providing the option of anonymity, you implicitly signal a need for protection from yourself. You effectively say that respondents require a shield against your reaction to their honesty, undermining whatever effort you may be putting into establishing a psychologically safe space and culture of transparency and trust.

Second, anonymous feedback is low quality as there is no way to dig deeper. It is impossible to mine for actionable value through follow-up questions if you don't know who to ask.

Third, anonymity removes accountability. We all have a responsibility for our opinions and must be able and willing to defend them, but this is where it gets tricky. You can challenge feedback and retain accountability without anonymity, but you can also enter perceived (or actual) persecution mode if you push too hard, and it is precisely this risk of persecution that underpins the case for anonymity in the first place. We find ourselves in a Catch-22 situation: we need openness to establish trust, but we need trust to feel safe enough to open up.

This brings me to my fourth and final argument against anonymity. The point of feedback is to gain insight into your organisation where you don't have visibility. Knowing that open critique cannot be safely delivered and that people feel the need for anonymity is insight. The trust issue in this scenario must be addressed as a priority, and anonymity will only perpetuate the status quo. 

So, remove anonymity from your feedback process and be patient. If you don't yet have trust, accept that the majority of feedback you'll receive in the short to medium term will be useless, but, whatever you get, discuss it openly. Celebrate those with the courage to ask the pointed questions or shine light into the uncomfortable corners. Act on the feedback you receive. Consistently. With integrity. And over time, trust will be established.

"I don't think anyone ever gets completely used to conflict. If it's not a little uncomfortable, then it's not real. The key is to keep doing it anyway."

The Five Dysfunctions of a Team by Patrick Lencioni is one of those books I have read multiple times. I wholeheartedly recommend it. However, in this post, I do not want to review or summarise1, but instead, briefly share two takeaways relating to conflict.

I find the interpersonal discomfort of conflict particularly intimidating and thus have to work hard at overcoming my psychological resistance to it. 

However, insight into the second dysfunction of a team, the fear of conflict, is helping me embrace conflict as a healthy and necessary ingredient in building and participating in successful teams.

Moments of truth are best handled face-to-face.

I like writing things down. It allows me time to think, pick my words carefully, and rework my message until it is as clear as possible within the constraints of my vocabulary. It is tempting to believe that the clarity achieved through writing can be passed on to the reader, especially when you know the feedback will be hard to hear. 

As that psychological discomfort starts setting in, you make a case for why a well-crafted, polite and succinct email is the best way to prevent misunderstandings. So, you agonise over every detail of your message and fire it off. No reply. Great! It must be because the message was well received and the feedback taken on board. Discomfort avoided all around, and everyone is in complete alignment again. Job done. 

Unfortunately for you, two weeks later, the issue unexpectedly resurfaces during a one-on-one that started with all the usual pleasantries. You're unprepared, scrambling for balance against the torrent of bottled-up bitterness, digging that hole ever-deeper as you're in full flight mode: "That's not what I meant!"

Moments of truth are best handled face-to-face. Hard conversations are not about elegant turns of phrase; they are about doing the right thing. As soon as I catch myself thinking an exchange will be awkward, I know I need to do the work.

Tension is not conflict.

Wherever people have different ideas or opinions, there is conflict. For the longest time, I had strong associations between conflict and violence and avoided conflict at all costs. Of course, violent or destructive conflict exists, but not all conflict is harmful. 

I have learned that the best innovations and ideas are found at the intersections of diverse perspectives. To get to these intersections, we need to move past the competing interests of our differences. And the way to do that is through productive discussions where the shared goal is to resolve critical issues, i.e. through constructive conflict.

Whether at the team ideation, or individual feedback level, when we fail to engage in constructive conflict, we end up with tension. I think of tension as that "walking on eggshells" experience. It generally starts as a defensive, fearful feeling. However, continued exposure to, and being forced to remain in, a state of elevated stress eventually evolves into resentment. The resentment, in turn, soon gives way to anger, and anger is more likely to result in destructive than constructive conflict.

Moving through tension to a place of harmony requires conflict. Harmony that exists because people hold back on their opinions and honest concerns is not real. Harmony is good only if it comes as a result of cycling through issues and conflict.

"Mine for conflict" in the tension and bring it to the surface.

It is not easy and I still make mistakes, but I’m going to keep at it.

Estimated reading time for this post is 2 min. Enjoy!

"Not to be constantly telling people (or writing them) that I'm busy, unless I really am. Similarly, not to be always ducking responsibilities to the people around me because of 'pressing business'" - Marcus Aurelius (Meditations)

It unnerves me when conversations start with a tentative: "Sorry, I know you are very busy, but I wanted to ask..."

It unnerves me because these conversations represent a perception that my time is somehow more valuable than that of the person in need of my input or assistance. It concerns me as it implies there are things requiring my attention, or areas where I may be of help, that are being swept under the rug or unnecessarily delayed so as to "not bother me". 

Ironically, being thoughtful and considerate of my time and not telling me about problems I could help solve prevents me from doing my job well.

My job is to provide the best possible environment for my teams to do their jobs, which includes unblocking them and helping individuals navigate work or career challenges. 

The fact is, everyone is busy, sometimes to the point of having more on your plate than what is comfortable, and you have a right to your manager's time.

Here is my recommendation on how to lay claim to that time (assuming it isn't immediately pressing):

1. If it's a trivial decision or request, send a DM via your internal messaging system (Slack, MS Teams, whichever). Channels or team chats become flooded, are hard to track and even harder to catch up on, but your line manager should be checking their direct comms a few times a day/daily at the very least.

2. If multiple people are involved, a conversation is needed, and the issue can be resolved via asynchronous means, create a dedicated short-lived channel or group to discuss the topic, or send an email (don't use cc gratuitously but do include action-takers). I find emails slightly easier to categorise and archive as "decision logs", but summarising a chat to share and store for reference via other means serve the same purpose.

3. If it requires discussion or is personal, find a slot in your manager's calendar and book it. I often see people asking via email or chat if they can book an open space. This is what your calendar's scheduling assistant is for, so use it. If you cannot find a slot, ask your manager via DM to make time available to you.

Suffering in silence serves nobody. The sooner an issue is made visible, the sooner it can be resolved.

Keep at it!

William

What did you think of this post? Leave a comment or share your thoughts with me on Twitter or LinkedIn.

Leave a comment

With a few simple substitutions, the essay could easily be from any parent to any child.

Hang in there. Do better!

Will

Listen, son: I am saying this as you lie asleep, one little paw crumpled under your cheek and the blond curls stickily wet on your damp forehead. I have stolen into your room alone. Just a few minutes ago, as I sat reading my paper in the library, a stifling wave of remorse swept over me. Guiltily I came to your bedside.

There are the things I was thinking, son: I had been cross to you. I scolded you as you were dressing for school because you gave your face merely a dab with a towel. I took you to task for not cleaning your shoes. I called out angrily when you threw some of your things on the floor.

At breakfast I found fault, too. You spilled things. You gulped down your food. You put your elbows on the table. You spread butter too thick on your bread. And as you started off to play and I made for my train, you turned and waved a hand and called, “Goodbye, Daddy!” and I frowned, and said in reply,

“Hold your shoulders back!”

Then it began all over again in the late afternoon. As I came up the road I spied you, down on your knees, playing marbles. There were holes in your stockings. I humiliated you before your boyfriends by marching you ahead of me to the house. Stockings were expensive‐and if you had to buy them you would be more careful! Imagine that, son, from a father!

Do you remember, later, when I was reading in the library, how you came in timidly, with a sort of hurt look in your eyes? When I glanced up over my paper, impatient at the interruption, you hesitated at the door. “What is it you want?” I snapped. You said nothing, but ran across in one tempestuous plunge, and threw your arms around my neck and kissed me, and your small arms tightened with an affection that God had set blooming in your heart and which even neglect could not wither.

And then you were gone, pattering up the stairs. Well, son, it was shortly afterwards that my paper slipped from my hands and a terrible sickening fear came over me. What has habit been doing to me?

The habit of finding fault, of reprimanding‐this was my reward to you for being a boy. It was not that I did not love you; it was that I expected too much of youth. I was measuring you by the yardstick of my own years.

And there was so much that was good and fine and true in your character. The little heart of you was as big as the dawn itself over the wide hills. This was shown by your spontaneous impulse to rush in and kiss me good night. Nothing else matters tonight, son. I have come to your bedside in the darkness, and I have knelt there, ashamed!

It is feeble atonement; I know you would not understand these things if I told them to you during your waking hours. But tomorrow I will be a real daddy! I will chum with you, and suffer when you suffer, and laugh when you laugh. I will bite my tongue when impatient words come. I will keep saying as if it were a ritual: “He is nothing but a boy‐a little boy!”

I am afraid I have visualized you as a man. Yet as I see you now, son, crumpled and weary in your cot, I see that you are still a baby. Yesterday you were in your mother’s arms, your head on her shoulder. I have asked too much, too much.

-W. Livingston Larned

Psssst! If you haven't subscribed yet, you can do so here. It's completely free, and you can unsubscribe at any time! You can also find me on Twitter @frontleftwill or connect with me on LinkedIn if you like.

We lived in heavily subsidised army housing in a military base and my dad, an infantryman, would quite happily wake us up at 6 am on a Saturday to mow the lawn "before the day got hot"2.

There was no dishwasher (well, you could make the case that from my parents' perspective, there were five of us), and above the kitchen sink was a small wooden plaque I read so often that the poem is forever etched into my soul:

Thank God for dirty dishes, 

they have a tale to tell. 

While other folks go hungry, 

we're eating very well.

My good fortune, as highlighted by this short poem, wasn't lost on me. However, like most other children, I didn't appreciate the implacable firehose of incoming chores at the time. Alas, there was nothing for it. My folks didn't run our household as a democracy, and hence the path of least unhappiness was simply to get on with it.

Well, if Malcolm Gladwell is correct and 10 000 hours is "the magic number of greatness", then I indeed became great at doing chores. The investment paid off when, as a struggling young adult, I had an epiphany one day as I was slogging through a pile of dishes after a family get-together: the process of organising and cleaning the dishes had a calming effect on me. It was as if, through cleaning the dishes, I was also cleaning my mind of stress and anxiety.

After this realisation, I started paying attention to my inner dialogue whenever I got into any physical labour (or exercise), regardless of the intensity. My personal hypothesis held. Whether I was doing strenuous manual labour or organising my desk, physical work decreased the chatter and calmed the chaos of my mind.

It was a short step from awareness to implementation. Soon, whenever I started feeling overwhelmed by mental churn, I would turn my attention to my environment and find something I could tidy up or clean. Of course, I would not try to deal with big-ticket items in this way as that would likely be escapist ("staring bankruptcy in the face, Sarah took to cleaning out her dresser"), but it works wonders for those general feelings of frustration without a source or that unwarranted annoyance towards life after a hard day at work.

I am not a wellness expert nor a meditation guru, but I know what works for me, and it is this: to get out of my mind, I get into my chores.

It's a safe and easy way to be present in the moment, all while getting things done!

Do the dishes,

Will

Psssst! If you haven't subscribed yet, you can do so here. It's completely free, and you can unsubscribe at any time! You can also find me on Twitter @frontleftwill or connect with me on LinkedIn if you like.

Whether you are a graduate or junior, mid or intermediate, senior, principal or staff software engineer (or developer) is mostly up to the business that employs you. Although there are common themes, there is no accepted industry standard. Instead, companies often have internal, formal career frameworks and some, like DropBox, go so far as to publish theirs publicly.

These frameworks can become rather involved as you try to capture the nuances in expectations between various skill levels, breadth and depth of experience, and responsibilities and, in my experience, most of the confusion falls on the boundary between Intermediate and Senior. Although the length of experience cannot be disqualified as a helpful indicator of seniority, it certainly isn't an accurate measure of the individual. Someone may have ten years of experience on paper but, upon digging, you realise it was really the same year, ten times. Another may only have five years of experience but was so immersed in every aspect of a complex environment that the breadth of their expertise is unmatched.

A more helpful guideline than years of experience is how you think about a role's expectations and its contribution to your team and business.

Here is my take on it.

Junior Engineer

I think of Juniors as an investment in the future and also as a business's way of "giving back" (we all need to start somewhere, and someone must carry that cost). 

The primary responsibility of Juniors is to learn. That's pretty much it. Of course, they can and must contribute with guidance and support, but they are primarily here to learn how software development works in the real world.

Intermediate/Mid-Level Engineers

The central focus for the Intermediate level is technical. They must be proficient enough to complete most software related tasks without help and keep up with developments in the industry, expanding their skills to include software architecture in the process.

Although their main contribution is technical, they should also be growing in the areas of product and process. As a result, their understanding of business requirements should improve as they start to develop a product mindset.

Intermediate developers are the "meat and potatoes" of every team, the core cohort. They're the builders that get the job done.

Senior Engineers

At this level, technical proficiency is assumed. Whether the job is architecting complex solutions, rapidly ramping up in new technologies, or dealing with unforeseen technical challenges, a Senior must be able to handle all of it.

Senior engineers have a strong product and mentorship focus (the primary output of Senior engineers should be more Seniors). They understand the cost-benefit trade-offs of every technical decision and how the product adds value to your clients.

When considering promotions to Senior, remember that individual contribution has a hard limit - there is only so much that one person can achieve or contribute. Promotion to Senior should, therefore, NOT be a reward for time served. It is NOT an inevitable outcome of developing technical proficiency and expertise, but rather a recognition of a person's leverage. 

Seniors are force multipliers for their teams; their job is to maximise the benefit from everyone else's contributions. 

Principal/Staff Engineers

Principal engineers are the technical Yodas of your business. They're the ones that everyone goes to with every technical challenge they can't solve themselves or don't know where to start, and must embody technical leadership excellence. 

Not only are they at the forefront of engineering efforts, but it's also a requirement of their role that they remain there; their breadth and depth of skill and expertise make them core contributors to your strategic technology planning. 

If Senior Engineers are the force multipliers for your software engineering teams, Principal Engineers are the force multipliers for your entire software engineering division.

There isn't much that falls outside the scope of what's expected of them.

When in Doubt

Thinking hard about career frameworks and job descriptions are necessary. It is crucial to get the details right for your business to ensure fair treatment and pay, and to provide clear expectations for a role and the requirements for progression. Unfortunately, it's hard to get this right, and the fact of language is, the more words you put into writing, the more likely you are to introduce ambiguity, misinterpretation, and cognitive overhead.

Whenever you find yourself lost in the weeds, consider a return to the basics: Where is your focus and what is the scope of your influence and impact?

If your goal is promotion, remember that the best way to get promoted, is by acting in the capacity of the role you are after. This takes the conversation around your ability to succeed in the new role out of the realm of the hypothetical.

Proving you can do it, beats claiming you can do it every time.

Happy coding!

Will

Psssst! If you haven't subscribed yet, you can do so here. It's completely free and you can unsubscribe any time! You can also find me on Twitter @frontleftwill or connect with me on LinkedIn if you like.

So much to read and so little time! Here is what I hope to read over the next few months.

Empowered by Marty Cagan

Marty Cagan is a relatively new discovery for me, but everyone I know with an interest in product management raves about his take on how to build great products.

I've read and shared one or two of his articles on LinkedIn before, but this will be the first of his books that I read. My understanding is that Empowered is aimed primarily at what's required to be a good leader of product teams, whereas his other book, Inspired, is specifically for product owners.

The Omnivore's Dilemma by Michael Pollan

I have listened to numerous podcasts where Michael Pollan was the guest (the most recent is "This Is Your Mind on Plants" on the Tim Ferriss Show) and I’ve watched his Netflix series, Cooked.

I am yet to find something of his that I don’t like, and yet I've never read any of his books.

This needs to be rectified.

Leadership is Language by L. David Marquet

I like his style and I like how his personality comes through in his talks. I heartily recommend watching Intent-Based Leadership at CMX Summit West 2015 (I've watched it multiple times. In fact, getting the link to stick into this post has caused me to press play again, it's running on the side as I write this).

I loved Turn the Ship Around and I have high hopes for this one.

Natural Born Heroes by Christopher McDougall

His book Born to Run was an easy read, a great story, and started my love-hate relationship with running a decade ago.

I hope that reading this will be the catalyst to starting something else that's beneficial to me but that I'll probably dislike.

Meditations by Marcus Aurelius (translated by Gregory Hays)

Last on the list, but only because I want it foremost in your mind as you leave.

Both Shane Parrish (here) and Ryan Holiday (here) recommend this version, which made the decision on which translation to go with that much easier.

Stoicism is becoming fashionable at the moment and as a natural sceptic, I am always a little wary of trends and fads, particularly as they relate to  "self-help" systems.

However, the pragmatism and focus of stoicism on taking personal ownership of one's life appeal to me.

I have flirted with the ideas of this philosophy, it’s time to take a deeper dive.

Happy reading!

Will

Psssst! If you haven't subscribed yet, you can do so here. It's completely free and you can unsubscribe any time! You can also find me on Twitter @frontleftwill or connect with me on LinkedIn if you like.

The concept of autonomy at work is pervasive throughout business literature on organisational culture, and most everyone has an intuitive understanding of the need for personal freedom to choose how you do your work, and how that relates to employee engagement.

What do we mean, however, when we talk about autonomy in the workplace? I think misunderstandings stem from conflating choice around how with choice around what and, to prevent these misunderstandings from alienating leaders from their staff1, a shared understanding of what we mean when we talk about autonomy is essential.

Limiting individual autonomy at work is a necessity. To reap the rewards of collaboration in organisations, we must sacrifice some personal license as we consider and accommodate the needs of others2. Nobody has perfect freedom; everyone is accountable to someone (reporting lines) or something (consumer demand). Within organisations, the scope of responsibility of a role is the limiting factor for "what" autonomy or, to put it another way, as the scope of a person's responsibility within an organisation increases or decreases, so too does the surface area of their influence over what gets done.

Diagram: The amount of "what" autonomy at different levels of responsibility within an organisation.

In contrast, "how" autonomy refers to freedom within a role, and this is what is generally referred to when discussing personal autonomy at work; how you do your job should be up to you and should not be dependent on the overall level of responsibility for your role within your organisation.

There are legitimate concerns around where the limits on personal autonomy in the workplace are, and should be. An "anything goes" approach will certainly result in chaos. The solution is to constrain total personal autonomy in the workplace via the "what". As soon as you start interfering with the "how", you're in the realm of micromanagement and disengagement. Be very clear on boundaries and expectations. That is where you mitigate your risks. Define the "what", support your people, and then let them get on with doing what you hired them for.

Until next time.

Psssst! If a friend sent you this newsletter or you found it through social media, consider subscribing and sharing it with your friends and family (you can unsubscribe any time)! You can also find me on Twitter @frontleftwill.

I doubt anyone would challenge the claim that the rate of social, environmental and technological change is accelerating as we rapidly leave the 20th century behind. Change management, especially in large organisations, is hard.

An internet search for "change management models" will spit out several options, but the one I am most familiar with is the Kübler-Ross Change Curve. Like many change management models and processes from the 1960s, the Kübler-Ross Change Curve is based in grief studies (the "Five Stages of Grief" specifically).

Image Credit: cleverism.com (article linked to above)

Your job as a leader is to support employees through each of the stages. The goals are (1) flattening the curve, i.e. decreasing the impact of the frustration and depression on morale and (2) increasing the gradient, i.e. accelerating the transition from the first stage (shock) to the final stage (integration). Of course, real life is messy, and individuals will move through the curve at their own rate, often doubling back on stages or even experiencing multiple stages simultaneously. However, it is easier to think and reason about the model when change adoption is considered linearly.

You might find it hard to believe, but my two toddlers are nothing like professional adults. However, as a simplified proxy to the complexities of change at an organisational level, they present numerous opportunities to practice. Toddlers like routine and the stability it brings, relatively easily maintained during the week but havoc on the weekends when things need to get done. In other words, I find myself supporting the five stages of grief approximately four times an hour every Saturday.

A typical scenario goes something like this: (1) Me, initiating trip to home improvement store: "Come, my boys, we have to go to Bunnings1." Shock - change happens, they were deeply engrossed in their breakfast session of Bluey. (2) Eldest: "Noooooo, you don't have to go to Bunnings. You have all the things in the garage." (actual quote, he has opinions) Denial - we don't want Bluey to end. We reject your reality and substitute it with our own! (3) I insist: "Get your shoes, mate, we have to go." Frustration and depression (aka tantrums) as I proceed to wrestle them from couch, through shoe-finding and dressing, to car seat, to Bunnings. (4) Arrive at Bunnings, still wrestling until we get to the trolley section. Point them at toddler trolleys2: "Want to get a trolley?"  Experiment, Decision, and Integration in rapid succession. Bunnings is the best! (Worth noting is that the same trip requires repeating the process in reverse: "OK boys, time to go home" and there we go again).

So here's what my toddlers have taught me with regards to supporting change:

Shock and Denial: Communication through these phases is vital. When possible, give a heads' up that change is coming, repeat as often as reasonably practicable. Explain the "why". "When this episode finishes, we're going to Bunnings." or "Bluey, teeth, then Bunnings because the light broke and I need to buy a new one, OK?"

Frustration and Depression: Listen with empathy, but stay the course. Repeat the 'why" as necessary. At this point, any indication that the status quo stands a chance of being maintained is a death blow to the initiative. The situation deteriorates, and they'll dig in their heels. I can still bulldoze through it with my boys, albeit at the cost of an extremely unpleasant experience for all. However, you run the risk that your team or even your organisation could descend into crisis in a professional environment. "I can see that you wanted to watch more Bluey, but the lightbulb broke, and I need to buy a new one, or we won't be able to see when it gets dark."

Experiment, Decision and Integration: Support experimentation with training. As soon as you have someone entering the experimentation phase, recruit the person to help you help others with the transition to the final stages of acceptance and commitment. "Careful where you run. There are other people here"  and "If you hold the trolley like this, you can push it easier. Can you show your brother how to do it too?"

Finally, celebrating and revisiting successful change adoption, emphasising the cases where the outcome was beneficial and better than expected, helps with future change. "Remember when you were unsure about going to Bunnings, but you did it anyway, and it turned out to be a lot of fun?"

Change management is complex. Reflection and awareness, paying attention to how your staff is experiencing the change, is your best chance at success. As the change initiator, you have likely refined your reasoning for weeks, if not months, leading to your decision. For you, it is no longer a big deal because you've had time to digest every nuance of the reason for the change.

Be sure to communicate the reasoning clearly and accept that your teams will require similar amounts of time to what you had invested in working through the reasoning for themselves.

Until next time.  

Psssst! If a friend sent you this newsletter or you found it through social media, consider subscribing (you can unsubscribe any time) and sharing it with your friends and family! You can also find me on Twitter @frontleftwill.

Notes:

1. For those not in the know, Bunnings is an Australian hardware/DIY supply chain where you spend way too much time and money if you are personally responsible for the upkeep and maintenance of pretty much anything.

2. Bunnings kiddie trolleys:

One such example I frequently encounter professionally is the divide between developer or engineering teams and “the business”. “The business” doesn’t know what they’re doing. “They” don’t get how things work, and so forth. These expressions are usually uttered with frustration or outright anger.

OK, so it is possible to find yourself in an organisation that processes information pathologically as a personal resource used in political power struggles (see Westrum’s Typology of Organisational Cultures for power-oriented cultures). However, in most other cases, I think it is safe to assume that different parts of your organisation want you to succeed as much as they want to be successful so that we all win.

Nevertheless, we often find ourselves seemingly at cross-purposes with our colleagues, and framing the issue correctly is one way to reduce compartmentalised division: “Sales committed to x and therefore we need to get it done” is going to elicit a very different response in an engineering team than “Sales is driving hard to increase market share, to do so they were forced to agree to some tricky requirements, and they need our help to deliver”. Of course, you won’t eliminate all the frustration of having to crowbar that half-baked feature in at the last minute. Still, you’d hope that most professionals can relate to compromising to make progress.

Approaching frustrating or seemingly unreasonable expectations and requirements in this manner reduces friction between teams. By extending your colleagues the courtesy of believing they want you to succeed (at least until proven otherwise), you open the door to further communication and improved understanding of the overall context, which may even improve the odds that you will ultimately be successful.

Our species rely on cooperation to survive and thrive. Only in the most tragic instances is “the business” your enemy.

Image credit: https://library.osu.edu/site/40stories/2020/01/05/we-have-met-the-enemy/

Until next time.

Psssst! If a friend sent you this newsletter or you’re reading it online, consider subscribing (you can unsubscribe any time) and sharing it with your friends and family! You can also find me on Twitter @frontleftwill.

"What could possibly be gained from such an exercise other than a detrimental impact on morale and engagement?

Focusing on the knowledge industry. Even if you choose to put the cultural aspects aside, what could you meaningfully deduce from the data other than "person x was (probably) in the office between the hours of y and z"? (I say "probably" as you could tailgate with colleagues, etc).

Furthermore, I can be in the office and not be present in a thousand different ways.

This is a perfect example of a vanity metric rooted in the illusion of control. You stand to lose a lot of trust and gain nothing in exchange."

Willard Le Grand Bundy invented "an early and influential time clock, sometimes described as the first" in 1888. Clock-punching became an easy way for shops and offices to calculate employees' pay in an era in which I claim it was not unreasonable to assume that physical presence approximated productivity.

I want to reiterate that my perspective is from the knowledge industry generally and software engineering specifically, but my stance is that societal shifts over the last forty years have made the practice of clock-punching obsolete.

Nearly everyone sits in front of a computer these days and, even if you have draconian firewalls, certainly everybody brings their own devices to work. Distractions are everywhere - email notifications, Instant Messaging pings, and meeting reminders are par for the course, and these are work-related interruptions (an, ahem, timely reminder that it takes on average 23 min to regain focus after an interruption).

The other annoyingly tricky thing with knowledge work is that your product comes from the same place your anxieties, current obsessions, hopes and desires reside. Neither your infatuation with new romance, nor your preoccupation with that annoying little rash you're a bit concerned about, cares that you're physically present in a specific geographic location and that your productivity is on the clock.

There's nothing for it. As a manager of knowledge workers, you cannot deduce anything meaningful from physical presence in an arbitrary building.

Just let it go. All you are hanging onto is the illusion of control.

Until next time.

Psssst! If you like this newsletter, consider subscribing (you can unsubscribe any time) and sharing it with your friends and family! You can also find me on Twitter @frontleftwill.

It bothered me that my inability to walk away might indicate a subconscious lack of trust in my people. If I couldn’t be confident in my ability to extend trust, I couldn’t be confident that I’d receive it. The absence of trust is such a fundamental problem that it’s the first dysfunction in Patrick Lencioni’s The Five Dysfunctions of a Team:

1. Lencioni P, 2012, The Five Dysfunctions of a Team,  John Wiley and Sons

Without trust, there are no meaningful relationships. Not personally, and certainly not in the workplace. Merriam-Webster defines trust as:

trust (noun, first entry)

1. assured reliance on the character, ability, strength, or truth of someone or something

2. one in which confidence is placed

3. to rely on the truthfulness or accuracy of: believe

4. to place confidence in: rely on

5. to hope or expect confidently

trust (verb, first entry)

“Hope”, “rely on”, “expect”. Roll the die, fingers crossed. A position of trust is not a position of actionable power; there is no way to extend trust without the acceptance of risk and vulnerability. However, I couldn’t shake the nagging suspicion that I was washing my hands off of outcomes by not being involved, which irked me as I believe leadership and responsibility are inseparable. Round and round and round I went.

And then, thankfully, I read David Marquet’s Turn the Ship Around1 in which he talks about a breakthrough he had, struggling with the same issue:

“Trust means this: when you report that we should position the ship in a certain position, you believe we should position the ship as you indicated. Not trusting you would mean that I thought you might be saying one thing while actually believing something else. Trust is purely a characteristic of the human relationship. Now, whether the position you indicate is actually the best tactical position for Santa Fe is a totally different issue, one of physics, time, distance, and the movements of the enemy. These are characteristics of the physical world and have nothing to do with trust.”

It hit me that I’d confused a subconscious lack of trust in communication with a lack of trust in my people. I had to check in. I had to track progress because I had no confidence that I’d done a stellar job communicating my intent and expectations. If I didn't engage, I wasn't doing my job and I was setting people up for failure through no fault of their own.

Lead with trust. Build and nurture it through consistency of action and transparency. As long as you remain inquisitive without becoming interrogatory, and avoid being directive in your interactions, you are likely also steering clear of micromanagement and damaging trust.

It’s OK to check in.

Until next time.

Notes:

1. He also gave this excellent talk at CMX Summit West 2015