In the early days of a startup like Paladin, you’re trying to figure out who your customers are and how your product can help them. In this phase, startup engineering is often optimized for shipping code — we want to get new ideas out the door quickly to unlock new customer segments and test new value propositions.

This, of course, comes at a cost. Technical debt can accrue, processes are left wanting and architecture ad hoc. Developer productivity and experience can suffer. This tradeoff is probably the right one to make while seeking product / market fit but, if left unaddressed for too long, can bring things to a halt.

From “DesignStaminaHypothesis” by Martin Fowler

At Paladin, we are reaching the inflection point Martin Fowler identifies above as the “design payoff line”. We’re starting to think about the bigger picture. On the engineering team, this means that we’re asking ourselves questions we were too busy to ask before:

What parts of our process are underdeveloped? What can we automate? What can we outsource? What should we measure? How do we address technical debt? What are our expectations of each other? How can we hire great people? How can our codebase be a joy to work with?

In short: how can we be a great team? What does being a great team mean to us?

To find out, we conducted an exercise:

Imagine you have just joined a new engineering team. As you settle in, you realize — this team is awesome! Now, ask yourself — what makes them so good?

How do they work together? How do they treat each other? What is the codebase like? What are their practices and processes?

From our descriptions of this imaginary awesome team, we drew common themes and from those themes, we composed a set of values that describe the engineering team we aspire to be.

Respect, Challenge & Celebrate Each Other

We treat each other with courtesy and kindness. We give each other the opportunity to express our ideas. We listen to what each other has to say. We understand we each have a unique background and experience that gives us a different and valuable perspective. We respect each other’s time. We celebrate each other’s successes. We support each other’s efforts. We respectfully challenge each other in order to grow and improve, to try new things, evolve our thinking and make our team stronger.

Write Code that Matters

The code we write should be code that matters, not code that becomes a liability. Code that matters is a force multiplier that lends new capabilities to our users, our colleagues and to our future selves. Code that matters unifies concepts and solutions that are core to Paladin’s business while outsourcing everything else. Code that matters is clean, well-structured, documented, tested and follows a consistent style and architecture.

Take Ownership & Responsibility

Everything important should have an owner. Owners are leaders, and we empower them to make decisions and lead projects to success. We care about the outcome of the projects or initiatives we lead. We prepare properly and rally our team in order to bring about positive results. We communicate our progress and are honest about the challenges we are facing. When we encounter problems, we don’t wait for others to act — we take initiative and drive toward resolution.

Process, Automation & Continuous Improvement

We want to spend our time on high-value work. Creating documented processes around our operations gives us structure within which we can be creative and efficient. We automate low-value and repetitive tasks. We constantly evaluate and measure our processes and tools in order to improve quality and efficiency.

Experiment & Learn

When we are unsure of the path to take, we use experimentation to gather data to aid our decision. We seek out and value feedback as a way to test our ideas and help us improve. As craftspeople, we have a desire to continue to study and improve our craft. Learning new tools and technology keeps us invigorated in our craft and gives us the opportunity to apply new techniques to our work.

Be of Service

The engineering organization exists to serve our users — both our customers and our colleagues. Any engineering undertaking should begin by asking what value we are delivering to our users. We are responsive to their needs. We provide well-defined interfaces for how our colleagues interact with us, what their expectations of us can be and provide transparency into our process.

These values articulate a shared vision for the kind of team we want to be and give us a set of guiding principles for the journey ahead!

We’re hiring engineers! And check out our jobs page to see other open roles!


The Engineering Team We Want to Be was originally published in Paladin on Medium, where people are continuing the conversation by highlighting and responding to this story.