Transcript
Stenglein: My name is Dave Stenglein. I am now an independent consultant. Spent about half my career doing systems of the Unix SA, back when there was more than just Linux. I've been for the last 15 years doing consulting in software, and cloud, and workflow, and things like that. I'm going to talk about empathy, and empathy with platforms. I'm also going to tell you about how you can use empathy in building your platforms as well. This is a non-technical talk, but there's lots of interesting things having to do with technology in here.
A Tale of Hubris: A Costly Mistake
We're going to start with a story about something that went sideways with implementing a platform. We had built a cloud native platform, and we were going to embark on a project to extend it. The platform was very nice. It was built on the Netflix stack. It had automated deployments, blue-green. It used, at the time, it was a while ago, many of the tools available for getting really good visibility. It was a great platform, but everything can be improved. There were a number of usability issues that we felt needed to be taken care of so that the users would have a better understanding of what was running where and how to actually separate their deployments, figure out, not what was running where but when it had been running, all sorts of things that we thought would make for a better user experience.
We got approval for a project to extend the platform this way, and we got to work. We started building. It's what tech teams do. We knew what needed to be done. We sat down, like I said, we built this thing so we were in the best position to make what was needed for it. Then we got to time to demo with the customers who are not stakeholders, we got sign off for this from the stakeholders. Those are not necessarily the same as the users of the system.
When we started demoing our solution for the platform to them, we started getting negative feedback, and we were not somehow meeting their expectations. Then we went back to the drawing board, we took the feedback, wondering why we were so far off the mark, since we built this thing in the first place, and we knew what it needed. We should be able to put something in front of them that would knock their socks off. We ended up doing this a few times, going back, demoing, not getting particularly good feedback. Until the point where we figured out we had a pretty fundamental disconnect with what the users expected and what we were building.
In the end, it became clear that no one was going to use this thing. It didn't matter if we were going to try and finish building it, no one's going to adopt what we were building, which is not what you want to hear when you're building a platform. We ended up with a canceled project, which is costly. You build something with the intent to accelerate teams, and you end up putting a lot of work into it. That's time and money spent that did not go towards making the company more effective. What happened?
It came down to a matter of our opinion versus our customer's perspective. We had an opinion that we knew what needed to be done, and we got to work more or less in a vacuum. We did not consider what our users' perspective was. We didn't consider that their idea of what was a good solution and a good change for the platform did not match what we thought was the same thing. We thought we're aligned, we're not. Our idea that we built it and therefore we knew what was best for it did not work out at all. We didn't have empathy for our customer. We didn't attempt to sit in their shoes, find out what their lived experience was, and see what they needed. We assumed what they needed and it just didn't work out.
How Does Empathy Change Things?
How does empathy change things? What do you think when you see this? Before I think, aw. Thing is, that is sympathy, not empathy. Sympathy is your reaction to seeing someone in distress, and you're not necessarily seeing that from their perspective. Empathy is the ability to see experiences from the perspective of someone else. This is important from sympathy, because sympathy is just seeing a negative emotion or essentially having a negative emotion when you see someone in distress.
Whereas you see this, and this may be triggering for a few people that are old enough to have seen server rooms, you can imagine what this person is going through. You're able to see from their perspective, probably because you've even been there. Empathy isn't just about negative emotions, you can also experience excitement through other people. You can essentially be excited for someone because you know what they're experiencing, now that's a good thing. Empathy is important for understanding someone's perspective, and knowing why they might see things in a good light, or bad light.
There are certain do's and don'ts with empathy. You do want to listen. It's very difficult for technical people to just listen. It's almost always the first thing they hear, they pattern match, and then they start solutioning. Instead of listening to the person that is telling them something about what they're experiencing, and deciding what they need to do with that. You need to ask questions. If you're going to listen, you also need to do some active listening, which usually involves asking questions that are not leading to a specific solution.
Like, why haven't you used this? You're trying to get to the core of an issue, a pain point that somebody is having. You want to be vulnerable, asking questions, and showing that you don't know things, which is also very difficult for technical people. You want to go in and you want to show them that you're very capable, and you can solve whatever problem they have. Even if you don't know what it is, you might just start trying to solve it. Instead, show some vulnerability, show that you don't know everything, which you don't, whether or not you're willing to accept that, and work through that. Don't explain. It's very easy, especially as a platform owner, to go to a group of users who are having trouble with your system, and explain to them why they're doing it wrong. That is a classic mistake that many producers of systems have made.
Don't minimize. This goes in general, this is across all forms of empathy. If someone had something bad happen to them, don't tell them, it could have been worse. If somebody is complaining about the build's taking a half hour, "At least you're not doing it by hand and taking four hours." It's not exactly empathizing or experiencing something from their perspective. Again, don't solution. Don't go in and immediately try to solve a problem, before you even have taken the time to understand what the problem is.
Why Do We Build Platforms?
Organizations build platforms to scale. That comes from too many people doing too many things. DevOps was this effort to have people own their own destiny. They became full stack engineering, everything down to sometimes the most minute details about how their software ran and got deployed. Also, that they could move faster and not be impeded by the other teams effectively around them. That works up to a point. Then as you get larger, and you scale out, and the number of concerns that come into play, from security, to audit requirements, to performance, to all sorts of things, it starts to work up into a large amount of cognitive load. What is cognitive load? Cognitive load is actually an area of academic research.
We throw around the term all the time, but it is the study of what the effects are of difficulty learning. If a person has the right makeup of cognitive load, when they're being presented something new in a learning environment, they'll be more readily able to absorb it. We've extended it into the idea of work. Actually, NASA has an interesting concept that they worked up with, I think the shuttle program, called mental workload, which takes cognitive load and deadlines and environmental factors and all of that, which we experience sometimes, and they call it mental workload. Cognitive load works for us. There are three parts to it. There's intrinsic cognitive load, which is essentially the problem you are working on. There is germane cognitive load, which is the stuff you need to know to be able to work on the problem. Then there's extraneous load, which is unrelated to what you're trying to do.
A quick example of cognitive load is taking a drive to the supermarket. You need to intrinsically figure out the route, do the driving, and get to the supermarket. What's germane is you need to have a license and know how to operate a car. What's extraneous is the traffic and potentially detours you need to take around your route, because that's unrelated to what you're trying to do and that is extraneous workload. When we get this big pileup of too many people doing too many things across an enterprise, you get all this extraneous load spiking. The overall efficiency of the organization starts to drop. Platforms get scale by capturing more of this extraneous cognitive load into the platform. They capture work, meaning a user doesn't have to do that work anymore. Or if it's something we can't entirely capture, we abstract it and make it simpler. Anything that's left that we're unable to take completely away from the user needing to do, we make it simpler to work with.
The Most Effective Way to Build a Platform
What's the most effective way to build a platform? You want to build your platform as a product. There are some reasons for that, that line up with empathy. A product has customers, customers have choices. That's a little different from how we're used to working with things that are internal, even though there's been plenty of situations where internal customers decided, we don't want what you're providing us, we'll just take our credit card to Amazon and get whatever we need. You have the birth of shadow IT.
If you treat your platform as a product, and you need to make that product the best option, you want it to be that best option, because the other alternative, even if they don't go off and hand a credit card to someone for an alternative to your platform, it's just as not do the migration, not adopt what you're trying to put in front of them. This is bad, because suddenly you've built something that is potentially just another layer in the stack of platforms that the company is collecting, because another one has been built. It's not compelling and solving problems that the users actually need solved. It's just going to sit out there. It may not even get canceled, it may become just part of the growing spread of tech debt in the company rather than actually solving solutions.
The old approach was very transactional. We would take requests from users through a ticket system, usually. I need feature x, or I need the build system to do y, or something like that. We would take these things and potentially synthesize them into a platform, or we would even take groups of requests and say, you're asking us to do this work, we need to figure out how to make this much more automated, or we're not going to survive under the load of requests. That is, unfortunately, the old way of doing things, very low understanding, and very little empathy because of that. There's this barrier between groups, and it's ticket systems and requests. There's very little collaboration. Platform engineering is about building for others, not for yourself.
This is the essential mindset shift of going over to platform engineering, as opposed to systems administration. Sysadmins and even DevOps engineers, and a lot of these, they were responsible for the piece of the system that everybody used, and they were responsible for maintaining it, and changing it on behalf of others. Whereas platform engineering, and a platform team should be building a service, ideally, very much a self-service product for other people to use. That's a big shift from protecting yourself from work with automation.
The new approach is to create an appealing product. If you're creating an appealing product, you probably need to know what makes it appealing. If you use empathy and get into your user's shoes, and see what it is that they need, then you're going to be a whole lot more successful than firing random stuff off of them based on what you think they need. Seeing from their perspective is like a superpower, if you're building something that is a product that you want people to adopt. Product-driven product organizations have known this for a long time, they've operated in this way. It's only time for platform teams to start behaving the same way with their internal users. You get happy users which are then satisfied customers. You're thinking of them as customers that need to be happy, need to be satisfied in order for you to perform well, is like I said, a big mindset shift.
Benefits
There are some big benefits out of this. You're more efficient with company resources if you're focused on building what the user needs, what they've told you they need. For instance, if I have five features that I'm building, but only two of them are actually useful for our internal customers, that means three of those things I spent money building, but they're not contributing to anything, they're just waste, effectively. I've just created tech debt. With that being said, if you take five out of five things, and you make those all useful to the engineering teams, you're going to be making them more effective than if you only built two other things that are useful to them.
Your acceleration is able to grow. If you do the first two things, you're probably going to get much higher employee satisfaction. A lot of situations with engineers, and a lot of the focus on developer experience has been about satisfaction, employee satisfaction. If you're working to make things that they need, and see things from their perspective, and eliminate their pain points, of course, they're going to be happier. This creates a virtuous cycle. If you start with figuring out what the users need, and then building it, they will adopt it. That will make the whole company more efficient and effective. That will make happier users. You will be able to continue doing that. If you just go and build something and expect people to use it, and they don't adopt it, your cycle just ends. You're essentially blocking the company from being more effective, more efficient, and getting into this cycle.
Putting Empathy to Use
How do I put empathy to use in building platforms? First, you need to create a culture of empathy. We're talking about a human emotional system. It's probably pretty important to put in a cultural aspect to it. You need to start listening. Everybody needs to learn to stop talking for some period when they're addressing other people, and figure out how to hear what they're saying, be active listeners, and engage with them as people. Getting to know your co-workers and your customers as people, is pretty important. You're not going to feel comfortable getting into their shoes, or shadowing them, or figuring out what their life is like, if you can't identify with them at all as people. The solution used to be, let's have a drinks night, a happy hour.
I think someone said, some people would be put off by happy hour, so call it snacks and refreshments, or something. Get people together and have them see each other as people. This is really important for establishing work relationships, in general. Things will run more smoothly. In a product sense, it'll give you the opportunity to talk with them frankly about what they need or don't need, and get to the bottom of their problems as opposed to just their requests. The way this starts is with using modeling behavior. Anyone can use this kind of approach to co-workers and customers by simply doing it. You do it in front of other people, and that's how other people learn it's done. Leadership comes from any level of the organization, it's not something you need to be a manager in order to demonstrate. You just show a better way of doing things, and people will start following along.
Product management practices. Product companies know that they need to understand their user and what their pain points are, and what they have to solve. Using a lot of these techniques is going to be beneficial when trying to do this for a platform. Surveys are really important because they're subjective data. When you're trying to understand someone's point of view, you need to know how they feel about something. You can't ask them, or you can't measure them on their deployment frequency or something like that.
That doesn't tell you how they feel about the system. You need to survey them, and ask them, do you feel like you're as effective as you could be? That kind of data point is actually surprisingly valuable. I've seen instances where organizations did no DORA metrics measurement, did all subjective surveying, and still managed to have their DORA metrics just pop up on their own because they went from deployment every 2 weeks to 20 per day. They did not focus on the DORA metrics, they focused on the subjective experience of the developers and what their pain points were, and what needed to be solved for. Focus groups. You could use them in your platform team. Bring together your best developers or the ones who don't like your platform so much, find out why.
Shadowing, this is just do a day in the life. Work alongside your developers, see how they use your platform, and experience it firsthand. You should be dogfooding, too. If you build a platform but you don't actually use it, then that's going to have obvious downstream impacts on usability. If you don't use it, then why should they? Roadmaps, they're really important to communicate that you've heard the user. If your stuff is on a roadmap, then you know that your needs are being considered and might actually be met. Whereas if your needs are not on a roadmap, and everyone looks at the roadmap and scratches their head and say, where did this come from? That shows a pretty big lack of empathy.
If you've ever been in a community for gaming, a hobby, or something like that, you've used something from a company, and the community has asked, "We have this particular pain point, can you fix it?" You can tell a lot about a company of how they answer that, and what they do about it. The ones that empathize with the users will at least say, we'll try to work on this. Others will say, out of hand, like, we don't care. We're after new users that are maybe not you. You can't really afford to do that with an internal platform, you need to work much more closely with your users. Then iterations and feedback. If you are building a product, you don't want to sit on it for a few months, and then put it in front of people and find out they don't like it, and that you have a whole lot more work to do. Consistently putting things in front of your customer, getting feedback, figuring out if you're aligned, effectively working agile is the way to go in order to achieve empathy integrated with your process.
The DevEx framework gives you a really nice way to go after what's important and ask the right questions about what your platform could be solving, or what kind of pains that your users are having that a platform could solve. Because all of these feed into each other in one way or another. If the feedback loops are not as tight because the builds are taking too long, then fixing the builds, period, the amount of time it takes will help them stay in a flow state for longer, because they won't have to wait for feedback from the build. If you abstract away a lot of the deployment options for working with AWS by hiding a lot of the complexity and reducing the number of types of deployments they can do, you reduce the cognitive load, and get them working faster.
There's a reason flow state is at the top because the longer you're in the flow state, the more you're going to get done, and the more you're going to do for the company. Also, consider cross pollinating teams. In the open spaces, one of the topics was software engineering versus platform engineering. It's like, it really shouldn't be an us versus them type thing. You want software engineers, if at all possible, working on the platform. I think one of the topics was also, how do you get from software engineering to platform engineering? My argument is, any organization should be really happy to have software engineers on the platform engineering team, because that gives them the diversity of viewpoints to see, are we building the right thing? Are we satisfying our customers if we actually have customers on the team? At the same time, the platform engineers would do well to go out and actually work on their teams, their customer teams, and see what the day in the life is for a developer.
Examples in Practice
I'm going to talk through a few examples in practice over the last 10, 15 years of doing consulting with platforms. Before we get too specific, I'll ask a question, how many people have used an API or a CLI or a system that they really liked, and was really happy with how it was implemented for them as a user? How many people have used something that was really terrible that really seemed like, do they even use this thing? There's a good example of platforms created without empathy when you think of like, did they even try to use this? Or did they just say, we need to do something, we need to provide them some interface, but we're not going to use it. Netflix has a CI/CD tool that they built called Spinnaker, that they published open source back in 2016 now.
The little consulting company that I was in, got involved towards the end of the release in order to make it actually usable, because we'd had a lot of experience up to that point, implementing Asgard, which was the predecessor or maybe even older to Spinnaker. It was not particularly friendly to set up for use. A lot of the Netflix stack was made for Netflix to use. A lot of people tried to adopt it, and it wasn't that easy to get into as an ecosystem. Knowing this, we offered to come in and help with the OSS release, and make it more accessible to more people because Spinnaker was going to be wildly more complex compared to Asgard, or previous tools.
There was a fleet of microservices that you had to bring up, configure, figure out how to run, and just experimenting with it was going to be really difficult. We stepped in, and the work we did was not outrageously difficult or anything, it was mostly creating a metapackage in Debian, so you just did one install. You pulled it all down, you had a little bit of configuration to do. Then you had an experimental Spinnaker that you could work with. The Google team went and really productionized this eventually by writing a full operator for Spinnaker on Kubernetes. At the launch, there was no concept of what it was like for a team that wanted to use this, how they would even deploy it.
Part of that is because Netflix never deploy Spinnaker, they just upgrade Spinnaker in place. They just deploy and deploy. The thing, it's its own dogfooding. For an open source community, it didn't represent a very good experience. This is an example of self-advocacy because we knew what it was like. We were end users of Netflix's open source products. We knew what it was like to just take their stuff and try and work with it as they produce it. We stepped in, and we tried to help. This is an awesome way for platform teams to work with their own customers, take in an inner source model, and allow participation in the platform to make it better. The people who are going to provide the best experience for users are the users themselves. You just need a way to let go and figure out how to incorporate user contributions into your system.
This was a large cloud migration. When I say large, it was like hundreds of apps and dozens to 100 teams just doing the migration portion of it. This wasn't the app teams even. There was a platform built for these migration teams to use, and moving all of these apps over. It was expected to be cloud native. The customer wanted a completely immutable infrastructure deployment. Terraform was the de facto standard. They wanted immutable instance images. That's all well and good, but the platform they provided for all these engineering teams to do the migration, it fell short. It didn't take one of the most common use cases, which is like a Java Tomcat app in an enterprise, and they didn't provide a standardized build of that.
Every team had to go and figure out how to get Tomcat out of the internal company marketplace vendor thing and build an image, and figure out how to have that image boot and take in parameters from the cloud launch environment and configure it. Every one of these teams had to figure it out from scratch. That resulted in a program that took months for even the first app to get across the line, and enormous amounts of money wasted because they did not put the effort where it needed to be in the platform. They displayed very low customer empathy. They basically said, you're doing it wrong. It was a classic situation of a platform team that really, they're under their own stresses, but at the same time didn't consider how much pain they were causing, therefore, how much cost it was resulting in.
This example is from my wife. She is an avid knitter. A couple of years ago, she told me about a couple of things that happened in the knitting community. A couple of tech bros bought knitting.com years ago, and they displayed very little empathy for their potential customer base, kind of belittling them. They had very little diversity. Product companies know that if they want to understand a customer, they need some people like their customer on the team. One of the guys had a 7-year-old daughter that had gotten into some knitting, and so therefore they thought, buy this knitting.com domain, sounds really cool. They proceeded to really not understand the demographic at all.
The domain is still around, I just have no idea whether or not their business plan panned out. They actually had a podcast called the most transparent podcast on the internet, that they ended up taking down after one episode, after they insulted their customer base by quite a bit. Also, in knitting, it was interesting, they came in, they thought they had this big market to dominate. There is an existing platform out there for community and patterns that get sold, called Ravelry. Ravelry, they did a reskin of their site, they made it less accessible, to the point where they had flashing lights on parts of the site. To this day, years later, they've still not backed down on these inaccessible features. When you think of the demographic involved with knitting, you want it to be accessible. They showed incredibly little empathy for their customers.
Key Takeaways
You need to see people and not problems. That's a huge part of empathy is if you can identify with the person first, there are a range of options in front of you. If you focus in solutioning a specific problem, you're narrowing your possible set of solutions unnecessarily. If you take the time to listen, take the time to see people and the variety of issues that they face, you're going to end up with much better results. Listen and try to understand goes with that. If you don't solution first, you're going to find out a lot more a lot faster.
What often happens with technical people is you go in, somebody says something, you cut them off, and you start solutioning. They say, no, that's not it. They start saying more and telling you more, you cut them off again, you start solutioning. The whole process ends up taking longer than if you just let them talk and tell you what they needed to tell you. Then you started identifying what might be done as opposed to running straight into the solution.
Remember who you are building for. You're not building for yourself, if you're building a platform team, and you're building as a product, you're building for customers. If you can keep that in mind, and start figuring out how to address that. A lot of the stuff that we're talking about is all actionable on an individual level. You can start doing these product management type things or other stuff, but if you work on a platform team, you can start tomorrow, learning to listen and not immediately solutioning. There's a bunch of things here that you can do at work. Build a product and make it appealing, and not appealing to you. Make it appealing to a customer. That will require you to get in your customer's head and figure out, is this really what they need, is this appealing?
Product management methods. There's a whole universe of product management that, unfortunately, internal tech teams are usually not aware of at all. One of the best things you could do is hire a product manager. There's actually a whole segment of product managers that have specialized on internal platforms. They're out there. There are people who could help you almost immediately if you look for them in figuring out this problem of managing your platform as a product. It's a new space. I'm not saying there's a huge number of these people out there. When certain companies like Netflix decided that this was something they needed to do, that people were already there to hire. This is going back a couple of years already. There are people out there who are ready to exercise product management practices in service of internal platforms.
Example in Practice
I did have another positive story that happened with a team that we helped. It was an e-commerce arm of a hard goods company. They had a complex Kubernetes environment, and they wanted to automate a lot of the deployment flow with Spinnaker. With that program, we sat down with them for about 10 weeks, we did some discovery. Then we had someone colocated with them for a significant amount of that time, understanding what they needed, doing fast feedback, and demoing regularly.
Then in a fairly short period of time, delivering the initial pilot system that they needed. As a consultant, we often build things for people, and then we hand it off, we try and hold it steadily. Sometimes those things fall over as soon as you walk away. I was very happy to find a year later when we went to the Spinnaker conference, they showed up, and they talked about how they'd adopted this system, migrated all of their flows to it. They had even worked on extending it. That was a really great alignment that happened.
Questions and Answers
Bryant: Do you have any advice for empathizing up and down in the business, because I've struggled with when I was an IC empathizing with how managers think, how leaders think, and vice versa? I'd love to hear your take on how you've liked the empathy for folks in the business that may be above or below the hierarchy?
Stenglein: My default answer is usually that it needs to come from the higher levels first. It's very difficult for empathy to happen upwards if it's not happening at all downwards. If you're in an executive position, and you show no empathy, then people aren't going to have any empathy for you. Executives have a different set of concerns that they have to manage. They are responsible for the health of the business, which ultimately results in the health of the employees' employment. It's very difficult for them to communicate that, and sometimes executives communicate instead, they're only concerned about the health of the business. It's not even a secondary or tertiary concern that employees will still be employed.
The ability of the executives to first take this kind of empathy into account is important, but you can also over-empathize. That's another thing to do. If you're running a platform as a product, or you're running a whole company, you've got to be careful about over-empathizing relative to your position. If you over-empathize with every single customer that comes through with every single request, you're not going to gain any ability to prioritize or anything. If you over-empathize with all of your employees, and you don't do what's necessary for the company, in hard times you could end up with a place for no one to work at, as opposed to, unfortunately, having to let people go. It often starts with modeling behavior from the executive on down, that will then make it easier for everyone to empathize.
There's another interesting, related thing, is that, there was a study that I looked up, it said that customers of e-commerce sites that felt that the company had empathy for them, were more willing to excuse outages. You could think that'd be very useful as a platform team. If you develop enough empathy bank with your users, that when you do have your outage, and you will, that they'll let it slide. Whereas if you have an antagonistic relationship with your users, and you have an outage, you're going to be out of a job.
Participant 1: How do you get those requirements and build empathy with the customers when what you're needing to build isn't a product request from them. Maybe you need to do something, you need to make a change that's solving a different concern that isn't initiated by those developers. You're going to build something that they have to use, but they didn't ask you to. It's not a priority to them that they may not care about.
Stenglein: You got to make it appealing unless you're going to get into the kind of like antagonistic IT scenario. Again, do you have any goodwill in the bank, and can you put the users through a certain number of forced migrations to things? That's only going to go so far. At some point, they need to have something that's in their favor. With these kinds of things, you may need to look at it as you're not doing it so that they have to.
The whole company needs to do this. It's not usually the platform team going off and dreaming up new ways to make everyone's lives painful. It's like, the company has certain priorities that they need to make, and the platform team needs to do certain things to fulfill it. You've got to tie it to the long-term story of why this is better for everyone, including them. You got to tie the story together and make it valuable to them directly or indirectly.
Participant 2: [inaudible 00:40:51]
Stenglein: I think it has a lot to do with relationships and vulnerability, and who starts the process. There's a certain amount of strength needed to be vulnerable. If you can demonstrate that with the modeling behavior, and start moving. It's like any change movement. It's showing the leadership from wherever you are, that this thing is effective, and it's a great way to work, and keep pushing it.
It's not always going to work. If the organization around you is anti-empathy, if it's on the left end of the Westrum scale, you're never going to get empathy to work in a pathological organization. You can start to get it to work in a bureaucratic one. Of course, you want a generative organization. There's a certain level of how appropriate it is for your context.
Participant 3: Suppose you're building a new application, and you have a good [inaudible 00:42:29] so you're implementing new business requirements. In those scenarios, how can you actually be in the shoes of the person who may use the system, managing things in that new environment altogether? How do you feel the empathy for the users of the system because it's a new thing altogether.
Stenglein: It comes down to asking them for one thing. Even though they're new business requirements. They're new, and they're a change. You can ask them simply, how do you feel about this change? What is this going to mean to you? That's frequently a thing you do in technology, like we have some new detailed requirement for remediating patches of a certain level within 24 hours, are you going to be able to do that?
You do a deployment every three months, what's that going to be like? I feel like you're asking, what do we do with external requirements? You still need to ask. Because even though they're external requirements, you're the one implementing them. You want to do it in such a way that they'll want to do it. If you just shove it at them and say, new requirements, you'd better migrate and upgrade. It's going to be a very different experience than if you say, we've got some new requirements, how are you feeling about this? How are we going to work together to make sure that we actually all fulfill this?
Bryant: Where do you draw the line between too much empathy? The case study example here was, when some users have picked up bad practices, you listen to them, and you're actually encoding those bad practices into your platform. How much is too much empathy?
Stenglein: If you're running your platform as a product, you need to also think about it as a business. Businesses should have a focus. That's why if you're running a platform as a product, and you're using empathy, you're also not able to do everything everybody wants, because your product will just become this giant mess. You need a way to prioritize while having empathy.
That's what product companies usually explain. You go to them, you say, I want a feature, if it's an enterprise thing, or a game, or whatever, and they say, "If enough people want it, we can consider it." Or they can say, "We make iPhones, we're not going to start making marshmallows too." It comes down to having the business side of what it means to operate a platform as a product.
Participant 4: I was talking about empathy really, it's a challenging thing, because it depends what you mean by it. It's emotionally charged. If you're going to actually empathize, is it cognitive empathy, is it emotional? I've had a charged type. I'd like what do you mean by empathy a little bit more, because, obviously, that can mean lots of things to lots of people, where in product it's usually about pains, what are the things they're struggling with, what can they get through, as opposed to trying to see their perspective all the time? If you truly get it, and they usually get emotionally upset that they are? How do you find that balance? Because I find that sometimes empathy is a charged org.
Stenglein: This comes down to sometimes emotional contagion, that's called, where you start experiencing the emotions of someone else. That's important for human connection to other people. The cognitive empathy, the actual modeling of their perspective, is, you want to establish the human relationship, but you also want to do the work to understand their actual perspective, which is what the emotional side doesn't give you. Of course, you can go way too overboard with empathizing with people.
You need to keep your perspective separate from what you're doing, which is modeling their perspective. Just because you're modeling sitting in their shoes, doesn't mean you're actually standing in them. I've seen plenty of people, especially in management situations, they start over-empathizing with people. It always comes back to the CEO thing, like CEO can't over-empathize with employees. He's got a different set of responsibilities.
See more presentations with transcripts
