Ship it and iterate often bugs me because sometimes it really works and sometimes it really doesn’t.
Summary being the example of where it needed to be iterated on more before release from labs. It could have been shipped as it was, had a couple of iterations and then been really useful when launched. As it was, it was not very useful at all at release and felt very rushed to fit the “Ship it and iterate” ideal.
This isn’t always the case and there have been a lot of features that didn’t suffer this problem. I personally feel that sometimes it needs to be treated on a case by case basis rather than “Ship it and iterate” no matter what
As mentioned in the article these are not rules to be dogmatically adhered to, but we believe they are generally-applicable enough to be a useful guide
Great blog post! I think there’s a few wise words there that would benefit any engineer.
I love “Solve problems at the root”. I think it’s fundamental to know deeply your application, as it’s the only way to improve/fix it in the right (and often fast) way, and implementing a good set of tests helps a lot to understand how the application works.
Also it is very important to be flexible and open to changes, it doesn’t matter how many hours you spent on a solution, if it doesn’t work, you need to change it, or add it to your technical debt.
Something that I often struggle, it’s to work for companies that knows how to proper handle the technical debt. Too often they behave like countries, thinking they can increase their debt forever
Re. Solve problems at the root
And don’t forget to consider whether the root cause is a problem in the business process itself rather than technology.
@Oliver, what do you think about adding accessibility to the engineering principles?
It is mentioned in this blog post, but should it be an official principle?
Agile…is the buzzword I hate.
For me, it’s “my bad”, but that’s a whole different topic, so…
I was hoping could you share some insights into how Monzo came up with these princilpes, was it something that came from the management structure downward? or was the whole team involved with the building up of the things the engineering team should hold true.
Also thanks for sharing this it’s really very insightful! I am trying to help my team build up a similar list of values
@oliver, hey — is the culture with engineering, the same in other teams? For example — CS or Design? Are all the people in the bank thinking the same way — trying to fix things. I know people in different disciplines will have a different approach to tasks and solutions etc.
This is really useful to see.
So underneath these principles are there a 1000 processes all becoming overgrown and incredibly difficult to maintain or is this really just it? Principles and then autonomy?