Thursday, July 24

Giving Feedback (Part 3) - Taking Your Time

Table of Contents



I

s There Enough Time to Breathe?

It’s not just about whether managers have time to give feedback—staff need time to receive and process it.

Running a team at 100% capacity is a false economy. Key people become unavailable when others need help. Processes snarl as staff create workarounds for missing inputs. Quality suffers. Services break. Customers are unhappy. Revenue is impacted. 

If your people have 16 hours of work to do in an 8-hour day, the first thing to go is communication—and with it, feedback.


Feedback Isn’t a Standalone Activity

Feedback is just one part of a larger communication ecosystem.


  • If expectations aren’t met, but no one shared what was expected—is that fair?
  • If veteran staff don’t train juniors, how can performance gaps shrink?
  • If subject matter experts or stakeholders are unreachable, how can work align to needs?


Teams need time and space for:
  • Briefing and debriefing
  • Coaching and support
  • Asking for and offering help
  • Co-working and handovers
That takes intention. And time—for both speaker and listener.


 


Summary of Key Principles

  • Timeliness matters. Feedback should be part of regular communication—not a rare event.
  • Specificity beats generality. Talk about behaviours, not character.
  • Curiosity builds trust. Feedback should open dialogue, not shut it down.
  • Safety is non-negotiable. People need to feel safe to speak, ask, and change.
  • You’re not too busy. Make time—for the speaker and the listener.
  • Start small. The earlier you address issues, the easier they are to fix.



Difficult Conversations: How to Discuss What Matters Most by Douglas Stone, Bruce Patton, Sheila Heen, Roger Fisher

Goes deep into the emotional undercurrents behind tough talks—including feedback—and how to navigate them gracefully.



Crucial Conversations: Tools for Talking When Stakes are High by Kerry Patterson, Stephen R. Covey,  Joseph Grenny,  Ron McMillan,  Al Switzler

Practical techniques for staying calm, respectful, and effective during emotionally charged feedback moments.



Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Malone Scott

Challenge directly while caring personally. For those who want to foster open, honest, and respectful feedback cultures.




Shift from one-way criticism to “feedforward”—a more collaborative, forward-focused style of giving feedback
at No comments:

Giving Feedback (Part 2) - Feedback on People Skills

Table of Contents




P

eople Matter: Why Feedback on Behaviour Can’t Be Optional

Feedback typically falls into three categories:

  • Task – Are results being delivered?

  • Process – Is the work safe, smooth, and repeatable?

  • People – Are relationships functional and respectful?


Of the three, people-focused feedback is the most neglected—yet often the most consequential.

When You Must Speak Up

Some behaviours require immediate feedback—no hesitation, no delay:


Communication Is Everyone’s Job

Collaboration, communication, and coordination are crucial, even when they’re not spelled out in KPIs. If they’re missing from job descriptions—why?

A common failure is “throwing work over the wall” without confirming the next person has what they need. Teams must understand: doing your narrow job description isn’t enough. If the team fails, everyone fails—even if you ticked all the boxes in your individual KPIs.


Who Pays the Price of Communication?

It’s worth asking: Is the cost of communication fairly shared?

The classic example is scheduling meetings across time zones. But the imbalance is often more subtle:

  • Who adjusts their schedule?

  • Who always takes the notes, sends the reminders, nudges the follow-ups?

  • Who responds to late-night messages?

These hidden costs accumulate—and they’re rarely distributed equally.

Sometimes, the team as a whole needs feedback. And sometimes, that feedback includes you.

The line “There’s no ‘I’ in team” is overused—but it’s often the first thing forgotten when pressure hits.


Self-Interest Hurts the Team

Some team members will prioritise their own convenience over the team’s success. It happens. And it must be addressed when it does.

A Cautionary Tale

I once had a senior developer who instructed a junior dev to do low-value busywork—not because it was necessary, but to avoid merge conflicts that would arise if the junior completed their assigned tasks. The senior developer thought it was better to do both roles alone.

I had to give them some pointed feedback: leadership demands a different mindset. Being a great individual contributor is not enough. You must care about the team’s success as much as your own.

I told them, “Please, don’t make me say this... but there really is no ‘I’ in team.”

I hate relying on aphorisms—they often signal lazy thinking. But sometimes, they say exactly what needs to be said.


Prioritise the Listener

As a general rule, I tend to side with the listener in a communication breakdown. When offering feedback, consider what the listener needs to hear—not just what you need to say. What format suits them best? What questions do they have? Did they actually understand you?

These aren't just tips for giving better feedback—they're also important topics to give feedback about when communication is breaking down. 


Feedback Should Be a Conversation, Not a Lecture

Feedback shouldn’t be a one-way broadcast. It’s a dialogue—one that requires curiosity and empathy.

Demanding an explanation is not the same as being curious. Your tone, posture, and expression matter just as much as your words. You need to look like you’re listening—and mean it.

Kim Scott in Radical Candor, calls this the “Give a Damn” axis. If you haven’t done the work to build a relationship, your feedback is less likely to land.

Some people will respond to feedback immediately. Others need time to reflect. If they seem unreceptive, invite them to think about it and revisit the conversation later. Many people resist feedback at first, then quietly change their behaviour. Take the win.

You also need feedback yourself—from peers, reports, and managers. Working without feedback is like driving with your eyes shut.

Kim Scott encourages not just giving and seeking feedback, but building a culture where it’s continuous and mutual—where feedback continually flows in all directions, across roles and ranks. 



Is It Safe to Speak Up?

Psychological safety underpins all effective communication. When people feel threatened, they shut down—entering fight, flight, freeze, or fawn mode.

The military has a term for what happens when people are too scared to speak up: SNAFU (Situation Normal, All Fouled Up).

One of the most frequent pieces of feedback I give is: “Ask for help earlier.” But if your environment doesn’t feel safe, that advice is impossible to follow.

People become over-invested in solving problems alone, believing the next Google search or attempt will get them over the line. Admitting they’re stuck feels like admitting failure. Their identity may be tied to being the person who always figures it out.

Often, the solution is a five-minute conversation or a second set of eyes. But that requires vulnerability, which requires safety.

Sometimes people are even set up to fail—because the system, including its unspoken rules, makes success impossible.

 “Every system is perfectly designed to get the result that it does.” ― W. Edwards Deming
If people don’t ask for help—or don’t feel safe to do so—and you and your organisation do not respond quickly or fairly to their feedback, you will get SNAFU.

Worse, you can get the kind of culture where teams are rewarded for failing in an acceptable way, but punished for succeeding unconventionally. That’s double SNAFU. 

Kim Scott’s third rule for building strong teams is simple but powerful:

Make it easier to speak truth to power.

That’s how teams are freed from blockers that prevent forward progress.  

Summary: Key Points:

  • Some feedback can’t wait. Disrespect and intolerance must be addressed immediately.

  • Team success matters more than individual KPIs. People must be held accountable for how their work affects others.

  • Communication costs must be shared fairly. Note-taking, after-hours responses, and reminders shouldn’t always fall to the same people.

  • Leadership is about raising others. Hoarding work or undermining colleagues is a failure of leadership.

  • Feedback is two-way. Deliver it with care, and be open to receiving it from all directions.

  • Psychological safety is essential. Without it, feedback and collaboration break down.

  • Truth must flow up the chain. Great cultures encourage challenge, honesty, and vulnerability.

 

Bottom Line

Address people issues early.
Make feedback specific, respectful, and two-way.
Foster safety and mutual accountability.

Because if you don’t?
Dysfunction spreads—and everyone pays the price.
at No comments:

Friday, July 18

Making Work Actually... Flow

A ll Problems Are Not Created Equal 

All teams have strengths and weaknesses. All teams have skill gaps. But every team is different—and so are their problems. There will always be problems, but is better to have smaller, less debilitating problems, and you do that by resolving one issue at a time.

One common problem is story or work item size. The solution is story splitting, but that solution is both difficult and deeply unpopular.

A quick rule of thumb: if your story takes more than 20% of your iteration to complete, it’s probably too big. However that is just a rough guideline.

 
The real test is

Does your work flow like a majestic river, or does it thunk through your system like a square boulder down a gravel hill?
So:

  • QA twiddling their thumbs early in the sprint, then drowning at the end?
  • Developers getting feedback a week later and saying, “Wait, what even was this ticket?”
  • Merge conflicts that are a tangled mess?
  • Constantly re-estimating because “uh, the scope changed again…”
  • Devs tossing out code halfway through because the requirements moved (again)?

If you said yes to any of the above:  Your stories are probably too large.

 

Take Your Medicine

The team needs to split  their work items until the symptoms and the pain caused by those symptoms goes away.
If the symptoms persist then keep cutting. I once worked with a team where the size of the work items was truly ridiculous, poor decisions at the start of the project sabotaged the prospects of success.


Other Common Culprits

While oversized stories are the usual suspects, they’re are plenty of other things that can clog your system:

  • Part-time key personnel
  • Unbalanced skill sets
  • Approval bottlenecks
  • Delayed feedback

For best results the value stream needs to flow smoothly. If tasks pile up in someone’s inbox while downstream coworkers are twiddling their thumbs —then there’s a bottleneck. Remember: a pipe only flows as fast as its narrowest point.



Feedback is Oxygen

The best proof of quality isn’t a checkmark on a compliance document or test coverage—it’s a pleased customer. The longer you delay feedback, the more likely you are to ship something the customer no longer wants (or never wanted in the first place). Markets shift. New tech is adopted. Disruptive world leaders make policy changes that overturn the business environment. The customers needs evolve and the usefulness of your captured requirements decay.

At each stage the feedback loop needs to be tightened.  

Can’t release to the public yet? Cool. Release to beta users. Can’t do that? Release internally. Worst case, throw it at someone without the “curse of knowledge” and time how long they take to figure it out. If it’s more than 30 seconds, you’ve got work to do.




The Hidden Cost of Admin Bloat

Long meetings. Inefficient processes. Manual multi-step deployment ceremonies. All of it makes your team slower and more resistant to change.

When the ceremony is painful, teams start batching work just to avoid it. That seems efficient, but workflow stutters.

The consequences

  • alternating periods of idleness followed by overwork and chaos.
  • Priorities are shifted and work reorganised  to compensate for  
    • Bottlenecked Resources
    • Need for the ceremony to complete (code freeze)
    • Delayed Feedback
    • Missing Approval

Also, remember the Christmas Rule:      
Anything you only do once a year, you do badly.

So:

  • Frequent = smooth and fast
  • Infrequent = slow and broken

Want fewer errors? Do it more often

The answer?

  • Automate what can be automated
  • Have a clear, repeatable process
  • Eliminate anything that doesn’t provide value—ruthlessly


Developers: Check in Early. Check in Often.

Humans are terrible at boring, repetitive tasks. Computers are terrible at ambiguity. Delayed merges combine both in the worst possible way. And that means bugs.


Also, please don’t use GitFlow or long-lived feature branches unless you enjoy pain. They’re complexity traps.

Instead, use feature flags—and even then, only lock away the bare minimum (usually the UI). Hidden code means fewer eyes, less testing, and more risk.




Tack, Tick, Tock: Get into a Rhythm 

Here’s a simple cycle I use to keep the chaos at bay:

Tack – Set the stage

  • Prep the codebase
  • Build or improve libraries
  • Boost Developer Experience (DX)
  • Make changes without changing behavior

Tick – Build the thing

  • Add the functionality
  • Show it to a customer proxy ASAP

Tock – Make it shine

  • Refactor
  • Polish
  • Pay off debt
  • Ship it!
  • Pay off more debt if needed
 

Miss a few Tocks, and your dev velocity will slow to a crawl as technical debt accumulates and interest payments come due.

After shipping, get feedback from actual users. Based on what they say, maybe you’ll need another Tock round. Or three.


Final Takeaway

If your team’s struggling, don’t let it slide.  If the problems are left alone, they will multiply—and then you’re doing late-night hotfixes and questioning your life choices.

Instead:

  • Split big stories
  • Tighten feedback loops
  • Kill wasteful processes
  • Automate mercilessly
  • Check in often
  • Maintain a rhythm

And remember: the goal isn’t to eliminate all problems. It’s to get better problems.


Related Posts

More Information

  • Story Splitting Guide

at No comments:

Wednesday, July 16

Team Building Exercises

Rethinking Team Building: Small Habits, Big Impact

When most people think of team building, their minds jump straight to full-day off-sites or multi-day retreats. While these events can be memorable, they’re often expensive and time-consuming—and their effects may not last. In contrast, something as simple as a five-minute icebreaker at the start of a meeting or a brief gratitude exercise at the end can help foster stronger team bonds—especially when done consistently. Regular, small practices tend to build trust and connection more reliably than one-off events.

My Foundations for Team Building

Beyond icebreakers and appreciation activities, the cornerstones of my team-building approach are 

If a company doesn’t already have these two rituals in place, I make it a priority to introduce them. Remember the first 90 days sets the tone.

One of the main reasons I’m so committed to professional development sessions and regular reflection is that I have found that when they are not practiced there is something missing, a buzz, an enthusiasm, a sense shared values and purpose, that is there when I put the work in.


The Limits of Big Offsites

While immersive, longer-form events can be fun and energizing, they’re not without pitfalls:

  • One-and-done doesn’t last: Sustainable growth and culture change require regular reinforcement. A single event, no matter how great, can fade quickly without follow-up.

  • The “What happens in Vegas…” effect: People may open up in an offsite setting, but those breakthroughs often don’t translate back into their day-to-day work environment.


That said, I’ve seen long-form activities work well—especially when they’re intentionally designed for learning and engagement. Some of my go-to formats include:


  • XP Game: Drawing – A powerful way to explore the challenges of verbal-only communication (original source has unfortunately disappeared).

  • Survival Ranking Game – Great for surfacing whether group problem-solving is inclusive. If they do worse as a group than as individuals, then it is likely that the loud voices are drowning the quiet ones.

  • Ball Passing Exercise aka The Ball Point Game – A hands-on exercise for showing the dangers of overloading the team.

  • Improv Games – Lighthearted, energising, and effective for encouraging mindfulness,  adaptability, creativity and listening.

  • Crazy 8s and Brainstorming Exercises – Excellent for unlocking creativity and divergent thinking.

  • Exploratory Testing with Cards – Adds structure and spontaneity to QA or exploratory testing sessions.


Icebreakers That Work

Icebreakers don’t have to be elaborate to be effective. Some of the most powerful ones are deceptively simple:

  • “Introduce Yourself” – A classic, especially if framed with a creative twist (e.g., share your superpower or your favorite failure).

  • Two Truths and a Lie – A reliable crowd-pleaser that gets people laughing and learning about each other.

  • String Theory – One person shares a unique fact; others raise their hands if they share that trait, and the next speaker is chosen from the group with raised hands. A great way to find unexpected common ground.

I have also been known to use

  • Would You Rather…
    Pose a light-hearted “would you rather” question, like “Coffee or tea?” or “Beach or mountains?”

  • If You Could…
    Ask questions like: “If you could have any superpower, what would it be?”

  • Emoji Mood Check
    Everyone posts or says an emoji that represents their mood.

  • What Are You Listening To / Reading / Watching?
    Participants share one media item they're enjoying.

  • Gratitude Shout-Out
    You could use one the practices listed below as your ice-breaker.

 

Gratitude and Appreciation Practices

Simple rituals of appreciation can strengthen team culture and morale. Here are some ideas I’ve found effective:


  • One-Word Gratitude Check-In – Each person shares one word reflecting something they’re grateful for today.
  • “What Went Well” Reflection – Everyone shares one success and credits someone who contributed.
  • Silent Gratitude Minute – A moment of quiet reflection on people or events the team is thankful for.
  • Meeting MVP – Nominate someone who helped move the meeting or project forward.
  • Start or End on a High – Each team member shares a recent highlight or win.
  • Appreciation Shout-Outs – Open floor for informal callouts of kind or helpful actions.
  • “I Noticed...” Moments – Share specific observations about positive behaviors or contributions.
  • Appreciation Cards or E-Cards – Simple written notes that go a long way.
  • Appreciation Circle (There are a few variations)
    • Gratitude  Round-Robin – Go around the group giving thanks to others, with or without a theme.
    • Sticky Notes Shout-Outs – Quick digital or physical thank-you notes shared at once.
    • Hot Seat Appreciation – Everyone shares something they value about one chosen team member (rotate each meeting).
    • Gratitude Chain – One person gives thanks, then passes the mic or speaking totem to someone else to continue the chain.


When Team Building Backfires

Team building can give you bad outcomes —especially when it’s used to push a hidden agenda or lacks authenticity. If an exercise feels political, patronising, or performative, it can do more harm than good.

Here’s what I’ve learned:

  • If you collect feedback after a decision has been made (especially one that impacts the team), it sends a strong signal that the feedback and the feedback givers are not valued.

  • Gathering feedback before decisions—and acting on it—builds trust and invites real engagement.

Some cautionary tales:

  • A Mid-Project Retrospective Gone Awry – The team gave honest feedback, only to have it dismissed. Morale dropped immediately.

  • Scavenger Hunt Misstep – Individual contributors were assigned managers as team leaders, reinforcing hierarchy and undercutting organic leadership. It left a strong impression that leadership behaviour and initiative were not traits that the company valued or desired in Individual contributors.

  • The Company Race Debacle – The CEO contradicted the organiser’s rules during his speech at the start of the event, causing confusion and a split in participation.  

Final Thought

True team building isn’t about grand gestures—it’s about consistent habits. Done well, small, regular practices build the kind of connection and trust that flashy offsites often can’t.  

Related Posts


Further Information



at No comments:

Update

While reviewing my previous posts, I noticed quite a few broken links and images that weren’t loading properly. I’ve gone through and fixed as many of these issues as I could — thank you for your patience!

I also realized that some of the older articles were a bit too long. To make things easier to read, I’ll be breaking up similar posts into multiple parts from now on.

Finally, I have several half-finished articles that have been sitting on the back burner. I’ll be polishing them up and sharing them over the next few weeks — stay tuned!

at No comments:

Tuesday, July 15

Deliberate Practice (Part 2)

Table of Contents


 D

eliberate Practice In Software Development

The Case of the Test First Developer


So how do we deliberately practice in order to improve our programming skills?

I use the same principles that I use to improve my bass playing to improve the software I produce.

Overlooked Opportunities

I find that many developers focus too much on learning language and frameworks features. While a full understanding of the tools you are using is essential, if you simply stop there, you are missing so many opportunities for improvement. Implementation is only one phase in the software lifecycle, you should not neglect the other phases and within implementation itself there are so many dimensions that it is unlikely you will run out of things to improve even if you feel you know the implementation platform back to front.

On-the-job Learning

Within my normal work there are many opportunities to practice. To keep it fresh I will focus on different improvement goals each session. In one session I may focus on composability, in another readability in another testability. In one session I will identify and exact reusable components from existing code in another test whether a particular approach or design pattern will keep the design simple or if an alternative would be better. 

Feedback

Test first design is ideal for maximizing immediate feedback. Pair programming gives lots of potential for feedback if you take advantage of it. Code reviews are a great way of getting feedback, however so often programmers see it as an annoyance. Tightening the feedback loop by getting early feedback from testers or users can be helpful.


Learning by Teaching

Teaching others is helpful in improving your understanding of the material. Whether helping a teammate with a problem or teaching a workshop on a topic or presenting at a meetup, the need to break down what needs to be done into small easily understood steps can help your own understanding and help organize your existing knowledge.


Learning from the Pain Points

I used the need to document an existing internal API to help drive improvement to the API. For each section in the API I would ask how can I change the API so as to make this section of the documentation u6nnecessary. I ended up simplifying the API a great deal making it much easier to use.

Learning using Practice Problems

You can use code katas or code koans to help practice your programming skills and there are many sites that offer problems for you to practice (see below).  


More Information

Articles

Videos

Problems to Practice

  • Project Euler - Solve mathematical problems using programming skills
  • LeetCode - Solve coding challenges, competitions and mock interview
  • HackerRank - Offers a variety of different types of programming challenges
  • TopCoder - Solve algorithmic challenges within a time limit
  • Code Wars - Community submitted challenges and discussions
  • Code Chef - Community site with challenges, competitions and tutorials
  • CoderByte - Coding challenges and tutorials
  • Exercism - Coding challenges with assistance from mentors.
  • Sphere Online Judge - Coding challenges, competitions and discussions
  • Hacker Earth - programming challenges and  interview preparation

Programming Games

  • Codingame - program simple games then play them
  • RoboCode - program tank AIs and pit them against others
  • CodeCombat - write code to solve puzzles

at No comments: