Beyond Root Cause Analysis
Using root cause analysis for people problems
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.
Don't know what to focus on? Develop a vision
How to know you're not focusing
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.
Turning up the Good
Get better results by focusing on what's working
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.
Learning Lab: Case Method
I've taken this workshop format from the videos on the HBS Case Method.
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
- Present scenario
- Split into pairs & explore case.
- Brainstorm case together.
- Split into larger groups to practice answering the question again
- Practice answering the question individually.
- 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.
Asking HN Their Favourite Lecture Series
Posting a Question on Hackernews
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
Lost Communication Moments in Remote Working
Remote vs. In-person debate
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.
Remote Mob-programming toolkit
This template is inspired by a number of software coaches including Woody Zuill, Kevin Meadows and Llewellyn Falco.
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:
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
- Someone volunteers to be the first driver.
- Someone else volunteers to be the first navigator.
- The driver shares their screen.
- Everyone reads the problem statement.
- Start the timer for 5 minutes.
- The navigator either directs the driver straight away or consults with the mob on what to do.
- 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.
Questions for teams' retros
Why use different retro questions?
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?
List of Software Definitions + Phrases
Definitions are pretty pointless...aren't they?
I remember studying for a physics exam. While my maths skills were pretty good, I never properly learned the definitions of things and, as a result, didn't get good marks in my exams. At the time, I remember thinking "It's not like I'll ever need this...what's the point in learning it?" But learning definitions is not pointless - it's necessary. When you learn a definition, you shortcut what probably took 1000s of hours from different people to get to that definition. The definition of anuthing is likely a far better summary than you could ever come up with.
But here's the catch - just because you know the definition doesn't mean you know what you're talking about. I think this is where the novice falls down. Sure, you can learn off the definition and not be an expert. But...and here's the point...you can't be an expert without knowing the definition. Almthough I complained that I had to learn off physics definitions for my exams, my (excellent) physics teacher easily cited back multiple definitions in each class without looking at any notes. The expert uses definitions to avoid reinventing the wheel.
For example, if I try to explain the software principle of DRY (Don't repeat yourself) without using the principle itself, I end up with a load of gibberish as I try to find different words to describe DRY. Even worse, someone might say "David, you're talking about DRY right?" and will soon conclude that I don't even know the thing I'm describing. Therefore, it seems to me that knowing definitions are not only important, but are necessary. So here is my attempt at gathering and recording any useful definitions I come across to 'parrot' back to the people who are unfortunate enough to listen to me.
List of Software Definitions + Phrases
Note: This is update with anything new I come across.
- DRY: Don't repeat yourself; Used to reduce repition of software patterns.
- Scrum: Empirical framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
- Agile: A philosophy of iteration and continuous improvement when delivering software; Incremental deliveries
- Kanban: Helps visualise work, maximise efficiency + continuously improve.
- Servant leader: Someone who wants to serve first, lead second;
- Satisfy the customer through early and continuous delivery of valuable software: Agile principle; Requires early and constant customer feedback; More feedback correlates to happier customers correlates to happier workers; So always seek more feedback;
- Welcome changing requirements, even late in development: Agile principle; Requirement always change.
Knowing chess rules does not make me a grandmaster
What are the rules of chess?
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.