ºÚÁÏÃÅ

Full transcript

Ìý

Rebecca Parsons: Hello, everyone. Welcome to the ºÚÁÏÃÅ Technology Podcast. My name is Rebecca Parsons, and I'm one of your co-hosts, and I am joined by my co-host Alexey.

Ìý

Alexey Boas: Hello, Rebecca, and hello, everyone, very excited to be here.

Ìý

Rebecca: Today we have Swapnil Deshpande and Prakash Subramaniam, who are members of our internal tech ops team who are going to talk to us about an internal developer platform, developer portal that has recently been released internally to a broader audience, and this platform is called NEO, so Swapnil, Prakash, welcome.

Ìý

Swapnil Deshpande: Thank you, Rebecca, thank you so much.

Ìý

PrakashÌýSubramaniam: Thank you, Rebecca, happy to be talking in this forum.

Ìý

Rebecca: Let's start, tell me a little bit about what really is NEO and what problem were you trying to solve?

Ìý

Prakash: NEO is an internal developer platform. Just for context, ºÚÁÏÃÅ operates from multiple countries. To run our business effectively and to provide also some experience to our employees, we build many applications and services. When software delivery teams build software, they go through a lot of delivery friction, for example, how do we get the required cloud infrastructure? Where do we publish domain events? And many similar requirements. Our idea of the development platform is that delivery teams not worry about things that are not essential to deliver business value.

The journey of NEO began a few years back, there was a time we used to deal with environmental service. As a first step, we started hiring our own data centers that enable self-service access to infrastructure. We eventually moved to cloud. As the next step, when we wanted to expose the business capabilities as APIs and published domain events, we added capabilities, such as API management and messaging capabilities to our developer platform.

As the delivery teams' requirements evolve with complexities such as fine-grained access control for event notifications, we started adding abstractions on top of messaging and API management and other such digital capabilities. At some logical point, we built a developer portal as well that makes it easier for delivery teams to get infrastructure on the self-service to understand the platform capabilities, to discover API events and data, and many other capabilities that are easily enabled via self-service.

Ìý

Swapnil: Yes, and interestingly, NEO actually stands for an internal developer platform for a network-enabled organization. That's what we think of ºÚÁÏÃÅ as. We are a very, very people-centric organization, very talented people work on a lot of things. They like developing new things, they like experimenting things, they like to learn new capabilities and we thought, "Hey, there must be something that we should be giving to our own people that can make their life easy of developing new things." That's where the journey of NEO actually started. We think of ourselves as a network-enabled organization, and we think that the name NEO perfectly describes an internal developer platform for a company like ours.

Ìý

Rebecca: I hadn't realized that's what it stood for, I'm sure I'd heard that in the past, but I'd forgotten about that. Can you get a bit more specific about what were the challenges that developers were having and how NEO approaches and solves those problems for our internal developers?

Ìý

Swapnil: Yes, I'll start on this. Let me just go back in time a bit, and let me focus on the whole journey of, let's say, experimentation, innovation, or even any product development that used to happen internally within ºÚÁÏÃÅ. Many years ago, even before we had anything around the internal developer platform, every team essentially was working in isolation, getting stuff done, critical, different application development journeys.

Over a period of time, and I'm sure Prakash will get into details about how do-- We started thinking about building an internal developer platform, where we started thinking about API marketplace as the first thing. We started defining some sensible defaults, and really going back to developers, trying to figure out, how do we make their life easy by having them get more and more self-service capabilities for them to do the job that they wanted to do?

Our initial focus was to focus on requirements like experiments, what people want to do, let's say for capability development, learning new skills, or for client POCs, or even for things like, "Hey, I want to solve a particular problem for my account, for my project, for my region." We started ºÚÁÏÃÅ Labs many years ago where we said, "Hey, you know what? We want to give a platform, rather, a podium for people to develop their applications or develop their ideas."

Our first attempt of giving those things to people was based on Heroku, where we said, "All right, we'll give people a Heroku-based infrastructure." Requirements were pretty simple back then, right? People mostly wanted to build web-based applications. Things like Heroku would normally be sufficient for people. We started being a little more proactive in terms of going back to people saying, "Hey, Heroku is available. If you want to build your applications, here is how you do it."

We started talking a lot about the ºÚÁÏÃÅ Labs process back then. Now through the ºÚÁÏÃÅ Labs process, what we also discovered is there are a lot of people who started warming up to the idea that they could develop their application. They could make their life easier by building, let's say, small automation, small stuff that they could use for maybe for their project, maybe for their account. The ecosystem started growing.

Of course, as everything grows, there were pains and there were gains that we started understanding, where we started refining the process.

We started understanding, "Hey, what do developers need? What kind of requirements are coming to us? What sort of applications are they developing? What sort of problems are they facing when they're developing those applications?" Over a period of time, we had a really good, let's say, database of the tickets that we used to use for requesting these applications and communicating back and forth with developers about all these things I mentioned, what kind of applications they're developing, what kind of problem they're facing, what support they need.

Then we realized that, number one, this process started to become too long. Especially for a growing company like ºÚÁÏÃÅ, we didn't want to be over-dependent on the manual processes about addressing the request. We didn't want to be in a place where somebody says, "Hey, I want to have an infrastructure for developing an idea." That will wait on some person on another end of the world to find time to respond to that ticket. Over a period of time, respond, and then start that journey. We also observed that over multiple months of observation, it would take anywhere between 7 to 10 days for a person to even just request infrastructure. Somebody saying that, "Hey, I have an idea, and raising a ticket, to them actually getting access to even Heroku. Then our GCP, as we started moving toward GCP, was about 7 to 10 days, right?

Once people get access to infrastructure, 7 to 10 days, that was not enough for them. They wanted to get access to things like APIs. They wanted to discover events that we have. They wanted to use organizational data to, say, automate something for their region, for their country, for their project, et cetera. The discoverability was another problem. Partly it was of course solved by the API marketplace that we had built, but again, back then, we did not have any discoverability on events.

Some of these problems we started encountering in terms of slowness of the process. The process was not going to scale as we grew, the whole delay that would be introduced at multiple stages, the non-availability of information, or non-discoverability of assets that would stop developers from moving forward. Overall what we observed that, if you talk about the whole development cycle of ideation to even getting that first line of code, or from the first line of code to getting that application ready to use, that cycle was almost two months to five months for even a simplest of an idea. That was pretty alarming for us.

We said, "Hey, we must do something." That's where some of the initial thoughts about, "Hey, how could we reimagine the whole developer experience now that we are starting to get a bit more mature in terms of our platform, core assets, and capabilities, how do we now take that next step where we focus our efforts on making that whole developer journey easier," started to come in our minds.

Ìý

Prakash: Yes. Just adding to Swapnil, I think that was really very well-covered on all dimensions. One particular I'd like to add is, if you think about any modern software development, it's very highly demanding from all the developers. I think there's just so many concerns the developer has to think about, starting from when you're starting the application development, starting from, "Hey, what is the right code base structure," and then you're getting into the build states, then you're getting into infrastructure, you set up environments, CI/CD pipelines, and by the time they get started, it's already a few days.

Then you're getting into- you're talking about, "Hey, the developers have to be full-stack developers, they'll take care of backend, frontend, they also had to take care of the DevOps concerns and so on," right? In this journey, there are things that are- some mundane things which could be simplified, right? To get an infrastructure that's not taking a lot of time, things to be available on self-service. It could be infrastructure, it could be some of the application of some of the security controls. All of these things, as much as possible, if some of that can be simplified, that accelerates the speed value, right? I think that's a focus area that we had.

Ìý

Swapnil: Through the overall process of observing developer behavior, we almost went through the needs of 200-plus developers across 30 development teams within 15 countries just to understand, "Hey, what problems are we facing?" This was done a little more passively. We didn't necessarily interview every single of those 200 developers. We observed their tickets, we observed the pattern, we interviewed some teams and figured out, "Hey, where are the choke points? Where are the blockages that we are seeing in the whole process?"

Ìý

Alexey: Yes, it's a beautiful journey. I had the privilege of seeing some of those steps first hand. One thing that strikes me is that we always talk about the difference in thinking about customer experience and developer experience, and how close you need to be, leading on the challenges the developers face, I'm impressed by the connection that you had with showcases, conversations, interviews, understanding patterns, and so on.

Maybe, can you talk a little bit about that closeness? After all, ºÚÁÏÃÅ is a tech company full of very opinionated techies with strong opinions about technology, about the tools they need, and about all that. How'd that feed into the process or change the process in a way of understanding requirements, getting input, getting feedback, and so on?

Ìý

Swapnil: That's a really good question. I think you're spot on. When we say Thoughtworkers are the hardest customers, I must say, because exactly the reason that you outline. I think I wouldn't necessarily say hardest, but most demanding because the standards are pretty high in terms of what they want to experience and what they want to have.

I think towards, I would say the end of 2019, the start of 2020, we also observed that there are some experimental applications or labs applications just started to turn into business-critical applications, right? You might remember some of the applications like Summit or Pathways. Both of them started as labs application, and just for the viewers, Summit and Pathways are our performance review and of our capability development software that we use internally. They started as a labs application. They reached a point where we wanted them to be, say, proper TechOps applications, and there were no set processes.

The demands also started coming from various journeys in terms of, "Hey, you know what? We want a path for our applications, first of all, to be done in a streamlined, faster, quicker way." Much more demand from people vocally coming to us that, "Hey, I'm frustrated, this is not good enough for us. We cannot wait for seven days just for tickets." We could understand the frustrations people are having.

Also, second interesting use case turned up where I mentioned, where some of the applications started turning to important business-critical applications. Third angle started to come out, where this whole rise of what we call regional IT teams, where all the countries within ºÚÁÏÃÅ started to figure out, "Hey, we might need to customize certain business processes for our own needs."

Along with-- Even though the journey of NEO started focusing primarily on experimentation, innovation, labs kind of applications, it actually grew into different use cases, where we said, "Hey, we need to also address the use cases where not only the experimentation can be faster because multiple people having multiple requirements, but also supposed to support the whole journey of new regional IT teams, that are supposed to build applications which are fully supported by different regions. Also, create a journey where some of the applications that we have built could turn to business-critical applications."

Coming back to your question, I think we have met with demanding people and we are really thankful for them because unless these people have been demanding of us, of high standards, we wouldn't be asking hard questions on our processes, our way of working.

Ìý

Prakash: Yes, I think there are also other aspects, which as ºÚÁÏÃÅ was scaling because we are growing across multiple regions, and the regional leads, some of them are really unique, an example is the Chengdu office. In China, they wanted to integrate with WeChat platform to encourage graduates graduating from the colleges to interact with ºÚÁÏÃÅ and potentially apply for a job.

That is something very unique to China. We started seeing a lot of these unique countries-specific regions, specific operating models, and also needs that can be only fulfilled by empowering the regional IT and that kind of an ecosystem. When they started happening, the policies in terms of-- Let's take an example of policy just to highlight this complexity we're getting into, a regional IT application, can it have access to all the data of across the globe? Probably not. It can have access to the region-specific data for that particular business function and so on and so forth.

You started seeing the needs of the fine-grained policies that is evolving. We had to really support these implementations of these policies as well in terms of access control, in terms of these varying use cases, and so on and so forth. I think that was another revolution of the journey that we saw.

Ìý

Rebecca: One of the things that we've put several times on the ºÚÁÏÃÅ Radar in various forms is this notion of applying product thinking to platforms. I know that for you all, you do think of NEO as an internal product. What has that meant in terms of how you've approached the development, how you define success, how you brought together all of that user research that you did and put it together into this journey that has culminated in at least this initial release of NEO? I understand that's going to continue to evolve, but what was the impact of thinking about this as a product, as opposed to just a platform?

Ìý

Swapnil: I'll give a couple of more statistics for us to just get into context. As a company, we actually have more than 53% of our employees into developer roles, and I'm just talking about people who are in developer and associated roles, and there are many more people who actually can code, have interest in programming, and want to learn things, which is a phenomenal context to be in.

If I go back and see, "Hey, how many applications or how many products did we have, which was focused specifically on the developer needs that can make their life easy," we had less than four. That was something which was revealing to me when I started looking at, "Oh-" and the first thing that we started thinking about from a product perspective is who is our customer? Do we consider our employees, developers as a customer? If you want to consider developers as a customer, then we must treat them as our first-class customers. To really center everything that we build, be it digital platforms, be it our internal developer platform, be it our business processes, or be it any processes like security checks, et cetera, they must center around the developers as the first-class citizens and the journey of product development.

That was the shift that we had to do within ourselves. Previously, what used to happen is we did have teams who would work and build components of platform. There was the API team, event streaming team, the data platform team, the infrastructure team, who were doing their job within their own remits pretty well, as best as they really could. What we started thinking in the last couple of years is how do we bring those isolated pieces that we had earlier into a journey which is centered around a developer and their product development journey, and what it means for us to really reimagine that entire experience without thinking about specific teams.

We said, "Hey, let's not talk about teams. Let's not talk about the underlying team structure of the business process right now. Let's completely reimagine what a developer would need." To simply the things, what we said is, we'll divide the journey into three parts for us. One is from ideation to first line of code which typically contains things like iteration zero, setting up infrastructure, all those things, from first line of code to essentially product go-live, which getting product features developed, their needs might require API integrations, event integrations, and the third phase we said is product maintenance, product usage, it's a metric around how the product has been doing.

We started thinking, "Hey, can we really challenge ourselves to imagine our own internal developer platform and the experience of developers while using that platform through the lens of these three sales phases and developer as a first-class customer and their journey, as the journey that we want to productize?" That's where this whole thinking started for us.

Ìý

Prakash: Yes, I think that was really a good perspective on that. Some additional inputs on that same area. I think the earliest stages we had, you can say many products almost, which did not talk to each other, I think the analogy probably we can take is a car as a product, but it's a product of products. An engine is also a product, you can apply the product thinking to engine as well as to path manufacturing.

In the same way, platform as a product is a product of products, and you got these different components or capabilities of this platform coming together to provide that cohesive experience to the consumers. That is something- it was really disjoined earlier, it was very, very much disconnected, but last two years, we've been trying to provide a very holistic experience. I'll probably give an example of that.

A delivery team, which wants to publish an API, we have this concept of this delivery team, so you'll add the team members to the delivery team in the API gateway, basically, API management capability, which is essentially an obstruction on top of the API gateway we build. The same team, if they want to handle some infrastructure requirements, they will again have to add their team members into another service because this team concept was- it's not seamlessly handled across these services.

We started thinking about platform as a product, and what are these digital capabilities that would be useful for different teams, and each of these different capabilities, again, applied the same product thinking. The way [unintelligible] talks about, what does usability mean for that, what is the value that is going to offer. Then that thinking, when you start applying and you started identifying the personas, of course, delivery team, you typically have developers, quality analysts and other roles, I think these personas- and once you start identifying the personas, you also start thinking about what would be the interface that will be required. It will be desired, one is that, of course, we have a developer portal as an intuitive interface because somebody wants to understand what is the developer platform, what capabilities we have, they want to understand it, so there's a place, that's where we have got a developer portal.

You also want to discover some core assets like API events and so on. Again, you can come to the developer portal. That is one dimension of it, but what if a team wants to subscribe to an event? I have a brilliant idea on developing an application in an environment like a developer environment or a test environment. I'm subscribing to that particular event, I'm testing it out.

When I want to promote this application to a higher environment, a staging environment or a production environment, in that scenario, the subscription itself, do you want to go and manually subscribe across these environments? Or do we want to promote it through CI/CD, as an automated this one, right? That's when we started thinking about, "Hey, the developer portal alone as an interface may not be enough, there will be some scenarios where automation would be desired." That's when you would have like a CLI, a command-line interface would also be useful. Imagine a terraform that provides a command-line interface and we are able to use that command-line interface and automate the promotion of this infrastructure, provisioning across these environments, similarly, promotion of this application or services across the environments. We started thinking about the interfaces also that would make sense.

Ìý

Swapnil: What was really interesting for us is, we started this journey on a hypothesis that, this is going to make life of developers easier, but we didn't want to really-- We wanted to validate on the go, is it really going to make life easier? The whole path that we have taken was really associated with some of the way we are consuming our own products. We basically said, "Hey, we want to be the first customers of our own internal developer platform, NEO portal, and will it make our own life, my own team's life easy," was the first question we asked. Including the very, very early version where it was nothing but a homepage, which is linked to a Google Form, where people could just request infrastructure, and will it make people change their behavior of-- Rather than going to an email and sending XYZ support at ºÚÁÏÃÅ.com and, "Give me infrastructure," to actually go to a portal, look at what of offerings they have, click on a form fill-up a form, and submit.

That's where we started even observing how the customer behavior works. The journey literally started, if I go back in time, the first release of NEO was literally an infrastructure offering image on a webpage. "This is what we intend to build," and then a link to a form, and then from then we really started to understand, "Hey, what are the key components we have to build? What are the key capabilities, like Prakash was talking about, we have to build? What are the key journeys we have to identify, and who are our primary feedback customers who can give us feedback?"

Those things we started to identify and with the help of many more developers that we have, and again, one great thing I like about ºÚÁÏÃÅ, even though people are opinionated, very demanding, they're very, very open to give feedback, however good or bad. They love giving feedback and they love trying new things. We took advantage of all these fantastic people we had around us to continue evolving our own product into a shape which is there today.

Ìý

Rebecca: I know the notion of internal innovation and experimentation is near and dear to your heart Swapnil. What role did that play in your envisioning what capabilities you wanted NEO to have and what user journeys you wanted to support to realize these ideas around experimentation and innovation?

Ìý

Swapnil: Very good question. I'll go back a bit in time when I was not playing this role, but I was playing a different role of head of workspaces back in time. In that role, actually, I had the privilege of visiting many countries, looking at what people do up and close in many offices, and one thing or rather two things I found very common across every place was in every office, there was a group or bunch of people doing something extra, which is beyond their day to day work. They had some maker lab in some places, they had some communities in many places, but they would build new things. I found it really common across almost every office I visited. That told me one very, very important point that people are already doing great stuff across many of our offices.

The second thing I also found, which was not so good is not many people know what they are doing. What ended up happening was people ended up doing great stuff, but it was only limited to their office, their project, their account, but not many people were knowing about it. For example, when we were talking about some of the IoT use cases back in time, I knew that somebody, let's say, in the UK, had built a prototype or an IoT, and somebody, one person in the US was looking for some references, but they just didn't know each other because the whole thinking about getting everybody together, making that information discoverable, visible did not exist.

That was one of the big motivation I had, in terms of really thinking about this innovation ecosystem within ºÚÁÏÃÅ where people not only will be able to build stuff faster, quicker, better, but also everybody would be able to socialize what they're doing. It'll be open for everyone to know what each other are doing and not only open but also be able to contribute. In the past when we had built our own internal IoT platform, about three years ago, I think Alexey, you, and I had spoken a lot about that in the past where we had one thing in common.

Everybody had an interest in terms of what we are doing, and everybody wanted to give opinion, contribute, and take advantage of what we have been building. We thought, "Hey, there's already underlying energy within people where they want to do things. They want to know what others are doing. They want to collaborate and make things better, and there's a general appetite in terms of a better collaboration."

What was missing was this whole notion of getting everybody together on a platform where they can not only build things, but also discover what others are doing and join forces to make things better, bigger together. This was my personal inspiration from the past many years, to start thinking about NEO and get us where we are.

Ìý

Prakash: There are also other benefits of bringing this connectedness, which is the shared teams is a reality, of course, whether it's sometimes sponsored by the regions or offices, sometimes a group of people come together and develop some interesting application that solves a localized problem. Now, if we bring this visibility, provide that support, make it easier to join the ecosystem, then we are able to take care of the complaints and security, and other considerations in a much better way.

Otherwise, what would happen is, applications or services are built in silos, they may not even have the context of what should be the policies they should be conforming to, and something is built, and it's not necessarily maintained or updated, and at some point, it may become outdated, or sometimes it may be maintained, but without necessarily adhering to the policies that as an organization that we want to apply. That's when if you bring into the ecosystem and make it easier for them to innovate and develop applications and services. It also, in fact, encourages better compliance, in my opinion.

Ìý

Alexey: I find it fascinating to see the focus NEO has on experimentation. At least from my personal experience in many companies, platform development has a strong focus on productivity and enabling developers to use services and those kinds of things and serendipitous innovation, and that kind of experimentation, it's expected, but it's not the main focus of the platform.

The way you both put it, you see NEO was a catalyst for leveraging the energy, the creativity, and the culture and the behaviors that are already there, around experimentation, innovation, building things, and not just the tool. I find that fascinating, and I'm sure it's very strongly connected to the strong results. We were seeing lots of things people developing based on NEO.

Ìý

Rebecca: What have you learned along the way and what are the lessons that other organizations can take away from what we've learned on this journey of the underlying product platform? I like how you put that, Prakash, this is a product of product. We need to think about those things individually, but what kinds of things have you learned that other organizations could benefit from as well?

Ìý

Swapnil: Very good question. Few things I can definitely talk about, I might have mentioned earlier, I think this is a lesson that we have learned. It goes back to, first of all, identifying how do we or where do we put our developers in the space of their own- for lack of different words, importance as a customer, in terms of processes? Typically, what organizations have done, and including us back in time, our focus when we developed application was mostly operational leaders or business people who want either reporting or want to get stuff done or want to run the business processes.

Developers have traditionally not been a focus for many companies and that's the lesson that we have learned over a period of time that you need to really treat your developers or your own internal employees as first-class customers, and build products around them. If you're able to do that, the whole cycle of- they coming up with ideas, their ideas moving into reality, and you actually getting a business value, that becomes much faster.

A small shift that I would strongly recommend every company to think about is start treating your internal developers as first-class customers. The moment you start doing that, and the moment you start building tools and processes around making them move faster, the whole enterprise agility becomes 10x or has a potential to be 10x in terms of you responding to a change, the organization responds to changes faster, and that's one of the biggest lesson I have had.

Ìý

Prakash: For me, there are a few learnings. The first and foremost would be why should an organization build an internal developer platform? I think it's always going to be contextual. I was reading somewhere, where the article said, the developer platform is obviously making PaaS, platform as a service, for the organism context because every organization has its own operating model in terms of organizational structure, process, people, and policies, and so on, and of course, technology landscape as well.

Making it work, you can't just make an existing off-the-shelf platform as a service. If it works out of the box for the organization's needs, there is no need to build a development platform. It is very unlikely that an off-the-shelf platform as a service will work for the organization context, exactly for that operating model, then, of course, we start answering why, what is the right time to focus on this?

If there is just not many active developments happening or not a lot of these innovations or applications happening, maybe there's a period of time, probably that's not the time to focus on this area, but I think most of the modern organizations that are aiming to become a digital business definitely are in constant evolution and innovation of exposing many innovative ideas to consumers.

That requires thinking about the points that Swapnil highlighted in terms of, "Hey, what is the time to market, speed to value, speed to business value," definitely, the platform makes it easier to accelerate the speed to value. There are also other benefits, which is, as I mentioned earlier, the developers are going through a definitely significant cognitive load. They are expected to handle a lot of- of course, apart from understanding the domain well, apart from understanding these modern architectural patterns and all well, they are expected to be, of course, taking care of a lot of these cross-cutting concerns. Always the numbers are increasing.

Platform is an opportunity to differently push down the complexity and abstract the complexity. In a way, you cut out the unnecessary complexity and allow the developers to focus on the essentials. Reducing cognitive load, and also making it easy to follow best practices would be other benefits. That's like "why platform" to me. There are also some other lenses to think about.

If you build a platform, as with everything with agile, I think Swapnil already highlighted, when we began our journey, we just had probably some Wiki pages or web pages. In fact, the people who- begin Team Topology, they talk about this idea of the minimum viable platform. Essentially, it's inspired from MVP. Maybe the beginning, the first step in building a development platform could be this Wiki page or a web page, which consists some of these basic principles and guidelines. Then we start adding layers and layers of these digital capabilities that will start reducing the friction.

Again, what would it be focused on will depend on what ideas are being built, and what is required for that? In our journey, it was in the early stages, it was just infrastructure, just make it easy to get the infrastructure. That's all. That's the first step. Then second step comes in. "Okay, we want to follow event-driven architecture, we want to publish events. Where do we publish?" You want to have a common message broker. Do we directly publish into Kafka or Google Pub/Sub? I think that could have been a good option if that solves our problems as it is.

In our context, a simple example is we operate in multiple countries. A lot of these events, very tighter access policies, in terms of who can receive these events, the message brokers out of the box don't have these fine-grained capabilities. Then you start weaving in abstractions on top of this, message brokers, API gateways, and so on and so forth, in a way that supports our organization policy. That's the next level of SSL bits we started adding. Then we started adding some of these things and that allowed us to have at least the absolute essentials taken care.

That's when, of course, you're thinking about the future, what would be the next future steps. The future steps are more modest, probably you can touch on in some time, but that's how we started. I think being agile, being evolutionary, and they can even definitely apply domain-driven design even here also. In fact, very often when you talk about platform, especially development platform, people think there is no domain here. There is domain here, except that the nature of the domain happens to be different.

The nature of users happen to be different. You can still have a domain-driven design, you can still create microservices which are defined by bounded context. All of those principles you would apply in a more business domain-oriented development definitely still applies here as well.

Ìý

Swapnil: In addition to what Prakash is saying, there are a couple of more things I want to talk about, specifically. I'll give a situation I had with one of the external conferences when I was meeting someone. I was talking to one of the business heads, and I was asking them, "Hey, why you're not investing into your internal IT that can hopefully speed up the whole cycle?" One of the answers I was given is in a metaphor, saying that "Cobbler's son do not need to have the best shoes". I was pretty surprised with that.

What they effectively meant is that, "Hey, my job is to provide innovation to customers, and I don't care if I'm innovative, myself as a company," and that stayed with me for a while. As we have seen the last couple of years turned out to be, the whole pace of digital transformation has been unlike ever before. The need for companies to innovate themselves is huge in today's environment. If companies who are not innovating themselves faster, they are in real danger of being irrelevant to themselves, to the market, to the competition.

One of the biggest lesson that I have had, and thankfully, a company like ours, ºÚÁÏÃÅ has been really, really supportive in this journey, is to actually invest in our own infrastructure, invest in building our own platform, invest in innovation because when we go and talk outside about innovation is going to drive the next phase of growth for every company, we are able to demonstrate within ourselves that, "Hey, you know what, we are not sitting stagnant, we are allowing our own people to disrupt our own way of working, they are allowing brilliant ideas within our organization to actually disrupt our own business processes."

A couple of examples I gave earlier like Pathways and Summit, they were ideas actually came from people who were doing experimentation, which now are some of the mainstream business applications that we are using. This is something I would strongly encourage companies to cultivate, listen to their people, listen to ideas, provide not only a developer platform for them to build ideas but also build a culture where everybody actually can voice ideas, everybody is having a path for their ideas to be realizing. You don't know which idea can pick up. You don't know which idea might open up new business for you. You don't know which ideas might create new growth avenues for you.

That also would be one of other lessons that we have seen I would say pretty well done within ºÚÁÏÃÅ, but something that I would also suggest other companies to think and do.

Ìý

Rebecca: I really like our positioning too of reducing the cognitive load on the developer so that they can focus on the idea and the potential for the idea and not having to worry about the security and the compliance and all of that to have that structure so that their creative energies are not sapped by "Oh, and I've got to worry about this and I've got to worry about that." This platform for experimentation along with, as you say, Swapnil, the culture of experimentation, that's how you unleash the potential of your people, and when that works, amazing things happen. Tell me, what's coming next for NEO? What's the future look like?

Ìý

Swapnil: There's a lot, honestly and honestly, all these ideas, I would be the first one to admit, are not necessarily coming from only our team. A lot of ideas are actually feedbacks that we are getting from Thoughtworkers who are using the product. Before just getting into what's coming up next, let me just put some of the stats into perspective because that will also tell us whether people are liking or not liking what we are doing.

Just to put something, we actually did an alpha rollout of NEO back in November 2020. Very, very limited. Like I said, we started using our own products, we started doing things, then we did alpha plus rollout with a wider group of people in January 2020. We did a full beta rollout in July 2021, and now with effect from August 2021, it's available across all the countries for users to use.

Since July, we started measuring how the growth of applications has been. It's been phenomenal. Month on month, we have seen from July to August 60% growth, from August to September 85% growth, from September to October 67%, October to November 86% growth in terms of usage of NEO. Today if I look at the platform or the portal, and if you said we have almost 2400+ unique Thoughtworkers having accessed some or other part of NEO, with 500+ active developers with 300+ teams onboarded onto NEO, with 330+ applications available in the catalog, 60+ APIs, 380+ events, and 13+ active teams measuring their delivery excellence through NEO, this actually give a really strong encouragement for us that we are actually on, hopefully, the right path, that we're doing something right. People are demanding a lot of things of us.

A few things that we are hoping that will make life much better, even better for people is, we are thinking about introducing multi-cloud option. Today when we started implementing NEO, we started basically implementing a sensible default journey. GCB as a sensible default option, GitHub and CircleCI. We didn't really give options to people. Now people are actually coming and telling us that, "Hey, we want to have an option of AWS and we should have it. We want the option of Azure, and why don't we have it? We want to have access to certain other capabilities."

We are really now working towards introducing multi-cloud as one of the options in the coming months. That's happening. We are also trying to introduce the data around our cloud carbon footprint, about our application. Typically one of the challenges have been is, getting that information and visibility to developers and the product owners about their, let's say, cost of the product, cost of the usage, their carbon footprint. The hypothesis here is that if you're making this information visible to them, they will be much more aware and they will be encouraged to take better steps, to either reduce the carbon footprint or reduce the bearing usage of the services that they have been using.

Some of the other thing that we are talking about interestingly are around developer profiles, where, like I mentioned so many developers have already onboarded on to NEO, it's going to be a really interesting view to see the actual work the developers have been doing. Typically, when you talk about a staffing profile of a person, it is typically based on skills where people either self rate their skills or get somebody else to rate their skills and talk about X in this technology, Y in that technology. Here we are really exposing the whole developer profile data to everybody in the company so that, "Hey you know what? This is the actual stuff a person has been doing. This is the actual codes they have written, these are the contributions they have made, these are the applications they have built." These are some of the exciting things that we are actually working on as we speak.

Ìý

Rebecca: Well, sounds very exciting. Thank you, Swapnil. Thank you, Prakash. Thank you, Alexey. I hope you've all found this discussion of a real-world example of a developer portal within a particular context useful and that you can take these insights back to your own organization. Thank you very much.

Ìý

Swapnil: Thank you so much. Thank you, Rebecca. It's been a privilege of being part of this group. Thank you so much.

Ìý

Prakash: Thank you, Rebecca and Alexey. It was really a good experience and thank you.

Ìý

Alexey: Thank you so much, Swapnil and Prakash. Bye.

Ìý

Alexey: On the next episode, Ashok and I will talk to Luciano Ramalho about why Python Ecosystem. We'll discuss some of its history, typing, and some other things Luciano has been brewing for the second edition of his Fluent Python book. Hope you'll join us for that conversation.