Article originally posted on InfoQ. Visit InfoQ

Transcript

Petkovska: If you’re in a software company just to make your company successful, it’s not good enough to have just good engineering teams, no matter how much we love them. We have to admit that we need other teams that are user focused, that will help us to promote our product to the users. We need product management also that will help us to craft the product based on the user needs, customer support, professional services, customer success that will help the users to use the product with all its features or to resolve issues when they are found. Data analytics and marketing to craft the product to promote new features. If we just focus on engineering, if we look inside, we have a similar situation.

We have all these enabling teams, as we find in Team Topologies, that help our product engineers to deliver the software. We have teams like quality, security, DevOps, infrastructure team that produce some software that is used internally in the company. All these teams have the product developers as users, and if you want them to be successful, it’s not enough that they will use just most fancy technologies. It’s also important that they will focus on other aspects, like product management and planning what they will bring next, understanding the user needs, supporting the users to use the software that they have.

I was also very thrilled to find that in the latest State of DevOps Report, we had a whole section about the importance of user-centric approach. They stated that teams that have strong user focus, they have 40% higher organizational performance and 20% higher job satisfaction.

On top of that, they have a small section about the platform engineering teams, stating that teams that focus on the users, and they don’t just do build it, and they will come approach, they can detect the needs of their teams better, and they can eliminate the area of friction faster. They can also have better performance, better productivity, and they can also have higher job satisfaction. I think this is what really put the focus more on platform engineering and other practices like developer experience, developer productivity, because they are all user centric. With platform engineering, we know that we need to treat the platform as a product. We started to have PMs in the platform teams that will craft the platform.

Key Achievements (DevEx Group at Nexthink)

The user centricity is the biggest change in the mindset and how we operate that we made in 2022. We had a DevOps team. I was initially an engineer in that team, now I’m a manager. What we decided is to form the first team of the DevEx group. We called it engineering productivity. At that time, there was no group, it was just one team. With this first team, we had great achievements. We changed the deployment mechanism to increase the speed at which we deployed to production. We have more deployments in the integration environments. We got a great adoption of what we built.

Then, we did some changes on the CI/CD system to have better scalability, better reliability. We still use Jenkins, and now we’re moving to GitHub Actions. We reduced the number of open support tickets that our team had. Then we also migrated all the repositories from Bitbucket to GitHub, because we wanted to move to a cloud solution. When we built this platform, we embedded governance and security from the beginning. We have autonomous management of repository settings, so the teams can be autonomous in doing and getting the things that they need.

Finally, in 2023, I got the second half of my original team, and then we focused a lot on the infrastructure and the data infrastructure, and we reduced the Kafka cost by 72% in internal environments. We also improved the reliability of the system, and we started to have closer collaboration with the feature teams. Today, in our group, we have 3 teams and 15 engineers. I’m the proud engineering manager, because they are great teams, and they’re bringing great improvements.

Nexthink – Digital Employee Experience Platform

Our users are the 45 feature teams that work on the Nexthink product, that is a platform for digital employee experience. In our company in general, we have the culture talking about the employee experience, and knowing that improving the experience will improve the productivity. Besides our 3 teams, we have other enabling teams that now form the technical platform engineering group, teams that focus on quality, observability, security, architecture, and so on. In total, we have 300 developers, and we work on different types of products. We have a cloud platform, on-premise platform, and some user applications and browser extensions that connect and send the data to this platform. This is what we have in our side. I wanted just to share it with you so you can just compare to your teams and what you have on your side.

Outline: Key User-Centric Practices

In this talk, I want to share with you the key user-centric practices that I believe changed how we work and were key for our success. The first part is about building the brand and establishing well-defined user-centric teams. The second one is about building the product. I will highlight the importance about building self-service platforms that are tailored for the needs of the user. The final one is, once we have the product or we have something to share with our users, how we do progressive rollouts and we track adoption. This is based on our experience and industry practices. I know that everything might not fit all. It really depends what is the state of your teams today, how many users you have, and what is the state of your company or the platform or the tools that you have as ownership.

For each of these topics, we will see first some practices, some theory why it is important. I will give some examples from our experience. Then we’ll see the outcomes, the benefits that we get for the developers and for the platform teams. Finally, we’ll see some action items, so what you can take away and maybe implement on your side.

The Brand: Establishing Well-Defined User-Centric Teams

The first part is about the brand, establishing well-defined user-centric teams. This is very important, because when you have a developer experience group, yes, they will improve the developer experience of your product engineers, but who will improve their experience? Who will take care about their experience? This is where we come as leaders to ensure that we are setting these teams for success and establishing them in a way that they can bring all the improvements for the rest of the company. Here I want to start with the team one-pager. Whenever we are discussing about forming a new team, I start with this, forming this one-pager and defining the team mission, the ownership, the roadmap, the team structure, and the communication channels. This will give a clear definition for the team existence. It should be inspiring for the team members, so they can be proud and happy to be part of this team.

Then, it should be documented public information so anyone can find. It should be communicated to the users. Usually, we do that on our all-hands meeting when we form the team. I show it on some onboarding sessions for newcomers. I even put it in my out of office message, because this gives everything to our organizations to know who they need to contact for which context, when I’m not there. I will touch a bit about the team mission, ownership, and roadmap, and the communication channels. The team structure is also very important, because you want to have diversity of thought and knowledge and capabilities in the team. Because it’s not just about having good engineers, you need to have also someone that can document well, can communicate well. Not everyone has to have these skills, and not everyone needs to have these skills from the beginning. People can learn and adapt, but you need also to think about that.

The first part that I want to mention is the mission strategy and the roadmap. For this, I’m inspired by the product strategy pyramid. This team, you remember, is like a small startup in your company, so it doesn’t really have the same mission like your software engineering company. This is why it’s important to define a mission strategy and roadmap for them to explain why your team exists, how they will achieve this mission, and what and when you will implement. Here I give you examples of two of my teams. What is the mission for these teams? This is the long-term goal for them.

For engineering productivity, it is to enable delivering business value to the Nexthink customers, fast and reliably, while increasing the developer experience. For the data infrastructure team, it is to ensure that data infrastructure and services are reliable, scalable, cost effective, and aligned with evolving product requirements. Next to this, I don’t write long strategy documents, but I append just few sentences that will say how we will achieve this mission. These are our choices that will allow us to win. This usually starts with some verb to be actionable that will provide a framework, gather metrics, operate, maintain, and evolve the infrastructure, support the developers, and so on.

If you see these highlighted sections, in the mission and the strategy, we want to be already user oriented, because with that, you can guide a team, your platform team, how to work and on what to focus. We want them to be aware that they need to increase the developer experience, to abstract engineers from the complexity, to think about the engineering excellence and velocity, and to support developers for usage of what they provide.

The final step is the roadmap. This is very important to align for the timeline of execution. The roadmap gives visibility for three main stakeholders. First, again, it is your users. When we show the roadmap to our developers, they are very excited to see that we are planning to do all of this in the next year, and that all of these great things are coming for them. Then, it is important for the team, because they can know what is the next priority for them, and they also know that these are all the things that we will work on. Even if now we have a project that’s not very exciting, there are better things coming next.

Then, finally, it allows us to align with the wider organization like PMs and EMs, to know that after we execute and finish one of these items, they need also to allocate some time for their teams to adopt the changes that we bring to the table. Because the product development teams, their highest priority is to ship new features, and we are sending more work to them. It’s also good if they know when they need to take these items and when they need to do some technical work. The roadmap is not written in stone. We are flexible to modify it when there are changes in the business priorities, to prioritize a new project. I also want at the end of the year just to review the roadmap of the current year, the year that is ending, and to adopt it, because this is like a proof of what the team has achieved in the year that just passed. It’s also good from that perspective.

Next, I will just talk briefly about communication. It’s also important for the team to have good communication with its users. There are already these proven user-centric communication practices that companies use for their users. We don’t need to reinvent the wheel here. We just need to do the same things, and with this, we can define a strong team API, as defined in the Team Topologies. This will be our specification on how we interact with the team. We have different communication channels for different purposes.

For example, we have a weekly meeting for important announcements, news, and office hours. This comes quite handy when we have big initiatives, when we are working closely with the development teams, because they can come, we can tell them what’s new. They can tell us if they have issues or ask for questions. Sometimes even developers ask us if they can present something to their peers that is relevant to the topics on which we work. Then we ensure that we have good documentation with internal setup of tools and governance. There was one workshop after which one of the developers told me, “I was fascinated how after every question that you got, you could just point out to a website where you have that answer”. That, for me, was a good proof that we are documenting well the questions that users might have, and that the information that they need is already available there.

Next, we have some dedicated communication channels for adoption of changes. Like when we did the migration to GitHub, we opened a channel for that. When we introduced LaunchDarkly, we had a dedicated channel for that. Then these channels initially serve just for our developers to ask our teams questions, to have an easy place to go and ask questions, but also to find information that maybe other people struggle.

Also, to encourage developers to collaborate between themselves and answer some questions between themselves. We are doing workshops, trainings for the tool and services that we own, and that we are introducing to ensure that we are also educating people about what we have and what they can use. We have a support board for the existing tools, where people can open tickets if they have some issues. We are launching surveys to get feedback, to understand what they further need and what we need to implement for them.

If we do all of these, the developers have the benefit that they know what our team exactly provides. They can have clear expectations about the timeline of the deliverables, and they can prepare to adopt these changes. With all the communications channels, documentation, workshops, trainings, they feel supported and empowered to use what we produce. For our platform team, we have good alignment about the team members on how we work, what’s our mission, what are our ways of working? We have clear priorities about the upcoming work so they know like what they need to focus on, what they need to estimate next. We have improved flow of work, because now they are not pinged on individual messages, but people can go and find information by themselves, or they can go to the right channels to ask for support.

The action items from this part are to have a one-pager to define your platform team, have mission, strategy, and roadmap from day one. The roadmap maybe doesn’t have to be complete, but at least expose what are the next big projects that you will do. List the components and services that are owned by the teams. Because maybe your team is not the only platform team in your company, so the team needs to know what you serve on the menu and when they need to contact you, and when they need to contact someone else. Set strong team API so they know how to communicate with you and how to get in touch with you.

The Product: Building Self-Service Platforms Tailored for the User Needs

Once you have the team, you can start building the product. In this case, I will focus on the importance of building self-service platforms. This is very important, because when we were a DevOps team, and we are still doing DevOps, because platform engineering is not just much different to DevOps, it’s just DevOps with some product management and more user focus for me. We were getting all of these requests. We were getting requests about access to tools, to get a new Jenkins controller, a new repository. I want to change the settings of the repository, and that was not allowed for everyone to do due to security and compliance. We need to deploy a new infrastructure for a new feature. You cannot scale after some point. Until some time, it is ok, but after some point, you become a bottleneck. This is why we decided to look into platform engineering, and to start building this self-service platform.

The first thing that we did is to have a repository in which we store the role-based access control as a code. Then, for Jenkins, we store the Jenkins settings as a code, and we added the possibility to have ephemeral agents that will be spawned as there is more load. When we migrated to GitHub, we took the opportunity to build a platform through which you can create repositories through the code, and you store the settings that you want to have these repositories as code. Then for infrastructure and deployments, we build the CD pipeline, and we’re working more on projects to have infrastructure as a service.

With all this, the developers now are autonomous in getting everything they need, and our platform team can maintain these platforms instead of serving these requests one by one. With this, we have improved the flow of the developers, because unlike before, they had to open a ticket for us, wait for us to take the ticket, ask for more information, then we come with a solution. Now their flow of work is much more like a straight line, and they can get what they need.

For our platform team, the biggest change with this, I think it was the decrease in support tickets. Here you can see the number of open support tickets that we had before introducing all these platforms. This is not everything, because we had even some tickets in the IT system. This is from the board that we had in Jira that is dedicated for support for one of the teams. Actually, if you remember from the first slides, around April, we even decreased the scope, but we continued to use still the same board, and this didn’t help. Even in some period, if we managed to go down, it was very quickly and easy to go up. I want you to remember these points because the maximum was about 50 to 3, and the average was about 30 open tickets at a given time.

Each of these tickets means that a developer is waiting on us to solve something for them. I was really not feeling that we are doing a good job. By going to self-service platforms, and focusing on the things that were most impactful from which we were seeing biggest load of tickets, led us to this. Of course, you don’t need to build a platform for everything. There may be some requests that come less frequently, and then you can still serve them in the standard way, like an enabling team. For the things that are most impactful, it’s really good to build a platform. You will say, yes, but you have these spikes. It’s very interesting, because these spikes are when we introduce something and we requested a big change for it from the teams.

The first one corresponds, for example, when we roll out the CD pipeline, and we wanted all the backend services to use this. The second one we wanted in production to use this improved format for environment-specific configuration. The biggest one is when we migrated 1000 repositories to GitHub. Whenever you’re doing a big change, you need to be ready to support the teams, because they will need you through this process. This is why, in general, it’s better to build something, and if it’s possible, to wait for the adoption from the teams to come gradually, instead of enforcing it by the given deadline to do something. It’s not always possible. There are some things for which we need to enforce, like if we have some deadline or we want to do some cost savings, sometimes you need to ask for deadlines. Whenever you can, it’s better to avoid enforcing the usage of your platform and the things that you bring.

When you build this platform, as I mentioned, our guidance was mostly by the statistics that we have from the support tickets. You can also look at the main points that are highlighted by the developers in the corridors, or struggles that are visible on public chats. You can launch surveys to get feedback, to understand what it needs, because many companies are measuring some quantitative metrics like DORA and SPACE, but this is not sufficient. They can tell you how your company performs, but they will not tell you what is the daily struggles of your developers. This is why it’s important to get these qualitative metrics, launch surveys, and make them also part of your team mission.

Then, make them as a requirement for every project, so you can also track adoption and understand what is the impact of the things that you build. Then, as the last part in this section, I would like to emphasize the importance of focusing on quality, because now you have users that are using the product, and you don’t want again, to deal with a lot of issues with the platform that you’re building. You need also to focus on quality, and think of how I can make these things easy to use and to ensure that I have good user experience for my users. For example, when we launch the ephemeral agents, we ensure that we have compatibility between the CI runners that we built and all the standard build tools that the devs are using. Then we added a lot of validation on the requirements for each of the peers for deployment of microservices.

For everything that is in YAML, because usually we use YAML as an interface between us and the teams to give their requirements and what they want to create with our self-service platforms, we added schema validation because it’s very easy to do a typo, and then that can go unnoticed and the changes won’t be applied. The outcomes of all of this is that your developers can have autonomy in obtaining the required services and tools. You can tackle the real impediments faster, because you can hear the voice of the developers, understand what they need. With this, you can improve the experience and productivity of your developers.

For the platform team, you will have better scalability and throughput, because now you will not solve individual request one by one, you can move to proactive issue resolution, and you will have more time for strategic work. With this, you can increase your impact, and you can also measure it, if you have metrics also for the user experience and developer experience of the developers, of your users.

The action item is to treat the self-service platforms as a product. Often, companies hire a PM, or if you don’t have a PM, just act like one. Try to build a roadmap for the services that you own. Make sure that you will maintain it and make sure that you have good user experience. Embed quality, governance, and security policies from the start. These are the most beneficial ones, because your users won’t need to think about whether they’re doing the right thing. They know that this just comes with the platform. Hear the voice of the developer to identify the true user needs and to build the platforms that will solve the true issues in your company. Design for habitability. Provide an intuitive and safe interface for the users. There’s a great talk by Sam Newman, and I recommend you to see that. He has many more great insights about building platforms.

Product Launch: Progressive Rollouts and Tracking Adoption

Finally, I will talk about the product launch. Once we have a product, we want to expose it out there and share it with our users to use it. We do that in different ways. First of all, we want to focus on early releases. Our team works in three modes, so we have usually three stages of works. This is usually just the three stages for small initiatives, but if it’s a big initiative, we might repeat these stages a couple of times. First of all, we want to prepare the platform and the documentation. This is a time when your platform team can work independently. Then we want to find some pilot teams that will try it out, and we try to find teams with different use cases so we can cover most of our final audience.

In this phase, we have close collaboration with a pilot team, so we want to get their feedback, not just on the platform, but also on the documentation, because we want to make sure that we are answering all the questions and we are giving them all the information that they need to use the platform. After this stage, actually, these pilot teams will become your ambassadors, because they will go and tell to the PRs, “We tried this. It’s easy to start using it. We are seeing great value”. When we are doing workshops or presentations about what we are doing, we are asking them to do a demo, because that’s a demo, not a real service. It’s a demo on a real product.

After this stage, we want to go to the GA adoption. When we want to go there, we want to work in a self-service mode. This is why it’s so important to prepare with a pilot usage. If you think of how companies work, they also have alpha and beta versions that they expose early to customers to get feedback, to improve, and then they have the GA version released.

As I mentioned, for small initiatives, it’s good. You can do this just once for the initiative. For big initiatives, we also want to divide the project or the initiative into stages. We don’t want to build all at once, but we want to go fast and in a short time to provide a minimum viable product. Then we can add features gradually to cover different use cases. Then, if you get some other requests by your teams, you can save them and you can prioritize them based on the needs. If it’s something blocking, you might want to do it earlier and to change the milestones that you had in mind. If it’s something not blocking, you can just leave it for later. Just an example, I have here the stages that we could identify for the migration of the repository management system.

First, we allowed our users to create new repositories, and we told our development teams, “We have now this capability, if you want to try it out for storing some file or some text document, something for which you don’t need CI/CD system, you can already try it out and give us feedback”. Then we had a Jenkins integration, so with that, every new repository could already be created on GitHub. Then we worked on the automation for the migration, and we first migrated our product repositories and then the platform repositories, or the infrastructure repositories that have different needs. Finally, we did the Jira integration. Although it was a feature for which we got a lot of requests, it was not blocking for us to finalize the migration, because for that, we had a strong deadline, as we didn’t want to renew our subscription with many seats.

Once we are ready to give something to the teams and we want to ask for adoption, we were always thinking, what is the best way to do this? We have seen many things, and we have tried many things, and always we found some things that we can improve. After some time, I decided just to document this. It’s not only me also that is sharing these requirements with the team, but now I can ask any of my engineers in the team like, go and follow these guidelines and do this for the initiative. We use this launch toolbox when we need work from multiple teams. It provides insights for everyone about the requirements and status of the initiative. We have this documented template so anyone can set it up.

It consists of several things, and I will talk about a couple of them. We have one-pager with all the information. These are all the information that the feature team needs to know, the Jira template, status dashboard. For these three, I have separate slides, I’ll cover them. Then we have also this Aha ticket. We use Aha. This is where we have the roadmap of the company. We want also in the roadmap of our engineering department to set a ticket that, ok, the feature teams will need to allocate time for this. With this, besides the tickets in the roadmap for the product, we have also our tickets so the team can plan the time that they need to dedicate to this.

Finally, we have some guidelines for communication, to send an email, to communicate in some channels. I bring it up on some ops meetings. We just want to spread out the word. You cannot over-communicate if it’s important.

If we deep dive into the first three items, first around the one-pager. Here we want to give all the required information to the people that should work on the initiative. This is the entry point for them. We don’t want just to tell them what to do, we want in the intro to give them the business value that they will bring by working on this. We want to motivate them. We want to see who are the impacted teams who need to focus on this and who can just ignore this communication. If we have a timeline or a deadline, we want to inform them for that so they can plan it on their roadmaps. We want to give them the required actions.

Usually, here we can just link to the page where we have all the details. We want to understand who needs to take action, because sometimes we don’t know which are all the teams that need to take action. They need to say whether an action is required, yes or no. If it is required, to tell us the planned Jira story. For the Jira stories to help them creating the stories, we are preparing, usually, templates for ticket creation in which a sub-task we have all the things that they need to take as actions to complete the adoption of the change. With this for the users, for our developers, we ease the creation of stories and issues.

For our side, we are sure that they will go through all the sub-tasks and they will do all the work that we need them to do. We can also add some common information, like labels or an epic that is attached to this story that will give us next, the dashboards, because we want also to know like, what is the status of the initiative? This is a common question that we get from our higher management on meetings where we review how we stand. On the dashboard, usually, we can see how many of these tickets are completed. On the right side, we can see how many of the tickets are open, which teams have open tickets, and when they have them planned. We can also go to them and ask them, why you still haven’t finished this. Do you plan to finish it soon? Do you need some help from our side? Yes, have better observability on the status. I know that Jira is not the perfect thing to track, but this is the easiest setup that you can have.

If you can involve a bit more time, it’s actually good to have some telemetry from your platform, so from the code to understand, what is the status of adoption? How many, for example, services were already migrated? How many are pending, not started, and so on? Like this, you can also identify where you need to put your efforts, with which teams you need to talk and ask them how it’s going. Can we help you, and speed up the adoption of the changes.

The outcome of this, for the developers, they have products that are tailored for different needs, because we include them early in the process. We collaborate with them to build the platforms. We encourage collaborations. They’re also very happy when they can help. Often, we are asked by many developers if they can come to our team. They’re sometimes excited to work with us later. We also provide easy to find information so everyone, not just our developers, but even our other stakeholders like our management, can find easy information like, what is the status of the initiatives, and what they need to do to implement the things that we are asking them to do.

For the platform team, we have impact from the first version, because we have this minimal viable product very fast. We can tackle challenges gradually, so we don’t need to think about all at once. We know that, this part, we will do it later. It’s not so important for now. We need to focus on the highest priority. We can have successful initiatives with our toolbox, because we can just track the adoption much more efficiently. The action item is to plan gradual milestones for adoption. Start with some pilot teams to tailor the solution and cover different use cases. Build a launch toolbox for initiatives. Maybe what I have is not applicable for you. Maybe you will come with something better. Have easy to access information for all the stakeholders.

Take-Home Message

With that, I’m coming to the take-home message. It’s very simple. I hope that I convinced you that focusing on user centricity platforms and practices, you can really see how you can improve the developer productivity and experience. It’s not just for your users, in the end. It’s not just for the product teams. It also improves the developer experience and productivity of your platform team. It makes them more successful. They increase the impact, and they’re more happy to be there.

Questions and Answers

Participant 1: Could you tell us a bit more about your experience or strategies around customer channel and communication and requests? How do you handle random requests?

Petkovska: It depends. As I mentioned, for requests, we have these two boards. We have our support board, where we get requests about immediate actions on things that we support. Then we have our Scrum Board, the Sprint Board where we have the tickets on what we plan to do. If it’s about an existing tool, we would tell them to open a support ticket. If it’s about a new thing, we would tell them to open a ticket in our standard board. Then, something that we did also, for example, when we have a new initiative on these DevEx Connect meetings, the weekly meetings, we sometimes even encourage people and tell them, open a ticket with this label, and then we will look into that, and we want to get your feedback of what you’re missing.

Then we’ll try to plan for that and see when we can include that in the platform. Because for us, it’s really important to know what our developers need and ensure that we can unblock them for that option. That is one way. Then I had the slide with all the options for all the different channels for communication. In general, for each of the teams, we have one channel on teams where they can contact us for any information. It’s like a public channel. Then we have also this dedicated communication channel for dedicated projects.

Participant 2: On the topic of your launch surveys. What style survey do you find is most effective, like multiple choice free form, or like a 1 to 5 scale rating. How frequently and how widely do you send those surveys out?

Petkovska: This is more of an initiative that another team started, but sometimes we are giving them topics from our side. For example, when we had the GitHub migration, we asked them to give us a score on how satisfied they were with the GitHub migration, from 1 to 5. We often have these open questions like, what can we improve in terms of tools and processes? Then, this is where you get the best insight, because then people will tell you what you miss. After the migration, when we run this, we could see that we got so many requests about the Jira integration, and then we could just tell our management that was pushing us to start on a new project, to say, “No. This is so important. We really need to do that”. It’s also a good argument if you want to prioritize something.

This ensures that you’re prioritizing the correct thing. Something that also comes from these answers is that sometimes you just need to educate people, because sometimes you will see some comments about things that you already have, but they didn’t know. Sometimes an education, or just reminding people of what you have, what is available, is enough. Then, we did also some surveys around when we launched GitHub Copilot, then we had a lot more questions around the satisfaction, and so on. We still haven’t started to do the eNPS surveys regularly. There is a great talk by Uber that I recommend you see. I think it’s a great thing to do. We need to start that on our side.

Participant 3: I was wondering if you could say a little bit about how you handle the migrations of teams. Once you launch, teams are expected to migrate to this new flow or this new tool. How you handle it when, teams, you’re not providing exactly their current implementation, that’s why they need to migrate. I also assume that there might be some stuff that might not be provided at all anymore. Could you say a little bit more about how you handle those sorts of interactions?

Petkovska: It’s not easy. After some time, you can implement just an amount of things, and if you have a tight deadline, we had to migrate them, and we had all these support tickets. This was the time when we discovered all the issues that we might have not seen, or we had to include earlier. There was this talk by Jessica that this is a time when you lose some of the credit, some of the trust, and you need to build this up later. First of all, we were always trying to tell the team that they are also empowered to help their developers. Often, they are willing to help. Even if it’s not the team that’s complaining, we could find someone else with a similar use case that was ready to jump in and help us to bring this to the table. Sometimes we need to tell them just, please wait, we’ll do this later. We just try to assess how impactful that is, also to know like when we will bring that in.

See more presentations with transcripts