malvasia bianca

Since my role shift at work, I’ve been thinking about teams: partly being surprised by my reactions to some interactions, partly thinking about ways in which my instincts are a bad fit for some aspects of our house style. And three questions about organizational team structure (in general, not about my current job) that I’ve been thinking about in particular are:

1. What are the groupings within the development staff that are coherent on their own? How does the organization think about individuals? About teams? About the development staff as a whole? (Let’s assume the organization is of a size where having multiple development teams makes sense.)
2. Within a development team, what are the divisions of responsibility? Does each individual own one slice of the code, is everything shared equally? I imagine almost everybody would say that they’re not at either extreme, but where on the continuum does the team lie, and what are the interesting different ways to think of that choice beyond a simple continuum?
3. How cross-functional are teams? Are all the members traditional software developers, or are there testers, product managers, project managers, interaction designers, other roles? For that matter, just within software developers, are the architectural responsibilities within the team, or are there people outside the team who have a strong say over how they should structure the software?

My current preferences are to treat the team as a quite strong grouping, to have as much shared ownership as possible among developers on a team, and to have cross-functional teams. And I’d been thinking about these as a naturally grouped set of opinions (with the second and third following from strong teams).

Now, though, I’m less sure about the natural linkage. I mean, I understand why I link them—it’s all pretty standard eXtreme Programming stuff, and XP has had a huge influence on how I think about software development. But the fact that they are linked in that one methodology doesn’t necessarily mean that they’re linked in general.

Thinking about it more, I think there is good reason that my answer to the third question might follow from my answer to the first question. If a team is a strong unit, it has to be able to both make and execute on important decisions. But you can’t really make important decisions on your own if people outside of the team are doing most of the deciding of priorities or are specifying the design (whether from a user-facing point of view or an internal architecture point of view). And, similarly, you can’t do a good job of executing those decisions unless you have the skills within the team to perform the various implementation tasks, and the judgment to steer you on a reasonable course in the small as well as the large.

I’m not nearly as sure about the second question, though: it seems to me entirely consistent for a team to say that it has decided that the best way for it to work is to divide up the responsibilities among the team members, with that division relatively stable. (In fact, to some extent that’s exactly the situation I was in earlier this year; some of the pressure for specialization came from outside the team I was on, but a significant portion came from inside the team.) Sure, having everybody work in the same area can contribute to team strength and unity, but having people work in areas that they’re not drawn to can just as easily distance them from others; and the main justifications I see for shared ownership within Agile thought are based on decreasing cycle times and decreasing risk, not on strengthening teams.

And, as I write this post, I’m realizing that, to some extent, the second and third points are in tension. If your team is all programmers, and especially if it’s all programmers working in the same general area, then sure, you can imagine that anybody could work on a given area of code if that were helpful. But the more cross-functional your team is, the more you’re going to have people who really can’t do each other’s jobs: when I worked on Sorority Life, I wasn’t about to start drawing dresses for the game, and the artists weren’t going to write server code.

Also, if (as I’m assuming) we’re having this discussion in the context of an organization that’s larger than a single team, then this concept of shared responsibilities makes a lot less sense for the interior teams: a first-level manager is going to be part of a team with that person’s peer managers, but those managers don’t have shared responsibilities at all: they’re managing different teams, they don’t manage whatever team happens to be convenient for them to manage on a given day! If you follow that path a bit further, you could even make the case that collective ownership has unfortunate political implications: once you’re a manager, you have an area that you can call your own, but individual contributors have to be considered as part of a collective pool.

Having written that, I still think that collective ownership is a good thing, certainly for me personally but plausibly for a wide swath of software development. And if I want to put a political spin on it, maybe it’s the reverse of that last train of thought that’s more accurate: if collective ownership is appropriate for individuals but not for bosses, then get rid of bosses! I was joking over lunch with one of my coworkers, saying that the two of us should form our own splinter anarchist team with no manager; we couldn’t get away with that, but it’s definitely tempting…

Though, when I say that I’m certain that this is what I prefer, what evidence do I have of that in general? Have I, in fact, ever been in a situation where I’m on a strong, cross-functional team with collective code ownership?

I’ve experienced aspects of that situation, no question. On StreamStar, I think we had pretty strong teams. People outside the individual development teams made decisions about the direction of the project as a whole, but within those broad strokes, the development teams had quite a bit of autonomy to decide how they were going to do things. (At least after we got acquired by Sun; before then, one of the cofounders handed down software design edicts by fiat.) And, at least on my team, we were pretty strong on collective code ownership (again, after we got acquired by Sun): different people had areas where they knew more, but if there was a big project, then everybody worked together on it.

That team wasn’t cross-functional, though: we had the programming covered well, but there weren’t any product people on the team. I didn’t really get to experience a cross-functional team until I worked on Sorority Life: there, we had programmers, testers, artists, game designers, and product managers all working together, seeing each other every day. In fact, that team did a great job of hitting my answers to all three points on the list: we were cross functional, we could make almost all the important decisions about the game ourselves, and the developers could chip in wherever was helpful. (That was the only job I’ve had where I did frontend work as well as backend work, and we all ended up being able to contribute on both sides.)

And: it was awesome? Well, it kind of was, actually: I had a lot of fun working on the game, I learned a lot from the experience, I enjoyed working with people who weren’t all programmers, we made a lot of money for Playdom, and I think the decision about architecture and about priorities that we made while I was on that team are a big part of the reason why the game was still doing well for Playdom a couple of years after I left despite its age.

But: I also left the team after nine months. So that certainly raises the question of whether what I say I want matches up with how I express my preferences in practice.

Honestly, though, I don’t think there’s a mismatch there. Part of it is that I didn’t just leave the team: I left the company. Playdom got acquired by Disney, it became a noticeably less pleasant place to work, and there were a lot of signs that it was going to get worse instead of better. Also, the work on the game itself had stabilized: in the first half year after I joined, we made what were in retrospect a quite impressive number of architectural changes, but in the last three months that I was there, it was starting to look like we’d done such a good job of reworking the architecture for the game that it just wasn’t all that challenging to continue to make our players happy and to make us money. And, talking to my former Sorority Life team members a couple of years later (or simply looking at the game), that seems pretty accurate: the same basic structure is still there. I’m sure we would have found interesting ways to improve the software architecture if I’d stayed (I’m sure people made interesting changes after I left!), but it’s not crazy to think that the product had stabilized.

So, yeah: I do like coherent, cross-functional teams with porous boundaries. But I also like working on software challenges. And, if I’m not managing to find away to have it all, I’ll just have to figure out what to jiggle…