I build a ritual with my teams where every week we ask ourselves "what did we learn this week?" This helps us really focus on continual improvement as part of our core DNA. For myself, I have a daily ritual of reflection and action. As I drive home for the day after work, I spend 20 minutes asking myself "what didn't go well today and how can I improve it tomorrow?" I make daily micro-adjustments to how I personally operate in challenging situations so that I'm always fine-tuning my growth.

So I've heard this discussed by Gene previously as well as Mike Rother in Toyota Kata. It wasn't until TUP where it really started to get me thinking that I should be focusing on this with my team. At the end of each week, I have my team submit a weekly report containing 3 things. 1) Weekly High, 2) Weekly Low, 3) Why the org should be glad they work there (in other words, brag about all the awesome stuff you did). That said, I'm now thinking of changing that 3rd item to "what did you improve in your daily work (or others) this week?".

That’s an interesting practice Steve. Thanks for sharing. The 3) Why the org should be glad they work there (in other words, brag about all the awesome stuff you did) part made me think of another, somewhat related question, something along the lines of... 4) Why should you be glad you work for the org? (in other words, hopefully they'd be able to point out stuff like... "b/c they care about and foster the improvement of daily work")

@USB84PTDL It's a really great tool. I get great insight into what is going on with the lives of my team. They don't just tell me about work-related highs and lows. It's also helpful for doing annual reviews because I have weekly summaries of all the things they did over the year. Helps combat the "recency effect" often seen in reviews.

Second the regular team retrospectives. We’ve experimented a lot with the frequency and the questions. Ones the team liked the most were simply “things I liked”, “things I didn’t like”. The good one was also (for a bigger period, like a sub-project), “3 things I am proud of, 2 things I learned, 1 thing we must change”. The most important part (and the hardest) is committing to implementing the improvements that were discovered on these meetings.

Also, there was an advice I got from another book club member here, @UNH35FT44, a while ago: if you could just spend 15 minutes of your day thinking on how to improve your work, that would make a difference (which echoes @URXJZDTEX’s comment above). Now, I don’t follow this as often as I should, yet every time I do do this, results are tangible.

I would like to share a real-world example of what this can look like from an organisation I am working with. They have an internal system that had provided support to the company over many years, continuously evolving to support the latest set of requirements. It was managed by a hero engineer (think Brent) who had found it impossible to refuse any request for change. The impact of this was that it was a highly complex configuration with redundant and conflicting processes in place. After a significant outage (costing many $$$ in productivity costs alone) an action was taken to identify the pain points in the system and work to fix. These became part of each weeks daily workload. Over the course of 6 months the number of outages fell considerably and the end user satisfaction increased. The most important aspect was the Change Control Board started to say no to requests that could impact the stability. Now with a much more stable platform new features can easily be tested and if they do not impact the current solution added within control. A great example of how the improvement of daily work helped move the organisation as whole forward from a place of pain.

@URVQS5GSE - a question for you about this… > The most important aspect was the Change Control Board started to say no to requests that could impact the stability. When in the process would these requests be reviewed by the CCB? I ask b/c I’ve seen stuff like this, specifically I’ve seen it go in this order: 1. Someone, somewhere requests a change 2. Engineers go off for a couple weeks or more to make the change, work hard on it, get it tested in pre prod envs, and have it ready to be deployed to prd. 3. The request for putting the change in prod comes to the CCB, and at this point it is denied. When I observed that, IMO it was completely out of order and led to a very toxic and discouraging environment b/c you have all these people that worked hard on something they thought mattered, only to get squashed at the very end. It seems patently obvious to me personally that if requests for change are going to be shut down, they get shut down as early as possible. Is this the way it’s worked for your org?

@USB84PTDL the first aspect was what could be described as changing the culture of the organisation from one where each person thought of the tool as being there to serve them alone to one of a tool that everyone shared and had responsibility for. This meant that everyone now had ownership for stability and they were therefore expected to consider this before they started any development. The CCB operated as a final quality control point to stop the deployment of code that could affect the stability. This brought together representatives of all aspects of the service. Whilst there are multiple reasons for a "No" the most frequent was where there was insufficient robust testing. Many items were allowed on subsequent submissions when they had been fully tested and reworked. But there was also a pre-submission process outside the actual CBB meeting where anyone could ask for advice as to whether a request was likely to be rejected and this could be done at any point in the development. This was very effective in making sure that what was presented to the CBB was more assured of passing. I would fully concur with your statement that leaving all decision making to the end can lead to a toxic environment. But the culture of this organisation was that there was a shared ownership throughout and the CBB was a Quality Assurance rather than a dictator and it provided guidance before, during and after on how to reach the quality threshold.

Good stuff there Phill. Thx again for sharing.

I see many organisations that are "scared" to stop/change development once a commitment has been made to a manager/stakeholder. So one of the other important things is to empower people to be self-critical and have the psychological safety to be able to flag this when required.

Yes! I'm sending it out shortly.

No. It was not recorded by chance. 😁

Hah

All part of the master plan

@ULPRC893P are there any updates on the transcripts of AMA sessions?