May 8, 2021
In our agile world, we often divide up tasks longitudinally; that is, along goal-oriented lines. This results in mini-projects like “put documentation on the website” or “put a contact form on the website”.
This is an intuitive and low-effort management exercise, which can have great results. And I love how it lets you put trust in people to figure things out. The problem is, to assign a directly responsible individual (DRI), they have to be the right person to make decisions about every part of the project: from the marketing copy to the coding to the deployment of the changes. If they don't? Not only can it be very frustrating for them, but output and quality of work can suffer. Not to mention that getting things back on track can eat up valuable time for other members of the team.
Alternatively, you can divide tasks latitudinally - along their natural, functional lines. These lines have to be felt out, since they depend on the nature of the types of work involved. This requires a bit more work up front, to map out how to break tasks up, and how to assign the pieces. But once the fault lines have been drawn out, a latitudinally-defined task, in theory, can be simply kicked off, and all of the work will shatter away effortlessly to completion.
In practice, it’s not as simple as that. The different sections of the work often, sometimes more often than not, interact with each other. For example, a failed deploy often means doing a code/configuration change, followed by another unplanned deploy. You could call this an example of unplanned work, as defined in The Phoenix Project.
Conventional wisdom in the early 2020s says that means we’re supposed to give up on latitudinal work division. (Read any rant post about waterfall development practices if you need to catch up with the orthodoxy.)
But, just because something is more complicated than we hoped doesn’t mean we should give up. Especially when we consider another area of the market that benefits from latitudinal work division: the assembly line. Even though latter parts of the assembly line can interact with the earlier steps, it doesn’t mean the overall approach (of breaking the work into steps) is invalidated. In fact, it’s a net benefit.
A major benefit of latitudinal work division is that it lets keen teammates with spottier skill sets contribute more effectively to the process as a whole.
You don’t necessarily have to hire separate QA engineers, devops engineers, or security engineers (though many companies do). Functions can, but needn’t, map to full time roles. Instead, you might hire an apprentice or junior engineer who can, with some mentorship and good latitudinal task division, fulfill QA, devops, and security functions. Such a role is fulfilling, both in terms of personal happiness and business output. And it is incredibly valuable for the employee, who gains highly marketable skills and who enjoys unprecedented influence at work.
Just because you use latitudinal task division for a particular project doesn’t mean you have to revert to it exclusively. Not every matter is worth the effort of designing fault lines, coaching and aligning the participants, and monitoring the process. But when longitudinal work division fails, when high-skilled people become the bottleneck, when cohesiveness and consistency of an experience matters, or when recurring human attention needs to be paid over a long/indefinite period of time, it might be time to find the fault lines.
2nd paragraph: missing a “the”: “they have to be right person” should be “they have to be the right person”