We have a great developer team. We make software. We also invest a lot of time and energy in ensuring that the work we do is excellent. It goes without saying then that our development team is a crucial part of our business.
As a team, how we work gets just as much attention as the work we do.This mindset recently played an integral role when we rebranded our company to better align with our values, the way we work, and our thoughts about software.
I’ve always regarded my job as a team leader to be a facilitator of great decision making, not just the one responsible for making good decisions all the time. Since I’m nowhere near technical enough to code anymore, I take a similar approach to enabling our development team to do great work. I help create an environment that inspires success—the rest is up to them.
Over the years, first with WooCommerce/WooThemes and now with Conversio, my approach to working with development teams has evolved. Here are a few pillars that dictate the way my team works and collaborates today.
Our team is fully remote, which means that no one can be that pesky manager trying to backseat pair programming or micro-manage projects. All members of the team have the space to tackle challenges in their own way and (mostly) at their own pace.
It’s true that diamonds are crafted under immense pressure, but that approach generally does not bode well for software teams. Fixing the odd bug under pressure is probably okay, but being creative and solving a problem in the most efficient way possible requires time and space.
We’re only two years old, and though we’ve built quite an extensive product in that time, it’s by no means a mature product. We’ve had to accept that neither our development processes nor our code has been perfect.
One of the conscious decisions we’ve made has been to pursue building features while creating better customer experiences. This doesn’t mean that we’ve taken on a lot of technical debt or had to compromise on scale; we’ve just prioritized the customer-facing parts of the development process. This has helped us work efficiently while learning fast and fixing our mistakes. This benefit alone seems like a better alternative than having theoretical discussions about coding standards and supposed best practices.
There are many tools and services out there that help young software companies scale up very quickly. The only problem is that the cost doesn’t scale indefinitely, which means you’re inevitably stuck in that discussion rather than building your own solution. We try not to worry too much about our growing infrastructure-related costs. While a rewrite or refactoring of product parts could probably curtail costs, it would come at the opportunity cost of not working on other things.
Our developers have the trust of the whole team to invest monetary resources such that they are enabled to get the job done in the best way possible. Sometimes that means opting for higher tiers of services in the short-term to give us time to eventually refactor a part of the product. Other times it means delaying a new release or urgently building better scaling into the product to avoid those extra costs. No development team should have to be burdened by monetary decisions, regardless of which route they take.
This is one of those things that founders say without offering much explanation. Instead of me tooting our own horn, I’ll pass the microphone to one of the developers on our team:
“[Members of] the team all have initiative and are driven to make the product better; we are all invested. I don’t know any one of us that would think twice about coming online out of hours to fix something or help a customer, [and] that attitude is what makes our day-to-day better. We have the freedom to expand our knowledge and experiment, in turn increasing our skills and helping us build better software.”
The worst thing that can happen within a team is a culture of apathy, finger-pointing, and “I told you so.” We’re all human and we all make mistakes. Even the best developers still create software with bugs.
When our performance is about the team and our ultimate goals, it’s much easier to respect every individual and give them the opportunity to express themselves through their work.
We try to be customer-centric in everything that we do, which means that at various times you can find the whole team helping out with customer support. It’s hard to wear multiple hats and switch between doing support and focused programming time, though. We solved this by scheduling on-call developer weeks, where one developer is the primary contact for our customer success team on any technical issues that pop up. The other weeks they can focus on their own code.
It might seem that we have this well-defined process for the way we make software, but the truth is that we have very little in the way of a defined process. Most of the time things probably look pretty messy from an outside perspective. This has been a very purposeful pursuit for us, though. We try to optimize the way we work for every individual, as well as for team and company goals.
I think we’re beyond the days when a company and team can expect individuals to adapt to them, but the reverse is never true. We’ve tried to create a space for everyone on the team to do their best work in the best way they see fit.
Adii Pienaar knows a thing or two about the inner workings of developer culture. Pienaar is a serial entrepreneur whose career took off with the co-founding of WooThemes and WooCommerce. He’s worked on countless projects since then, and made plenty of mistakes along the way. Today, as founder of Conversio, an all-in-one marketing tool for BigCommerce stores, he’s taking the lessons he’s learned and applying them toward growing a better, healthier, more content team of developers.
Connect with Adii on: Twitter | LinkedIn
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
