After more than 25 years of coding and 20+ years in product teams, I have come up with the following cultural values I care about most. That said, as I continue to grow, this list will most likely evolve as well.

Customer First

We’re not just an engineering team. We’re a product team, and we put customers first. That means we don’t just write code. We solve problems that matter to our customers. Understanding the bigger picture is crucial.

  • Engineers are involved from the start, and your voice matters when deciding what features to build or tweak.
  • We don’t “throw code over the wall.” We own the product end-to-end, from the first line of code to how it performs in the hands of our customers.

No Limits in Transparency

Our guiding principle, especially in a fully remote or a hybrid setting, is having no limits in transparency. Every member of the team should feel empowered by the free flow of information and the unfiltered truth.

  • Our team chat is a transparency hub. Discussions relevant to projects or team matters happen in open channels, so everyone is in the loop.
  • When a key decision is made, it’s documented and shared. We explain the when, what and why.
  • If project scope, deadlines, or anything else shifts, you’ll hear about it right away.
  • If a team member needs sick leave, vacation, or any similar absence, they inform the team in team chat so planning and coverage are handled together.

The Importance of Context in Communication

In a remote team, most communication happens in writing. But words without context can lead to confusion or misinterpretation. That’s why we emphasize the importance of providing context in all our communications.

  • If you’re discussing a problem or proposing a solution in team chat, give enough background. Assume the reader doesn’t have all the pieces of the puzzle you do.
  • When you submit a code review, explain not just what the code does, but why it’s needed and how it fits into the bigger picture.
  • In the issue tracker, include context and clear acceptance criteria.
  • Include an agenda in meeting invites, or at least state the objective. This helps everyone come prepared.

Taste in Design and Execution

“Taste” isn’t just about how things look. It’s about how they work, how they feel, and how they meet customer needs with elegance and efficiency.

  • We follow design principles that prioritize customer needs and experiences, just as much as we prioritize clean, effective code.
  • Every feature, every interaction, and even every line of code should be approached with the customer in mind.
  • Whether it’s a new feature, a piece of code, or a customer-facing interface, we review each other’s work critically to ensure it meets our standards of taste.

Strive for Elegance

In our world, simple doesn’t mean easy. It means clear, intuitive, efficient, and manageable. Every line of code, every architecture choice, and every feature should be as simple as it can be.

  • In code reviews, we don’t just ask if something works or if it’s clever. We ask, “Is this simple enough? Can it be made even simpler?”
  • Before we dive into building, we document the planned architecture and features, keeping an eye out for needless complexity.
  • Every team member is encouraged to question decisions. If something seems too complex, speak up.
  • We revisit old solutions regularly. Even if it was the best we could do at the time, there’s almost always a way to simplify further as we learn and grow.

Beware of Accidental Complexity

As we aim for simplicity, it’s mandatory to identify and avoid accidental complexity that creeps in without adding real value.

  • Extra layers of abstraction, redundant code, or over-engineered solutions are often red flags.
  • Before adding any new element to our code or architecture, we ask, “Why is this necessary?” If there’s no clear answer, it’s likely accidental complexity.
  • When we run into issues or bugs, we dig deep to see if accidental complexity is at play. If it is, we don’t just fix the issue. We simplify the system to prevent it from happening again.

Better Than Yesterday

Here, we raise the bar every day. Every line of code, every document, and all architectural decisions should reflect a commitment to being “Better Than Yesterday”.

  • Whether it’s a small bug fix or a major feature development, we welcome improvements that push us to be better than we were the day before.
  • Every pull request is more than a merge. It’s a learning opportunity. We review not just for errors but for improvements, always asking, “Is this better than what we had yesterday?”

Final Note

This playbook is not static. As I learn, I’ll refine it. But the goal stays simple. In order to build better products, we need to improve our people, values, communication, and expectation management.