#deliverymanagement — Public Fediverse posts on home.social

James King @[email protected] · 2026-08-28 · 02:28 UTC

Pondering invisible bottlenecks and delays

Looking for a job is different to working in an organisations with many teams.

For one thing looking for a job is more boring than having a job. For another thing, my side of the job matching is visible, while the “hiring person” side is basically invisible.

I can see if I look at a role and then postpone applying and even though a day might slide by, I can see that the bottle next was me. I cannot see whether someone read my resume or discussed it internally or much of anything else.

This impacted my “quick cycle times lead to quick learning” because I can fire off a resume and hear nothing back, or I can hear back a couple of weeks later. So I improve my online profile and the information I submit for jobs with no feedback from real customers.

That is the opposite of continuous discovery and good product management but is also a factor of the constraints of my current market. Of course calling it a market when I have one product (me or the services I can offer) and a few potential hirers is probably a stretch, but the principles of product management apply.

I could innovate with the product by offering to work as an interim executive, a volunteer, a part-timer, a contract or permanent. I could add features to my offering by doing a course in governance or learning to be a hit man. I could do a lot to tweak what is on offer and I should prioritise that.

Interim executive is a good idea, governance training will not likely improve my time to the next role but it would add value in the long run. Hit-man qualifications are probably not going to enhance the value of a delivery manager, unless I change my target market to “illegal mafia like organisations and international espionage”.

What I was thinking though – is that nearly everything on my side is visible to me and that is a real luxury compared to working as part of a system.

Even the invisible bits can be tackled. If I want to improve my resume I can fire it off to many organisations and hear nothing, or I could share it with friends who work in the industry and get real feedback from these “proxies for the customer”, because they, like I, have hired for similar roles that I would apply for.

But in a real job, you often wait for feedback, wait for permission, wait for work to get done and generally depend on others. In this situation you can get really busy, but the activity will not move things along if you are waiting for some input or decision.

So you get good at managing dependencies, stakeholders and change. It is a real skill that comes with experience but can almost be invisible.

Of course you can “get good” at managing dependencies by harassing people mercilessly, but that strategy is both less fun and less effective than it sounds.

On TV, leaders are often very demanding and they get all the resources they need because they demand them. They also tackle drama head on and keep moving at a pace that keeps the audience engaged.

In the real world, asking for people to swarm onto your dependency is less likely to succeed when there are many more dependencies for them to manage, with their own dependencies to manage and many more annoying stakeholders asking for urgent attention.

So a real skill is to know when focusing on something will increase the speed and quality and when it is better to let things take their course.

I guess that seems like a vague statement, but they say you don’t appreciate something until you miss it or lose it. In this case I think I don’t see the challenge until I am in a simpler environment with few dependencies and a product I build myself without needing much negotiation with others.

So sitting hear next to the trees in my backyard, I can operate at my own sustainable pace. But the real thing I realise is that in a complex working environment, not everything is visible and the lack of that visibility has a real impact.

It is quite easy to “see” a bottleneck and focus on it. But generally you are seeing the symptom of a bottleneck and not the real cause, or sometimes not even the real bottleneck.

For example, at my last company, code reviews took a long time. So doing faster code reviews with AI would seem like a good idea. But in fact it was not the time spent on the code review that was an issue, it was the scarcity of experienced people who understood the code.

So getting more people experienced with the code seems like a good idea and it probably is.

But there are a couple of problems with that. Firstly the desire to use a tool or process to fix things – “Use AI to make it faster” – can actually be a distraction. Getting people to pull experienced technical people into meetings to decide whether to make AI code reviews better makes them more scarce on the ground. Doing that might cause them to take longer to go to a code review and make it harder to find time to mentor others to increase the people who can review code.

Of course, using AI to improve code reviews is the way to go and things like telemetry and automated checking will improve both quality and time spent on manual reviews. But it won’t in itself make senior staff more available.

So what might make the crew more available is better delegation, better decisions rights or more focused discussions when the crew do get together.

But then, what if the problem is not just scarcity of gurus? And what if the improvement or decay in our cycle time is the result of a change we made a month or two ago.

Guru scarcity will increase if we have a lot of turn-over but should reduce over time if we have stable teams and good senior staff who spend time coaching others. Even having people fix bugs will add to their understanding and reduce the overhead of code reviews. So we could see improvements now that are the result of one good tech lead creating stability in the team because people enjoy learning from her.

That change occurred a while ago, then people realised and then their skill increased and then we saw the improvement. Similarly the use of AI in code reviews might initially not have a visible impact and then a few weeks later it might be having a massive impact, but people are not mentioning it because it is obvious.

Or the code reviews are taking a long time because in fact the engineer was making “dumb assumptions” because they did not understand the way the customer used the product and the guru sent them back to ask questions of the PO and then make changes. If this happens then the delay in code reviews happens twice every story (or code package). And it might be the result of poor information coming into the team, which is fixed by neither the use of AI or the increased availability of coding gurus.

So I guess the conclusion is that, while AI is revolutionising the way we build products, there are skills and attitudes that still matter a lot. And the more complex the environment the more they matter.

The problem is though, the same as it was a hundred years ago. People fix and improve what they see and when they see a change they often assume that they understand the cause, when they are only looking at a symptom.

I don’t think I can put “take time to notice things and has a knack for finding invisible stuff” on my resume.

But I can say that it is a requirement of many senior product and engineering roles. It is part of the joy of the work and also part of the invisible value that motivated and experienced people can add.

So if it is not a resume thing, what is it?

Some of it is boring process and habit management. Making things visible, being transparent and looking at the system are all ways that uncover previously invisible delays and bottlenecks.

Part of it is also curiousity. There is an Irish saying, or at least a saying I was told is Irish – “If you fall over, don’t look where you landed, look back at what caused you to trip”.

We could say that it is moving upstream or shifting left, but it is really as simple as remaining curious. Instead of acting on the symptom you see, you pause and ask how it came about.

More often than not, the slow moving tech lead who is not getting to code reviews is not actually a slow moving tech lead not bothering to look at code. It is a person in a system with many forces creating the existing situation.

And the better you get at finding where the hidden things are the better. It is often the time to make a decision that delays the implementation. It is often the distraction and not the work itself that is a delay. And it is often a lack of access to the right information or resources that causes the delay and the rework.

That kind of sounds obvious when you sit back next to a tree and ponder. But the art comes in paying attention and creating space to notice and ponder things when being pulled in 20 different decisions while multiple important things compete for attention.

`

#ai #artificialIntelligence #chatgpt #deliveryManagement #leadership #llm #presence #productManagement #technology

#ai #artificialintelligence #chatgpt #deliverymanagement #leadership #llm

James Arthur Cattell @[email protected] · 2025-04-02 · 15:40 UTC

Public sector delivery managers!

Set yourself an alarm for 1055 Tuesday 8 April, as the last 80 DeliverCon tickets will be released 5 minutes later!

https://lu.ma/xm4sg0dc

Our May event in York is gonna be awesome 🤓

#deliverymanager #deliverymanagement #publicsector #unconference

James Arthur Cattell @[email protected] · 2025-03-31 · 13:41 UTC

I'm re-reading, "The 2020 Scrum Guide" https://scrumguides.org/scrum-guide.html by Jeff Sutherland and Ken Schwaber.

#agile #scrum #deliverymanager #deliverymanagement

James Arthur Cattell @[email protected] · 2025-03-30 · 00:07 UTC

I'm reading, "This is Lean: resolving the efficiency paradox" https://read.amazon.co.uk/kp/kshare?asin=B00JZZS7Q0&id=amjvkujeyzeoxpmlp2f5nskz7i by Niklas Modig and Pär Åhlström, published November 2012.

#lean #deliveymanager #deliverymanagement

James Arthur Cattell @[email protected] · 2025-03-27 · 10:52 UTC

Q: How does the term "risk management" make you feel, please?

#deliverymanager #deliverymanagement

James Arthur Cattell @[email protected] · 2024-06-27 · 07:51 UTC

I'm reading, "Senior Delivery Manager (Ref:87948)" https://www.civilservicejobs.service.gov.uk/csr/jobs.cgi?jcode=1914045 by Justice Digital in the Ministry of Justice UK, part of the UK Civil Service.

#agile #delivery #deliverymanagement #deliverymgmt

#job #jobs #jobsearch

#agile #delivery #deliverymanagement #deliverymgmt #job #jobs