The beauty of working in a small and high-performance team
We don’t have long-lived branches other than master
The master branch is the single source of truth. It is always on, always green, always testable, always measurable, always deployable.
We don’t assign developers to repositories
Instead, we encourage every developer to contribute to every repository. Developers are more than welcome to stretch themselves to other areas. They might have a focused area, but the line is very vague.
Having said that, it turns out to be quite productive. The team proactively pick up tasks on the repositories they are familiar with or interested in. If one decided to take a challenge but have questions at the beginning. Just ask in Slack or tap your mate on the shoulder, questions will be answered quicker than you thought.
We don’t have User Acceptance Testing (UAT)
Every PR merge to the master, our CI/CD will automatically validate, build, deploy to the production environment, test, and broadcast the result to Slack.
Move fast!
We don’t blame
We are not afraid of failures. Instead, we think fast, move fast, fail fast, learn fast, so that we can succeed fast.
What’s done is done. Pointing the finger of blame doesn’t solve anything. We track it, review it, dig its root cause, ask ourselves how to avoid it happening again, take actions, and review if the actions work.
We don’t write a wall of text on cards
If you work in a complex organisation, collaborate with multiple stakeholders, or work as a consultant, you might need it to protect yourself and the team.
In a small team, however, we try our best to avoid those admin costs. We capture just enough information, mostly requirements, and timelines if there is any, and bring it to the team. Give the team space to ask questions, explore solutions, discover alternatives, or maybe even redefine the requirement.
We don’t do hours long sprint planning
Who would like a 2-hour planning meeting fortnightly? Who likes sitting in a meeting room with 10 people? I don’t. I’d rather play poker cards with my friends at parties. The ugly truth is, in most circumstances, it is necessary.
However, there is always a way to avoid it if you adopt the “slow cooking” approach. The team does their best to keep the cards well written, put context if they know, estimate the T-shirt size, tag cards, pick up cards proactively. That way, you can always keep your backlog healthy and up to date.
We don’t tell the team what to do
Instead, we bring context to the team, we tell them why it matters, we share our vision. We give them a stretch goal to chase. This is where innovation comes from.
We don’t ignore technical debt
We constantly pay back Technical Debt to keep our technical set-up robust. We constantly simplify our codebase — burn legacy, delete unused. The codebase we own is always healthy, up-to-date, ready to deploy, easy to maintain, and easy to develop.
We also don’t over-bake our technical solutions
We are more focused on moving needles and satisfying customers. We invest just the right amount of work in paying off technical debt. Our goal is to deliver customer value, not to have the shiniest technical setup.
We don’t split people into Operation and Innovation
It is a common way to divide people by strength. One team focuses on operational efficiency, whereas the other one focuses on innovative initiatives and experiments. Sure, it will give you the best outcome in the short term, but it will fall over eventually.
We work as one team and success as one team. We try our best to find the balance between maximising productivity and growing people.
