10 Things I learned Building Platforms

Most of my career has been focused on shipping end customer focused apps which provided me an opportunity to explore various areas of software development in the space of digital products, data engineering, AI/ML, ERP system integrations, API's, cloud and testing. I’ve taken up a challenge for the last year on building 2 amazing enterprise platforms - Kubernetes and Secrets Management with mentorship from my founder friends and below are few things I’ve learned over this journey.

1. People: This is intentionally kept on the top as end of the day its people who make amazing products and having a right team with the right roles, attitude and skillset makes a great difference. This piece will take time and one need to put effort for scanning through hundreds of resumes, vetting them before getting to next rounds to check on fitness to fill the gaps and needs of the team.
2. Pilot Teams: For platform teams it’s the Pilot Teams who make them successful as they give immediate feedback, convey process improvements and take the journey with you knowing that the platform is still evolving. Here is where you need to understand the phase in which these pilot teams are, some go as fast as you want and some due to other competing priorities take a different pace. Always focus on the teams that trust and tag along and ensure they are successful and have the continuous feedback loop going with them.
3. Separation of Environments: Once the initial pilot teams are in the Prod journey, it’s important to stabilize your prod environment and have the changes only flown through after being testing in at least 2 lower environments. Always have a separate sandbox/ experimentation environment which is meant to break and test out new features and in-fact encourage to have multiple of them so that the developers can spin them up as needed and tear them down when the new feature tryout is completed. Good part of containers is the ephemeral nature which lets you do that.
4. Communicate Dependency: As you are making changes to very structure of GitOps repos, swapping various integrations, always know that end of the day you are accountable for the high availability of the platform and any breaking changes or dependencies that App teams have to make any changes in their charts/ code will need to be given enough time for them to act. A version of JDK as you are upgrading underlying kubernetes version (Welcome to the world of upgrades and continuous changes in the k8s API’s which is necessary to enhance the features), changes in the helm templates that will need to be adopted across your app teams, there will be many such dependencies that will be good to be communicated ahead as you start working on them.
5. Customer Pain Points: Here is where your design thinking will come into picture to emphasize on customer empathy and understand how you can enhance the overall experience. As part of building the enterprise k8s platform, we’ve taken up a lot on our plate to enable right out of the box integration with other enterprise tools for monitoring, logging, secrets management and security to let developers focus on the business logic. This is always a double edge sword, but over period looking for optimization opportunities and having a standard ways of doing all these integrations will make providing this experience possible and sustainable.
6. Security: Always drive with the notion of security being your first class citizen in your platform and look for opportunities to improve them as you lay out the templates, processes and how your customers(App teams) interact with the platform. Have the right tools to continuously scan your environment, bring the transparency and work with the partners on the security to unlock the processes to fix the vulnerabilities at the beginning with the shift left mindset.
7. Libraries and frameworks: One thing I always learned is good products release features and great product release libraries and frameworks. Though they both are different in terms of inversion of control. Having good libraries that your developers can leverage to make their build, deploy process, templates for helm charts to create consistency will enhance the way teams interact with your platform. Frameworks takes time and a great team to build, but having that vision to drive towards it will make us establish a good culture.
8. Scale: Having the mindset of scale is important as it’s not about solving a use case once, but as the adoption kicks-in the same solution will need to be replicated at scale. Hence focus on process, operations, support will help scaling the platform across multiple app teams.
9. Documentation: Can’t emphasize how much this can help everyone from team members, app teams and anyone who is looking for information on what the platform does, to gain history into why we took those decisions and how it evolved over period. We document everything and keep it as detailed as possible. Cataloging them and enhancing those wiki pages as things change will be critical for the success of the platform. This documentation covers the trouble shooting guides, use cases we solve, demo recordings and labs we organize for app teams for making the journey to platform seamless.
10. Have Fun: A sense of team is so important and how you provide avenues for every one part of the team to be in the Star network mode of communication. We’ve working sessions together as a group, collaboration meetings between individuals and demos to showcase and discuss the feature releases. As a team we always ensure that we deliver it together, share the learnings and enable one another to explore what others have build. Keeping the environment lively with laughs, focusing on the end goal and having fun through this journey make us come closer as a team and that’s what makes this worth.