Little Tasks, Little Trust

"Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager’s eyes or in your government’s eyes) is irrelevant; it’s only the right to be wrong that makes you free."

In my current company, design tasks are just tickets, but we tend to assign implementation tasks to the same people who did the design tickets, when possible. However, design gets done in isolation, with little to no consultation. Some factors can trigger a design review, but it comes so late in the process that changing anything at that point is disruptive and regarded as a kind of failure.

Much better (in my opinion) is for one person, who will also implement the design if plans permit, to be responsible for the design, but the process of designing to be done "in public." Somebody is responsible for making sure the design is done on schedule, documented, etc., and they have the final call on any contentious issues, but it is discussed by everybody who is interested, and the meetings are publicized and open to anybody who wants to come. Since it is public, you get ideas from the most people, raise awareness so negative impacts to other systems are more likely to be spotted, and generally raise the level of understanding of the system as a whole among all the developers. Since it is individually owned, there is a single point of contact for product and management, it's clear who needs to be allocated time for documentation and research, and the implementer gets to feel a sense of ownership.

Ideally.

In practice I've seen it go the opposite way where management's reaction is trust less and less, making smaller and smaller tasks. Developers aren't innocent either, instead of griping about having less control, they throw up their hands and work-to-rule. Doesn't matter if the task description has obvious problems, that's what is getting implemented. Nothing less and nothing more.

Honestly this all comes off as toxic. Maybe it's high time to leave where I am seeing this all go on.

>No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a healthy portion of “give me some space to do my work.”

The author speaks as though they have never been in the situation where their team delivered a product that meets the spec but isn't actually useful to their customers. Agile (what the author means when they speak about tasks/backlogs) doesn't guarantee this problem will be fully solved by doing by-the-numbers scrum or w/e, but the system they are flirting with in this essay is almost certainly worse. It's a complete recapitulation of waterfall/cowboy and adhoc design processes, without the honesty to interrogate why these processes failed organizations large and small.

>As I see it, little tasks are born of a fundamentally different management attitude. Small tasks are a not-so-subtle way of saying that all the product vision lies with management. Keep away. Don’t touch.

The author is talking, here, about how encountering agile makes them feel. This is not a universal experience. I would reply that we have a division of labor/responsibility because technical personnel are often some of the worst people to speak for the customer, and history has born this out.

>Then you went back to your private office (I sure miss private offices, but that is a topic for another day) and fixed a few things. Later, in a weekly status meeting you would tell people how it went — yep, that’s right, no daily stand-ups where you look mournfully at your shoes and admit that you didn’t make any notable progress yet.

Once again, the author is telling on themselves If they don't like feeling like they aren't making progress, it's almost always because they aren't motivated or need help. Certain team strutures (e.g. Mob Programming) actually produce incentives for this sort of task-going-nowhere problem to be addressed constructively (also against silo-ing, another perverse tendency that this author implicitly endorses throughout the essay).

As an aside, I agree about the communal working space trend in tech being shitty, if you team can't work communally. This is a problem that agile practices are only beginning to address (again, please see Mob Programming for a way to deal with this).

>Sadly, as developers, we do it to ourselves as well. Once someone gives us a better title, we are right on board with the program. When a regular developer might have had a chance to do some research or design, we immediately snatch it away for ourselves.

This is a philosophical non-sequitur. How are tasks related to snatching design work away from non-architect/technical-lead developers? Any team that wants to spread around design work can address this and whether a team does agile/task-based work has no bearing.

>Worse yet, we design every product’s architecture, and expect any deviation to be approved by us first. All that is left are tiny morsels. Grunt work for the foot soldiers once the fun has been stripped away.

The author moves and back and forth between speaking as a grunt developer and speaking as an architect/technical-lead, and it's quite confusing. They are also, per their bio, a fan of "organizational self-management". Furthermore:

>“I am Amerigo, the product guy. Heretofore, no developer will make product decisions, for they are mine.” >“And I am Ferdinand, process guy. Heretofore, no developer will make process decisions, for they are mine.” >“I Bartolomeu will enforce compliance.” >“I Vasco used to be pretty good at Microsoft Access, I guess I’ll be the database guy.”

I feel like you put all of these things together and get a picture of a programmer who I, personally, would be absolutely terrified to allow in front of a customer, let alone expect them to work constructively with other functional stakeholders.

For the record: I'm a technical lead in a medium-sized (~150 developer seats, many more non-technical roles) enterprise software organization. Most of my experience is in the enterprise/consulting space and my perspective reflects that.

I think the kind of unstructured/responsibility-based approach the author advocates is naive and says more about their problems working with others than it does about how dysfunctional agile can be. I think the main barriers to teams delivering is how to cooperate to deliver consistently and sustainably, and not that rockstars needs to be set free to pursue their own agenda within vaguely defined boundaries of responsibility.