Month: September 2019

Article originally posted on InfoQ. Visit InfoQ

There are a lot of good reasons for building a CQRS and event-sourcing based system, and some benefits are only achievable in such systems, but there are also problems that appear only after an application is in production (day two problems). In a presentation at the recent Event-driven Microservices Conference held by AxonIQ, Joris Kuipers shared his experience running and evolving CQRS and event sourced applications in production.

For Kuipers, CTO at Trifork Amsterdam, one problem he sometimes sees is that people start to build this kind of system too early, before they really understand the domain. Later, they gain new insights which requires models to change. However, you now have events that map to certain aggregates which don’t fit in new models. This requires a refactoring that can be very hard to implement.

If you are building a traditional system that only stores current state, it’s often quite easy to change state during an upgrade; commonly, the only thing needed is to run some SQL statements during deployment. When updating a CQRS and event sourced application, this doesn’t work. Typically, new functionality implemented will publish new event types and new versions of events. To minimize problems in such scenarios, Kuipers refers to Postel’s law, a robustness principle that states:

Be conservative in what you send, be liberal in what you accept.

For an event sourced application, this means that you should be conservative and consistent when emitting events, but liberal in what you accept; avoid validation against schemas and allow information unknown to you. Kuipers emphasizes that being liberal also includes your own events, both from the past and the future. It’s very important that both older and newer versions of an event sourced application can coexist as they evolve.

For external event processors, it often works well to ignore unknown event types and unknown fields in an event, but Kuipers points out that this is a general rule; there are exceptions, and a developer must make a conscious decision. For internal event handling, it’s more complex. Both in blue-green deployments and in the case of rollbacks, when a new version is misbehaving, different versions of an event may have been stored which requires forward compatibility when reading events. In Kuiper’s experience, this is extremely hard and often means that organizations instead accept downtime. If possible, Kuipers recommends roll-forward — use small and frequent deployments, and if a problem occurs it can be fixed, and a new version deployed.

A problem for public event handlers is that events often are marshalled from specific class types into JSON and XML, and then unmarshalled back into the same types. This may cause problems in external systems for new event types and for systems built on other platforms. Using metadata and annotations are often usable to mitigate these problems.

Separating internal and external events is something Kuipers has found useful, because they have different requirements. Events that are public must be more stable and must adhere to contracts and similar agreements; fields can’t just be removed or have their meaning or type changed. Internal events are never exposed publicly which means you have full control of all parts that deal with these events, which simplifies when they must change.

With a new version of an application, some aggregates may need additional state, and for Kuipers this is handled well when CQRS and event sourcing is used. Initially, the aggregates can have a minimum of state, just enough to be able to handle the business logic. But as the need for more state increases, new state can be added to the corresponding aggregates, and due to the power of event sourcing it will look as if this state has been there since the beginning.

Snapshots are often used for optimization reasons to store current state of aggregates, but when an aggregate changes new snapshots must be created. An approach that works in systems with a small number of events is to just delete all snapshots and recreate new ones as they are required. In systems where a large amount of events have been stored, the snapshots has to been recreated up front which requires some tooling.

For new query projections, a similar approach to the one for snapshots can be used. In systems with a small number of events, the projections can be recreated by replaying all events. In systems with many events, a better approach is to update the projections. One way to do this is to use custom commands and events only used during the update phase.

Kuipers concludes by encouraging people who have experience running an event sourced system for several years to share their experience with others. What does it mean to have an application running for five years, with aggregates in use that have events since the beginning? How do you evolve, maintain, and deploy new versions of such a system?

The presentations at the conference were recorded and will be publicly available during the coming weeks.

Article originally posted on InfoQ. Visit InfoQ

At the recently concluded Helm Summit in Amsterdam, the Helm project was front, left and center. Helm is already a defacto package manager for the Kubernetes community and is on the verge of entering Cloud Native Compute Foundation (CNCF) as a top level project.

Helm is an application package manager running on top of Kubernetes, and describes an application’s structure through Helm Charts, making it convenient to install and manage packages and their dependencies. Helm is akin to the OS package managers yum, apt, and Homebrew, etc.

With the advent of microservices and the need to scale and manage these services independently, Helm offers a way to do this through the use of Helm Charts.

InfoQ caught up with Matt Butcher, the founder of Helm and the organizer for the Helm Summit in Amsterdam, and explored the growth in usage of Helm’s and its future roadmap. Butcher discussed the history of Helm, how its design was influenced by other package managers, how it’s helping the Kubernetes community, it’s tremendous growth, and some of the security challenges.

InfoQ: Could you begin by giving a very brief “trip report” of the recent Helm summit, and a brief history of Helm. Can you provide some insight into how it got started and some inside stories that may be relevant?

Butcher: At Deis, I was leading a team to build the first Kubernetes-based PaaS offering, called Deis Workflow. Installing this multi-microservice application was difficult, to say the least. When Deis had a two-day all-company meeting, we had a hackathon team building exercise. The winning team at the hackathon got a $75 Amazon gift card. I grouped up with Jack Francis and Rimas Mocevicius, and we decided to tackle the problem of installing applications into Kubernetes. During the two-day hackathon, we built a tool we called “k8s place” (pronounced “Kate’s Place”) that was a package management system for Kubernetes. We won the hackathon.

The day after the all-company meeting, the CEO and CTO called me. They had been talking, and wanted to know if Jack, Rimas, and I thought that this K8S Place thing could be made into a real tool. I said that I thought it could. But we all agreed that the K8S Place name was just a little too cute for a project. So Jack and I got on a phone call and read through a glossary of nautical terms to find a better project name that fit with the Kubernetes theme. And thus Helm was born.

A couple of months later, we launched Helm to the public at the first KubeCon. And a few months after that, Helm became an official Kubernetes sub-project.

The First Helm Summit – Helm gained more traction than we had ever anticipated. But when it came to KubeCon, we generally were stuck giving pretty standard deep dive sessions. And the KubeCon organizers couldn’t allocate too many sessions to Helm because the ecosystem is so big. So Karen Chu, the community manager at Deis and then at Microsoft Azure, floated the idea of doing an official Helm Summit. For the first one, in Portland, OR, we did a single-track conference. It was great. We filled the venue, and I got to meet dozens and dozens of devops, developers, and system administrators. Brian Grant, the lead on the Kubernetes project, came. Afterward, he suggested that perhaps Helm had outgrown being a Kubernetes sub-project. He championed Helm moving up directly into CNCF, and helped us along the way.

The First European Helm Summit – The Helm Summit in Amsterdam was our first European summit. I had initially targeted 120 people, but we ended up at 130. And we had initially wanted to do it in Milan, Italy. But we couldn’t find a perfect venue. Folks within Microsoft in Amsterdam advocated for a venue there, and so we switched.

Helm Summit Amsterdam was the first Helm event run by CNCF. That was spectacular. They bring deep expertise, and were fabulous to work with. I have never been part of such a well-organized conference before.

For this summit, we switched from the single-track style of Helm Summit Portland to a two-track conference. This enabled us to accept more speakers and also provide some workshop content in parallel with regular sessions. Session quality was very high, and as far as I know we received unanimously positive reviews. I think a big part of the positivity was the size. I think I met and shook hands with almost every single person who attended. While the 12,000-person KubeCon is fun and flashy, a small conference like this enables some personal connections, providing ample opportunity to get to know people with similar interests.

The high point of Helm Summit for me was meeting Yusuke (known in the Kubernetes world by his GitHub handle ‘mumoshu’). I have worked online with Yusuke for years, and he’s contributed to many Helm-related projects as well as Brigade (another CNCF project that I started). But we had never had the opportunity to meet in person. I flew from Colorado. He flew from Tokyo. It’s a fabulous world that we live in when we can collaborate for years without ever actually meeting — and then meet for the first time on a continent foreign to both of us!

InfoQ: Since Helm is often positioned as the Homebrew / apt / yum package manager for Kubernetes, is Helm more applicable to system admins than developers and architects?

Butcher: Jack, Rimas, and I were deeply inspired by both Apt and Homebrew. Adam Reese and Michelle Noorali (who joined Helm in its first official week as a project at Deis) were both deeply influenced by the Ruby ecosystem. Together, we believed we were extending the packaging metaphor to a brand new space: Cloud native (distributed) apps.

As we see it (and I think I can comfortably speak for all of them), Helm’s first goal has always been to make the “zero to Kubernetes” story easy. Whether you’re a developer, a seasoned devops engineer, or a student just getting started, our goal is to get you installing apps on Kubernetes within two minutes.

Of course, since the days when we set that goal, things have changed quite a bit. Kubernetes has exploded in popularity. It’s now common to see production k8s clusters. At an inflection point like this, it’s good to ask: Who is the real audience for Helm?

We believe that those in operations are going to derive the most immediate benefit from Kubernetes. The Helm Hub, conceived by engineers at Bitnami (now VM Ware), is a portal designed with Kubernetes operations in mind.

But we have worked hard to make Helm Charts easy for developers to create. My team created a project called Draft that was specifically designed to help developers go from code-to-chart without having to learn Kubernetes manifests first. Our design philosophy here (as in Helm and our other projects) is this: Give people a tool to get their high-priority job done NOW, then give them the means to “learn their way backward” into the underlying technology. Ruby On Rails did this exceptionally well for the Ruby world, and we have long seen that as an inspiration for our work.

InfoQ: Do Helm Charts replace the complexity of YAML files for installing Kubernetes apps? How are some of the other criticisms, especially the complexities of Kubernetes addressed in Helm?

Butcher: Our main goal with the chart format was to make it so that a Kubernetes newcomer would never have to see a Kubernetes YAML manifest in order to install something on Kubernetes. But as such users got increasingly interested in doing more with Kubernetes, Helm would become a pedagogical tool. Again, drawing on the previous answer, Helm is supposed to help people “learn their way backward” into Kubernetes. Install a chart. Then go see what was created (after all, Helm tells you). Then change a few things. Try your changes. Look at a few more charts. See how they work. Before long, the motivated Helm user becomes a knowledgeable Kubernetes user. And all along the learning process, those individuals can be successfully deploying applications!

One thing we are proud of about Helm 3 is that charts continue to be relatively simple. We had options to add lots of different template languages, many more hooks, and all sorts of additional bells and whistles. But when we listened to our users, what we heard was:

• (a) simplicity was great for learning,
• (b) the tooling we provided was largely sufficient for 95% of the users’ use cases,
• (c) where Helm was not sufficient, a wealth of add-on tools have been created to fill in the gaps.

InfoQ: Is Helm relevant in the continuous integration or delivery (CI / CD) of microservices, and if so, what role does Helm play?

Butcher: I’m not sure that grouping CI and Microservices together is a natural fit, but I’ll try.

The microservice architecture has become something new: It has become a way to truly write and operate distributed applications. But to do this well, microservices really needs the orchestration layer that Kubernetes provides. Otherwise, it is simply too complex to wire all of the pieces together.

Helm tackled one part of the cloud native/distributed application sphere: It made the Kubernetes part easier. But I would say that we fell short in a few key ways:

Helm only addresses the Kubernetes part of the equation. But modern cloud offerings include hosted services, managed tools (like database services), virtual machines, and networked storage–all outside of Kubernetes. Helm does nothing for these. Helm does not manage the container images. It assumes that those are managed externally, and it merely manages the Kubernetes manifests.

We pondered adding both of these to Helm, but realized that this would ruin one of the key things we loved about Helm: It’s simplicity.

Following the UNIX mentally of “do one thing well”, we created a new tool to handle the large cloud-native space. We created an open specification called Cloud Native Application Bundles CNAB, donated it to the Linux Foundation’s JDF, and then created both a reference implementation and an opinionated declarative builder. CNAB works with Helm–and also with Terraform, Ansible, and just about any deployment management tool–to enable truly rich deployments of cloud native applications.

CI is an interesting story as well. We frequently deploy our Helm charts as part of a gitops-style pipeline. And the other tools we built have similar needs. But when we looked at CI and CD, we noticed some uncharted territory. Kubernetes provides the rudimentary layers of continuous operations: Jobs are short-lived pod runtimes, while Deployments are perfect for the long-running gateways. But when we took a look at the landscape in 2017, nobody had made use of Kubernetes in this capacity.

So we took the knowledge we gained from Helm, and we created Brigade. Brigade is not just a CI system, though. It is more flexible than that. Inspired by the way UNIX shell scripts allow users to chain together shell commands and pipe data from one to the other, we created a general framework for writing scripts (in JavaScript) that could chain Docker containers together, passing information from one to the other to form processing pipelines.

Brigade, also a CNCF project, provides an event-driven interface on top of this. So you can write Brigade scripts that respond to GitHub pull requests, or cloud events, or Kubernetes API events, or Kafka pub/sub messages … the sky is the limit.

At Helm Summit Amsterdam, Yusuke (mumoshu) gave a presentation in which he showed how he had taken Brigade and built a sophisticated CI pipeline for Helm charts that then handed off tested charts to a CD system that immediately deployed them into production. It was such an enjoyable moment to see someone take a little iota of an idea that I had and run with it, building something far more elegant and powerful than I had imagined when my team started on Brigade.

InfoQ: Can we ask what is new in Helm 3? How are some of the security issues of the Tiller cluster-side component of Helm being addressed?

Butcher: First, to set the record straight, “rumors of Helm 2’s insecurity are largely exaggerated”. The main complaint was that Kubernetes was not multi-tenant secured by default, which is true. One has to turn on security in Helm. A few very loud individuals spread rumors that there was some deep and inherent security flaw in Helm, when in actuality, the solution is “turn on mTLS”. (Helm itself has only ever had two CVEs, neither one critical)

Helm 3 completely removes Tiller. We were never thrilled with Tiller when we added it to Helm 2, but at the time Kubernetes was looking like it was going to go all-gRPC, and we had envisioned a more integrated experience. Instead, Kubernetes stuck with YAML and REST. So we dutifully rode out the Helm 2 cycle without making any breaking changes. Then the first thing we did in the Helm 3 branch was remove Tiller and refactor the code. Helm 3 now uses in-cluster resources with atomic versioning to store releases, but no longer requires running any code in-cluster.

We have done our very best to remain true to SemVer2, not breaking compatibility between Helm 2.0 and now. But Helm 3 is our chance to fix up many things. For example, CRDs were introduced over a year into Helm 2’s lifespan. Thus, we could not add support for CRDs in any way that might break existing clients or charts. But with Helm 3, we’ve finally been able to write a sensible implementation of CRDs.

While we’ve literally rewritten the entire clockworks of Helm, the cool thing is that the everyday Helm user won’t have to change much at all. A few command line flags changed. We introduced a new chart format (Chart v2), but almost everything will “just work” as it always has. And for established Helm installations, we’ve even got a migration tool to ease the transition.

InfoQ: Can you talk about the growth of the Helm community? Is there anything else you want to highlight in Helm that obviates some pain points for developers and architects?

Buthcer: Helm’s ecosystem has gotten big enough that I can no longer track it. One of the most petrifying moments of my life happened when an individual saw me wearing a Kubernetes logo and pitched me on their company, which made their income off of Helm. He had no idea who I was, and I never told him. I just quietly listened to his pitch, asked a few questions, and moved on. But it was a powerful moment for me. I had never really thought about the fact that a tool my team built was actually the source of livelihood for a company with 20+ people!

We used to track all of the tools in the Helm ecosystem on GitHub. But at this point, that document is no longer all that representative of a much larger ecosystem that has formed around the project. I cannot tell you what a privilege it is to know that so many projects have been built around our little hackathon project. Open source … it just blows my mind some days. Think of the thousands of hours all of these developers spread all around the globe put into building tools that “scratch an itch”, and then they offer it up for others to use and expand.

On the code side, I am just utterly blown away by the participation of the community. Thousands of contributors from over 700 companies have helped us build Helm, create charts, and manage the core Helm tools and website. Many of those people also contribute to other projects in the broader ecosystem, like Helmfile, Helm Hub, and Monocular.

I could say that I am proud of Helm. But “proud” is not the right word. It implies that I raised it to be what I wanted it to be. Rather, I am overawed by Helm. The people, the code, the ecosystem–all of these are so far beyond what Jack, Rimas, and I imagined when we first hacked out our little K8S Place demo. Two years ago, when Microsoft acquired Deis, I was asked what my hopes were for Helm. At the time, I said “I hope that Helm is a 10-year project,” meaning that I hoped it was a project that could reach a ripe old age in the fast-paced software world. And I still hope that is true. But these days, my real hope for Helm is that the vision of the community around it will continue to outpace my own shallow imagination.

In summary, Helm has become the defacto package manager for Kubernetes, and it has experienced steady growth as it solves core application development pain points on the infrastructure platform. 

More detailed information is available in the Docs, including a getting started guide.

Article originally posted on InfoQ. Visit InfoQ

In this podcast, recorded at the Agile India 2019 conference, Shane Hastie, Lead Editor for Culture & Methods, first spoke to Jeremy Kriegel about design innovation and then with Doc Norton about why Tuckman was wrong and how dynamic reteaming makes organisations more resilient.

By Jeremy Kriegel, Doc Norton

Article originally posted on InfoQ. Visit InfoQ

Brittany Postnikoff covers some of the capabilities of physical robots, related human-robot interaction research, and the interfaces that can be used by a robot to social engineer humans. She discusses the security, privacy, and ethical implications of social robots, the interfaces used to control them, and the techniques that can be used to prevent robot social engineering attacks.

By Brittany Postnikoff

Article originally posted on InfoQ. Visit InfoQ

The book Managing Technical Debt by Philippe Kruchten, Robert Nord, and Ipek Ozkaya provides principles and practices that help you gain control of technical debt throughout the software development process and life of the software product.

By Ben Linders, Philippe Kruchten, Robert Nord, Ipek Ozkaya

Article originally posted on InfoQ. Visit InfoQ

Transcript

Tevis: I’m going to ask you to engage your imagination for a few minutes. I want you to imagine that you are in the great state of Alaska. Alaska is very large, it’s the largest state in the United States. I want to orient you a little bit. I want you to imagine that you are right here. You are where Icy Strait empties into the Gulf of Alaska. You’re about 25 miles north of the town of Sitka, which is the former capital of Russian Alaska. You are there, it is a glorious early September afternoon, you’ve been on a vessel there in the Inside Passage for about six days. You’ve been enjoying the beauties of nature there; the steep-sided fjords, the crystal clear blue waters, the wildlife, the plants, all of that. You’ve gone out into a skiff with about 10 other people across the water and you’re looking out and you see this.

There are two things in this photograph that are interesting to me. One of them may have become real obvious to you, and that’s this: these are sea otters. They’re cute aquatic mammals that people seem to love and they’re great. The other thing that’s there is this, and that’s bull kelp. What’s interesting to me is that if this picture were taken in this exact spot 50 years ago, neither of those things would have been present. Also, the fact that both of them are there, and the relationship between those two is actually important to understanding what I’m going to be talking about in the rest of the session.

Here is a little brief ecological aside, it’s going to help you understand about empathy as a keystone habit. Otters, marine mammals, unlike most marine mammals, they do not have a layer of blubber, they just have really thick fur to keep them warm in the cold water. That’s good for the otters, but it’s also bad for the otters because it made them incredibly attractive to Russian fur traders, because remember this used to be Russian America. Traders and trappers basically hunted the otters to extinction in Southeast Alaska by about 1900. They basically didn’t exist there anymore. The thing about otters is that they love to eat sea urchins. You’re like, “Ok, this is starting to get a little weird, but go on.”

Sea urchins are an important part of the habitat there. What sea urchins feed on are the holdfasts that keep that bull kelp attached to the bottom of the ocean floor. This is kelp that can grow to be up to 50, 60 feet long, three or four feet a day in the height of summer, it starts out at the bottom and it grows up to that sunlight layer. If this yellow part at the bottom isn’t attached to something, it floats away and dies. That’s what urchins eat. What happened in around 1900 when the otters were hunted to extinction is that they took these kelp forests to a tremendous source of biodiversity and habitat for all kinds of aquatic creatures. The sea urchins ate all the holdfasts, the kelp floated away, and basically over about 20, 30 years this turned into this. These are called urchin barrens, because what happens is sea urchins basically go through and they deforest sea bottoms.

About 1920, ’25, if you’d taken that picture, in that spot, you would not have seen otters or kelp. This picture was taken in 2018, these were both present; what happened? What happened was in the 1960s, they said, “This is not great. What can we do?” They took about 400 otters from the Aleutian Islands and airlifted them and dropped them around the spot that I saw them just north of Sitka there. I have to imagine that has got to be a weird experience for those otters. They get trapped, they get flown 1,000 miles, dropped down the middle of nowhere. Then they just turn these 400 otters loose and they didn’t do anything else.

The otter population made a remarkable recovery, they just bounced right back. That spot where that picture was taken is about 30 miles from the entrance to Glacier Bay. When we were in Glacier Bay, we saw some otters there. In Glacier Bay in 1993, there were five otters in the park. Today, there are about 8,000 otters in Glacier Bay. Like I said, they’ve made a remarkable recovery and what they’ve done is they’ve hunted down the urchin population, which means that those barrens have turned back into these kelp forests. It means that biodiversity is up and all sorts of species are recovering as a result of the reintroduction of the otter.

It has these interesting second or third order effects which you get in complex systems like ecosystems. Things like bald eagle populations are up because the fish that the bald eagles feed off of have more habitat in which to breed and thrive. The simple reintroduction of the otter into Southeast Alaska has had a huge impact. That’s because otter is in this environment are what’s called a keystone species. This happens in a lot of different spaces, where there’s a particular species in an environment where its presence or absence determines huge features about the environment. You say, “There are 8,000 otters, that’s not that big a deal,” but look at the outsized impact that they have on the environment, not just what they directly feed on, but all these other things that they’re connected to.

The term for this in ecology is what’s called a keystone species. If you’re familiar with the reintroduction of wolves in the Yellowstone, it’s the same thing. They’ve had a dramatic effect on the landscape. The earth itself is shaped differently because there are wolves there versus when they’re not. Charles Duhigg wrote a book called “The Power of Habit” where he studied habits and how habit formation works and what do we know about habits.

He tells the story of a woman named Lisa Allen. Lisa was 34 years old, she was newly divorced. She was deeply in debt, was failing at work, and at 34 was also suffering from the fact that she had been a heavy drinker and smoked since she was 16. Just after she was divorced, she went to Egypt and she saw these people doing these treks across the desert. She says, “I want to do that.” There is something that called her and said she wanted to do it. She recognized that she wasn’t going to be able to buy a pack of cigarettes in the middle of the desert. She probably was not in the shape she wanted to be in to do this, so she said, “If I really want to do this, I have to quit smoking.”

She developed what’s called an if-then habit, a replacement behavior. What she said is, “If I’m craving a cigarette, then I will go for a run.” Simple habit. Within four years, she had not only trekked across the desert in Egypt – whereas it turns out, you could buy a pack of cigarettes in the middle of the desert if you needed to – she ran several half marathons, ran a marathon, got promoted at work, paid off all her debts, bought a house, went back to school for a master’s degree, got engaged. None of those things have anything to do with running or quitting smoking, except that this is a pattern we see again and again in human behavior, where certain habits create chain reactions that help other good habits take hold. That’s the thing that Charles Duhigg talks about in his book, “The Power of Habit.” What he talks about there are these certain keystone habits that when we develop them, they have outsized impact on the rest of our lives.

My name is Paul Tevis, I was an engineering manager for 13+ years. I started to get interested in how we as human beings interact, because it turns out, it’s weird, humans build software. What I’ve found in my experience, is that the presence or absence of empathy determines whether or not a human ecosystem can flourish. That’s what I want to talk to you about here today. Developing the habit of empathy can make you a keystone contributor in your organization. It could make it so that you have an outsized impact on your environment around you.

When Gene was setting up the track today and talking about the importance of these human skills as we work together, he used a phrase which I get a little triggered by. We spend a lot of time building up our hard skills – our technical skills in specific domains. Then we come to discover that when we work together, we actually need to develop the harder skills of working together as human beings. That’s the way that I think about them in my experience. These skills are not soft, they’re harder.

In the rest of the talk here today, we’re going to talk a little bit about what the heck is empathy, because I’ve been really light on that so far. Then we’ll talk about it through three different lenses. How can you help come to understand yourself better, understand other people better, and when you’re working with other people, how can you help each other to understand each other better? I’m going to do this in a very practical way. I’m going to give you seven things you can try. Some things you can walk out of this rooms to do, because fundamentally, this is about practice. This isn’t about “This is a good idea.” Try these things, see how they work for you. Spoilers, they’ll probably go badly at first, but as you practice them you can develop the habits of empathy and that can really have an impact on how you show up in your personal life and at work.

There are two disclaimers before we get to that that I want to share with you. Charles Humble was talking about how one of InfoQ’s principles is that they’re information Robin Hoods. Since we’re in this ecological metaphor, my role is very much like that. I am a scavenger, I find things that are useful and I bring them back. Pretty much none of the ideas that I’m going to be talking about today originated with me, but I have found them useful in the work that I’ve done both with myself, and with a lot of people that I work with. I often describe my focus and my work as enabling technical leaders to work as effectively with people as they do with technology. I’m going to be sharing with you little bits and pieces that I found here and there that have been useful as I’ve been working with technical leaders.

Because none of these really come from me, I’m going to try to cite my sources a lot. I’m going to tell you, “Here’s where I’m getting ideas from,” so you can go track them down and do a little more research if you want. At the end, I’ll share a link with you so you can actually download a condensed version of the slides, right even today. I’m not trying to make it sound like I know all these famous people. These are just people whose work has been very influential on me. At anytime I can include a Weird Al Yankovic quote, I will.

The second disclaimer is that I’m going to talk a lot about my own experience, and that’s not because I’m a narcissist. It’s just because I’ve done a lot of personal reflection, and I don’t necessarily know where other people are coming from, so I’m going to share stories about my time as a technical contributor and working in big organizations where these things have been useful and I’ll occasionally ask for things from you, because hopefully you’ll find some of your own experience reflected in the stories that I share. Let’s dig in.

Understanding Empathy

I want to start by talking about what the heck is empathy? A great way to start is always with a different dictionary definition – not really. I want to draw your attention to a specific thing in this. What I’m going to be talking about here today, is about the idea of being aware of and understanding the feelings, thoughts, and experiences of another person. Not so much the vicarious experience of them, but really coming to understand what are other people are thinking and feeling in particular situation. This is something that social psychologists called perspective taking, being able to understand what another person’s perspective is.

This room is actually a great example of this. Look at where you are sitting in this room. Now, pick another chair in the room, another chair that’s maybe a little away from where you are. Just look at how that chair’s perspective on what’s happening right here at the front of the room might be different. We’re all experiencing the same thing outwardly, but we’re experiencing it internally in very different ways based on our perspective; where we’re sitting in the room, what our history is, where things come from. Coming to understand that your experience of a thing is not the true only experience of that is fundamentally what empathy is about. It’s about coming to understand other people’s perspectives. When I talk about empathy for the rest of this talk, you can largely just fill in “perspective taking.” There are a number of other things out there that talk about empathy in different ways, and I do occasionally, but for the purposes of this talk, I’m going to focus on other people’s perspectives.

What’s the motivation for this? Would your job be easier if you were better at building trust? Do you think being able to understand other people’s perspectives would be useful in doing that? What about influencing others? Would your job be easier if you are better able to influence other people? Taking people’s perspectives might be useful in influencing them; what matters to them? How about enabling collaboration? Is anybody here commonly called on to be a better collaborator to enable collaboration? Would your job be easier if you were better at that? Collaboration is all about perspective taking.

How about working with conflict? Has anybody here mastered conflict? Me neither. Conflict is so often about perspectives being misaligned and not understanding each other’s perspectives and talking past each other. Perspective taking makes you better at working with conflict. Research has shown that this type of perspective taking helps with creativity, with conflict, with bias and stereotype production. Recognizing that your experience is not universal turns out to be pretty key to recognizing and working with bias and stereotype production, and also building relationships and social bonds.

That’s all I really want to talk about, why this stuff matters, because I figure if you’re coming to a talk about empathy as a keystone habit, you’re largely bought into it. But I do want to keep in front of mind the fact that work happens within a container of relationships. The reason why I do this work with teams is because it allows them to do harder work. If we are not empathetic with each other, if we’re not able to build strong relationships with each other, we have to spend energy on managing all of that and energy on solving whatever technical problem we’re called upon to solve. If instead we can build a strong container of relationships in our teams, in our organizations, that becomes an asset that we can leverage to get work done. I do this work not just because it helps make us better people and helps us actually have a better time at work and live our lives more fully, but it fundamentally gets us better results. This is empathy in the service of doing the work and that’s what I’m here to talk about the rest of the time.

Understanding Yourself

Let’s talk a little bit about understanding yourself. You might think it’s a little weird to start talking about perspective taking by talking about yourself, but as it turns out, research shows that people who are more in touch with what’s going on with themselves are more able to understand what’s going on with other people. In a lot of cases, the first step to understanding others is understanding “What’s going on with me?”

There are a lot of different ways that you can do this. A lot of people talk about personality assessments. I love personality assessments, I take all of them that I can. There’s a line from the economist, George Fox, where he says, “All models are wrong, and some are useful.” For me, models are ways of looking at the world in a different way from what I might have done normally, because it gives me new information. Personality assessments can be really useful, but I’m not going to talk about those in this talk today. What I actually want to talk about is the F word – feelings.

Who here has ever been in an environment where you were discouraged from talking about feelings at work, explicitly or implicitly? “We want to focus on the problems, not on our feelings.” What I find really useful is to take on the perspective that feelings are data. This comes from the work of Dr. Marshall Rosenberg. How do we work with feelings as data? One of the ways to think about it is that feelings are like the check engine light on your car. They are signals that you should get curious about what’s going on. “Hold on, what’s happening here? I don’t know what’s going on, but we should figure it out.”

He said they’re connected to what’s going on with us in a subconscious way. Treating feelings as data looks kind of like this. It’s a four-step process. The first step is you ask, “What is it that I’m observing? What’s happening out here? What’s outside of my head that I’m noticing that might be stimulating this feeling.” Then the second step is, “What feeling am I actually experiencing?” I want to be very clear about this. We’re talking about emotional states like anger, happiness, joy. Oftentimes, when people talk about feelings, they actually mean opinions, “I feel that you are wrong.” That’s not a feeling. One of the litmus tests for that is being able to instead of, “I feel that,” or “I’m feeling that,” say, “I am angry.” That’s an emotional state you can be in. “I am afraid.” “I am you are wrong,” doesn’t work. We often insert our thoughts and opinions as feelings. In this model, what is the feeling that I’m experiencing? That’s the data part.

Rosenberg’s work is really about how our feelings are connected to these universal human needs, being either met or unmet. For example, if I’m feeling frustrated in a conversation, it might be because my need for acknowledgments isn’t being met, my need for being understood isn’t being met. If I’m happy, it might be because my need for acceptance is being met. What he says is, when you get that feeling, get curious about what’s the need, either met or unmet, that’s behind that? Because that’s the information you may not have access to in the moments. Then do something about that. If you notice, “I’m feeling frustrated because I’m not being understood. What might I do to help get that need to be met, to actually be understood?” When we treat feelings as data, we can start to think about what’s actually going on?

Who here has ever been involved in a technical discussion where emotions ran high? I’m going to ask for a few to get shouted out here, what are some feelings that show up in a code review or technical discussion?

Participant 1: Frustration.

Tevis: Yes, frustration is always number one. Whenever I do this talk that’s the one that comes out. What else?

Participant 2: Defensiveness.

Participant 3: Fear.

Participant 4: Anger.

Tevis: Those are pretty negative emotions right there. They’re cluing us into the fact that we’re not good with the situation. What are the needs, the unmet needs, that might be under some of those feelings? This is the hard work. Anybody got a guess?

Participant 5: Lack of appreciation.

Tevis: Lack of appreciation – yes, I’m not being appreciated. What else?

Participant 6: Clarity.

Tevis: Clarity. Yes, this is really unclear. I’m getting frustrated because I don’t know what’s going on. Yes, absolutely. Anything else?

Participant 7: Respect.

Tevis: Respect. Yes, not feeling appreciated for who I am. Not feeling respected, not feeling listened to. Not, “I don’t think I am being listened to.” You can see I’ve been doing this work for a few years and I still get the language a little wonky. Yes, absolutely. It’s data. What happens if you’re in a technical discussion and you notice, for example, that you have some fear? You’re concerned, you’re, “I’m worried that we’re not addressing this particular issue.” That’s data. What happens if you discover that everyone else also has that same fear?

Participant 8: Validating.

Tevis: It feels validating, and it’s useful. It’s “Maybe this is something that we actually should dig into if we’re all thinking it.” Those are the kinds of things that can start happening when we start treating feelings as data, is we can start to recognize there are reasons why we feel stuff. They’re cluing us into things and they’re a sign we should get curious and talk about what’s going on. That’s tip number one, treat feelings as data.

Understanding Others

Now, we want to talk about understanding others. We’ve got other people who are involved, not just our own feelings. Let’s talk about perspective takes as relates to other people. My second tip is this notion of if you wanted to develop the ability to take on perspectives, you want to listen at at least level two. What the heck does that mean? This comes from the work of the Coaches Training Institute, and the idea that there are levels of listening when we listen to people.

The first level is internal listening, which is where you’re listening from the perspective of self. I’m listening to you because I’m waiting for my turn to talk. Or, I’m listening to you because I want to know how this impacts me. The important thing in level one is that the locus of listening is internal. It’s on me. That’s how I’m listening. That’s very different from listening in a way that is focused on the other person, “Hold on, what’s going on? I hear what you’re saying, what’s important to you about this? Why does this matter? What are you telling me this for? What is it that you’re excited about in this?” It’s putting the focus on the other person when you’re listening to them. Me focus listening, other focus listening.

There’s this third level that they talk about that’s really important in coaching, which is global listening – listening for how is this landing in the space? What are all the things that are going on here? Listening in context. Level two is really the key for that empathetic perspective taking start, because when you do it, you develop what a lot of people call empathic presence. Have you ever had the experience of having someone listen to you at level one? Where you know all they’re doing is they’re listening for what’s in it for them? They’re doing this “me, me” thing inside their head. Anyone had that experience? Yes, absolutely. Have you ever had the experience of that different second level when someone is really listening to you for your sake? They’re listening to what matters to you? Yes. We can tell when we’re having a conversation, when our conversation partner is listening at level one, or listening at level two. It’s a skill you can practice and it’s a thing that you can learn. It massively improves your ability to understand the other person’s perspective, and also greatly enhances your relationship with them. It allows you to get stuff done a lot more effectively. The second tip, particularly when we start talking about understanding others, is to develop that deep listening skill, at least level two.

Tip number three comes from the work of Dr. Virginia Satir, she talks about the importance of noticing your judgments and noticing what you are adding in to what’s happening out there. She has a model called the Satir interaction model. I told you I love models. This is a little complicated, so I’m going to simplify it. There are four things that happen when we’re taking stuff in from outside. The first is asking the question, “What did I see or hear?” This is again going back to Rosenberg’s work. What did I just observe? What’s happening out there? She says that’s the first thing that happens. There’s a thing that happens out there, and then as we take it in, we decide what that thing means. We interpret that and ascribe meaning to it. Then we think, “How do I feel about whatever it is that that means?” Then “What am I going to do?”

This is the rough model. We observe something, we ascribe meaning to it, we attach feeling to that meaning, and then we decide how we’re going to respond to it. That second step is really important, recognizing we are ascribing meaning to those things that we observe out there. The meaning is not independent of us. We’re putting stuff in there. One way of thinking about this is asking, “What story am I telling myself about what I just saw or heard?” For example, has anybody here ever had the experience of a co-worker who was chronically late to meetings? I suspect many of you have. What’s the story you tell yourself about why they’re late?

Participant 9: They don’t own a watch.

Tevis: Sure. What’s another story that you tell yourself?

Participant 10: They don’t want to wait for others.

Participant 11: They don’t care.

Tevis: How often is that? What are some other possibilities of what’s really going on with them? There are a lot, there’s an infinite number of things and until you actually talk with them, you don’t really know. The important thing is recognizing that’s a story you are telling. If you can recognize that story, you can actually start to change the narrative. You can put a different story in place and you can actually change. You are responding, your feelings are in response to the story you are telling, not necessarily to the thing itself. Oftentimes that story gets in the way of understanding the other person’s perspective. We tell ourselves a story, we write them off, we’re done. When you notice your judgments, when you notice the story that you’re telling yourself, it enhances your ability to get at the truth of what their experience is, of what their perspective actually is.

Sometimes you have to go deeper than that, and ask WTF, where’s that from? Did you think it was going to be some other acronym? This comes from Ellen Grove, who I’ve had the pleasure to work with a number of times over the years. Sometimes we go “I know I must be telling myself a story about this, but I don’t know what it is.” It’s rooted in what psychologists call the fundamental attribution error, which is my favorite thing in psychology because it explains so much stuff. The fundamental attribution error is this: we tend to see our own actions as being reflective of our circumstances. We are controlled by what’s going on around us. We tend to see ourselves that way. We tend to see that other people’s actions are a fundamental reflection of who they are as a human being. My actions are reflective of my circumstances, your actions are reflective of your character.

For example, if I’m driving on the freeway and I cut you off, it’s because I’ve had three cups of coffee and a bran muffin. If I’m driving on the freeway and you cut me off, it’s because you are a garbage human being. That’s the fundamental attribution error. It’s because we know our own inner lives, we know what our perspective is, we know what we’re feeling, we’re thinking, we’re experiencing. We only experience other people’s behavior and we experience that filtered through our own beliefs and assumptions. This makes total sense, but it happens all the time and unconsciously, and until we can start to recognize that, we can’t do anything about it. When somebody does something and you’re, “This makes no sense at all. They must be a garbage human being,” what Ellen challenges us to do is ask “Where is that from?” If I assume that I am working with a reasonable person, and they have a good reason for acting the way they do given their circumstances, what must those circumstances be?

Then it becomes a problem for me to solve, to go “Ok, cool,” because now my brain is engaged on this and going, “I wonder where that’s from?” Here’s the thing, you could be wrong, but 9 times out of 10 – even more than that – I have found there is a good reason for why they’re doing what they’re doing. Sometimes it’s well-intentioned and unskillfully done; that’s a whole other set of things that I talked about, where our intention does not match our impact at all and there’s often a gap there. But really recognizing why are they acting this way and getting curious about that can be really powerful. Asking where they’re coming from can help you understand their perspective. That’s interacting. That’s how to come to understand other people.

Understanding Each Other

One of the interesting things about what I’ve talked about so far, is that none of this has required you to actually talk to the other person, which I imagine some of you are taking great comfort in. However, at some point, you are actually going to need to interact with other people and apply these skills. Do the inner work first, those first four steps, practice that stuff before words come out of your mouth. Eventually, you’re going to need to actually talk with other people. The last three things I want to give you are actually about when you’re talking with other people.

The first comes from Bruce Lee, and it’s a very famous story in Zen Buddhism. He got it from his master and I encountered it in a slightly different context, but I find this metaphor useful. He talks about a scholar and a Zen master and the scholar is going to visit the Zen master to learn from him. When the master hears the scholar is coming, he sets up tea for the two of them to sit down together. When they sit down to enjoy tea, the scholar begins to tell the Zen master all of the things that he knows, and that he’s excited about learning, because he has studied greatly from these various texts, and he’s dug deeply into these things. He knows that there are these sometimes irreconcilable differences and how some of the Zen stuff doesn’t make sense in these various different ways. As the scholar continues to talk and tell the master all the things that he knows, the master picks up the tea kettle, he reaches out and it begins to pour tea into the scholar’s cup. As the scholar continues to talk, the master continues to pour, and eventually the tea reaches the edge of the cup and then spills out over the edges. The scholar says, “What are you doing? Do you not know that you cannot pour tea into a cup that is already full?” The master says, “Precisely.”

This story is often told in Zen about the importance of beginner’s mind in recognizing what it is you do and don’t know, and setting aside the things you know for the purposes of learning. Where I learned it was actually in my facilitation training, where what we’ve come to recognize is that when we have an idea that we hold so closely, and we know is important, we can’t let it go until we know there’s at least one other person who understands it, who gets it. Our cup cannot hold any of anyone else’s tea so long as it is full of our own. A lot of my training as a facilitator was actually about helping people to empty their cup when we get into those difficult conversations, and being able to let them know that there’s at least one other person who understands it. Until they get to that point, they can’t hear anything that anybody else says, because their cup is full.

Knowing that your own ideas are understood by someone else helps to empty your cup. Oftentimes, you can help other people to be able to hear you by listening to them, by using what’s called reflective listening. This is the often paired skills of paraphrasing and mirroring, where all you’re doing is you’re repeating back to the other person. I think what I’m hearing you say is you’re worried about if we store secrets in this way, that’s going to open up us to these three vulnerabilities. Did I get that right? They go, “Yes, exactly.” I don’t have to agree with any of that. I don’t even necessarily have to understand it really deeply. But at least they now know someone has heard of what it is they’re saying, and those ideas are out here now. They don’t have to keep them in here. Now, I can say, “Cool. I have these other concerns. Can we talk about that?”

Helping other people empty their cups helps you understand where they’re coming from, but it also makes space for them to be able to understand where you’re coming from. The advanced move of this is actually asking someone to help you empty your cup when you realize you’re full of stuff that you can’t let go of. Say, “Just humor me for a second here. Could you tell me what you think you heard me just say?” Sometimes, and I’ve worked with people like this, they hear what you say, but they don’t acknowledge that they’ve heard it. They’re already three steps ahead and so it’s hard to feel heard in that situation. It’s hard to think that you are heard. Help people empty their cup because you’ll understand them better and they can now come to understand you.

The second thing for interacting with other people is about knowing and disclosing what’s going on with you. We talked in tip one about what’s going on with me, let’s make sure that I understand that. This is actually about putting that out there. This comes from Jim McCarthy. Has anybody ever read Jim McCarthy’s “The Dynamics of Software Development?” It’s a fantastic book; it has one of the best advices for working with people, which is don’t flip the bozo bit. He also developed a thing called the core protocols, which are ways that people can make agreements about how to interact with each other in teams. One of the core commitments, in the very beginning he says, “I commit to engaging when present, knowing and disclosing what I want, what I think, and what I feel, and using that tool to seek effective help.” I focus on that knowing and disclosing what I want, what I think, and I feel. If I’ve gotten in touch with what’s going on with me, it can be really useful for the group to know what that is, so that they can work with it, because then it becomes an asset, it just becomes another thing for the group to deal with.

I have a story about how I did this. I did not recommend doing what I did, but I will let you know what it was so you can see the power of how this can work. Last year, I had a fairly turbulent year. I had a number of what I call the series of medium-sized events; nobody died, nobody was born, drama happened, but it was a turbulent time. I was going through some difficulties in my career. I was really inspired by something that my friend Megan has done a number of times, which is this knowing and disclosing. I recognized I was feeling unskilled, like I never was really helpful to people. I recognized the story I was telling myself was that I was unable to be kind and that was sitting with me, I was really hurt. I recognized I wanted to break that story, so I posted on Facebook. This is the part I don’t necessarily recommend doing. I was getting ready to drive to San Diego, which from my house is about four hours, I was going down to work with some people down there. I just posted this thing on Facebook, this is inspired by my friend Megan who did this, “I’m feeling a little overwhelmed. I’d love some evidence to counteract the story that I’m telling myself. If we’ve ever done something awesome together or if I was ever helpful or kind, please let me know, give me some data.”

I drive down to San Diego, takes about four hours. I get to San Diego and I check and I have 117 comments. Ok, let’s take a look. The beginning of this is just some friends saying some nice things about me. Ok, that’s nice. My friends, Tim and Danielle, I officiated their wedding, they’re still married, so apparently I was helpful. That’s great. This was the first set of things that I saw and that was interesting. Then I had some people who I’ve worked with professionally, who said some really nice things. Did anybody here hear John Cutler’s talk yesterday? John and I used to work together and so it was really great to hear this from him and from these people. I was, “Ok, I really am beating myself up. This is just a story I’m telling myself”. Then my good friend, Heidi Helfand who is one of the track chairs here, she and I also worked together for a number of years, she just overwhelmed me with this “No, seriously, you’re beating yourself up. You’re being dumb.” Ok, fine. I’m good.

Then the weird stuff happened. I had people who I have not spoken with in 20 years respond to this request for help. Tell me about a time when you were kind or effective. We did something awesome together. I’m also glad to know that 20 years later, Trevor actually understands that yes, he was a jerk to me. He gets it, so that’s good. It was just amazing what happened when I knew what was going on with me and I was willing to ask for effective help about it. The story I’m telling myself here is what’s going on. It was fantastic. That’s not something that could have happened three years ago. I wasn’t far enough into this work to really understand what that looked like. It was amazing and that got me through a whole bunch of stuff. I then got a slightly concerned text from my mom saying, “What’s going on here?” I said, “It’s ok, I’m fine.” I explained a little bit about.

This was an experiment in radical transparency that I recommend everybody do. It’s amazing what can happen when we let ourselves do that, when we know what’s going on with it and we disclose it, rather than hiding it. Now it becomes something that we can work with, it becomes something that group can work on. It can help us collaborate in amazing ways.

The last thing is the only tip here that I can’t trace directly to getting from somebody else, so maybe it came from me. I’m not entirely certain, but it’s really about asking for reactions. When you put something out there and particularly if you put something out there that may be hard to hear, asking what’s going on with the other person. Really slowing down and helping them process this difficult conversation you’re having, being able to say, “I really want to talk about the blow up in the meeting yesterday. I suspect I came across a lot harder than I meant to. That was not the impact that I wanted to have. What do you think about that?” Just stop there and start the conversation with them.

There are a lot of different ways you can do this. You can say, “I know we need to talk about your performance review, and about how that hasn’t gone the way that you’ve wanted to for the last couple of years. I’m concerned about your future in this organization. How is it for you to hear that?” Start to engage them in conversation. Get them in touch with what they’re knowing and feeling at the time. Also, you have to find language that works for you. Sometimes I’ll say, “How does that land for you? I’m a little disappointed about how the employee engagement survey went. How does that land for you? What does that bring up for you?” Or my favorite when I say something that I know is probably going to be hard for the other person to hear, “I’m wondering if that was hard to hear.” Just being able to name it, acknowledge it. Sometimes they’re, “No, I get it. I know that that’s what’s going on. Thank you for bringing it up. It’s actually pretty easy for me to hear.” People can be surprised by it. Ask for reactions when you put stuff out there because now you can start to have a dialogue about your different perspectives on whatever this thing is. That’s tip number seven.

Briefly, in summary, we’ve talked about what empathy is, coming to understand yourself, others, and each other. I’ve given you seven different tips for how you can do this. The material that you can dig into to actually apply this, because this is a practice, this is a habit. This is not just a way of thinking; this is a way of being and a way of doing. These things are simple, but it does not mean they’re easy. I often define the difference as it is simple to run a marathon: start running, stop 26.2 miles later. It is not easy. You’ve got to do the hard work to be in a place where you can actually do that.

Fundamentally, I believe that empathy is a keystone habit that when you do it, it starts to make all kinds of other things easier. It can really make you a keystone contributor in your organization, where you can have an outsized impact on the people around you and on your organization. I hope that you are able to take this stuff and use it because if I just come here and talk about it and it doesn’t change how anybody shows up, then I’ve not done my job.

Questions & Answers

Participant 12: You talked about a lot of interventions here. Do you know any psychology departments in the country that have done large scale experiments on certain dimensions that actually have resulted in people being more empathetic?

Tevis: Yes. I don’t have specific ones to mind right now, but there’s a big focus in social psychology. In particular, that stuff about self-understanding allows you to become more empathetic towards other people, that first step. There’s a lot of research back into that. I just don’t have the references quite to mind right now.

Participant 12: The second question is, there’s a psychologist at Yale, Paul Bloom and he has a recent book, “Against Empathy.” Pretty much his point is that empathy evolved as a trade when people used to live in very small groups, like 150 people, and it’s using the same term where you are working with 200 people now, and then, let’s say you are CEO of Google, for example, how can you be apathetic to 50,000 people? How do you respond to that?

Tevis: I’ve read his book, “Against Empathy.” I love his setup for the book. When he was writing he said, “I’m writing a book about empathy,” and people go, “Cool,” and he says, ” I’m against it,” which usually ended most conversations. Vicariously experiencing the feelings of another, identifying with the other, and actually understanding the perspective are separate things. That’s why I want to separate that out. I believe that the perspective taking thing is something that you can do pretty effectively, even in large groups. The emotional identification with the other is actually one of the things. There’s another book out called “The Dark Side of Empathy,” which talks about precisely this, when it actually can create a large othering reaction. “I’m going to have empathy for the people I identify with, the people who look like me, the people who believe like me, the people who are part of my tribe, and I’m going to other everybody else, and I’m not going to have empathy for them.”

That’s actually what Paul Bloom talks about. He’s really talking about our natural tendency to do that. He actually talks about rational compassion in his book, and that’s really what the perspective taking piece about, is coming to understand, “Look, I don’t have to feel the way that you do about this, to understand you’re essentially a human being, and then I need to behave in ways that are consistent with that.” It can be really hard, because our experience is limited. I can’t have the experience that everyone the people in this room have had. I have to always be questioning myself about that. I think there are real challenges to it. I’m really happy to see work out there that’s really saying we can’t just trust our feelings about this. Feelings are data and we have to use them in a rational way as well. Just because we have a tendency to fall in that tribalism, it doesn’t mean that we need to throw the baby out with the bathwater and ignore that essential humanity about ourselves. Feelings do matter. We don’t just live in our heads. I’m glad someone brought that up because otherwise I’d be, “Why did I read this book?” Thank you.

Participant 13: Do you find it useful when you coach about the differences between feelings and emotions? The second question is, do you have any pointers or good resources on how to express empathy in international teams?

Tevis: Do I distinguish between feelings and emotions? Not really. Ultimately, we’re talking about emotional states, which are things that exist in the brain, which is interesting stuff. That is why I differentiate between, “I feel that you are wrong,” and “I am angry.” Those are different classes of things and you need to tease those apart. In terms of the way that you express empathy – and that’s really where that the practice of it starts to be useful – you’re going to do it wrong the first several times, the many times that you do it. Particularly across cultural barriers, there is probably going to be a gap between your intention and your impact, and so largely, it’s about learning how you screw up in different ways and how to learn from that. That’s why the ask for reactions part is really useful. I would not start as being radically transparent with a person who I just met, but even a person who I have worked with for a while, but who I know that I have some differences from, as I have with someone who I have worked with for a long time and I know we share a lot of things.

Even when I’ve been working with someone for a long time, I will still ask, “How was that for you to hear? What landed about that for you? What was the impact on you?” That inspect and adapt part of what you know and disclose, and then the asking for it back and forth, that’s where the real practice of empathy is; it’s where that dance is. You need to have a cross cultural awareness. You need to recognize what might be different here, and that will inform what you choose to do and not do. But there isn’t specifically “This is how you be empathetic” in a cross cultural environment. Participant 14: I think maybe just one tidbit is having worked with some remote teams, go there. At least understand their context to the extent that you can. You cannot understand their culture completely, but at least you can see how they live, you can see how they commute to work, which will help you empathize with them in a slightly different way.

Tevis: I’ll throw out the other thing I’ve liked: ask for it ahead of time. I’ve worked in a number of cross-cultural teams, and just be like, “Cool. We’re going to have some sharing. There’s this holiday coming up. What is it? We don’t know what this is.”

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Recently, Amazon introduced a new option to its cloud storage service S3 – Same Region Replication (SRR). With this new option in S3, customers can now create a replica of their uploaded data in the same region yet in a different S3 bucket.

By Steef-Jan Wiggers

Article originally posted on InfoQ. Visit InfoQ

In a recent blog post, Microsoft announced a new preview service, called Azure Private Link, which provides organizations the ability to connect to Azure Platform as a Service (PaaS) offerings, or their own services, using a private IP address. Azure Private Link connections travel over Microsoft’s backbone network and avoids exposure from the public internet.

By Kent Weare

Article originally posted on InfoQ. Visit InfoQ

Article originally posted on InfoQ. Visit InfoQ