When I started my career with an automotive major, the use case was building a centralized supplier portal/supplier database for more than 50k+ suppliers across the globe and which had to be rolled out to 100+ countries, so that the $100 Billion+ organization could take leverage of the production capacity, pricing efficiencies and ultimately better supply chain models to be put in place. Later in the financial domain, an AI feature which involved neural network processing behind the scenes and had a direct impact on the revenue had to be rolled out to opted-in customer base. With the recent experience working in Platform Engineering, releasing features and focusing on adoption for efficiencies. I’m not sure if you noticed, there is a strong Why before every experience. I have tried my best to put them across various phases that a product evolution with each one of them having a purpose for any Product to take the adoption/growth journey.

I broadly categorized the phases that a product had to go through these 4 Stages. Please note that this experience is specific to B2B scenario and B2C could be having different buckets.

Stage 1: Zero to One

First stage is where most of the products fail or loose traction and hence this is crucial. For everything that needs to be done, having an early adaptor, a users who can take the journey with you knowing the product isn’t perfect yet will be important. Building the foundational infrastructure while focusing on the MVP(Minimal Viable Product) addressing customer pain points to get the platform off the ground. Market research and competitor analysis can provide valuable insights and guide the development process.

This phase is the long pole in the tent and one needs to make sure while building the platform to have scalability and flexibility in mind to handle future demand. Through the Product evolution journey it’s important to focus on the feedback as it’s an iterative process and your backlog for improvements only come from this feedback.

Stage 2: One to Hundred

This stage is crucial for sustainment of the Platform Product and also to address more use cases for various types of customer that get onboarded. One will see a community being build around this phase with regular feature release or capability demos and few times customers will be our voice of the product. It’s important to keep the engagement and drive towards customer satisfaction with aspects like self service and roadmaps for visibility into what’s coming.

Table stakes like Observability, patching, scalable architecture will need to be addressed at this stage. Having a strong partnership with vendors who can expedite and help in solving few use cases will also be an alternative that needs to be evaluated.

Stage 3: Hundred to Thousand

At this stage, it’s about handling the volume and having focus on Support, Operations, Automation for workflows, Governance and standardization with templates wherever possible will be crucial aspects. It’s important to drive the platform with right metrics which support strategic business objectives.

Double down on the customer satisfaction and how swiftly we will be able to respond to feedback and new requirements. Platform product evolution is all about contact improvement and ensuring the platform is relevant in the ever-evolving market with cutting-edge technology stack and hence evaluating the landscape to stay ahead will be important.

Stage 4: Thousand and above

This is the stage where the talk around ROI, optimization and having a solid team built around customer success will be crucial. In summary, growing a platform requires a strategic and iterative approach in building product features. Building a solid foundation, attracting and retaining customers, scaling the platform, and staying responsive to user feedback and market trends are key factors in achieving sustainable growth and success.

The reason for holding off this article is as you can see, there are lot of items through this journey as a leader it’s important to have a framework for yourself to consume the complexity. This is where I was trying to fit this in St. Gallen Management Model which simplifies things in the thinking model of Why/What and How’s of this. Here is a snippet of how it looks like and just a different way to look at the Platform Product Evolution.

Putting Team member First:

This was an experiment I’ve tried to know what each of my team members preferred for their work styles, availability, or preferences in terms of when they would want to have one on one meetings and to my surprise it’s all over and this was contradictory to what I was expecting. But this helped me prioritize their schedule and preference and I was able to spread my 1:1’s according to their choice of slot in a day.

How My Work Week Looks like?

For me what worked is to have my 1:1’s done early in the week as that’s what sets my weekly agenda and focus items from the discussions. They say for being agile, you move the needle, one week at a time and you won’t believe things change every week with the pace we go in my team. The other blocks are where my meetings with partner team, reviews, status meetings or all other manager work happens. This is also aligned with Paul Graham's suggestion around having separate schedules for Makers mindset vs managers mindset.

Template I use for One-on-One Meeting:

This is a Notion template I use for my One on One and this is a shared page with my team member so that we’ve a single record that we keep over period. I don’t want to boast about the Notion features and capabilities (and not about the AI capabilities, that can summarize everything) as it’s a topic for another day, but this helps me organized ahead of the meeting for my action items and agenda that team members put together. Of course, not all team members fall in the same spectrum of leveraging this, but I’ve seen most of my team put the agenda items and bring up interesting topics for a fruitful discussion. This simple template was shared by Allie K Miller, and it makes things organized well.

As the team, scope, interactions with partners/stakeholders increases, it becomes more important to leverage digital tools which acts like your second brain and that's where this format comes into picture. Literally during my meetings, if something comes up which needs to be communicated to Person X, I always have Notion open and make an immediate note of it in Person X's page. Having such a tool helped me a lot to save ideas, thoughts and conversations at right places.

Real Conversation:

People remember their managers, talk about them at dinner table, social gatherings and managers have a lasting impact on how employees approach their work and achieve results.

My approach to life and work is centered around creating such a lasting impact and making a positive difference. You can achieve amazing things by building high-performing teams and foster strong relationships through one-on-ones and other collaborative efforts such as Demo (Show and Tell) and team building activities. By aligning team members around shared goals and objectives, we can create a powerful network that drives success and growth.

Few years back being an introvert, I used to think what would be there to talk for 30 mins. and at such a frequency. Over period I realized that it’s not enough and you still have a lot to discuss. People come as a whole person, not just what they have to do for work, their passions, little joys, experience they had over a vacation, family visits. The more you know about them, the more you appreciate what makes them who they are.

The book "Radical Candor" by Kim Scott discusses the importance of balancing empathy and challenge in our interactions with others, especially in the workplace. Using the "radical candor" framework we can guide our interactions: care personally, challenge directly, listen carefully, and respond thoughtfully. Be specific and actionable in our feedback and avoid vague or general comments. Prioritize building trust and rapport with team members, as this will make it easier to have difficult conversations. By balancing empathy and challenge, we can create a more positive and productive dynamic in our interactions.

I do take sometime as well to seek feedback from team members to know about how I show up, things they want to see less of me in certain areas or more in some. Management is a right balance of science and art to tackle and One on one has been such a great tool to build high performing team and delivering amazing results.

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.

API Economy is taking off exponentially and its every business need to expose their digital services and assets in a secure way. I'll walkthrough in this article how one can take a API-first , design first approach to take into the account, the needs of API consumers and various steps that lead to creating a Developer Portal using all the tools that we've currently. Please note that these tools have alternatives in the market, but these are what got me to the goal post in the fastest way and case could differ for others.

Open API Specification

One of the broadly accepted industry standard for describing modern API's and programming language-agnostic are open API Specs. For the sake of this article I've taken JSON Resume Schema as a reference API to create a API end points for aspects of resume.

1. Stoplight - Gartner has recognized it as one of the cool products considering the fact that API design and API testing as important stages in full life cycle API management. Stoplight studio is a nice tool with visual interface for designing API pretty fast and if you are wondering how fast - you need to check out this video. Here is the output of stoplight generated openAPI YAML file.

2. SwaggerHub - To write a book, you would have probably read a lot of books, to write an amazing code, you would have probably read through a lot of code, so with API's to design a good API, you would have been exposure to so many API designs. This is a nice place with collection of many published API designs and some other place similar would be postman API network. There are 2 ways to developing API's as in this article and the SwaggerHub has also the capability to generate Server Stubs which will provide a template server code that can be good enough to start writing the business logic and to put in the persistent layer for storing data. Github link for generated code.

3. Serverless - Open source serverless framework helps in deploying app in cloud platforms when we are able to get the function, event and resource configuration updated in the serverless.yml file. I got lambda functions coded in Node, express and using dynamoDB for persistence and the Github link for these.

4. API Gateway - Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. After the previous serverless deployment we've got the API Gateway in place and in case you are wondering if there is anything to be done here, you can move to the final step.

5. Dev Portal - Now that you've got your API's ready and deployed, this article explains the steps for setting up the dev portal with repository from serverless application registry. All you've to provide is the S3 bucket names for storing the API catalog, Dev Portal Static site and Cognito Domain Name/Prefix to sign in page URL's

If you want to look at the designer view of the cloud formation template...

Well, don't get bogged down by the bells and whistles in the resource stack above, but it has got everything that's needed for the user management through Cognito Identity pool, DynamoDB tables for users, feedback, SNS notifications and 12 lambda functions for managing s3 bucket updates, cognito, cloud front security headers and API gateway where we will be able to manage the throttling, deploying more API's in various stages, API keys and client certificates.

When you see this Developer Portal, it means you've reached the end of the journey of what is takes from designing API to putting it up in the Developer Portal. You will be able to now put your API catalog in the s3 buckets and manage the users via Cognito and manage how your API's are accessed.

With my experience touching a decade in the space of project management, I wanted to explore sharing my learnings with people and get to know a different perspective of problem areas. As the quote goes from Richard Feynman – “If you want to master something, teach it”. Fortunate to get people who were consistent in attending all the 6 sessions and enthusiastic to ask and provide their views.

Please note that I've taken the permission to put up these pic

Below was the schedule of the classes and presentation that was used during the sessions.

1. All about Agile Jul 01, 2019 http://bit.ly/304l6kE
2. Roles and Ceremonies Jul 08, 2019 http://bit.ly/2Z3xi7Z
3. Examples and Games Jul 15, 2019 http://bit.ly/2N00PJb
4. Examples and Games Jul 29, 2019 http://bit.ly/2N00PJb
5. Agile Transformation Aug 05, 2019 http://bit.ly/33wQp9R
6. Enterprise Agile Scaling Aug 12, 2019 http://bit.ly/2KHEm0W

I use retrospectives as a very important tool to assess and also to find areas that I could improve for future sessions. Below is the screenshot of feedback provided by the attendees.

Disclaimer: I’m not a Hacker. From the know sources I put this before you.

RFC:

In the internetworking and computer network engineering, Request for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies.

There are about 8500+ RFC’s (4500+ when I wrote it 12 years back) for you to look up. It is not a surprise to know most of the internets standards are adopted by IETF are from proposals made in RFC’s.

The Art of Computer Programming:

The Art of Computer Programming is a comprehensive monograph written by Donald Knuth which covers many kinds of programming algorithms and their analysis. It comprises of 4 volumes and self-sufficient to maneuver your programming skills.

Rather than me saying about this book, let’s look the other way.

Bill Gates: “If you think you’re really good programmers… read (Knuth’s) Art of Computer Programming…”

Steve Jobs:” You should definitely send me a resume if you can read the whole thing.”

Lego Bricks or Black Box:

Recently I came across a conversation which goes like this,

New: I wanted a new toy car, and everybody’s raving about how great Lego cars can be. So I bought some Lego, but when I got home, I just had a load of bricks and cogs and stuff in the box. Where’s my car??

Old: You have to build the car out of the bricks. That’s the whole point of Lego.

New: What?? I don’t know how to build a car. I’m not a mechanic. How am I supposed to know how to put it all together??

Old: There’s a leaflet that came in the box. It tells you exactly how to put the bricks together to get a toy car. You don’t need to know how, you just need to follow the instructions.

New: Okay, I found the instructions. It’s going to take me hours! Why can’t they just sell it as a toy car, instead of making you have to build it??

Old: Because not everybody wants to make a toy car with Lego. It can be made into anything we like. That’s the whole point.

New: I still don’t see why they can’t supply it as a car so people who want a car have got one, and other people can take it apart if they want to. Anyway, I finally got it put together, but some bits come off occasionally. What do I do about this? Can I glue it?

Old: It’s Lego. It’s designed to come apart. That’s the whole point.

New: But I don’t want it to come apart. I just want a toy car!

Old: Then why on Earth did you buy a box of Lego??

One thing is clear from this conversation that we as a passionate software engineers should be dare enough to play with the bricks and not the black box kind of proprietary software. This is provided by the GNU project started by the passionate programmer Stallman. This is where you can live in freedom and have access to the source code and modify to your needs. (Building toys)

P.S: Interestingly if you can master the three fields you can open your doors to become a hacker. After all what a hacker wants Extreme programming skills, Networking knowledge and an OS to work with. Well! This is not the end. In fact, who am I to say the cardinality of the skill set is only 3 fields?

Please note that most of the content is from the notes that I've taken during the tour and some from online research (Links provided at the end). I've taken permission from the tour guide to write this article at a later point.

We were first taken to a intro room where we were given an idea about the tour sequence and audio device as it will be noisy in the area. The overall process has been split into 7 steps:

Inbound, 2) Stow, 3) Pick, 4) Pack, 5) SLAM, 6) Shipping and 7) Delivery

Inbound: Here is where the products arrive from manufacturers and sellers which are stored in the Amazon FC.

Stow: Where products are placed in coded bins and entered into inventory for them to be located later.

Amazon uses RSP (Robotic Storage Platform) where robots (Kiva Robots) come to associate with shelves (Which can store up to 600 Products). The Kiva robots are usually 16 to 18 Inches in height and can carry a load of up to 750 pounds to 3000 pounds based on the model of the robot used. They use QR codes throughout the floor for tracking their location and for following the path of the grid.

Stowing process is randomized placement of items in the bins and that's an advantage amazon takes. shelves are highlighted if they are filled and guide associate with potential locations for where a product can go in. Using motion sensor the bin location of where the associate has placed the product will be tracked. A snapshot is always taken after this process for quality purpose to validate where something is being stored .

1. Pick: When an Order arrives associates picks the products and place them into one of the bins with the help of Kiva robots which brings the appropriate shelves to the associate. The picked product is placed in the yellow totes or container which travels all the way for packing through conveyer belts. At any point in the fulfillment center the data related to any pallet location, quantity of items in it are virtually available.

To encourage associates, FC's usually run a robotic signing competition where associates who picks maximum number of items per month or week.

Pack: The yellow totes travel to a separate area where packaging happens and lot of  associates are involved in this activity. Based on the size of the product appropriate packaging material is suggested to the associate who picks up the product or sometimes its a grouping of product to an address that happens. Finally they will be placed carefully in those smile boxes and smart packs.

SLAM: which stands for 'Scan/Label/Apply/Manifest' is where the package goes through final processing and routed to the proper outbound truck. The FC used CTM labelling system which was amazing to print the address and also apply it to the box while the box is still in motion. They showed us the controls of how the system is handled during exception like missing the label, printer paper being over, etc.,.

The weight of the package is also something that's validated and if any anomaly occurs, it's being taken to a problem solver to open the box and figure out why the weight or label is not printed.

Shipping: The package is then brought to the sortation center, routed to the proper outbound truck and shipped to a delivery station. The FC has smart vision lights throughout the conveyor belts and chutes to detect any anomaly. Yellow chutes push the package to the right truck - to the sortation center and it looks like a fun ride through the spiral slide right to the truck.

Delivery: Final stage where Amazon Delivery Associate or Flex drivers bring the order to door step. I was fortunate to attend one of the Last Mile sessions that Amazon has conducted in Austin which brought a lot of insights into their  projects of achieving ultimate customer delight. I love the recent feature which shows exactly how many steps or hops a package is away from the destination showcased on the map.

Associates Happiness:

I learned a lot about how the FC keeps it's associates happy while the work is demanding is by having many programs like Cookie Bake, Amazing Children, Bowling night and Trivia. It also has boards for Voice of associate and voice of business. They are provided with Career choice after an year of work with financial assistance of up to 90-95% for 1 or 2 year degree. Associates rest period is also something to note that for every 40 mins, they are asked to do a 60 seconds rest.

Sustainability:

I know Jeff Bezos has signed the paris climate agreement and Amazon is very particular about sustainability and with the amount packaging material that floats around, trying to do the right thing is very important for them. I know recycling of cardboards that vendors gives while shipping their products and cardboard compactors within the FC.

The scale of the entire system is Amazing and no words to tell and it's a bliss to my operations and process management eye. It's where humans and robots work together. It was a day well spent and can't wait to look forward to them working on their efficiencies towards hourly delivery, drones and they have already hit home run with regards to single day delivery with most of their products adhering to it.

Amazon opens the doors to new Romulus robotics fulfillment center

The Romulus facility is one of 25 that employs hundreds of robots to move around shelves of millions of products.

The Detroit NewsBreana Noble

Getting Naked emphasizes on service provider to be vulnerable – to embrace uncommon levels of humility, selflessness, and transparency for the good of a client. These factors would need one to go through suffering in terms of being naked and opening up to the clients. Suffering is something which most of us avoid as they are awkward and painful situations one has to encounter. I’ve tried to capture the model described in the book here below:

Clients come to trust and respect service providers who do this and ultimately come to think more highly of them. That’s because there is nothing more attractive and admirable than people who willingly and cheerfully set their egos aside and make the needs of other more important than their own.