Hello dear reader!
As you know if you read my blog I was a startup guy for many years, and it was a life changing experience. Over the years I have come to realise how key that experience was, both for good and for bad, from feeling a complete ownership of the project to looking at every last cent spent.
I decided to compile this into what I call my “Leadership principes”, this is what I try to convey to the people I work with and what I have seen bridges the gap between two worlds: One with limitless energy and a mindset to do anything to get things done, and another that should be scalable and sustainable in different orders of magnitude.
Current situation
Most companies currently have an asynchronous development model where engineering gives capabilities to teams. This is based on the premise that teams should be given everything they need to develop and enable technologies they decide to use from a given stack.
It is worth noting that while the capabilities of the model are fairly thorough, especially on the on-premises side of the equation, there are several points that could be considered problematic:
- Many companies use the same model for on-premises as we are for Cloud, making it cumbersome and sometimes costly to run. This is what is comminly referred to as a “Lift and Shift”, since you are taking what you have and directly putting it on cloud.
- No one is reviewing the technical decisions taken by the different teams, but we are being held accountable for them. For instance, if a team decides to use Mongo DB Atlas, they are given the freedom to do so, and the company is forced to foot the bill for that decision.
- Teams are evaluated on their potential to deliver, not for their technical excellence. In an increasingly competitive world, we need teams to be accountable of everything, not just delivering the product.
- The model, whilst comfortable and controllable, sets a baseline for everything, one that bureaucratically and conceptually is difficult to break, this benefits mediocre teams and guarantees everyone is in line, but also scares off extremely productive teams who would like to propose different approaches.
The way forward
Taken this into account, there are a number of principles that should be the corner stone for our generation in my view. This would be the following.
“Goodbye Frameworks. Hello Layers”.
Up to now, companies usually build framework that allow developers to seamlessly transition from on-premises to cloud and vice versa, with capabilities like observability and authentication build right in, this is a mistake. The effort to develop such frameworks is huge and a very painful task. It is the same problem Google run into with Android, by allowing companies to modify it and ended with a user base scattered across a myriad of versions that was almost impossible to control and update. In the end users have preferred cleaner versions of Android that are released directly by Google, simplifying development, and ensuring users are always on the latest release.
Applying this to what we currently have, by using the default frameworks instead of modifying them we would give teams access to the latest technologies without having to manually adjust to what the company has implemented on top. The capabilities that are needed should be added on top as layers, that can be added or removed on convenience by the different teams. This would simplify development and essentially lighten our services, which would be extremely helpful.
“Teams should be aware of where they are running”.
Even though I appreciate the effort taken with Openshift to decouple the idea of being on Cloud vs being on-premises I believe this to be another mistake. Teams should be made extremely aware of where they are running. If the decision is made to go into cloud, then the paradigm is completely different, we need lighter services that focus on speed and low RAM usage to perform well on a possible PaaS system. If using on-premises, Teams can use a different approach, but knowing where you are is as essential as understanding your surroundings in real life.
The trick to make this work in an easier way, is to slim services to have only what we need in each service. This ties with the previous point, by not building frameworks, instead of a huge bundle that can be deployed anywhere, we can create a system that is slimmed down by build actions to run where they are needed. For instance, if deploying on cloud, all the on-premises layers could be removed and vice versa.
“Use full potential of Cloud- Be native”.
When moving to Cloud, we need to change how we go there. We should understand IaaS as a wrong path in most cases, as it is always going to be more expensive and featureless than what we have. If we decide to embrace Cloud, we must go in a full dive with it. Understanding the risks but being ready to reap the real benefits. This essentially means we need to change how we create services by being completely cloud-native, using PaaS that give us the full suite of operations we need, from CI/CDs to resilience and scalability.
This also encourages us to use and exploit the best features of the different cloud providers and simplify processes for technical teams whilst reducing the overall load on architecture and platform teams.
“Technical freedom is earned- and must be initially justified”.
We previously mentioned that we were, in a manner of speaking, giving the freedom to technical teams to implement what they see fit. This leads us to costly services that are sometimes difficult to scale and incur in huge expenses. Teams should be given a baseline of what a service should be (For instance a PaaS, with a PostgreSQL database, as simple as that). If teams need something different, they should justify and explain why, and this should be evaluated. The trick behind this is that the evaluation has to decide not only that what they are proposing makes sense, but also that they have the capabilities to do so and understand the different aspects of that decision.
Once Teams show that prowess, they will be incentived to continue down thar route. The true aspect of a leader is to create fellow leaders, and that is what we should aim to by protecting teams that over-performing, with sound technical knowledge and sensibility.
“Teams are not just accountable for delivery. Excellence is expected”.
Companies usually measure teams on deliverability. That is the main aspect we look for when forming teams and creating products. However, in most cases, that makes us lose focus on pure and absolute technical excellence. There are several things that a technical Lead and an overall team must be looking into constantly:
- Constant dependency updates.
- Latest programming language adoption.
- Code quality – not just from a testing standpoint, but also an architecture one.
- Response time – we expect all APIs to perform requests in under 200ms, anything beyond that should be justified accordingly (it might an export process, but that focues is what makes us a better).
- Butter smooth interfaces made with the user in mind – from component separation to and end user focus.
- Constantly looking at service and trying to see what can be improved and what can be bought to the table to improve the service and the company as a whole.
We need teams to understand that we do vital work here, and being here is a privilege that has to be worn and carried with pride. We expect to work with the best, and whilst we are willing to help people evolve, eventually our image and example must be that of pure and utter excellence.
This leads to an interesting point, that we could essentially gamify the whole experience. Creating leader boards with the best teams and rewarding them, creating a culture where we encourage going that extra mile to get the job done properly from every angle and showing teams examples of what we expect of them on every level.
“Start-up mentality – Cost and Open Source are main pillars”.
A Start-up is the ultimate example of ownership and accountability because you are expected to own everything, from the development to the actual cost of running that development. That is the point where you realise that over provisioning is great for performance, but that someone actually has to pay for it when the times comes, and you might end up realising that you misused money (imagine if it actually was your money).
In this new philosophy we want teams to understand this and strive to make their services as cost-efficient as possible, thinking what would happened if they were the ones ultimately payting for them.
This has two main immediate advantages:
- It encourages them to clean up constantly their resources. Many times, we find that teams are nor clearing development tests and leave infrastructure that is generating cost and has no usage forgotten.
- It also helps focus on how much capacity you really need, compared to what would be desirable to have as much peace of mind as possible. This once again ties in nicely with using PaaS and leveraging what you really need, nothing more and nothing less.
- Accountability on cost essentially helps adopt solutions which are more cost-effective and require no licenses. This is where open-source shines. Teams should be really encouraged to use this type of resources, and as a company help to improve and develop them (this what AWS is doing with PostgreSQL for instance).
This is another metric that can be quantified and measured to help teams embrace it as a much as possible.
This is just my two cents, but what do you think? What would you like to see up next in this blog?
Thanks for reading!
Until next time!
Pablo Clemente Pérez 
Leave a comment