Why do we write software? To produce code or to solve problems? Are we solving problems for ourselves, or for others?

Code is a tool, a means to an end. It is something you can leverage to solve problems.

Imagine standing in a workshop, plans sketched out for a new project. You gather the tools you need and start working. There are hundreds of different types of saws, and all of them could get you to your end result. Not all with the same path, not all with the same efficiency, but with enough time and patience, they would all work.

So the real question becomes: how do I value my time and energy?

I could spend tens of thousands of dollars on a CNC machine (a computer-controlled cutting machine that automates precise cuts) and have it do most of the work for me. Or, I could spend almost nothing on a cheap hand saw and spend hours cutting by hand. Either way, I have to choose the happy medium. There is no perfect world.

Even with a CNC machine, I lose the ability to iterate easily; I have to know the answer ahead of time. There are always tradeoffs. I have to ask: what imperfections am I willing to live with?

At the end of the day, I know the result I want. I weigh what I value most about the journey to get there, and then I get to work.

Writing software is no different. We solve problems. Code is just a means to an end.

From individual to team values

In my workshop, though, it is just me. I can prioritize my own values, however I choose.

But what happens when I am working with three or four other woodworkers? What if one of them is a CNC expert? Or what if one of them is crazy good working with hand tools?

Now the question shifts: how do we determine which values to prioritize together?

The answer is different for every team, but one thing stays true: the values must belong to the team, not to individuals.

Finding that balance of what works for all of us, and letting go of "perfect" (read: often our own values), is what makes collaboration possible. We are all working together to reach the same end result. So we find the optimal path together, and we build that balance into our work.

Scaling teams without building walls

How does this scale? I think this is the point a lot of people and teams get stuck.

Managing one team’s values and how they do things is hard enough, let alone as that scales to multiple teams and entire departments. This is where silos begin to form. We tend to build walls because it's "easier".

What happens if you change your perspective?

What if instead of looking for the complexities of managing every individual’s values, with every teams values, with the org’s values, it was one big team first?

If you start from the outside looking in and focus on the people around you, the perspective starts to shift.

Picket fences, not walls

Imagine picket fences instead of walls.

Would you see isolated teams, or people working together toward a common goal?

I want to see my neighbors. I want to talk to them, I want to learn from them, and help them achieve their goals. I want to see someone struggling to trim their tree and offer my ladder and chainsaw.

Because when they thrive, the whole neighborhood thrives. And, maybe selfishly, my view looks a little nicer too.

Build a thriving neighborhood

If we can take down walls and replace them with picket fences, we begin to see the people behind the work. We build empathy. We build shared responsibility. We see the whole neighborhood for what it could become: a place we are proud to be part of together.

Let's build picket fences.