The Value of an Identity-less Team

Common to many organizations is the desire to have a department or group with like skills practicing like behaviors. For example, the "requirements group" or the "development group" and so on. I do not know the origins of this model, though it is indeed logical to put like people with like people. It is simply a logical thought similar to the way most of us categorize and organize our clothing in closets, silverware in utensil drawers, and food stuff in cabinets. This is what we do - we categorize (label) and organize associatively. Putting like people together into departments with like labels also tends to make sense in order to offer people a career path and differentiate skills and experience in terms of compensation and advancement triggers.

This model ordinarily gets extended in the operational machines within a company by how we tend to staff and manage projects. One example is our tendency to estimate projects not only by task, but by role-by task - often calculating capacity based upon an individual.

Another example: a department may take whatever one group says and multiply it by a mathematical factor and be content to say "if development says X, then I say X*0.75 by standard".

As discussed in an earlier post titled Compressing Software Lifecycles by Eliminating Lines of War, we see yet another example is how projects are structured: projects ordinarily have someone running the project called a "Project Manager" who then staffs and manages the project based upon labels, aka titles.

If we look at many statements of work or contracts in the marketplace, we tend to see estimates and rates broken down by role with variability within each role associated to seniority or "junior-ity". The label identifies the chargeable cost based upon the title; but what does it really mean? Value some gets associated with the title which then produces some equivalent hourly bill rate. If it were merely a method of identifying roles utilized to complete work it would be fine. Often though, each label in the contract is actually a title with a person's name associated to it (whether public or privately communicated).

It is time to change our model.

I posit that the reason many teams do not work well together is because of company organizational models. The practices of putting people into buckets, assigning hierarchy within buckets, and then expecting them to "team" with others is counter-intuitive and runs contrary how their compensation based performance is measured. Team members are not ineffective by choice; they are ineffective because companies do not understand how their organizational structure impacts operational effectiveness.

If the organization creates "classes" or other differentiators between people groups within corporate society, then that is the way people see themselves and each other. Later when said people are on a particular project, they do not show up as solution providers serving a customer; rather they show up as their corporate societal class or label expects.

Is it a reasonable hypothesis that waterfall processes are merely child products of poorly thought out organizational models?

I am my label. You are your label. Our labels together will deliver a project solution as long as you do the stuff associated with your label, and then I will do mine.

What would happen if we did not have departments and labels? Aside from the uproar from people who believe they can label and organize people like their sock drawer at home, we would eliminate many territorial boundary problems which plague our teams with fruitless bureaucracy and latency.

What does an identity-less solution delivery team really look like?

  1. Everyone has equal license to perform any role, on any task, at any time, for any reason versus certain people only being licensed to perform certain tasks when it is their turn
  2. Everyone stands at the marker board or window at the same time, each with marker in hand, collaboratively talking, writing and solving together versus someone being designated "the leader" and everyone else waiting to be called upon
  3. The focus of the group is to identify what types of work must be performed to solve the problem at hand versus thinking of "who" should be involved, when, and how to get them
  4. Everyone has the proactive responsibility to participate and provide immediate and direct feedback on everything all of the time versus waiting until it is their turn, then logging the observations into a database and sending feedback through a process tunnel
  5. Everyone is equipped and licensed to answer questions at any time from anyone on any subject versus queuing and directing certain questions to certain people on certain timeframes
  6. The team ignores requests for titled people and immediately begins seeking an understanding of the problem versus receiving a request for "John, the Architect", then backing away from the need, and telling John he has a phone call on Line 1
  7. Each team collaboratively identifies the work, signs up to do the work, and delivers the work versus assigning someone to be responsible for motivating and managing the team
  8. Each team member focuses on skills necessary to create solutions versus "who"

Human Resource career pathing plans, departments composed of like people, resource managers responsible for managing like people, and project managers requesting people names or HR titles for projects are all products of corporate culture - and all unwittingly perpetuate team breakdown. As long as our conversation includes identifying a requirement person over the bridge, a developer through the woods, and a tester over yonder - we are focusing on the wrong problem.

Try this at the next planning meeting:
  1. What is the problem needing a solution?
  2. What tasks and roles are necessary to get there?
  3. In what order should these things be prioritized considering risk and value?
  4. Who wants to sign up to address each task?
  5. What do we think we can get done in a pre-defined timeframe like two weeks?
  6. Go.
Rather than having departments by role-type managed by resource managers, who farm out their department personnel into "matrixed" organizations, overhaul the system and change the paradigm. It works. Try it.

  1. Measure teams versus individuals and departments.
  2. Deliver whole solutions to customers versus bits and pieces between departments.
  3. Encourage self-directed teams versus third-party management.
  4. Let the operational structure be the organizational structure versus creating an organizational structure and figuring out how to get it operationalized.

Customers don't care how many departments we have or how many people are in each department with associated hierarchies. Customers care about delivering.