Elizabeth Bacon's Sundial Model

Elizabeth Bacon's Sundial Model:
My department recently (trending to not-so-recently) had a realignment. It would be more accurate to call it a reorganization. Reporting lines shifted en masse, so that's obviously what it was. The goal was to facilitate Agile development and how we interact with other teams in a vertical manner. While we had distinct objectives in mind, optimizing to Agile and vertical development are rather esoteric statements, and it's difficult to see how the realignment achieves this end without concrete examples. Here's one example, and how it ties to some theory. For the vertical development objective, our goal in reorganizing was to break down some of the specialization - what you see in Elizabeth Bacon's sundial model above as generally the bigger the company, the more those skills become defined as distinct roles (in our case it was code domains, not UX domains) - and code throughout the stack, bringing individuals with a breadth of experience to bear on technical questions so that design and architecture are as much a part of our daily work as development.

The issue with specialization, at least one of the issues, is that there is a premium, salary- and benefit-wise, paid by large companies for developers in order to hire people who willingly deal with an overabundance of process, don't mind the extensive roster of roles (role specialization, or at least the lack of generalization) that interferes with personal ownership, and flourish despite not working directly with customers. The premium isn't for the best developers (although that is a goal for any development team), but for developers who fit a set of criteria. Those criteria can be characterized as broken from some perspectives, particularly the Agile perspective, despite that they fit company needs. The flip side of this "corporate tax" is the idea of "golden handcuffs". It's a two-way street. While big companies shop for best of breed developers who still fit within their box. Best of breed developers who fit within the large corporate box shop for those companies to ensure stability, a premium on their salary, and a low-impact, mobility pressure valve that doesn't always come with a small shop.

Relating this to Alan Cooper's presentation, we can conjecture an interesting correlation between big company hiring practices, specialization, and offshoring. If the hiring goal is fulfill the above constraints, then the appeal of offshoring is, in part, that the company feels this developer persona can be offshored. What is headed abroad in many cases is not the job of a self-empowered, iterative, design-capable, agile knowledge worker - a craftsperson - but an extremely specialized, heavily process-focused, non-customer-informed, placeholder.

That seems harsh. As though I'm disparaging both onshore and offshore resources for large companies. But far from it. Large companies have specialization. They have process. They lack customer contact at certain levels. And to thrive in that environment is a skill, or set of skills, as is the reverse. And if we look at ShuHaRi, we realize that some of this work takes place in the lowest level of knowledge. But it serves as building blocks for moving to higher levels of knowledge and understanding. Onshore or offshore, the move toward craftsmanship (being a craftsperson) is inevitable in an educated base of developers. Consider the focus applied to process by new offshore groups. Then consider how, over time, the process evolves into something more. The natural progression, so it would seem, is to rise above the traditional big company premium restrictions. Moving the premium offshore simply delays an evolutionary change in how software is constructed or pushes the premium from offshore group to offshore group until the very last developer is empowered (a good place to argue Friedman's World is Flat).

The good news is there is space for the process-focused developer who is moving toward being a craftsperson, and for the developer who has already moved past that stage and is a craftsperson. It requires the former to allow the latter to stretch. But you have to acknowledge that you're the latter and put yourself in a structure that enables non-process focused, customer-oriented, iterative, generalized (ownership-focused) development. That might be Agile (in the strictest sense). Or it might be an organization rebuilt around the idea that these are positive goals to achieve and developers should be proactively enabled to drive at those ideals. Our department has started a journey toward Agile, and has come down strongly on restructuring to empower developers. We know we have a team of craftspeople and we're striving to allow them to actualize that reality despite, or perhaps by building upon the strengths of, the corporate tax.