Principles

The following principles are department based (as opposed to company wide). This means that we came up with them ourselves, agreed upon them and are now using them on a daily basis to do things in alignment with each others actions without the need for a lot of rules, policies or supervision. A lot of these sound like open doors but the difficulty is not in creating them but to actually use them in day to day behaviour.

Simple is better than complex

Design simple, repeatable, and reusable solutions. Simplicity saves documentation, training, and support time. Simplicity also increases the speed of communication, avoids confusion, and helps to reduce the risk of development and operational errors. If the implementation is hard to explain, it’s a bad idea. If the implementation is easy to explain, it may be a good idea. Identify accidental and essential complexity; remove the first and optimize the latter.

Done is better than perfect

Do things correctly but not necessarily until perfection. Keep in mind the 80-20% rule, which states you can do 80% of the work in 20% of the time. Use your judgment to make the call to continue beyond 80% or to stop and work on something else. The system is optimal when the cost of improvement is higher than the benefit.

Proactive is better than reactive

Take the initiative to send information rather than waiting for people to request it. Look at graphs to spot trends instead of waiting until the monitoring system starts sending out alerts. Try to be an engineer instead of a firefighter. Prevent becoming the limiting factor through continuously reviewing what we have and innovating on that.

Enable, don’t restrict

Try to prevent the knee-jerk reaction of restricting if something goes “wrong” or other than you may have expected. Instead, look at why this happened and think about what you could have done to prevent this or change its outcome. The other person rarely has bad intentions. Quite the opposite, he or she is also just trying to add value for the company and do his or her job. Look for solutions where you don’t restrict them. Think about improving communication, information radiation, presentation, documentation, tooling, and education to help them do more and do it even better.

Enable people to do as much as possible autonomously as this will greatly improve the efficiency with which things are done. Get out of the way as much as possible instead of creating barriers. Do not become a professional roadblock.

Think in solutions instead of problems

We can do anything if we set our minds to it. Have a positive attitude in general, and specifically towards new challenges and ideas. Embrace and reinforce the ideas of others and look at how they can work instead of telling why they may not work. Even if the plan is not great as a whole, it still stimulates a constructive conversation where something (even) better may come out by reusing great components from the original plan.

Assumption is the mother of all f#$@^ups

Not all assumptions automatically lead to a fuckup but there is an assumption at the basis of every one of them. Try to make sure you know instead of assume. This is what being data driven is all about. You should still be able to take a calculated risk once in a while but be aware that you’re basing it on an assumption rather than a verified fact. Try to be as explicit as the situation allows. In case you do have to make an assumption, make it conscientious, explicit and communicate it openly.

Being implicit leaves room for the others to fill in blanks and do as they see fit. In short you assume the other to do the right thing. There are lots of situations where this is wanted but be aware of it and try to start from the point that explicit is better than implicit.

Engage early and engage often

Share ideas and information about plans and new technologies. Gather operational requirements when gathering functional ones. As a project progresses test deployment, backup, monitoring, security, audit, performance and configuration management as well as application functionality.

Failure is an event, not a person

Failure is bound to happen some time during some, or maybe even any, project. Try to learn from these failures, share the lessons you’ve learned and prevent Spil suffering from the same cause and/or failure twice.

Create post mortems that are blameless and solely geared towards learning. It’s often not the failure itself that people fear but rather the consequences. Blamelessness will greatly help in getting people to talk freely about what happened.

Try to prevent failures in production. Think about how you can prove that something works like designed before you run it in production.

Pursue growth and learning

Challenge yourself to keep learning and to keep obtaining new skills. Practice deliberately. Join in on interesting and challenging projects or propose them yourself. You are and always will be responsible for your own growth but Spil will try to support it wherever possible.

Embrace change and drive improvements

Change is inevitable in general and even more so at Spil. Try to find the balance between being conservative, careful and changing things. Try to change one thing at the time and look at how it affects the surrounding systems. Changes come from all directions so you should not only just deal with them, drive them as well by proposing new projects, sharing your ideas and looking at how to improve existing systems and processes. Try to get the smallest possible piece of a system to work first and then iterate on that. If you change something, try to think of the consistency of the rest of the system and update it where necessary.

Leave a Reply