Skip to content

Update a_shield_or_a_cudgel.mdx #283

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dwjohnston merged 1 commit into from
Jun 1, 2026
Merged

Update a_shield_or_a_cudgel.mdx #283

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/routes/posts/a_shield_or_a_cudgel.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Using the scrum model, which nobody seems to talk about any more but was very po
- to serve as an arbiter between the developers and the product owner
- to serve as an unblocker for the developers, in terms of getting access to systems/resources, making sure the developers' dependencies are fulfilled etc.

In this later sense the delivery lead is on the side of the developers. The idealised picture of this is that the developers have a clear picture of what they're trying build, and what the problem they are solving (because the product owner has done their job), they've created a plan to get there, and now they can sic the delivery lead onto whatever impediments get in their way. The delivery lead hassles whatever admin needed to approve an access request, runs interference when a different part of the organisation tries to get this team to prioritise their piece of work, and resists external stakeholders expanding the agreed scope of work.
This latter sense has delivery lead being on the side of the developers. The idealised picture of this is that the developers have a clear picture of what they're trying build, and of the problem they are solving (because the product owner has done their job), they've created a plan to get there, and now they can sic the delivery lead onto whatever impediments get in their way. The delivery lead hassles whatever admin needed to approve an access request, runs interference when a different part of the organisation tries to get this team to prioritise their piece of work, and resists external stakeholders expanding the agreed scope of work.

However, what I have seen more commonly is that the delivery lead becomes a cudgel against the developers. The reason this happens I think is obvious - the role of 'delivery lead' involves a good deal of stakeholder managment, with stakeholders outside of the feature team, and often senior stakeholders at that. It's likely a lot better for someone's professional reputation to be that person who can say 'yes' to these external stakeholders, than to resist them. It's likely also better for their own performance appraisal to be seen as someone who can be getting things done, rather than someone who is constantly saying 'no'.

Expand Down
Loading