From 8fab965253af2abb97dd31fb5394a5f201363441 Mon Sep 17 00:00:00 2001 From: David Johnston Date: Sun, 31 May 2026 15:10:35 +1000 Subject: [PATCH 1/2] Draft --- src/routes/posts/a_shield_or_a_cudgel.mdx | 29 +++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 src/routes/posts/a_shield_or_a_cudgel.mdx diff --git a/src/routes/posts/a_shield_or_a_cudgel.mdx b/src/routes/posts/a_shield_or_a_cudgel.mdx new file mode 100644 index 0000000..372784a --- /dev/null +++ b/src/routes/posts/a_shield_or_a_cudgel.mdx @@ -0,0 +1,29 @@ +--- +meta: + title: A shield or a cudgel? + description: A dynamic I frequently observe is the project manager becomes a cudgel against their team members, rather than serving to project them from the rest of the organisation. + dateCreated: 2026-05-31 + +tags: + - "software_engineering" + +--- + +The dev ops and shift-left movement, that was at its zenith around 2015-2019 in my experience popularised this concept of feature teams, or product verticals, fully owning their part of the application. + +Typically these teams will have at least one person whose job title is something like 'product manager', 'project manager', 'product owner', 'delivery lead', 'scrum master' or 'team lead'. Note it's common that these are two roles - and when this happens the split is typically a 'product owner', who is a bit more technical, they're looking at RUM dashboards, interviewing users etc, and from that deterimining the work to be done, and a 'delivery lead' whose focus is more on timelines, resourcing, dependencies on other teams etc. + +Using the scrum model, which nobody seems to talk about any more, but was very popular when I started my career in 2013, the 'delivery lead' type role is the role that most closely approximates a 'scrum master' - and two of their key roles are: +- 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 fufillied etc. + +In this later sense the 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 what ever 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 pretty obvious. The role of 'delivery lead' involves a good deal of stakeholder manager, with stakeholders outside of 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 be resisting 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 is constantly saying 'no'. + +This leaves the developers in a shitty situtation - they're being told that the delivery lead is the person that can help them get their job done, while that delivery lead becomes the very source of external pressure. + +This is a psychologically unsafe environment for the developer - it might not be wise for the developer be candid with the delivery lead about their estimates of delivery times and risks, because then delivery lead becomes the person who is going to take away their wiggle room to accomodate an external request. + +Being a software developer is a difficult enough occupation - if a developer doesn't have someone who is serving as their advocate to resist external organisational pressure, then that job falls on the developer's shoulders and occupies mental (and time!) that could be better spent actually building products. + From 69d31f0e5c830cecc6889b705ee791a3168776db Mon Sep 17 00:00:00 2001 From: David Johnston Date: Sun, 31 May 2026 18:17:33 +1000 Subject: [PATCH 2/2] Fixes --- src/routes/posts/a_shield_or_a_cudgel.mdx | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/routes/posts/a_shield_or_a_cudgel.mdx b/src/routes/posts/a_shield_or_a_cudgel.mdx index 372784a..7e036f9 100644 --- a/src/routes/posts/a_shield_or_a_cudgel.mdx +++ b/src/routes/posts/a_shield_or_a_cudgel.mdx @@ -1,7 +1,7 @@ --- meta: title: A shield or a cudgel? - description: A dynamic I frequently observe is the project manager becomes a cudgel against their team members, rather than serving to project them from the rest of the organisation. + description: A dynamic I frequently observe is that the project manager becomes a cudgel against their team members, rather than serving to protect them from the rest of the organisation. dateCreated: 2026-05-31 tags: @@ -9,21 +9,21 @@ tags: --- -The dev ops and shift-left movement, that was at its zenith around 2015-2019 in my experience popularised this concept of feature teams, or product verticals, fully owning their part of the application. +The DevOps and shift-left movement, that, in my experience, was at its zenith around 2015-2019, popularised the concept of feature teams fully owning their part of the application. -Typically these teams will have at least one person whose job title is something like 'product manager', 'project manager', 'product owner', 'delivery lead', 'scrum master' or 'team lead'. Note it's common that these are two roles - and when this happens the split is typically a 'product owner', who is a bit more technical, they're looking at RUM dashboards, interviewing users etc, and from that deterimining the work to be done, and a 'delivery lead' whose focus is more on timelines, resourcing, dependencies on other teams etc. +Typically these teams will have at least one person whose job title is something like 'product manager', 'project manager', 'product owner', 'delivery lead', 'scrum master' or 'team lead'. Note that it's common that these are two roles - and when this happens the split is typically a 'product owner', who is a bit more technical, they're looking at RUM dashboards, interviewing users etc, and from that determining the work to be done, and a 'delivery lead' whose focus is more on timelines, resourcing, dependencies on other teams etc. -Using the scrum model, which nobody seems to talk about any more, but was very popular when I started my career in 2013, the 'delivery lead' type role is the role that most closely approximates a 'scrum master' - and two of their key roles are: +Using the scrum model, which nobody seems to talk about any more but was very popular when I started my career in 2013, the 'delivery lead' type role is the role that most closely approximates a 'scrum master' - and two of their key roles are: - 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 fufillied etc. +- 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 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 what ever 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. +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. -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 pretty obvious. The role of 'delivery lead' involves a good deal of stakeholder manager, with stakeholders outside of 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 be resisting 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 is constantly saying 'no'. +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'. -This leaves the developers in a shitty situtation - they're being told that the delivery lead is the person that can help them get their job done, while that delivery lead becomes the very source of external pressure. +This leaves the developers in a shitty situation - they're being told that the delivery lead is the person that can help them get their job done, while that delivery lead becomes the very source of external pressure. -This is a psychologically unsafe environment for the developer - it might not be wise for the developer be candid with the delivery lead about their estimates of delivery times and risks, because then delivery lead becomes the person who is going to take away their wiggle room to accomodate an external request. +This is a psychologically unsafe environment for the developer - it might not be wise for the developer to be candid with the delivery lead about their estimates of delivery times and risks, because then the delivery lead becomes the person who is going to take away their wiggle room to accommodate an external request. -Being a software developer is a difficult enough occupation - if a developer doesn't have someone who is serving as their advocate to resist external organisational pressure, then that job falls on the developer's shoulders and occupies mental (and time!) that could be better spent actually building products. +Being a software developer is a difficult enough occupation - if a developer doesn't have someone who is serving as their advocate to resist external organisational pressure, then that job falls on the developer's shoulders and occupies mental bandwidth (and time!) that could be better spent actually building products.