I am currently reading the book “Fierce Conversations” by Susan Scott. I am on hiatus from teaching my leadership course this year, so I am taking the opportunity to refresh my content and my perspectives. The basis of the book is fairly simple:
Our work, our relationships, and our lives succeed or fail one conversation at a time. While no single conversation is guaranteed to transform a company, a relationship, or a life, any single conversation can.
Susan Scott, Fierce Conversations: Achieving Success at Work and in Life One Conversation at a Time
This has gotten me thinking in general about conversations that have impacted me throughout my career, whether with colleagues, direct reports, supervisors, customers, or mentors.
Recently, I had an interaction on Twitter that got me thinking about a long-ago conversation in a different context that, although I had never thought much about it, had an effect on how I view the role of technology in solving problems. That Twitter interaction is here:
My contribution to that thread was referring to the fact that Fulcrum had been used to track shelter availability in Houston in the aftermath of Hurricane Harvey. A third-party support contractor was using Koop to route the GeoJSON data feed from Fulcrum into situational awareness environments being used by response organizations. As the event unfolded, there was genuine, productive interaction between our staff, the contractor, Esri staff, and our mutual users. The event and the problem set were center-stage and the usual preferences or parochialisms of the various participants were set to the side in order to get the job done.
Thinking about this event got me thinking about an earlier situation, coincidentally enough, working in a previous role as an Esri business partner. I had gotten a lead on some potential work from an account manager in their defense team. The project was with a Navy user whom I knew well. He had moved to a different department and I had lost track of his work. He was working a project to build a new heads-up touch-screen display for use inside a vehicle and needed some help integrating map visualization.
The account manager had been talking to them about using Esri technology, with which the user was familiar. Once all the connections were made, we got the project pretty quickly through an existing contract vehicle. Once I got on the project, it didn’t take me long to recognize an issue – Esri’s tools at the time couldn’t meet the user’s requirements.
This was in the early beta stages of Microsoft’s Windows Presentation Foundation (WPF) and the user had selected it as the basis of the display. Having worked with him before, he was proficient in such things so I had little concern he had committed to an early beta, but nothing Esri had on the market was compatible. I found a solution using other tools, but this put me in a quandary with my friend, the Esri account manager.
I had accepted the project that he had recommended me for and everyone understands the unspoken part of such arrangements. If a company gives you a lead on business, it’s expected you use their tools to do the work. If a company invites you to exhibit at their conference, you display their tools in your booth. If you’re not willing to do those things, then you pass on the lead or the invitation. This is what we call “etiquette.”
So I called the account manager and told him what I had found. The conversation was easier than I expected. He had a defense background and said “mission first.” After confirming that anything Esri may have had related to WPF only existed on a whiteboard, he gave me his blessing – with one condition. He asked that I write up in detail how their tools did not meet requirements, so that he could forward the information on. I did that gladly. It was the least I could do, given he had thrown me the lead.
Incidentally, the solution I came up with used SharpMap, which also didn’t support WPF at the time. Because it was open-source, I was able to decouple its rendering and display layers and build a WPF-native equivalent that integrated with our display. If I had not had access to the source code, I would not have been able to meet our requirements on time. I was just beginning my pivot toward open source and this experience solidified my thinking. Also, Esri did eventually release a WPF product with which I was quite productive for future customers.
I have tried to carry the “mission first” ethos forward. My current company makes a product that directly competes with some of Esri’s offerings. I’m convinced our product is superior and I want customers to choose it every time over theirs or any others. Every morning, I wake up with the goal of helping to make sure our product isn’t merely superior, but obviously and almost unfairly so.
But it’s always important to remember that people outside the tech industry are using tech of various stripes to solve real problems that are meaningful to them. Most of them don’t rise to the level of seeking shelter during the aftermath of a hurricane, but sometimes they do. In those situations, the time for debating the merits of one technology or another is not in the middle of such an event. Then, it is incumbent upon everyone to put mission first and make everything work together as smoothly as possible.
Openness helps make this a lot easier, for both users and tech providers. Open data formats and open standards, de facto and de jure, natively supported, prove time and again to be key in emergent situations. Because our tool supported GeoJSON, a third-party support contractor could use a tool like Koop to route live data being collected by our users into a display environment that, for some reason in 2017, needed help understanding a feed in standard format that was nine years old at the time.
But the openness that matters most, just like the problems that matter most, is openness between people. If the tools you use don’t support the functions you need, you need to communicate, agitate, or, in the case of open-source, participate to get the solutions you need. Even if that means approaching a respected colleague and saying “Thanks for the work, but I can’t use your stuff.”
