Staying Out of Your Lane
Image by David Mark from Pixabay
Anyone who has ever got a mortgage loan probably knows that when things go wrong, they tend to go wrong at the point of handing off responsibility. You’ve been working with a single contact for a while, and they’ve often built up a lot of context on your exact situation and what you need, and the time comes for the next person in the process to take over and everything suddenly breaks; suddenly all the knowns about your situation flip back over to being unknowns and everything that was going along swimmingly before comes to a grinding halt.
People can generally do the jobs they were hired to do, but when the time comes to give their task over to the next person in the chain, communications are often speed-bumps; even where everything the next party needs to know is communicated correctly, the communication itself takes time. And the hand-off itself isn’t without costs; the simple process of a job being sent to the next person who then notices and begins work on the task can take days in some cases.
Clipboard Health has talked a bit before about flexibility in hiring, particularly as it relates to being flexible with titles. There, we were focusing more on the idea that titles sometimes got in the way of getting the right people for the job, or that the titles sometimes created a bit of an artificial barrier to individual growth for the person you hired, keeping their growth confined to the size and shape they and the company perceive the title indicates that the job has. Here we are talking about something different - the idea that a title often constrains job responsibilities to exclude tasks and functions it might otherwise make sense to include.
This often happens because - since job titles tend to exist at multiple companies - jobs are often reduced to the common denominators between companies. A business analyst can become someone who only deals in SQL and Tableau, with nothing else allowed or required. Even if that wasn’t so, a lot of an individual’s job responsibilities are pounded out during the hiring process - it’s easy for both the company and the newly hired team member to consider that a done deal, slot the team member into their described job duties and never address it again.
That kind of “job with rigid borders” thinking is not without any advantages at all - everyone likes clarity - but it does make for an awful lot of handoffs; every time an issue reaches the edge of an individual’s assigned range, it has to change hands. This gets worse the more steps you have in the process; eventually you’ve accumulated a lot of opportunities for something to go wrong.
Clipboard Health addresses this by a model that flows out of one of our major values: Ownership. When an individual touches a project, they are universally expected to care about outcomes. Handoffs are avoided in general where possible, and true handoffs of the “it’s your problem now” variety are strictly verboten. We will get into a bit more detail about how this happens later in the article but think of it for now as a longer-term and wider-scope commitment than most companies expect from their people.
The Dangers of being “Done”
One common complaint you hear from software engineers is regarding someone who doesn’t properly comment within their code or otherwise play well with documentation. Eventually, that person leaves the company or moves on to another project or is in some other way “done”, something breaks, and everyone has to scramble to figure out how the code they wrote actually works, without any notes to help them do this. But in a lot of cases, the programmer did their job - they were asked for some particular deliverable and delivered it.
That’s the trap of focusing fully on deliverables; in that scenario, an individual considers their role in each deliverable done as soon as they hand it in. But this kind of thinking is death for your actual outcomes - each person in the process is incentivized only to move things forward. Moving things forward isn’t bad, but without any skin in the game in the eventual outcomes, each person is going to be a lot more likely to optimize only for their own step in the process, not the actual experience your end-users have.
One of the ways Clipboard addresses this is by making each individual “own the outcome” for any project they are involved with. This is just the first part of the solution (there’s more to come) but we are absolutely committed to breaking “just the deliverables” thinking. Every individual from Product Managers to HR People to Operations is expected to take a much wider view of things and is expected to keep the eventual goals of their work in mind at all times.
This requires more thinking on everyone’s part - for the team member, it means zooming way, way out from the confines of their job description, and viewing things on a company level. For managers, it means giving both the flexibility and the tools the team members need to approach their work in that way. For the C-suite, it means a lot of communication; if the team doesn’t have a good handle on the overall goals of the company and their projects, there’s no way they can get the perspective they need. But that work has been consistently rewarded; when you optimize for outcomes, you not only get better outcomes as promised but avoid many of the problems of “I’m done” thinking as a bonus.
Redefining Lanes
Besides focusing on deliverables, there’s something we already touched on a bit that Clipboard thinks has more downsides than upsides: focusing on lanes. A “this is my lane” way of thinking is built on defining job roles and then functioning well completely in their confines; getting outside of the lane is here considered to be negative and to be avoided.
This doesn’t mean there are absolutely no benefits to this system - if nothing else it’s very clear and simple - but it means that when something unusual pops up that isn’t well defined in anyone’s particular job role, there’s a lot of confusion around who picks up the responsibility and reluctance to do so. When we start to consider that this system that absolutely demands a lot of hand-offs also encourages a situation where problems like these might fall through the cracks entirely, the benefits of clarity stay-in-your-lane thinking gives begin to look pretty light in comparison to their downsides.
Clipboard tries to handle this by redefining lanes entirely, focusing on domains. The most explicit example of this is our product management team, whose responsibilities are broadly divided into domains; a PM who is in charge of, say, payments to our users is connected to it in a “floor to ceiling” way that encompasses any possible issues that pop up in their domain. They care about, work on, and stay informed about risks, opportunities, and user problems of all sizes. There’s never a point where they “are done” with something that happens in their domain - our customers can expect their support no matter what happens.
If that seems a bit like a lane-by-another-name, understand that it doesn’t stop there. Our people are also in the habit of jumping in and out of their domains where needed; whether it’s a PM or anyone else in the company, there’s an expectation that they are constantly evaluating their time and the situation on the ground to make sure that their efforts are always going to the highest-impact areas available to them at that time.
When you combine those two things, you have a situation where handoffs are minimized and responsibilities are always clear, but also where flexibility is maintained and maximized. Where, say, a user problem pops up that needs the product team’s help, it’s clear where that problem gets sent. If the product manager in charge of the project needs help, he can reach out to anyone in the entire company and expect assistance immediately, as opposed to hearing something isn’t someone else’s department. This philosophy is mirrored in every employee in the company; the systems we use change to be appropriate for the department, but the benefits are the same.
We like the domain system coupled with an expectation for help, and our nurses are well served by it - we have managed to nail down a system where our users can expect quick help for any issue, no matter how “outside the lane” it is. This helps build trust, something we think is important. But whether you mimic us or not, we encourage you to take the time to examine your own system - don’t let excessive hand-offs and reliance on lanes hurt your product.
If this article is the kind of thinking you find cool or exciting, we’d love to talk to you. Apply here, and we will be in touch soon!