What would you say you do here?
If an org has ten employees, then there are ten different perspectives on how the org works and how each person contributes. If the organization is a machine, each model is a different schematic. These models definitely have power because they at least include each person’s model of their own job and of the interfaces that they’re directly connected to. Those parts of a model determine action.
The models will exist at different resolutions. If Alice works in IT, and Bob works in Sales, then her model of the IT department will likely be much more detailed than Bob’s, and vice versa.
This provides a lens on responsibility. If no one’s model includes someone whose job it is to do a certain task, then the task won’t get done. Similarly, if Alice thinks it’s Bob’s job, and Bob thinks it’s Alice’s job, then it still won’t get done. Worse, both Alice and Bob might feel resentful of their colleagues for dropping the ball.
There are various assumptions that are imported by each person when they join. Assumptions that they bring about how the org functions, assumptions about what various coworkers’ titles likely mean, and assumptions about what their own work will be.
Each person has
- Their own role (and role definition with implied boundaries)
- The interfaces they need to use
- Their expectations and requirements from the rest of the org that need to be met for their role to matter
The org has
- Areas that no one is covering
- Areas that multiple people are unwittingly covering (overlapping)
- Areas that are clearly owned by an individual or a team
Requests
One way to think about the work that gets done in an org is in terms of requests. These can be implicit or explicit and they can come from inside or outside the org. Importantly, each person must have some process by which they decide, when they get a request, if they will accept or reject it.
Rule 1 – Boss said so
Sometimes individuals believe that the rule should be “if my boss is making the request, then the answer is yes, otherwise the answer is no”. This can run into trouble if the person is overloaded. They might accept too many (seemingly legitimate!) requests, when instead they need to be applying backpressure.
My third manager taught me this lesson pretty clearly. He suggested to me language that I could use when I was reaching the point of overwhelm. “I would like to be able to help with that, but I already have thing X and thing Y in my queue. Do you think that I should drop X or Y to take on this new task?”. It was a valuable starting point for me. I was new to working at small startups where responsibility was rarely crystal clear and there was always more to do than time to do it.
Rule 2 – Someone said so
Another overly-simple policy is to accept all requests. This often gets socially rewarded, especially at first. Before your role at an organization is clearly scoped out, you can actually accomplish a lot of valuable work simply by regularly agreeing to be helpful to anyone who asks. Still, it usually leads to overwhelm, it limits the degree of focus and specialization that an individual can achieve, and it doesn’t contain a strategy for prioritization. Each node in the graph / person in the org should have some ability to prioritize. Even if there’s only a single stream of work, you still need to make decisions about scope, lest a project spend more effort than the org can afford.
Rule 3 – That’s not in my job description
This rule’s philosophy is that each person should have a clearly written document that explains what requests they should accept and which requests they don’t have to or shouldn’t accept. One problem here is that writing, while helpful for clarity, is often too heavyweight to keep up in dynamic orgs. Another problem is that it takes clear culture or solid backbone to give this pushback against extreme status differentials.
Rule 4 – The customer is always right
This rule is “if the request came from a customer or potential customer, then the request should be accepted”. Many companies have lost their way because they tried to please a customer at the expense of building what could actually make for a sustainable business in a clearly scoped market.
Model making
Getting things done often requires help. This leads to new requests being made within the org. This is where the rubber meets the road. If you’re championing a project and you start making requests to your coworkers, you’ll quickly discover if your model of their roles matches their self-models. If you’re wrong, then the requests will be rejected, and you’ll have to reroute. The person you’re asking will often be the one to redirect you. “That’s not my job, ask Bob”. Redirection will cause models to spread and be copied, passed around like lore.
However, each person also has a meta-policy. Their policy for how their role evolves. It must involve a degree of self-determination, but it also usually includes a way that their boss, at least, can negotiate with them to change it.