My Principles

Delivery always comes first

No matter what you're doing or how important it is, the delivery will always come first. Did you promise to deliver something until a deadline and you won't make it? Inform your team and your manager so we can create a plan together about new deadlines and plot scenarios. Give room for people to process the information. Don't tell people on the last day.

This principle doesn't mean we need to deliver things at any cost. Other principles must be respected also. If you see that the deadlines are hurting other principles, like doing the things right, talk with the team about it.

It's also important to state that the delivery goal must be clear. Delivering a PoC means that you can do stuff in a more unorganised way once it's not something that will go to production by any means.

Be solution oriented

We solve problems. Solving problems is what makes coding fun. Code and Software are the tools we use to solve problems. All tasks must have a clear problem to be solved. If the problem is not clear, try to make it clear by writing about it or documenting it.

Doing the things right is more important than doing the right things

There's no quick fix. If you do the right things in the wrong way it will take you double the time to fix them. Maybe even a full refactor of the code will incur a big cost to our customers or the company that will make us feel bad about why we didn't do this right since day 1.

It doesn't mean that we need to find a perfect way of doing stuff or over-engineer things. But the usage of industry standard practices and team guidelines is important so we are sure we do the things in the right way.

Be remote-first

This means we focus more on whether people are delivering solutions rather than if you are present at meetings. It doesn't mean you should not communicate and collaborate with your teammates, but some things get more clear when you are remote-first.

You met a customer in the office. The conversation was good and many points were aligned. We are remote-first. So people remote don't know the meeting happened and the outcomes of it. Write a short summary on Slack and inform your peers about it so they can feel part of the organisation.

• Prefer async discussions over meetings
• Don't try to book meetings for discussing stuff or getting help — post in Slack so people can search and find answers
• Record meetings and presentations and post them later — the team will feel they belong
• Over-communicate when you are remote

Be open

• We are allowed to talk whatever comes out of our mind
• We are allowed to make dumb questions
• We are allowed to say how we feel about decisions and updates
• We are allowed to disagree — discussions don't need to reach a consensus
• We prefer public channels in Slack — private channels are only for very sensitive information

Don't ask to ask. Just ask!

The team is together. The team works towards the same goal

At the same time we are open, remember we as a team work together towards the same goal.

We are allowed to disagree, but we're not allowed to be misaligned. If a decision was made, we must cope with the decision and give our best effort to make it succeed. Don't try to play against it or undermine decisions. Sometimes you may be missing context to see the big picture.

People are allowed to speak up. Don't misjudge them by trying to imply they had some back-thinking when they told something. Always assume people want the best for the organisation and their peers.

Software development is a process

A process must be documented, standardised and streamlined to its maximum performance. Deviations must be documented and treated. All of this sounds very ISO 9001, and it is.

This principle is the reason why this page exists. It's a way to document processes and principles so they can be discussed, challenged, and improved over time. A process that isn't written down can't be questioned, and a process that can't be questioned can't evolve.