Chunking refers to how our brains prefer to group information. Our working memory can hold about 3 pieces of information simultaneously, with the ability to stretch to 5. So our brain is pretty bad at handling lots of information at the same time.

Chunk information to retain it faster

If we have a large amount of information in front of us, we can group or chunk the information to help our brain retain it. We chunk by finding relationships between information and creating groups we understand. The goal is to get to about 3-5 categories of information.

How to Chunk

Here's how I might chunk notes I've taken while reading a book:

This isn't a shortcut - I have to really think during this process and analyze deeply. It's quite uncomfortable, but that discomfort indicates deep learning. After completing a chapter or book and thinking about how the info relates in this way, I can recall it much more easily later on when I need to.

How this Applies to Systems

If we're not good at juggling more than 5 things in our brain at any given time, then this has significant ramifications on how we should design understandable systems.

This is bad:

Problems:

• No clear starting point.
• Some signs of a flow but lacks clarity.
• Everything is emphasised in the same way.

This is better:

Things that are better:

• Starting point on left.
• Chunked into 3 clear stages.
• No more than 5 items in each stage.
• Transitions between stages.

Problems:

• Everything is still emphasised the same.

This is best:

Things that are good:

• Starting point
• Chunked into 3 clear stages.
• No more than 5 items in each stage.
• Flow between stages
• Highlighted boxes / checkpoints act as anchors for critical information

Chunking systems in this way allows the brain to both understand it faster and retain it better. High risk, critical systems require fast, long-term comprehension from all involved parties. A system could be well thought-out and have the elements correct, but have a bad structure. This ends up as poor adoption (or no adoption) and frustrated participants at having to be involved in something perceptually complex and confusing.

Since we have instant access to information we can instantly understand, can't we remove the need for memorising? We never liked it in school anyway. What was the point of learning multiplication tables or essays about historical events except to regurgitate it in an exam? These poisonous memories of memorizing unimportant information surely proves we don't need to memorise anything!

Let's look how the brain works:

Working memory is the stuff that we're consciously thinking about right now. Our working memory receives information from the environment and interacts with our long-term memory. When information isn't available in our long-term memory, or we can't 'reach' it, we need to find an answer, so we might look it up online. This is an example of an "External Resource".

In essence our working memory pulls information from the environment and long-term memory. If something isn't available in long-term memory, we need to find it somewhere else.

For example, if I'm in a quiz and get asked the question "What year did world war two end?", I can either access my long-term memory to pull that information, or I can sneak my phone out under the desk to look it up.

Advantages of Long-term memory over outsourcing.

Working memory always attempts to access long-term memory first. If it can't find anything (ie. we're not sure about the answer or how to solve the problem) then we need to get the information elsewhere. So we go externally.

Having that knowledge stored and available in our long-term memory for instant access acts as a multiplier on our ability to think and solve problems fast. If I have the information in my long-term memory (ie. I've learned it previously), then I can answer the question or problem immediately.

Moreover, knowledge is not stored in a vacuum, but in a web. Each piece of knowledge is connected to another piece of knowledge. So the more I know, the faster I can learn and the easier it is to connect information together.

Here's what learning about a new topic might look like for someone unfamiliar with the information:

What happens:

• Unsure how to integrate new piece of info.
• Adds a little, but not much to the understanding of the topic.

And here's how a master's knowledge structure evolves with a new piece of knowledge:

What happens:

• New information immediately hooks onto prior knowledge.
• Lots of connections to the new piece of information, making it much more memorable.
• Potentially makes connections between prior islands of understanding, leading to more 'eureka' moments.

So do we need to "memorise"?

Given our allergy to the word "memorise", as it evokes images of late nights learning flashcards off-by heart, I think it's important to define good memorisation and not-so-good memorisation techniques.

Not-so-good memorisation

Rote learning is one of the least effective methods of learning. It involves forcing your brain to remember something, usually based on tedious repetition. Rote learning attempts to force information into your brain that your brain simply doesn't want to learn. Particularly if the information is unimportant to you, your brain will always struggle to commit it to long-term memory and prefer to delete it to make space for more useful things.

Good memorisation

What's something you enjoy talking about? History? Politics? Music?

Now think of something you know about this topic. Did you have to learn that off-by-heart, or did your brain just commit it to memory without much effort?

Good memorisation involves a desire to understand. We need to tell our brain "We want to know this".

Good memorisation comes from understanding, not learning facts off by heart. In other words, by understanding the content, we commit that knowledge to memory much faster. What's more, that knowledge is much stickier now because we're not rote learning an isolated fact that has no connection to anything else. Understanding develops a web of information and relationships between information that results in a rich picture of the topic that the brain can navigate through.

But we should learn to solve problems, not memorise facts, right?

Problem solving is often mistaken as a process separate from knowledge. As if knowledge is the set of cooking ingredients and thinking is the act of cooking.

This naturally leads people to believe that if we taught everyone to cook, then it doesn't matter what ingredients they have or don't have. In other words, if we could teach people to be "critical thinkers", then we could do away with knowledge. You can look everything up nowadays anyway!

But this isn't how thinking works. Thinking and knowledge are not separate - they are both part of the same soup. Knowledge begets thinking and thinking begets knowledge.

It therefore follows that more knowledge = better thinkers.

So should we offload memorisation to ChatGPT and Google?

The answer is clear: Absolutely not. We need facts, figures, statistics and information in order to be able to think. If you offload this to any technology, you end up impairing your brain's thinking skills.

How do you know what to commit to memory? That's easy - whatever is important to you. Whether it's your work, your hobbies or just knowledge for the sake of knowledge, your brain needs information for it to think and develop understanding.

We'll see in a few years where this epidemic of "knowledge lookup" with ChatGPT leads to - I suspect nowhere good.

In the exciting space of high-risk systems, it's pretty boring to think about "Making things safer". It evokes imagery of someone in too-tight clothing saying "No!" to every little change.

"Safety" is also a cost to the business where we should instead be thinking about revenue growth. When someone asks me what I do, I don't want to say "I cost the business money and say no to everything". There must be a better way of looking at it.

Safety is answering the question: "What do we need to do today to grow our revenue in the future?".

What's the structure, the checklists, the systems we need to put in place today so that we don't collapse into chaos in the future? It's like preventative chaos engineering.

Instead of being seen as a necessary evil to the business, safety in this way becomes a revenue-growth enabler.

And there we go - safety is a little bit sexier.

Think of the people you admire - Michael Jordan, Albert Einstein, Wolfgang Mozart, surgeons, teachers, sports people...

Are these people naturally gifted? Maybe.

Did all of them work hard? Yes, absolutely.

Intelligence and physical ability are certinaly fixed in certain respects. I can't grow to 7 foot no matter how hard I train. Fluid IQ appears fixed no matter how many brain training games I play.

But I can train my muscles to grow and get stronger and fitter. I can read and solve difficult problems to increase my crystallized IQ.

I don't need to natural talent to get better. Jordan, Einstein and Mozart did not get to where they got to by natural talent. Each practised for tens of thousands of hours.

Skills are built. Mastery is earned, not given.

Flagship engagement with 4 teams (32 engineers) in highly regulated banking environment had no delivery governance.

Our client, a Tier-1 bank, operated with a top-down hierarchy, resulting in slow decision making and siloes. We needed to establish engineering excellence from scratch to prove extreme value in this flagship engagement.

Challenges

• No continuous improvement culture
• 2-month onboarding time
• Teams struggled to work efficiently
• No automation, limited testing environments, bureauctratic approval processses
• Slow-moving technical gatekeepers
• High stakes: Losing this make-or-break engagement would significantly damage our reputation

My Approach

• Diagnosis: Client needed systematic engineering practices but couldn't transform all at once. Careful stakeholder alignment required across directors, managers, scrum masters, tech leads AND client management.
• What I built: Architected engineering excellence framework.

The Framework

The engineering excellence framework covered:

• Delivery standards and quality gates.
• Requirements flow and refinement processes.
• Continuous improvement mechanisms.
• Team working agreements.
• Technical standards (eg. LLDs, automation, testing)

Adoption strategy

• Started with quick wins - small, achievable tasks (eg. "Use the Low Level Design template once")
• Delegated actions to scrum masters & tech leads.
• Weekly check-ins.
• Assisted teams in breaking down complex processes and defending their requests (eg. environment analysis to break down their environment needs over the next 18 months).
• Constant engagement with resistant client technical leaders to push decisions forward.

Impact

• €2 million annual revenue retained.
• Client requested program expansion to the whole division including other projects.
• Case study helped secure €6 million deal with another client the following year.

Company had significant engineering capacity between client engagements but no way to convert that capability into new business opportunities.

With a 12-18 months sales cycle in our domain and no sales function in the business, we needed a proactive approach to generate sales leads. The challenge was to transform our bench resources into a revenue-generation function.

My Approach

• Diagnosis: We had a bench of engineers sitting idle. We had no sales function in the company. The industry was moving into a solution-first model of business, but we were operating as a "Time & Materials" company.
• What I buit: Working with the Director of Product at the time, I co-architected an innovation sales function from the ground up.

Innovation Function

• Innovation squad: Selected 7 self-starters from the engineering pool. This team evolved into the comapny's presales function.
• Sales pipeline: Developed the process to generate sales leads including discovery, deep dive workshops, client engagements, pitch decks and proof of concept development.
• ROI Focused: We proved ROI to leadership before investing further in the team and building it into a presales team.

Impact

Revenue

• €8 Million in closed revenue (€6 Million flagship deal, €2 Million strategic engagement, paid research projects).
• 16x ROI (€500K investment including grant offsets).
• 100+ qualified prospect meetings.
• €10+ Million pipeline established.

Strategic Transformation

• Innovation team evolved into permanent presales team (generating over €20 Million in deals to-date)
• Transformed available engineering capacity into revenue-generating asset.
• Built commercial engine that continues to drive business.

Screenshot of part of our miro board:

Recurring bugs were drowning engineering teams in reactive patch fixing. Across 6 teams (~60 engineers), the same categories of bugs kept reappearing because teams fixed symptoms instead of root causes.

Business Impact

• €15 million in annual recurring revenue at risk: Clients refused new software or bug fixes due to reliability issues and downtime risks.
• 120% capacity on bug fixes: One team spent nights and weekends for months on end reacting to new bugs.
• Features delayed: Critical bugs overloaded teams, leading to delayed releases.

My Approach

• Diagnosis: Teams patched individual bugs without addressing root causes, leading to constant firefighting. No governance existed to ensure preventative actions were implemented.
• What I Built: A CAPA (Corrective Action, Preventative Action) system for software, rolled out across 60 engineers.

The Framework

For every critical bug or incident:

1. Incident assessment
2. Root cause description
3. Corrective action (immediate fix)
4. Preventative action (Systemic change to prevent this class of failure)
5. Identify plan, owner & deadline to complete actions

Governance

• Monthly governance review
• Participants: Scrum Masters, Tech Leads, Management
• Agenda: Prioritise preventative actions, unblock resources, track completion

Adoption Strategy

• Prioritised quick wins. Engineers saw benefits of process quickly.
• Broke down big ideas into manageable pieces.
• Negotiated scope when teams pushed back.
• Management actively unblocked dependencies.
• Preventative work was made visible and tracked in monthly review.
• Within 12 months, started to include external teams.

Impact

• Revenue recovery: Moved at-risk €15 million ARR to retained.
• Productivity recovery: €2 million annual cost savings from recovered engineering capacity (reclaimed 400 hours per week from one team).
• Quality: 90% reduction in recurring critical bugs across 6 teams. CAPA framework became standard practice.

Applying this to other domains

CAPA (Corrective action, preventative action) is a standard procedure amongst any high-stakes or regulated domain:

• FSA (Fault slippage analysis): Tech
• CAPA (Corrective Action, Preventative Action): Medical device industry
• SMS (Safety management system): Aviation
• Incident analysis: Emergency services
• PSIMS (Patient safety incident managemente system): Healthcare, hospitals

A €3 million project ran 3+ months late due to scope creep, undefined design principles and no risk tracking, missing the initial deadline by over 90 days.

Repeated occurrences of these failures across subsequent projects would cost us over 7 figures in lost income.

Root causes:

• No design phase: The company signed the contract and launched straight into development. No designs, no onboarding period, no teambuilding.
• No change control: Changes and issues were untracked. A large amount of scope creep occurred over the project resulting in an estimated 10% additional cost.
• No project governance: Milestones and timelines overlapped. Requirements were not evaluated ahead of time.

I architectured the system to prevent these issues from happening again, saving over €1m for every 100 developers.

My Approach

• Root cause diagnosis: Sales and delivery operated in silos with no shared language, quality gates or design process creating blind spots in project governance.
• Architected a 5-stage governance framework: Created clear gateways and flow of work from initial sales engagement all the way to delivery and sign-off.
• Drove adoption: Over 10 working sessions with C-Suite, Delivery Directors and Engineering Managers

Impact

• Prevented €1 million in recurring revenue wasted over 100 engineers.
• Created shared language between sales and engineering, increasing accountability and reducing misalignment on subsequent projects.
• Reduced late stage scope changes by 50%.
• Framework now governs €15 million in annual project delivery.

In a previous post, I explored what deliberate practice looks like and how it is the fastest route to mastery.

Developed by Anders Ericsson, deliberate practice is a combination of:

1. Focus: The learner must be completely focused on their objective.
2. Expert: The learner has access to a good teacher or mentor.
3. Difficult goals: The bar for achievement must be high.
4. Well-defined tasks: There is a good plan to achieve the goal.
5. Feedback: The learner must receive feedback as they progress.
6. Adjustments: The feedback must lead to an updated plan.
7. Mental models: The learner discovers their own way of doing things over time.

Most of us have experienced what difficult practice feels like:

• Sitting down at the piano each morning.
• Going to football training in the rain.
• Studying for a difficult exam.

We then continued deliberate practice in University where we would attack the optional maths problems and attend the lecturer's office hours for 1:1 support. Then, we encountered real-world, difficult problems in the workplace that required serious thinking and planning. All of these experiences led to significant growth and learning.

It is all being disrupted.

How AI disrupts the process of deliberate practice.

ChatGPT isn't affecting 'practical' trades as much as knowledge work. In knowledge work (think software development, copywriting, journalism) it is significantly changing the learning process. When it comes to those moments of extreme growth we used to experience, we need to know how ChatGPT influences the learning process so we can continue to experience that growth.

How we define focus

Deliberate practice requires extreme focus. The task at hand should be difficult enough that it is well beyond what you are currently capable of. Let's see what happens when you focus hard on something.

And let's zoom in on the key components of that focus.

Firstly, you look at the problem or task and attempt to break it down into manageable steps. If it's a difficult maths problem, you create a plan of the different sub-problems you need to prove. If it's a new technique for holding the tennis racket, you attempt to visualise how it should feel in your hand, your ideal body position and the perfect motion of the racket as it hits the ball. Whatever the objective is, you break it into its sub-components and attempt to get each sub-component correct, hoping it will culminate in the desired outcome.

Secondly, as you grapple with the problem or technique, you are constantly reflecting. For each step forward, you ask yourself "Did I do that well enough?". Maybe you didn't quite hit the ball correctly because your hand was in the wrong position. You figure these small adjustments by constant reflection.

Thirdly, you constantly reevaluate yourself against your objective. This is a larger piece of feedback to check where your progress is relative to your goal. Maybe you have found another interesting maths problem or a weakness in your swing, but that is not what we are concentrating on now.

These three things culminate in extreme focus. You constantly perform a task, reflect on it and then evaluate as it relates to your larger objective.

Disrupting Focus with ChatGPT

Let's look at what happens to focus when we use AI.

The first thing we should do is to break the problem into steps. But if I'm using ChatGPT to solve for X, then I will never engage in breaking down the problem. I can just ask ChatGPT "Solve for X".

The AI rarely returns the correct answer the first time, unless I am looking up an easy fact. So I prompt it again saying "That's not the right answer, try again". It returns a different response and I rinse and repeat.

None of the first 2 criteria for focus are met. I'm not (1) breaking the problem into steps and I'm not (2) reflecting and adjusting my tasks. You might argue that I'm re-evaluating the AI's answer in relation to the overall objective, but then I break that thought process by just re-prompting for a different answer.

Using AI skips the whole process necessary for deep focus.

The Practice Cycle

Next, let's look at the practice cycle in deliberate practice.

This is the intensive part of the learning process:

• We create a list of well-defined tasks.
• We choose a task to complete.
• We execute it and get feedback of some sort.
• We adjust our practice and rinse and repeat.

This is what happens when we're studying for a test, practising drills on the piano or practising a golf swing. But what happens when AI is used for knowledge work such as studying and learning?

By default, ChatGPT skips the whole practice cycle

Here's another way of looking at the flow of learning. When we focus on a task, our brain engages, takes in some new sensory information, encodes & consolidates that information and eventually we achieve our objective or complete the task. This encoding of new information is essential to learning. The more focused the person is on the task, and the more difficult the task, the more the brain works and takes in new information.

Contrast that to when we use ChatGPT to solve a problem: We type in our problem into ChatGPT, it spits out an answer, and we severely limit the encoding phase. This means that little to nothing is learned. Imagine the consequences for teenagers whose brains are still developing!

But I just want to get things done!

To be clear, I'm not suggesting we shouldn't use ChatGPT. But we need to ask ourselves a question every time we use it and skip the learning process: "Do I need to learn this?" If I need to learn about this task, then I should not use ChatGPT. If you're a student who has a paper to submit, you shouldn't use ChatGPT. If you're a software engineer who needs some skeleton code quick, maybe you should use it. But this leads us into another danger.

Using AI doesn't just stop your learning, it atrophies your current skills

Skills atrophy when we don't use them. Everyone knows the pain of learning a foreign language only to come back years later and forgot everything. The Ebbinghaus curve illustrates this.

Forgetting is not a weakness of the brain. It is a strength. People with hyperthymesia (the ability to remember a large number of life experiences) have tremendous difficulty in operating a normal life. So we need to recognise that while we want to remember the lessons in this chapter, our brain just wants to make room for more things.

Therefore, when we use AI to perform tasks we find tedious or easy, we should be careful. We may be tempted to throw the AI an "easy" task which we already know. The more you "automate" that skill with AI, the more it atrophies.

This is further emphasised by a recent early-stage study from MIT which demonstrates how brainwaves for people who use only ChatGPT hinders their brain processing, retention and engagement with written tasks.

This isn't surprising when we look at the "Learning Process with AI" diagram again. When we ask ChatGPT to solve our problem for us, we skip over the part where we engage our brains to complete the task. Our brain does not engage in any level of difficult thinking, and so the information and skill is neither developed nor used.

In the context of deliberate practice, this is clearly a destructive pattern if the person wants to learn. Discomfortis crucial for the brain to learn.

Why is discomfort and difficulty important?

Prior to studying this area, I always thought the optimal state for learning was the flow state. Flow state is that feeling of being in the zone and at your peak performance. You can usually achieve it by focusing on a task that is slightly beyond your current skill level.

Your body and brain wants to relax

We know that our bodies and brains are excellent at adapting to challenges. We build muscle by lifting heavy weights. We build expertise by engaging in challenging experiences.

But our bodies aren't good at growing by themselves. In fact, they constantly want to relax. This is called homeostasis. Our body puts on muscle or sheds weight because it sees that as the best way of relaxing in the future. When we go to the gym, our brain tells itself: If this weight is heavy today, I need to put on muscle so I can lift the same weight more easily next time. This anticipation to change is called allostasis.

We can use homeostasis and allostasis to our advantage. Think about it like this: The more pressure we put our bodies and brains under, the faster they will grow. And this is where deliberate practice comes in. Deliberate practice should not be slightly beyond your skill level (like doing tasks in the flow state). It requires discomfort to force the brain and body to grow fast and therefore requires tasks that are uncomfortably outside your skill level (but not so far that you fail to get any meaningful feedback).

Takeaways

If it feels easy, I didn't learn anything

This fact has now become my go-to litmus test on whether or not I'm studying properly. Whether I'm using ChatGPT, reading, watching videos or any sort of learning task, I ask myself how uncomfortable this feels for me. Learning isn't supposed to be easy - if it were easy then the brain wouldn't adapt and grow.

If I think I know a subject after watching a video. If I read a blog post and now feel like an expert. If I paste a difficult concept into ChatGPT, ask it to simplify it for me and suddenly think I understand it. These self-checks tell me I don't yet know the material.

If this is a struggle, I'm learning something

But if a task is difficult. If I'm struggling to understand something despite having mapped it out. If I need to revisit a study again and again (like the MIT study above) to clarify information. If I'm constantly finding new information that contradicts what I already believe. I know that these challenging moments are the moment where my brain is burning energy trying to make sense of things and build up a schema.

Importance of Expertise and Mastery

In a nutshell, difficult tasks are what everyone should constantly do. In the age of ChatGPT, the temptation is to get something done as quickly as possible and disregard whether we know it or not. But as ChatGPT and other AI tools become increasingly better at doing menial tasks, the bar for expertise gets higher, meaning we must not sacrifice our learning in favour of speed. As intelligence gets cheaper, our expertise must increase, not decrease. ChatGPT and other tools can help us work faster, but it's only worth it if we work to increase our abilities and deepend our mastery.

Overview

In this post, we will look at the different stages of mastery and explore some elements of effective practice at the different stages of mastery.

The different stages of mastery

Although mastery is an endless journey, we can still say that the journey has different milestones.

The Dreyfus model attempts to describe this journey, identifiying a number of checkpoints from novice to mastery.

• Novice
• Advanced beginner
• Competent
• Proficient
• Expert
• Master

Credit: brainbok.com

Combining this with another framework (structure of learning outcomes), we get this:

• Novice: Has singular data points; Doesn't see how they connect yet.
• Advanced beginner: Has gathered more data points; Starts to see some connections.
• Competent: Understands how things fit together.
• Proficient: Sees patterns and has a knowledge of workflows and paths through the data points.
• Expert: Understands how all data points fit togehter; Can make abstractions and apply novel solutions;
• Master: Knowledge and applications are all auto-pilot; Lots of mental models and muscle memory;

For our purposes, let's split them into 3 categories:

• Novice & advanced beginner
• Competent & proficient
• Expert & Master

Before we explore how each stage approaches mastery, let's understand the common denominator: What makes practice effective?

What are the elements of good practice?

Anders Ericsson has coined the term "deliberate practice". Here is what deliberate practice looks like:

It has a number of elements. Alex is going to be our learner.

1. Focus: Alex must be completely focused on achieving their objective. He must be deliberate. He must tell himself he is doing X because it is important for him to achieve Y.
2. Expert: Alex must have access to someone who knows the domain to a high degree and can closely guide them throughout his development. This is usually a teacher, coach or mentor.
3. Difficult goals: Alex must embark on a difficult journey, putting himself under constant pressure - this is where growth happens quickest.
4. Performance-focused, well defined tasks: The teacher works with Alex to develop a tailored, specific set of tasks to achieve the difficult goal.
5. Feedback: Alex must receive constant feedback. Initially, this comes from the teacher. Over time, Alex develops the skills to self-adjust based on his own self-feedback.
6. Skill adjustment: Fundamentals come first. Over time, Alex builds off the fundamentals to get more advanced skills, refining individual skills as guided by his teacher (or himself later on).
7. Mental models: Alex discovers his own way of doing things over time, creating his own mental models. This is a strong sign of expertise.

This is a complex system, difficult for anyone to put into place. Each elements requires Alex to redesign specific elements of his life to achieve the complete system. However, if this is the gold standard for self-improvement, then it is the best blueprint we have to become great at something.

What makes good practice for each stage?

The novice has very different abilities compared to the expert. So while the principles of deliberate practice applies to everyone, each stage requires emphasis on a different element in the system.

Practice as a novice and advanced beginner

Having mentored many people and spent many 100's (maybe even 1000's) of hours teaching music to students, here is what the novice and advanced beginner needs in the beginning of their mastery journey. Let's bring back Alex and take a look at what he should focus on in the initial stages.

Focus - High importance

Alex must want to learn. There is nothing more painful than trying to teach something to someone who doesn't really want to learn. Or maybe they want to skip the hard work and reap the rewards at the end. Or maybe they just haven't developed the discipline yet. In children, it's generally up to the parents to enforce this discipline - no 10 year old wants to sit down at the piano for 20 minutes each day! But in adults, a lack of discipline, focus and willingness leads to no progress. For Alex, he has to want it.

Expert - High importance

When starting to learn a new subject or skill, the problem is we don't even know what we don't know. Where should I start? What should I focus on first? We could go through the slog of exploring the domain ourselves. But if we want to achieve a difficult goal, then the journey is already hard enough! We need to optimise the journey as much as possible to make progress as quickly as possible.

Alex must find an expert mentor or teacher. This will ensure that he sees progress early on which will, in turn, spur him to do more. There's nothing worse than working hard at something and not seeing yourself get any better!

The expert can help outline the journey and tasks that Alex needs to achieve in order to progress, giving him tailored advice and guidance, something which a book or forum cannot do.

Feedback

Feedback is really the thing that people pay for in a teacher. It's not just about the knowledge - we have books for that. It's the ability for the teacher to notice the small things Alex is doing and make adjustments.

Giving feedback is also the best part of being a teacher. The best lessons I've given have been where the student has come in with their exercises practiced and I have the joy of saying "Well done - I think we can do this a little differently". Contrast that to the worst (and often the most common) type of lesson where the student has not been disciplined through the week and we need to spend 30 minutes practicing instead of refining their skills.

Practice in the competent & proficient stages

As Alex moves into proficiency, the important elements of the novice stage remain. He still needs to focus, have access to some sort of expertise and work on well-defined tasks. However, since Alex has gathered the fundamentals, he has new challenges to contend with, the main one being complacency (Anders Ericsson calls this the "Plateau").

There are many people who graduate through different career milestones based on years of service alone rather than competence. We presume that people who have been around longer will naturally be better. But this is only sometimes true. We generally gather experience over time, but not at great speed. We may rely on our intelligence or our past success and think "Now I can relax".

This can be a good attitude sometimes. Breaks are required throughout anyone's career. Other prioritise arise - family being a big one, so not everyone can commit 100% effort all the time.

However, if we want mastery, then complacency is not an option. Your skill level will quickly max out around whatever day-to-day challenge you face. And if we face the same challenges each day (like most of us) then our progress quickly plateaus. We rise and plateau based on the standards of our environment.

Difficult goals

When Alex was a novice, his difficult goal was clear: Learn the fundamentals. But as he accomplishes the fundamentals, it becomes important to identify new and more difficult challenges. Again, he needs to stave off that complacent attitude of "I've worked hard for the fundamentals - now I can relax".

We want this: You could identify difficult goals in a few ways:

• Weaknesses: What tasks or skills do you struggle with? Maybe you're not clear on how that software framework really works. Or you struggle to keep up the pace for the final 1km.
• Strengths: What are your main strengths? How could you put them into practice? If you're a great musician, you could teach 1-2 students. Or if you're a good artist, set yourself the goal of hosting an exhibition in your local library.
• Collaborate: People love working with other people who have excellent skills. Join up with other musicians to create a band and meet once a month. Or contribute to an open source project.
• Make something you don't know how to make: There are few better ways to learn something challenging than by trying to do it in practice. Build a server. Convert your bedroom into a loft. Go to France for a month and only speak in French.

Feedback

As a novice, Alex required feedback to make sure he didn't develop bad habits. He needed a good teacher that understood the fundamentals.

For the proficient stage, Alex still needs feedback, but I have highlighted it in the picture because I think it is too often overlooked. We think feedback is only important for novices. We gain a certain level of pride as we accomplish the fundamentals. It's as if accomplishing the very basics of something means we are finished, or can teach ourselves the rest.

Now, we sometimes can teach ourselves the rest, but when it comes to fast improvement, we need to identify the big and small things we are doing incorrectly to progress. Having a person or system in place that can do this is necessary. This could be a mentor, coach or teacher. Or it could also be a software system (such as a test that tells us if our answer is correct or not).

Mental models

In the proficient stage, Alex gradually starts building up mental models. He starts to understand what works and what doesn't work. It is very difficult to teach mental models to a novice because mental models require data points to connect together to create patterns and context. But at the proficient stage, Alex now has enough information to reference, so he can work on processes and structures that help him get better.

As he builds up these mental models, he learns the patterns and the steps for things like:

• This is how I warm up properly.
• This is the brush stroke that gets me the best effect.
• This question is how I coach this person in their specific context.

Mental models are essentially patterns of thought and action that Alex knows works.

Practice as an expert and master

The expert and the master practice very differently to the novice. As an expert, Alex is no longer concerned with low level information - he has ingrained that knowledge to the point that it is reflexive. He has a large set of mental models to draw from. He has accomplished a large number of difficult goals and now understands the value of setting a high bar and completely focusing on it.

Alex can focus on his overall performance and learning systems. He understands how to identify areas of weaknesses, drill into them and improve them over time. He knows how to schedule practice routines and learn what he needs to learn to accomplish his goal.

Alex is focusing heavily on micro-adjustments to everything. Maybe he is drilling down into a maths technique he's not sure about. Or maybe he's found a muscle that needs more exercise.

Alex looks at the 'meta' level of his practice. Not just the tasks themselves, but whether or not the task is the best task to do at this moment.

• Master golfers take the time to tweak their swing.
• Master basketballer work on their jump shot under pressure.
• Master scientists adjust their data set based on the experiment.

Progressing through the stages

It's unfair to say there are different "stages" to mastery. Each journey is different, and as we said before, mastery is not a destination but an eternal journey.

However, just because each journey is different, it doesn't mean there aren't patterns to how a master achieves great things. Deliberate practice is clearly the fastest way to master something. Difficult goals with consistent and carefully measured practice with constant feedback ensures we improve as fast as possible.

Let's explore how a software developer might progress through the different stages.

Software Engineer: From Novice to Master

We can go back to our diagram of deliberate practice and fill in the blanks. Focus, expert, deliberate goals, practice feedback, adjust, mental models

Focus: This will be difficult and long

The learner must understand that the journey will be over the next couple of years. Maybe they have just started university or maybe they have floated along in their job for a few years. Either way, the learner must be honest with themselves - their expertise and mastery won't come for free.

The learner decides to be deliberate with their time. They think that 10 hours per week would be a good start, but know that they will struggle to keep to that. So they decide to carve out 1.5 hours per day in the morning before they go to work. And on Saturday, they decide to dedicate 2 hours in the morning to their learning.

Expert: Finding a mentor

The learner know the value of having an expert mentor could see them cutting the time it takes them to get to mastery by 2 or more. They attend a software development conference in their local city and get the names and numbers of 3 experienced engineers they spoke to. He explained to them he's looking for a mentor and was happy to pay them a fee for 1 hour a week.

Deliberate goals: Identifying the path forward

The mentor has over 20 years experience in the industry and knows the modern landscape quite well. She guides the learner to analyze the job market and pick the technology stack that is most likely to get him a job. They land on java and springboot for developing cloud applications.

The mentor shares some ideas for projects for the learner to build. Each project tackles a key part of the technology stack, allowing the learner to build up the foundations over time.

Practice: Getting the fundamentals right

She knows that the learner needs to get into the habit of building things without referencing online forums or ChatGPT. So they create some ground rules. The first project will look at practising the fundamentals of Java and springboot, only referencing the official documentation. The learner is not allowed to use AI or online forums to get the answer.

Feedback & adjust: Guiding even the little things

Each week, they get together to look at what the learner has built over the week. They discuss problems, and each week the mentor identifies areas the learner needs to improve on. For example, the first couple of weeks they choose to work on the tooling - which IDE to use, the shortcuts, setting up a proper desk for long coding sessions and so forth. The learner sees the benefit of a 1:1 mentor quickly, since he never even thought about learning the IDE shortcuts properly - he never saw it suggested in the online forums.

Mental models: Building up a picture

Over time, the mentor shares their thoughts on how the learner should approach a problem. In the beginning, she guides the learner on writing clean and readable code. As he progresses, the mentor teaches him about when to use different design patterns and why they are useful. She draws on examples of seeing good practices in her workplace, and examples of what bad practice can result in.

The learner gradually builds up his own understanding of the mentor's tips and tricks, creating his own mental models. As he ingrains things like for loops, springboot libraries and transfers his development flow into muscle memory, he starts to think more about how the overall system is designed. He spends more time drawing diagrams and data flows, trying to account for things like disaster recovery and fault tolerance.

Continuing the journey

After 18 months, the learner has developed at an exponential rate, understanding more than most senior engineers would across their career. They have absorbed all their mentor's examples and lessons and have even started giving ideas and solution to their mentor, consulting on a couple of their problems.

The learner understands their continuous need to keep learning, and they eventually go on to develop a network of mentors which he calls on for various consultations. He accelerates through positions at work, driven by his desire to want to work on more challenging problems. He continues his daily practice, getting up early each morning before work to hone his craft. Now, he has a good enough view of the landscape to drive his own goals. Every so often, he slows down, but a quick call to one of his mentors gets him back on track.

Closing comments on Mastery

Having high bars for ourselves is always a good practice. Yes, someone could argue that they don't want to put too much pressure on themsleves. But let's be honest - how many of us really put too much pressure on ourselves? Isn't it better to be uncomfortable trying to achieve something difficult (and growing because of it) than to not have any difficult goal at all?

Something I haven't covered here is the topic of discipline. Discipline is the bedrock upon which great things happen. We'll leave that to another blog.

Previously, we discussed "What is Mastery": A difficult, obsessive journey in the pursuit of becoming highly proficient in a person's craft. Masters take their craft and read about it, study it, practice it and spend tens of thousands of hours at it. To go on that journey, it's important we see the benefits that come with it. If the great masters often hated parts of the journey, why did they continue with it?

Purposeful sacrifice brings joy

There's a deep joy to mastery. We are always proud when we accomplish difficult challenges. In a world focused on pleasure and short-term gain, sacrifice is always put to tomorrow.

But people who frequently sacrifice short-term pleasures for long-term gains come out much happier. We have a name for this: Delayed gratification. We intuitively know that trading something nice now for a greater purpose later will make us better. A healthy lunch today instead of McDonalds will leave me feeling better tomorrow. A 5k run in the pouring rain today will give me energy and help me sleep tonight. By trading something easy and pleasurable today for something more difficult (and sometimes painful), we know we will be better off tomorrow.

Masters understand this. They are completely focused on the journey of purposeful sacrifice. When he wakes up at 5am to train or write that chapter, he knows that the pain now is a stepping stone towards something good.

Sacrifice now makes me valuable in the future

The journey of mastery is uncomfortable, sometimes painful. In those uncomfortable moments, each person needs something to help push them through. The novice who chooses this journey sees something in the distance, something that makes today's sacrifice worthwhile.

For many sportspeople like Michael Jordan or Serena Williams, they're desparate to be the best in their sport. Or with someone like Marie Curie, she was obsessed with scientific discovery. The master sees a north star somewhere. This north star gives them a strong purpose, helping them push through each challenge.

What does a master's career look like?

In the last post, I drew a picture of the "Zone of Mastery". Here it is again on the right of the picture.

As the novice goes up the "slope of enlightenment" (the journey of gathering more knowledge and wisdom), she encounters increasingly more difficult problems. She achieves new milestones and applies new solutions. She develops her skills, becoming more and more valuable. Each achievement unlocks new contacts and she builds up with a well-connected network of people. She can collaborate with people in this network to make even more discoveries and breakthroughs. She can meet other masters who are working in similar fields.

Over time, she builds career capital.

What is Career capital?

In the book "So Good They Can't Ignore You", Cal Newport argues that great jobs are rare. Traits like freedom, autonomy, a great team and a great company don't exist in every job. Therefore, to find those traits, we need to have something to negotiate with - valuable and rare skills.

We should note there are many rare skillsets that are not valuable, for example tiddlywinks. And there are many valuable skillsets that are not rare such as teaching. So when we're looking for career capital, we want the intersection of valuable and rare.

How do we find valuable and rare skills?

There are a few ways to find valuable and rare skills.

One way is to get so good at what you do you surpass everyone else. For example, you could be:

• A software programmer who knows the ins and outs of your programming language, algorithms and data structures.
• A world-record holder for the Iron Man.
• A surgeon who has practiced for 20,000 hours.

Another way is to be able to solve painful problems that others don't want to solve, like:

• A sewage tank cleaner
• A project manager for high-risk, high-cost projects
• An engineer in an offshore oil rig

A third way, and arguably the simplest way, is to combine skillsets together to create something unique.

• A project manager specialist in the medical domain.
• A barista who focuses on high-quality Turkish coffee.
• An electrician specalised in software heating systems.

Finding these niched skills and becoming excellent at them makes you unignorable. People can't help but call you to solve their problems.

Masters understand these things. It takes hard work to become excellent. Painful problems often require rare skills. And finding a niche is valuable.

How can I trade career capital?

The person with a rare and valuable skillset will find themselves in positions of endless opportunity. She will be offered positions, projects and money to get her to join the team. But that's just the beginning. Dream jobs are made up of more than mere title or salary.

Take a moment to think of 3 traits in your dream job.

...

...

...

Some common ones are:

• The ability to be creative.
• The freedom to choose what to work on.
• The flexibility to work when and where you want.
• Contributing towards something impactful.
• Working on something fascinating and meaningful.

A good job might have 1 of your dream job traits. But very few jobs have most or all of your ideal traits.

People get their dream job because they have career capital to trade.

Mastering a set of rare and valuable skillsets can help you secure the job traits you want in exchange for your expertise. This is one of the best reasons to aim for mastery at something. When you are respected and valued enough, you are trusted to work on whatever you want however you want. You can negotiate to work from home. You get selected for the exciting new project. You can demand a 30 hour week instead of a 45 hour week becase your employer knows you can deliver. All of these traits are in your grasp if-and-only-if you have valuable skills.

What does mastery actually feel like?

Discipline

Masters have a deep sense of fulfillment in what they do. The novice who embarks on the mastery journey will consistently re-invest in her own future with purposeful sacrifice. Each investment builds off the previous one, giving exponential gains over time.

This practice of continuous sacrifice also creates discipline in the novice, allowing them to accelerate up that "slope of enlightenment". World-class violinists are able to practice 8 hours a day because they built up the discipline in their youth, practising 1000's of hours in their childhood and teenage years. World-record holders developed their training discipline over years and years. Getting up early when we want to is easy. But getting out of our cosy bed to go out in the rain or make a breakthrough requires we develop strong discipline.

Flow state requires some mastery

Discipline isn't just about getting through the pain to achieve success. It enables other pleasures along the way. As discipline is established, the novice gives themselves the space to work on difficult problems with intense focus.

They forget the outside world. They get into the zone. We call this state of mind the flow state. Anyone who has experienced this knows it is a feeling of great pleasure.

But thoughts need to happen at a certain pace to achieve this state. It is difficult for the novice to get there. They are bogged down with the low-level information. The student mathematician is distracted looking up terms and formulas instead of focusing on the bigger picture.

So fluency is a requirement to get into the flow state. And fluency is something a master has plenty of.

Confidence

Masters are confident in their work. They speak confidently, write confidently, argue confidently. Their fluency means they can see the forest from the trees. Where a novice sees everything as important, the master knows what is important and what they should ignore.

For example, a novice designer might obsess over their colour scheme, wanting it to be new, contrasting and perfect. The master designer knows the 5 colour schemes that work and how to tweak them, allowing them to focus on more important things like the user experience. Having walked the path and made the mistakes, the master is confident in their opinions, able to put them forward strongly with good reasons.

How do masters describe their experience?

It's difficult to find masters describing their experience of being a master. Most masters don't see themselves as masters. They see the journey as a never-ending path of growth. Each and every one of them focus on the journey of getting better and discovering more.

For example, Kobe Bryant describes his mindset in one of his speeches: Those times when you get up early and you work hard; those times when you stay up late and you work hard; those times when you don’t feel like working, you’re too tired, you don’t want to push yourself, but you do it anyway; that is actually the dream. That’s the dream. It’s not the destination, it’s the journey.

And Michael Jordan's focus on challenging oneself: I can accept failure, everyone fails at something. But I can't accept not trying.

Or if we look at the academics, Richard Feynman is a nobel-winning physicist who was known for his relentless curiosity and deep thinking. Here he describes himself as "always feeling stupid".

Kent Beck is a renowned software developer and has authored many frameworks and books. He is famous for saying "I'm not a great programmer; I'm just a good programmer with great habits.".

My take from people like this is that the person who wants to become a master must develop themselves into someone who is driven by the journey, not the destination. This constant pursuit requires grit and discipline. Whether it is in an academic, professional or sports field, the master is always moving forward, grappling with new and difficult problems. It is a difficult, exciting and meaningful journey and it is available to all of us.

Think about a few people you consider masters of a craft, sport or science. Who are they? Einstein, Beethoven, Usain Bolt. Maybe you had a great music teacher growing up or a friend who became a professional sportsperson.

What makes that person a master? Why do they stand out to you? Think about that answer for a few seconds...

Great masters have a few attributes in common.

They are often great teachers, able to expain a concept at multiple levels, whether to a fellow expert or a five year old. This ability to teach comes as a biproduct of a depth of knowledge the person has gathered. But teaching is only one indicator of mastery. There are many examples of masters who were not great teachers such as Tiger Woods or Bobby Fischer. So we must look further.

They perform at a high level, making new discoveries and beating records.

They draw from a vast toolkit of knowledge, mental models and techniques.

They innovate, experimenting with new techniques to expand their domain.

Their experience makes them confident, able to defend their opinions. They stand apart from mere experts by becoming reflexive in their thoughts and actions. An expert may still need to think and take time to come to a conclusion. But a master does not need to think - they react instinctively.

They have worked diligently in their domain for many years and have developed a deep curiosity in their craft.

Their domain has clear rules for success. Everyone needs to compare that person to everyone else and say "They do that much better". World records, academic papers and scientific breakthroughs are examples of standing above the masses. In contrast, it is difficult to consider someone a "master of parenthood" because we don't have clear criteria for high success as a parent.

How do different fields define mastery?

For many fields, we have strong criteria for what classifies "mastery". Different fields have different criteria to identify masters.

A violinist is a master if she can perform advanced pieces consistently for an audience. A sprinter is a master if he wins competitions and breaks records. A master painter would exhibit in the top galleries in the world.

But other fields have weaker criteria to recognise mastery. Teaching, parenting, managing - it can be difficult to figure out who stands above the rest.

Or what does a master leader looks like? Is it the way they work with people? Is it the way they drive an organisation? Should we consider Steve Jobs and Elon Musk master leaders despite being extremely difficult to work with? Is a software engineer a master when he has become the best at 1 language or when he has learnt the most languages?

Clearly some fields have better criteria than others for mastery. This raises the question - how do we know when someone has accomplished mastery?

Is Mastery a journey or destination?

I think it's fair to say there isn't an exact point where someone graduates to mastery.

The Dunning-Kruger curve is an image that explains why we may be overconfident or underconfident in our assessment of our abilities. If we observe the Dunning-Kruger curve, you can see I've put mastery somewhere along the "plateau of sustainibility" (see the red zone on the right in the diagram).

Masters accelerate through the "valley of despair" by teachin and solving increasingly complex problems. This experience helps them build up a body of wisdom from which to draw from as they move to mastery where they start to innovate novel solutions and solve complex problems.

And after all of that is done, they must have the interest, curiosity and energy to continuously dive into new problems and explore new knowledge.

Clearly, there is a point at which one can call themselves a master, but it is only the starting point of a continuous journey.

What is the difference between a master and an expert?

There are many experts in the world, but few masters. The experts are experienced, able to solve complex problems and can understand a situation quickly.

But the masters standout from the crowd in two clear ways.

Firstly, They can analyze a problem and innovate brand new solutions. They understand their techniques so in-depth that they can refine them and create new novel techniques. This allows them to take complex problems and use a seemingly simple technique to solve them.

Secondly, the master is unconsciously competent. Where the expert needs to think, the master can react to situations intuitively. Their accumulated body of mental models and practice means their cognitive processes can run extremely fast. They can think of the perfect counter-argument without hesitation. They instinctively know how to adjust their body for the new terrain. The master doesn't need to go through the journey of problem solving - he can jump straight to the solution, often surprising even himself that he knows the answer but not the reason.

Is Mastery only for the highly gifted?

A study of conservatoire violinists by Anders Ericsson found that the top performers, as selected by the teachers, studied almost twice as much in their youth compared to those who were categories as excellent but not the best. While Mozart was considered gifted, he actually started being trained as a musician as young as four. In fact, Anders Ericsson's research has disrupted the notion of "gifted" people. Inevitably, we find that the "gifted" person has 1000's of hours of deliberate practice behind them.

This is terrible news - it means we don't have the excuse of saying "I'm not gifted enough". If we want to master something, it really is in our grasp. It will be a long and difficult journey, but it is within everyone's grasp to become great at something.

It's common to look back on our education or personal development and think we could have done better. We look at ourselves now and think "Ok - I'm going to fix this and do another degree" or "I'm going to get that course done". But there is another path to mastery we never consider - the personal apprenticeship.

What is an apprenticeship?

Apprenticeships are commonly a company-sponsored program. They allow the employer to train new employees in relevant skills. After completing the apprenticeship, the employee has a set of valuable skills for their industry whether it be a trade, a medical discipline or something like software engineering. Compare this to a university student who has very few job-relevant skills after a university degree. All of this and the apprentice gets paid. It's win-win.

Industrial apprenticeships are fantastic programs, but we don't have to rely on companies for them. We can take the same apprenticeship model and apply it to anyone who has a career or hobby they are passionate about.

An apprenticeship more generically is...

An apprenticeship is a period of focused learning. The apprentice isn't focusing on income or title - they're focusing on their work. The objective is to acquire practical skills and sow seeds. The more seeds sown during the apprenticeship, the more opportunities will open up. The apprentice focuses on developing a few high-quality skills (ie. not lots of things). Over time, the apprentice combines their skills together, building them into a toolkit of mastery for their craft.

Secondly, apprenticeships are unique to each person. Everyone falls into the trap of looking at someone else we admire and trying to copy them. It is useful to look at others' paths, but only as a guideline. Following someone else's path will lead to a loss of focus, disinterest and ultimately burnout. We see this all the time in certain disciplines - just look at the dropout rates in universities for software development and medicine. These are financially attractive disciplines, but they require a person who is dedicated to the craft.

Apprenticeships must be challenging. An easy apprenticeship is pointless - nobody learns anything. We learn fastest by overcoming difficult situations. A good litmus test for a person's progress is how many difficult things they have accomplished. This could be a research paper, writing a blog or article, giving a speech or presentation, delivering a project or passing an exam. The more challenges someone encounters in their apprenticeship, the more they learn.

Designing your own apprenticeship

The apprenticeship model is extremely practical and useful for sowing seeds for future success. But we don't need to rely on a company or university to design an apprenticeship for us. Look at the three criteria for a good apprenticeship:

• The objective is to learn.
• It is unique to you.
• It must be challenging.

The objective is to learn

Tell yourself that you are carving out a period of time specifically to learn and develop your skills. You're not looking for promotions (though if they come then great!). You're not looking for a career change (not yet anyway). This period is about focusing on the domain or set of skills you believe are important.

It is unique to you

The apprenticeship should focus on something that drives you. It should be something that grips you - a vision of your future.

For example, let's say you want to become the CEO of a large company someday. Your apprenticeship might focus on setting up a very small, profitable business. This would enable you to learn about things like tax law, business finance, profit and loss, marketing and product development.

Or if you wanted to switch careers into university lecturing, your apprenticeship could focus on developing the skills for a PHD.

Another great thing about a self-directed apprenticeship is there is no time limit. You can take it slow and build up your big, deep ideas for yourself. If you are busy with work or family and can't commit lots of time to your apprenticeship, that's great! This will allow you to hone your skills over a longer period of time.

It needs to be challenging

If your self-directed apprenticeship is easy, don't bother with it. Good learning requires you to struggle with the content or skill. A challenging apprenticeship also means you won't get bored after a week. Your perseverance will give you wins to be proud of.

Finally, if it's not challenging, you're not setting the bar high enough. You need to decide if your apprenticeship is worth it. Why do you really want to go down this route? What grips you about this field or study or skillset? A high bar will produce expertise you are proud of. It also means nobody else will have the same expertise - other people don't want to do the difficult things you've done!

A personal example

I've just kicked off my own personal apprenticeship in Learning Science. I've ticked off the three criteria:

• Period of focused learning: The first phase of this personal apprenticeship will be over 6 months and split into monthly increments. Each month will focus on an overview of an area I want to study, from learning science to organisation change to neuroscience. After the six months, I will take a recap of everything learned and decide on next steps.
• Unique to me: It connects a bunch of skills and work experiences I've enjoyed over the last few years.
• It's challenging: The skillset is a bit of a rarity in my field (ironic considering the title "Learning and Development"). I've incorporated difficult challenges to complete along the way, which you can see highlighted in the diagram below. (Right click => Open image in new tab)

Speed is important. Life passes quickly, so we need get things done. We need to build things. We need to meet deadlines. We need to uphold our responsibilities.

The kids need to be dropped to school before school starts. The assignment needs to be submitted on a Friday. The work needs to be completed by end of Q2. Time is of the essence for many things.

But not for everything.

We've forgotten how wonderful being slow feels

Yes, many things need to be done quickly. But we can fall into the trap of believing that good work always requires speed. We think "If I'm not finished task X by date Y, then I'm not being as productive as I could be." Then I feel guilty and demotivated.

There are many things in our lives, often the most important things, that requires slowness. And if we are in the habit of getting everything done as fast as possible, it is difficult to switch to something slow.

Remember what is what like as a child to do something without thinking about when it would be done? Building the lego set didn't have a deadline. There was no pressure to level up in Call of Duty (good thing too because I was slooow). We didn't care how long it took to explore the fields.

Slowness is a virtue we have forgotten.

Big, deep ideas are better without deadlines

If you are lucky, you remember a time when something gripped you. Something you couldn't escape - you thought about it every day and maybe still do. You might not even know what to do with this gripping thing. But you think about it all the time.

When you were a child, that gripping idea might have been a new hobby. Or maybe it was a scene you wanted to paint.

Don't forget about your idea because it feels slow

As we get older, these gripping things become more important. But if we're not careful, they also become more fleeting. We find excuses to discount great ideas because they won't be done by a certain time.

• The idea is too big.
• I don't have time for it.
• Nothing will come of it anyway.

These may all be true, but it doesn't mean the big, deep idea doesn't have immense value in and of itself. These gripping ideas deserve time. In fact, they shouldn't be explored as fast as possible. If left alone, time can make them deeper and more gripping, allowing you to commit to them with greater zest when the time is right.

Time will build your hunger for your great idea

If something grips you today but you can't work on it, that makes you hungry to work on it tomorrow. Over months, or even years, that hunger grows and grows. Later, you might find yourself in a unique position that allows you to finally work on your idea. You've spent so long waiting and thinking about it that you have a fierce hunger. You don't care about any excuses now - you're just going to work until your hunger is satisfied.

Think about it - speed makes it seem like you have less time

Don't worry about any deadlines. Agree with yourself to work and think slowly. Great! Now you have infinitely more time than if you worked quickly.

With more time, you can think about things more.

• You can plan them better.
• You can engage with them deeply.
• You can talk to more people about them.

You can build the wisdom for your idea, hammering out something that is potentially great.

We build patience when we practice slowing down

A knock-on effect of our fast-paced lives is that we are extremely impatient. Things we used to do aren't required anymore.

• We don't need to queue at the bank - it's all online.
• We don't need to read books or learn deeply - we can just google (or now chatGPT) the answer.
• We don't need to talk to people - social media and Netflix took care of that.

Everything that once required us to wait is now gone. As a result, we have lost the virtue of patience. We expect things to be answered in the moment - including our own deep thoughts, complex problems and confusing ideas.

• A relationship isn't immediately gratifying so we opt for one-night stands.
• A book takes months to read so we go on Instagram instead.
• A fight with a friend or spouse isn't resolved immediately so we cut them off.

And our big, deep, gripping idea is so big, deep and gripping that we simply cannot comprehend it and choose to forget about it.

Anyone who has lots of patience started small

Is it any wonder we can't hold onto our big, gripping ideas? We wouldn't expect ourselves to squat heavy weights the first day in the gym. Our big, deep idea is perhaps one of the heaviest weights we could ever lift. And it requires the strong muscles of patience. If we haven't built up those muscles before with other, more manageable things that require patience, it won't be possible to lift the heavy burden of our big, deep idea.

Slowing down a big, deep idea allows us to build the virtue of patience. We can take one bite at a time instead of rushing the whole lot.

Things that are better slow

• Dating + relationships: "Taking it slow" helps to build a solid foundation of values and agreements for the relationship.
• Careers: Young people can fail to develop good skillsets by changing direction or job hopping too often.
• Business idea: Many businesses fail because they flip-flop between ideas and don't slow down to choose a direction to focus on.

Make more decisions

People confuse talking with decision-making. While it is true that talking is part of the decision-making process, if your decision is not written down, it will be forgotten and you will have to revisit the same conversation in the future. Once a decision is written down, it is concrete and everyone can move onto the next thing. The more decisions you write down, the more progress you make.

Write more, think better

Writing is thinking. Amazon has 1-pager and a 6-pager writing practice which encourages employees to think in-depth about their thoughts and vision for their work. As you write down your thoughts, you are forced to organise them and create a coherent narrative. If you're not writing down your thoughts, you are relying too much on your ability to articulate them. And let's be honest - that doesn't work very well. It doesn't look good when a leader stumbles over their words as they try to get your thoughts in order. You need to at least look like you have an idea what you're doing. So write down your thoughts.

Get agreement

If you don't write things down, you rely on people to spread information via word of mouth. Maybe that used to work when oral, in-person communication was the main form of communication. But in the digital age where most our work in online, relying on word of mouth isn't good enough. It takes just one person to zone out or miss a meeting for everything to be re-explained. Write things down - you will avoid repeating yourself and relying on Chinese whispers.

Write to increase your team's speed

If you don't write things down, your speed as a team, organisation or company slows down. If a decision is not written down, it's not a decision. And at the end of a meeting, if nothing gets written down, nobody knows what happens. They don't know what actions need to be taken. They don't know what happens next. "Oh - I guess we'll need another meeting". Meeting after meeting occurs with nothing written down, no sense of progress or alignment and everything slows to a snail's pace. Write all thoughts down and make sure everyone sees the decision process. At least that way the next meeting will have something to build off instead of saying "What were we talking about again?".

Here's what ineffective meetings looks like.

Compare the above to a series of meetings where everything is written down.

Write and take your work seriously

Strong writers are always viewed as professional and good at their work. A leader who writes their thoughts down come across as articulate and clear. Who know where you stand with someone who has written their thoughts down. You know what their decision process was. You know what their presumptions were.

Write more and improve your work and the work of the people around you.

Here is a sales funnel: On the left, we see all the opportunities for potential new business. As our target market become aware of what I offer them, I work with them to get their interest and hopefully a decision for them to do business with me.

Good sales strategies will aim to be specific. If we make generic statements about what I sell, it's going to fall flat in the sea of advertising noise. I need to make my value heard, and to do that it needs to be specific.

For example, instead of "David's Incredible Deserts" I could focus on "David's Incredible Chocolate Chip Ice-cream". Instead of a generic statement where I try to catch as many people as possible, I just focus on the people who want some great chocolate chip ice-cream.

Here is an example of how a generic message can fall flat.

And here is how a specific message can have a better impact.

Floppy Funnel

Notice that by advertising chocolate chip ice-cream, I'm potentially excluding people who only like strawberry ice-cream. What should I do? I could call it "David's Incredible Chocolate Chip and Strawberry Ice-cream", but we can see straight away how it loses its impact.

This is what happens when we make our sales funnel 'floppy' and change the story of what I provide to suit more and more people. In the end, everyone feels like there is no difference between me and the ice-cream they can buy in the shop, so why pay more?

My funnel needs to be aimed at a specific group of people or businesses which I know I can bring value to. My offerings need to be tailored to those groups such that I am happy to exclude the majority of people in favour of a few key people who value my services.

If I have a floppy funnel, when someone asks "What ice-cream can you give me", my response will be "Well what ice-cream would you like? I can give you any ice-cream you want!".

I might not even give them any options: "You just tell me what you want.". When this happens, the customer quickly sees I either don't know what I'm doing or I cannot provide anything of quality.

Contrast the floppy funnel response to a more direct response: "I provide homemade chocolate chip ice-cream with Irish chocolate and dairy from the local farmer's market". The person might not like the price I'm charging, or they might not like chocolate chip ice-cream, but that's ok as long as enough people do like it. And because I'm charging premium prices, I can get away with fewer customers.

Business is the same. A business which has Floppy Funnel Syndrome will respond to the question "What do you do?" with the answer "We can do whatever you want us to do". Everyone knows that response is rubbish - no business can do everything. And if they can, they're not going to be very good at anything. If a business responds like this, they lose all trust before starting any real conversation.

Floppy Funnel Syndrome in other areas

Business is not the only area where Floppy Funnel Syndrome can happen.

• Career: You can switch career directions too many times so that you never build a deep expertise in anything. Later in life, you will find it difficult to stay employable.
• Practice: When practising a subject, it can be tempting to switch direction when something gets difficult. Pick a category of work to point your funnel and learn about the things that interest you. As the subject's information gets filtered through your funnel, it will get more difficult. Eventually though, you should have a set of skills that are well-honed.
• Relationships: Don't try to make everyone happy. Pick the people you care about and who care about you and develop those relationships. You don't need to change yourself so that you can get more friends. Your funnel should be focused on the people who care about you for your own sake.

Reading through Make It Stick, I keep coming across misconceptions I have about effective learning. Here are a couple of antipatterns I've fallen prey to.

Learning Antipattern: The Path of Least Resistance

...where I choose to learn things that are easy to avoid anything difficult, tedious or tiring.

The Path of Least Resistance: Problems

• Easy learning gets lost. Reading a book cover to cover might retain 1% of the information in the book. But if I slow down, pace my reading and make it more difficult on myself to progress, I will understand and more information.
• If something's easy to achieve, it probably means lots of people have achieved it. When lots of people have the same thing, it loses its value. Everyone has a bachelor's degree today, which is why it has lost so much of its unique value. Easy things are less valuable.
• Easy learning indicates unimportant learning. As a corollary, difficult learning indicates important learning. How much does the average person know about the Kardashian's versus Dostoevsky?

The Path of Least Resistance: Solutions

• Remove any low-value information intake like LinkedIn, Instagram, news + blog sites. If you struggle with this (as I do) start with acknowledging the moments that are wasteful. Look out for endless scrolling.
• Pick an area of interest and deep dive into that area. Read, write, watch, listen. Make it slow. Make it difficult.
• Don't fall into the trap of doing easy things all the time. Interleave your easy learnings with deeper, more difficult learnings. For example, after you finish your current book, write 3-5 paragraphs on what you remember and what you found interesting.

Learning Antipattern: Beating a Dead Book

...where I read, read and re-read to remember the information.

Beating a Dead Book: Problems

• Reading alone does not result in retention or understanding.
• Familiarity with words & sentences gives the illusion of mastery. If I showed you a €1 coin, I'm sure you would recognise it. But if I asked you to draw a €1 coin, could you do it?
• We default to reading easy things such as blog posts and articles, cycling through lots of low-quality information. We cannot gain deep understanding with shallow information.

Beating a Dead Book: Solutions

• High-quality learning is a constant cycle of input and output. If reading is the input, pair it with an output such as writing.
• Remove as much low-quality reading as possible. Cap how many blog posts you read before diving deeper into the topic. Otherwise, you may be trapped into thinking you have mastered the subject matter whereas you only recognise the subject matter.
• Increase the difficulty of your reading. Difficult material forces you to slow down and unpack the complexity with notes, drawings and scribbles. This helps with deep understanding and prevents shallow thinking.

Learning Antipattern: The False Gospel of Learning Styles

...where I avoid books and tests because I am a kinesthetic learner.

The False Gospel of Learning Styles: Problems

• Apart from anything else, learning styles are scientifically bogus.
• Belief that you learn best through one mode means you are less likely to look at other modes of learning. "I can't learn with tests because I'm a visual learner".
• It furthers the myth that because you don't enjoy something means you learn less from the experience. "I don't enjoy reading, so I'm going to watch videos instead because that's my learning style." See Path of Least Resistance above.

The False Gospel of Learning Styles: Solutions

• Don't be afraid of different modes of learning. The more experiences you have about a topic, the better it will stick!
• If engaging with other people who talk about learning styles, do so politely. "I'd be interested to hear what you think of my understanding of learning styles..."
• If you've fallen into this trap already, now is the time to build up your toolkit of learning strategies. So you're not a good writer? (My hand goes up here) Start to write!

Learning Antipattern: The Miserable Crammer

...where I treat learning as something to be rushed for an exam.

The Miserable Crammer: Problems

• Cramming information and retaining information require very different practices. Your brain is designed to forget about short term memory.
• Cramming for the purpose of an exam and then passing the exam gives the illusion of mastery of the content. Regurgitating information is not the same as being able to apply the information to solve problems.
• We often cram for high-stress exams and sacrifice sleep. Poor sleep patterns reduce our ability to consolidate memories and develop neural pathways.
• Many of us have foregone the joy of life-long study because of our terrible experiences in school. Curiosity is a muscle that requires time to nurture, and sadly it atrophied in many of us due to this antipattern.

The Miserable Crammer: Solutions

• Where deadlines are not an issue, slow down your intake of information. Write about what you understand of the chapter in your book before moving onto the next.
• Whenever possible, avoid "1 and done" learning. Repeated practice of the material helps to master it.
• Diversify your information intake. Read multiple authors about the same topic. Draw diagrams. Write. Look underneath the what to the why and how.

Learning Antipattern: Back of the Book

...where I go straight to the solution before attempting to solve the problem.

Back of the Book: Problems

• Seeking the solution too early gives the impression of success but results in no learning at all.
• Learners avoid the struggle of figuring out the problem. When there is no option but to figure it out yourself or with others, we make significantly more breakthroughs.

Back of the Book: Solutions

• If figuring out a problem for the sake of your own learning, don't ever look up the answer. Your struggle with the problem will solidify it in your long-term memory. Only look up the answer to confirm your own.
• If you are completely stuck on a problem that has the answer available, seek someone's help to help you understand the method or process behind finding the answer.

Learning antipattern: Act first, learn later

...where I avoid study because I learn best by doing.

Act first, learn later: Problems

• Contrary to popular belief "learning by doing" is not the best form of learning. Popularised by Edgar Dale, his Cone of Experience has been consistently misused to give the impression that learning can be nicely split into categories of varying "effectiveness", where learning by doing is the most effective method of learning. Here is his original cone.
• Ignoring sources of information in favour of "doing" handicaps the person who is trying to learn.
• Learning by doing can be downright dangerous. I once met a person who's favourite way to learn was to log into the production system and fiddle around. I don't want him on my team.

Act first, learn later: Solutions

• Doing is a key part of learning, but don't ignore other sources of information such as books, videos or a teacher's wisdom. A combination of input (eg. books) and output (eg. doing) is best.
• Be critical of theories like the "Cone of Experience" which has taken grains of truth and created false teachings. Just because things appear in a pretty picture does not make them true!

Learning Antipattern: Testing is the devil

...where I avoid tests of any kind because they make me uncomfortable.

Testing is the devil: Problems

• Testing is a powerful tool for retrieval practice. Apart from using it to score someone's performance (most common form), tests enhance individuals retrieval of information to improve long-term retention.
• Avoiding stressful testing practices such as flashcards or multiple choice quizzes because they are difficult results in the giving the learner a false sense of mastery. Without the ability to recall information, the learner has not mastered the content.
• Cynicism of testing is often accompanied by a cynicism of recalling the little things. "Why does it matter if I remember the little things as long as I can do the big things?" people ask. They can just google it, right? However, the brain surgeon who cannot recall how to stitch a bleeding artery is a dangerous brain surgeon.

Testing is the devil: Solutions

• Flashcards are one of the best ways of testing yourself and improving your long-term retention. Here's a tutorial.
• Combine flashcards with other efforts such as concept mapping, videos, lectures, podcasts and other multi-media to engage your understanding as well as retention.
• Another way of testing yourself is by writing what you understand about the concept. Close the book or the video and write in a notepad (full sentences) what you understand.

Learning Antipattern: Topic Tunnel Vision

...where I study one thing at a time before moving onto the next one.

Topic Tunnel Vision: Problems

• We have been taught that knowledge is divided into neat categories. Maths is over here. Biology is over there. Philosophy is somewhere else. But great breakthroughs and understandings occur when a theory from one category is applied to another category.
• Your unique perspective gets lost if you treat knowledge as straight forward and silo'd. You have a unique perspective from your background in social studies or software or teaching that can give you a unique new insight into your study. Any unique opinions about a topic helps you understand the knowledge better.
• Putting learning into neat categories can stem unique learning opportunities. What happens if I take this mathematical theory and use it to write a piece of music?

Topic Tunnel Vision: Solutions

• Add colour to your study mediums. If you're reading a book about Plato, supplement it with some videos and podcasts. Each person will explain the concept in their own words and overlap with another person's understanding. This overlap is called "interleaving" and help improve your understanding.
• Read multiple books in conjunction about the same topic. Your learning will be slower, but you will pick out many more insights.
• Opinions are good things, despite what we've been taught in school to learn only the "facts". As you write about a concept, think about the why as well as the what. What are people's motivations? Why does the machine work like this? What is your opinion on the matter? Opinions create a 3D model out of a set of 2D facts.

The path to mastery looks something like:

• Understand the business objectives and strategy
• Develop a learning+dev strategy that supports the business strategy.
• Consult and receive feedback from stakeholders
• Define the backlog of initiatives to meet your strategy
• Design the initiatives - we will explore this here
• Execute the programs and track success.
• Retrospect on progress and change based on feedback.

Recap

In the last post, I discovered that design is a lot more than a short blog post. We explored how to design the backlog, so now we will explore how to design each initiative in the backlog.

Principles of good design

When it comes to good learning+dev design, we don't need to reinvent the wheel. The best learning+dev design principles should be based off product design principles. Our product is the learning+dev initiative and our customers are our employees. Inspired is a book I repeatedly return to for wisdom on good product.

Obsess over value to your clients

You must obsess over the value your programs bring to the company. Anyone can do your job as a learning practitioner and create courses that are of no value to anyone. If we don't obsess over value, we will water down our value with unecessary elements. For every extra detail you add, ask yourself "What value will this bring to my customer?". If it's unclear whether it provides value, it probably doesn't, so remove it. Your customers have enough to do without trying to bat away more waste.

Everything is an experiment in the beginning

This is key to progressing quickly through wasteful initiatives. No amount of planning or upfront research can tell you what the perfect initiative looks like. You must experiment with everything. So get your idea on paper and test it by trying it on a small group or talk to someone about it.

Everything is a minimal viable product (MVP)

When designing something, the first draft must be small. There should be no such thing as a 12 month program in the first draft - it's too long. There are a couple of reasons for this.

Firstly, you're too busy to build large-scale projects all the time. The needs of your colleagues change daily. What they needed last month they no longer need this month. So building things that get launched quickly is extremely important.

Secondly, people don't have the interest for long-term optional programs. If I want to learn more about leadership skills, I can probably keep that interest for a month at most. A 6 month program? I won't finish it. However, I might be interested in learning more about stakeholder management this month, public speaking next month and crafting presentations the month after. Even thought they're all leadership skills, by chunking it into manageable sections I'm able to retain interest and look forward to the next section.

Focus your initiative on one persona at a time

You can't please everyone with everything. So the key to good learning+dev design is to please a group of people now and another group of people in the future. For example, if you are rolling out a leadership program, you could roll out a program that tries to address the needs of all leaders. But this would make the program generic and watered down.

Instead, your leadership program should focus on a small cohort of people first (eg. new leaders), then expand it into another group such as team leads, then another group such as project managers. This allows you to create small initiatives consistently and ensure your participants keep receiving value.

State the goal and expectations

A tool to manage goals and expectations is the Object and Key Results (OKR) technique.

• Objectives: What business results are you aiming for in the organisation?
• Key results: What are the metrics you expect to change which would show your initiative is working?

Take each initiative in your backlog. Write out what the objective is for that initiative and the results you are looking for. As you write out each intiative, you may find you have many objectives - this is a sign you are too scattered. Each intiative should have 1-3 objectives. Any more than that and you need to reduce your priorities.

Kill it

The Sunk Cost Fallacy applies to Learning+development as much as any other discipline. Most projects don't work out. Most initiatives don't work out. Maybe they lack engagement. Maybe they didn't address the learning objectives appropriately. Maybe it was a great initiative but the wrong time. Maybe it was the right time but the wrong initiative.

Many things can cause a learning+development initiative to be deemed "unsuccessful". If the initiative is not outputting more value than the time that goes into it, you need to kill it. If the initiative has little to no engagement, you probably need to kill it. If it has simply run its course and does not provide any value anymore, you need to kill it.

Learning+development needs to constantly evolve and meet the business needs again and again. We cannot do that if we are bogged down by managing a long list of low-value initiatives. To quote Steve Jobs, focus is about saying no. To focus in the areas that provide most value, you must say no to the low-value items. Doing so will hurt feelings and egos (most of all your own). But focus is key to success, and learning+development is no different. So get used to killing your projects and ideas.

Cluster initiatives together

Similar to Learning Clusters, Program Clusters ensure I don't provide a single solution to a complex problem. The problem of "My team won't communicate properly to each other" will not be fixed with a single workshop. Complex problems require multi-faceted solutions.

For example, improving team communication could be improved with:

• A team workshop exploring the problems they face + exercises to bring awareness to their actions.
• A root cause analysis of the moments where communication is most critical but most lacking.
• A list of templates containing best practices for the team to base their emails, reports and meetings on to ensure necessary info is captured.

For any complex problem, increase the likelihood of your program's success by adding multiple prongs to it.

The ingredients of effective learning+dev initiatives

After you have your goals and expectations written down, it's time to fill in the colour. A library could be written on this. Best pracitces in workshops, courses, performance enhancement and so forth. Each learning+dev tool has a body of research behind it all with best practices attached to it. So there's little point in me exploring anything too in-depth. Having said that, there are some axioms I consistently obey when designing any program or initiative. These axioms are there to focus on ensuring I deliver value and fail fast with whatever initiative I'm developing.

Curate with Learning Clusters

Learning Clusters are a selection of curated resources based on a topic or need. They solve the problem of providing the correct resource for each individual at the correct moment. By curating a list of resources in different mediums and different depths, I remove the need of having a conversation with the person who has requested the resource or topic. Whether they want to look at a quick cheatsheet or watch an in-depth course, I can provide everything to them in the one place and leave it up to them what they want to use.

Whenever I receive a request for training, workshops or problems in general, I always sprinkly my response with at least 1 learning cluster. The Learning Cluster adds extra strength to whatever initiative I'm designing. Even if only 1 person gets benefit from it, it was still worth the effort to create.

Track participants progress with timelines

I've written before how everything should have a timeline. This goes for both project delivery as well as individual participation for Learning+dev initiatives.

Here is what my excel tracker looks like.

Collaborate as much as possible

Depending on the type of initiative, collaborative exercises can work extremely well. Each program should have at least some level of collaboration with other individuals in the program. Particularly where the initiative is related to "soft Skills" such as leadership. Getting together with other people who are interested in learning from each other can be extremely beneficial to the participants.

Allow people to join who will make the initiative better

Not everyone wants to participate in your initiative. Maybe it doesn't speak to their needs. Maybe they are too busy to even consider what you're trying to teach them. Maybe they just don't care.

Each person in your initiative who does not participate will suck the energy from every other partipant. I have have many programs and courses of 10 or more people and 1 person has destroyed the whole feeling of the group. Try to avoid these people in the future, and if you can detect them before starting the initiative, leave them out. They will shut down conversation and sit in the background like a silent judge, making everyone else uncomfortable.

Homework is a good thing

The great thing about homework is that it's ascynchronous. Many learning programs focus on what the learner achieves in the workshop or class. However, most learning takes place outside the classroom in the flow of day-to-day work. Therefore, having homework which applies to the learner's day-to-day tasks bridges the gap between the theoretical, lab scenario and the real-world scenario.

Homework has the secondary effect of identfying who is taking the program seriously. An optional, low-value program will have increased dropout rate with homework. As a learning+dev practitioner, this is exactly what you want - to reduce the amount of other people's time you are wasting. If they don't find the program important, they shouldn't be doing it. And if nobody does the homework, it is a good sign that your program is misguided and needs to be cut.

For those who do the homework or exercises outside of the regular program meetups, it indicates they are both taking it seriously, find it useful and want to continue. A program where everyone is doing the homework regularly is a great display of its quality and importance to its participants.

For example, let's say you launch a leadership program to develop the internal leadership skills of the company. You get great initial participation. But week-on-week, fewer people show up. Of those who do show up, they have not completed the exercises and seem to just want to waste 30 minutes on a call. At this point, we need to identify if the leadership program is serving its purpose. Maybe it's the case that it's a poor program. Or maybe it's a great program and the participants aren't linking it to their development. Or maybe they're not bought in enough so that when things get challenging, they drop out in favour of easier things. While this result may look "bad", it's better than the alternative of having 20 people show up to a call where they don't bring anything to the table and just waste 30 minutes of their own time. One way or the other, the homework does its job of helping people develop in their own time or highlighting they are not interested enough to complete it and drop out.

An example of designing a learning program

I'll describe a recent initiative I developed to take the top performers in the organisation and increase the value they bring to the table. The program involved a group of 12 senior engineers who had spent their careers in the telecoms domain. The goal was to increase the number of senior engineers who could consult with customers about their complex telecoms problems.

The first step was to identify the main KPI.

• Increase number of people who can speak with customers.

Next was to write down what I thought would make the program a success. I used some of the ingredients listed above for this.

• Collaboration is key. Most engineers do not have the depth and breadth required to develop these solutions. As a team, we can do a lot more.
• Everyone needed to see everyone else progressing so that they put onus on themselves to do the work. An excel progress tracker was used to visualise this.
• Domain knowledge, not just technical knowledge, was key here. We employed the Harvard Case Method to deliver and facilitate specific cases around the domain problems we wanted to learn about.

The program we developed was excellent.

• Highest attendance rate out of all programs in the company: >90% for 4 months.
• Consistent participation with only 1 workshop delayed.
• We analysed more than 7 cases around the domain.
• 5 people were brought into customer-facing conversations within the 4 month period.

Next steps

After looking at these design principles and techniques, next we will move onto executing and managing the programs.

Maybe your project lacks engagement, stakeholders or customers. Maybe it didn't address its objectives. Maybe it was a great initiative but the wrong time. Maybe it was effective in the beginning but lost steam.

Many things can cause a project or initiative to be deemed "unsuccessful". And we need to be ruthless with unsuccessful initiatives.

If your initiative doesn't output more value than the effort that goes into it, you need to kill it. If it has little to no engagement, you probably need to kill it. If it once provided value but doesn't anymore, you need to kill it.

In my discipline, Learning+development, we need to constantly shift to meet the business needs again and again. We cannot do that if we are bogged down by managing a long list of low-value initiatives. To quote Steve Jobs, focus is about saying no.

To focus in the areas that provide most value, you must say no to the low-value items. Doing so will hurt feelings and egos (most of all your own). But focus is key to success in all disciplines - we need to be comfortable killing our projects.

The path to mastery looks something like:

• Understand the business objectives and strategy
• Develop a learning+dev strategy that supports the business strategy.
• Consult and receive feedback from stakeholders
• Define the programs to meet your strategy - we will explore this here.
• Execute the programs and track success.
• Retrospect on progress and change based on feedback.

Keep it small, keep it quick

Learning+dev no longer has the privilege of designing and rolling out large-scale projects. The risk that those projects won't meet expectations after delivery is too great. 6 months to design and rollout an initiative is too long. Learning+dev must make speed and agility a priority. We must be able to take new requirements every day, prioritise and execute them swiftly.

As we discussed in the previous post, identifying your stakeholder's priorities are key to identifying your own. Once you have an idea where your contributions will be valuable, you can think about the initiatives that would assist your stakeholders. Remember not to design things in a vacuum. Your ideas must receive constant feedback from your stakeholders.

What is a learning+dev backlog?

At its simplest, a backlog is a list of tasks. The term is extensively used in product management, as it allows fast conversations around details and priority. Since it is a single list which everyone can look at, it provides a single source of truth for projects in progress and future projects. It facilitates team discussion when executing and it makes it easier to assign work.

There are many backlog tools available, from the simple stickies on the whiteboard (my personal favourite) to extensive product management software such as Jira. If you work by yourself, your backlog may even be inside your head, though I doubt such a backlog is of much use for discussions. It's important to write it down somewhere.

How do I create my backlog?

First pick your method. Personally, I like the stickies on a whiteboard - it's good to see what you want in front of you. Stickies also means you can move things around as needed. If you want software, Trello is free and provides all the functionality you need.

Take the priorities you spoke to your stakeholders about. Start throwing out ideas - anything and everything. What initiatives can you launch to support the strategy goals?

Brainstorming techniques

Your ideas are best written down. Ideas stuck in your head are of no use to anyone. You can't see them, you can't interact with them, you can't visualise them. Brainstorming is the act of putting your ideas in front of you so you can connect ideas together, see patterns and create better ideas.

There are plenty of brainstorming techniques and tools online. Here are the ones I come back to all the time:

• Sticky notes on a whiteboard
• Mind maps
• Miro
• SWOT analysis
• 80/20 analysis

Here is a braindump of Learning+dev ideas to help:

• Workshops
• Online micro-courses
• Study groups
• Communities of practice
• Mentoring programs
• Coaching programs
• Certification programs
• "Soft" skills programs (eg. Public speaking study group)

As you scribble down ideas and swap things in and out, you will build up a list of initiatives. Well done - you've built your first backlog!

Can I add anything I want?

In the beginning, you should add anything that comes to mind. If you hit a block and can't think of anything suitable, do your research. All the problems you face have been solved before by someone else. And don't worry about a perfect solution - there are none. In my experience, about 20% of initiatives provide tangible value to the company. This is why it's important to make your initiatives small. 80% failure rate of small initiatives is great. 80% failure rate of large initiatives is terrible.

After listing down things you want to do, go through each one and figure out whether they are feasible to rollout in your organisation. Fortunately, the product managers have been doing this for a long time, so there are plenty of resources to help.

Here are some questions to help you adjust each initiative in your backlog.

• Does this initiative align with the company goals?
• Do you have the resources (budget, people, time, tools) to launch and manage this successfully?
• Are your employees & stakeholders ready and able to engage with this initiative?
• What does success for this initiative look like? How will you measure it?

How do I pick which initiatives to start with?

Again, there is no 100% correct answer. I usually start by going through the list and asking myself the following questions:

• What would happen if this wasn't rolled out for 6 months?
• Does this impact my most important stakeholder?
• How many people have asked me about something related to this initiative over the last few weeks?

Prioritising your initiatives is as much about understanding what's not needed right now as well as understanding what is needed right now.

What's next?

We didn't touch on a lot of other "design" elements of learning+dev initiatives. So I'll expand on this in the next post.

The path to mastery looks something like:

• Understand the business objectives and strategy
• Develop a learning+dev strategy that supports the business strategy.
• Consult and receive feedback from stakeholders - we will explore this here.
• Define the programs to meet the strategy including success criteria.
• Execute the programs and track success.
• Retrospect on progress and change based on feedback.

Why should we care about other stakeholders in the organisation?

For most of what we do in our jobs, nobody cares as much as us. I think that's a good thing - it's great to be in a job we enjoy that nobody else is interested in. It makes us valuable.

Every so often, I land in the fantastic position where what I'm doing is so valuable to someone else that they care more about it than I do. And this is the position we all want - to bring as much value to our colleagues and organisation as possible. Going back to Learning+dev's purpose, we want to help others maximise their value to the organisation.

This is the power of frequent experimenting. Short, small ideas executed over time increase the likelihood you will land on an important problem. 1 person starts caring about 1 thing you're doing, then another, then 2 more. Eventually, you have lots of people benefitting from your work - a fantastic place to be as any practitioner.

Now, I could create and rollout 10 new initiatives to my organisation in the morning. But if they don't meet with the organisation's strategy, then nobody will care about it and it will become noise. Even if I land on something valuable, it will be drowned out.

This is where stakeholder engagement is so important. Engaging with your colleagues and creating initiatives without your primary stakeholders buy in is a sure way for failure. Without communicating with them, you increase the likelihood that your initiatives are not aligned with theirs.

However, once you get full alignment across the people who your initiatives will impact, then you end up producing valuable initiatives that push everyone in the direction they need to go in. What's more, you will get support from your stakeholders who will work with you to make your work successful. They won't push back against you because you failed to communicate properly.

Who are my main stakeholders?

There are many stakeholder engagement frameworks to help identify and prioritise your stakeholders.

• Mendelow Matrix
• Salience Model
• Influence / Impact Grid

Or my favourite stakeholder framework is the simple question: Who do I need to keep happy? If you know who to keep happy, your can focus your communication in their direction.

How do I engage with stakeholders for my strategy?

In my experience, the best way to engage your stakeholders is to present your initial strategy in slides. If you want, you can brainstorm with them, but only if the problem is crystal clear.

You can't ask your stakeholders "What do you think I should be doing?". It's not their job to think of what your job should be. So you must always come forward with suggestions, not a blank canvas.

Once you've presented some ideas (called a strategy), you can engage your stakeholders with questions:

• How will this strategy help you?

  This will help you identify if your strategy is of any benefit at all. If everyone says "I don't think this applies to me", then that's valuable feedback.

• Will these ideas support your own goals?

  You will get a response like "I don't think this will affect my own goals directly. But we can look at my own goals if you want?". This gives an insight on what your stakeholder cares about. You can throw ideas out as you talk about their goals.

• I was thinking about doing X. What's your opinion on it?

  Open questions are good for giving people space to think and bring their own creative suggestions. They might say something like "That's not my understanding of the problem. I think we need to improve our programming skills in general - maybe create a workshop for it?". We know they don't need a workshop, but they have given us insight into the kind of problem we need to solve for.

The consulting process is an art. You need to build trust, get their buy-in, understand the other person's needs without them even knowing their needs themselves, lead people who are not interested in being led and much more. With this in mind, it's not a good idea to talk to someone and say "What do you want me to do?". I've fallen into this trap many times. Asking someone "What do you want me to do" is not helpful. You've just placed another problem on their shoulders. So when engaging with stakeholders, we must go in with a proposal. Even if you're not sure what they want, a proposal gives them something to push back against.

Overall, my strategy to engage with stakeholders looks like this:

• Develop the strategy.
• Show the strategy to all my stakeholders at the same time.
• Talk to each stakeholder individually.
• Note down thoughts, ideas, push backs, problems.
• Repeat.

The last point is crucial - repeat. There is no such thing as a strategy that is done. What matters is that you get the critical items down on paper and agreed so that you can start to work. Too many people focus on "big bang" approaches to strategy. They fail to realise that tomorrow's environment is different from today's environment. Agility is key, and that means we develop mostly small projects. This way of working helps our stakeholders get on board. We can propose ideas that can get rolled out in a matter of days or weeks instead of a matter of months. Furthermore, a small project that gets rolled out and fails is much better than a large project that gets rolled out and fails.

Doing things now vs. later

As you engage in more and more conversations, you will develop a backlog. You will uncover the ideas and solutions that are important and put a timeline on them. Your timeline is subject to change as new priorities will arise.

I present a 12 month plan in January with the full knowledge new requirements will come in that will change the plan. This is why it's important to have a strategy attached to the business goals. New requests and requirements will always come in, so you need a way of priorisiting. Or in other words, you need a way of saying "No" to anything that does not align with your strategy.

The exercise of prioritisationg is key to a Learning+dev manager's success. There are an endless number of good ideas. Your job is to figure out what is most valuable to your business' strategy. You can use various different types of prioritisation methods:

• Prioritisation matrix
• Pareto Principle (This one is a favourite of mine)

Conclusion

The best way to engage with stakeholders is to just start talking to them. Whether it's a formal meeting in the calendar or a casual chat at the coffee machine, conversation is key to a happy stakeholder.

As mentioned before, the path to mastery looks something like:

• Understand the business objectives and strategy
• Develop a learning+dev strategy that supports the business strategy - we will explore this here.
• Consult and receive feedback from stakeholders.
• Define the programs to meet the strategy including success criteria.
• Execute the programs and track success.
• Retrospect on progress and change based on feedback.

Figure out the business strategy first

We mentioned in the previous post how difficult it can be to figure out the business strategy. It's not always clear who has the best information or who is making the decisions, so it takes some time to find the right people to talk to. We will proceed based on the assumption you have at least an initial understanding of your business strategy. If you don't, it's best to start figuring it out as any learning+dev strategy you produce may be contrary to the org's strategy.

Initially, focus on the long-term

In the beginning, your focus should be on long-term objectives for your learning+dev strategy.

• Where does the company need to be in 3-5 years?
• What do they need to do to get there?
• Who needs to be part of the journey?
• What does the destination look like?

Forget about the cool workshop you're excited to run with the teams. Forget about the AI course you want to rollout. These are short-term goals, commonly known as tactics.

"Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." - The Art of War

For example, let's say you work for a software company who wants to enter the automotive industry. Here's what the long term goals might look like:

• Secure a tier-1 automotive customer within the next 3 years.
• Generate revenue of €2m per month in the automotive domain within 3 years.

Now let's overlay this with some learning+dev goals.

• Secure a tier-1 automotive customer within the next 3 years.
  • Establish a process to find new business opportunities in the automotive space such as communities of practice, Hackathons, competitions, industry site-visits.
  • Create a program that prepares the leadership team to engage with this industry.
• Generate revenue of €2m per month in the automotive domain within 3 years.
  • Identify key talent to enable this growth (eg. Account Managers, Pre-sales engineers).
  • Bring key talent together to workshop long-term strategy.

Notice we're not quite diving into low-level tactics just yet. These goals provide enough direction without describing the finer details.

As you analyse your own company, build two pictures: The company's 3-year strategy and Learning+dev's 3-year strategy. Make sure your learning+dev strategy is linked to the company's goals.

Brainstorm tactics

Take your two sets of information and pick out the opportunities for you to get involved along that journey. Ignore what you know today as a Learning+dev practitioner - that's beside the point. You need to do whatever is required to push the car towards its destination, no matter what skills you need to learn. But remember your role in all of this. This is not where you shine as the lone hero. Going back to our first article: Learning+development should help people maximise value to their organisation.

As you outline what you need to bring to the table, make sure you have this statement in mind. If you find yourself as the sole player in this strategy, you need to revisit your strategy.

Now for some tactics. Read through both the company strategy and the Learning+dev strategy. Write down any idea that comes to mind to support these strategies. The purpose of these ideas is not to define initiatives or tactics, but rather to give your stakeholders a starting point to have a conversation. If all goes well, most of your ideas will get thrown out. But in throwing out your ideas, you build a better picture for your strategy. Here's an example.

Goal: Establish a process for identifying new opportunities and building proof of concepts in the automotive space. Learning+dev tactics:

• Create an automotive community of practice lead by our automotive SMEs.
• Define 5 small projects we could research and build in the automotive area to explore new business.
• Host a Hackathon under the automotive theme and fund any promising projects.

Each goal should have 2-3 ideas under it, ranging from very small to large. Remember, the purpose here is to get conversation going. This is an early stage - we don't want to execute on anything yet.

This is how I visualise the strategy. Notice how each Learning+dev point is an idea to support a point in the main company strategy. There should never be an initiative that has no ties to the company strategy.

Next we need to talk to our stakeholders and get some conversations going.

As mentioned before, the path to mastery looks something like:

• Understand the business objectives and strategy - we will explore this here.
• Develop a learning+dev strategy that supports the business strategy.
• Consult and receive feedback from stakeholders.
• Define the programs to meet the strategy including success criteria.
• Execute the programs and track success.
• Retrospect on progress and change based on feedback.

Understand the business objectives + strategy

The world of business is breakneck. 6 months is a lifetime in business, sometimes quite literally. Companies have collapsed in the short timespan of a few months because they were unable to adapt to changes. Some famous examples are Blockbuster, Kodak, Toys R Us. But to adapt and change the business direction quickly, we first need to know which direction we are currently facing. Without a clearly articulated business vision accompanied by objectives, nobody knows where they're going. They don't see the north star. And if they don't see the north star, they can't juggle their tasks and prioritise work to move towards it.

Let's say a SaaS business CEO wants to expand to a new region - Eastern Europe for example. He has thought about this in his own head and sees lots of potential to grow. But he has failed to communicate this idea to his heads of departments. So now, instead of paying closer attention to Eastern European trends and clients, the SaaS employees simply focus on whatever problem is in front of them. Nobody talks to the Eastern European clients, nobody keeps an eye out for new opportunities. So the business doesn't grow. The CEO has become his own worst enemy because he has failed to communicate his idea to his business.

Why does learning+dev need to understand the business strategy?

Now imagine you're the Learning + Development manager. Without understanding the need to expand in Eastern Europe, how can any of your initiatives meet the needs of that expansion? Maybe the Eastern European market requires specific new skills. Maybe the market is focused on a particular niche for us to learn about. Maybe you need to include Eastern European languages in your learning+dev initiatives!

If we don't know the business objectives and the strategy created to meet the objectives, there is never going to be a moment where we are maximising our value to the company. Our initiatives could even contradict the direction of the business. By understanding the business objectives and its strategy, learning+development can support and attach itself to that strategy. By attaching ourselves to tangible business outcomes, we can track progress, metrics and successes that matter to the people around us. The value of this is incomparable to traditional learning+dev which focused on class attendance and training programs.

I don't know the strategy!

You might ask yourself, "Where can I find the business strategy?". It's not publicly available on the website - external people don't need to see the internal strategy. If you are not already participating in monthly or quarterly strateegy meetings, it will be difficult to get the insights you need. Or maybe your company doesn't have any strategy meetings (this often happens in smaller company). If you don't have the information and you don't know where to find the information, how can you learn how to support with learning+dev?

The first thing is to find out if there is a regular strategy meeting and get added to it. Being at the table when the strategy is being discussed is the most valuable place for learning+dev. If you are not invited or there is no meeting, the next step is to talk to the people who engage with the strategy. These could be C-suites, directors or other managers. Second-hand information is not 100% reliable (because people absorb only the things they need to absorb), but it is a lot better than no information at all. At least the people you are talking to hopefully have actions and responsibilities to update at their next strategy call. Ask to see and discuss their actions and figure out how you can help with specific actions.

Over time, by talking to multiple people across multiple conversations, you build up a picture of what the short-term and long-term goals look like. As you build the picture, you can progress from helping with individual tasks to proposing grander solutions.

Nobody else knows the strategy either!

Worst case scenario, there is no clearly communicated strategy. Actually, that's not worst case. Worst case is if there is absolutely no strategy at all. But this is rarely the case - your company was not built by accident. The strategy might simply be in your leaders' heads.

There are many problems that stem from not having a clearly communicated strategy, but the bright side is there is plenty of room for suggestions! So break out powerpoint start building grand initiatives. Use the strategy gap as an opportunity to excel and promote your own ideas - don't complain there is no strategy! (Unless of course the company is going under...then it might be time to look elsewhere.) Figure out what the leaders of the company want and translate it into proposals that can be rolled out across the company.

For example, let's say you have spoken to the leaders and a few people mention the need for more expertise in AWS migration. Scratching beneath the surface, you ask "Why is this expertise important to you?". You find out that many managers across the company are leading AWS migration projects and all have similar problems.

Bingo!

Now you can propose initiatives such as a cross-project community of practice, curate resources, hire consulants and so forth. And now, you have created a small strategy - do this enough times and people start to notice.

So don't resent the fact there is no strategy. The biggest opportunities lie in the gaps.

Strategy - Figure it out or build it

In conclusion, figure out the business strategy by getting to the table where it's discussed, talking to the people who are at the table, or building your own. As long as learning+dev's part involves solving people's biggest problems, you will provide a huge amount of value.

Learning+development is a strange concept. Learning+development (L&D) has its beginnings in corporate training programs in the industrial revolution where initiatives were created to ensure workforces could keep up with the pace of change. Henry Ford has the historical quote: "The only thing worse than training your employees and having them leave is not training your employees and having them stay". World War 2 had a profound impact on training the workforce in America. The rate of change in the corporate culture was so fast that companies had to invest large sums of money to ensure their workforce were able to meet demands. These shifts in attitude towards large-scale training produced new theories and academic research over the 20th century.

The 21st century brought technological revolution, leading to new initiatives in not only individual training, but organisation development. Things move too fast in the 21st century for a command-and-control style of management. So the focus shifted away from industry to the needs of the employee to enable autonomy and fast, large-scale change. Learning+development transformed to become a facilitator of strategic change in the organisation, something that many people today still don't realise.

The shift to focus on the employee has a lot of overlap with Human Resource (HR) practices. As a result, many Learning+development departments fall in as a branch of HR. This has led to the rise of organisations such as CIPD directing Learning+development towards HR needs, rather than focusing on Learning+development as a separate practice altogether. As far as I can see, this has tainted the Learning+development profession to the extent that many professionals are drawn into HR-related initiatives instead of focusing on the development of the individual and organisation. Dare I mention "Diversity, equity and inclusion"?

In summary, the Learning+development profession has transformed according to the needs of the organisation. Organisations are no longer command-and-control. They require people to own their work and transform their environment for the better. With the infinite amount of knowledge available online and much of it for free, the need for bespoke training is rarely required from Learning+development. Now, with the dawn of ChatGPT, knowledge is quick to access and easily consumed. So what now? What do we do? Training isn't needed. Knowledge creation isn't needed. Can we scrap Learning+development?

Not quite. Yes everyone has all the knowledge at their fingertips. No, that does not mean all their problems have disappeared. Now, employees must be supported and challenged. Their performance is on the line. And how do we judge performance? We judge performance based on the contributions of the individual towards their company.

So this answers the "what". What should Learning+development professionals do? We should do whatever it takes to support the performance of individuals. Or in other words: Learning+development should help people maximise value to their organisation. This is the vision for great Learning+development. We must strategise with the organisation to increase its employees' value.

That's the "what". Next is the "how".

Learning+dev Fundamentals

Like any discipline, Learning+development has an infinite amount of knowledge we can spend many lifetimes studying. But like any discipline, we need a structured approach to understanding how to master it. So what will the best Learning+development practitioner do to help people maximise their value? The flow looks something like this:

• Understand the business objectives + strategy
• Develop a learning+dev strategy that supports the business strategy.
• Consult and receive feedback from stakeholders.
• Define the programs to meet the strategy including success criteria. (Note: "Programs" here does not mean training programs, but initiatives to help the employee and organisation succeed.)
• Execute the programs and track success.
• Retrospect on progress and change based on feedback.

Over the next couple of posts, I will explore an outline of each of these areas. I hope to provide a journey of important topics to get started as a learning+dev professional.

I've been using ChatGPT consistently for about 5 months now. I experience about 20-30% extra value output each day for my management responsibilities. That means I get an extra week's work done each month - well worth the €25 investment!

With this level of extra productivity, I presumed everyone else was doing the same as me and using ChatGPT for as much work as possible. But it wasn't until I attended a conference recently that I realised how little people are using ChatGPT. Maybe people are uncomfortable with it. Maybe they see it as cheating by automating their tasks. Or maybe they are using it but don't want to say.

For anyone that is using it, the use cases are straightforward. Most use cases equate to pasting content into ChatGPT and asking it for feedback or insights. That's not to say this isn't valuable, but it only touches on the extra value it can bring to a manager. Let's walk through how I use it to manage learning and development in my organisation.

ChatGPT is not a new Google - it is a copilot

Many people have warned against using ChatGPT as a google replacement. Worse still, some people have relied on ChatGPT to their detriment. ChatGPT's answers should not be blindly trusted. Anything it produces should be verified, particularly if it is crucial information.

But anyway, quick knowledge is not the primary benefit of ChatGPT. Its value is in its ability to interact with my ideas. A loose idea can quickly get teased into a robust proposal with ChatGPT. It can be used as a coach, content creator or document expert which allows me to interact with it for a particular task.

ChatGPT prompts

Prompts are the input we type into ChatGPT. Each prompt will get you a response, but the more detailed and specific your prompt, the more relevant the output will be.

Brainstorming initiatives and solutions

Quick brainstorming is one of the most common ways I use ChatGPT. I can prepare for a meeting in 15 minutes instead of an hour. If a colleague asks me to help them with a problem, I'm able to interact with ChatGPT and propose a more robust solution that better solves their problem.

Stakeholder request example:

ChatGPT prompt:

"I want you to act as a learning and development manager in a software company. You've just received the following request from a stakeholder and you want to propose back a solution that is more robust and better aligns with their needs. Here is the request: I have one team that is poor at debugging and resolving their tickets quickly. Give them a workshop to fix this problem."

Screenshot:

As you can see, ChatGPT responds with suggestions on diagnostics, training programs, hands-on workshops and regular feedback. Not only does this better align to the stakeholder's needs, but I can propose something like this to my stakeholder at a much lower cost of my time than previously. The answer may not be 100% or even 50% what I want, but it gives me enough to start putting ideas together. Combined with my own expertise, I can write out a pretty good proposal for my stakeholder.

Create workshops

With ChatGPT, I can put together a decent workshop in 1 hour instead of 3. The workshop still needs to be tested on a group of people, but I no longer need to spend the time researching in-depth into multiple topics to find the correct one that meets by team's needs. I will still spend the time to research the chosen topic, particularly if I'm the one giving the workshop. But now I'm hyper-efficient. A quick prompt on the problem statement and what I'm trying to accomplish and ChatGPT spits out the outline of a good workshop. I can interact with the response, suggesting games or activity formats that suits my team.

One big advantage I'm getting from this is that I can create multiple workshops to offer a team, rather than offering a single workshop to everyone. Instead of booking a team into an hour's workshop and presenting them with the predefined topic, I can offer them a menu of options to choose from. This helps them get the most out of the hour together and choose something that best supports their needs. In the future, I hope to get to a stage where I can ask each team what individual problems they have and develop a workshop tailored to their specific needs.

Each workshop has some key ingredients that make it effective. I use ChatGPT to help me craft better versions of these ingredients quickly.

Ice-breakers

Ice-breakers are a common way of getting people to talk and interact with each other straight away. Here I've asked ChatGPT for a list of ice-breakers to begin my workshop:

Interactive Activities

Effective workshops are interactive and get people talking. Discussions, games and pair-based activities are all things ChatGPT can help with.

Engage with document content

One of the newer features of ChatGPT is its ability to absorb documents you provide. For example, I can upload this whitepaper for "Learning through play: A Review of the evidence".

Then I can ask ChatGPT to give me information about the document back to me.

Formulate better ideas

Learning and development is a highly creative discipline. It is fuelled by ideas that can help people. Anyone who is used to coming up with ideas everyday understands how messy they are in the beginning. It takes discussion, drawing and writing to transform a loose idea into a robust solution. ChatGPT can help us short-cut the messy phase and get into proposal mode faster.

Here is an example of a specific idea that was messy to begin with. ChatGPT was able to give me a starting point to structure the loose thoughts.

Custom GPTs

We can now create our own tailored chat bots used Custom GPTs. These are custom versions of ChatGPT that respond in a particular way which you have defined.

Learning + Development Coach GPT

Here is a coach I created that is specialised in learning and development, organisational development and innovation. I generally spend 30 - 60 minutes per week engaging with this bot to help me identify challenges and goals for myself. It is designed to act as a coach and ask me powerful questions rather than give me answers to everything. This helps me challenge assumptions and organise my thoughts.

Learning + Development Mentor GPT

I found myself typing the same information into ChatGPT again and again. The number of people in my organisation, my role, the domains we are part of. So I created a Custom GPT with all this information in it. Now I just have to start a new chat with my Learning and Development Copilot and it knows all the specifics related to my job.

Here is the instructions I give the GPT:

The GPT, as 'Learning and Dev Copilot,' is specialized in providing support for various learning and development initiatives across an organization. It offers expert guidance on remote-based courses, workshops, and projects, tailored to the needs of a diverse workforce. The GPT will provide innovative ideas for engaging and effective training, feedback on existing plans, and suggestions for improvement. It will take into account the challenges and opportunities of remote learning environments and diverse learning styles. The GPT will avoid making assumptions about the specific nature of the organization or its employees, instead asking for details when needed to provide accurate and relevant advice. It will maintain a friendly and professional demeanor, aiming to be a supportive partner in the learning and development process.

Domain expert

A big challenge for teams in my organisation is to learn domain knowledge quickly and easily. Usually this involves trawling through messy documentation and confluence pages to find the correct information. I've started to create domain expert GPTs for each team's area. I hope this will help the teams find the necessary knowledge they need quickly and easily.

So far, domain experts has included telecoms ecosystem, kafka and high performance java.

Conclusion

ChatGPT is incredibly powerful for management tasks. The increased level of productivity and quality you receive is a no brainer. Add in the extra features of the premium version and you get a powerful virtual assistant who knows nearly everything about anything.

Most things have timelines. Projects, tasks, meetings - nearly everything has an end date. Timelines are needed to clarify expectations and let people know when things will happen. Without timelines, dependencies can't be managed and communication breaks down. Your colleagues need to know what time you'll arrive at work. Your manager needs to know what date the project will deliver. You need to know when the plumber will come to fix the drain.

Timelines influence priorities

While timelines exist to add structure and predictability, they can be mismanaged. Timelines also indicate priority, so we should be hesitant to apply aggressive timelines without checking their priority. If I have 3 high priority items on my todo list, I'll do the one with the shortest timeline first.

But if I have a low priority item that needs to be done in the next hour, it suddenly becomes the most important thing on my list. If we're not careful with timelines, they can do more damage than good, introducing chaotic timelines instead of following priority.

Timelines add accountability

We are not good at task management. We opt for tasks that are either enjoyable or tasks that have someone shouting at us. In other words, we aim for the most pleasurable tasks or try to complete the most painful.

But there is a lot of space between those extremes, and the "enjoyability" of a task shifts as it progresses. Learning a new skill is always exciting in the beginning. But as soon as we hit a challenge, we say to ourselves "I'll come back to that later" or "This other thing is high priority so I better get it done first". What was once exciting is now difficult and we find excuses to do something else.

A timeline can help keep us on track for tasks that were once enjoyable but now difficult. I'm much more likely to progress with a difficult challenge if I know someone will check-in on me. This is why universities use timelines. Whether an assignment or a subject is enjoyable or stressful, the timeline is there to place accountability on the student.

Accountability vs. Pressure

We hate the word "deadline". It conjures up images of late nights and long weekends with pressure from the boss. However, we can all agree that deadlines are needed most of the time to hold us accountable to progress. So what is the difference between holding someone accountable and pressuring them? Two things are important - the intention of the manager and the support received by the person who is accountable.

A manager who has the intention of getting to the goal as fast as possible and sees people as a means to that goal will treat them as such. This has the opposite effect of creating responsible work environments and causes people to be less accountable. The person who is under pressure without any support sees responsibility as a punishment and will opt out of it in the future.

However, a manager who has the intention of supporting his people to do their best work can produce an environment of accountability where each person understands the expectations and knows the people around them are there to support them instead of pressuring them. Therefore, deadlines by themselves are not enough to hold people accountable to their goals. The manager holds his people accountable by providing clear expectations on the goals together with the necessary support to set them up for success. Once this is done, the person feels a sense of empowerment and excitement to do good work instead of being afraid of extra responsibility.

Why should I put in a timeline when I know they'll slip?

Most timelines slip - it's the nature of the complex work we do. Something as certain as "today I'll have my lunch at 1pm" is not a sure thing. While one purpose of the timeline is to predict when something will be completed, another purpose is to make sure people are kept up to date and invite conversation.

When my 1pm lunch gets postponed, I know I have made the promise to my friend to meet them and so I must now make sure they know I'll be late or need to cancel. They might be disappointed, but not as disappointed if I never showed up. So sure, timelines make us commit to things that may not come true. But thankfully, if and when things do get postponed, those commitments enable us to have the conversation to discuss a new plan.

How does this apply to Learning + Development?

I repeatedly make the mistake of giving the impression that learning is optional. In many of my Learning and Development conversations, a new initiative can often be met with pushback.

• We don't have time for that right now.
• We have a tight deadline. (see my previous paragraph on tight timelines)
• This isn't a priority for us.

In each response, there is valid feedback that makes me question whether the idea is worth the time invested. But often, teams and individuals will prioritise the tight timeline against the Learning + Development initiative. Why? Because the L+D initiative has no timeline.

• Oh it's ok. You can take this at your own pace.
• Get this done in your spare time.
• There's not pressure to complete this course.

Now, let's make sure everything has a timeline and an estimated number of hours. The above responses change:

• Anyone who signs up to this program will require 5 hours per week for 6 weeks.
• The course will close in 8 weeks giving everyone plenty of time to complete.

Now, participants understand what they are signing up to. As the program progresses, check-ins help keep in touch and remind participants of the importance of their learning. The timeline has smaller checkpoints indicating progress in their knowledge. Each participant feels a sense of onus to progress (especially if they have to give updates in front of other people) and the program has a higher level of energy and participation.

A manager's default task is to communicate. If the manager finds themselves prevented from communicating to their stakeholders by more "productive" tasks, they risk failure in their role. All managers face this challenge at some point or another and fall into the "I'm too busy leading to lead" trap. Managers should communicate all day, everyday. They should overcommunicate by sending the same information through multiple channels - email, meetings, presentations, group chats.

For example, if a manager wants to advertise each team's project status, they could:

• Send an email detailing each team's project status.
• Setup a meeting and ask a delegate from each team to give an update.
• Attach a meeting agenda to the call to communicate what they need to prepare.
• Send a follow-up email after the call showing the summary and highlighting any actions.

Look at how much communication has occurred for an effective cross-team meeting. There can be no doubt for anyone included what the status of things are.

Here's how not to do it (taken from a real-world scenario):

• Invite every team member from each team into a call.
• Ask a delegate from each team to give their update one-by-one.
• Finish the call.

In this example, the manager could say that everyone now understands what's going on. But in reality, most people who joined the call knew they didn't need to be there and zoned out. The critical actions and cross-dependencies between teams were not captured and followed up afterwards. The manager is relying on everyone to:

• Be present and attentive when someone else is talking.
• Recognise critical information.
• Recognise hidden information

Communicating in L&D

For "horizontal" responsibilities that cut across the whole company, communication is even more important as so many people rely on hearing from you. In Learning and Development for example, employees want to hear about new initiatives and opportunities that come up that they could participate in. Even if an employee never joins any L&D initiative, seeing other people participating acts as a reminder to them to keep improving themselves. An L&D practitioner can communicate to the company in multiple ways:

• Display the L&D dashboard at the all staff update.
• Send out a monthly L&D newsletter summarising the latest initiatives.
• Communicate to managers and major stakeholders that engage with the company.

These methods of communication are for the general employee. Each initiative must also be communicated individually. Few things frustrate people than feeling like there is a secret project they don't know anything about, especially in smaller companies.

With all this in mind, it therefore makes sense that a large portion of time is spent preparing to communicate. Effective emails and clear visual dashboards help people see the trees from the forest. So spending the time, whether it's 15 minutes before a call or 1 hour to prepare a company slide, is extremely worthwhile.

It's no surprise that focusing on the negatives all the time leads to increased stress and burnout. It reduces motivation and engagement with our lives and the people in it. We forget the good things we have and wish everything was perfect all the time.

Recognising the positive events can be a big step towards a more enjoyable and meaningful life. And I think this is difficult to achieve alone - I think we need to celebrate with others.

Benefits of Celebrating Wins

Give people credit

A great joy is found in telling people "Well done" when they've achieved something. Their face lights up, they try to hide a smile or they shrug it off. But you can tell that they are really pleased with themselves and excited by your compliment. The biggest part of saying well done is that you are telling them "You should do more of this". So they go away and work hard to get another "Well done".

Get people on your side

People like you more when you give them compliments and celebrate their achievements. Celebrating produces positive emotions and so you become enjoyable to be around. Even if you're known for being hard on people, if you consistently give credit where it is due, they will forgive your faults. New opportunities come up too when people are on your side. You make more progress and people are more likely to help you achieve your goals.

Recognise progress

Celebrating small wins shows progress. When we celebrate small wins, it shows we are on a journey towards a larger win. Ignoring small wins leaves people with a sense of "I haven't accomplished anything lately". For example, authors like to divide their books into smaller chunks so that they can feel a sense of accomplishment as they complete each chapter. So they're not creating a book - they're creating a collection of articles.

Give a positive outlook

Celebrating wins encourages us to celebrate more wins. There will always be nay-sayers who say things like "Well that's not very impressive". But we're not solely aiming to impress people when we celebrate - we're aiming to get credit. Amabile and Kramer's Progress Theory shows that celebrating and tracking small achievements leads to more a more creative, productive and engaged person. This gives everyone a positive outlook on the future where everyone is excited to see what will happen next.

Identify who should celebrate wins

Knowing who to celebrate with is important. Rather than an email to allstaff@mycompany.com to tell them what we achieved today, a better idea would be to send a report to our manager at the end of each week. When I start a new job or project, I keep my reporting manager up to date on every win each week for the first couple of months. This shows they are getting value from money from me straight away, rather than guessing if I was worth the hire.

Leaders

The biggest dopamine hit is not when I send my manager an email each week, but when they reply back saying "Well done". That's the first group of people who should celebrate wins - leaders. If a leader gets into the habit of celebrating and showing off the people around them, they will find enormous gratitude coming from their people. People get excited when they are celebrated. They feel more creative and courageous to bring new ideas to the table. We all want that appreciation - more than money. This is the tip of Maslow's Hierarchy of needs - self-actualisation. We want to know we are creating something great.

Teams

While leaders should celebrate wins, it's not always clear to them what small wins happen during the day. A team sees every piece of progress each day. So they are in the best position to celebrate. Take a look at your team today - what small wins were accomplished? It could have been a code commit, a ticket closure, a bug breakthrough, a difficult conversation. Turn around to person in your team and say "Good job on closing that ticket this morning!". Imagine what multiple "well done"'s throughout the day can do for people. It drives them on to achieve more and do better things.

Identify your Wins

Focusing on your wins over your failures is a different mindset than we are used to. Whether this is on a personal level, a team level or a business level, we always find it easier to find fault. In contrast, we are glad when things work out and breakthroughs happen, but quickly go back to the next headache. This is called Negativity Bias. When presented with two things similar in kind and of equal intensity, we will focus on the more negative thing. This results in a short-term outlook on situations. By focusing on the negative, we are only concerned with getting over the pain and make rash decisions that affect long-term progress.

This isn't to say that we should never focus on the negative things that happen. But we shouldn't focus only on the negative things. Acknowledging wins brings a long-term, forward facing attitude to decision making. We can see what has been accomplished and, with a little effort, work to create a similar environment for more wins going forward. There are a couple of ways to identify wins.

Celebrate during daily reflections

I'm not a big fan of daily journaling - it never clicked with me. I prefer to write about ideas (hence this blog). So when I talk about daily reflections, I'm not saying anyone should buy a bullet-journal and start drawing pictures, though feel free to do so. A daily reflection can be a 5-minute intellectual exercise with yourself or your team. Ask yourself "What was 1 good thing that happened today?". Then ask yourself the most important questions: "How can I make similar good things happen again tomorrow?". This is a tactic I credit to Woody Zuill who asks his teams everyday "What went well today and how can we turn it up tomorrow?".

Celebrate wins as they happen

One of my biggest learning curves was as a Scrum Master a few years ago. I made the mistake to view our team retrospectives as yet another "pesky" meeting. One of our phrases was "We'll talk about this in our retro next week". Imagine that - we just achieved something and we said we would acknowledge it later. We could have done much better. We should have said "Let's get on a call so that John can show us what he's done - great work John!". John gets to show-off what he's accomplished, everyone else gets to learn and we all get to give him a big pat on the back.

Simple phrases like "Well done" or "Thank you for doing that" are huge boosts to morale in any scenario. My approach is: When in doubt, say good job.

How to Celebrate Wins

Wins require effective project management at both a macro and micro level. Setting clear goals, avoiding micromanagement, allowing time, providing support - these are all trademarks of a good leader. But many managers are effective in these skills, yet forget to celebrate the wins. So we need another ingredient. We need to record and advertise these wins.

Track Wins

Nothing gets celebrated if it is not written down. So the first step to celebrating wins is to write them down somewhere. This might be in a chat, an email, a dashboard or even a notebook. The simple act of writing it down is a win in itself. You are giving yourself and your team permission to celebrate by taking the time to write it down. As you build up a record of wins, you can start advertising them to others.

Advertise Wins

I'm not good at claiming credit for things. If someone pats me on the back, I prefer to say "Oh it was nothing really". So advertising our accomplishments and achievements can seem a bit cocky in contrast. But the simple fact is this: Nobody will ever know what you've accomplished if you don't tell them. And if nobody knows what you've accomplished, they will assume you haven't accomplished anything at all. So once you have your accomplishments and wins noted down, it's time to advertise them.

Pick your Celebrants

How you advertise your wins depends on your position, your stakeholders and your surroundings. If you are a manager, you probably don't need to advertise your wins to your sub-ordinates, especially if you're not in the habit of advertising their wins on their behalf. Or if you are on a team, it probably doesn't make sense to email your friend about all the great things your team are doing. So pick the right people - who are your main stakeholders? Who is charge of your raises? Who is charge of advocating on your behalf? Who are the people you work with daily? These are the people you should communicate to.

For example, if you are a software developer on a team, it makes sense that you advertise your personal wins to your team, your project manager and your line manager. Your team because they are who you work with everyday. Your project manager because they advocate on your behalf with other managers. And your line manager because they keep record of your achievements for performance reviews. Make sure to reciprocate the "good job"'s! When your manager and teammates achieve something great, say thank you and well done. They appreciate hearing it as much as you do!

You can communicate your achievements in many ways:

• Email
• Powerpoint dashboard
• Team Chat
• In-person
• On a call

Pick the medium that best suits your stakeholders. If you are advertising to your manager, an email is the best way to ensure they see it. If you are showing-off your team's wins at a company update, a powerpoint dashboard is best. Choose the best medium for the situation.

Say Thank you if your win is celebrated

It's one thing to celebrate your own wins and the people around you. But what happens when somebody else calls you out and celebrates what you have achieved? It is just as important to accept praise as it is to give it. If we decline someone else's praise, we are saying that we don't want to hear those things in the future. It doesn't mean we need to jump up and down when someone says well done. All it takes is a simple "Thank you - I appreciate it", and move on. There is no need to make a big thing of it. But there is equally no need to make nothing of it (if you want people to say well done in the future anyway).

I'm approaching 1 year as an L&D manager. Mentorship and community are an important part of learning any new role, so 12 months ago I joined a virtual L&D community. I attended some meetups but didn't enjoy them. I couldn't take the community seriously. Everyone had the voice of a teacher talking to a young child. That condescending tone that high-fives everyone and says "that's so awesome" a little too much. Coming from a software development background, this was grating. Give me a problem and let's get some ideas on paper!

Not only were we avoiding real-life problems - everyone was making up problems that didn't exist! It dawned on me that the community didn't understand what true problem-solving looked like. They were engaged in "theatre". Everything was a show. Value was manufactured rather than created.

Theatre is when we pretend something is important without bringing forward tangible ideas or solutions. There are many public topics where we engage in theatre: environment, politics, equality, education. In the workplace, there are many more: leadership, HR, marketing, innovation, security.

I'm not saying these topics are unimportant - quite the opposite. They are so important that to treat them as theatre destroys their reputation. The same goes for Learning and Development. Every organisation and L&D practitioner knows the modern, fast-paced environment requires constant learning and better performance. So if we all agree on the problem, let's get serious about the solutions.

What are examples of L&D Theatre?

Since I joined and left the community, I've done a lot more reading. I now think L&D practitioners are our own worst enemy. We propagate the notion the L&D is soft and fluffy. The literature has great principles - OKRs, business results, learning in the moment of need... But the success stories are few and far between! We focus on the number of people that attend training rather than how it affects their decisions. We track soft, easy metrics rather than the difficult business metrics. Some key leaders are focused on changing how L&D operate. For example, the Learning and Development Podcast by David James hosts guests dedicated to valuable learning and development. I'm an avid listener.

Companies that hire L&D divisions often do so because they want to be seen as a place of learning. I repeat - they want to be seen as a place of learning. But learning by itself is of no benefit without a goal.

The best learning companies in the world understand this. Pixar uses learning as a means to create new ideas. Similarly, Google's learning culture exists to drive performance and business goals. These companies understand that learning is not the ultimate goal - it is a means to an end. Therefore, L&D practitioners must swallow this pill and focus on the outcomes the business wants to achieve.

Why does Theatre happen?

Theatre is a marketing exercise. We market things in our company to attract both talent and new customers. That's not to say we shouldn't market valuable assets in ourselves or our company. But if an asset exists for the sole purpose of marketing, it is an empty asset. Organisations must market valuable assets. If an organisation markets L&D as a cornerstone of its operations, it needs to deliver on it. Otherwise, people join the company and realise it was all for show.

How can we combat Theatre?

Beware of theatre and work to avoid it. The first step is to take ourselves seriously. How are you adding value to the business? At the end of the day, if we cannot add value, we might as well not be here.

Secondly, we need to take credit for the value we add. This is often overlooked in favour of a modest approach. But if people don't see what we do, they won't see the benefits and will perpetuate your work as theatre. So we advertise our successes and track our value added. For example, you could give an update on the monthly company call or the weekly management meeting to advertise what has been achieved. Or use a dashboard with your metrics and graphs to advertise successes.

As you create and advertise your value, everyone takes you more seriously. What's more, they will want to get involved and help out. This will lead to more opportunities to add value. Granted, none of this is easy and it takes consistent hard work.

How do we deal with Actors?

I mentioned that L&D practitioners can be our own worst enemy. The same might go for any other discipline. So how do we deal with the actors around us? There is no point is saying "Don't do this" unless you have a better idea. So suggest alternative ways of working.

Instead of focusing on maximising the number of people attending training classes, ask what brings value to each team. Instead of using the number of workshops as a success metric, track the number of workshop ideas that generated new business. Demonstrate value instead of counting numbers and show there is a better way of doing things. People will get on board when they see this way of working makes them look good too.

How do we deal with Theatre facilitators?

Some people only want theatre. They don't want to put in the work to add value to the company. They will always detract from the mission. A direct conversation results in an argument. Ignoring them results in sabotage. These detractors are not our friends when we introduce new ways of working.

Instead, show them incremental and early wins to demonstrate the value of the new ways. Do not focus on what they have to say, but make sure they hear other people promoting your new way of working. In time they will get on board when everyone else gets onboard.

Conclusion

Theatre is everywhere. Many people enjoy the theatre - I don't really have a problem if you do. But if I can't add value, then my employer makes a loss on me. In my mind, this is the equivalent of theft. If you want to break out of theatre, figure out what is valuable to the people around you and do more of it. You will be taken seriously, more opportunities will open up and you will feel great satisfaction in picking the difficult route.

What is an L&D vision?

A Learning and Development vision is one of the most powerful tools you can use to improve your organisation's learning culture. An L&D vision describes the future you want to create for your organisation. A good vision depicts 2-5 years into the future. Anything shorter term is more a short-term goal than a vision. For example, your short-term goal might be to increased your click rate by 10% in the next quarter, while your vision might be to become the leading provider of affordable education in the world.

Secondly, the L&D vision differs to the company's overall vision or "mission statement". For example, your mission statements might look like "To create great recordings of old books" or "To save people money".

Thirdly, the L&D vision is not a plan. It should not describe the steps towards achieving some goal. Its primary purpose is to communicate the future to stakeholders, colleagues and customers.

What are the benefits of a vision?

Marketing

A strong L&D vision statement is marketed to people to get everyone focused on the same destination. It gives you a starting point to make your arguments with stakeholders, managers and colleagues. People will find it much easier to help you if they get onboard with your long-term vision.

Focus

A vision brings focus to your L&D strategy and backlog. L&D leaders often find themselves with too many things to focus on. A vision gives the leader the ability to say no to things that do not align with that vision.

For example, if part of the 5 year vision is "to support the business in diversifying their customer base", then initiatives like "improve our current customer engagement" can be deprioritised. There are always an infinite number of things to work on. The L&D leader needs a method of saying no to maximise their effectiveness and focus on the high-value opportunities.

Find 'True north'

The L&D vision is the true north. A vision gives your L&D division a direction. The direction might not be 100% accurate. In fact, you can be sure it won't be. But you need to go somewhere and aim for something. We could spend days, weeks or even months analysing the best way forward. But business and needs change too quickly. L&D need to move forward quickly and adjust for change. A vision guides you for each step and decision you make.

Celebrate wins

As you move forward towards your vision, you can celebrate wins along the way. Even if your vision is something that may never be fully achieved, breaking it down into milestones gives a great sense of progress. As each milestone is achieved, you can celebrate with your team or colleagues. Metrics are important to attach to each milestone so that you know when it is accomplished.

Strive for excellence

The L&D vision should be grandiose. It should aim for something that seems just out of reach, but not something impossible. Setting a high bar will push you and your division towards something great.

How can I develop a vision?

"Start with Why"

Simon Sinek's book demonstrates why visions are so effective. Explaining people the 'what' is relatively straight forward. What are we doing? What's the next step? What's the goal?

But answers to these questions will not get people on board. Answering the "What" does not convince people to change or to join you in your mission.

Explaining the "Why" is much more important. It is also much more difficult and thus, we often either forget about it or push it away for another day. It requires a lot of thinking to define the Why. But once you have defined your purpose, it is much easier to communicate it to colleagues and stakeholders.

Obsess over the destination, not the journey

You may have heard this put in other ways: "Fall in love with the problem, not the solution". It means the same thing - the solution is not your end goal. Many L&D leaders get caught up in delivering the perfect solution. They get caught up in the journey, the analysis, the design, the delivery and the review.

These are all important aspects to L&D, but they create a "production trap" where we get caught up in the journey and forget about the destination. What happens if the problem statement changes in the morning? What if our idea had false assumptions? What if our solution needs to change? We know by focusing incessintly on the destination. Everything we design and deliver is questioned at all times: "Does this get me to my destination?".

Think Big

Big ideas inspire others. Small ideas do not. If the L&D vision is not grand enough or big enough, nobody will get excited about it. Think about Google's vision: "To provide access to the world’s information in one click." Focus on visions that add value to other people's lives. These sorts of visions inspire and grab people's attention.

It helps people

People get inspired with vision of helping themselves and helping other. The horrible cliche "making the world a better place" is perhaps one of the only statements all people can get behind. A vision statement that focuses on the person you are helping will inspire others to get on board. A great vision will get people to say "I want some of that".

Be Dangerous

An L&D vision that stays inside the lines and does not attempt to push or break boundaries is too safe. Too often, L&D are treated as one-stop training shops. If L&D wants to affect real change and change business outcomes, we need to think big and dangerously. When people ask us "This doesn't sound like a learning initiatives - why are you focusing on this?", we need to answer with a strong vision.

A realistic future

Your vision should push the boundaries to the extent that circumstances allow for them. For example, an L&D vision that says "Allow learners to download any information to their brains in an instant" is not supported by any realistic technology (yet). Similarly, a vision that focuses too conservatively is no good: "Help teams to learn together". A great vision should push the boundaries while remaining in the realm of possibility.

Changing vision = Weak vision

An L&D vision that changes or iterates means that it was a weak vision to begin with. A good vision needs to be feasible. Challenges will still come up, but the vision should be able to withstand. A vision that iterates and changes because the challenges are too great means either the vision is weak or the people aren't actually behind it. Having said this, the journey can always change. The details are not set in stone and the strategy can (and should) iterate constantly. But the destination should always remain.

Ingredients to a compelling L&D vision

Time

A great L&D vision is an exploration process. You cannot hope to create it in one sitting. If you rush your vision without giving it time to soak in, you won't be able to argue in its favour and it will feel flimsy.

Write and rewrite, then rewrite again

As you take the time for your vision to soak in, it needs to be hammered out. Writing down your vision is the best way of adding depth to it. Furthermore, without writing it down, how will you know if it makes sense or not? Most proposals I have sound silly once I have them written down. I'm writing a new L&D vision as we speak. I look back at the first draft I showed my manager and cringe at how little sense it made. I'm on my 6th draft now and it's finally beginning to take shape and make sense to the business.

Stakeholders buy-in

Stakeholders need to be involved early on so that they can get a sense of what you are trying to achieve. Early and frequent conversations with stakeholders gives them the context they need to understand your vision. If you come at them with the vision statement, they will wonder where it came from. Bringing them through the journey will help them agree with your final vision and give you buy-in when you start executing the strategy.

Start with Why

I make this mistake all...the...time. It's infuriating each time it happens again. Why do you have this vision in front of you? What is the point of saying you want to create a culture of learning and innovation? Why does it matter to anyone who you talk to? If you get the why down, it will be much easier to get a what. Furthermore, the what will really matter rather than look like a bumper sticker.

Take the leap

No L&D vision can be validated up front. If that were possible, it probably means the vision is too small or short-sighted. The vision should be for 3 to 5 years into the future so that it drives people towards something meaningful.

Become exhausted reminding people

People Need To Be Reminded More Often Than They Need To Be Instructed. - Samuel Johnson As leaders, we don't like repeating ourselves. Phrases like "As I said before" or "Going back to my last point" tell people that we are frustrated when we have to repeat ourselves. But leaders have no choice - we have to continuously repeat ourselves. This is important when evangelising a vision. We need to have our ducks in a row - then we need remind everyone what our ducks look like. Remind people of the vision again, and again, and again. Ideally, you should be able to write out your vision in a sentence and explain in through an elevator pitch.

The team retro is the sacred space where all team members bring improvement ideas to the table. Team retros are not complicated. But it can be difficult to participate given all the distinct personalities in a team. A great retro will leave all team members satisfied that they have spent their time productively. Unfortunately, my experience tells me that many teams have retros as a tick box exercise rather than a productive meeting. I firmly believe that effective, regular retros lead to teams that are a joy to be a part of.

The key ingredient to effective retros is participation. After looking online, I have only found articles and books describing how to facilitate a retro. I haven't seen anything describing how I should improve my participation. So here we go.

"I don't like talking in groups"

The engineering industry is full of introverts. Most of us didn't enter into software engineering to talk to other people. The dream was to stay at our desk in the corner of the office and write code. This may have been possible up to the mid-2000s. But today software is so complex that is requires multiple minds working together. The team is the new unit for software development. Everyone must work with other people to deliver high-quality software, whether they like it or not. If we don't have a choice to work with other people, we might as well make the most of it in our retros and discuss how we can work better together. Furthermore, why not figure out how to enjoy working together in a team?

Solution

• Speaking up in groups can be tough. Think about what you want to bring up in the retro before it begins. Write it down on a piece of paper.
• Instead of speaking up to your whole team, talk to 1 person about your concern or idea. Pick the person you like the most! Then present your idea to the team together.

"My teammates don't give me a chance to speak up"

In an effective retro, people talk and argue together. If you don't have many chances to speak up, keep in mind this could be a sign of fruitful conversation. The retro facilitator's job is to ensure everyone's voice is heard, but this is difficult. Sometimes, dominating voices want to give an opinion on everything. Whatever the reason, it is important to get your voice heard, especially if you have something valuable to say.

Solution

• Try to enter the conversation by saying "Do you mind if I share my thoughts?". This politely signals to everyone that you would like to be heard.
• If you continuously struggle to speak up, pull your retro facilitator aside and express your concerns. Tell them you would like them to make more space for you and your quieter teammates in retros. The facilitator will likely appreciate the feedback. The biggest concern any facilitator has is to get everyone participating.

"I can't think of any serious problems"

This is common in less experienced or new engineers. People new to the team tell themselves "I'm new here. I need to gradually integrate myself to the team, so I'm not going to speak up yet. Anyway, it sounds like my problems are tiny compared to the problems my team are bringing up!". But this ignores one fact: everyone is part of the team. Therefore, everyone should express their ideas, no matter how small they are.

Solution

• If you have nothing big to bring up, offer up a smaller suggestion. Maybe it's a blog post you saw online explaining how to make better code reviews. Or maybe you want to receive more pair-mentoring from a team mate. All suggestions are valid.
• Not everything has to be a problem. Think back to a day or hour where you thought "This is great - I love this". Offer it up and ask "Could we figure out how I can do more of this?". This is called strength-based inquiry. For example, maybe you had 2 hours yesterday when you were in the zone. Explore with your teammates how to get more 'zone' time.

"I'm afraid of someone disagreeing with me"

We never want to look foolish in a new team. Depending on the team dynamics, teammates may be either be comfortable with disagreements or they may be more tentative. While a team who are comfortable disagreeing with each other is a sign of team trust, it can be intimidating for a new joiner to raise suggestions.

Solution

• Start small. Test the waters. Talk about something that affects you rather than a general team issue. If you don't want to tread on other people's toes just yet, focus on yourself.
• Write down your idea. Practice arguing against yourself and come with a list of pros + cons. This will help you argue your point if you get pushback.
• Change is necessary, but uncomfortable. Therefore, disagreements are signs that the team is exploring real change. So speak up! If you don't, nothing will change.

"I can never think of anything to say"

It can be tiring to think of problems week-on-week. Sometimes, we go blank or have a bad day. When this happens, it feels like we are not contributing. Or worse, if we fail to contribute regularly, it can feel like the team relies on 1 or 2 people to make all the improvements.

Solution

• Tell a story of something good that happened. Retros don't need to be full of problems. Talking about the good things helps people remember their strengths rather than their weaknesses.
• Thank a teammate for their help. People like to feel appreciated for stepping up.
• Prepare before the retro. Write down your own thoughts on things that have frustrated you in the last few days. Maybe it was the way someone spoke, or maybe you don't understand what someone in your team is building. Reflect before talking with your teammates.

"I think the retro is a waste of time"

Let's face it - bad retros are a waste of time. Companies tell teams "We do Scrum", so the team ticks off each Scrum event without spending time to get good at each event. The team is disengaged because the same questions get asked every retro: "What went well? What went poorly? What should we improve?" Maybe you sometimes get a good discussion, but then the team comes back at the next retro to realise that nothing has changed and no actions were taken.

Solution

• Express your feelings. Say you don't enjoy talking about the same things every retro. If you have a scrum master, ask them if they could research some improvements in their retro.
• Do a bit of research yourself. Retromat is a great, quick resource for retro templates.
• Ask your teammates how they feel. Maybe it's just you that feels disengaged. But maybe everyone feels the same.
• If you're not enjoying making your team better, ask yourself why. Nothing ever changes...we still have the same problems...I'm the only one that speaks up. Talk about these problems to your teammates and come up with some experiments.

Onboarding Antipattern: Obvious Blindspots

...where the company assumes that obvious information is obvious and the onboarder will 'just know it'.

Problems with this antipattern

• Less experienced people have less knowledge. Something that is obvious to a 20 year senior is not obvious to a junior fresh out of university. For example, steps to setup a dev environment might include "Install the docker container named 'company-dev-123'". This is a terrifying instruction for a junior. What is docker...what commands should I type...what websites should I visit. These are all questions that need to be documented.
• Most information is quite complex in the beginning because the onboarder doesn't know what info is important and what isn't. They cannot separate the wheat from the chaff and regularly go down rabbit holes. I've even seen this with senior engineers who are too proud to ask their new team for clarification.
• The manager often lacks empathy if this antipattern occurs. They might say "Why didn't you just ask someone for help?", without seeing that the new joiner didn't know who to ask or even that they were allowed to interrupt other people's work.

Antipattern solution

• Many antipattern solutions come down to decent documentation together with a mentor. This combination gets the onborder through 95% of their issues in the first couple of weeks.
• Assume every new joiner is a junior straight out of university. Assume they don't know what technologies they need to learn, who to contact or how to message another human being. Take your expectations and cut them in half. An optimistic onboarding means a bad onboarding experience. The more hand-holding in the beginning, the better.

Onboarding Antipattern: Social Exclusion

...where the onboarder doesn't meet anyone in their first few days, making no new relationships or meaningful connections.

Problems with this antipattern

• Contrary to popular opinion (especially in engineering circles), the most important part of any job is not what you do but who you do it with. The best onboarding experiences people remember are not when it goes perfectly, but when they make meaningful relationships and have fun with the people in their new company.
• Most jobs today require group thinking. In other words, success is not dependant on a person's individual abilities, but their contributions to a larger team of people. - The onboarder does not feel part of something greater in their new job. They start asking themselves "Is this really what I signed up for?".
• Companies often focus on processes and projects instead of the important part of their company - the people. A bad onboarding process where people struggle together is better than a "perfect" onboarding process with nobody to interact with. In the former, at least the onboarder is making personal connections.
• The onboarder feels like an obstacle to be avoided instead of a valued employee. "If nobody talks to me, I'm not worth people's time."

Antipattern solution

• Have a list of people from various areas to introduce to the onboarder in their first day and first week.
• Introduce the onboarder to their team, ideally in person. If this is remote, make sure the onboarder knows what everyone looks like. I've met people who don't know what their teammates look like after a year of working with them because the team never had their cameras turned on!
• Ideally, the team should do something non-work related like going for lunch together. This breaks the ice and gets the onboarder talking to their new team.

Onboarding Antipattern: Onboarding Carousel

...where the onboarder finally gets comfortable with their colleagues and responsibilities, only to be told they are moving areas again.

Problems with this antipattern

• The onboarder has spent weeks, if not months, soaking themselves in the information, practices and people of their new project. All this effort is not in vain because they have been told they are moving to a completely different area.
• The onboarder is frustrated - all their efforts have been flushed away.
• The company has spent weeks and months of salary on the onboarder to no avail.

Antipattern solution

• This antipattern can be prevented in advance with a bit of foresight.
• Don't put people into teams with projects you know will be cancelled.
• Avoid putting people into teams that are likely to be moved soon.
• In cases where it is unavoidable, give the onboarder as much notice as possible. Lay out a plan for their new area so they don't continue wasting time learning things they won't need.

A good onboarding experience will get the new-joiner up and running quickly. A great onboarding experience will stay with them forever. A terrible onboarding experience will leave a horrible taste in their mouth about their new company on their first day. They will lose confidence in themselves and the people around them. The onboarding experience is a litmus test for how seriously a company supports their people.

Building a great onboarding experience doesn't require much secret sauce. Most of the battle is to understand what makes a horrible onboarding experience and then do the opposite! Here are some antipatterns I've come across to ensure your onboarder has a terrible experience.

Onboarding Antipattern: Information abyss

...where the company provides no information to the onboarder, assuming they will figure it out or "just know it". This leads to onboarders feeling lost.

Problems with this antipattern

• Without clear instructions, the onboarder must be brave enough to ask for help. There is enough to contend with without trying to improvise every step of their first few days.
• Every obstacle to getting started is another frustration for the onboarder.
• The company loses time to productivity. This is the moment the onboarder starts returning value on their salary.

Antipattern solution

• Provide a document (physical or digital) containing clear instructions how to setup their laptop and access the internal company resources.
• Include instructions for the basics like email, online accounts (eg. microsoft suite), development environment, password reset procedures...
• Build on the documentation over time and include new procedures to make the onboarding process more seemless.

Onboarding Antipattern: Muddy Instructions

...where the company provides instructions that are unclear, ambiguous or incorrect.

Problems with this antipattern

• The new-joiner feels productive at first but gets more frustrated as time goes on.
• Bad information is worse than no information. It only serves to frustrate the onboarder.
• The onboarder is torn between trusting the procedures which don't work and interrupting someone for help.
• The onboarder feels stupid that they can't figure out the procedures.

Antipattern solution

• All documents should be sanity tested every few months.
• Gather feedback from every onboarder, asking specifically about information that was unclear.
• Give onboarders the authority to update documentation to make it better. This is simple if the documentation is digital.

Onboarding Antipattern: A Philosophical Onboarding

...where the company focuses on documentation and videos to give their onboarder a strong grasp of the theory of their job instead of focusing on what tasks the onboarder needs to do.

Problems with this antipattern

• The onboarder gets frustrated when they are asked to learn as much theory as possible in their first few days.
• Without knowing what they need to do, the onboarder feels like they are not progressing.
• The onboarder is delayed in becoming productive because they have no practical knowledge of what to do.

Antipattern solution

• Write down the main 3 tasks that qualify new-joiners as 'productive'. For example: First code commit, first ticket closed, first improvement introduced. Write the steps to each of these tasks and bring the onboarder through them before giving them the theory.
• Give the onboarder a mentor to clarify their questions.
• The onboarder is a member of their team from day 1. Ensure the team understand this and include them at all moments.
• Replace steps containing "Learn about A, B, C" with steps that say "Do X, Y, Z".

Onboarding Antipattern: A journey without a destination

...where the company has no clear goals or success criteria for the onboarder. The onboarder wonders what they should do next.

Problems with this antipattern

• The onboarder is left without any clear goals, wondering what tasks they should prioritise.
• The onboarder doesn't know what success looks like and therefore get demotivated when they feel they're not progressing.
• The company is not getting quick return on investment from their new hire because they don't know what to do.

Antipattern solution

• The onboarder should be provided with a list of goals they need to achieve in their first day, first week, first month and first 3 months.
• Clear criteria should be provided to each goal (eg. To confirm you have setup your outlook account, open the email titled "Day 1".)
• Each goal should be supported with either documentation or a go-to person such as a mentor for questions.

More antipatterns

3 more onboarding antipatterns

Let's say James (a manager) pulls me aside for a talk.

"David, my teams just don't collaborate. They work by themselves and only talk together in their morning standups. Even their planning sessions and retrospectives are silent. Because of this, the team is duplicating their work. People find out they are working on the same code as their teammate. Instead of helping each other out, they wait for the other person to finish before starting their own task. I'd like to have a workshop on collaboration - that should fix things I think."

I've had a lot of these conversations and they can be difficult requests to navigate. When I was an engineer, I could look at a bug and trace the logs to create a story of what's breaking. I could use root cause analysis to find the underlying problem. Usually, it was a problem underneath a problem underneath a problem. The beginning is tiring, but as you get good at root cause analysis, it becomes quite enjoyable. It's a mental challenge to figure out quickly what all the different causes could be.

This is how I've treated my L&D conversations until now. If I'm talking to James about his problem, I would open with a couple of questions like:

• Why do you think this is happening?
• Have the team ever collaborated together?
• Has anything changed to worsen that collaboration?

Usually, the answer is something along the lines of "They have been under a lot of stress lately". In my tradition root-cause style, the next step is to figure out the cause of stress.

• Where is the stress coming from?
• Why did they overcommit in the first place?
• Is their project manager supporting their workload?

I've asked 100 probing questions to build a full picture, and he's exhausted.

And the problem is rarely unqiue. It's usually along the lines of overcommitting, scope creep, bad management or something similar.

So let's say we identified that James' team overcommitted and are stressed as a result. As a reuslt, the team have shut down communications and blame each other when work isn't done on time.

So what's next??

We can't undo the root cause of overcommitting, only prevent future occurrences. James is looking for an answer now, not in three months time.

No matter what the outcome of the above situation is, James probably hasn't come out of our conversation with high hopes. He's just spent the last 10 minutes tirelessly digging into the teams problems. I've asked 100 probing questions to build a full picture, and he's exhausted. What happens next time he has a problem? He will think back to this conversation and remember the pain of talking to me. He'll leave it for another day and potentially leave me out of his future issues altogether.

This is the challenge with using the root cause analysis as the only tool to diagnose people problems. It's annoying to be asked "And why do you think that happened" 10 times over to find the root cause. I've always found the 5 Why's to be an irritating exercise.

Other conversational types

We've established that a single conversational tool in our toolkit is not enough. What other types of conversational tools can bring more insights and value?

Appreciative Inquiry

Appreciative inquiry focused on what's working in an individual, team or organisation. Rather than using a problem-solving approach to conversations, it looks at the individual's or group's core strengths to identify improvements. Once the person identifies their strengths, they are encouraged to dream about a vision of the future.

• What does the perfect future look like?
• What could happen if we felt like this all the time?
• What else could we do if we allowed this to happen indefinitely?

Woody Zuill took this approach in his "Turn up the good" method of team improvement. At the end of each day, he gathered his team together to ask "What went well today?" and "How do we turn it up to 10 tomorrow?" For example, if the team enjoyed programming together as a team for the two hours today, they could ask themselves "How can we do more of that tomorrow?". They might decide to program together for 4 hours the next day to see how it goes. As the team build on their strengths, they bring a new kind of energy to the day. The team is no longer concerned with the most stressful problem on the table. Now they have something to get excited about!

The Appreciative Inquiry model looks like this:

• Discover: What are the things we do best?
• Dream: What would happen if we did more of this?
• Design: What's the outcome we'd like to see next?
• Deliver: What should we try?

In Woody's case, his team's daily retro probably looked something like this:

• Discover: What did we do really well today? (eg. Our 2 hour team programming session was great!)
• Dream: What could happen if we did more of this tomorrow? (eg. We might be tired, but we also might figure out that difficult ticket we've delayed)
• Design: What would we like to see as an outcome? (eg. We would like to see our most difficult ticket resolved)
• Deliver: What experiment will we try tomorrow? (eg. We will try team programming for 4 hours tomorrow)

The team analysed their strengths and picked an experiment for the following day.

Powerful questions

Powerful questions is a coaching technique used to engage the other person with open-ended questions. Instead of directing the conversation down a specific path, we can use powerful questions to take advantage of the other person's expertise.

Powerful questions generate curiosity, encourage reflection, invite creativity and generate energy. A constant focus on the problem becomes tiring and stressful. When we ask "Why did this happen?...and why did that happen?...and why??..." to get to the root cause, this can sound urgent and stressful. Furthermore, looking at the negative problem stifles creative solutions. Powerful questions bring some energy and excitement to the conversation while keeping it solution focused:

• What opportunities do you foresee for our team to expand our skill sets and take on new responsibilities in the future?
• I'm hearing you would score your team a 2/10 in collaboration. What would 10/10 look like to you?
• What are your team's strengths? How can we use those strengths to solve this issue?
• How can we reframe this problem as an opportunity for learning?

Coaching techniques

Coaching techniques capitalise on the other person's knowledge and strengths, facilitating them to solve their own problems. Instead of giving advice, the coach guides the conversation through questions, encouraging the other person to brainstorm and test their own ideas. There are various coaching techniques:

• Active listening: Get comfortable with the silence and repeat back to the other person your understanding of what they have said.
• Goal setting: Establish clear goals together using something like the SMART framework.
• Accountability: Help the other person stay accountable to actions by checking-in frequently. This encourages them to take ownership of their development.

When practiced, these tools transform the L&D practitioner into a skilled conversationalist. They come across as clear communicators and, most importantly, creative problem solvers. The difficult problems in any industry are people problems. Therefore, having a single tool (such as root cause analysis) to solve every problem is like using only a hammer to build a chair.

Do you ask yourself any of these questions?

• Where am I going in my job?
• Why do I feel demotivated even though I have the position I always wanted?
• How do I get rid of the feeling of being stuck?
• Why am I not motivated to improve anything?
• Why do I feel the need to try everything?

I've had some of these questions in the past. Sometimes, I've achieved exactly what I wanted and set out to do, but I still had the feeling I wasn't progressing. Some people say "I'd love to be the CEO of a company some day". But when I hear that, I hear "I'd love to achieve the title of CEO some day". And this tells me that they probably have no idea what being a CEO entails. Because achieving the title is arguably the easiest part of being a CEO. The real journey begins after that.

And this is what I admire about people in big positions. Think CEOs, presidents, politicians, sports people. They understand there is no final destination. Once they have accomplished something big, they know they have to wake up the next day and keep moving. This mindset is different to the mindset most of us have. We generally treat the goal as the final destination. The CEO treats their accomplishment as a milestone along a bigger journey. When we treat goals as final destinations, we can get caught asking ourselves the questions like "Ok I achieve my difficult goal...what's next?". The CEO needs to start leading the company. The graduate needs to start looking for a job. The PHD graduate needs to know what to do with their PHD. The Wimbledon champion needs to prepare for next years' competition.

Developing a Vision

Goals need to have a bigger picture that include ourselves and the people around us. When the CEO wakes up everyday to a new problem that could end the company, they need to be able to say "This is worth getting up for because...". When the PHD student is feeling burnt out in their 3rd year of consecutive study, they need to be able to say "I'm going through this pain because...". The same goes for any difficult task. You need to be able to say "This is worth it because...".

The "because" is our vision.

• What will solving this problem get you?
• What step of the journey will you be closer to after today?
• Why is the pain today / this week / this month / this year worth it?

The answer is unique to everyone and can include visions like family, career, health and finances.

Writing it down

For some reason, writing down our vision and integrating our current goals gives it more power. It is difficult to write down what we want for the future, because acknowledging what could be means acknowledging what might not happen. But doing so organises our messy thoughts. We might think we know what we want becuase we've said "I've thought about this a lot". But we haven't really thought about it unless it's written down. The future is too complicated to analyze in our heads. There are too many variables, conflicts and outcomes.

For example, I recently wrote down my vision of the future. After identifying the main goals and defining the steps to getting there, I realised two goals were in conflict. I saw that developing my new hobby required me to be away every Saturday for a few hours, conflicting with another goal to spend more time with my family. Until I wrote this down, I didn't see the conflict, even though it seems obvious in hindsight.

Steps to developing a vision

If you want to try this out, you can start developing a vision by answering the following questions:

• Where do you want to be in 5 years with your job?
• Describe what your ideal family life would be like. Include parents, siblings, children, partner...
• Combine everything and describe your ideal future:
  • Where do you want to be?
  • What do you want to do?
  • What kind of person do you want to be?
  • Why do you want these things?
  • What steps will you take towards these goals?
  • When will you start each step?

Finally, describe the kind of vision you don't want. As you right out a future you dislike, you will realise that it is not only possible, but likely to happen if you don't work towards your vision.

• If you failed to achieve the above, how would you feel?
• What does the future look like with none of the above goals achieved?
• Would failing to achieve your vision cause pain or anxiety on you or your loved ones?

While the previous exercises describe a vision to run towards, this will help you build a picture of the kind of future you want to run away from.

In his book, Extreme Programming Explained, Kent Beck describes how Extreme Programming was conceived: "My goal in laying out the project style was to take everything I knew to be valuable about software engineering and turn the dials to 10." Woody Zuill, the author of Mob Programming, took this idea with one of his teams, running a short retro at the end of each day with his team. In their 15 minute retro, they asked themselves the question: "What went well today and how do we turn it up to 10 tomorrow?" After deciding what the team did well for the day and figuring out how to turn it up to 10, they came back the next day and tried their new practice. Over time, they developed a mob programming way of working which Woody now talks about all over the world.

We often forget to look at what we're doing well. We're too focused fixing problems. And once the problems are all fixed, we make up problems to fix. For example, software teams often have an excellent 'root cause' mindset. They look to problems in their team, quickly find the root cause and fix it. But many problems have complex root causes, particularly when it comes to interpersonal, team problems. Questions like "Why is our team engagement low?" or "Why is my team not motivated?" have multiple intricate root causes. These root causes require skilled practitioners to diagnose. Turning up the good avoids this way of thinking. Instead, it focuses on what is working, encouraging people to collaborate together to come up with a new idea.

Why is it important?

Focusing on the good has multiple benefits. Firstly, focusing on growth leads a team to being excellent at their jobs. When we pick something we do well and focus on improving it further, we leverage our strengths instead of minimizing our weaknesses. If I'm the keyboard player of a band, should I improve my keyboard skills or learn the drums? Given my value as a keyboard player, I argue it is better for me to learn new keyboard skills! This will give my band a better keyboard player instead of a bad drummer. My strengths as a keyboard player are what make me valuable.

Secondly, problems seem to fade away when we turn up the good. A team that does great code reviews could turn their reviews up to 10 and create smaller code commits. Over time, this leads to more frequent code reviews, reducing the number of bugs and reducing development cycles.

Thirdly, focusing on what you do well is energising. Many teams host retrospectives with dread. "Oh great - another set of problems we haven't fixed since the last retro". Teams that have a "Good | Bad | Improve" retro often skip over the "Good" section, assuming it's there as a tickbox exercise. But what if we removed the "Bad | Improve" sections and just focused on the "Good"? The team will focus only on what they have done well and celebrate their successes.

Turning up the good in our personal lives

Take a sheet of paper and write at the top of the page "Good things I do in my life". Your list might look something like this:

• Spending time with my family after work.
• Meeting up with my friends for coffee.
• Reading fantasy books.
• Playing music in my band.

For each idea, write how you could turn it up to 10.

• Spending time with my family after work: Dedicate 2 hours after work each day focused solely on my family without any screens.
• Meeting up with my friends for coffee: Schedule a coffee every two weeks with your friend to catch up.
• Reading fantasy books: Set aside 30 minutes before bed to read a book.
• Playing music in my band: Practice an extra 30 minutes each week before band practice.

This way of continuous improvement is motivating over time. It encourages focus, ensuring you don't spread yourself thin by taking on too many new tasks or hobbies. This is particularly helpful for someone like me who wants to do new things all the time. We can do new things all the time by turning up the good.

How to turn things up

When I started diving into this concept, I quickly realised that it's easy to see what my team and I do well. The difficult part is turning it up to 10. Here are some ideas on how to turn things up to 10.

Scale it up

Apply the practice to more people or more teams. For example, if there are people that work well together, get more people on the team to work with them.

Enhance the process

Refine the good thing to make it even better, incorporate new ideas and bring in more advanced technologies. For example, a team that are known for following company security guidelines could think of a way to automate some of their practices and share it with other teams.

Share the expertise

Expand the expertise across the team or the organisation. For example: An expert in java programming could pair with some of the other java programmers to show them their techniques and tools.

Set a higher standard

Raise the bar to further increase the team's output quality. For example, if a team have great code coverage, bring in some extra rules like Sonarqube to catch and suggest better coding practices.

Reward the good thing

Celebrate the good practices and behaviours of the team. For example, a person who steps up and helps another team mate in their time of need could be called out and recognised.

Increase the frequency

If the good thing occurs frequently, see if the team could increase its frequency. For example, if the team spend 15 minutes learning together in the morning, they could boost it up to 1 hour learning per day.

Measure success more often

If the team finds that recognising their good behaviour is useful, they could increase how often they evaluate their good behaviour. For example, a team that runs the 'turn up the good' exercise in their monthly retro could think about turning up the good on a weekly basis.

I posted a question to the hackernews community asking them "Ask HN: What's the best lecture series you've seen?". Here are the highlights. You can read the full list in the comments.

Results

Free Courses

• Andrej Karpathy: "Neural Networks: From Zero to Hero".
• Andrej Karpathy: "Let's build GPT: from scratch, in code, spelled out."
• Classical Physics by V. Balakrishnan from IIT Madras, India => First lecture => Whole Series
• Gilbert Strang: Linear Algebra
• Ken Joy: Computer Graphics
• Percy Liang and Dorsa Sadigh: Stanford CS221 Learn AI (2019)
• Micromouse 2021-2022 by UCLA
• Robert Sapolsky: Human Behavioral Biology
• Feynman: Physics
• Sussman & Abelson: SICP => Particularly Streams
• Timothy Snyder: The Making of Modern Ukraine
• MIT 16.885J Aircraft Systems Engineering, Fall 2005
• Jeremy Howard: Practical Deep Learning for Coders 2022
• Andy Pavlo: Intro to Database Systems
• Robert Morris: MIT 6.824 Distributed Systems
• Christof Paar: Introduction to Cryptography
• The Maths of General Relativity
• Walter Lewin: MIT Physics
• 3Blue1Brown: Linear Algebra
• Berkeley Psych 117: Drugs and Human Behavior

Paid Courses

• The Other Side of History: Daily life in the Ancient World

Use this template to facilitate an in-person or remote learning lab where the group explores a case study. I've run this with a group of 4-6 people, but larger groups are possible.

Details

• 45 minutes
• 4-10 people
• In-person
• Use powerpoint to display details
• Use whiteboard to brainstorm with the group

Agreements

• Treat each other with Kindness, Consideration and Respect.
• No phones.

Format

1. Present scenario
2. Split into pairs & explore case.
3. Brainstorm case together.
4. Split into larger groups to practice answering the question again
5. Practice answering the question individually.
6. Retro on what we've learned.

1. Present Scenario

• Show the slide with the scenario.
• Read it aloud.
• Invite questions + clarify.

Example Scenario: The Family Gathering

• You are at a family gathering when someone asks ‘What do you do?’.  
• “I work as a software engineer in the 5G space“, you reply.  
• “That’s sounds cool! What’s 5G?“ 

How do you respond?

2. Split into pairs & explore case

• Split the group into pairs.
• Ask them to explore the question for 5 minutes

3. Brainstorm the case together

• Bring everyone back into the bigger group again.
• Ask each pair what they came up with.
• Write their thoughts on the whiteboard.
• Step back and ask for their thoughts. Further clarify the case and explore different paths.
• Cross out and add thoughts on the whiteboard to explore the case and come up with better information together.

4. Split into larger groups to practice answering the question again

• It's time to re-explore the original case again.
• Split the group into 3-4 people and ask them to re-explore the question using the new information.

5. Practice answering the question individually

• The facilitator goes around the room and asks each person to answer the original case study question.
• Facilitator: "So David, you are the actor in this scenario. How would you answer the question 'What is 5G?'."
• Go around the room and explore the question with each person.

6. Retro

• Ask the group what they have learned today and how they will bring it into their daily conversations.
• Retro on the workshop itself and ask what their favourite part of the workshop was so that you can improve it for the next one.

As lockdowns lifted, many companies have returned to in-person working with the belief that it is overall better for collaboration and delivering immediate value. This may or may not be true, or maybe it is true in some cases and not others, or maybe collaboration and immediate value should not be the only metrics to look at. Whatever the case may be, it strikes me as obvious that there are some serious disadvantages when working remotely. But the disadvantages do not affect everyone in the same way.

I think it comes down to the question "Do you know what you have to do?" In other words, is your task well-defined enough that you can do it by yourself? In many jobs, this is the case. Developing presentations, organising people to talk to each other, updating a client - these are all well-defined tasks.

But what about writing code for a project which we don't understand? Or analyzing a bug where, almost by definition, we don't know what's causing it? Or learning the basics of a new skill that other people take years to master? How can we be expected to do this by ourselves? The answer is: We can't. And if we can't do it by ourselves, that means we need others to help and support us. We get that help by communicating with them.

Lost moments of communication

• Overhearing an ad-hoc conversation between your two teammates.
• Seeing your teammate red-faced and stressed at their desk.
• Talking to someone in-person and noticing their foot shaking as if they are agitated.
• Signalling you want to interrupt someone's monologue to correct them.
• Turning around to your team and asking them for help (ie. Not needing to setup a meeting just to talk to a teammate).
• Hearing other people laugh at a joke.
• Hearing a happy story that someone encountered this morning.
• Seeing the magic of someone else writing great code.
• Having a conversation in a meeting while your colleagues have a separate conversation across the table.

These moments are not possible in a remote environment, and we make many trade-offs for the benefits of working remotely.

Background

Many teams are called 'teams' by name only. From what I can see, this is because we often do not focus on building team-specific skills. In sports, we focus on growing and developing the team because it's obvious that's how games get won. But in the software industry, we seem to think that the rules are different. Time and time again, we see that only groups of people working together on the same problem at the same time can succeed in complex domains.

This workshop gives people a sense of what it means to be a real software team. It introduces the participants to the communication tools they need to solve problems together and learn together. For people who have not had experience programming as a team before, this is always good fun and people come out of the workshop excited to bring these techniques into their day-to-day work. And that's the facilitator's goal - help your participants have fun and give them something tangible to bring back to improve their work.

Facilitator's Prep

Pick an exercise

• For a completely beginner team, I recommend working in online environments to avoid wasting time on misconfigured laptops.
• Examples:
  • hackerrank.com
  • Cyber Dojo

Invite the participants

• Best results are with 4-6 people. Consider splitting up larger groups.
• Sessions should be 90-120 minutes.

During the Session

The Tech

• Screen sharing: Each participant needs to access and hand-off the code they are working on
  • Examples: MS teams
• Timer: Any timer will do.
  • Examples: Mob-programming timer app, Google timer

The Rules

• Any code you want to write must go through the hands of someone else.
• Build on whatever code was written before you - ie. No starting from the beginning.
• Treat everyone with kindness, consideration and respect.

The Terms

• Driver: The person at the keyboard. The driver doesn't think. They just do what they are told to do.
• Navigator: The person who talks to the driver. They are the only one who is allowed to tell the driver what to do.
• Mob: Everyone else. Their thoughts, ideas and suggestions are funneled to the navigator.
• Facilitator: The person who is coaching and involving the whole team. The facilitator does not take part in the problem solving. They should ensure the team is obeying all rules and ask open-ended questions such as "When was the last time we ran the code?".

The Session

1. Someone volunteers to be the first driver.
2. Someone else volunteers to be the first navigator.
3. The driver shares their screen.
4. Everyone reads the problem statement.
5. Start the timer for 5 minutes.
6. The navigator either directs the driver straight away or consults with the mob on what to do.
7. At the end of the 5 minutes, rotate the driver and navigator. The next driver can use the 'control screen' option on the first driver's computer.

Retro

• With 15 minutes until the finish, stop the session and run a retro.

Useful questions:

• What new and useful tools did we use?
• What new thing did you see when we were coding?
• What shortcuts did we see?
• What was fun?
• What did you most enjoy in this session? How can we bring that into your team?
• How did you feel and what caused you to feel it?

Pick an experiment to bring back

• Group similar topics from the retro.
• Talk with the team to select 1 thing and decide on an experiment to bring in over the next week.

Most teams have workshops called 'retros' where they reflect on the previous couple of weeks and decide what to improve going forward. For most teams, the retro is treated as another obligatory meeting dictated to them by the scrum rules. Teams that have no experience in effective retros see these workshops as a waste of time, and why wouldn't they? The teams that do have retros often have them too infrequently, taking a retro once every couple of weeks. As a result, teams find retros are 'too long' or inefficient because they try to do too much. Instead of taking retros more frequently, teams stop doing them or give up in putting in effort.

One sympton of inefficient retros is to run the workshop again and again in the same way and without any variety in the questions the team ask themselves to diagnose and introduce changes. After the team has asked themselves "What was good? / What was bad? / What should we improve?" a few times, everyone gets bored. Here is a list of questions to help your team find different and interesting experiments to run.

Day to day questions

Mini 15 minute retros everyday can help supercharge the team by bringing in tiny improvements each day. It also prevents those horrendous 3 hour long meetings at the end of a sprint where the saved up all their problems and ideas.

• What was good today? How can we turn it up? "Turn up the good" is a concept from Woody Zuill and Kevin Meadows' 'Mob-Programming' book. When working with teams, they asked themselves this question at the end of each day.

• What was the best thing about working together today? This is a good question to see how the team can do more good teamwork together.

• How many hours did each person spend working with someone else? What would happen if we increased this? A team is not a team if the people are not working together. Increasing the amount of time people pair and mob-program together could supercharge the team.

• How many hours did we spend blocked by someone else this week? How can we reduce this? Blockages and work in progress are huge areas of waste for teams. Identifying where major blockages are is extremely valuable to help teams do more of the fun stuff.

• What was our favourite tasks we did in the last 3 months? How can we do more of these tasks?

• What went really poorly today? How can we prevent it in the future?

Post mortem questions

In the event the team encounter a critical problem affecting customers, they will need to run a post-mortem on the event to diagnose and prevent future issues.

• What went wrong?
• What made you nervous?
• How can we prevent this happening again?
• Why did this incident happen?
• What else could go wrong that we got lucky with?
• What's the worst thing that could happen in this situation?

Worst case scenario analysis

What's the worst thing that could happen your team? It will likely happen at some point. Don't be the team that doesn't prepare for worst case scenarios because it is too uncomfortable to think about.

• What's the worst thing that could happen us? How to we mitigate that risk?
• If component X crashes in production, how can we get it back up?
• What's our bus factor for each responsibility and how do we increase bus factors of 1?
• What's the worst thing that we own that could happen and impact our customers?

Best case scenario analysis

Analysing a perfect day in the office can give insights into improvements. This is similar to 'turning up the good'.

• When do you love doing your work?
• What does the perfect day look like for you?

General improvements

• What's one thing you've always wanted to try?
• If we were to fix something permamnently tomorrow what would it be?
• What's something you learned about recently that you would like to introduce to the team?
• What tasks feel stale for the team?
• What's the thing you hate doing? How can we make it less painful?
• What's the thing you love doing? How can we do more of that?
• On a scale of 1-10, how good are we as a team?
• What's the lowest priority thing on our Todo list? What would it take to delete this task from our Todo list?
• Whats the main thing we do or support that we are known for?

Chess rules are simple: Trap your oppenent's king before they trap yours. Of course, there are other rules like how pawns should capture other pieces or how a king should castle. I know these rules and I know them well. My go-to method of procratination is to play a game of chess on lichess.org.

So here's a question: If I know the rules of chess, why can't I beat an experienced chess player?

I know that bishops move diagonally and knights make that weird "L" shape. But if you put me against an experienced chess player, I don't stand a chance. The reason for this seems plainly obvious: Knowing the rules is not enough.

The same applied to all games. While knowing the rules is essential to play the game, they do not inform the tactics and strategies of the game. The rules don't tell me what the best chess openings are or what the best endgame is. They don't explain the traps that happen when I move the queen to this position or the knight to this. They don't tell me the consequences of my move in two, three or four moves time. Knowledge of the rules alone explains none of these things.

How does this apply to the business world?

So we've established: Knowing the rules does not qualify us as a master of the game. Then why not apply the same standard to the professional world?

A Python certificate does not a Python developer make.

A Scrum certificate does not a Scrum Master make.

A Six Sigma certificate does not a Project Manager make.

We should not place blind trust in CVs or certificates that simply say that a person is qualified in subject X.

What signals mastery?

How would we know someone is good at chess? We would play them against someone else who is also good at chess.

The same goes when hiring candidates or evaluating people's expertise. Their CV says have some certificates - great! At least it means they probably have an interest. But we must make sure they can play the game.

My favourite way to evaluate expertise is to talk to the person about problem scenarios in their field. In my opinion, this is how all interviews should be conducted (not multi-day take-home assignments or leetcode exercises). If it's a programming problem, let's talk through it together and come up with a solution on paper first and then write some code. If it's a leadership problem, let's discuss the assumptions, ideas and proposals to solve it.

That's how we check for expertise - we see if they can play the game.

How can I show I'm an expert in something?

At the risk of repeating myself: Show others you can play the game.

Show them that you don't just know the rules but can apply tactics and strategies to real world problems. Write about the times you've played the game. Tell them about the mistakes you've made and what you've learned. Build things to prove that you can build them.

Of course, all of this assumes one important thing: You must know what you're talking about.

While there are shortcuts to achieve expertise quicker (namely focus), nothing replaces putting in the hard work. That doesn't mean you need to spend 2 hours everyday for the next year learning how to play the game (but if you have the time why not!?). However, it does mean that you need to keep chipping away at it. A little bit here, a little bit there - it all adds up. But please, please, don't stop after just learning the rules.

The rules matter.

But playing the game matters most.

Questions for the Team to Answer

Tips for the Team

Questions for the Team Lead to ask

Note: Team lead can refer to Scrum Master, Manager or technical lead.

Tips for the Team Lead

If you want an equation, here's mine: Culture = Behaviours + Expectations + Wisdom

Cultural Behaviours

Pick any group and you will quickly see that each has their own ways of interacting and behaving with each other.

• Country
• County (especially in Ireland!)
• Village
• Local community
• Family
• Company
• Team

Cultural behaviours are unconciously picked up when we integrate into a new group of people. If you have travelled abroad to multiple countries, you know that the 'feeling' between coutries is very different. If you have stayed with another family for a few days, the 'feeling' of that family feels foreign, strange and often uncomfortable. A family member of mine says "Other people's families are always very strange". This is true. Different cultures are just that - different. People expect each other to behave in a certain way and give a strange look when that doesn't happen.

Cultural Expectations

If the first part of culture is its peoples' behaviours, then it follows that the second part is what people expect of you. When you go to France, you greet another person by kissing them on the cheek. You must point with your thumb instead of index finger in Malaysia. When you sit down for a meal with your family, you are expected to say Grace. We call these expectations 'customs'. Expectations keep people in check and produce a sense of belonging, protection and safety - an amazing evolutionary strategy we have developed.

Cultural Wisdom

Thirdly, wisdom plays a huge role in culture. Over time, the culture's behaviours and expectations become instinct to its people. In other words, the culture's people build a body of wisdom which comes naturally to them.

It is common for people who misunderstand a culture to treat it with resentment. But cultures are formed through behaviours that have given its people support to survive and thrive. In other words - cultures form over time because they work for that group of people. This doesn't mean that change should not happen. But we should be careful not to throw out the baby with the bathwater. Some behaviours are good, others are bad, and some are just different.

The body of wisdom that is built up in a culture should be treated as just that - wisdom. Not a list of rules that have come from 'back in the day' that we need to change and get rid of simply because they are old.

So when we talk about culture, remember: Culture = Behaviours + Expectations + Wisdom

What is a Learning Culture?

If Culture = Behaviours + Expectations + Wisdom, then Learning Culture = Learning Behaviours + Learning Expectations + Wisdom about Learning. You need to understand what behaviours will help your colleagues progress their knowledge. This is the primary purpose of L&D. Without knowing how people learn and what their learning needs are, any L&D individual will fail to understand what learning behaviours should be encouraged.

How is a Learning Culture Created?

Cultures are made up of complex people and, as a result, are complex things themselves. In “Toyota Kata”, Mike Rother describes structured, practised behaviours that are the building blocks of a learning culture.

Learning Behaviours

What behaviours do you want from your colleagues when it comes to learning? Narrow in on specific behaviours, right down to the scenario and task level. As you develop and support different scenarios your colleagues experience, they start building a set of behaviours condusive to their learning. Be warned though - you cannot force people to behave in a certain way. You can only encourage things that they want to do. Focus on the individual's strengths and interests to understand how they can enrich your company's learning culture. For example:

• Someone interested in coaching might be able to give workshops to teams.
• A subject matter expert might be interested in mentoring new joiners.
• A new joiner might be able to become owner of a team's documentation and improve it in some way.

List the Learning Behaviours

List down the behaviours you want to see in your organisation.

• I want people to learn everyday.
• I want teams to continuously improve.
• I want managers to enable change.

Each item is a high-level expectation. Get specific. Divide each item into specific scenarios you want to see.

For example:

Behaviour: I want people to learn everyday.

• Scenario: When someone sees something useful, they note it down and bring it to their daily work.
• Scenario: People take online courses in areas that they are interested in at least once a week.
• Scenario: People read books on topics they are interested in.

The more scenarios you can think of, the better.

Next, prioritise your list of scenarios and break them into actions you will take.

Scenario: People read books on topics they are interested in.

• Action: Create a library area in the office with 100 books.
• Action: Enable people to order any book they want to add to the library.
• Action: Have a monthly 'book' day where people share what books they've read and what they have learned.

As you can see, wishing for a learning culture to appear is not good enough - get specific! Otherwise, your colleagues will become disenfranchised with your mission and, worst of all, become apathetic.

Having said this, your goal isn't to encourage every behaviour in every individual. Some encouragement with some individuals is enough. Small wins along the way is the goal.

Learning Expectations

After you've figured out which behaviours to encourage, the next step is to look at expectations. What should your colleagues expect from each other? The lazy answer of "I just want people to be better everyday" isn't good enough.

Step back for a second. What if someone came up to you and said "I want you to be better today". You wouldn't know what to do.

It is easy to say "I expect people to learn", but without accepting the responsibility of providing encouragement and support, then they are empty words. L&D must put their money and time where their mouth is.

What About Hiring?

It is difficult enough to promote culture amongst people who agree with its principles. It is impossible to do it amongst those who don't. In his book 'Principles', Ray Dalio writes how his company, Bridgewater, hire for a specific kind of culture.

Bridgewater's culture values brutal honesty above all else. If you think this results in a nice work environment where everyone is up front with each other, you would be wrong. It results in an environment many people are not cut out for.

Imagine if every proposal was met with everyone in the room responding with "I disagree with you because XYZ". Imagine if every single action was challenged by multiple people in the room.

A look at Glassdoor reviews shows these values coming through as good and bad, depending on who is commenting.

• "Culture is huge here, managers really like to take an interest in people's inherent personalities and tendencies. As someone who likes a demarkation between work and personal life, such a probing culture isn't really conducive for that."
• "It's not for the weak-stomached. If straightforward feedback induces anxiety, this would not be a healthy work environment for you."

Are these 'bad' reviews, or is it more likely that you need suitable personality traits and values to succeed in such an environment? While this may be an extreme case, it illustrates my point. People with values anti-thetical to the culture will not thrive. So you need to be up front with potential employees from the very beginning.

If you are building a Learning Culture, it needs to be screened at the interview stage.

• Do you work better alone or with other people?
• Walk me through a time you improved someone else's job.
• What is the last project you made outside your work (technical or not)?

No interview questions are 100% perfect, but the goal of any interview is to estimate if this person would fit well in your company. If the person does not display curiosity or enjoy sharing information, then they likely won't thrive in a learning culture where these values are the foundations.

The End Result

Now that you have a list of behaviours you want to see, get to work! Over time, encouraging particular behaviours together with screening for good hires will build the culture you envisaged.

Below is the Learning Cluster template I use in my organisation.

A Learning Cluster is a selection of learning assets given to the learner at their moment of need. The biggest benefit for both L&D and the learner is that whether the learner wants to watch a video, read a book or find a quick definition, it is all provided in a single location. With a Learning Cluster, the learner chooses what they want to learn, how they want to learn and when they want to learn.

How do I give the learner what they need when they need it?

L&D's challenge is to understand and answer this question: "What does my learner need to know and how can I help them get there?". Every industry is ever changing, growing, and becoming more complex, so much so that we all need to constantly adapt to keep up. This has resulted in the rise of the L&D discipline.

However, we in L&D are still asking the question "How can I train my colleagues to be better?". This is an outdated question. Today's question is "How can I help my colleagues make better decisions when it counts?". Better decision making underpins every discipline and therefore L&D's mission must enable people to make better decisions.

Now two questions come to mind:

• How can I help my colleagues make better decisions?
• How do I know when they need that help?

I think the answer to both questions is something along the lines of "I don't know what people need or when they need it, but I'll have something ready when they come looking".

The benefit of learning clusters is that we don't need to ask questions like:

• What situation is the learner in?
• How much time do they have?
• Do they want to read a blog post, watch a video or see a live talk?

By putting all options on the table, the learner can decide themselves what they need and when they need it. In the same way that a restaurant offers you a menu of options instead of trying to understand if you're meat or vegetarian, Learning Clusters give you the option of making your own decisions.

How Do Learning Clusters Help the Learner?

Learners want to choose how, when and where to learn. This poses a challenge for L&D: How do we provide everything in a single place?

By giving the learner a cluster of options to choose from, we are more likely to meet their moment of need. It doesn't mean that every learner will look at every assets. That's not the point. By adding a cluster of options to choose from, it is more likely that the learner will use at least one of the options. We're not looking for big wins here. Incremental improvements to our colleagues knowledge is our goal.

Developing Learning Clusters

Use the template at the beginning of this article to create a cluster for any skill you want. You can probably think of a way to upgrade it and make it even more relevant for your organisation. Next, choose a topic you want to address, for example "Email Security".

What do you want to achieve with this Learning Cluster?

• I want to provide a cluster of assets about email security
• So that my colleagues do not send sensitive information or click on dangerous content.

Once your goal is laid out, fill in your cluster. You can use custom content created by your organisation or find free content online. As you get better at collating links and resources, you will develop a list of useful websites to use in future Learning Clusters.

Where did they come from?

Learning clusters are part of a larger framework called the Owens-Kadkia Learning Cluster Design Model (OK-LCD Model) which attempts to bring together and expand on learning models such as ADDIE and SAM.

The authors, Crystal Kadakia and Lisa M.D. Owens, saw poorly executed goals within L&D. Namely, that L&D were focused on a single thing - a deliverable to close the capability gap. The deliverable could be a wide range of options such as an interactive video, classroom training or a manual. But the deliverable was always just one element.

What's the problem with delivering one element for one problem? Learners don't want to be told what to learn, when to learn or how to learn. Learners want to be able to choose how, when, where and what they want learn. L&D therefore need to shift from the "1 problem = 1 deliverable" mindset and move towards a "Learning Cluster" mindset.

One problem should not be met with a single solution. It means we put all our eggs in one basket. Instead, by creating a diverse suite of deliverables, we give the power back to the learner and increase the likelihood that they will find something useful and enjoyable in our deliverables.

For more information on the wider framework, see "Designing for Modern Learning" by Kadakia and Owens.

Source by Alen Pekic on scrum.org.

Scenario

A Development Team, arguing it is self-organising, indicates it no longer needs the Daily Scrum; they collaborate throughout the day and they feel it has become a needless ritual. What should the Scrum Master do?

Answer

Re-iterate the Daily Scrum's Purpose

The Daily Scrum is an opportunity to inspect and adapt while being transparent with the rest of the team. Other collaborations during the day are great, but they do not provide the main object of the Daily Scrum: Create a 24 hour forecast of work to get closer to the Sprint Goal. The Scrum Master should bring forward examples of when the Daily Scrum recently proved useful. Similarly, examples of what could happen if the Daily Scrum was removed could help the Dev Team think about it in a more positive light.

The Root Cause

The Scrum Master must try to understand why the Dev Team find the Daily Scrum a 'needless ritual' - this is the root cause of the whole complaint. The Scrum Master should put the question to his team: "How can we make the Daily Scrum useful?"

A similar situation occurred in my team which was exacerbated during lockdown. The Dev Team felt the Daily Scrum had turned stale where nobody listened to each other. The Daily Scrum had devolved into an individual status update instead of a team collaboration event. In my case, the Dev Team's concern that the Daily Scrum was a 'needless ritual' was completely valid! A morning status meeting does not promote teamwork throughout the day. In the Daily Scrum, the team must forecast the work for the day and discuss how they will get it done.

Since the Dev Team do not find the Daily Scrum useful anymore, the Scrum Master should facilitate a brainstorming session with the team on how to make their Daily Scrum useful. For example, rather than stepping through each person saying "Yesterday I did X, Today I will do Y, No support required", the Scrum Master could suggest the team restructure their Daily Scrum around top priority issues. This could help the Dev Team to pair program on critical items and focus on what is important for the day. This would transform the Daily Scrum to create a plan on "How can we close these critical items as fast as possible?".

Here are some other ideas to help re-structure the Dev Team's Daily Scrum:

• Prioritise tickets by turnover time: The longer the ticket is open, the more priority it has.
• Keep it to 15 minutes (surprisingly many teams do not stick to the 15 minute rule!).
• Establish an 'interrupter' for each Daily Scrum - someone who steps in if a conversation goes on too long and needs to be taken offline.
• #lookForward - Only focus on the plan for the future, not what each person did yesterday.

Source by Alen Pekic on scrum.org.

Scenario

You are a Scrum Master working with a Scrum Team. The Development Team constantly complain that requirements are not clear enough. The Product Owner claims she is too busy to provide extra clarity. What should the Scrum Master do?

Answer

Coach the Dev Team

Since the complaint comes from the development team, the Scrum Master should first work with the dev team to answer the question: "What criteria do we need to commit to each requirement?" The result should be a list of checkboxes, commonly known as a "Definition of Ready".

A Definition of Ready is a useful set of criteria for the team to check against each requirement they discuss. If a requirement satisfies the Definition of Ready, both the Product Owner and the Dev Team agree it is ready to be taken. This further promotes commitment to each product backlog item during the sprint planning.

Coach the Product Owner

There are different solutions for the Scrum Master to suggest to the Product Owner depending on how much time the Product Owner has available.

Firstly, the Scrum Master should remind the Product Owner of the importance of transparency between her and the Dev Team. If this transparency reduces, the team will deliver something that is not valuable to the customer, resulting in wasted sprints and, more importantly, wasted budget. The Product Backlog needs to be transparent to the dev team so that they understand what will bring value to their customers and what they need to focus on for their sprint.

Secondly, if the Dev Team continue to complain about unclear requirements, the Scrum Master can suggest a dedicated weekly sync-up between the Dev Team and the Product Owner. This meeting would serve to discuss top priority product backlog items together with any questions the Dev Team has on sprint backlog items.

Thirdly, if weekly meetings do not work, the Scrum Master should recommend the Dev Team to directly contact the customer. Although the Product Owner acts as the main interface for the customer, it does not prohibit the Dev Team from reaching out directly.

Finally, if none of these actions bring clarification, the Scrum Master can encourage the Dev Team to proceed based on their own assumptions. The Dev Team should also contact the Product Owner via email to state their assumptions and how they will proceed.

Coach the Whole Scrum Team

The Scrum Master should constantly ask questions that challenge the whole team.

• How can we commit to each product backlog increment?
• Does everyone understand these requirements?
• How can we avoid similar confusions in the future?

Asking well-placed question encourages the team to be open and have the courage to speak up when required. A clear product backlog is essential for the team to have focus and commitment towards their product increments.

Continuous Improvement is often an abstract and vague term to describe better ways of working. Within the context of business and technology, Continuous Improvement seeks to enhance every aspect of value in a team's processes and products. By reducing waste, reducing burden, and increasing consistency, teams boost the value they produce towards their stakeholders. It is impossible to remove all waste, burden and inconsistency completely from the team's work, but teams should work to minimize each one incrementally. This incremental change is what we refer to as Continuous Improvement. Let's look at Continuous Improvement and how we can utilize its main driver - the "Retrospective".

Continuous Improvement Lifecycle

As teams deliver value, it is important to regularly reflect and ask the question: "What can we improve next?". During this reflection, the team brainstorms ideas on what experiments they can try out (also known as actions or improvements). These experiments hope to deliver an incremental gain in the team's value. Repeated experiments encourage innovation, risk and courage, each of which are important for a team's progress. This cycle of Retrospect => Experiment => Improve => Value is called Continuous Improvement.

Continuous Improvement in Sport

Let's step back for a minute and look at Continuous Improvement in the world of sport. In 2002, Sir Dave Brailsford joined as head of the British Cycling team. Prior to Sir Dave's leadership, British Cycling had won just one gold medal in almost 80 years. In 2008 Beijing Olympics, Sir Dave led the British track cycling team to 7 out of 10 gold medals! After achieving this staggering result, he turned his focus towards "Team Sky" - Britain's first ever pro cycling team. He led Team Sky to 6 out of the last 9 Tour De France events, an impressive feat to say the least.

How did Sir Dave achieve this? Sir Dave held an MBA and used methods of Continuous Improvement when coaching his teams. He looked for small things to improve in how the team worked together, referring to these improvements as "marginal gains".

"Forget about perfection; focus on progression and compound the improvements." - Sir Dave Brailsford

The team hired a wind tunnel to understand and experiment with aerodynamics. They painted their truck's floor white to detect and reduce dirt on the bikes. They even brought their own mattresses and pillows to each hotel to get a good night's sleep! By regular retrospection, the team encouraged ownership and, eventually, everyone started to come up with their own ideas for improvements which, in the end, led to their huge success. This is the power of Continuous Improvement. "Marginal gains" made frequently in the short term encourages growth and prosperity in the long term.

Continuous Improvement is an Engine

Think of Continuous Improvement as an engine. The purpose of an engine is to drive something forward in a given direction. Continuous Improvement should be the engine that drives your team forward to deliver more and more value each iteration.

Retrospectives are the Fuel

All engines need fuel. Without fuel, the engine slows down and stops. If Continuous Improvement is your team's engine, then the Retrospective (henceforth referred to as the 'Retro') is your team's fuel. Like an engine without fuel, Continuous Improvement without Retros slows down and stops. A car that does not move forward becomes a stagnant, empty shell that is only nice to look at (many people own such cars!). We do not want to be teams that are stagnant, empty shells with nothing to drive us forward. We want to be innovative and come up with creative solutions to our own problems.

Forward progress gives us satisfaction in our jobs and without that sense of progress, we become scattered and burnt out. But to achieve progress and forward motion, we need fuel. We need Retros to provide fuel to our engine.

What is a Retro?

Team Meeting

The Retro is a team meeting where space is created for everyone to learn and brainstorm ideas. It is important that the whole team contributes towards the Retro. A Retro in which only part of the team speaks up is not a good Retro. For example, it is common for the loudest person on the team to speak the most in Retros. Or maybe people do not want to speak up because the most experienced person will argue them down. But the Retro is one of the few places where all members of the team come together as equals. The Retro facilitator should work to ensure all members contribute and have their voice heard.

Regular Schedule

If the Retro is the fuel to your team's engine, then it needs to be topped up frequently. Therefore, Retros should be scheduled on a regular basis. They should be monthly at a minimum, but ideally more often. In between Retros, the team can test their experiment ideas and gather feedback for the next Retro. The Retro should also close out your team's iteration period. For example, if your team works in cycles of two weeks, the Retro should be the last event of the cycle. By taking a Retro at the end of the cycle, it provides the team the opportunity to plan for the next cycle. If your team has no cycle time, then pick one - teams always work best with defined timelines.

Opportunity

Retros provide the opportunity for the team to give feedback about themselves, their processes, and their product. Whether you have been part of the team for a day or a decade, your opinion is equally valid in your team's Retro.

If you are new to the team, this is your opportunity to speak up about the things you find difficult and frustrating. Are you happy with the onboarding process? Are you invited to pair program on tasks? Do you understand your objectives as part of the larger team? As a new team member, it is up to both you and the team to make sure you are integrated and valuable to the people around you. If something is difficult as a new member, then have the courage to speak up and be honest in your team's Retro.

If you have been with your team for a longer period, you likely have valuable insights on the biggest problems you and your team face. Is the team's quality sufficient? Is there enough innovation and experiments happening in the team? Are you excited, bored, or burnt out with your work? With experience comes more expectations, but that does not mean you should expect to be stressed or under pressure all the time. Use the team's Retro to voice your concerns with your teammates. They just might surprise you!

Experiment

"What experiment do we want to run next?"

This is the question the team should work to answer in their Retro. Simply having a meeting called "Team Retro" will not achieve improvements without a solid outcome and plan for what happens afterwards. The real work is done between Retros where the chosen experiments are tried and tested. The Retro allows the team to learn about problems, identify solutions and pick an experiment going forward using methods like the 3 questions: "What went well? What did not go well? What should we improve?"

Think back to the experiments Sir Dave ran with his teams. White paint, mattresses, hand washing. These are not particularly profound ideas. I am sure there were many experiments and ideas Sir Dave's team tried which came to no avail. However, each time they tested something out, whether it succeeded or failed, the team learned something new. There was no single experiment that won gold for the team. Each success built on the last until, eventually, enough 1% marginal gains were made to achieve the gold.

A good Retro experiment will like the British cycling team's experiments - short, actionable, and valuable.

It needs to be short so the team can commit to it on top of their other work. "Pair program on critical tasks" is better than "Re-architect our software to support faster deployment".

It needs to be actionable so the team do not jump through hoops to complete it. "Order our stand-up tasks by priority instead of person" is better than "Suggest a new tool for ticket tracking to the organisation".

And it needs to be valuable so that the team can add it to their ways of working. "Scrum Master to close stand-up after 15 minutes" is more valuable than "Create unit tests for this deprecated piece of code".

Benefits of Retros

Develop Agency

Agency is a psychological term which means 'I can act on my own behalf'. A team with a sense of agency can act independently to control and change their surroundings. By raising their problems in the Retro, the team empowers themselves to come up with their own solutions. They develop ownership over their environment and push for change where change is needed.

Learn the Mood

"How do you feel?" "...Fine, and you?"

This is a common response when you throw the 'f' word at someone (feelings). While we don't like to share our feelings with other people, it can be a valuable piece of feedback for a team to understand each other's mood. In my team, we start off the Retro with a quick word from everyone on their mood in the past few weeks. We have yet to hear the word 'fine'. Usually we hear 'stressed', 'anxious', 'messy' or 'productive', 'fun' and 'exciting'.

Each answer gives a good insight into how the team's mood is. A positive overall answer indicates the team is doing something well and should continue to do so. A negative reaction indicates something needs to change and the retro should then focus on alleviating those negative points going forward.

Brainstorm Ideas

Any good team understands the need to innovate. Teams can only make Continuous Improvements if they have created the environment to brainstorm and innovate. Their Retro facilitates such an environment where ideas, both good and bad, are welcome. Without creative ideas, we cannot innovate. Without innovation, we cannot discover those marginal gains Sir Dave talked about. The Retro provides the space to identify these 1% improvements we can bring to the team. If each Retro facilitates just a 1% improvement to your team, imagine the massive changes that could happen over the course of a year.

What Next?

First things first - setup regular Retros with your team if you are not already doing so. Within each Retro, focus on a particular area the team would like to improve. This could be quality, bugs, meetings, processes, teamwork or anything else the team thinks is a priority. For each Retro, focus on answering the question: "What experiment do we want to run next?" Once the team picks an experiment to focus on, plan it into the next iteration and track whether it succeeds or fails.

Remember, the team's retro does not have to be a complicated or lengthy meeting. However, it does need to be taken regularly to yield those marginal gains and fuel your team's Continuous Improvement.

While this can be effective, there is a better way to run retros and maximise their value. Retros usually do not deliver something tangible that is immediately obvious or valuable and so they can be taken for granted,. They are essential for long term growth but teams often feel that they are a ‘nice-to-have’ meeting.

Without well-run retros, your team cannot hope to improve significantly over time as they are removing the main opportunity to inspect and adapt. A good retro should follow the same rules as a good meeting. Think about all of the meetings you attend which are a waste of time. What do they have in common?

• They have no goal.
• They have no structure.
• They have no start or end time.
• There are too many people.
• They have no output, actions or follow up.

If our retros follow the same bad practices, why should we expect them to be anything but a wasteful meeting?

Below is a template I am developing with teams to run retrospectives. It is largely derived from Derby and Larsen’s expertise in the area, together with some additions I have found helpful for the teams. If you want to deep dive each section of the retro meeting, I suggest to read “Agile Retrospectives: Making Good Teams Great”.

You can copy this template for each retro and refine it over time for your needs.

Template

0. Preparation

Write down the list of actions taken in the previous retro.

Gather the team data to be shown and analysed. For example:

• Burndown chart
• Velocity
• Number of bugs opened
• Number of bugs closed
• Number of stories completed
• Number of stories open at the end of the sprint
• Lines of code touched

Tip: Create a Runbook on how to gather each data point above or even better - automate the whole thing for each sprint with a tool like Jira!

1. Set the stage

Welcome

You are all welcome to this sprint's retrospective. The purpose of this meeting is to look back over the last sprint and gather feedback on what went well and what went poorly.

State the Goal

The goal for this retro is to...

• General goal: Reflect on the previous sprint what went well and what went poorly.
• Refined goal: Improve our teamwork/coding standards/XP practices.

Ask for a Word (Ice breaker)

Ask each person for a quick word. Examples:

• Can each person say what their energy level was this sprint (low/medium/high)?
• Can each person give a sentence on what they hope to gain this retrospective?
• With one word can you describe your mood this sprint?
• With one sentence, describe a high point of this sprint.

Plan

1. Timebox: 90 minutes
2. Review the last retros' actions and outcomes. Discuss further if necessary.
3. Show the data.
4. What was Good/Bad/Ideas/Thank yous.
5. Actions for next sprint.
6. Retro of retro.

2. Show the Data

Last Retro’s Actions

List the 1 or 2 actions from the last retro.

• Did we accomplish these actions?
• Why did we not accomplish them?
• Should we permanently add these actions to our ways of working?

Metrics

You should have metrics prepared prior to the retro to analyze with the team. For example:

• Burndown chart
• Velocity
• Number of bugs opened
• Number of bugs closed
• Number of stories completed
• Number of stories open at the end of the sprint
• Lines of code touched

Coach your team to look for insights with questions such as:

• What problems do we see from this chart?
• Are we happy with the number of bugs closed?
• I see this bug count doubled from previous sprints. Do we need to do something about that?
• Our velocity has halved in the last 2 sprints - do we think this is a problem?

Events/Insights

Ask the team to write down their thoughts for this sprint.

If the retro is in-person, use sticky notes on a whiteboard.

If the retro is remote, use a virtual retro board such as agile.coffee

Use a list of questions to get the team to think about different things. Examples:

• What was good/bad?
• Big announcements?
• Important decisions?
• New team members?
• Celebrations?
• High points?
• Low points?
• When were you excited to come to work?
• When did you dread coming to work?

Tip: Divide the whiteboard into columns such a Good/Bad/Ideas and place the sticky notes in the appropriate column.

Comments

Ask your team to quickly comment on any observations:

• Do we see any patterns on these sticky notes?
• Are there any surprises that we didn’t expect?

3. Create Actions/Improvements/Ideas

Go through each item and ask questions:

• Why did this happen?
• What can we learn from this?
• What action can we take to keep this going/prevent it in the future?

4. Decide What to Do Next

• Ask the team to vote on their top 2 actions they would like to try next sprint.
• Create tasks or notes in the backlog for these top 1 or 2 actions.
• Assign each action to a person where possible.

5. Close the Retro

• Take a screenshot / photo / save the output of the retro somewhere.
• Thank you for joining and putting in the effort to this retro and sprint.

Retro of retro

Before closing the meeting, ask your team:

• If you could change one thing in our retros, what would it be?

If anything big comes up, setup another call to discuss how to improve your retros.

6. Post-retro Activities

• Put the most popular 1 or 2 actions into a backlog item for next sprint.
• Record the retro outcome in a document or take a photo/screenshot. You will need to look back at the actions when you prepare for the next sprint’s retro.
• Note down any suggestions from the retro of retros.

Day 0 - Ticket created

Our team owned the failed component in question - let's call it SweetShop. SweetShop creates and manages Sweets. Historically, SweetShop has been a problem. Our most difficult tickets have been related to SweetShop in some way. Suffice to say, my team does not have a good relationship with SweetShop. In the ticket description we saw "SweetShop logs say OutOfMemory after we create 2300 Sweets".

Day 1 - First responders

We picked up the bug the next morning. After a quick review of the ticket, we logged into the system to see the SweetShop logs. We confirmed what the QA team reported in the ticket: OutOfMemoryError: Java heap space. We suggested to QA to increase heap memory for SweetShop. That was our first possible solution.

Possible Solutions

1. Increase heap memory.

Principles Learned

• Respond to critical tickets quickly with the smallest possible solution.

Day 2 - Gather info

The next morning, the QA added more details to the ticket. The test was to verify that SweetShop can create and store 3000 Sweets. In hindsight, this ticket was poorly written from the outset. There were no details of what the QA team were trying to accomplish, only some errors they found in the logs. More importantly, there was no information on the test itself. A few simple data points always help the support team to get started quickly.

• What type of test is it? eg. Load, stability.
• What are you trying to accomplish in this test? eg. Create 3000 Sweets in 3 hours, Create as many Sweets as possible, Create infinite Sweets.
• Has this test passed historically or is this a new test?
• Who is observing the problem?

We logged onto the system and ran some of the common linux commands: top, iostat -x 1, netstat and so forth. Increasing the heap capacity did not remedy the failures. We even tried to install Zabbix to do some monitoring because on of our developers used it before. There was no thought give to what we were trying to achieve. Why would there be? We had no idea what to do and wanted the ticket closed ASAP. In Netflix they call this the Street Light Anti-Method. In other words, start with the problem first, then use the right tools to figure out what is wrong. Don't start with the tools you know simply because you know them.

Possible Solutions

1. Increase heap memory.

Principles Learned

• Do not investigate any ticket until sufficient details are added.
• Ask basic questions to understand the problem.
• Once you have asked your questions, then find the tools.

Day 3 - Bring in the troops

On Day 3, our ticket appeared on the management's morning stand up. When this happens, the ticket goes straight to the top of our priority list and our mission becomes simple: Get the ticket solved. So we shifted gears. We requested to see the system logs for SweetShop and the scripts they used to create their Sweets. The QA team kindly responded with a link to a Jenkins job which supposedly ran the scripts. In other words, find the scripts yourself - lovely! To top it off, we were cc'd to a management thread with our ticket name as the title.

Possible Solutions

1. Increase heap memory.

Principles Learned

• Do not accept vague information. Make sure you get exactly what you asked for.
• If a manager wants something ASAP (as was this case when we were cc'd), don't expect anything less from their side. Escalate quickly if you don't get what you want.

Day 4 - It's Getting Hot

I should say that this was our first major performance issue. We were learning on the job and struggling to think of ideas. This meant we had no monitoring tools setup or any idea of what tools we could use. All we had was the failed system and the QA script that said Sweet123 creation successful or Sweet999 creation failed. Nevertheless, we weren't lying down. We rejected the Jenkins job link that we received the previous evening and demanded the scripts be provided. Once received, two of our teams began their investigation.

In parallel, we looked into SweetShop performance tuning. We found a troubleshooting page that said the min and max heap size should be set to the same value. We had the min heap = 2GB and max heap = 4GB. This indicated that the garbage collector could be insufficient at higher levels of load. Heap size was back on the table as a solution! We set the min heap and max heap to 4GB each. Even if it didn't fix the situation, it was recommended by the SweetShop support and so should go in.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.

Principles Learned

• Look for shortcuts to a solution. Close off as many paths as possible in parallel.

Day 5 - A Blind Scramble

At this stage we had two devs looking into the test scripts and an idea to tune the heap. Being a pessimistic team, we weren't ready to relax. We needed more information on how the system was behaving at load. We had nothing setup to monitor our systems - big mistake! This was our first performance bug. We hadn't prepared for anything like this before. We checked with other teams - they had nothing either! Fortunately, linux comes with a few handy tools. We ran the performance tests on 3 different systems. On two of those systems, we increased the heap size to see if it would help. On the other system, we created a quick python script to create batches of 10 Sweets with a delay between batches. While one of the tests was running, someone spotted that the garbage collector was slowing down significantly. The beginning of the test looked like:

tail -f /path/to/gc.log
Total time for which application threads were stopped: 0.0001006 seconds

The 500th Sweet creation looked like:

tail -f /path/to/gc.log
Total time for which application threads were stopped: 3.0001342 seconds

A few hours later, the 1500th Sweet creation looked like:

tail -f /path/to/gc.log
Total time for which application threads were stopped: 24.1947332 seconds

Then, the system started to fail. Since the heap was increased and the garbage collector was still having trouble, we decided to increase the time between batches to see what was the issue.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.

Principles Learned

• Performance testing must be accompanied by the appropriate debug tools.

Day 6 & 7 Getting Somewhere

Some good news came the following morning. With the delay of 2.5 seconds, the performance tests managed to create 2600 Sweets. Ok - we were onto something. We looked through the scripts once more to see if anything else could cause unnecessary load on the system. Wait..what's this? CONCURRENCY=20 How did we miss that the first time? That puts a huge load on the SweetShop service! We weren't even sure if it could officially handle that level of load.

We updated the test scripts and ran them again with the following parameters:

• Batch delay = 4 seconds.
• Concurrency = 10.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.

Principles Learned

• Do not blindly trust tests written by other people against your service. They may be testing something that is not supported.

Day 8 One Step Forward, Two Steps Back

The next morning we got a new result - only 1750 Sweets were created. This was frustrating! Again, we saw OutOfMemoryError: Java heap space in the logs. So none of our changes had resolved the issue. The day was spent trawling through all the logs again to see was there anything we missed. In the meantime, the performance team kicked off another run for some extra feedback.

Possible Solution

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.

Day 9 Blame Someone Else

We weren't making much progress for such a high priority ticket. We decided to take the failed system with 1750 Sweets and push it to see how far it would go. We created our own python script to create a single Sweet one at a time in sequence. We removed the batches and the time delays and connected a java monitor to the system. The result: 62 Sweets were created in 16 hours. The java monitor showed the heap was maxed out constantly at 4GB. We suspected something was happening with the createSweet method so we opened a ticket on the development team who handled some of this code. I believe this violated another one of Netflix's anti-methods - Blame Someone Else:

• Find a system you are not responsible for. In this case the java functionality - Done.
• Hypothesize that the issue is with that component - Done.
• Redirect the issue to the responsible team - Done.
• When proven wrong, go to 1 - Todo.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.

The development team observed that the system significantly slowed down after the 1000th Sweet. The CPU also maxed out a 100% - embarrassingly, we didn't spot this. The development team decided it wasn't their code and pushed it off as an internal bug to SweetShop, completing our cycle of the Blame Someone Else Anti-Method:

• Find a system you are not responsible for - Done.
• Hypothesize that the issue is with that component - Done.
• Redirect the issue to the responsible team - Done.
• When proven wrong, go to 1 - Done.

Let's update our solution list.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.

Now we had two tickets. The first was ours to figure out how to successfully create 3000 sweets. The second was the one we raised on the development team to figure out why the createSweet is inefficient at high load. The second ticket in turn was connected to a SweetShop support ticket - what a mess! Remember the manager's standup? Our ticket was front and center each morning.

Principles Learned

• Don't "Blame Someone Else". Instead pull in people to help without assigning blame to them.

Day 15 A Slow Death...Then

Days went by with no progress. Each morning, our team gave a status update like "We are trying x, y and z but no success yet". I suppose this violates the Drunk Man Anti-Method:

• Try things at random until the problem goes away. The development team attempted some improvements recommended by SweetShop support, but nothing improved the situation.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.

A week later, we found a way forward. The SweetShop support finally admitted "We don't support this number of Sweets in a system. We would expect issues with the garbage collection. Please upgrade to the latest version to resolve this." In other words, there is a garbage collection bug in SweetShop that cannot be patched. A major upgrade would take months of work, so that was not an option since our quarterly release was about 6 weeks away. But this was good news for our team. At least we now knew there was a limitation where a permanent fix was not possible. Next task: figure out a way to clear the heap and free up some memory.

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop.

After some experimenting, we found that the SweetShop garbage collection could be completely cleared via a service restart. So we were left with a dilemna. Restarting services as part of a load test is not a real solution. In fact, it's a really...really bad solution. But we were in a tight situation and had no other alternative. To propose it to management, we needed a plan to completely resolve it. After pushing the SweetShop support team, they recommended upgrading our product from v2 to v6. SweetShop v6 had improved garbage collection capabilities. We added it to our solution plan:

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 2.5 4 seconds between batches.
   • Reduce concurrency to 10.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop to v6 in Q1.

As I said, a major upgrade would take months of work. Our quarterly release was only a few weeks away. So what could we do right now? What quick and dirty solutions are on the table? We know that a restart clears the garbage collector. So we restarted SweetShop after every 500th Sweet created. We took the QA performance scripts and added in a service restart after every 500 Sweets. On the first run, we were able to run the full script up to 3000 Sweets - fantastic!!!

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 4 seconds between batches.
   • Reduce concurrency to 10.
   • Restart SweetShop after every 500 Sweets.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop to v6.

However, upon a review of the logs, we saw that 200 out of 3000 Sweets failed to create. Still, it was good progress. We reran the test again with smaller batch sizes - every 400 Sweets. We also added in some error handling to retry if a createSweet failed. This time, we successfully created all 3000 Sweets. We updated our proposal:

Possible Solutions

1. Increase heap memory.
2. Tune heap memory.
3. Optimise the test scripts.
   • Add delay of 4 seconds between batches.
   • Reduce concurrency to 10.
   • Restart SweetShop after every 500 400 Sweets.
   • If creation fails, retry.
4. Get the development team to fix it.
5. Get the SweetShop support team to fix it.
6. Upgrade SweetShop to v6.

The proposal was agreed along with a lengthy explanation to our release notes why this use case had a serious limitation.

Principles Learned

• Don't discount quick and dirty solutions. Every solution is on the table in a critical scenario.

The ticket was closed...until...

Day 45 Dec 6

"We see this issue again in system 6!" Considering the quaterly release was just 2 weeks away, this was not a pleasant message to see in the afternoon. Ok, let's review the situation.

• The proposal was actioned 30 days ago.
• Multiple performance tests were run since the proposal.
• No further issues were seen until now.
• No changes had been made to SweetShop.

Something didn't add up. We asked the QA engineer if they ran the exact same test as last month. They confirmed "Of course". "Of course" - two words which I now know translate to "maybe". Fortunately, we learned our lesson from Day 7: Do not blindly trust tests written by other people. We re-checked the parameters in the scripts:

• Batch size = 400 => OK
• Restart SweetShop between batches => OK
• Concurrency = 20 => not OK!!!

But "of course", the exact same test was run! I firmly responded to rerun the test with concurrency = 10. After this, the test passed and we never returned to it again.

Principles Learned

• I repeat: Do not trust tests written by other people. They may be testing something that is not supported!

Conclusion

While these couple of days were quite stressful, it resulted in a rewarding experience. We were able to attack the problem head on and rule out wrong solutions quickly. In the following sprints, we fed a lot of performance and monitoring improvements into our backlog. We didn't want to get stuck like that again. The principles we picked up along the way have been instrumental in how we handled subsequent performance tickets. Now, when a ticket comes in from the QA Performance team on SweetShop, we have a set of tools ready to analyze the problem and judge quickly what needs to be done to solve it. Here is a list of all the principles we learned along the way.

Principles Learned

• Respond to critical tickets quickly with the smallest possible solution.
• Do not investigate any ticket until sufficient details are added.
• Ask basic questions to understand the problem.
• Once you have asked your questions, then find the tools.
• Do not accept vague information. Make sure you get exactly what you asked for.
• If a manager wants something ASAP (as was this case when we were cc'd), don't expect anything less from their side. Escalate quickly if you don't get what you want.
• Look for shortcuts to a solution. Close off as many paths as possible in parallel.
• Performance testing must be accompanied by the appropriate debug tools.
• Do not blindly trust tests written by other people against your service. They may be testing something that is not supported.
• Don't "Blame Someone Else". Instead pull in people to help without assigning blame to them.
• Don't discount quick and dirty solutions. Every solution is on the table in a critical scenario.

Teams require constant maintenance, updates and improvements. Otherwise, they become stagnant and inefficient. To become hyper-efficient, each team must analyse how they work. One key metric is to understand how much time your team wastes on repetitive tasks. While software developers are excellent at automating away their own problems, they often forget to focus on the team's problems.

If you analyse your team's time and value output, you will see many areas to improve. Obvious areas are poorly written bugs, too many meetings, poor communication with colleagues and so forth. But there is a category of work that is often overlooked - repetitive team tasks. Repetitive team tasks is any task that the team needs to perform on a regular basis.

Ask your team:

• What tasks do we do on a regular basis? e.g. Gather logs from a customer system.
• What topics do we constantly explain? e.g. How to install MyComponent on a Linux server.
• What issues regularly crop up? e.g. A bug with MyComponent which needs a workaround.
• What support do we regularly give? e.g. Recovering MyComponent in the event of a failure.

These examples are straightforward for the team member who knows what to do. However, team members are often out of office or unavailable to help. When this happens, something as simple as resolving a code conflict is difficult for someone who does not have the know how. This results in wasted cognitive expense as your team attempts to solve a problem that was previously solved. Your team's valuable time for new features is replaced with old, repetitive work.

We need to reduce this waste.

What are Runbooks?

Runbooks document your team's knowledge for the future. A runbook is a step-by-step recipe to solve a problem. With runbooks, your team can rely less on each other's availability. Instead, when a problem arises, they can search through a database of runbooks for a solution.

Runbooks contain clear and concise steps. They can be "How-To" guides, tutorials or any step-by-step instructions. Runbooks should not have walls of text. This is better left to blog posts and articles. Instead, sentences should be brief and bulleted.

What are the benefits of runbooks?

Most people don't write. It's not surprising - we're not paid to write. But writing down solutions to problems has a host of benefits. When teams document their solutions, they achieve hyper-efficiency quickly. With a runbook, the writer must deep dive into their problem. They must write in such a way that other people can read it quickly and efficiently.

After 6 months of documenting solutions, my team has written 114 runbooks. The top runbook has been viewed 125 times by our team of only 8 people. This top runbook is an extensive 'How-To' document which explains gotchas and workarounds when installing a dev environment. I estimate that each viewing saves about 30 mins. Therefore, this one runbook has saved the team 60 hours. If we account for another 113 runbooks, our team has easily saved 100s of hours.

What kind of runbooks can I create?

Create runbooks to solve specific problems. Not everything should be put into a runbook. Long topics do not facilitate quick and easy searching. Long form writing is also difficult to give quick information to the reader. So, what should go into a runbook?

Bug Runbooks

An in-depth analysis to my team's most difficult bugs has proved useful on multiple occasions. When I create a Bug Runbook, I ask myself: Who will need this in the future? Very often, a new bug is opened against our team where someone will say 'Hey I've seen this one before. Anyone remember how we solved it?'. When this happens, I need quick information about the previous bug.

Without runbooks, I need to go through the team's history of Jira tickets and search for keywords until I find it. Even when I find the old bug, if the assignee closed it in a hasty manner then a lot of information will be missing. Root causes are nowhere to be found. I am lucky if the assignee has even linked their code fix. On the other hand, let's say the bug ticket has a link to a runbook with the following information:

Key phrases

• RuntimeError in /path/to/logs.

Problem Statement

• User's login page failed to load.

Steps to Diagnose

• Viewed logs x and y.
• Checked the VM resources using df -h.
• Discovered the VM directory /var was full due to large logs.

Root Cause

• Customer set their logs to MESSAGE for some investigation then forgot to change back to INFO.

Steps to Fix

• Remove the log directory /path/to/logs to bring the VM back up.

Steps to Prevent

• Create an alarm to detect when the VM resources become too low.

Other things to note

• This happened to a system under heavy consumer load over the course of 2 weeks.

I now have a detailed root cause to a similar ticket. Instead of starting my investigation with no information, I have a possible root cause to quickly check if it solves my new ticket.

Runbooks with this analysis has saved us many hours of repetitive troubleshooting. I admit that most of our bug runbooks never get opened again after creation. But every so often we get a valuable analysis that is useful again and again. We think of runbooks as a method of automating our effort. Rather than spend a limited supply of brainpower repeatedly, we record it once with the hope that it will be useful in the future.

How-To Runbook

How-To Runbooks allow repetitive tasks to be semi-automated. A How-To Runbook should contain all details to figure out a particular scenario. Use these runbooks to setup dev environments, close tickets, create improvements, install software etc. Once a How-To Runbook is created, anyone in your team can use it whenever they please. Otherwise, you would have to ask your teammate to help when they already explained it to someone else. With a How-To Runbook, distractions are minimized as you streamline the team's knowledge into a shared database.

Our template for How-To Runbooks is very straightforward:

Scenario

• Explain when your team need to use this runbook.

Steps

1. Do x.
2. Do y.
3. Do z.

Process Runbook

Teams constantly shift. They get new members, people leave, they go on holidays and so forth. In many cases, the team processes are only known in depth by one or two people. If they take a sick day or leave the company, does someone know how to take over? For example, if your scrum master takes a day off unexpectedly, do you know how to plan the sprint with the dev team and product owner? Of if a new member joins the team, can they quickly learn about the team's processes?

Take a moment to think about what your team does on a regular basis. Describe that process in a Process Runbook.

For example, my team has a runbook for 'Story Workflow'.

Scenario

• A developer wants to take a story or task from the backlog to complete.

Steps

• Open your Jira ticket.
• Read the description.
• Write down anything you do not understand.
• Read the acceptance criteria.
  • Is it clear what you need to do?
  • If not, talk with your scrum master, product owner or a team member.
• What testing do you need? Comment this in the Jira ticket.
• What documentation do you need to update? Comment this in the Jira ticket.
• What tasks or steps will it take to complete this story? Comment this in the Jira ticket.
• After completing each step, add a comment to your ticket with your progress.
  • You should have at least one update per day.
• If you get stuck, request help from your team.
• Once all tasks are completed, show your team what you have accomplished. This is called a demo.
• To commit your code, follow this Runbook => Link.
• Ensure all code is reviewed by a team member and merged before closing your story.

When a new developer needs to work on a story, you can provide a workflow that is easy to follow. The developer can work by themselves (to a certain extent) without being hand-held through the process. Without a runbook for this, someone must assist the new developer to ensure that all steps are completed. This increases distractions and eats into the team's total time capacity.

Troubleshooting Runbook

Troubleshooting is a key part of any team. It can also be a frustrating part of the job, particularly for newer members. In general, teams learn new information ad hoc. Ad hoc learning results in different team members picking up different levels of information. This naturally leads to an inequality of expertise across the team. If there is a large inequality of expertise across the team, then a high dependency gets placed on one or two team members. Then, what happens when that person is absent? Or worse, what happens when that person is hit by a bus?

A couple of times a year, my team takes a meeting to ask, 'What is our bus factor?'. In this meeting, the goal is to identify each area of expertise we own and assign it a bus factor. Thereafter, we work to increase our bus factor on anything below 3. The quickest way to do this is for each expert to document their knowledge in a runbook.

Troubleshooting Runbooks are extremely beneficial to document methods of solving bugs or support issues. It will prevent trouble in your team when one or two are missing and a high priority bug comes in. Here is a short troubleshooting runbook we have in our team.

Scenario

• Developer wants to enable debug mode on MyComponent and check the debug logs.

Steps

• Open the MyComponent GUI => https://example.com/mycomponent
• Click on the 'Server' tab.
• Click on the 'Debugging' tab.
• Change the dropdown from 'Error' to 'Message'.
• Save.
• Login to your Linux terminal for your system.
• cd /path/to/debug
• You will see the debug logs are populated with new information.

Here is an example of a longer Troubleshooting Runbook.

Scenario

Developer wants to check the health of MyComponent.

Step 1. Setup SSH password-less connection.

• ssh-keygen
• ...

Step 2. Verify the following endpoints are reachable

• ping https://example.com/mycomponent/isAlive
• ...

Step 3. Run diagnostic script

• cd /path/to/diag
• ./diagnostics.py

Step 4. ...

• And so forth

With a couple of these runbooks, you can reduce stress in the team if someone is out for the day. Troubleshooting Runbooks also work as a proxy for the expert themselves. By providing some basic information in a Troubleshooting Runbook, the work can be passed to a more junior member, freeing up capacity for the more senior member. This benefits everyone in the team.

How can I get started with my team?

To get started, adopt your team's current method of documentation. Try not to introduce a new tool that your team is not used to. For example, my team uses Confluence to document everything. When we introduced our Runbook system, we created each Runbook in a Confluence page under the same heading 'Team Runbooks'. Now, our Confluence space looks something like this:

• Team Runbooks
  • Bug Runbook: JIRA-1234 MyComponent crashed under load
  • Bug Runbook: JIRA-9999 MyOtherComponent failed to upgrade
  • Troubleshooting Runbook: MyComponent
  • Process Runbook: How to create a story
  • etc.

It is important you use the easiest method for your team. Software engineers hate documentation because most practices do not encourage quick and easy changes. For your team to be enthuasiastic, pick a method of documentation that is simplest for everyone. Then, once your team gets started and sees that it saves them time and effort, they will be eager to continue. Eventually, the phrase 'Can you create a runbook for that?' will be a regular ask in your team.

It is valuable to develop a large toolset. Using tools is in our very nature. Tools help us accomplish tasks and solve problems. In the job market, nobody cares about your theoretical knowledge. No interviewer will ask you to write a paper on theoretical computer systems. Every interviewer wants to know one thing and one thing only - can you get the job done?

Stay Flexible in the Job Market

Without tools, we would not be able to accomplish most of our everyday tasks. The more tools you can use, the more problems you can solve. And the more problems you can solve, the more jobs you can do. A large toolset means you are flexible enough to apply yourself to many different jobs. If you're flexible, you can apply to other jobs should something disastrous happen such as a layoff or health issue. This gives you a lot of stability and peace of mind.

Get Good at Lots of Tools

Tools solve problems. So, what problems do you have in your job or in your personal life? Start from what you need. Do you struggle to track your money? Learn excel to record your spending and calculate your budgets. Is there something broken in your house? Learn how to use a hammer and nail to fix it. Do people often get frustrated with you at work? Learn to communicate yourself better to them. There is always a tool to solve your problem. Therefore, start with your problems and see what tools can solve them. There is a dual reward to using a tool to solve your problem. The first is that you figured out and solved your own problem - that's a great feeling. The second is that you now have a new tool in your kit for the rest of your life. When a similar problem appears in the future, you will be able to use the same tool to solve it. A life of tool learning builds on itself to become something extremely valuable. As you encounter similar problems again and again, you can use tools you know to solve them quickly.

If thinking is the art of linking ideas together, then writing is the canvas upon which thoughts are painted. Like any work of art, without a canvas the painting only exists inside the artist's head. Even then, you could debate if it exists at all. In the same way, to engage in deep thought without writing is not only difficult, but impossible. Few people practice deep thinking. You are likely not one of them. Instead of thinking deeply about a topic, you experience quick thoughts in rapid succession which you forget as soon as you are distracted.

A friend once told me he concluded that God is a ridiculous concept after thinking about it for a mere 15 minutes when he was 16 years old. Let's think about this statement for a minute. Imagine that you play the piano. Think of the vast works of piano music. Think of the accomplishments people have achieved in both making and playing the piano. Think of the mastery that is required for piano composition. Now imagine someone comes along and attempts to play the piano for the first time. After failing to play for 15 minutes, they conclude the piano is a bad instrument. That is what my friend did.

Writing requires you to think for much longer than 15 minutes. When you write your thoughts, you do not have the luxury of cowardly casting off difficult opinions as if they were nothing. It is easy to discount opinions you do not understand - this is called a strawman. When you have an unpalatable thought, you can ignore it. For example, think about what it is like to lose your house, become homeless and develop crippling depression. It is difficult to consider for more than a few seconds. When you write about a displeasing idea, you do not get the luxury of changing to more comfortable thoughts. Whether you like it or not, any important idea is uncomfortable to think about. Consider the last political cause you were passionate about. Are you competent enough to argue for the opposition's side? Do you fully understand why people would vote the other way? I doubt you could. I doubt it because it is a strenuous task which takes a lot of mental effort that even sophisticated minds struggle to accomplish.

When you write, you think deeply. And when you think deeply, you discover the great void that is the understanding of yourself and those around you.

Grow Up and Be Informed

Let's face it: you're ignorant. And I'm not pointing fingers - I'm right there with you! You don't really know what to think about most things. You don't know your politics; you have a dismal view of history and you don't even know what higher purpose you believe in. This is where I'm supposed to say, "But it's ok - everyone is the same!" Yes - everyone is the same. But no, it's not ok. It's not ok that you don't know what to think about your local politics. It's unjustifiable that you have no idea of the atrocities of history. And it's inexcusable you don't know what higher purpose you believe in. So, get to work and start to write and think - nobody else will do it for you!

To start, write down what you know on an interesting topic. Do you believe in God? Write down why. Who will you vote for in the next election? Write down why. When you write your thoughts, you identify gaps quickly in your knowledge and can work to fill in those gaps. As you fill the gaps, you become an informed, mature person, capable of attacking lies and defending the values you hold dear. Of course, the alternative is to stay an adult infant. It is a blissful hell many people prefer.

Improve Your Communication

Think of a bad communicator you know. Maybe this is a work colleague or family member. What makes them a bad communicator? They do not speak well. They have poorly constructed sentences. They trip over their words. They are unsure of themselves. They are easily persuaded by an objection. They leave out crucial information. This person has certainly never written down their thoughts. This is because a single thought does not constitute an idea. We cannot think more than a single thought in a given moment. So, when you speak about your thoughts without preparation, you quickly realise it is impossible to get past one or two sentences. When you write, you write as many thoughts as necessary. Once your thoughts are written down, you can join them together in a larger, coherent idea. This enables you to weed out bad ideas. It also helps to highlight interesting or useful ideas. In this way, you develop strong ideas and arguments to defend them.

Let's return to the bad communicator. If they wrote about their ideas and opinions, they would be able to speak more coherently. They would not ramble in tangents. They would be confident. They would be able to defend their ideas against mere objections. Most importantly, they would be able to convince others that their idea is a good one. Effective communication awaits the novice writer.

Increase Your Success

If you can communicate good ideas effectively, people will listen to you and provide you opportunities. The quickest route to any kind of success is convincing people your idea is a good one. If you can write, think, and argue, you are unstoppable. Think about your career for a moment. Your dream job will require an interview process. An interview requires you to make an effective case for your skills. What happens if you do not think deeply about yourself prior to an interview? You ramble about things you don't understand. You don't form coherent arguments to show off your skills. You get distracted by the sound of your own voice. The best way to do well in an interview is to control the topics. You can only control topics if you have formulated and thought them out prior to the interview. The only way to formulate them effective is to write them down.

What if you want to ask for a raise? This requires you to make the case how a raise will benefit both you and the employer. The better your case, the larger a raise you will achieve. In recruitment, a quick way to secure employees who are good at their job is to bump those that write to the top of the hiring list. This isn't to say that the best person for the job is always a writer. I mean that the candidates who write have desirable traits of knowledge, critical thinking, and discipline. These are always ideal characteristics in a job applicant and the recruiter will recognise such. As you can see, the writer has a much better chance to defend and promote him or herself in opportunistic scenarios.

Be Disciplined Instead of Weak

I hated writing in school - it was difficult and, worst of all, I believed it was pointless. I continued to think this into my adult life. As an university student, I even opted into modules simply because I wouldn't have to write an essay. It is an attitude I regret, but one that was instilled in my school years when I was taught to hate writing.

I'm going to guess that you had a similar experience. Writing is mentally draining, onerous, and time consuming. Why then do writers do what they do? There must be something of value to be achieved. Apart from the pleasure of deep thought, writing requires you to carve out time. It requires you to organise your thoughts and ideas. It requires you to communicate each thought in words, phrases, and paragraphs. It requires you to commit to doing a task which you dislike and to fend off pleasures such as Netflix or YouTube. Even hanging up the clothes is preferable to writing! When you write, you encourage discipline. It should go without saying what any of us could accomplish with a little more discipline.

Perfect Your Ideas.

There are two ways your writing can subject your ideas to criticism. Firstly, you are your best critic. A good writer will look for gaps in their ideas. Secondly, if you publish a blog or newspaper article, your ideas are subjected to your viewers' scrutiny. The reactions of your viewers will help you to harmonize and perfect your ideas.

You may ask why you should subject yourself to criticism? You can enrich other people's lives by passing on your wisdom about a passionate topic. One of life's many pleasures is the passing on of information to those hungry to learn it. Furthermore, a unique idea grants you respect and authority over that idea.

If you lead a software team, then a significant part of your tasks will involve some sort of bug fixing or support for other teams. In particular, if your team works on a product used by a lot of customers, you can expect to sped 10% or more of your team's time fixing bugs from your customers.

When it comes to bug fixing, your customers expect a high standard from your team, so you should expect the same from them. As part of your team lead duties, you need to look for opportunities to reduce the team's work as much as possible. In my case, I discovered that the team spent longer trying to understand a bug's description than actually fixing it.

A poorly written bug means your team is getting distracted trying to figure out what the bug means instead of fixing it. Distraction leads to context switching leads to frustration leads to slower completion of work. And there are few things more distracting than a badly written bug.

Rather than trying to fix the bug, a lot of time is wasted trying to understand the bug's context and the steps leading up to the incident. In the end, your team practically writes the bad bug themselves!

This was the case for the product I worked on a few years ago. Although the product was relatively mature, there was very little structure around the processes used to make the product better.

A quick search through the bugs history showed poorly written one-liner bugs marked as closed with no explanation or code fix attached. Clearly, the developers were conversing directly with the stakeholders via email and not attaching the information afterwards.

When my team joined the product, the most frustrating part of our days was solving bug tickets which had no useful information attached. Furthermore, we had no method of prioritising our bugs against our current list of tasks - the loudest person won the priority.

After 2 months of this and identifying it as a major pain point in our retros, we decided to fix our bug process.

The Bug Template

Our bug template was revolutionary to our workflow. First of all, by filling in a template, the bug author was required to think about their problem.

What did I do leading up to this?
How could this have happened?

Occasionally, the bug author even figured out the solution by themselves while filling in the template.

Secondly, the bug ticket required some effort to create. A good rule we discovered was if you make it easy for someone to do something, they will do it. In this case, if you make it easy to create bad bugs, then bad bugs will get created.

By putting a list of questions to answer in the template, the author is less inclined to raise trivial questions since it would be quicker to figure it out themselves. Most importantly, you won't be left with some 'critical' bugs that just have a one-liner description.

Bug Logging Template
 
1  OVERVIEW
------------------------------------------------------------
1.1. Technical problem description
------------------------------------------------------------
Give an overview of your problem.

------------------------------------------------------------
1.2. Product impact
------------------------------------------------------------
What part of the product/project/system is this impacting?


------------------------------------------------------------
1.3. Conditions
------------------------------------------------------------
Are there any unique parameters or conditions you think are relevant? 

 
2   AFTER ANALYSIS
------------------------------------------------------------
2.1. Software version
------------------------------------------------------------
  What version of software did you find this in?
 
------------------------------------------------------------
2.2. Steps to Reproduce Fault (**Mandatory**)
------------------------------------------------------------
Please give exact steps on house we can reproduce this issue.
Give specific commands if necessary.
Attach screenshots if necessary.
 
 
------------------------------------------------------------
2.3. Logs
------------------------------------------------------------
Attach relevant log files

 
------------------------------------------------------------
2.4. Frequency of fault
------------------------------------------------------------
When / how often does this occur?

 
------------------------------------------------------------
2.5. Expected result
------------------------------------------------------------
What do you expect should happen?

------------------------------------------------------------
2.6. Actual result
------------------------------------------------------------
What actually happened instead?
 
3   REACTION
------------------------------------------------------------
3.1. System restore
------------------------------------------------------------
Did you take any steps to restore the system?

 
 
------------------------------------------------------------
3.2. Temporary fix / Workaround
------------------------------------------------------------
Did you find a solution or workaround?

Whenever you see a badly written bug, attach the following to the comments section:

"Hi Sam, We need more information to begin working on this quickly. Please fill out this template with relevant details." Then paste in the above template.

Prioritise Your Bugs

As the team lead, each day you should work with your team to identify the highest priority work. If critical bugs are coming in, you may need to down-prioritise other tasks.

I have a general rule I use to decide what to prioritise:

"If it hurts, put it first."

If the ticket is a big customer or is likely to cause your team embarrassment, then get it closed out asap. It is important to keep the pressure off your team as much as possible, so getting painful bugs closed quickly can give them the head space they need.

Furthermore, there is little point in having your team work on edge case bugs that were accidentally found in-house when there are customers shouting for a fix on another bug.

Argue Against the Bug

Before you assign any bug to your team, make sure it is something suitable for your team to work on. Don't confuse a 'loud' bug with a high priority bug. Very often, there are stakeholders that create tickets and need them worked on immediately. Always question the validity of their priority.

Firstly, you don't want to be the 'pushover team' that will hop on tickets when someone shouts loud enough. It is very beneficial to your team if you can disagree against tickets with the hope of either delaying their priority (especially if your have a large backlog) or get it moved to a more relevant team.

To argue against the bug, ask a few simple questions:

• Is this bug for your team?
• Is there enough info for someone to begin working on it?
• What level of expertise is required here (senior / junior)?

By asking some basic questions, your team gets more context to the ticket and can empathise with the ticket author. If the ticket does not already have your template, make sure you attach it and ask the author to fill it out.

Emails are not Bugs!

As the team lead, I am often pulled into an email chain with stakeholders such as QA or customer support teams with questions such as:

• "David - Can you get someone to have a look at these logs?"
• "David - Can we secure someone from your team to look at this?"
• "David - It is critical that we fix this bug by Monday. Who is available to work over the weekend?"

Do not take requests like this. My response is always the same:

• "I'm sure we can help. Please raise a ticket with all relevant details so that we can track this."

Without a ticket, your team don't know where to attach their information or ask more questions. Moreover, if you revisit the bug in the future, without a ticket there is nothing for you to reference.

The complexity is compounded the more teams you add to the mix. Most of the time, it is like asking a bunch of toddlers to paint a masterpiece and then getting a different bunch of toddlers to give an analysis of the artwork.

First of all, the Throwers likely don't care too much if the Catchers get it wrong. Even worse, if the Throwers are losing their jobs, as is often the case, then there is a certain level of resentment towards the Catchers.

Secondly, if you manage the project, you have to note down all the tasks, dependencies, edge cases and expertise you can think of and try to extract as much information as possible from the Throwers for each item. This includes code, product architecture, business cases, documentation, bugs, ad hoc expertise, testing...the list goes on. Even if you get the maximum amount of information from the Throwers, it doesn't really matter unless the Catchers absorb the information.

This is the position I was in a few years ago, where a large product involving 10 teams was transferred to my teams. The product came from a different part of the world in a different timezone. I was a product owner at the time.

Here are some lessons I have learned and mistakes we made that might help you if you are in a similar position. The good news is, we eventually got there and the project is now thriving, but it wasn't easy.

We didn't follow all of these suggestions, but I wish we did. We made a lot of mistakes and cost ourselves a lot of weekends and failures.

The rules to transfer a project are as follows:

• 20/80 Theory/Practice Split.
• Define team goals quickly.
• Get a backlog in place.
• Take ownership of the product.
• Brainstorm improvements.
• Keep an expert available for questions.
• Don't take on too much work.

20/80 - Theory/Practice

It is important to understand the ratio between learning something theoretically and learning something practically. In a software project, theory will only go so far.

There is a difference between thinking you understand something and being able to apply it in a practical situation. The same goes for your teams. Very often, your teams will find that theory does not apply to the practical application.

The Throwers are often tempted to make a bunch of slides and online videos detailing how they interpret the system and how they picture the software working. The problem here is while theory is nice to have as a background, it is of zero use if the Catchers do not understand how to apply it. For this reason, I suggest to spend about 1-2 hours max each day in knowledge-sharing sessions. Anything longer and your Catchers will get tired and zone out. The rest of the day should be spent on technical exercises such as writing code, debugging, writing documentation and so forth.

Let's be crystal clear on this. If your teams learn something theoretical and don't immediately put it into practice, then it has been a waste of time. In this early stage of the project, it is critical to value your teams' time as much as possible. Just because they sit at a computer and listen to someone speak does not mean their time is well-utilized.

Define Team Goals

The danger of any kind of team-based learning is that the team are left by themselves to 'transfer knowledge'. From the beginning, goals must be defined. The danger of not having any goals is that the knowledge is endlessly abstracted and taught as if the software it applies to works perfectly.

The goals should be broken down starting at a high level.

• What use cases do you want this team to understand?
• What set of tasks do they need to be able to do on a technical level?
• What questions to you want them to be able to answer?

As you break down the goals further and further, it will become clear where the gaps are. Fill in the gaps with more goals and keep going until you run out of ideas.

Once the goals have been defined, discuss them with the team and get their feedback - they may have a better idea on what they need to learn.

Backlog, Backlog, Backlog

Once the high level goals have been defined and you have discussed them with the Catchers, it's time to get the team focused. This is where the backlog of tasks comes in.

The Catchers will want to break down the high level goals so that they can identify their knowledge gaps and raise questions quickly with the Throwers. The onus for learning the project is not on the managers of the project, it is on the team. The team will be the ones developing features, solving bugs and answering questions. They need to hone their skills going forward, and that comes from the backlog.

It is tempting not to create a backlog until the project has been transferred and the teams feel 'ready' to start developing features. This is a mistake. The team need to create velocity and work as a team on the project from the beginning. The team lead or scrum master should keep a focus on the backlog so that the team can have small, manageable goals each sprint and start moving towards an ownership of the project.

Take ownership of the project

High performing teams always have ownership of a product or a subarea of that product. It is important for your team to feel they have ownership over the product as quickly as possible. This will make them feel responsible for the product and give them purpose in their daily work.

Teams take ownership by carving out responsibilities for the product.
When defining the team goals and backlog, group work into categories. Once the work is somewhat categorized, it is a good idea to assign a category of work to a single team if possible. This way, the team will get that 'feeling' they have an area of responsibility.

I have seen teams that struggle to secure a place of responsibility in the product. This decreases morale and you will hear it turn up as an issue at the retrospectives. Things like "We don't know our what we are responsible for" or "What is our team vision?" repeatedly get said. This is normal to hear at the start of transferring the product, but you should move to rectify it quickly.

Think about this when you assign the team features and backlog. If you assign a team tasks that are not related to each other, it will confuse them as to what the long term goals are and what they should concentrate on owning. By assigning tasks that are in a similar category, the team can deepen their knowledge in a particular area.

Sometimes you can directly assign an area of responsibility to a team. Here are some examples of use cases a team could be easily assigned.

• Ensure our product installs successfully.
• Develop all future features related to login.
• Develop pipelines to automatically test the product each night.

Once an area of responsibility has been established, the team can make themselves experts for their responsibility. Having at least one area of expertise (most teams have multiple) gives the team a sense of ownership over the product and purpose. This helps to gel together as a team.

Brainstorm Improvements

No software is perfect. Your teams will realise this straight away, while some more outspoken persons will comment exclusively on the quality of the software they are receiving. Hopefully, it's not as bad as everyone says!

A fun way of learning about the product is to brainstorm improvements for the difficulties your teams encounter. Very often, the Catchers find improvements that have been discussed by the Throwers. The Throwers can give the Catchers quick feedback on their ideas and whether or not it is worthwhile to improve.

Since the Catchers are a brand new team to the product, they will also find improvements to difficult problems that nobody has touched before. In particular, if the project has been under a lot of pressure for deadlines, then there will be a lot of technical debt and rushed code. The Catchers should take notes as they go through the project and keep a backlog of improvement ideas they can return to in the near future.

If capacity is available, the Catchers can even begin to work on some of these improvements. Making the product better is always a bonus, even if the improvements are small.

Fix bugs

In my opinion, this is the quickest way to learn the new product. Code is always best learned by solving practical problems. As the team work together through the problem, they will encounter pieces of code that will not make sense to them. They can record these difficulties and bring them up with the Throwers.

Once the team are aware of their responsibilities, they should research the most relevant bugs in their responsible area. Imagine having a document of problems and solutions you could search through to find answers to your questions. This is what a bug backlog does.

As an exercise, the Catchers could take some sample bugs from historic tickets and work them out themselves. If they get stuck, the answer is (or should be) in the ticket.

Keep an expert available for questions

This is crucial to a smooth transfer. As part of any project transfer, there must be a gradual period of transfer. During this period of transfer, the teams do what we have gone through above. At any point, the Catchers could have questions and ideas that need feedback from someone who understands the software. This means that the project experts should be kept on hand for questions and support.

Ideally, an expert should be kept on as long as possible. As the catchers take ownership of the product, they will find that there will always be unknowns. This is ok - it's part of transferring a product, so don't worry.

Your team needs to develop a baseline knowledge so that they have the tools to figure out the rest of the unknowns. Until this baseline knowledge is achieved, it is good to have someone close by.

Don't take on too much

A danger of transferring tasks to your team is that the team takes on too much work. You don't want to set yourselves up to fail. Ensure that whatever you take on is manageable. If you don't know, then don't agree!

My team were in charge of a particular area during the product transfer. We were given a large responsibility to make sure a particular part of the application stays functional each release.

As it turns out, this part of the product never worked properly in the first place. We didn't have the environments available to troubleshoot and our feedback loop for any single line of code was about 1 day. In the end, we failed our responsibility and the product couldn't be released that same quarter.

So be careful what you take on - don't let management force work that is not manageable onto your teams. The Catchers are new to this - it will take time to get settled so don't rush into it!

If this wasn't enough of a challenge, team leaders need to handle difficult members of their team. In my opinion, this is the most challenging part of the job. A team member who acts in a way that is destructive to their team them means your team suffers. In the medium to long term, if the team keeps suffering, then you have ultimately failed as the team lead.

Fortunately, there are methods and techniques to manage such people. However, it is not a simple or pleasant task. Effectively managing difficult people comes with knowledge and practice. Expect to make a few mistakes along the way. Keep the goal clear in your mind - to develop a high performing team. If you reflect on it, then you will make better judgements when it comes to difficult scenarios in your team.

Below are some of the scenarios I have come across and how I think they should be dealt with.

Proud Seniors

Every team has at least one or more seniors on the team. Let's call him Rob. Rob's role is to lead the team in a technical manner and make intelligent and informed decisions for the team while coaching less experienced members. Above all, Rob sets a standard for the team and makes sure the standard is upheld.

As Uncle Ben said, 'With great power, comes great responsibility'. When a leader within the team abuses their position, or does not know how to deal effectively with others, then it can damage other members of the team.

I have often seen Rob act inappropriately towards his team. Sometimes Rob is loud and outspoken and happy to talk over the more junior members of the team. Rob's opinions are often the only ones heard, while he snaps or condescends other opinions. This can be a natural response -  Rob feels like he has the best opinion because he is most experienced. As a result, any challenge is personal.

In a high performing team, each individual must be comfortable to speak out and voice their opinions without judgement. Even juniors who have little experience often give valuable insight into the simple things that the rest of the team have become accustomed to. You need to work to allow Rob's experience to come through in decision making, while making sure everyone on the team is comfortable voicing their opinions.

Resolution

Remember - your goal is to develop a high performing team. In the above scenario the relationship between Rob and the rest of the team is broken. So the question is, how do we repair and maintain that relationship?

In my experience, having Rob work closely with everyone else on the team is the quickest way to mend the relationships. Rather than assigning tasks to Rob and have him work by himself, assign the task to a more junior member and get Rob to oversee it. In this way, Rob will be forced to work on his communication and develop an understanding with the rest of the team.

Over time relationships grow stronger and the more junior team members voice their opinions more often since they are now more comfortable speaking with Rob. Even if Rob's attitude does not soften, at the very least everyone will know his personality well enough to be comfortable challenging it.

Too many egos spoil the broth

Working on a team with one Rob is challenging. A team with multiple Robs can be nearly impossible to handle at times. I have not worked directly on such a team, but I have experienced it by proxy in my managerial days when I had meetings with individual teams.

The most common place egos clash is in the beginning, when the team is being formed. The four team stages of team formation are commonly known as "Forming, Storming, Norming, Performing". (ref https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development ). When a team begins to form, people aren't really sure what position they have in the 'hierarchy' of the team. They're not sure what kind of personalities surround them or each other's backgrounds.

Once the team have been 'formed', in other words, once they recognise who will be on their team going forward, then they enter the 'storming' phase. This is the phase where team members challenge each other and voice their opinions. This is also the phase that is most painful for the team lead.

As the team try to familiarise themselves with the other team members, they spark and argue with ideas other team members put forward. This is amplified further in job sectors with a high competition - software for example. Each individual on the team wants to be correct and will stand by their views no matter what.

Resolution

Don't worry! This is a natural part of the team's journey and it will pass.

Once your team gets to know each other, egos will settle down and your team will enter the 'norming' phase where they get comfortable with each other and begin working as a team towards the common goal.

In the meantime, it is an opportunity for you to practice conflict resolution. Ever wonder what it would be like to be a politician? Here's your chance!

If you find that the team are still not settling in with each other, then it might be time to bring in some team practices in order to make decisions and resolve their arguing. You need to discuss this directly with the team (at a retro is a good time) and brainstorm some ways to achieve decisions.

Some ideas for achieving resolutions is to take a team vote, refer to an external expert (if one exists), lay out the pros and cons of the arguments, or refer to the technical lead within the team.

Unproductive Members

In any industry and on any team, there are some people who are highly productive and driven, and others who are the polar opposite. I once discovered someone who, hired as a software developer, had merged about 5 commits in the few years they worked in that company. In total, their code contribution amounted to a maximum of 100 lines of code. Let's call this person Mike.

The Mikes of the world are lazy, unproductive and always have an excuse why their tasks are not completed. Believe it or not, Mike could be the most dangerous and destructive person on your team. All your other team members look at Mike and see the lack of focus and output coming from him. When a difficult job comes, they wonder why they should be bothered to do a good job if Mike is getting away with doing nothing.

Furthermore, Mike brings down the team moral. He is taking up a space which could be filled by a worthwhile and valuable team member. A brand new junior just out of college is far more valuable than Mike. At least a junior is willing to work their way up the ladder and assimilate into the team. Mike has no such goals.

Resolution

How do we deal with someone like Mike? Believe it or not, Mike's problem may not be his lack of knowledge - it is his lack of accountability. Mike has gotten into the habit of working the minimal amount and discovered that by working poorly and making excuses, he can reduce his work load and take it easy.

So the question is - how to increase Mike's accountability? It's quite simple - don't let Mike work by himself!

Remember how Mike made just 5 commits at his company over a couple of years? What do you think the scrum master did? He continued to assign small tasks to Mike and leave him by himself without anyone working him. Mike had no accountability to his team, so he didn't hold himself accountable. To this day, Mike is known for doing the smallest amount of work, and nobody wants to work with him.

As team lead, you can fix this surprisingly quickly. Team Mike up with one of the more productive members (Vicky) who can guide Mike and hold him accountable. Vicky can support Mike in working on his tasks in a 'pair-programming' manner. This will prevent Mike from skipping off for a few hours or getting distracted easily.

For each of Mike's tasks, ensure that he is not working by himself - always pair him with someone else. You might think that this is a waste of Vicky's time. In the short term, this may be true. But in the long term, Mike will develop a discipline and become more productive by himself. He will gradually gain back the trust of the team and hold himself to the same accountability as the rest of the team. Over the long term, the team will benefit greatly from having the extra productive team member.

Side note: There is an argument to be made that nobody in the team should work by themselves, but that's for a different post.

Just..not...interested

In any team, there are jobs that nobody wants to do. Documentation, bugs, support, admin, testing...the list goes on. As the team lead, it should be one of your focuses to provide each team member with a balanced workload according to their skill set.

Notice how I didn't say that everyone should have an equal workload - that is a bad tactic for a high performing team. As a quick example, juniors learn quickest by getting involved in some of the boring work (testing, documentation). Whereas seniors are kept interested by removing this work from them as much as possible.

Resolution

Each person on the team needs work that is challenging according to their expertise. If one of your team says they are bored of their work, ask them politely what they find boring or tedious. Then work on speeding up the completion of that work and get them onto something they would rather do.

Look back over their previous tasks. Have they been assigned work on numerous occasions that does not challenge them? Can this type of work be shared or shifted to a more junior member? Make a note that their work needs to be more varied in the future.

Unprofessional Team Member

I find this the worst problem to have on the team. It is one thing to be unproductive or difficult to talk to, but acting unprofessionally is the most obvious and painful characteristic someone can have. Let's call our unprofessional team member John.

'Unprofessional' is a catch-all category. There are many ways John can be unprofessional. Snarky, tardy, insulting, offensive, rude..the list goes on.

John is difficult to have at meetings, especially with people external to the team. He says things on a whim without thinking about them and often insults or speaks out of turn. Sometimes, he is downright insulting.

Resolution

Since you are the team lead, it is difficult (and unadvised) for you to single out John and request that he acts more professionally. If John feels insulted, you have done a disservice to your team and damaged a valuable relationship with one of your team members.

The best thing to do is bite your tongue for now, and have a chat with the manager in charge of personnel. This could be a HR manager or more often a line manager. Frame your conversation as a 'concern' rather than a complaint. "I think John could improve his attitude in meetings by doing x".

The danger in dealing with an unprofessional team member yourself is that it could backfire on you and John could complain about you, or you could lose your cool and become unprofessional yourself.

In my case, I have a sharp temper (which regularly gets tested), so when I hear a statement that is completely out of line, I bit my tongue and either ignore it, or if it is interfering with the team's work and progress, make a note and discuss with my line manager at our monthly catchup meeting.

The worst thing I could do in these situations is to snap back. Although I may be in the right and the other person in the wrong, it is too dangerous that I say something damaging which could affect the team as a whole.

These are some good practices that encourage teams to be open and increase the free flow of information.

Retro on the Last Day

Have retros as close as possible to the end of your sprint / team cycle. It is very easy to leave the retro until the start of the next sprint, but this leads to a couple of problems.

Firstly, your team forgets easily. After a couple of days, if you ask your team their problems for the last 3 weeks excluding the previous week, they won't remember anything. The team needs to have a fresh mind. That means having the retro as soon as your sprint is over, preferably on the same day it finishes. In my case, we take the latter half of Friday evening to relax together and go through the feedback from the previous three weeks.

Secondly, actions needs to be brought into the upcoming sprint. If your planning happens on the first day of your sprint, and you have the retro a day or 2 later, you can't address the problems on time and account for them in the sprint planning.

Make it fun

If the team don't enjoy getting together and talking, then they will not enjoy the retro. Make a game of it as much as possible.

Write feedback on colorful stickies. Bring in some biscuits or cake and have the retro over some coffee. Take a break from your usual office space and go out for lunch together.

Keep records organised

It is critical to connect each retro to the previous one. If your retro does not refer to previous retros to show progress, then the previous retro is effectively lost.

At the beginning of each retro, go through the actions from the previous retro. This develops value in the retro, because now your team feels that progress is being made.

If an item keeps coming up at every retro, address it ASAP. In my last retro, I realised that a problem (albeit small) was mentioned 5 retros in a row! That was a signal to me that it had to be prioritised.

Prioritise actions for the upcoming sprint

This is the most valuable part of your retro. Once the problems have been stated and solutions or improvements identified, prioritise them and execute on them. This could be on a technical level (test cases missing) or on an interpersonal level (manager X is interfering in the team).

Pick out the top two or three actions your team think are needed as a priority. Create tasks from these actions and bring them into the upcoming planning session to make sure they get completed.

Put the tasks front and center - don't let them get lost on a virtual document where nobody can see it. You could create physical stickies on a notice board above your team space or put them on your virtual board that you share at your morning standup.

Remember, without making an effort to improve the team's problems, the retro is of no benefit.

Don't leave problems until the retro

As the team lead, take note of the problems during the sprint. Don't let the team get into the habit of saying "It's fine for now - we'll discuss it at the retro". It is tempting to get lazy or to delay fixing problems. By the time the retro comes, they will have forgotten their pain.

Get the team to practice bringing up issues as they arise. You can discuss them further in the retro, but the right moment to discuss is now, not later.

Case Study

The following is an example of how my team performs our retrospective.

Frequency: Every 3rd Friday
Attendees: Whole team, sometimes the product owner in the background.
Preparation: Create a digital document with the following categories:

• Previous retro.
  • Fill in with the actions.
• The Good
• The Bad
• General Improvements
• Top 3 actions
• Thank yous

Schedule

Previous Actions

Briefly go through the previous retro's actions.
Were the most important actions completed? If not, why?

Example

• [John] Raise a ticket with operations to fix our test environment. DONE.

The Good

Take 5 mins for each person to write down what they enjoyed or what they achieved since the last retro. Categorize the items and pick out the common themes. This is where your team pats themselves on the back for the good work they have done.

Example

• Great communication despite working from home. [TEAM]
• Quick response to messages online from the team. [TEAM]
• Less than 5 bugs for the whole sprint. [BUGS]

The Bad

Categorize and discuss the bad things that have happened since your last retro. Make sure you attach a solution or improvement to each bad item.

Example

• Frequent missing of morning standup meetings.
  • Improvement: Move morning standup ahead by 15 mins to avoid the clash with the other meeting.
• Poor ticket writing from our QA team.
  • Improvement: Create a template for the QA team to fill out every time they write a ticket.

General Improvements

What general improvements would the team like to discuss?

Example

• A test case is missing in our test suite. We should add it before we get stung with a bug ticket.
• The morning standups are going over the 15 mins mark - set a timer to cut off the standup at 15 mins.

Top 3 actions

What are the top 3 things from 'The Bad' and 'General Improvements' we should address in the next sprint?

Thank yous (Optional)

This can be a nice way of finishing off the retro. It is surprising how powerful saying thank you to someone can be. They will be more inclined to help you in the future. Is there anyone we should thank that helped us out?

The good news is, there are many scenarios where you can reduce or remove the need for your team in their downtime. First, you need to understand why you team is being called for weekend work. Let's go through a few reasons and how we might prevent them from happening.

Reasons For Weekend Work

Site Outages

A Class A, highest priority ticket has come in on Friday evening as everyone is preparing to leave - a customer's site has crashed. Your team must drop everything (including their social plans) to get online and come up with a solution.

After working all night Friday and half of Saturday, your team puts in a fix and calls it a day. But they are not happy - their weekend with their family and friends has been cancelled, and they wonder if the job is worth these weekend calls.

Prevent Site Outages

After the issue has been resolved, take a whiteboard or pen and paper and answer these questions.

• What did the user experience? For example, did they receive an alarm, get a 500 response error, etc.?
• Why did the site go down?
• Did something like this happen before?
• Who was involved / what expertise was required?
• How can we prevent this from happening ever again?

Once you have these answered, put a plan in place to mitigate this issue happening ever again. Sometimes, it can be as simple as adding a new test case. Other times it may be more complicated and involve setting up new test environments. Look at the cost/reward of fixing it going forward and make a decision.

Late Release Work

The release deadline fast approaches. There is only a few days left until the software is released. Everything is late, and your team are under pressure to deliver.

One of the tasks your team was working on is blocked because the environment was down the past two days. Now the environment is up, but management has requested the task be worked on over the weekend and completed by Monday morning.

Prevent Late Release Work

All teams understand the pressure of having features that are late and in danger of not making the deadline.
To prevent late delivery of features, here are a list of DON'Ts you can apply.

• Don't underestimate the work. Always take your final estimate and add an extra 20% onto it.
• Don't plan optimistically. Assume that things will go wrong, other teams will be late, code will break. In Ireland, there is a phrase "It'll be grand", meaning that everything will work itself out. It won't be grand. Nothing will work itself out. Plan accordingly.
• Don't promise delivery dates that are not feasible. Pressure from management may tempt you to do this. Do not give in. Have data to backup your claims.
• Don't promise delivery dates without doing your homework and gathering as much data as possible. List out as many tasks as possible and estimate each of them. What are your risks? How could your risks affect the delivery date? Are the risks low, medium or high?
• Don't hide problems from your manager during the release. Is a task going to be late? Tell your manager asap and show what you are doing to mitigate it.

An experienced team lead will have this list off by heart without even realising it. Have you got more Don'ts you have learned the hard way? Comment them below.

Late Sprint Work

This depends on your team. There are teams that are not strict on their sprint commitments, and there are other teams which require themselves to work weekends if the work is not ready to deliver.

Prevent Late Sprint Work

Late sprint work usually comes down to poor sprint planning in the first place.

• Did your sprint planning cover this task sufficiently?
• Why did the team underestimate this task in their planning?
• What can you take from this going forward to ensure future similar tasks are estimated more accurately?

Effective sprint planning is difficult, but is worth it to get the team in the habit of delivering their committed work.

Supporting Other Teams

If you are leading a high performing team, then more than likely you will have at least one or more persons who act as experts or specialists in a particular area. This is great for your team...most of the time.

A downside of being an expert is you get called up for consultation on things you were not even involved in. You could be called into an escalation because another team is behind in their commitments. I have often seen specialists called into very tricky situations like performance test failures, where an application is failing at scale and nobody knows why. Scenarios like this are dangerous for experts, because it could bleed your evening and weekends dry.

Prevent Supporting Other Teams

The title here seems unprofessional. Experts are there to act as experts, right?

This may be true, but the fact is that even experts don't like getting called on a Friday evening or Saturday morning and asked to go online. As the team lead, it is your job to protect your team as much as possible in their downtime, so that they can focus more effectively during working hours.

There is a host of reasons your team expert could be called into work unexpectedly. Work with your team to brainstorm how to reduce the need for being called to unplanned work. Here are some suggestions.

• Train a member from the other team in some debugging techniques for the particular area of expertise.
• Document troubleshooting procedures for various scenarios. Share this document with the organisation.
• If a call comes in, brainstorm some possible solutions for the caller to explore. There may not be a need for you to be online. Give enough information that they can proceed with troubleshooting.

As the team lead, your goal is to keep everyone happy as much as possible. Can you prevent the team from being called in the first place by preparing in advance during working hours? Discuss the above with the experts in your team and get a plan together to protect their weekends.

Dealing With Necessary Weekend Work

Sometimes weekend work is absolutely necessary - there is no way around it. That bug isn't fixing itself and the release date isn't moving, so your team is left with no choice.

Now your job as team lead is to reduce the team's pain as much as possible. Here are some suggestions for reducing this pain.

• Instead of John working Saturday and Sunday, can John work Saturday and Jess work Sunday?
• Challenge the work that is requested. Can some part of it can be investigated on Monday instead of now?
• Develop a rota for the next 4-8 weekends so that your team can plan in advance that they might need to be online. This will also prevent last minute requests to your team members and ruining their weekend plans.
• Is there a support team that could take some of the requested work? In my case, I discovered a 'secret' team that were setup specifically to support internal stakeholder escalations, yet my team had been supporting these cases for the past few months. Nowadays, any time an internal stakeholder asks my team directly for support, I forward their email to the dedicated support team. They're happy, I'm happy, and my team are none the wiser that I have protected their evening and weekend.
• Work smart, not hard. Most likely, your team do not need to be online 24/7. If so, propose time slots that your team will be online to check emails and answer requests. For example, when my team are asked to be online over the weekend 'just in case' something goes wrong, I insist that we give a list of times where we will be online and contactable. In general, the time slots are 10-11am and 3-4pm. Outside of these times, my team can relax and go about their day.

If all else fails and someone has to be online to support a problem, make sure they are not working alone. Any work is painful when it is done alone, and weekend work it is 10 times worse. It may be you that needs to make the sacrifice and go online to brainstorm ideas and support in the troubleshooting. They will be secretly grateful for your company, and won't feel the weight of the world on their shoulders.

• Subliminally Standoffish - Don't be difficult to approach with problems.
• Micro-manager - Don't be a tyrant on your team.
• The Libertarian - Don't give your team unlimited freedom.
• Defender of the Poor - Don't defend your team from every criticism.
• Team Grouch - Don't complain.

Subliminally Standoffish

What is it?

A standoffish person is someone who is difficult to approach with a problem. If you, as a team lead, are disagreeable to your team members coming with their problems, then it will cost you in the long run.

Why it's bad.

Problems left unsolved will bite you and your team. Leaving something on the long finger will cost time, effort, money and sometimes even weekends.

A backlog of problems that are not getting resolved and that you are not interested in listening to will ultimately make the team unhappy. To have a team lead who is unapproachable is the same, sometimes worse, as not having any team lead at all.

How to avoid.

Listen to your team, both as a group and individually. If you hear someone complain about the same thing again and again, sit with them to discuss a solution.

If someone raises a problem that needs some thought at your standup, ask them to stay for 5 mins after the standup is finished. Discuss possible solutions with them.

As the team lead, the responsibility is on you to have at least a plan to fix the problem. If a new recruit is struggling with their work, pair them up with another team member who can coach them through the problem.

Sometimes, you may need to step up to the mark and lead the solution yourself. The team respects you - that respect should be commanded and used in high priority scenarios.

For example, a few ago a critical bug came into our team from a performance test. After a few hours of the team going through different scenarios, it was clear that some direction and leadership was needed.

I helped the team split up the possible solutions, and assigned each solution to 2 or 3 team members. I then stayed with the solution most likely to give an outcome. In this way, we covered more ground and found a solution much quicker than if I had left the team to their own devices.

Examples and signs.

How many problems have your team reported to you recently? If the answer is none, then either you have a perfect team (which doesn't exist), or they are not willing to raise their problems with you. Maybe they feel you don't care enough about solving their problems.

If the team are requesting support often, and asking your opinion, then you know you are on the right track.

Tricky part

If you have a history of being standoffish or snappy, it will take time for your team to trust you again. Take it one day at a time - say specifically that you want to hear more of their problems. Encourage expressing problems at retros and stand-ups in particular - this is where the team are ready to help out each other.

Micro-manager

What is it?

Control - lots of it, all of the time. Control over individuals tasks, control over bugs, control over work hours...

A micro-manager will ask for more than frequent updates and pick at anything that they think is incorrect or unproductive. They will call for unnecessary updates to make sure every detail reported is on track.

Why it's bad.

A common misconception is that micromanaging is always bad. It's not. Sometimes it is absolutely necessary. A poor worker who is untrustworthy needs to be micromanaged. Anybody who cannot abide by a professional working structure needs a low level of management.

Having said that, the majority of your team will not have this problem (if they do, you're in for a rough time). When someone feels micromanaged, they feel not trusted to do their work. As the team lead, if you micromanager your team, it indicates you do not trust them to get their work done.

I once witnessed a team lead chase down a colleague who took regular coffee breaks. She then proceeded to scold him in the hall. This behaviour will  not lead to a good working environment.

How to avoid.

If someone is not pulling their weight, bring it up in a team context. If Patrick is not acting professionally, ask the team - "What can we do to help out Patrick here? Alex - can you join him this morning to try and help progress with his story? Patrick - can you update the team on your progress at the end of the day?"

In this way, you are not singling out Patrick, so he does not feel intimidated. But you are letting him know that the team sees a problem with how he is progressing.

Examples and signs.

You are constantly correcting and asking information from the the same individual again and again, more so than any other team member. A team member is getting frustrated at giving you so many updates and being told how to work.

Tricky part.

Micro-managing can be necessary. You need to balance between effective updates in a team setting while giving the freedom to work effectively.

The Libertarian

What is it?

The right to do whatever you want, maximum freedom and autonomy, little to no updates on progress at standups, and no structure on the team as a whole.

While the libertarian philosophy is ideal when talking about government and how one should live their life, it is not a good idea to allow your team absolute freedom in how they work.

Why it's bad.

Effective teams require structure and rules. You must help the team enforce those rules upon themselves. Remember, they are team rules, not yours. You are not a tyrant. A team without structure will perform poorly and get easily distracted.

How to avoid.

Encourage the rules within the team. Encourage effective updates in the standups. Ask questions and critique assumptions to encourage people to speak out.

Example and signs.

I met an old colleague of mine after he moved jobs into another software developer role at a bank. I asked him how things were going. He said it was fantastic.

His team didn't have to turn up to work by any set time. They could have their standup remotely from home and come in later on if they wanted. They didn't practice any of those 'nasty' scrum processes. Instead, they worked in an individual Kanban fashion and could take and leave tasks as they wanted. Needless to say, he was on the hunt for another job within 6 months, and the same bank made headlines for some data breach.

The above is an extreme case of 'anything goes' and on a macro scale. When it comes to your team, if you see tasks slipping, team members being absent from team meetings or complaints coming in from different team members about other team members then it might be time to revisit the rules within the team.

Tricky part.

A good team needs freedom to move. Your job is to help enforce the rules that provide that freedom. Each team will share a common rule set (eg. scrum), but certain teams require additional rules to pull together as a working unit. Your job is to figure out where the freedoms are taken advantage of and to suggest more structure.

In Defense of the Poor

What is it?

Whether you are an experienced or inexperienced team lead, you will come across colleagues that just don't want to be there. As the team lead, part of your job is to show off the team. You do this via demos, planning meetings, retrospectives etc. However, we must not confuse showing off the team with blindly defending the team at all costs. Avoid defending a bad decision made by the team or an individual in the team.

Why it's bad.

I have witnessed a few cases where a team lead was adamant that a weaker member of his team did not make a mistake. He seemed to think that by 'team lead', his job title included justifying every bad action made by his team. 

By defending the team's bad practices or habits, you damage their productivity. In particular, if a team member is consistently making bad judgements, do not defend them beyond doubt. Teams learn as individuals learn - they need to make mistakes to progress. By not admitting to mistakes and working to fix them, the team is damaged long term.

Furthermore, anyone who scratches beneath the surface of the team will quickly see the fault lines. Most importantly for you, it displays you are an incapable team lead. Your job is not to be 'nice' towards your team. It is to create an effective and high performing team.

How to avoid.

Avoid 'defending the poor' in the first place. Each individual should practice being accountable towards their team. Encourage the team to correct each other at stand-ups and other team meetings. Ask questions like  "What should we have done to avoid this mistake?".

If the issue persists, particularly with individuals who are consistently making mistakes, you may need to consult with your line manager. Sometimes it is simply the case that certain people are not fit for the team or the line of work.

If you do have a weak link in the team and you are asked to explain to an external colleague (eg. manager), respond with something like:

We recognise this is an issue - we have taken a retro internally and are working on a plan to fix it.

Remember - don't mention individuals. The team made the mistake, so you must express the mistake as a whole, not on an individual basis.

Examples & Signs

Gary has been arriving late to meetings and is merging faulty and untested code into the master branch. Your manager asked you what you were doing about it. You defended your team's pride saying that Gary turns up to all team meetings and is an excellent worker and team player. Your manager walks away unconvinced.

Notice how you have not solved the problem - you have essentially said "I don't want to know about it". Your manager won't thank you for that.

Tricky part

Very often, bad performers need to be called out. But you are the team lead so it is not up to you to call them out. Be socially intelligent enough to get the team to critique themselves and each other. This comes with practice so start now!

Team Grouch

What is it?

Everyone knows this guy. Sometimes there are a few of them. They love to complain and moan about every existing problem and every non-existing problem they can think of. They complain about management, about other teams (even their own team!), about their difficult life and so on.

In a work environment, it is bad enough to have co-workers who complain.
But as the team lead, it is not acceptable for you to complain.

Why it's bad.

Complaining displays weakness as a leader. Let's be clear here - when I say don't  'complain', I do not mean you should not recognise problems. The issue is when problems are raised for the sake of raising them. Then it becomes fruitless whining. Complaining is a childish quality and so leaders should never complain. Since you are in a position of leadership, either figure out a solution or keep quiet.

How to avoid.

Ensure any problems you raise are followed up with a potential solution. Stating problems without solutions are of no use to anyone. Finding solutions to problems is why you are in your position.

Sometimes you need to let loose to your colleagues. That's ok - we're all human. Just make sure these occurrences are rare and far between. Even if a team member is complaining, don't join in with them. Instead ask "How can we fix that?". Complaining is often used as a common ground to be friendly with others. Unfortunately, you cannot have this luxury. Find other ways of being friendly!

Examples and signs.

At the team standup this morning, John complained about the QA team lead saying they don't know anything about debugging the backend. You joined in saying "Yeah John, I've had problems with that guy too in the past".

Instead, you should have said "Ok John - can you think of any way to fix this? Would you be able to give the QA guy your debugging cheat sheet?"

Tricky part.

Not complaining is difficult. We like to let off some steam every now and again. But you represent the team and so must rise above it. If you see a problem but cannot figure out a solution, ask for help to find one. As long as you are seen to seek solutions to problems, you won't come off as the team grouch.

Anyone who has been a part of a high functioning team understands that continuous improvement is not optional. In order to perform better and to keep performing, the team must identify their weaknesses and plan to strengthen or mitigate those weaknesses. These improvements remedy stress points in the team, technical debt, repetitive tasks and so forth. The mindset of continuous growth is one that must be worked on and nurtured over time. Your team is not a fine wine - it will not improve if left alone in the corner. It will go sour.

It is one thing to be told to improve something. But very often, being told to improve something does not necessarily benefit you or your team. For example, if my manager comes to me and tells me my communication is poor and he wants bi-weekly emails from now on from my team's status, all he has done is improve one of his problems, not mine. Improvements must come from within the team, and they must be gathered and executed on regularly. So the question is - how do we gather improvements that are worthwhile and specific enough to solve our problems, not someone else's?

80/20 Analysis

The Pareto Principle, most commonly known as the 80/20 rule, states that about 80% of the effects come from 20% of the causes. In layman's terms, most of the good things your team is known for doing likely comes from a small subset of your total work.

In my case, my team is known for our expertise in the upgrading of our product. How much of our work is related to this each week? I'd estimate less than 10%.

S_ide note_: This wasn't always the case. When we first formed as a team, we spent about 90% of our time on this work.

Over time our mindset of continuous improvement led us to automating away most of our problems. Here is how you can utilize the 80/20 rule to find pressure points to improve. I do this regularly by myself, and occasionally with my team.

Create a chart.

Drawing on a piece of paper or whiteboard produces far more ideas than typing on a screen. So create a chart!

What is going poorly?

Always start with the bad. What makes you stressed on a Monday? Why does your team constantly get called for customer escalations on a Sunday? What makes you cry at night? (If you're crying at night you really need this).

Copy the following table onto a piece of paper and fill it out now with any ideas you have.

What is going well?

This is less effective than analyzing what is poor in the team. You should prioritise fixing the bad over improving the good. There is no point in improving what your team is already good at if there are still issues that stress them.

Ask yourself - what are your team doing well? What do you need to keep doing well? What would happen if you improved these items?

Again, copy the following table onto a piece of paper and fill it out.

You see the action columns? Take those, discuss with the team whether they agree on the actions required, and put them clearly for all to see everyday. You could create a task in your backlog that gets seen everyday on your sprint board, or print them and place them in your team's area.

Preventative Actions

Identifying Preventative Actions is something that I have recently come across. Each team in my project go through this process every 3 weeks (every sprint). Here's how it works.

A high priority bug has come into your team. You have spent all weekend pouring over it with your team, and finally came up with a solution late Sunday night, allowing your customer to continue their business as usual. Before you close the bug, there are a couple of things you need to consider and you must get answers to them. Otherwise, there will be another weekend in the future that will interrupt your team.

Why did this bug occur?

• We received a bad requirement specification from our business analysts.
• We missed a corner case in our testware.
• There were too many manual steps in the documentation which led to human error.
• We missed a critical part of our study when planning the requirement.

What correction did you apply?

• We built a patch fix and sent it to the customer.
• We clarified with the customer that the particular use case reported is not supported yet.

How will you prevent this type of issue from occurring in the future?

• We will call a 1 hour meeting with our business analyst each week to plan and clarify the feature request.
• We will build a new pipeline that will test our customer's use case each night.
• We will automate steps x,y and z in our documentation so that human error is reduced.

In my team's case, for each bug we have the following grid which we fill out.

Retrospective

If your team uses the scrum framework for their work, then you will be very familiar with the retrospective. However, you do not need to work in a scrum environment to have a team retrospective.

Team retrospectives, if taken regularly, can be a valuable tool in the team's work week and is an opportunity for the team to come together and discuss the good and bad things that have happened in the past few weeks.

A retro should be scheduled on a regular basis, and you as the team lead must lead the meeting. Make sure that everyone from the team is present for the retro, and ensure that everyone is taking part and answering the questions.

What was good that you need to keep doing?

• We closed out 100% of our stories for the sprint.
• There was good communication with our management.
• We trialed pair programming this sprint - we have seen excellent results and should continue to do this.

What was bad?

• We had poor communication within the team.
  • Improvement: We will trial pair programming for a sprint.
• The QA team raised tickets with very little detail resulting in a few days of delay in closing.
  • Improvement: Create a template that you would find helpful and send it to the QA team lead. Request that they copy this template and fill it out for all future tickets.
• We allowed untested code into the production software.
  • Improvement: Revise the +2 code review criteria with the team.

The most important part of the retro is to make sure that improvements or solutions are attached to each 'bad' item that is discussed.
At the end of the retro, prioritise the top one or two improvements, and take note of them for the upcoming sprint to execute.

Improvement Backlog

To become a top performing team, each individual must be comfortable with raising and discussing improvements as part of the team's responsibilities. A team that does not have improvement ideas is a team that is not interested in improving which will lead to stagnation and a low performing team.

An improvement backlog is a list of ideas maintained and prioritised by the team. The list can be physical, like stickies on a whiteboard, or digital, like part of your jira backlog.

For example, my team created a Jira sprint and named it 'Improvement Ideas'. We have list about 50 improvement ideas, most of which are one-liners and some of which have been discussed with details and acceptance criteria attached.

Each sprint planning, we prioritise this list and take the items we feel are most valuable to us. We have a couple of ad-hoc rules for this backlog.

• Any ideas that come up in meetings are inserted as a 'one-liners' in this backlog.
• The list is regularly prioritised each sprint.
• Each idea is explained by the team member who originally raised it.
• We take 10-20% of our sprint capacity for improvements.

Keeping this backlog up to date and prioritised will ensure that your team has consistent tasks to work on that primarily help the team.

Stakeholder Feedback

Working in a team can often be like working in a bubble. It is tempting to fall into confirmation bias. The most valuable improvements you can get for your product will come from your customers and stakeholders.

Leading the team does not only include leading the people on the team. If your team are known for building the wrong thing, or if their customers are not satisfied with their part of the product, then you as the team lead have ultimately failed.

When it comes to feedback, there is nothing more valuable than your own customers' feedback. Your customers drive your product backlog. If you are in a large company, you may not have direct contact with your customers. In big companies, customers are often separated by layers of business analysts and management. This is not ideal, but it is something you can work around.

All you need is a small list of stakeholders that consistently use your product area to gain feedback from them. Talk to your managers about the customer interface and who could give feedback. In my case, we were 6 months without any contact with stakeholders that could give us valuable feedback. Eventually we were able to make friends with two guys who act as an interface to one of our company's top customers. To get those contacts, we needed to follow the breadcrumbs, bypassing the Product Owner and manager.

This stakeholder's feedback shed light on areas for improvement that we had not even considered before. Furthermore, they were able to give valuable feedback for improvement ideas we had in our backlog and help us prioritise.

It should be possible to get at least one or two stakeholders as a personal contact. Setup regular meetings with them and take note of their feedback, in particular their problems and stresses.

Feed this feedback into your improvement backlog and make them a high priority to implement as soon as possible.

Conclusion

The above techniques have helped my team and I gather valuable feedback and improvement ideas from both internal and external stakeholders. In using these techniques effectively, your team will improve dramatically and increase their performance.

Remember, it is not enough for your team to do the work they are asked to do. It is not enough to wait to be told what needs to improve. A high performing team must churn ideas continuously and critique themselves. Improvement ideas must come from every part of the team, since every part of the team has a role to play.

In a future post, we will explore how to get individuals of a team involved in forming ideas. For now, take a workshop, brainstorm on a whiteboard and keep executing.

Rather, we should consider the team as a car. Each individual within the team is a part of the car which has a particular purpose. We have the wheels, the engine, the body and so forth. Each part of the car is just as important as the other parts, since without any one of the single parts, there would be no car. In the same way, each team member has a unique place in the team. To replace anyone with someone else means you replace the team as a whole.

If each person has a particular place of responsibility, this means that each person must lead their responsibility. As a result, what we have in a team is not a group of interchangeable individuals, but a group of leaders, each of whom have a particular responsibility to lead.

A lot of team members don't realise this simple fact. Whether you are someone who doesn't see how important it is to lead your team from within, or if you are someone who is looking for ways to lead your team from within, you should be able to pick up some wisdom in the following paragraphs.

Be Proactive

Has your manager sent a poorly worded email to your team's distribution list without any actions attached to it? Trust me when I say your team lead hates these kinds of emails. It's one of those emails where you say "So what??" after reading it.

Rather than leaving it to your team lead to figure out, take it upon yourself to respond back and ask your manager to clarify their request. Once the request is clear, accompany the request to its completion. You will stand out to your manager and will improve the image of your team.

For example, if your team received an email asking: "Can someone on Team Xtreme meet someone from QA to figure this out?", respond back and ask for some clarification. "Hi Jane, I can help with this. I understand that X needs to be done, but can you clarify what you mean by 'figure this out'? Furthermore, who is best placed on our QA team to take this conversation with me?"

The same goes for any request that is made 'generally' without any specific actions for anyone. I often get general emails send to a distribution list with a question attached. However, when the email is addressed to 50+ recipients, everyone says to themselves "Someone else will answer that".

Rather than say "Someone else will answer that" to myself, I briefly analyze the email and see if I can answer the query directly. If not, I usually respond with something like "I think Tom worked on that before. He might be able to answer. Tom, any ideas?".

Team participation

I should go without saying, but I am surprised how often I see people not taking part in their team conversations. The worst thing anyone can do to their team is to not participate in the discussions. Silent team members who give no opinions or ideas are of little use to the team.

When you are at team meetings, speak out and argue with your team mates (politely of course). Demonstrate to your team that you are capable of free thought and happy to defend your opinions.

The same goes for team outings. Whether your like it or not, if your team are meeting up outside of work hours and you are not there, you will naturally be left out of conversations during work hours. A good leader understands that you can't have all work and no play. Attend as many gatherings with your team as possible. Show that you want to get to know everyone better.

Leading from within the team means engaging everyone in the meetings and driving the conversation. Don't wait for conversations to start from the "top" (ie. team lead, technical lead). You are as much a part of the team as anyone else, so your opinion is equally as valid.

Look Foolish

Yes - you read the title correctly. Look foolish! One of the main reasons people don't speak up when they are confused is because they are afraid of looking foolish. It is our pride that gets in the way of furthering our knowledge.

To be an effective leader, you must have the humility to ask silly questions and expect to sound foolish. If you do not take this risk, you will be very slow to learn new things.

This was the piece of wisdom that accelerated my skills forward as a team lead. By lowering the bar to a point where you don't care whether you look foolish, you will find that you can ask questions a lot easier and learn quickly.

Team Improvements

Always be conscious of the tasks you find difficult, repetitive or menial. Leading the team is about figuring out solutions to problems you regularly have. Ask yourself questions like "Is there a way we can automate this?" or "Is there a new process we could introduce?". "Why do I dislike this task?" is a good question to explore the things nobody on the team wants to do.

Request to be assigned to improvements (especially your own suggestions) as much as possible. The improvement work is often the most interesting and rewarding work. You are contributing to making the team's lives easier as well as improving your product.

Make sure you demo your work to the team - it gives them an insight into how things are improving in the background. Your team will know you are looking out for them and will appreciate your contributions.

Menial Tasks

We all know the tasks that nobody wants to do. Documentation, admin, bug reporting etc. But it has to be done for every team, including yours.

If your team lead asks for a volunteer for a task, put up your hand! Your team will thank you for taking on a menial task so that someone else doesn't have to. You have also set an example for the rest of the team to follow.

Don't Whinge

This is my pet peeve. One of the most frustrating things anyone on my team can do is to state a problem without having thought about a solution first.

When you state a problem without a solution, you essentially say "it's your problem, not mine". Instead, say to the team "I've had this problem for the last couple of weeks. Here's what I think we can do to fix it." In this way, you have switched yourself (and the team) from a state of whinging about your problems, to a state of problem solving.

As part of a team, you will regularly come up against problems that require solutions. So make sure that you get into the habit of being solution oriented, not problem oriented.

I recently had the pleasure of reading “Extreme Ownership” by Jocko Willink and Leif Babin. Jocko and Leif are two ex-Navy Seals and have spent a large portion of their training learning how to lead effectively. Their book has some excellent insights into how anyone can, and should, be a leader, no matter what their role. I read this book with the focus on Product Ownership, and have some key takeaways that I can apply everyday in my job. 

There are no bad teams, only bad leaders 

A strong leader will do everything in their power to help their team achieve their goal. They aid the team in compensating for their weaknesses, thereby continually boosting the team morale and keeping the energy levels high. 

A poor leader will do none of these things, and will always result in poor team morale. This in turn leads to bitterness and pettiness within the team, where each team member will try to pull another down rather than boosting them up. 

Have a clear vision

If a Product Owner were to begin her product vision with “I suppose we could do this” or, even worse, “I don’t have a very good product vision”, then her teams will quickly dig in their heals and be without a purpose. Team energy would immediately drop and the Product Owner would wonder why her teams were not producing good work. 

For reasons like this, leaders should be analysed and scrutinised early and often. This could be a manager, Product Owner or Scrum Master. If these key individuals do not perform from a leadership perspective, then the likelihood of a failed project inflates quickly. 

Leading the Boat Crew

In their book, Jocko and Leif give the example of a boat race they were having during training. Each boat crew had a leader. For the first race, Boat Crew II had a proven, strong and assertive leader. He was able to kick his crew into gear from the start, despite the fact he had never lead them before. 

Boat Crew VI, on the other hand, had a leader who was poor in decision making and lacked willpower. For the first race, Boat Crew II won by a large stretch. While Boat Crew II members were ecstatic and pumped at their win, Boat Crew VI were bitter and resentful towards each other. What was worse, the leader of Boat Crew VI blamed his crew for the loss, saying they weren’t up to the job. 

Then the commander had the idea to switch leaders to see what would happen. Obviously, Boat Crew II’s leader was not pleased, but Boat Crew VI’s leader was more than pleased – he was finally going to get a good team! 

The commander was surprised with what happened next. Boat Crew VI’s new assertive leader kicked them into shape from the beginning, shouting orders and getting them to work together. Boat Crew II already had some experience working together, but with a poor leader they fell apart. Boat Crew VI won. 

Leadership is the biggest factor in any team’s performance. Without a strong leader, the team will surely fail. 

Each leader should have a definite goal of what they are trying to achieve. For the Boat Crew leader, it was the beach marker. Setting small, certain goals instead of vague, far off ones will help the team focus and hold themselves accountable for reaching their target. 

Hold your team accountable

A good leader will have a high standard of performance. If she sees a weak team member, she will help in building  them up and developing the skills they lack. At the end, she is left with a better team and a grateful team member. However, people must be held accountable for substandard performance, otherwise the leader will face the situation where her team is sub-standard because she has let it become the norm. 

Above all, a leader must develop a culture of leadership. Just like a good teacher develops a culture of learning, a good leader will have junior leaders ready to step up temporarily to get a job done. She should encourage that each junior leader within the team require the highest standard of performance possible from the other team members. 

Above all, a leader must develop a culture of leadership. Just like a good teacher develops a culture of learning, a good leader will have junior leaders ready to step up temporarily to get a job done. She should encourage that each junior leader within the team require the highest standard of performance possible from the other team members. 

Check your ego 

Everybody knows and understands how many egos are associated with office politics. But it is pride that makes us think that we are never a part of it. Before you respond in a meeting or a conversation with somebody, check your ego. 

In Task Unit Bruiser, it was “insisted that our uniforms be squared away and our haircuts military regulation”. The team held themselves and each other to a high standard. They understood that humility and discipline now would lead to trust and high performance later. 

In the software industry, there are often ways that teams fall short of what is expected of them. Did you leave your documentation to the last minute? Did you avoid using Test Driven Development because it was too steep a learning curve? Did you forget to reply to that email? 

If you put your own personal incentives ahead of the team’s success or, worse yet, put more preference in your own laziness, then you will play a destructive role in the team. 

Don't give into laziness

I find it very easy to give into tiredness after a long day of meetings and not bother checking acceptance criteria correctly or leaving writing that email until the morning. It’s not that urgent, it can wait! Eventually, these shortcomings lead to some failure. They might even lead to failures you had not anticipated, and upon first glance, don’t appear that you are to blame. 

But when one of your teams makes a mistake, there is only one person to blame: you. You were supposed to lead them and in failing to do so, they have failed. Jocko advises a senior leader on what he should say for an upcoming meeting with his boss. He needs to update him and say why the product is failing miserably. 

 “Our team made a mistake and it’s my fault. It’s my fault because I obviously wasn’t as clear as I should have been in explaining why we have these procedures in place and how not following them can cost the company hundreds of thousands of dollars. You are an extremely skilled and knowledgeable superintendent. You know more about this business than I ever will. It was up to me to make sure you know the parameters we have to work within and why some decisions have got to be run through me. Now/ I need to fix this so it doesn’t happen again.” 

Are you a leader whose team suffered a heavy defeat? Don’t think it’s your fault? 

Check your ego. It’s your fault. 

Prioritise and execute 

Difficult situations often arise in the business world, particularly for team leads and Product Owners. New requirements are coming in on a regular basis for each team, new bugs are being raised against teams during their sprints, daily meeting requests fill up our calendars, and then we have to try to get some work completed. 

It is easy for any Product Owner to become over whelmed with the workload on their to-do list. In these situations, Jocko and Leif suggest you “prioritise and execute”. Leaders must remain calm in any situation. As soon as a leader loses his temper or panics, he has lost the respect of his subordinates. 

In such situations, Product Owners must take a step back to visualise the whole picture. Since the direction of projects is constantly changing, particularly in the software industry, we as Product Owners must not have our sites fixed on a single goal. Since the goal is changing, we must be able to step back to see what must be planned and prioritised. Once we have a plan and a list of priorities, we execute. 

How to prioritise and execute

Jocko and Leif give a list of tasks to prioritise and execute in a difficult situation. Practice these steps so that they become ingrained into your way of working. 

• Evaluate highest priority problem.
• Lay out highest priority in simple clear terms. 
• Develop a solution. Seek input from key leaders and team. 
• Direction the execution of solution. Focus all efforts towards that priority task. 
• Move to next priority problem. Repeat.
• When priorities shift, notify up and down the chain. 
• Don’t allow to get fixated. Step back constantly to see other problems and rapidly shift as needed. 

A key follow on from “prioritise and execute” is that we should never try to do everything at once. Trying to accomplish 5 things at the same time will lead to most of them failing or having them half completed. 

Don't panic! Prioritise and execute.

Leading down the chain of command

Most people are familiar with the concept of leading down the chain of command. Senior leaders do not need to understand the intricacies of their more junior members. By knowing too much about something, it is very possible for senior leaders to become bogged down in the details, rather than handing off the responsibility to a junior member. 

Communicate the What

As a Product Owner, I must convey the “What” to my teams as best as possible, answering their questions about requirements or at the very least, pointing them to the person that can answer the questions. Once I start delving into the “how” of a solution, I have immediately lost my position of leadership. Straight away, the team have turned from a vision-focused attitude to one of how are we to accomplish this? The Product Owner must learn to step back from the technical side and entrust it to their team. 

Communicate the Why

The above problem is common, however the more pervasive issue that occurs is where the senior leader fails to communicate the Why. Why is your team putting in this requirement? Will it help the product? How will the end user use this requirement? Without putting across the why, the team cannot understand the best solution to the problem. It is very possible that the requirement is not what the user needs to accomplish their goal. 

When a Product Owner is discussing requirements with his teams, the What and the Why are the key issues he needs to get across. By leading down the chain in this way, and entrusting the how to his teams, the requirements can move in the best direction forward. 

Leading up the chain 

Leading down the chain is a very clear concept. Essentially, it is about senior leaders leading their junior members in the best way forward by communicating the what and why. 

Leading up the chain is something many people struggle to understand. Yet once you understand it properly, it becomes a powerful skill. This lesson is the most valuable in the whole book, and rings true with my daily tasks. 

My leader isn't leading

A problem that everybody comes up against, whether you are a junior developer or project manager, is that we regularly come into situations where nobody is willing to lead. 

For example, a junior developer receives a bug in her backlog one morning when she arrives into the office. The bug contains 2 lines describing briefly what happened to the user, but there are no logs attached, no steps to reproduce, nothing except a brief overview. 

The developer looks at her screen, spends an hour trying to recreate the vague situation that has been described and eventually huffs and gives up. At lunch with her workmates she complains about how terrible the bug author is and does not know how to proceed.  

What should this developer do in such a situation? She is lacking leadership from the bug author and cannot proceed without doing something. Jocko and Leif say that if you are not being led, then lead. 

In the case of the junior developer, it is up to her to contact the bug author, and give a list of details that must be filled out before she can continue with the ticket. 

Reach out

For example, an email to the ticket author might look something like the following. 

Hi James, 

I see you raised a ticket against me this morning. Before I proceed with solving the issue, there are some details I require from your system: 

Product version 
Logs / trace files 
Steps to reproduce 

I cannot proceed with your ticket without the above details.  

Best Regards, 

clara.

Here, Clara has led up the chain of command to the bug author. 

From a Product Owner’s perspective, we come into situations constantly where no direction is being given, and communication is vague and implied. In these situations where our colleague is unwilling to lead, it is up to us to lead them. 

State the problem, propose a solution

If, for example, a senior manager contacts you as a Product Owner, asking you to assign a responsibility to one of your teams without giving any details about what is an expected outcome or what tasks are involved, do not simply say yes. 

Tell your manager that in order for your team to take on this new responsibilty, you first need a list of items that need to be completed and a list of expected outcomes. Once you have this information, you can then approach your team and communicate properly what is required of them. Otherwise, they will become frustrated that you are asking them to do something, but don’t seem to know exactly what. 

Learning to lead up the chain of command is the most valuable skill I have learned so far as Product Owner. The wall most people run into with this lesson is this: If your leader isn’t leading you, then it’s their problem. This is false. Your leader will still require you to get the job done. It is up to you to explain what you need in order to get there. If you want to stand to your senior management and colleagues, learn this and practice it every day. You will make mistakes getting it right, but will be very respected once you come out the other side. 

State the problem, propose a solution.

Summary 

Leadership is a part of every job. You do not need to be a manager or in a particular industry to utilise these techniques. Teachers, doctors, developers, recruiters can all find benefit in these skills and use them to accelerate their careers. 

If you are interested in getting started as a leader, I recommend reading “Extreme Ownership” by Jocko Willink and Leif Babin. 

To summarise: 

• There are no bad teams, only bad leaders. 
• Check your ego. 
• Prioritise and execute. 
• Lead down the chain of command. 
• Most importantly, lead up the chain of command.

• Take a deep breath before you walk into a conversation.
• What is the person leaving out?
• Paraphrase the other person's concern back to them.

Listen Effectively

Listening is a highly underdeveloped skill that most of us do not use. It is also a very difficult skill to develop. We spend about 50% of our time everyday listening. Despite this, only a tiny minority of us have ever been trained to listen effectively.

Nowhere is this more clear than in the workplace (and the college campus!). Daily conversations and arguments happen over lunch or in meetings that are often dominated by a minority of strong personalities.

As a result of a select few taking over the conversation, the people who are more reserved do not get the chance to make their opinion heard. Furthermore, if the louder person is particularly dismissive, then it is not uncommon that the quieter opinion gets pushed into the margins.

Apart from these cases, the average person can also use their listening skills more effectively with just a few techniques. Use these techniques when you need to clarify someone’s position or gain a greater understanding of a viewpoint.

I use these techniques everyday during meetings or conversations when somebody is explaining their idea. By asking some key questions and listening carefully, I make sure that I understand the message of the other person as well as make them feel comfortable speaking with me. If you are in a leadership position, this is extremely important. A leader who is a poor listener will not progress with their teams.

Take a deep breath

Breathing is a proven effective exercise for calming the mind and relaxing your body. By breathing deeply before having a conversation with a person or walking into a meeting, you de-stress your body so that the conversation is relaxed, friendly and professional.

Before you walk into a meeting or when you queue in the canteen for lunch, take a moment to breathe deeply and slowly. Breath in for 5 seconds, hold it for 5 and breathe out for 5. By doing this, you will relax and enable your brain to go into a conversation clear of distraction.

What is not being said?

Oscar Trimboli has written about the 125/400 rule before. To summarise, most of us speak about 125 words per minute. Moreover, we can process between 400 and 450 words per minute. When we are trying to explain a concept to somebody, our mind outperforms our mouths.

Without first thinking about what we want to say (and let’s face it – who does?), it is easy for our conversation to take tangents. Our mind starts to race ahead of what we are saying and instead of explaining a story with a beginning, middle and end, we jump from the beginning to somewhere else and only sometimes end up at the finish. It is very easy to lose context when we speak, particularly if we are not rehearsed.

To gain a deeper understanding of the person’s narrative, think about what they do not say. Are they missing out on explaining some technical details? Do they make an assumption that does not sound correct?

Of course, you should think about what they are not saying within the confines of the conversation. Don’t ask about the weather if you are talking about a new product feature.

But why Dave?

For example, say Dave wants to talk to you about a new login page for your customers. He explains in great detail what the login page will look like, how the user will use it and so on.

Dave has explained very clearly what his idea is, but he has not explained why he thinks we need a new login page. In fact, it is possible that the why here is much more important than the what. Has Dave identified a user scenario we have missed that requires this page? Does Dave have information about a customer that we have overlooked? Do we need to redesign the current login page?

As you can see, by simply asking Dave “Why do we need a new login page?”, we gain far more knowledge about his idea and the purpose behind it. If we had merely asked him to clarify about his new design for the login page, we would not discover this crucial piece of information.

Ask questions to uncover what was ­­_not­_ said. You will quickly gain insights into your conversations and develop deeper levels of listening and comprehension.

Repeat it back!

Have you ever noticed that it isn’t until you explain a topic to somebody else that you realise how many holes are in your understanding? The purest form of thinking is when we talk to people. By speaking our thoughts aloud, we quickly realise how little we truly know about a subject.

If you don’t believe me, pick a random topic that you know and try talking aloud about it for five minutes. Don’t prepare anything. You are doing very well if you reach the five-minute mark. This is because without preparation, it is very difficult to organise our thoughts enough that they are ready to pour out to somebody else when called upon.

By taking this into account when somebody is speaking with us, we can use this next technique to gain a deeper level of listening.

Paraphrase

To make sure that you fully understand the other person’s viewpoint, paraphrase back to them your understanding of the conversation thus far. The other person will either nod their head vigorously, or interrupt you to correct you.

Since we can only process so much meaning in our speech, it is important that you state the other person’s concern or idea back to them so that everyone is on the same page and the conversation can progress.

If you are wondering what ­_not_ to do, have a look at this: "So you're saying..." .

To have a meaningful discussion, it is important that you represent the person’s views fairly. In debates, we call this making a “steal man” of your opponent. It is also the opposite of “straw man”. Although you should not treat conversations as debates, this concept is very important to represent somebody and make sure they are  heard for what they think, not just what they say.

Summary

Remember to take a deep breath before you start speaking in a meeting or even in a one-on-one conversation with somebody.

Think about what the other person is not saying. They may leave out key bits of information you need to fully understand what they are talking about.

Ensure that you are on the same page as the person talking by repeating back to them what you understand about their query. They will either confirm your understanding or correct it if you misunderstood something.

• Avoid using vague terms.
• Use real world data.
• Use real world examples.
• Stop writing scripts.
• Involve fewer people.

Overview

Example mapping is an effective way to clearly communicate new features or user stories to a team. When used effectively, examples are shortcuts through hours of conversations and long user scripts.

Everybody who works in the software industry should understand how to map out good examples of their work. It is an extra tool in a developer’s toolkit and it is necessary if you are in a position of leadership such as Product Owner or team lead.

A prime example of example mapping is in the Friends’ episode titles. Here are a few of them:

• "The One with the Blackout"
• "The One Where the Monkey Gets Away"
• "The One with a Chick and a Duck"

If you have seen these episodes, you know immediately what these titles describe. There is no need for a description or even a list of the characters. Because the title is written as an example, is good enough for us to understand what the episode is about.

There are many ways to create examples. I have gathered five helpful tips from my own experience which you can use.

Avoid using vague terms

You should use concrete examples as much as possible to illustrate the use cases. Take a step back from your example and ask yourself “Is this as specific as we can make it?”.

For example, if my customer is using my banking system, rather than saying

• Where the customer clicks the submit button more than once and receives an error message.

You should say

• Where the customer clicks the submit button twice and receives an error message.

Be specific

Narrowing down what is meant by ‘more than once’ helps us to get a clearer picture of the example. Furthermore, it increases a shared understanding in the team. It is very possible that the first example would give confusion as to whether a button should behave differently when it is clicked twice or one hundred times.

Represent an idea with a concrete example rather an abstract example.

Use real-world data

When creating examples, one should strive to create examples using real-world data. The difficulty in creating examples with made up data is that we run into strange situations where our real-world data does not align with our fictional data.

For example, I can create the following example with my fictional data in my banking system:

• Where my customer deposits $300 into their savings account.

The team would receive a shock when their customer contacts them angrily saying that they have not taken into account their customers who are using euros!

It is easy for examples to deviate from the product specification when we fake the data inside them. Something so simple as using dollar instead of euro can easily be resolved by understanding the real-world data.

Furthermore, if we are working on a “legacy” system and use fictional data in our examples, then we cannot know with any certainty that our made-up data will fit with the data the legacy system produces.

The changing rules and data structures of legacy systems means that using real data to drive our examples is key. A simply misunderstanding in the data can very likely result in an incorrect solution.

Use real-world examples

In the previous section, we spoke about using real-world data. Following on, we should use real-world examples also.

It is important when creating examples that we capture how the end customer will use this specification. By capturing how they will use it in an example, we are able to capture what the specification involves.

If, instead, we use fictional examples, then we are creating a “what if?” scenario. Rather than focusing on what the specification ought to look like, we focus on our imaginative conception of the idea. More often than not, this will be a false conception.

Let’s go back to our banking application.

• Where the user withdraws €20.50 from the bank’s machine.

This looks good, right?  But what happens when the bank calls us back saying that they do not give change from their machines and inputting a decimal point results in a major failure?

This could have been avoided by using the real example of how a user ought to withdraw money from the bank.

Get close to the customer

It is key in these scenarios that the teams creating the specification have close access to the customer. In reality, this can be very difficult.

Large companies often have a heavy buffer between the customer and developers. If this is the case for you, then your goal is to get close to the person who is close to the customer.

Often, there will be a team that are customer facing and take on their requirements. Introduce yourself to this team and communicate frequently with them. Once you are on good terms with this team or person, you may be able to suggest that you come on board for the next customer meeting.

Stop creating scripts

Here is an example of a script:

• Enter username & password
• Click login button
• Land on dashboard
• Go to search page
• Search for “12 Passat”
• Click on first result
• Click on ‘details’ tab
• Check that car price is present

Scripts are not examples. What we are describing here is the how, not the what. By prefacing the how with the what, we are ensuring that the how follows the what and not the other way around.

What we are creating and why we are creating it is more important at this stage of discussion than understanding exactly how we are going to achieve our goal.

Furthermore, from an example perspective, we should not care how our specification is implemented.

Scripts act as anti-patterns to examples. By using examples, we can cut out the majority of a script and get to what the script is describing.

Imagine that any given feature involves pages and pages of scripts in order to correctly describe it. Now imagine what we need to look at when one of our usability tests fail. We need to comb through too many words to find what we need or where it all went wrong.

By having scripts instead of examples, we create a murky idea of what we are implementing. By using examples, our communication with the reader is much more effective and allows us to cut out a lot of writing, thereby saving us energy and lots of time.

Brainstorm with fewer people

A common issue I encounter is when there are too many people in the room for us to have a meaningful conversation. It is rare that a room consists of people who are all interested in what everyone else has to say. Most often, a subset of dominant personalities will take over the workshop and drown out the good ideas of the others.

There is a simple way to mitigate the amount of opinions in the room – reduce the number of opinions.

There may be those of you that think that having many opinions in the same room can be a good thing, and you are correct!

Very often, in order to hammer out the finer details of a user story or a feature, we need two or three strong-willed individuals to clash. In my experience, this type of conversation can be very helpful, but only if there is somebody to take charge and mitigate the conversations. This is usually the team lead’s duty.

Circular conversations

Doing workshops with large groups also increases the regularity of circular conversations. I believe circular conversations to be the most common time-waster in meetings.

By decreasing the number of persons in a workshop, we are able to take down everybody’s thoughts quickly with minimal time wasting.

At a very minimum, I suggest that three people are present in any one of these workshops.

• Product lead
• Test focused developer
• Developer

The product lead understands the product the best. This may be the product owner, team lead, or another stakeholder.

The test focused developer is important for their testing mindset. They need to be able to poke holes in what is discussed and find out where there are gaps in knowledge and understanding.

Finally, developer should be focused on understanding as much as possible from a developer’s perspective so that the how can be focused on later on.

Summary

Writing examples is a quick way to cut out needless conversation. Use examples regularly to save time and to increase communication between yourself and your team mates.

To summarise:

• Get specific - don’t use vague terms to describe your examples.
• What is actually happening? Use real world data.
• Who is doing what? Use real world examples.
• Save time - stop writing scripts.
• Circular conversations? Involve fewer people.

Go to https://www.cygwin.com/install.html and download setup-x86_64.exe Run it

• Select 'Install from Internet'
• Choose root directory (default)
• Choose pacakage directory to store installation files
• Use System Proxy Settings
• Select any mirror site to download

In 'Select Packages'

• Select Category dropdown and search for lynx
• Go to All -> Web -> lynx: A text-based Web Browser
• Select latest version
• Click next to complete installation

2. Install apt-cyg

This is a package manager for cygwin

To install:

• lynx -source rawgit.com/transcode-open/apt-cyg/master/apt-cyg > apt-cyg
• install apt-cyg /bin

3. Install dependencies for ansible

To install altogether

• apt-cyg install binutils curl gcc-core gmp libffi-devel libgmp-devel make python python-crypto python-openssl python-setuptools python-devel git nano openssh openssl openssl-devel

You can also install individually by using

• apt-cyg install  or by using the installation GUI

4. Install Ansible

To install

• easy_install-2.7 pip
• pip install ansible -vvv
• Here, the -vvv is used in case the install seems too slow. It will show you if everything is still working.

5. Test ansible

To test installation

• ansible
• Should receive list of options

Some configuration

Cygwin comes with some strange default settings, particularly if using vi or vim.

Open a .virc file.

• vi ~/.virc

Type in

set nocompatible
set backspace=2 

Run a playbook with Ansible

Make a new directory to test ansible with a simple playbook.

mkdir ansible-lab
cd ansible-lab

Ansible needs some configuration to work on a Windows machine. Our Windows machine is called the 'control' machine. Ansible does not officially support this.

Create an ansible configuration file.

vi ansible.cfg

Copy and paste the following into the file.

[ssh_connection]
ssh_args = -o ControlMaster=no

Now we will create our ansible playbook to test.

vi playbook.yml

Copy the following into the file.

- hosts: all   
  sudo: yes   
  tasks:   
    - name: install apache2  
      apt: name=apache2 update_cache=yes state=latest   

Bring up a virtual machine

We need a virtual machine to run this against. For this we will use a Vagrant box. Don't worry if you have not used Vagrant before. It is an easy way of installing virtual boxes on your machine and managing them.

We need a Vagrantfile to bring up our virtual machine.

vi Vagrantfile

Copy and paste the following.

Vagrant.configure("2") do | config|  
  config.vm.box = "bento/ubuntu-18.04"  
  config.vm.network "private_network", ip: "192.168.33.10"  
end

This will bring up a ubuntu virtual machine to run our ansible script against.

To bring up your virtual machine, make sure you are in the same directory as your Vagrantfile and type

vagrant up

Depending on your connection, this may take a little while to boot up.

Once your machine is booted (you can check if it was successfully booted by typing vagrant status), you need to make sure your control / Windows machine can connect to it.

Setup ssh connection

On your Cygwin terminal, generate an ssh -key.

ssh-keygen

Keep pressing enter until it is finished. Print out the .pub file where it saves the key. For example, mine looks like the following. Yours will be in the .ssh folder also.

cat /home/abcd/.ssh/id_rsa.pub

Copy the value that is printed out. Now you need to go to your vagrant machine.

vagrant ssh
vi .ssh/authorized_keys

Go to the end of the file, go to the next line (by pressing enter) and paste in your key from the id_rsa.pub file

Exit your vagrant machine.

exit

Test your ssh connection with the following.

ssh vagrant@192.168.33.10

You should be able to login to the virual machine without any prompt or failure.

Exit the machine once again.

exit

Run your ansible playbook

Make sure you are in the same directory as your ansible script. Ideally, you have your Vagrantfile, playbook.yml and ansible.cfg all in the same directory.

Ensure ansible is ready to go.

ansible-playbook --version

Now type the following.

ansible-playbook -i vagrant@192.168.33.10, playbook.yml

Your tasks should appear in a list. Once finished, the PLAY RECAP should have ok=2 and changed=1.

Congrats, you have just run your first ansible playbook!

Codeigniter HMVC is a transformation of the popular MVC (model-view-controller) model that is widely used today. It came about as a solution to some problems that developers came across when using the MVC framework.

Problems with MVC

• Quite often, it can be difficult to transfer features from one website to another.
• MVC does not scale very well. It discourages good design practices and can lead to a lot of spaghetti code.
• MVC doesn’t have standardised practices. As a result, we get lots of different opinions as to how one should properly use MVC
• In comparison to HMVC, adding widgets to an application designed with MVC is difficult.

HMVC solves most (if not all) of these problems.

Advantages of HMVC

• Modularization: We can separate each section of the app, dividing the app into different parts.
• Extendibility: We can add parts to the application easily with little risk of breaking the application. For example, widgets.
• Organization: Super tidy file separation and folder organization!
• Reusability: If implemented well, the developer should be able to reuse every bit of code they write.

HMVC Structure

The HMVC (Hierarchical Model View Controller) structure is a combination of multiple MVC triads. Each MVC triad is called a module. A controller of one module can call a controller of another module very easily.

Furthermore, we can call other modules from view files. This makes it very easy to insert widgets quickly.

Modules

A module contains the model, view and controller folder for a certain section of the app.

For example, if we take http://www.mywebsite.com/welcome, then we know that /welcome is actually a module! So every file that relates to my /welcome page, apart from external libraries, are placed inside the Welcome module =>

This demonstrates how easily managed apps can be, cutting down on time resolving conflicts from different versions of files, and avoiding general confusion.

Now it's time to install our own HMVC framework.

Installing Codeigniter MVC

• We need to install vanilla Codeigniter before we install our HMVC file structure.
• First download most recent version of Codeigniter.
• Install codeigniter on your computer – this is just a simple matter of copying + pasting the files into your root directory.
• If you do not have a server installed, checkout my post on installing wamp.

If you have followed the Codeigniter documentation, you should have the MVC file structure setup in your directory like below. Here we can see our controller, models and views folders – which is what the MVC framework looks like.

• Check that all is working and go to the URL /index.php/welcome
• You should see the welcome page of Codeigniter.

Install HMVC structure

• Download modular extensions
• Unzip the downloaded file
• Go into the /third_party folder
• Copy the folder /third_party/MX
• Go to your Codeigniter directory and paste into /application/third_party

• Do the same thing again except copy and paste the contents of /core in the downloaded file into /application/core in your codeigniter directory.
• You should now have something like this:

• Make sure everything still works by going to the URL /index.php/welcome

Transfer files into HMVC framework

• Create the directory application/modules/welcome/controllers
• Move the file application/controllers/welcome.php to application/modules/welcome/controllers/welcome.php
• Make sure everything still works by going to the URL /index.php/welcome
• Create the directoryapplication/modules/welcome/views
• Move the file application/views/welcome_message.php to application/modules/welcome/views/welcome_message.php
• Make sure everything still works by going to the URL /index.php/welcome

Once the above URL loads, this means that HMVC Codeigniter has been successfully loaded. Congratulations!

Redirect from /index.php/welcome to /welcome

When you first access your newly setup HMVC app, you will need to access each module via /index.php/welcome.

If you try to go to /welcome directly, you will get a 404 not found. This is a bit messy - so let's fix it.

Go to the root folder of your Codeigniter application. Create a new file called .htaccess. Paste in the following code.

RewriteEngine on
RewriteCond $1 !^(index\\.php|resources|robots\\.txt)
RewriteCond %{REQUEST\_FILENAME} !-f
RewriteCond %{REQUEST\_FILENAME} !-d
RewriteRule ^(.\*)$ index.php/$1 \[L,QSA\]

Note: There are already .htaccess files in Codeigniter - these are not the files to edit. Create a brand new .htaccess file at the root of your directory structure.

Now go to /welcome. You should be able to see your welcome page!

Next Steps

Experiment with your welcome module and learn how codeigniter works. Mess around with the controller.php, create some new views, add in some CSS and get comfortable with your new framework.

Once you are comfortable, it's time to think of an app idea -good luck!