DRAFTING
I have for a while now learned about how the mainstream deals with knowledge work glut. I was a big fan of David Allen’s Getting Sh*t Done–just kidding ;D it was Getting Things Done1. And I forget where, but I also came across the notion that all the pre-digital-era ideas to getting your sh*t together don’t apply since paper cuts are nothing compared to a digital sh*t storm. Ok enough of that bullsh*t.
While reading about these civilian approaches to knowledge work glut, I have also lived the parallel life of experiencing how the software world has been struggling with it . Most people don’t know much about “Agile” but it has been slowly spilling into the mainstream. Cal Newport sits sort of close enough to the software world that he has written, in Slow Productivity2, sort of borrowing some of the good parts of Agile, to help modern knowledge workers with their woes. I have not yet sat down with Cal’s book but I have heard him characterize the idea of the infinite work queue quite well, in his podcast. He describes that knowledge work is unlike physical work, where you do precisely what is in front of you, if you are a barista tending to customers at a coffee shop of an auto worker on the classic Ford assembly line working on cars.
Knowledge work is a special kind of hell, where if you are not careful, you will receive an endless inbox of actionable things which are only visible to you. There can be emails to respond to, reports to write and in software an endless list of issues and bugs to triage. Cal thoughtfully borrows the concept of the sprint from “Scrum” which is a flavor of “Agile”, where you make your work visible on a “sprint board”, because then you can theoretically gate your time, pointing to what you are currently doing in your “sprint” and that anything additional would need to go into a future “sprint” or otherwise would have to “bump” an in transit task, leading to a kind of messy context switch that is the killer of flow and classic waste. In principle, this sounds like a fair improvement upon the knowledge worker status quo, however it comes with a price, in that you may lose all control of your time.
Surveillance Productivity
If you are not careful, your Scrum / Agile / sprint system becomes your Kanban Cage. In principle, your time looks protected, but this constraint means that everything you do is scrutinized. The problem here is that although in theory your only job is to do what is on your “sprint board”, this is actually far from the truth. You are still spending most of your day simultaneously collaborating with your coworkers because “Scrum” is a “team sport” as they say. Depending on how senior you are, you may spend at least half of your time helping to unblock your teammates as well as your customers within your organization or outside of it, dealing with bugfixes that crop up and impact user experience.
In fact all of the responsibility of “sharpening the saw”–making your product more resilient so your users report fewer bugs or improving the quality of your internal documentation so your teammates can self-resolve their issues–falls on your back, and you basically cannot put any of this extra work into your actual “sprint board” because in practice the business will do their best to “help you prioritize” your work, which is to say “their short term work” versus your long term stability resiliency work.
Much more to say on what I see as a kind of light at the end of the tunnel. I think it starts with negotiation.
You might be in a Kanban Cage if…
If you are being asked to give a T Shirt Size to ypur Task, you might be under surveillance.
Predictability is this intriguing part of some scrum ceremonies .
You know complex tasks are not tractable yet this concept of estimation creeps in. My favorite quote on the topic,
If I knew how long this took it means I already did it so I could just give it to you.
( e.g. NP Hard Problem)
And the book No Estimates cleanly states, the simple alternative is just get good at cutting scope. Again , it is negotiation.
And the cutting skill invalidates Sunk Cost Fallacy if you do everything quickly.
So if you are doing planning and it works , it probably means youre doing widget work, which yes you have to do every once in a while, but hopefully thsts not your life otherwise exploit and no explore . (exploitative by definition ) .
The Tacit Dimension
How did we get into this mess where light hearted terms like “planning poker” are used to engage with topics around the future that we really cannot know much about.
In the realm of the unknown of what may take place in a non-widget-work project, you might really not know and thinking forwards , you can spend enough time on the hypothetical to merit actually doing the work.
But you might also enter the realm of the tacit dimension, where you may know something but you just cannot describe it well . This is also the realm of “show don’t tell”21. (requote from Cal on email 10 ), Cal quotes a known line from a michael polanyi book, The Tacit Dimension,
“I shall reconsider human knowledge by starting from the fact that we can know more than we can tell."
My coworker summarized this brilliantly also as, “planning is planning and working is working.” This also reminds me of the handy “driver” analogy I heard in this interview11,12 between Barbara Oakley and Daphne Gray Grant, about her advice on how writing is like driving a car and between your writer and editor, only one can drive the car at a time, otherwise it gets messy. And I realize similarly, Planning and working are also similarly very different and it’s almost like attempting to plan in the level of detail recommended in my first experience of PI Planning felt like attempting to mix these two. You simply can’t achieve that level of detail while you are planning and if you try, well you might as well have spent that time working.
The answer I usually get is the Eisenhower quote about about how,
“plans are worthless, but planning is everything”
but this quote feels grossly out of context because software projects are way more flexible than battle plans, but also Eisenhower’s quote literally also acknowledges that plans are worthless and yet a lot of software planning language espouses language like “commitment” and “capacity planning” and “estimates” which enter a territory of certainty that is not knowable and not necessary to know (hence “agility”).
To answer the question, I think we are here out of a very strong desire for certainty and a discomfort around not having the certainty, that maybe is difficult to shake for many.
Fisticuffs or alignment?
Martin Fowler’s blog post3 on negotiation, Product vs Engineering,
my notes: “2025-10-23_0837–0400”
Wow this is written well, says what I didnt really realize what I wanted to say, that there are basically two roadmaps, product roadmap and engineering roadmap.
But on our team, the problem is deeper that our product roadmap isn’t even for customers; it’s for the devops team. some referring to an adjacent concept of buckets also.
Our Product Team is not accurately representing the product interests , not engineering interests either. It has been no taxation without representation . As I read about PI planning, the distinction with OKR planning is that “everyone is in the room” so that the meeting represents all the interests at play.
That , lack of representation has been a problem in our OKR meetings too, wrt, top down and bottom up OKRs.
But the theory and execution of pi planning can be different.
As an example of our recent experience, what ended up happening, our plan was kind of oddly pre-populated and there was no connection to the various exploratory working sessions we were doing over the last several months. We spent time in a bit of asynchronous work, writing out sort of plans across the stories. Then people added a kind of confidence. Then under a bit of coersion and duress, even recorded ,–to sign with blood as we joked– , agree, commit , without a full review of phoenix, technical backlog, tech debt, etc.
Only “ad hoc” lip service in Pi planning might be the on-call work , which is not “tackling” tech debt at all, it is making minimum monthly payments, just fixing what broken without making it more resilient for the future.
quote,
“Us vs them”, and product leaders throwing requirements over the wall, treating engineering team as a feature factory.
quote
When product and engineering organizations aren’t communicating or collaborating effectively during product planning, we tend to see an imbalanced investment mix. This can mean the product backlog leans more heavily towards new feature development and not enough attention is directed toward paying down technical debt.
Hmm though yea im leaning more towards Shane De La Moore that this is got to be internal , precisely why PI Planning is not the fit for our team. Basically, here are the two choices: (1) either we have a fully unified team where everyone is fully represented. And perhaps we can have a board we share with product, because it is just our product. No us vs them
(2) us vs them isolation, so engineering team has its own lead and its own board and negotiates the various deliverables , and handles its own tech debt decisions etc, balancing.
Product is cool
This article goes into depth about cool ways to unify the team, get excited about product.
We are sorely missing this .This year , just mainly bending to will of the Devops dictatorship in our company , showing fealty to asks without demonstrated utility.
Outcome oriented team, vs our activity separate.
Backlog negotiation
The PI planning thing totally missed this mark. that we forgot to negotiate
epiphany reading the google swe culture book
ok I found it , https://abseil.io/resources/swe-book/html/ch05.html the chapter on tech leads and engineering managers.
ok I kind of had this intuition about the way my current company runs projects is spineless and reading a bit of this online book, I think I’m on the right track.
In my past companies , the way of getting work done is that each person would basically be part of small execution teams (2 or 3 people) and each team would just work on basically one project several days at a time. The mini teams just organically divide up the work and just collaborate super organically. And you just talk to your boss basically whenever you got super excited about something you want to show or when if you held off too long , your boss would tap on your shoulder to see what’s up haha.
Leadership by Backlog
Instead my current team does Scrum but without the negotiation. The product arm of the team is mainly a mouthpiece to the company’s Devops agenda, which our customers dont really know about and affects our ability to produce good improvements.
And without a healthy back and forth, our product arm just uses their backlog like a shield and any resistance is met with agitation .
Passive agressive is the operative word here w.r.t. the sprint backlog.
First PI Planning experience
Everyone participated hoping it would finally be a team effort, and then at the end the product arm of the team rearranges the results , sorting projects by their own preference.
That final moment was quite eye opening and the PI planning arguably pointless.
I suppose the PI Planning process enables this kind of scenario , but I understand from this video, recently, the theory and practice, can diverge a lot.
The quote was, it is like Strawberry Jam, the further it spreads, the thinner it gets.
And lead-by-backlog was not the original intent.
And I really love reading this Google SWE culture document because it reminds me of the good old days of working projects at past companies .
The stuff of Thought
One of the sort of chicken and egg questions that came up on the team, recently during the time in between the first and second PI planning sessions, is that pi planning , tries to perform a kind of exercise called “capacity planning”, filling all of the available time available.
But this means there is no time to write proposals so the team is stuck with only the ideas from the point of view of external parties. You benefit from getting proposals from all the perspectives and not just the outside looking in ones.
BYOA
Bring your own agile. If someone offers you a SAFe™ space, just say thanks but no thanks 😂. If your team has been coerced into SAFe™, then that’s already evidence your company isn’t listening to its engineering teams, so reasoning your way out is unlikely to work, but according to Thoughtworks, adoption is on the rise13, so there may be no escape soon.
I think one of the principles that the SAFe™ elephant breaks, while it runs through the agile china shop, is that it arrives especially when it is not invited. The premise of agile is that a group of people who work together will be best positioned to figure out their working pattern. And SAFe™ pi planning smuggles in a pre baked–half baked–method of gantt-charting each sprint under the promise of connecting together dependencies between multiple teams will lead to a superior result.
flip predictability on its head
why not commit to a cadence and get good at cutting slicing splitting. this is A LA No Estimates.
And instead of one sprint goal per sprint tied in , into a PI, just do OKR, which is order invariant, communicable, specific measurable and gives you room for stretch and moon too.
PI planning is like a shitty OKR.
funny in this video4, at the end the guest says PI planning is like OKRs but with everyone involved, discussing it. I think, ok well, that would be cool but why not just have the OKRs plus negotiation? PI planning has all other weirdness to it.
law of raspberry jam. further it spreads, thinner it gets 😂
Less is More
Possibly the simplest reply to all of the ceremony and rhapsody around the religion of process is to plan in small increments, and treat everything as an experiment and learning experience.
Thoughtworks captures the planning hubris with an iceberg14 as a clever analogy. And their recommendation is incremental value and experimentation.
Kant
Kant explained morality systemically, his theory, “categorical imperative”. He gave examples, one involving debt repayment. Not repaying debt out of avoiding consequence of no more loans is too self interested to be moral for Kant. He said, broadly, if no one repaid their debt, no one kept their promises, then there could be no trust.
And from the Kantian perspective I understand why PI Planning is a kind of attempt at a social agreement in company projects. There is a huge desire for certainty.
Kant did also say that humanity cannot know the true nature of reality .
multithreaded, locks vs distributed map reduce
locking is bad. Golang avoids. best use distributed, concurrent. and limit dependencies.
reduce, shuffle, are expensive
Measure what Matters not what is easy
Measuring predictability is so predictable . it is also the
McNamara_fallacy:
“the first step is to measure whatever can be easily measured. The second step is to disregard that which can’t easily be measured or given a quantitative value. The third step is to presume that what can’t be measured easily really isn’t important. The fourth step is to say that what can’t be easily measured really doesn’t exist.”
It’s also Goodhart’s Law, but this corollary, offers a motivation too.
Like in this https://michal.piekarczyk.xyz/post/2025-11-08--innovation/ innovation note, the hard stuff is just not within your grasp, but you need to offer something to your overseers.
This is also Cal’s notion of “proxy productivity” , busyness is visible, so that is what you reward.
At my place of work, folks share words of wisdom on their anniversaries and I didnt prepare this time recently, was kind of stuck, I said. Will prepare later I said. but funny opportunity came up, I was randomly mentioned that I had most commits out of others or something like that 5,000 or whatever. I responded like, umm this is not impact and that what you measure fails to become a good metric. we went to another topic. At the end I realized my wisdom if you can call it that, is dont fzll into the trap of proxy productivity, pseudo Productivity, because the good stuff typically is not noticeable but without putting your head down, you will just be busy. waving your arms around. Funny , my skip level interpret what I said as “big picyure thinking " which is important too but kind of missed the point, being, big picture doing !
That being said, “building in public” is great too, blasting out legit artifacts , but not just git commits haha 😆. Someone else was saying she wants a prize for the number of meetings she attends. Indeed.
the way things were
Before pi planning hit our shores, inviting itself in, we planned by everyone putting what theu were excited about into a big group writable table and everyone with equal votes , voted. then we ranked. thats what ir was . that was great
Dont Defer thinking
You shouldnt defer thinking about what problems to solve to your product team any more than you should defer design choices to your AI LLM tool of choice.
(Last bit inspired by https://youtu.be/eIoohUmYpGI )
What would a Nobel Laureate say?
I recently made this discovery that Daniel Kahneman wrote about planning in his Thinking Fast and Slow17, discusing it as, the planning fallacy18. And the reason why I looked was because one of my skip level managers has mentioned he is a fan of Kahneman’s book many times and he is also a big fan of PI Planning, so I was curious to look into this to maybe understand the connection better.
(As an aside, although Kahneman discusses the topic in his 2011 book, actually the planning fallacy wiki18 cites his work with Amos Tversky presenting the idea back in 1979, though later in 2003, Lovallo and Kahneman added the benefit shortfall as a secondary consequence of the fallacy. Researchers have been adding empirical evidence to make the theory more quantitative ever since).
My manager here, quotes Eisenhower too often, “all plans fail but planning is everything,” so I knew Kahneman’s point would probably be more nuanced.
So I learned that in his planning fallacy chapter, Kahneman relates to an anecdote of when he was involved in helping to build a course and the people involved estimated it would take two years, three years tops. He asked them to dig around to get some data about what comparable efforts took. He learned, from them, that of the 50% efforts they looked at that didnt fail, they took over 8 years and even some over 10 years. But then asking them how will they use this information to revise their plans, and well, they didnt. And ultimately the course also took into the same ballpark , of 8 years.
Kahneman uses the anecdote to say that planning is good if by planning you mean looking at reference data of past projects to inform your estimation effort. This is what he calls the “outside view”. Otherwise you are just basing your planning on your own biased narrative, your own optimism, with your blindspots. This is what he calls sticking to the “inside view”. So I realized PI Planning, at least the way our organization is utilizing it, has no view of reference data. So the baby is gone and all we have left is the bath water. (I can’t speak for PI Planning in general but I hope the SAFe proponents of it do actually advocate for the “outside view”). So why do all the people I know in my organization who love planning end up with planning theatre? And here we see Kahneman has the explanation as well, as the other parts of his book–which I should get more familiar with since it sounds helpful!–, deal with thinking fast, your System 1 thinking that is, and here you have your rituals and ceremonies and feeling special that you can ignore all of historical data because you are special and you got this, go get em tiger!
Yuppies vs Hippies
Hopefully we don’t have to whip out a horoscope but researchers have also looked at generational differences [20].
There are many competing ethea (aka ethoses ), about getting from point A to point B
Hopefully this collection is representative .
“Fake it til you make it” -?
“Underpromise and overdeliver” -?
“There is no try, there is only do” -Yoda
“80% of life is showing up” -Woody Allen
“Everyone has a plan until they get punched in the face” -Tyson
“If You’re Gonna Be Dumb, You Gotta Be Tough” -Roger Alan Wade
“It ain’t over till it’s over” -Yogi Berra
“Just get sh$t done”
“It is possible to commit no mistakes and still lose. That is not weakness; that is life.” -Jean‑Luc Picard
“Slow is smooth, and smooth is fast.” -military, anonymous
“Think slow and move fast” (reverberates the military quote, but comes from riff off Kahneman’s book)
“Shut up and calculate” -Feynman
“measure twice, cut once”
“Move fast and break things” -early Facebook mantra?
“The path is the goal” -zen saying
“Show don’t tell” -many sources21
Bullshit jobs
[22] ultimately have to really realize pi planning as much as nobel prize wining thinkers like Kahneman would criticize it, it is likely hefe to stay because theres just too many bullshit jobs that partycipate in the ceremony of planning theatre.
What happened after our second attempt at pi planning
This time around we wanted to prepare better, instead of being caught by surprise. Indeed fool me once shame on me. So second time around the team put together their initiatives in a clean way on a spreadsheet and everyone voted on initiatives. (Well the product team refused to participate in the voting and perhaps that was a red flag.)
However after we started putting together the verbage for our initiatives, we almost accidentally learned that our upper management already held their roadmap prioritization meeting and so essentially our initiatives would yet again be at the bottom of the pile.
And once again during our pi planning session, the capacity planning exercise threw out all of the initiatives the team came up with internally.
The team scrambled together to try to de-scope the top down initiatives to desperately try to make some “official” breathing room for some smidgens of internal work.
I’m writing this particular bit on a Saturday after just fixing a production issue related to some tech debt we didn’t get a chance to address earlier. My lesson yet again is that if the system you use in your team or company is rigged so the house always wins, you can’t win by playing the house rules by definition–tautologically speaking. The house in this case insists you only work on what it asks you to work on, but if you want the product that the team is building to be successful, you need to incorporate all the sharpening-the-saw activities as well, paying down the tech debt as early as possible, and pay attention to all the best ideas, regardless of where they come from (And chances are the best ideas will come from a mix of both top down and bottom up initiatives). But if the house wants your work to be visible, so it can look over your shoulder to see that you are only doing what was asked of you, then that is the essence of the Kanban Cage. You have no choice but to work outside the system.
Maybe the analogy of the shadow economy is appropriate here ? Why is there a shadow economy. Maybe there is an economics answer to some of these problems in knowledge work?
Alex Honnold and Kind vs Wicked Problems
In the David Epstein book Range, he contrasts problems which are static vs those that are dynamic. Alex Honnold even thinkinh about solo-ing Yosemite ’s El Capitan gave him the chills for years –even though he has less inhibition that most do. But mountain climbing on a day of your choice has little to no unknowns. And Honnold rationalizes performing the solo ultimately by meticulously planning and sort of memorizing every hold, by rope climbing dozens of times first.
I was in a grungy Virginia hotel room during the 2024 Olympics in France. Everyone talks about the ecoli water in the Sein but in that hotel room I remember watching the sprint climbing events. Everypne climbs sort of the same style and importantly exactly the same course. And milliseconds are what separate gold from silver. There is zero risk of death.
Summary of my points
- As the Martin Fowler blog puts it, a team Backlog is a mix of product and engineering priorities. Product looks at the user perspective, and Engineering looks at stability, reliability, maintainability and all the other -ilities.
- All the team members will wear the Product and Engineering hats , some might lean one way more than the other.
- There might be other external pressures other than Product or Engineering that put thumbs on the scale as well, call it Corporate. Corporate doesnt represent either user interests or engineering interests. But they are the HIPPO so you will hear them
- The Corporate opinion for example: lets measure proxy productivity, in lieu of value because is hard to measure
- Predictability is a typical measure of proxy productivity
- The process of PI planning is a negotiation, where all parties state their positions and bid for the time of the individual contributors
- At the end of the day , there is room to be excited about what the team is up to and can unify behind.
References
Getting Things Done, David Allen
Slow Productivity
Martin Fowler’s blog https://martinfowler.com/articles/bottlenecks-of-scaleups/03-product-v-engineering.html
https://youtu.be/jHRsBDC5E9Q , Yuval Yeret and Ryan Ripley, “Breaking the SAFe™: Deconstructing PI Planning”
Extreme Gohorse
Cal Newport and Adam Grant, https://link.chtbl.com/4HaHYkSm
https://michal.piekarczyk.xyz/post/2025-06-04-fragile/ x. https://en.wikipedia.org/wiki/McNamara_fallacy
…. north star concept
why can’t ai manage my email , Cal Newport , New Yorker
my description about writing brain , https://michal.piekarczyk.xyz/post/2023-09-10-summary-learning-how-to-learn-coursera/#if-your-inner-writing-brain-and-editing-brain-are-in-the-same-car-only-one-can-drive-at-any-one-time-
learning how to learn , https://www.coursera.org/learn/learning-how-to-learn
top down and bottom up OKRs,
other meaning of topdown, https://open.spotify.com/track/17MK2u7iHFpNb3tPuJnUdw?si=P0q6ooVVTBiRYMAyT9L9ng from Channel Tres
Thinking Fast and Slow
https://michal.piekarczyk.xyz/post/2025-06-04-fragile/ , discussing Robert “Uncle Bob” Martin Clean Agile
https://www.sciencedirect.com/science/article/abs/pii/S0191886906002194?via%3Dihub , “On the distinction between yuppies and hippies: Individual differences in prediction biases for planning future tasks”
bullshit jobs article, book
https://www.nutrient.io/blog/what-ive-learned-about-product-iteration-planning-while-building-sdks/ prioritization article