I wrote and published this internally at my company, Automattic (we’re hiring!). Some of it is specific to us, a distributed technology company, but I suspect some pieces may resonate with others, so I’m sharing more broadly.
We often have a sort of narrow-mindedness where we focus on our own tasks or our own areas of code to the exclusion of the greater whole. And we play a game of hot potato where we do our thing and then throw it over the fence. We think of our job as working on the narrow piece that is our expertise — an API endpoint, a page in an app, some section of code. But we don’t work to understand the other parts of the system.
I think this comes from a mindset of fear. Fear of something bad happening on our watch, in our area. So we race to get our piece done and throw the responsibility to someone else. This leads to things like code reviews where people list objections without solutions. Where people point out why we cannot do something without offering ideas moving us forward. It leads to slow exchanges in conversations where we waste days due to timezone overlaps, narrowly answering questions but not digging further. Where we don’t coordinate or ask people about their side of a project because “that’s not my job.”
It also leads to solving problems at the wrong layer. Addressing API problems with front-end workarounds. Writing “fixers” that address the symptoms of problems after they occur rather than addressing the root cause. It leads to missing things like planning for analytics or ab-testing or launch plans, because we’re focusing on building code… because we think that’s the job. “I did my piece, so if anything goes wrong it’s not my fault.”
But doing our one piece is not the job. Our job is to get the thing done, make good products, and get them in the hands of our customers, however that has to happen. That doesn’t mean we have to do everything. But it does mean that rather than throwing things over the fence, we need to purposefully hand-off and confirm with others. Take the extra step and think “What can we do to solve the real underlying problem?” or “How can we get this new awesome thing improving our customer’s lives as soon as possible?”
We need to think about and understand how our projects are going to help people. And we need to better understand how our work fits in with everyone else’s work to get in the hands of our customers. Take time to learn how the other systems work, how components interact with each other. Plan ahead to make sure the whole project lifecycle is being considered, and to make sure other teams are ready and available to help. Consider our job complete, not when it’s built, but rather when it’s helping a customer.
This comes from a mindset of eagerness and opportunity. It comes from leaning in, understanding the customer journey and having empathy. We should be excited about what we are building and want to get it out there to see what it does. Feel proud about what we’re doing for people, because we can see and understand how it makes their lives better. We should feel that we can explain in a very simple way — in an elevator conversation with a customer — how what we are building is going to make things better for them.
This shifts us from focusing on tactics to focusing on strategy and narrative. It gets us thinking about the value we are creating… thinking about the opportunity in front of us. It gets us thinking in new ways… maybe there’s an easier way to build this. Maybe there’s a better idea that solves the underlying need we are trying to address. We build smarter, faster, and better when our motivation comes from the good things in front of us.
It’s also just a lot more fun.