Back in March I asked the Podia dev team these questions:

1. If someone asked you to describe the Podia dev team, how would you describe us?
2. What do we do that other teams don’t (or what don’t we do!)?
3. What principles do we hold but rarely discuss?

As the team had grown slowly over the year, I wanted to codify the culture we’d formed. I wanted to verbalise those unspoken guidelines so we could share them with new hires and use them to make clearer decisions.

It was important to me that this was drawn from the team itself and not imposed “from above”. I wanted the team to describe itself, using their own words, instead of me describing us from a single biased viewpoint.

I primed the team by asking these questions in 1:1’s (not expecting deep thoughts—but just to start the process), then dropped them into KnowYourTeam, told the devs to expect a “big ‘un” this week and to spend some time thinking about it. To my delight, the team members wrote pages of responses and I could immediately see common themes emerging.

This was it! This was how I felt about the team too. I set about compiling the responses into something approaching a coherent document for the team. This would be our charter, describing the high-level principles by which we operate as a team.

Presented below is the first Podia dev team charter in all it’s glory (with just some minor redactions). It’ll change and evolve over time as we reflect on it and grow as a team but this is what we have now…

No team exists in a vacuum so first we need to establish context for the team…

We’re a startup

We’re a startup. The business is [redacted statement about the current market & financial circumstances]

We’re a small team

We’re 5 years in and the product development team is only 5. Small teams, like small countries, have a culture of their own, with many advantages that larger companies lack. But… like those small countries, we’re more resource-constrained than our larger brethren.

We might not be ”small” forever, and we’ll definitely grow in time, but we’ll always aim to be small for the impact we deliver.

We’re a remote team

We work across countries and time zones, and usually from home.

We build product-sized features

Podia is an all-in-one solution for creators to sell their digital creative work. When creators choose Podia they switch away from or avoid choosing a multitude of other tools. This nature means we ship product-sized features. We ship a Mailchimp, a Drip, a Teachable, a Gumroad, a Patreon or an Intercom—not as a new product like those companies did but as an integrated feature of Podia.

Our principles

We are full stack

We’re all ”full-stack” developers but we all have specialities and leanings towards one end of the spectrum or the other.

We choose boring tech

We choose ”boring” technologies — a.k.a. reliable and well-proven technologies like Postgres and Rails. Another way of putting this is that we “spend our innovation tokens wisely”.

We prefer to use the boring tech we have (like Postgres full-text search) rather than bringing in a new tech like ElasticSearch.

We follow ‘The Rails Way’

The largest contributor to our ”boring tech” stack is Rails and we try to stick to ‘The Rails Way’ as much as possible. Our default language is Ruby and our default toolbox is Rails. We’ll always choose those tools and patterns first in a pragmatic approach but we’ll bring in new ideas where we see value in them (see next point).

Following The Rails Way enables us to ship features quickly, and with the minimum amount of stress, by keeping the codebase well-organised, predictable, and coherent. Embracing ‘The Rails Way’ is a major contributing factor in our ability to ship such a large feature set with such a small team.

We also invest in new tech

Not everything can be done purely within The Rails Way and we will always explore new technologies. Most of us have side-projects or keep up with interesting new technologies and love sharing what we learn with the group. We make sensible bets on solutions to painful problems we have right now (we don’t imagine problems to justify a solution just because other companies use it).

Looking to new technologies fits with Podia’s core principle of ”Always looking to the future”.

Some examples of times we’ve successfully strayed from the The Rails Way has been the introduction of React for messaging, Interactors for organising and reusing code, and ViewComponents for encapsulating UI logic.

Done is better than perfect

Given our size and phase, we cannot polish a feature until it’s perfect. Perfect code that hasn’t shipped hasn’t been tested and hasn’t delivered any value to us or our creators. We prefer shipped code over unshipped code; good code now over perfect code later.

We recognize that nothing is perfect, there will be bugs, and not every bug is a hair-on-fire emergency.

We’re all in this together

We all own the code and take collective responsibility for it. There’s no place for ”not my job”-ism on the team (though recognising we all have different areas of familiarity and expertise). When one developer ships code, we all celebrate it, and we all support it in the future.

Blameless learning

Mistakes happen but what really matters is how we react to them, what we learn from it, and that we improve over time. We don’t blame each other, finger-point, or deflect responsibility. We don’t allow ourselves or others to wallow in our mistakes.

We empathize and assist. We encourage. We advise. We provide feedback with compassion, curiosity, and without blame. This is us, the team, working against the system and solving the code. In an interview setting, the whole team would sit on one side of the table and the code would sit on the other.

We trust each other

We are both trusted and, in turn, trust each other.

We’re trusted to get our job done, to do what we say we’ll do, to build with our best effort, to make our best decisions, and we’re trusted not to abuse the autonomy we’re given. In turn, we trust that others will do the same.

We’re open with each other

We share what we’re working on, what progress we’re making, and what we’re struggling with. This transparency creates trust within the team and allows the team to help mitigate issues before they become bigger problems. We also open up those things which make us, us—our authentic selves—and don’t try to hide that behind a façade.

We will also be aware of what we’ll be working on next and how the roadmap is changing. Our management will be open about new problems, strategies, and changing circumstances as early as possible.

We support each other

We support each other. We are kind and helpful and offer to lend a hand. We make ourselves available to help, whether it’s advising, pairing, bug fixing, rubber ducking or just being there for another team member.

We look after ourselves and each other

We don’t have fixed working hours so we’re free to work at a time and pace that’s most productive and convenient to us. We respect that we all have lives, hobbies, sports, and responsibilities outside of Podia. We prioritize our own well-being, including our mental and physical health, knowing that this has benefits to ourselves, our team, and Podia as a whole.

We do not work weekends (usually).

We have fun

This is another directly ties to one of our core Podia principles: we aim to maintain a fun & friendly atmosphere among the team. We share memes, jokes, our kids and our pets, and our music that no one else likes.

We write

Written communication is our primary medium, whether it’s fast-paced conversations in Slack, explanations in Github, documenting processes in Slab, or long thought-out pieces in Basecamp. Clear-but-concise written communication is a critical trait of our team.

We challenge each other to make better decisions

We argue as a way to reach a better decision: we listen to each other’s viewpoints respectfully, explain our code and choices, weigh the pros and cons, empathize with differing viewpoints, look for consensus, and ultimately agree a decision—even if it did not go our way. We argue the technical merits not the personalities, and we try to keep these discussions meaningful (no bike-shedding).

It’s important that all team members feel comfortable challenging approaches but that we’re all open to changing our minds. Strong opinions; loosely held.

We give feedback

Feedback is one of the ways we grow as individuals. We seek it out from others with humility. We provide honest, considered, and constructive feedback both when we’re asked (like in a PR review) but also unprompted when it’s helpful to do so.

We support other teams

We are not an island: we work with other teams in the company to fulfil our mission. Our support team in particular helps us understand when, how, and why the app is not fulfilling our creator’s needs. We help them make our creators happier, resolve their problem, and delight them with new features.

Even when other teams add to our workload, we treat it with the understanding that the broader mission of the company, and our creators in particular, are why we have jobs.

We work independently or together

We may work together in pairs, even small groups, or independently. We’re all extremely capable of delivering large features working solo but we also have the communication and collaboration skills to work together.

We minimize processes

We don’t have scheduled meetings, we don’t do daily stand ups, we don’t have lock-step processes like sprints, we don’t do deadlines (unless externally imposed), and we avoid over-planning and detailed estimation. Where we have processes they are lightweight and without ceremony (i.e., the Podia release process).

We defer to the principles listed above in preference to any complex process.