Just imagine being able to get group of so-called “individual contributors” together and build software with freedom to execute in a manner that works best for the team, with minimal or no project management overhead, no architect(s) or committees to ratify design decisions, and the empowerment to quickly change the course as necessary. There is just one catch – the team must be after a mission to accomplish some measurable and timely business goals. How the team gets there is up to the team. I’ve had opportunities to form teams and execute in this manner twice so far in my 20 months at eBay, and I love the experience. What’s better than getting paid to solve problems for real customers and scale without the overhead and slowness that is typically attributed to large companies!
During this course we blended a number of ideas from open source projects so that we get the best of the both worlds.
Having been in this trade for years, I’ve come to realize that how a team organizes itself and conducts its activities is a critical contributor to the quality and agility as well as the enthusiasm and happiness of the team members. One of the ways to get a team of people behind a set of goals with passion and enthusiasm is to let the team decide the how. Unfortunately, that does not happen in most places of work.
Let’s imagine that there is a mission and set of goals to accomplish. The typical model I’ve seen used goes like this – One or more architects (or some senior equivalents) define how the big picture ought to look like to meet those goals. An architecture is drawn as pretty diagrams and published into slide decks and wikis. The big picture is presented and discussed, and then is broken into parts that smaller teams can execute. Smaller teams are then formed. Finally coordinators like project/program managers get assigned to conduct the development process so that dependencies and communication can be streamlined. This model creates an hierarchical organization supposedly to help reach the goals.
Then Conway’s Law happens. First, the organization will start to influence and dictate choices. Second, since each team is going after a part of the mission, the parts may not necessarily guarantee an integrated experience for the customer irrespective how well they were built. Third, coordination of the development of parts creates an extra layer of friction and slowness that most productive engineers hate. I’ve seen things that take 10 minutes to fix get discussed between teams for hours and days only to get dropped in the end.
Such an organization is counter-productive.
How are successful open source projects organized? The rules of engagement in open source model are not organization-driven but are organic:
- Individuals come from different parts of the organization, often working in different timezones. There is no direct mapping from managers to things that engineers work on.
- Individuals get to work on the things they work on because they have established their credentials with the rest of the group, and not because they work for such and such part of the organization or they’ve been assigned to.
- Decisions don’t get taken because some senior person said so. In stead, individuals have the power to make, and the responsibility to socialize and defend their choices.
- There is no one paid to coordinate. Open source projects don’t have the luxury of support and coordination roles. Certain members may volunteer to coordinate things like prioritization, and releases but it usually takes a small amount of their time. Such roles are often rotated.
- Inferior ideas are voted out as the group tends to recognize innovators and strong executors – community recognition is a key perk in open source projects. Consequently, you don’t get to hide behind a manager curtain and build stuff in isolation.
- There are no mundane tasks. Consequently, things that are manual or that require inferior skills don’t exist.
All these are easy to apply even in non-open source projects irrespective of the size of a company, and it is well worth it. But it opens up an important question since you’ve some business goals to accomplish and work for a man.
How do you make sure that things that are needed to be done get done. In a community-centric model, some work items may attract no attention.
This is easily solvable.
To start with, the team must get behind the mission and stated goals and make the mission their own. What I’ve learned is that, when individuals are given the ownership and freedom to execute and a mission, they usually get things done end to end. You don’t need to tell them how. Things fall through the cracks when they don’t have that freedom. Of course, this is contingent on creating a reward structure that rewards meeting the end goals and not specific tasks or actions.
In a system where anyone can join and pick up anything, mundane things won’t get done because those are tedious and repetitive. This usually leads to a subpar team structure with lower tiers of engineers doing mundane tasks. The only way to avoid this is replace mundane tasks with clever solutions. Create those solutions such that you can make yourself redundant from doing those ever again.
Finally, let the mission and goals help decide what needs to be done and what does not need to be. Feature creep happens when teams are looking at parts and not the big picture. You can minimize this by making every one part of the big picture.
The net result is a team that is focused on the mission with the freedom to figure out how to organize and conduct itself. This may sound anarchic, but I would argue that is it is objective.
But does it work when you have hundreds of developers all working on a large project, or any project for that matter? I don’t know but I think it is important for the people involved to take the time to figure out.