How we work, and for whom, part 2

Alberto and I are splitting the DMS CE duties while ESS recruits a replacement for Warren. The main thing we hope we’ll be doing is tracking progress against the schedule, but inevitably things will come up. The interesting question will be to understand what happens when things to come up.

I understand that people find value in the CE role. The CE is our chance to coordinate architectures and implementations across missions, and get consistency across subsystems. I believe there might be even more value if each CE had a narrower focus. The number of CEs was rather arbitrary, so why have three? Why not have six or seven? Or even eight? If we had a strong-project-lead model, and treat each build as a separate project, the CEs would effectively direct both the work and the people, and the Branch Manager would have a limited, administrative role. (To the point that we might only need one.)

Matt talks about the importance of teams. For the big projects, we want to contribute team members that have a good understanding of products and practices, informed by their experience on previous efforts. For little projects, and for maintenance efforts, we want sustaining teams that work in sustainable ways, so the project managers should expect to be “stuck with” the products they build. Put baldly, the CE needs much of the Branch Manager role to be effective.

Peg talks about organizing around the work: Look at where work gets done, and create an organization that supports that, recognizing that different work has different needs, and may need different organizations. Again, what ESS works on is products, so we should organize around products. When we contribute people to cross-functional teams, we should pick them based on their understanding of existing products, recognizing that they may be asked to build an entirely different product.

My notion of the Product Engineer is a CE with staff responsibilities. It is, in a sense, “back to the future” in the sense that ESS used to be organized around product teams. It is, however, informed by the experience of the reorg. We can have larger branches, and have products in rational groups. We can matrix people, though we’ve learned that we need to not split them so finely.

We’re going through an exercise of understanding what works and what doesn’t about the current organization. It may be that I’ve prejudged the outcome, so I’m anxious to see where that exercise takes us. What I don’t accept is that we can’t change roles simply because we’ve invested effort in getting acceptance of the CE role. That’s a classic case of the sunk cost fallacy.