Transcript
Erin Doyle: I want to welcome you to Empathy Driven Platforms: you build it, let’s run it together. As I was putting this talk together, I happened to be watching a lot of old cartoons and reading comics from the ’80s and ’90s. I noticed a pattern that I felt would be a great analogy for the message I want to get across today. In so many of these shows, you’ve got a villain or an evil organization working towards some world domination or other malignant aims, and these are our bad guys. Then there’s often a team or group of people that are dedicated to thwarting the enemy, and these are the good guys. What often happens, though, is that the good guys are throwing everything they can at the enemy. They’re using all of their abilities, often one at a time, but are continuing to struggle to defeat the bad guys. It looks like all hope is lost and the good guys aren’t going to make it this time. Defeat looks inevitable. Then the good guys pull out one final stop. They save their ultimate attack for last.
Finally, they are successful in overcoming the enemy. They save the day, and the enemy retreats off to come up with some new evil plan to work on some other day. For today, good prevails. It was all thanks to that ultimate attack. I often wonder to myself, why didn’t they just do that first instead of wasting all that time and energy? Of course, the answer is because then there wouldn’t be a show. For those of us in the real world, I think we can learn from this. It could be really easy for us with our best intentions to think we’re doing the right thing to get the job done and save the day, but instead our efforts are not as effective as we thought they’d be. Our enemy in this story is the relentless roadblocks to engineering productivity that block us from being able to do our best work that so many of us are wrestling with every day. I’m hoping the tips I’ll share with you today could be that ultimate attack that we can just turn to first. Let’s dispatch the enemy faster so that we can get back out there and do more engineering good sooner and better.
Professional Background
I’m Erin Doyle. I’m currently a founding engineer at a company called Quotient, where we’re reimagining how to measure developer productivity and help teams achieve the best engineering cultures. Throughout my career working across various fields, I’ve spent most of my time as a full-stack engineer. I’ve directly experienced the daily hurdles that developers face in building and deploying their work. I’ve felt the pressure of tight deadlines and having to justify delivery estimates. I also know the frustration of external obstacles frequently hindering my team’s progress.
Then eventually I joined a platform team, where I was able to add the developer’s perspective. I knew that developers often weren’t getting the help they needed in the way they needed it from the platform team, and I hoped I could help the platform team support developers better. As I learned the ropes on the platform team, I realized that the communication gap was mutual. Platform engineers weren’t always getting what they needed from developers either. Ultimately the lack of understanding on both sides often prevents us from collaborating as effectively as we could. That’s why I’m here today to talk to you about how, through empathy, we can build better platforms together.
Origin Story
First, I think we need to go back and briefly review the origin of the story we’re about to discuss. Some of you lived through this like I did, and some of you, maybe your career started someplace in the middle. I think it’s important to understand how things evolved and what problems were being solved at the time that led us to where we are today with the state of platform engineering. Back in the IT operations days, there was no cloud, all servers were on-premise in a local data center. IT operations were made up of many different dedicated roles and teams. There were system administrators that only worked on networking, or storage, or operating systems, or databases and so on. Monitoring was performed by people whose job it was to stare at dashboards and would call or page someone if anything was outside the defined parameters.
Deployments were performed by people who would manually upload and configure your application to run on the requested servers. To handle all of these different roles split across different teams with different concerns, different priorities, a developer would have to open a ticket for every single aspect of what they needed support on from IT operations. These teams were often siloed and didn’t talk to each other until they had to. To make it worse, our different teams’ incentives and priorities were often conflicting. It was common to hear statements such as, poor planning on your part does not necessitate an emergency on mine. This was very much a time of throwing it over the wall and waiting. Everything as a result took much longer than it should have and felt overly painful and frustrating.
Then there was the DevOps movement. For those of you that didn’t live through it, I highly recommend reading either, “The Phoenix Project”, or, “The Unicorn Project” to really give you some rich examples of why and how the DevOps movement started. In brief, DevOps came about out of the frustration we were all experiencing from the way things were. Both developers and operations administrators were fed up with how slow and bureaucratic every little thing had become. None of us could just do the work we wanted to without countless speed bumps and red tape outside of our control.
As cloud services emerged and more tooling and automation options became available, a lot of the concerns of those dedicated IT operations roles was able to be offloaded. Developers could start to own more of these concerns themselves instead of filing a ticket and waiting for someone else to do it for them. Operations admins could start to broaden their domains of responsibility and consolidate down to one collaborative team instead of the many disparate teams with misaligned goals. We were able to start doing more, faster and more easily with less division, less red tape, and less walls between us. This was the time of the You Build It, You Run It principle. Developers were now able and expected to own the responsibility of not just writing the code but now also deploying, maintaining, and operating that code in production.
Now too much responsibility had been shifted to development teams. Development teams were still being held to the same expectations and priorities of shipping code that they were before. Now there’s this cognitive load of needing to be experts on not just applications development but this whole new domain of everything it takes to run applications. We started to see the impacts of this shift. Developer teams with too much autonomy, making decisions without alignment or consistency across the org. Lack of understanding the cost impacts of certain infrastructure choices. Infrastructure not being right sized. Lack of oversight on usage. Maybe infrastructure running that nobody is even using.
Then, of course, security vulnerabilities, compliance gaps, and improper access controls over infrastructure. We needed to shift back some of the responsibility off of developers’ plates. To respond to these issues, the pattern emerged of putting a centralized team in place to be the shepherds over the cloud. Thus, the platform team was born. The intention is for the platform team to be the provider of the platform with developers now as the customers.
Platform teams were charged with defining standards and patterns for implementing cloud solutions that meet the concerns of security, compliance, and cost optimization. They build what we frequently refer to as golden paths or paved roads, which are reusable methods supported by the platform team for implementing solutions that meet functional requirements with best practices in a standardized way. Platform teams aim to build guardrails for developers to continue to meet those concerns with sensible defaults. I want to pause for a second and just say, for the sake of simplicity, I’m using the term platform team. Your company may have another name for it. This is essentially whatever your company calls that centralized team that automates operations and improves developer experience, if you have that at your company.
The day has still not been saved. With the emergence of the platform team model, we definitely were heading in a better direction. There was and continues to be a real need to offload the growing cognitive load from development teams and allowing them to focus more on building capable and robust applications. The scope of a platform team can be unclear. What should be standardized? Who owns which decisions? Who’s responsible for what? Of all the technical concerns, non-functional requirements, and building blocks that it takes to build and run applications, where does an engineering org draw the line of responsibility between development teams and the platform team? This can vary widely based on the company, their maturity, their scale, the type of products they’re building, the tech stack, skill sets on the team.
This is going to change over time. There’s no easy formula or recipe to follow. When we get this balance wrong, we can end up with developer teams making decisions and implementing solutions in ways that have negative consequences they’re unaware of. Cognitive load is still too high. Poorly designed abstractions that aren’t easy for developers to adopt or don’t properly meet their needs. We get back to too many controls, or gates to slow velocity, like back in the IT operations days. Maybe one team gets what they want, but overall, the engineering org and the company are still losing. How do we figure out what that right balance is for our teams in our engineering org, where we’re at today? I think we have to understand each other better, but often being on separate teams with separate goals, directions, priorities, and incentives, we don’t understand each other.
After all this evolution over the years to bring us closer together, we’re still divided. Having been on both sides of that fence myself, I’ve seen the stereotypes and misconceptions we have about each other. Some things I’ve heard developers say about working with the platform team. The platform team is too busy. Platform will just say no if I ask. Working with platform is just going to slow us down, we don’t have time for this. Platform engineers will talk over my head and it’s intimidating. Or, platform engineers will judge me and I’ll sound stupid. Then, on the other side, things I’ve heard platform engineers say about product developers. Developers don’t know what they’re doing. They’re always cutting corners. Developers ask for help without doing their due diligence first. Developers never want to collaborate with us when we need it, or they’ll probably just ask ChatGPT.
Outline of Solutions
What do we do about these problems? How can platform engineers better reach across the aisle to support product developers better? In this talk, I’m going to walk through how I believe building empathy and understanding for product developers helps platform teams figure out where to draw the boundaries of their scope in order to better support where product developers are at today. I’ll talk about how through fostering psychological safety, a platform team can improve collaboration with product development teams. I’ll cover ways that I believe platform teams can improve adoption of the solutions they’ve built for product developers. Then, finally, I’ll talk about some ways that a platform team can help product developers learn and grow in the areas they may not have as much bandwidth to ramp up on.
1. Building Empathy
Starting with building empathy. Merriam-Webster defines the word empathy as the action of understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another. This is distinctly different from sympathy. Sympathy is acknowledging another person’s hardship and feeling compassion or sorrow for them, while empathy goes further. It’s really involving understanding and sharing the feelings of another as if they were one’s own. By building empathy for developers, we can attempt to understand where they’re coming from, their context, which may include what timelines or deadlines they’re under. Their constraints. Their current challenges. What kinds of things are currently on their plates. We can hopefully come to understand their cognitive load better.
Then the next time a developer needs help understanding why their deployment failed or doesn’t know how to manage an incident, didn’t properly set up the access controls in their S3 bucket, didn’t know that their app has been crash looping for the past day or how to find the logs with the errors explaining why, instead of feeling frustrated or judgmental, we can remind ourselves that they may not have time to deep dive and learn how to use certain tools that maybe the platform team is using every day. When they only need to do a certain thing a few times a year, they probably won’t be great at it or remember all of the details. They may not have time to build certain muscles. If we can understand where devs are at, what their challenges and needs are, we can shift our scope to support them properly and meet them where they’re at.
What are some ways we can work on building empathy? We could take a page out of Google’s Site Reliability Engineering Fundamentals where SREs have a goal to cap their ops work at 50% of their time. That includes ticket work, being on call, operations work or toil. That leaves the other 50% for software engineering work. I’m not necessarily suggesting a prescribed percentage, but just in general, platform engineers should be encouraged to work projects or tasks that involve software engineering. That could be internal apps, core services, tooling, automation, or improving the reliability or observability in product development teams’ apps. This allows platform engineers to directly experience the pain developers are dealing with every day.
The time it takes to get the app running after a fresh checkout. The works on my machine issues, slow feedback loops, technical debt. It can allow platform engineers to see with fresh eyes the areas that they can help improve. These are areas where maybe developers have grown used to the painful process. Or if they have this beaten down attitude of, we’ll never have time to fix this, so they just tolerate it. Or they may not know how to make a certain thing better or that there are better alternatives or options. This helps platform engineers build better solutions. By building a deeper knowledge and experience of other software engineering efforts in the org, platform engineers can be better equipped to support them from being able to help right-size VM resources, better meet scaling needs, or help make apps more resilient.
Another great way to get a better understanding of a team’s context is through embedding or dotted lining. Embedding is a strategy where a platform engineer will temporarily or even permanently be placed on a development team to help accomplish platform-related tasks for them. The platform engineer will attend some or all of the dev team’s meetings and perhaps participate in their processes and ultimately be treated as a member of the team. By dropping a platform engineer right in the middle of the team, they get a great firsthand view of what are the team’s priorities, deadlines, struggles, and pain points. What might they need help with that’s going to give them the biggest boost based on what they’re working on today or on the near horizon. It really helps lower that invisible wall between the teams. There can be some drawbacks to embedding, however.
A few areas where I’ve seen this go wrong, the platform engineer can end up being treated as just another headcount on the team, or like they’ve been on loan to the team. They can be pressured to take on regular product work. Or if the team was in a deficit that the platform engineer fills, whether that’s just being generally under-resourced or perhaps the platform engineer fills a skill set or a seniority role that the team was missing, it can be very challenging to conclude that embedding as the team may become too reliant on them.
Additionally, it can be hard for the person embedding to continue to stay connected with their original team, the platform team. Can effectively feel like they’ve left the platform team. The context they’re gaining from the embedding may not be easily shared back with the platform team until the embedding has been concluded. To counteract these challenges, it’s important that strong, clear boundaries are established up front on what the platform engineer will and won’t do. The platform engineer’s duty here is to help the product team in the ways they couldn’t help themselves before. They should really only be doing work that their platform-related skill set is best suited to. During the duration of the embedding, the platform engineer may need to attend more meetings or hold more syncs and tie-ins to keep up with both teams. The embedding should really be temporary with a concrete end date and predefined goals.
A similar approach, but alternative to embedding, is to have a specific platform engineer dotted line to a product team. The platform engineer is still a full-time member of their team, the platform team. Whenever the product team has a need for platform assistance, they have an assigned person that they can always go to and they can build rapport with over time. This can still help build that deeper understanding of the product team’s context without losing the context of the platform team. The sharing can go both ways. The platform engineer can keep the product team appraised of the latest happenings on the platform team. That leads to what I believe is the best thing you can do as an engineer on any team in any function. If we can all just do this better, we’d be solving so many problems more effectively. That’s just talking to each other.
Too often we end up speculating on what we think someone else was thinking or wants or needs. We even talk to other people on our team about what we think someone else was thinking or doing or needing. So often we don’t just reach out and talk to that person and ask them directly. Instead of wasting time and energy guessing over something, trying to understand what someone was doing or assuming you know what they need, just talk to them. Instead of just responding on a PR or on a ticket or through a terse response through a Slack message, DM that person or have an out loud synchronous conversation with them. Approach them with compassion and curiosity. Try to understand where they’re coming from and what they’re trying to accomplish. You get to know each other as humans. You help understand their problem better. You help them solve it better. You form a relationship for future conversations and collaboration.
2. Fostering Psychological Safety
Moving on to fostering psychological safety. Psychological safety is a term attributed to Amy C. Edmondson from her research on failure. It’s the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. That the team is safe for interpersonal risk taking. By fostering psychological safety between platform and product teams, we can help developers feel more comfortable approaching and asking for help from the platform team. It can facilitate the collaboration between both teams, build trust, and help developers see platform engineers as partners. When product teams view the platform team as a partner and a collaborator versus just some other silo, there’s so much more we can accomplish better together.
Platform engineers can help devs with architectural designs. Building resilient, reliable, fault-tolerant applications. Adding the right amount of observability. Building dashboards. Essentially getting the product team’s apps and features production ready. The Google SRE handbook talks about this, and states that collaboration between the product development organization and SRE is really at its best when it occurs early on in the design phase. Ideally before any line of code has been committed. SREs are best placed to make recommendations about architecture and software behavior that can be quite difficult, if not impossible, to retrofit. Having that voice present in the room when a new system is being designed goes better for everyone.
Let’s talk about some ways that platform engineers can foster an environment of psychological safety. One of the most powerful ways to help others around you feel more comfortable is by being open and honest about your thoughts, your ideas, your feelings, what you don’t know, where you need help, your failures or mistakes, and what you’ve learned. By modeling vulnerability, especially the more senior you are, the more you show that you’re comfortable sharing these things with others without fear of judgment or repercussions, the more comfortable others may be for sharing as well.
The more people demonstrate that it’s ok to share, the more you collectively build an environment where that’s just the normal and expected thing to do. When you ask a question or you ask for help, that demonstrates to others that it’s ok to not know something and to need help. That shows others that if you weren’t embarrassed or afraid of being judged, then maybe they don’t need to be either. When you share something you’ve learned, you again reinforce that message that you don’t know everything and that you’re still learning new things. That’s not something to be ashamed of. Learning should be encouraged and celebrated, not kept private. This reinforces that message that while some people may know more about a given topic, it’s ok if you’re still learning about it. We all have different backgrounds and contexts that bring us to where we are at today. It doesn’t mean you’re failing or behind if you know less about a given thing than someone else.
That thing you just learned, maybe someone else could benefit from that learning as well. The most powerful thing you can share is when you’ve learned something from a failure or a mistake. You could demonstrate that no one’s perfect, no matter how experienced you are, we all mess up sometimes. Or something doesn’t work out the way we expected it to. When you can just demonstrate sharing a mistake you made like, FYI, here’s what I did, here’s what happened, here’s what I’m going to do about it, without embarrassment, shame, or groveling, you could show others that they don’t have to be afraid or embarrassed of their mistakes either. When you can share that something didn’t work out the way you thought it would, you can demonstrate reframing that failure into a learning opportunity. Instead of feeling like we failed, we can look at these events as opportunity for learning or growing from the outcome together.
One great way to model vulnerability on a regular basis is by adopting a habit of working out loud. This is an approach where you can share publicly your progress as you work on a given task. This could be as big as a project or as small as troubleshooting an issue. As you work the given task, you can essentially talk out loud and log your thoughts, your theories, the actions you’ve taken, the results you got, and all of that as you go. This could be in a Slack thread about a given issue, or it could be a whole channel dedicated to a project, or maybe a document stored somewhere public that you keep as a diary where you can log your work on a larger task. Subset of this is learning in public, which is a method where as you learn a given thing, you share your learnings as you go in a public way.
There are numerous benefits to working openly like this. It of course makes it much easier for people to subscribe if they want or ignore if they want. That’s fine. It makes your work more visible. It makes it easier for people to keep up with your progress and the status of that thing. It makes it easier for you to keep track of the things you’ve done and what you’ve learned if you forget later, which you will.
The most powerful side effect and why I’m bringing it up here is that this level of transparency will automatically include revealing that you run into things you don’t know. You don’t always have the answer, and that you have to go through a process to figure things out. It’s a great way to help normalize that we’re all in a constant cycle of not knowing something and going through an intentional process to learn or solve that thing. The more of it we share can help others learn from what we’ve done and also help them feel comfortable sharing themselves.
A unique position that platform engineers may often be in more consistently than others is dealing with urgent and critical situations such as troubleshooting production issues, outages, incidents. These are high stakes and potentially high stress situations. People may be trying to move quickly in the midst of fear, anxiety, a lot of unknowns and pressure. This is a touchy time where it can be easy to unintentionally react with poor behavior fueled by stress. It’s therefore a critical time for platform engineers to exhibit a calm, patient, and understanding demeanor. By doing that, we can project a sense of the situation being under control and help lower the pressure and stress felt by others. The words you use and your tone is really important here during these times. There’s actually a term for this called emotional contagion, which is defined as sharing of the emotional states between individuals. This can include influencing the emotional state of others in either a negative or a positive way. Though the negative seems to be way more common.
Your behavior in these situations can really help calm others down or you could spin them up. Even if you’re nervous, it’s really important to model a collected, cool-headed attitude. You can approach the situation with confidence that we will figure out the issue and solve the problem, and then there’s no blame or judgment around the situation. Through these experiences, we can hopefully create an environment where it’s clear. It’s ok if we don’t have all the answers all the time, or if there’s things we don’t know or that we missed, we’ll get the problem solved together.
Any mistakes or failures made are opportunities for us to learn and make things better going forward. Any post-mortem or retrospective as a result of an incident is a key time to reinforce this behavior. The platform team should really be the caretakers of the blameless post-mortem being a safe space where we can really dig into what went wrong, without blame or judgment, believing that everyone was doing their best at the time with what they had available to them, and helping us learn from the experience and identify ways we can all improve.
Finally, I think it’s really important for the platform team to project a high customer service attitude and high availability. The platform team should always prioritize being available to the customers, and they should view product developers as their customers. You may use a ticketing system or some process to organize ad hoc requests to the platform team. Even if a request from a product developer isn’t urgent or a higher priority than what else is being worked on at the time it comes in, make sure to communicate with the requester to acknowledge you got their request and keep them informed of your status and estimated timeline.
Your customers can’t feel like their requests are going into a black hole with no idea of when it might get worked. You may have to put whatever you’re working on temporarily on the shelf to be available for an ad hoc request for help to triage an issue or answer a question. It may be disruptive at times, but the nature of platform is constantly shifting priorities and having to put things down to pick up later. Don’t allow your priorities to become too narrowly focused on mainly operations or your team’s concerns, but rather always be looking towards what would be best for the business and your customers, internal or external first.
3. Improving Adoption
Moving on to improving adoption. We’re not winning if the platform team puts in all this effort to try to enable product development teams to perform better, yet what they built isn’t the right fit for those teams, or there are rough edges that continue to cause friction. There’s still too much of a gap between what was built and what the teams actually need. If the platform team has built empathy for product developers and they foster psychological safety, improving communication between the teams, the next step is using that improved communication flow and understanding to build better solutions that developers are more likely to adopt and actually find useful. When it comes to building solutions for product developers, don’t just guess on what you think they need, build it, put it out there, and expect them to use it.
Platform engineers can instead utilize a product mindset to take that known problem and gather the requirements from the customer, the product developers, to understand what do they truly need. What are they trying to accomplish? What’s currently getting in their way? Check in with them to review your design, make sure it actually meets their needs, or find if there’s anything you missed. Once the solution’s been developed, continue to check in with them to make sure the solution is actually useful to them, and it doesn’t have any rough edges that still need to be addressed. Then iterate, continue to make a better fit for them.
One of the more common types of solutions platform teams build for product development teams are abstractions. Abstractions built by platform teams aim to hide underlying complexity and allow product teams to focus on their specific goals. They may purely aim to improve developer experience and productivity, or they may have baked in solutions for many of the concerns the platform team is responsible for in a way that allows developers to still meet those concerns without adding more cognitive load to their plates.
Building right-fit abstractions can be challenging. It could be easy to build something with the best intentions that doesn’t end up being as useful as we hoped, or perhaps it makes things worse in a new and different way, or may not end up getting used at all. We need to keep the potential pitfalls in mind when designing an abstraction so that we can hopefully find the right balance. When we hide too much of the details of a given tool, library, or system behind an abstraction, we make the developers reliant on the abstraction itself. They will only learn the abstraction instead of the thing being hidden behind the curtain. If the thing being hidden is something they really need to know how to use, they may lose that muscle around that thing. Or never build it in the first place because they only interface with the abstraction.
What are some ways to avoid these pitfalls? Don’t create an abstraction too soon, or because you think it will be useful. Wait until there’s a clear problem to solve first and then keep your focus on solving that root problem. Be very thoughtful about the level of abstraction you’re building. How much are you hiding of the underlying thing? How many layers of abstraction or indirection are there between the thing being hidden and the interface the end users will be using? Try to keep it as close to the bottom layer as possible.
Make the most common use cases simple and easy but allow for extensibility. This helps keep the abstraction flexible but provides escape hatches so the developers can self-serve when the abstraction needs to handle a more complex or less common scenario, but still keeping it all within reasonable guardrails. We need to make sure what we think are sensible defaults truly are sensible for the end users. You can invite devs to contribute PRs on these tools when they do need to extend them. These kinds of tools can reach their best potential when they can be built and maintained collaboratively.
I want to walk through an example. Maybe we want to provide a simpler CLI for developers to run their applications and all their dependencies locally. This is a super common use case. We’re going to create a command, start-app. Under the hood it’s going to set up and run all the things they need to run their application locally on their computer, all with just one command. Sounds great. We’ve decided to use a Makefile to define this command. This command has a couple of prerequisite targets that we’ll run first.
Then one of those prerequisites itself has a prerequisite. Then that prerequisite target runs a shell script. Then that shell script does a thing, and then it calls yet another shell script which does a couple other things. If there was a problem or need to adjust any of the pieces in this chain, it would require the product developer to dig through multiple files and understand make, docker, shell scripting, Unix and Linux commands, and any of the other CLI commands used here, just to follow what all is being done when they run that one command, let alone make any adjustments to it. If we follow this approach to hide all docker based commands, for instance, maybe some developers never learned docker or forgot what they knew because they never actually have to work with it directly. They’re just using the commands we’ve built for them. It’s just all magic to them now.
Magic sounds nice until you run into anything that’s not part of the happy path. If anything goes wrong or needs modifying with the abstraction, now developers have to open the hood and may not have the ability to resolve the situation themselves. By ability, I’m not saying that they aren’t capable. Rather, they may not have the time or bandwidth to troubleshoot or ramp up on the knowledge to fix the thing that’s been hidden from them all this time. What’s likely to happen at this point? Developers may come up with some suboptimal workaround or they just put up with the friction of whatever the problem is. Or they have to ask platform to bail them out.
Continuing with the goal of making solutions that are self-serve for developers, we want to avoid as much as possible developers being stuck or blocked waiting for assistance from the platform team. To achieve that, documentation provided, owned, and well maintained by the platform team is crucial. Any solutions built by the platform team that developers are expected to use need to be documented in a way that’s clear, easy to follow, well organized, and easy to find. If you’ve heard the same question asked more than a couple times by different people, it’s time to document that somewhere. This may be common knowledge to the platform team, but it’s certainly not for developers. Don’t just answer the question over and over, but document it somewhere so that they can find the answer for themselves next time.
Another important area that the platform team can assist with is by owning architecture diagrams. The platform team is probably the closest to being aware of the current state of the entire platform. By maintaining and keeping these diagrams up to date, it can really reduce the cognitive load for developers, especially the more senior developers who may not have the full picture of the entire platform in their heads, or deeply know or understand all of its parts. Another option is to encourage product developers to pair with you on these diagrams. Or you can invite them to contribute to them and make this something that the teams collaborate on and own together.
4. Helping Others Grow
Finally, helping others grow. I believe one of the charters of a platform team should be to own providing education around those topics that fall within or overlap with the platform team’s domain. Where developers may have less bandwidth to learn new tools, technologies, concepts, and build muscle with them, the platform team can provide support to help them learn and build that muscle more easily. There are numerous ways a platform team can add education and training to the common menu of services they offer product developers. I just spoke about the importance of documentation for the purpose of helping developers self-serve. It’s also an incredibly useful educational tool. Supplementing docs that describe the what or how to do something with some additional details on why can be really helpful. Why was a certain decision made? Why does something need to be done a certain way?
You can structure your documentation in a way that makes it really easy for someone to jump straight to the instructional part so they can do what they need to do quickly, but still include additional supporting details if they’ve got time to learn more. Maybe that’s links to reference materials. Maybe it’s sections that are collapsed by default that can be expanded, or an appendix. That approach doesn’t have to be limited to documents. Really, anytime you’re providing information to someone, regardless of the medium, you can provide the answer, the instruction, the information needed, but then also provide supporting information or ways for people to learn more if they’re interested. There may be tools that a platform team uses or processes that they follow frequently and therefore have built up a level of comfort and expertise that developers may not have. A really great way to bootstrap that experience for others is through video recordings. It could be a short demo, a longer walkthrough, maybe a live lunch and learn that was recorded.
The platform team can share tips, tricks, and knowledge that may take others years to figure out and learn on their own, and impart that to them in less than an hour. That recording, that one-time sharing is now available to the entire engineering org for years to come. Finally, a potentially stressful or fun, depending on your personality, way to sharpen skills and build muscle for tasks that may not occur frequently is for the platform team to organize and run exercises, such as chaos experiments, simulated outages, mock incidents, game days.
This allows developers to actually go through the motion of handling these hopefully rare, but high stress situations often enough, but in a controlled and safe environment where they can practice and learn so that when the real thing happens, those skills that suddenly become critical aren’t rusty. I said this before, but I want to say it again. It really all boils down to communication and lowering the barriers that get in the way of us just reaching out and talking to each other. If you take nothing else away from this talk, I hope you take away the importance and power of building relationships and strengthening communications.
Summary
To sum it up, platform teams should build empathy to more deeply and directly understand the context of what developers are working on and struggling with today. Foster psychological safety to enable communication and collaboration between platform and product teams. Adopt a product mindset to build effective abstractions that developers will actually find useful and adopt. Enable developers to become more self-reliant by making self-service easier.
Then, continue to support them and help them grow through education and knowledge sharing. When the platform team assembles to fight the evil forces of impediments to developer productivity, they can, with the best intentions, throw what they think are the right attacks at the bad guys. They can make their best guesses at what they think will be helpful solutions. They can aim to make things less complex with abstractions. They can add guardrails and set what they think are sensible defaults. With all of that effort, they may still fail to win. The ultimate attack that can save the day is when we let go of guessing, assuming, speculating, or judgment, and we just reach out to have dialogue, start conversations, and build relationships so that we can solve these problems in the best way possible together.
Questions and Answers
Participant 1: When you have these multiple teams that could be tackling one issue, like if we want to add a new tool or anything, how do you mitigate any of these like too many cooks issues that could arise from that and cause time loss and things like that?
Erin Doyle: I think it’s super important for an engineering organization to have clear ownership and responsibilities defined. I think we need to know for each repo, for each application, there must be a shepherding team. It needs to be really clear what the path is to a decision being made, who owns the decision, how do we move forward? Because I think without that, you end up with too many cooks in the kitchen. Someone might say, I really think maybe we should do this, but then it doesn’t go anywhere because there’s no clear path from idea to actually following through with the change. I think it’s an organizational thing. Unfortunately, I think it really has to come top-down. You can only do so much bottom-up. I think from VP, director, engineering manager level, that all has to come down and that we have a clear path to making decisions here at our company.
Participant 2: What would you say if you had to give a quick statement about artificial intelligence in relation to all of everything you just said?
Erin Doyle: One thing to keep in mind that I think could be critical to especially our remote workers or our hybrid workers, when we have the ability to just turn to ChatGPT or chat wherever and Cursor to ask questions, I think we’re seeing now that people are asking AI questions where before they were reaching out to their team or to their org with questions. They may be getting their questions answered and maybe it’s more efficient and maybe it’s less distracting to others because certainly getting Slack pings all throughout the day, that can be distracting. I think it also is now removing those little touch points of connection and communication that we had before. I think our days are now becoming quieter. We’re not talking to each other as much. We’re not helping each other as much. I think we need to put some thought into that.
Maybe teams need to talk about like, as a team, this is what we’re going to do. Or maybe we need to somehow replace those connections that used to be like, “I have a question. I need help”. Maybe we need to replace that with other intentional opportunities to connect with each other. I don’t have an answer for what everybody should do, but I think it’s a really important thing that teams should be talking about.
Participant 3: Do you have any experiences with winding back relationships that have already been poisoned over time?
Erin Doyle: I have. It takes doing all of these things. It takes time. I feel like it’s an act of planting seeds. I feel like anything with engineering culture is planting seeds and trying to get enough people planting the seeds. One person alone who’s doing these things that I suggested probably isn’t enough to really change our attitudes, change our culture, and our behavior. I think if you get enough people on board, and it’s talking about these things, like, we really should be changing our behavior here or changing our approach to this. I know a lot of companies have communities of practice or guilds. Maybe you have a staff team. Whatever it is, if you’ve got groups of people who are working together and talking about things, I think talking about these approaches, like we all need to start modeling vulnerability. We all need to start working out loud, like all of these things we need to do. Then very slowly and steadily, maybe we build trust. Maybe people do start talking to each other and communicating. That’s what I would recommend.
Participant 4: In terms of like the AI of it all, one thing that just came to mind hearing your response is, for those interactions that we’re having with Cursor, ChatGPT, if we have one that is successful or it unblocks, taking that and putting that in Chelp or whatever the Slack conversation where you would have previously reached out to a colleague feels like a way to reopen those communication pathways that AI have helped us close.
I wanted to hear a little bit more about embedding platform engineers on teams. Something that we’ve done at my company is we’ve had them on teams for different projects, but then they get treated like other ICs on the team and they take on more product work, which I think you talked about as well. I’m curious more for like that embedding. How do you integrate them onto a team so it’s not just like you’re just coming to meetings, but you’re like a fly on the wall. We want them to be part of the team, but we don’t want them to take on product work to the disservice of the platform perspective that they’re meant to bring.
Erin Doyle: Those kinds of suggestions I had, I’ve seen help. I’ve not really seen an embedding being 100% successful yet myself. I know a lot of companies do it. They probably have success with it. I haven’t seen it yet because of the pitfalls I described. I think what helps is starting out with a contract, a written contract that is maybe put together between the platform engineer and maybe the engineering manager on the team or the platform team manager and the engineering manager.
Like between two people who are in charge of making these decisions to put together a contract that they both agree to. It’s going to outline these are the kinds of things that this person is not going to be asked to work on. These are the kinds of things they should be, what kinds of tickets or what kind of work should the team prioritize that they would really like this person to focus on while they’re there. The timeline, like we’re looking at this many months and then it’s going to be over. Then, what are our goals for this engagement? Is there anything specifically we’re looking at to accomplish that we can call this a success when it’s done? I think that’s really important.
See more presentations with transcripts
