Tuesday, January 24

Never Ask for Feedback You are Not Willing to Listen to

W

hen you ask for feedback, you’re not just gathering opinions—you’re making a implicit promise to listen and think about the feedback . The person giving it needs to feel heard. That doesn’t mean you have to do exactly what they say, but you do have to respond with honesty, humility, and genuine respect. If you can’t act on it, explain why—openly and without defensiveness.

Some people dismiss this as “touchy-feely.” Don’t. If you get it wrong, the fallout can be ugly.

The Day Feedback Went Spectacularly Wrong

At a previous company, I sat in an open-plan office where my team shared space with another group I’ll call Team Marmalade, the where working on Project Indigo. They were a constant source of vicarious learning—and sometimes cautionary tales.

Most managers, when they need to discuss sensitive topics, book a private meeting room. It’s quieter, more focused, and free from an audience. For reasons only he knew, Team Marmalade’s manager decided to skip the boardroom and hold an important meeting right in the middle of the cubicles. I heard everything. So did the entire office. And by the end, I suspect he wished no one had.I suspect he wished no one had.

Most managers when talking to their team about important and Most managers, when discussing important or sensitive topics with their teams, book a boardroom. These rooms are quiet, private, and free of interruptions. For reasons only he knew, Team Marmalade’s manager decided to hold an important meeting right in the middle of the cubicles. I heard everything. The entire office heard everything. And unfortunately, so did his team. Normally, it’s a good thing when a team hears their manager. But by the end of this particular meeting, the manager likely wished everyone would just forget it had ever happened.

The meeting began reasonably enough. The manager explained that the team’s process wasn’t working, results were slipping, and change was needed. He then invited the team to share ideas.

They did—enthusiastically. They identified problems, proposed fixes, and mapped out ways to boost productivity. The suggestions were clear, practical, and—if implemented—would have solved much of what he’d raised.

But with each idea, the manager’s expression grew more and more alarmed. Eventually, he cut them off:

“I can’t tell upper management any of this. We’ll just have to stick with what we were doing.”

 

The Downward Spiral

Morale dropped like a stone. Productivity followed.

A few weeks later, the team leader (not the manager) managed to lift spirits through… let’s say creative morale-boosting tactics. They might have worked if results had soared. They didn’t. The team’s output improved slightly but never reached even the low levels from before the “feedback incident.”

Worse, the team’s attitude shifted. On the surface, they seemed fine. Underneath, they were frustrated, angry, and disengaged. Nothing had really been forgiven—or forgotten.

Then one day, while the manager was offsite and the team leader’s “creative” tactics were in full swing, upper management walked in. The scolding was loud, public, and humiliating.

And still—had all the managers forgotten meeting rooms existed?

Morale collapsed again. So did productivity. This time, recovery took months. 

And this time, it took a long time for Team Marmalade to recover.

This isn’t the only time I’ve seen a request for feedback go wrong—but it was definitely the worst.

If you don’t treat feedback with respect, those giving it can become cynical, resentful, and disengaged. By the time you’re ready to take action, your team or community may no longer care to listen.


The Lesson

I’ve seen feedback requests go wrong before, but this one was catastrophic.

If you ask for input but then ignore, dismiss, or shut it down, you teach people that speaking up is pointless. Cynicism sets in. Engagement erodes. And when you are finally ready to make changes, it may be too late—because the people you need have stopped caring.


Related Posts



Monday, January 23

Lessons from Project Indigo: A Slow-Motion Train Wreck

M

y boss called me into his office and asked if I thought Project Indigo could be completed on time.

Strange question. My opinion on Indigo’s feasibility was no secret — I’d told him more than once. Indigo was due to start the next business day. Was he having last-minute doubts? Or wondering if I’d make trouble with his superiors or the new hires?

It felt like being dropped into an Asch conformity experiment. I had estimated Indigo would take five years with a team of seven. The other senior developer and the project manager? Nine months with a team of five.

Even my five-year figure was generous, thanks to the anchoring effect. Every shred of my experience told me it was a multi-year slog, yet surrounded by confident people quoting nine months, I began to doubt myself.



Mistake #1 – The Compromise Trap

Under my boss’s gaze, I suggested a “compromise”: the PM’s detailed schedule said the first module would be done in a month. If we measured progress after that month, we’d know how long the whole thing would take.

That was my first mistake. The problem wasn’t a lack of evidence — Indigo was a reboot of a project that had already failed once. We knew exactly how long it would take.

If my boss was looking for a reason to kill the project, I’d just blown my best chance. Or maybe he only wanted to know if I’d be a “team player.” In a company as internally competitive as ours, that wasn’t paranoia — just experience talking.


Mistake #2 – Not Locking in a Review

I also failed to set a firm, calendar-booked review meeting with clear evaluation criteria. If it’s not scheduled then and there, it won’t happen.

Later, I learned to make post-spike reviews non-negotiable. They led to pivots in some projects and smaller, life-saving adjustments in others.

Still, my partial resistance paid off: the PM and other senior dev ran Indigo, while I stayed on Project Teal — the project Indigo was supposed to replace. Perfect spot: close enough to watch the train wreck, far enough to avoid the flames. 


Month One – Nothing Done

After a month, I checked the tracker: zero completed stories. The PM insisted they were on track because they’d “partially completed many stories.”

I pointed out that partially completed work is impossible to measure reliably. He said his “years of experience” told him they’d make the deadline.

I told my boss it wasn’t going well. He said it was “early days” and he trusted the PM. 


Year One – Still Nothing Through QA

A year in, not a single story had passed QA. Some tasks had passed QA, but tasks aren’t supposed to be tested alone — they’re part of stories. 

Indigo’s stories were massive. In fact, stories were functioning like epics, and tasks were functioning like stories. The estimates? Pre-determined before anyone started.

Using completed tasks (gappy though they were), I built a chart showing Indigo would take eight years. My boss dismissed it: “We’ve learned a lot, we’ll do better this year.” When I asked how long he thought it would take, he didn’t answer.

By this point, canceling the project would have been too embarrassing. I don’t think anyone expected to meet the deadline. They wanted the project approved and assumed “few months” of overrun would be fine. It turned into years.


Year Two – Scope Games

Real scope dropped (low-priority features cut), but on paper scope increased as hidden work surfaced. New stories were added.

Management panicked: No more new stories. No more splitting stories.
This, of course, made stories even bigger and harder to push through QA.


Year Three – Reality Check (Sort of)

Management reversed course: Split stories, re-estimate to real values. The backlog improved, but stories were still too big. QA remained a bottleneck, and the backlog kept growing.

The PM was now flying in from interstate every two weeks, reputation on the line, venting to anyone who’d listen. The original team, except him, was gone.


The Endgame

I left for greener pastures.

Years later, over coffee, the final Indigo team lead told me the ending:

  • Year 5: A prototype was shown to beta customers. They hated it.

  • Year 6: Project Indigo was canceled. The dev team was laid off.

My former boss had been right — there was a lot to learn from Indigo. Unfortunately, the lessons didn’t stop after Year One.


Final Thoughts

Most of Indigo's problems I have seen to a lesser extent in other projects. However the words "lesser extent" are doing a whole lot of work in the previous sentence. 

There was one difference that was a difference of kind rather than a difference of scale, one mistake that doomed Indigo from the very start. A mistake that caused many of the other problems.


Mistake #0 – Letting Politics Determine Estimates

There were other projects were I was pressured to reduce my estimates, as if re-estimating would change the real completion time. There was only one project that I have ever been on where I was given the estimate I was supposed to come up with before hand.   


Related Posts

More Information

Article

Videos




Saturday, January 21

Learning Plans for 2023

C

urrent Focus Topics

Focus People Tasks
Abstract Communication,
Coaching &            
Leadership
Category Theory,
Abstract Algebra & 
Lambda Calculus
Concrete Reducing Stress &
Refocusing
the Mind

Swift



Changes for 2023

I am currently spreading myself to thin between to many study topics. For the upcoming year I intend to slowly finish up many of the topics and narrow my focus.



Category Theory

I feel that am pretty much done with Category TheoryAbstract Algebra  &  Lambda Calculus. I will experiment  more with practical applications of the theory, and some of the functional swift libraries then close the topic off in March with some final revision. I have been building up an Anki flash card deck which I will share. I won't replace this topic with another. I will leave that quadrant blank for now.



Leadership

I worked my way though a large chunk the courses and books I had earmarked for these topics and I am also applying that knowledge. I am going to finish Communication & Leadership in June and Coaching in October.  I intend to study creative writing in 2024. 



Wellbeing 

I am going continue on with this. The only changes I am making from last year is to alternate my exercise routines and restart my music practise.


Swift

There is still a lot I want to do in this area, so this one will be keeping me busy.


Related Posts

Related Artefacts

Thursday, January 19

Learning Outcomes for 2022

F

ocus Topics for 2021

Focus People Tasks
Abstract Learn to Learn Category Theory & Lambda Calculus
Concrete Reducing Stress & Refocusing the Mind JavaScript & Knockout


Changes for 2022

In the second half of 2021, I changed jobs. As a result, JavaScript became less relevant, and Swift took its place as the main language in my new role. I also felt that I had internalized the principles of "Learning to Learn" well enough to move on. I replaced it with a new focus on leadership and communication.


Wellbeing remained a priority—I carried it forward into 2022. My progress in category theory during 2021 was limited, so I decided to continue that journey.


New Focus Topics for 2022


Focus People Tasks
Abstract Communication,
Coaching &            
Leadership
Category Theory,
Abstract Algebra & 
Lambda Calculus
Concrete Reducing Stress &
Refocusing
the Mind

Swift



Category Theory

In 2022, I leaned heavily into category theory—perhaps too heavily. I often found myself caught in a web of unfamiliar mathematical concepts. Still, I managed to lift my understanding from a shaky beginner level to a more solid intermediate grasp.


Along the way, I was repeatedly told that category theory becomes easier with a foundation in abstract algebra, so I added that to my learning path. Most of the examples I encountered were written in Haskell, so I started exploring that as well.


Translating theory into practice proved difficult. Swift incorporates many category-theoretic ideas—optionals, sequences, throwing contexts, and concurrent contexts are all monads in disguise—but it doesn’t present them in a unified way. Without the theoretical background, the common structure is easy to miss.


Moreover, Swift lacks support for higher-kinded types, which makes it hard to generalize over these abstractions. While libraries like Bow attempt to bridge this gap and simulate higher-kinded types, I didn’t explore them deeply. That may be something for 2023. 


Leadership

Despite category theory dominating my attention, I did make progress here too. I even found opportunities to apply what I learned at work.

In truth, many of these leadership activities were natural extensions of things I’d already been doing—or things I had started back in 2021 under my “Learning to Learn” focus. Still, I felt a shift in intent: I was deliberately developing leadership skills, rather than just picking them up incidentally.


Wellbeing 

For the most part, I maintained the wellbeing routines I had developed in 2021. However, stress and insomnia began creeping back in. I suspect this was due to letting my music practice lapse.

While exercise and mindfulness helped, they weren’t quite enough. Playing an instrument has always been my most effective way to decompress, and reset. Without it, my stress levels noticeably increased.



Swift

Swift remains a fast-moving target. Each year, Apple updates Swift itself along with Xcode, iOS, macOS, watchOS, and tvOS—not to mention a growing ecosystem of libraries and APIs.

While I learned a lot in 2022, I still feel like I’m only scratching the surface. I’m even still working through videos from the previous WWDC. It’s a marathon, not a sprint.

Conclusion

All up I was less effective in converting my learning into day to day behaviour change in 2022 than I was in 2021. But I still made some good progress.