Do you think it is a reasonable expectation to know what every team in the company is working on, and to ask them to use the same system for tracking work?
I'm thoughtful about how to track activity outside of a product context. I work in a team of OD consultants within a large, public-sector organisation in the UK.
The issue is that outputs aren't always clear. For some people their activity on a given project today would be recorded as "attend a regular meeting and assure the business's decisions". For others it might be "prepare a deck and get the business to make a call about what to do". Both of those are technically valid, value-creating activities - but only one of them is tangible.
I'd like to move towards a system where everyone can articulate what role they're playing in a given meeting. I wonder if the Viable System Model might be useful here: so if asked, people can say "I'm here providing internal control (system 2)" or "I'm here providing horizon scanning (system 4)" and then we can determine whether it's worth having someone deployed there. It's still subjective, but a little closer to helping us understand what adds value.
I'd welcome your thoughts on this. It seems like we're failing at a system level here. There are definitely some people in our team who are delivering less meaningful work, and being less effective within their roles - but they fall through the gaps, because their failings are masked by the big-ticket items that other consultants are delivering, which are tangible and impactful.
Thanks as ever - your writing and thinking is always appreciated, and I'm grateful for the time you take to articulate and share it.
The "chart" is a perfect description of all the things that happen and with good intentions pave the road to hell.
The awesome thing is that a new Agile Coach or ScrumMaster, whatever, coming in often has some upfront credit. If that person is me, that person usually immediately tells teams to stop caring about the vicious cycle enforcing BS and focus on what matters.
They then ask "But what about XYZ? We'll be penalized if we don't do XYZ!"
My response: "Blame it on me. Don't even discuss it. Blame it on me and send people my way."
This way I break the vicious cycle (often using the term towards stakeholders "That's what you hired me for.") and turn things into a gracious cycle:
More time for what matters -> more delivery -> more trust -> less control -> more time for what matters.
That diagram really resonates with me. It looks like you could enter that loop from any of those points and get stuck. I'd be interested in people's thoughts about the best off-ramps in the loop (other than the reporting covered in the article). Where could you make a concious decision to say "nope, we are not doing this"? I imagine it would be different from company to company but there must be some that would be generally more effective than others.
Man, I felt that flow chart too. Loss of trust often requires a superhuman effort to right and leads straight to teams burning out or over/under indexing on process. The escape hatch I've seen used effectively is what Robert mentions above - accountability, employed personally by a leader with a strong reputation for trustworthiness. In lieu of such a leader, often hard work and delivering on achievable overcommitments is the way to build trust from the ground up.
Superb framing here. The vicious cycle diagram nails what I've seen repeatedly, where lowconfidence triggers morecontrol which only erodes trust further. The point about dream teams getting exempt from tracking requirements is spot-on, they're producing outcomes so nobody demands granular work tracking. Seems like the real flex is trusting teams enoughto focus on outcomes instead of proxies.
Like most things, "context is king". Like most things, "culture eats strategy for breakfast".
A good (business) system is one that produces desired outcomes, consistently. A good engineering system does the same. Speed is the throttle, gas pedal, and brake.
The best systems constantly evolve, adapt, and are willingly EOL'd for better approaches to get the **gasp** desired outcomes. Love this post.
I couldn't agree more, John. the other thing to perhaps consider that brings the need for a overarching and unifying view is the customer journey... In my org, we have a huge variety of digital products, but a great many serve the needs of the many
John,
I'm thoughtful about how to track activity outside of a product context. I work in a team of OD consultants within a large, public-sector organisation in the UK.
The issue is that outputs aren't always clear. For some people their activity on a given project today would be recorded as "attend a regular meeting and assure the business's decisions". For others it might be "prepare a deck and get the business to make a call about what to do". Both of those are technically valid, value-creating activities - but only one of them is tangible.
I'd like to move towards a system where everyone can articulate what role they're playing in a given meeting. I wonder if the Viable System Model might be useful here: so if asked, people can say "I'm here providing internal control (system 2)" or "I'm here providing horizon scanning (system 4)" and then we can determine whether it's worth having someone deployed there. It's still subjective, but a little closer to helping us understand what adds value.
I'd welcome your thoughts on this. It seems like we're failing at a system level here. There are definitely some people in our team who are delivering less meaningful work, and being less effective within their roles - but they fall through the gaps, because their failings are masked by the big-ticket items that other consultants are delivering, which are tangible and impactful.
Thanks as ever - your writing and thinking is always appreciated, and I'm grateful for the time you take to articulate and share it.
THIS. A 100 times this.
The "chart" is a perfect description of all the things that happen and with good intentions pave the road to hell.
The awesome thing is that a new Agile Coach or ScrumMaster, whatever, coming in often has some upfront credit. If that person is me, that person usually immediately tells teams to stop caring about the vicious cycle enforcing BS and focus on what matters.
They then ask "But what about XYZ? We'll be penalized if we don't do XYZ!"
My response: "Blame it on me. Don't even discuss it. Blame it on me and send people my way."
This way I break the vicious cycle (often using the term towards stakeholders "That's what you hired me for.") and turn things into a gracious cycle:
More time for what matters -> more delivery -> more trust -> less control -> more time for what matters.
Psychological safety is key, without it, tracking becomes a control mechanism, not insight.
That diagram really resonates with me. It looks like you could enter that loop from any of those points and get stuck. I'd be interested in people's thoughts about the best off-ramps in the loop (other than the reporting covered in the article). Where could you make a concious decision to say "nope, we are not doing this"? I imagine it would be different from company to company but there must be some that would be generally more effective than others.
Man, I felt that flow chart too. Loss of trust often requires a superhuman effort to right and leads straight to teams burning out or over/under indexing on process. The escape hatch I've seen used effectively is what Robert mentions above - accountability, employed personally by a leader with a strong reputation for trustworthiness. In lieu of such a leader, often hard work and delivering on achievable overcommitments is the way to build trust from the ground up.
Superb framing here. The vicious cycle diagram nails what I've seen repeatedly, where lowconfidence triggers morecontrol which only erodes trust further. The point about dream teams getting exempt from tracking requirements is spot-on, they're producing outcomes so nobody demands granular work tracking. Seems like the real flex is trusting teams enoughto focus on outcomes instead of proxies.
Thanks, this picture alone says more than a thousand words and it hits way too close for comfort.
Some organisations I know match this so perfectly, they should do their estimations in "dysfunctional points" as a constant reminder.
Like most things, "context is king". Like most things, "culture eats strategy for breakfast".
A good (business) system is one that produces desired outcomes, consistently. A good engineering system does the same. Speed is the throttle, gas pedal, and brake.
The best systems constantly evolve, adapt, and are willingly EOL'd for better approaches to get the **gasp** desired outcomes. Love this post.
I couldn't agree more, John. the other thing to perhaps consider that brings the need for a overarching and unifying view is the customer journey... In my org, we have a huge variety of digital products, but a great many serve the needs of the many