What I say to people who say, “that’s the way we’ve always done things”.

Whenever I start thinking about why I like our dev culture at EDITED, my mind goes straight to the story of Schlemiel the painter.

It’s more of an anecdote, and it’s fairly straightforward; a man named Schlemiel is hired to paint a dashed line along a newly paved road. On day one he manages to cover a fair bit of ground, but every new day he accomplishes less than he did the day before. When asked why, Schlemiel wipes the sweat from his forehead and indignantly points out that every day the can of paint gets further and further away.

Essentially, he didn’t realize the can could be picked up and carried along the way. Schlemiel, we find out, is no great thinker. But if we were to change the story slightly and say instead that his employer forbid him from moving the can for no real reason, we’d call Schlemiel something else.

Maybe even a software developer.

I’m kidding, but only in a half measure. In the world of software development we’re used to hearing stories of developers forced to use tools or systems despite their obvious flaws. And why? Any number of reasons, all familiar, all fairly unsatisfying.

“That’s the way that we’ve always done things.”

“We’ve already paid for it. We must use it.”

“My boss loves it so politically speaking, I also love it.”

“What? Learn something new? Me? I’m good, thanks.”

Personally, I feel these issues result from a lack of clarity around who is responsible for deciding what tools are needed to do the jobs optimally and who is culpable if the job is not done up to company standards. When most companies talk about “responsibility”, what they’re really talking about is culpability. That sets the stage for a lot of finger pointing when things aren’t working as well as they should.

At EDITED, we’ve taken an interesting approach to avoiding that misinterpretation. We’ve made one group responsible for both things: us. The product and engineering team as whole. We run ourselves as a collective and get to determine how to approach our tasks independently. But it also means we’re completely culpable for the ultimate success of our product.

We have the trust and the freedom to choose for ourselves what we think is the right library, framework, xyz… but it also means we have the responsibility to choose wisely and use them correctly. It’s not a license to go out and buy a bunch of technology for no reason!

Outside of picking our own tools, one of the greatest benefits of our system is our ability to spend time looking out for potential “paint cans” and eliminating them before they start slowing us down.

It’s like widening a perfectly adequate tunnel before traffic increases. By planning ahead we avoid future traffic jams that could potentially negatively impact the user’s experience using the software you’re building.

Another metaphor, stolen from ice hockey, would be to skate to where the puck is going to be, not where it already is.

I know that view may seem a little idealized. No matter how you allocate responsibility there’s always pressure to go faster and add new features to your product. Outside of your team, the news that you are moving the product pipeline to Apache Storm, moving from Backbone to React or doing anything else that involves a major restructure of code might not sound like the most exciting news to your sales or customer success teams, who are hungry for new features and user-facing upgrades.

We’re not tone deaf to that, but at the same time we like to remind ourselves that a product that works and delivers results builds trust with users more than a product with more features but shaky usability.

By owning our own product pipeline we’re able to structure growth intelligently and scale the product responsibility. That includes taking time to measure for bottlenecks, investigating alternative ways of doing things and most importantly — building prototypes we’re comfortable throwing out the window if we have to.

In fact, when we take the mindset that it’s okay to build things we may not use in the future, we usually end up with something that works better!

We’ve also had to make some tough decisions ourselves. For instance, what to build next and what to say goodbye to. Knowing which features to retire is as important as knowing which to add!

But at the end of the day, we’re holding the can in our hands. And we can move it wherever it needs to be.

Sujay Mansingh is a Data Architect at EDITED. To see what the dev culture he’s talking about looks like in practice check it out online and let us know if you want to get together for a coffeee.