4 ms·

Isn't this an exceptionally lossy, and circuitous feedback method? When I'm managing a team, I'm spending all of my time ensuring that any obstacles are obviou

Isn't this an exceptionally lossy, and circuitous feedback method? When I'm managing a team, I'm spending all of my time ensuring that any obstacles are obvious, and that everyone has the stuff they need. This article seems to recommend leaving out details and waiting for people to ask for that detail. Normally I'd prefer to be as clear as possible. 1. Our goal is to meet [objective], by [timeframe]. 2. The plan is to accomplish [supporting tasks]. 3. [Supplies] for tasks can be obtained here. Likely you will need X. 4. Distribution of duties is thus. Notes: Any ideas that will accomplish objective faster/better are welcome. When we run into large obstacles or need help say something. Identify bad decisions (especially mine) before they cause big problems or waste a bunch of time. Conversely this article wants to stop at step #1, and then wait for people to figure out 2 & 3 on their own. Which is probably exactly why they haven't started work. Perhaps I've been blessed with excellent team members, but I've only encountered a handful of truly lazy people. Whereas, I commonly encounter fractured teams because of competing objectives, unclear tasks, and ambiguous goals. Engineering tasks to have hidden canaries is trying to solve the uncommon problem (lazy professionals), by exacerbating the more common problem (ambiguity during a coordinated effort).

bigiain 8y ago
Broadly, I kinda feel like you're comparing Agile and Waterfall. If I'm "Valuing people over processes" I'll quite likely stop at #1, and rely on my people/team to work out the plan (#2) and supplies (#3) and task breakdown (#4) amongst themselves. This does though, require a team willing and capable of resolving ambiguity, who'll proactively communicate their decisions and ask for assistance/resources. Your "uncommon problem" of lazy professionals is always going to be a killer, but if you're trying to do (original manifesto style) Agile with a team who're not confident or experienced enough to make it work - you'll end up with a way worse outcome from ambiguity than with an experienced/confident "Agile team".
vidarh 8y ago
I don't see it advocating leaving out details at all. I see it suggesting that if you know the necessary steps or figure them out when you wonder why things are taking time, they become easy mechanisms for identifying if there's a communications problem (that again may reflect other problems). Whether or not you expressly communicates the next step at the start is incidental to that (at some point you stop breaking things down in further detail; no matter how detailed your plans are) - the only point is the existence of a required step that can be verified independently of a team or team member that is not being open with you about the real progress. > Perhaps I've been blessed with excellent team members, but I've only encountered a handful of truly lazy people. But it's not necessarily about being lazy, but about people juggling multiple priorities, and finding it easier to fob people off with a "working on it" than explaining why their likely totally legitimate reasons have prevented them from getting further. Yes, this signals organisational issues with communication, but being aware this implies a problem does not make it go away - people don't like being the bearers of bad news, so it typically takes a lot of work to get visibility in these type of situations. Often this is people trying hard to do their best, and delivering as fast as they can, just doing it by sacrificing taking time for feedback to stakeholders. > Engineering tasks to have hidden canaries is trying to solve the uncommon problem (lazy professionals), by exacerbating the more common problem (ambiguity during a coordinated effort). You don't need to engineer tasks to have hidden canaries. For most tasks there will be canaries all over the place. The article even explicitly makes the point she has not set anything like this up intentionally, but have seen them when wondering why tasks take a long time. And this would also reveal ambiguities: Maybe the cause is that the team is building something, but it's different from what you expect and so doesn't affect the canary. In which case that is still a valuable indicator of a problem you may not have caught as quickly otherwise.

bigiain 8y ago

Broadly, I kinda feel like you're comparing Agile and Waterfall. If I'm "Valuing people over processes" I'll quite likely stop at #1, and rely on my people/team to work out the plan (#2) and supplies (#3) and task breakdown (#4) amongst themselves. This does though, require a team willing and capable of resolving ambiguity, who'll proactively communicate their decisions and ask for assistance/resources. Your "uncommon problem" of lazy professionals is always going to be a killer, but if you're trying to do (original manifesto style) Agile with a team who're not confident or experienced enough to make it work - you'll end up with a way worse outcome from ambiguity than with an experienced/confident "Agile team".

vidarh 8y ago

I don't see it advocating leaving out details at all. I see it suggesting that if you know the necessary steps or figure them out when you wonder why things are taking time, they become easy mechanisms for identifying if there's a communications problem (that again may reflect other problems). Whether or not you expressly communicates the next step at the start is incidental to that (at some point you stop breaking things down in further detail; no matter how detailed your plans are) - the only point is the existence of a required step that can be verified independently of a team or team member that is not being open with you about the real progress. > Perhaps I've been blessed with excellent team members, but I've only encountered a handful of truly lazy people. But it's not necessarily about being lazy, but about people juggling multiple priorities, and finding it easier to fob people off with a "working on it" than explaining why their likely totally legitimate reasons have prevented them from getting further. Yes, this signals organisational issues with communication, but being aware this implies a problem does not make it go away - people don't like being the bearers of bad news, so it typically takes a lot of work to get visibility in these type of situations. Often this is people trying hard to do their best, and delivering as fast as they can, just doing it by sacrificing taking time for feedback to stakeholders. > Engineering tasks to have hidden canaries is trying to solve the uncommon problem (lazy professionals), by exacerbating the more common problem (ambiguity during a coordinated effort). You don't need to engineer tasks to have hidden canaries. For most tasks there will be canaries all over the place. The article even explicitly makes the point she has not set anything like this up intentionally, but have seen them when wondering why tasks take a long time. And this would also reveal ambiguities: Maybe the cause is that the team is building something, but it's different from what you expect and so doesn't affect the canary. In which case that is still a valuable indicator of a problem you may not have caught as quickly otherwise.