Persistent Problems require Persistent Practice

A video is available on Vimeo

Greetings IA friends and mentors. I am speaking to you today from sunny Melbourne Florida. 

I have to start by acknowledging the elephant in the virtual room – this is not how any of us expected this event to go, heck it’s not the way any of us expected this year to go. We are living through what will likely be referred to as the one of the darkest times in our collective history. 

People are dying all around us, and there is nothing most of us can do about it except follow directions, stay home and wash our hands. 

Add to that, many if not most of us have had to change how our lives are fundamentally arranged. We have had to make incredible sacrifices to make sense of what we are experiencing both collectively and individually.

I can say that for me, these weeks have felt like months and somehow the days have felt like seconds. I can’t place myself in relationship to time as easily right now and that is an anxious place to be. And yet… I am here today to talk to you about information architecture. In spite of the current situation. 

To be honest, in every version I imagined of this day, it never occured to me that my today would need to be transcluded into your today. Another awe inspiring moment in the progress of technology. 

Six months ago I started to think about the subject of this talk and I landed on a topic that has been interesting to reflect on in light of the happenings in the world today. 

The topic I chose was…Persistence. 

When I look at what this community and specifically the team that runs this event has had to persist through, it leaves me breathless. Before I get too far, I want to take a pause to sit with the complexities that this team has worked through to get us to this day. 

To be honest after some consideration I can think of no better time to talk about the concept of persistence in a time such as the one we are currently facing. 

So my talk today starts from the recognition of the persistence of this community, the information architecture community that gathers at this event once a year to compare notes on the ways in which the world is reacting to and interacting with this thing we all hold space for in our professional identities. 

We have seen the need to persist in spite of many trends and forces over the 2 decades that this event has been taking place – and what we have waded through has been messy and not at all simple to make sense of. Many of the people in this virtual room not bound by time will recognize the story I am about to tell. Some of you will be hearing this for the very first time. 

This community has had to persist through some pretty big periods of pushback. Times where our day-to-day jobs stayed exactly the same while the words to describe those jobs started to become more and more slippery. The boundaries around things were harder and harder to hang on to. 

I remember a time, not all that long ago where it felt like everyone around me was encouraging me to give up on IA. To give up on the term, while continuing to do the work. 

First I was told that IA was not needed because Web 2.0 and asynchronous javascript calls were eliminating the need for navigation entirely. This perspective pre supposed that IA is navigation, which is its own whole thing. In this period of pushback – Rich Internet applications would make such a great user experience possible that IA simply wasn’t as needed because the experience wouldn’t have to be parcelled out into pieces at all – everything would be instant. 

The next period of pushback was when we were told that we didn’t need IA because modern search engines were getting so attuned to human needs that machines would do a much better job at my job than me. Everything would be findable. 

Next it was mobile. IA wouldn’t be needed because screens were getting smaller, so teams would just be forced to have less stuff to organize. Everything would be tiny. 

And then when teams didn’t get the memo to have less stuff to organize, Everything would be tiny hamburgers.

Then it was social media that would eliminate the need for IA. No one would need IA since businesses were just operating within the confines of a platform’s IA decisions. Everything would be social. 

Next up was apps. Everyone needed an app, but apps are all the same. No IA would be needed because all we needed to do was copy the other apps and adjust the structure for whatever we were designing. The shazam of car insurance, the google maps of shoe shopping, the angry birds of retirement investment planning. Please raise your hand if you were ever in a meeting where any of those ideas were actually considered circa 2012, even if just in jest. If you worked in agency land you might have had the pleasure to attend meetings involving all three. Everything would be a walled garden that mirrored other people’s walled gardens.

And most recently, it was agile and all things silicon valley startup culture. We didn’t need IA since all we wanted to do was move fast and break things. We needed to move too fast to think about things like language and structure. We needed to make things fast to get feedback fast, so surely the right IA would just be iterated into existence. Everything would be autonomous, and broken – BUT it would be first to market.

If you are attending to the IA Conference in 2020, chances are that you entered the working world in enough time to experience one or more of these periods of push back. The last few years have been hard for those of us who have positioned ourselves as information architecture specialists. 

• We have watched the IA job title fade almost entirely.
• We have watched an entire generation of UX designers doing IA work many of whom are doing so without knowing anything about IA’s history, or even knowing the term information architecture. And these UX designers have worked with a whole generation of product managers, engineers and researchers who also have not been exposed to the theories, practice and language of information architecture.
• We have watched companies stop seeing a need to request IA services from external consultancies and agencies
• And if you really want to have a bummer of a day look up Information Architecture on Google Trends

To be honest friends, it’s been hard to be a part of. There have been times where I felt like my own self esteem has become far too tied to the success of my field of practice. And I am sure I am not the only one who.

In reality…

• Everything I know about IA tells me it is A) a thing and B) important
• Every project I have ever touched with my IA skillset has been better for it
• Every deep conversation I have ever had about IA has given me more fodder for a seemingly endless appetite for figuring out the world and making it a clearer place.

And yet…

I wake up every day and worry that what I do for a living, what I use to support my family, what I spend my free time reading, writing and speaking about is not a thing at all. Or even worse, that it is a thing that is not important or of value to other people. 

This makes me feel isolated on the best of days and completely crazy on the worst. 

Is it still called gaslighting if you are the one holding the match?

I don’t think this is my story alone. I think there are a lot of you out there who have these same feelings. Many of you have moved on in terms of job title, admitting amongst your IA tribe once a year that yes you still do IA work but that your company just prefers that you call it UX Architecture, Navigation Design or UX Strategy. 

And to be crystal clear –  I have absolutely no problem with that. In fact – I applaud you for rolling with the punches and doing this hard IA work in the face of the push back from our end users. 

That said, it sometimes makes me laugh to make comparisons to other professions. Would they ever ask a lawyer to just not call it that, perhaps they could be better labeled as an Argument Maker. Perhaps we would see more value in a Librarian if they were called a Book Finder. And I know I would appreciate the expertise of my acupuncturist a bit more if he allowed me to call him my Needle Sticker.

My point with these absurd examples is to show you that in few other cases are other people telling a whole industry of people who are experts in a field of practice to call themselves something different.

But this isn’t happening to lawyers, librarians and acupuncturists. This is happening to us, the ones who pride ourselves on helping people to make sense of things. This is not an ironic observation, this is a proof point about what we are good at: we always want to be clear, and the term IA doesn’t feel like it is able to be immediately clear to people so of course we are ok with iterating on our label until our services are more findable and the work can progress.

Information architects are persistent in our practice, even if it ultimately ends our ability to identify our practice with one another. It has only recently occurred to me that the people who lose the most in the current arrangement of “do IA but call it something different” is the community. Without the shared label we have no calling card with which to identify each other and we have no curriculum with which to bring up the babies.

So is it too late? Is it all doom and gloom? Is IA a thing of the past that we will look back on fondly as a thing that faded along with the web trends of the early aughts? 

Will I be walking off this virtual stage and finally changing my twitter handle to Abby the Box and Arrow maker?

Well — not so fast. Here is where the story gets interesting. 

What happens when the world that these circumstances built turns into a full stack of persistent structural deficiencies? 

What happens when suddenly organizations are feeling that pain with no name that might feel familiar but only to those who survived the dot com bust of the late nineties?

What do organizations need when suddenly everything is expected to be instant, findable, tiny and social but all you have are walled gardens that have been built autonomously?

What happens when the world is facing an unprecedented pressure to change the way it operates and the world turns to these organizations who have in the past been built with the mindset to move fast and break things? Do we finally need to slow down and fix things? 

The answer is that the thing they need is the thing that they have been pushing away for the last 20 years. They need structure, they need governance, they need clarity and they need sense makers to bring those things to the messes that are growing more complex every day.

As my friend Jorge Arrango recently said: 

“We were made for this moment.“ – Jorge Arrango

Information architects are built for this level of VUCA! Volatility, uncertainty, complexity and ambiguity are our base materials from which we can bring to life clarity, intention and meaning. 

I spent the first ten years of my career working mostly agency-side, and after a decade of dive bombing into organizations to make sense of their information messes, I landed at Etsy in a beautiful mess that I knew would take longer than a single mission to make sense of.

I have learned in the last 4 years how extruded time is when working in house. I have seen minor problems turn into major missteps. I have watched experiments not do what we expected, sending whole departments into a tailspin. I have watched as minor data decisions were extrapolated across millions of instances. I have watched the impact that people churn has on organizations and their information challenges. Most of all I have learned how important persistence is in practicing information architecture in these environments. 

I want to talk to you today about what I have learned about persistence. What I have learned about persistent problems and what makes them so damn hard to make sense of… and what I have learned about persistence in my practice. 

On Persistent Problems

There has been a lot of talk in this community about wicked problems. While I find those conversations endlessly fascinating and inspiring about how IA could impact the world in such large ways, I struggle with taking those lessons to the board room. How can I make my company care about these wicked problems? How can I position myself to support my family while thinking about such wicked problems?

While wicked problems are the white whale of the information architect’s world, persistent problems are more like the carp. There is a seemingly endless supply, every organization is stocked and there is plenty to go around so everyone can be fed.

So what is a persistent problem?

• It’s well tread territory. A problem that everyone sees, but no one changes because it is how we have always done it.
• It’s messy to think about. A problem that holds an organization back, but no one changes because it would be too hard.
• No one owns it. When no one owns it, no one changes it. 

How do persistent problems become persistent?

I have identified at least five factors that contribute towards the persistence of a problem.

1. Time
2. Attrition
3. Autonomy
4. Boundaries
5. Mind Monsters

Persistent Problems are created over time, and take time to fix.

Time is a material I have had alot of interest in exploring over the last several years. One of the main reasons that I decided to close my personal practice to join Etsy was that I had a hypothesis that I wasn’t practicing what I was preaching in terms of collaboration in information architecture since the longest client engagement I had ever been on was less than a year. 

So let’s talk about time for a minute (see what I did there?). 

There is a little secret I have learned during my career that I want to share with you today: 

Mess + Time = Messier

It’s true, every day that you ignore a mess instead of starting to make sense of it, it grows. This is an overwhelming reality for many organizations whose messes have been ignored and fed on that lack of attention for years or even decades. So what happens when an organization has an ever growing mess? When is the right time to start to make sense? Well that begs another litany of questions: 

How much attention will the making sense part take away from business as usual?   

Who will have to stop working on something else to focus on this?

How much will this cost to make sense of? Is that less than what it is costing us? 

Is this problem even measurable by measures we have in place today. 

There is another important point here, which is that most organizations are not set up to tackle problems that break the timescale of the organization. We all have felt parkinson’s law in action when amazingly our work expands to fill the time allotted. And in my experience, this fits into the conversation about persistent problems too because in my experience the time scale of the organization, not the scope of the project, dictates what can (and can’t) be done.

So what happens when the timescale of your organization is at odds with the time needed to make sense of a persistent problem? It never gets done. Like trying to fit a square peg into a round hole, we can have the best dang pitch, we can put together the best dang team and present the best dang project plan and still we won’t get the support to fix what we need to. 

In these cases, we don’t always get a no. In the best cases, we are green lit to tackle a small part of the problem or pilot a potential solution. In the worst cases, we are asked to move faster and in trying to solve the problem quickly, we make it grosser.

Move fast, break things – while making me queasy – is at least a brutally honest retort. Because if you move fast, you will break things.  And if you are only ever moving fast, you will probably never fix things. 

I often wonder what the tech world would be like if we thought more like “Move Slow, Fix Things”. What would it be like if we were actually given the resources and the runway to fix the persistent problems. To move slowly and deliberately and most importantly, to collectively admit that we are not going to get there soon, but at least we might have a chance to get there.  

Simply put: Persistent problems are created over time. They don’t appear one day out of nowhere. They are the result of lots of tiny decisions that are made over time. So to think that they will be solved without being given adequate time is a fool’s errand, one that many of us have attempted at some point in our careers.

People leave. Messes stay. 

How many of you have been in your current role for more than 1 year? How about 3 years? 5? 10? 15? 

The truth is that people leave organizations all the time. The average turnover in the design and tech world is only around 18 months. That means that in the typical organization, there are just not many people who will stick around long enough to work through a persistent problem. 

To make matters worse, when people don’t stick around, they have no incentive to fix the things that are broken. Instead they have every incentive to work on whatever they can get done in the time that they have, and ultimately the work that will get them their next job. 

I was recently talking with someone who has been taking on a large persistent problem for the last year. When they got about 3 months their product manager confided in them that their peers had started poking fun at them for taking on such a lofty, messy, under the surface project. In their world, taking on something that is clear and able to be time bound is the surest way to their next role. This person was really struggling with going against that grain, and as the project continued, many of the member on her team started to feel the same way. That othering moment of feeling of being different than the rest of the organization. 

One of the most important tools you need when tackling a persistent problem is shared understanding. It is incredibly hard to foster shared understanding, especially of something complex, when people are coming in and out all the time. It also becomes a reality that the people who know the most about the problem space are like ticking time bombs waiting to resign and immediately purge all their nuanced understanding in their brain.

When I was consulting I often had to explain to clients that they are merely renting space in my brain and that I wouldn’t be offering any long term storage options. It always amazed me how fast the details would float away after the engagement is over. And employees are the same, once they are gone they take alot with them, but they also leave the messes they helped to make behind. 

Persistent problems are aided in their persistence by attrition and turnover. If the average tech employee only stays around for 18 months and average persistent problem takes more than 18 months to work through, you can do the math.

It wouldn’t be an IA talk if we didn’t talk about silos

Let’s talk about accountability for a second. There is a concept called the tragedy of the commons that I find incredibly applicable to many organizations.

Tragedy of the Commons: A situation in a shared-resource system where individual users, acting independently according to their own self-interest, behave contrary to the common good of all users by depleting or spoiling the shared resource through their collective action.

Let’s rewrite this for organizations: A situation in an organization where individual groups, acting independently according to their own incentive structures behave contrary to the common good of the organization by depleting or spoiling the organization through their collective action.

In other words, persistent problems are a kind of death by a thousand cuts. No one sets out to make a decision that will deplete or spoil the organization, and yet…. 

In fact the key part of the definition are:

• They are acting individually
• They are acting based on how they are incentivized
• The depletion or spoiling happens through COLLECTIVE action

It is when all the actions pile onto each other that the persistent problems arise. So we have to remember in dealing with persistent problems that autonomy can be like kryptonite. We are drawn to its powers, yet we are depleted collectively by that power. 

Persistent problems grow in environments where everyone is doing their own thing, based on their own self interests and no one owns the collective action. 

And while we are on the topic of silos, let’s not forget how boundaries play into persistent problems. Toes get stepped on. Turfs are warred over. Bucks are often passed.

When it comes to persistent problems, there is an organizational phenomenon wherein no one cares about something until you want to change it, then they care ALOT about it. Change can be very threatening. And in the case of persistent problems, they exist because of (or despite) everyone’s efforts. Someone put that thing there. Someone decided those eleven-ty-billion tiny decisions that got us here. So don’t be surprised when you start to identify a persistent problem that defensiveness rears its ugly head. Defensiveness is a human condition. It is a protective mechanism that we use when we feel threatened. It is rabid in most organizations and its caustic in its impact on an organization’s ability to tackle persistent problems. 

Do you know when you are being defensive? Can you feel it? Does it have a somatic element? I know it does for me, and the identification of it is an in the moment gift when trying to make sense of persistent problems. Now that I have been at the same company for several years, that defensiveness is something I am having to pay specific attention to in myself, for now there are new people edging in on the boundaries of what I myself have created in past lives (and incentivations).

An organization is sort of like land, every piece has a lineage, a history and often an owner. But persistent problems don’t abide by turf boundaries as much as we would wish them to. This is made even worse when the lines blur or are erased and redrawn altogether (maybe several times) over time. I know I am not alone in being part of an organization that sees at least one major reorg effort every year. Everything in an organization’s past happened because, reasons. Sometimes it is our job to figure out those reasons and confront them from the light of a new circumstance.

But when it comes to organizational apologetics – the blame game is one of people’s favorite past times when it comes to avoiding making sense of persistent problems. 

“Well if so and so would have listened back then…”

“We could have tackled this sooner if it wasn’t for that thing that other group did…”

“We can’t fix that until that team gets their ducks in a row”

“Well if HR could fill all our reqs, we might be able to actually start working on this…”

Have you ever had a time when your house or office got out of control messy and for days or maybe weeks you avoided tackling it because it was just SO MESSY, but then you finally tackle it only to find it really only took you 20 minutes. 

Or how about a conversation you have been avoiding? Have you ever built up a moment in your head so long that it prolonged you actually dealing with it. 

We have all been there.

The same is true of persistent problems in organizations. It can feel so scary in our heads. It can feel impossible, overwhelming, and oh so scary to even start to unravel. But here’s the truth – monsters are always scarier in our heads. Once we start to get them out of our heads and start to share the view of them with other people, they become less scary. These mind-monsters feed on our isolation. They lurk in the darkest corners of our mind, jumping out at us at the absolute worst times. 

So how can we be persist against problems that defy timescales and feed on attrition and autonomy? How do we even start to think about going after these monsters in our minds?

I want to start with a skill that I don’t think gets talked about enough in the work that we do. That skill is bravery. Now stay with me here, I anticipate that some of you might be feeling like this talk is starting to take a sharp turn towards the woo woo, but hear me out. 

In my experience, those who are practicing information architecture are the ones who are walking into messy situations that are fraught with historical context, a variety of personalities and various levels of ambiguity, complexity and unrest. 

This is scary. Let’s just all sit with that admittance for a few seconds. This is scary. The work that we do can be scary and to tackle that work we need to be brave. 

You have to be brave to point out a problem no one else seems to see clearly.

You have to be brave to start to sort out something that the people around you might assume is “un-sort-out-able.”

You have to be brave to ask hard questions.

You have to be brave to push back when you see a train wreck approaching.

You have to be brave to make sense of persistent problems.

One of the first steps of bravery you can take when facing a persistent problem is to draw a picture of the monster your team has lurking around in their heads. This is brave because once we put pencil to paper, we have already decided to try to make sense. Bravery is what gets us ready to make sense. 

It continues to amaze me how even the most basic scribble can move a team from “terrified of starting” to “we got this.” Have you ever been in one of these moments? The discussion is getting harder and harder, people are starting to push away from the table, sigh loudly, maybe someone has started pacing or rubbing their eyes while leaning back in their chair. At that moment, everyone is scared. Scared that it is their job to talk about and do this hard thing they don’t yet understand. Scared that the thing they need to sort might not be able to be sorted. Scared at the thought of a future where this problem isn’t solved BUT is confirmed to not be solvable. 

In a moment like this, the bravest thing someone can do is grab a marker, walk up to the whiteboard and start to break down things so they can be pointed at, discussed and considered in the light of day. 

Who here likes being right? I know for me the feeling of being right is like a warm cup of cocoa with marshmallows. It’s sweet, it warms me up inside and I enjoy every drop. You know what totally gets in the way of being a team player? An overwhelming need to be right. 

“But I’m the expert, they pay me to be right” you might be thinking. Early in my career this was a feeling I had ALL. THE. TIME. But it’s interesting because the more experience I got in IA the less I felt like an expert. Coincidence… I don’t think so. 

I think that sometimes we hide behind our expertise when really what we have is an overwhelming need to be right. If you really break that down, it is a symptom of a much nastier disease. It is a reflection of our professional self esteem.

So what do you do if you are the outlier on a decision being made by your team. Let’s say that I am working on a new taxonomy and the team wants to call one of the top level buckets something dumb. Let’s say that they want to call it “more.” In this case, I use my three times at bat rule. I will try three different tactics to try to convince the team not to do this. The first time up at bat I might suggest we do a treejack A/B test to see how well “more” performs compared with my alt label. Let’s say that all 7 of our test participants struggle with the label “more” and that my alt label performs MUCH better. But guess what, the team still wants to go with more – because reasons. 

My second time at bat I might dig up some articles and whitepapers about the value of clear navigation labeling and discuss my concerns with the team through the lens of what other people in the industry are saying. Let’s say that in this meeting my team makes it clear that our product is unique and therefore any comparison is not worth making. 

My third and final time at bat, I will escalate, synthesize, reflect and let go. I will say very clearly in both writing and in a meeting: I have provided you with both industry and user feedback that supports “more” being the less clear label for this. Next I will tell them what I see as the ramifications of this decision and then I will say “Are we sure that given this information we want to proceed?” – and if they say Yup! I will fall back and be a team player. I won’t sulk. I won’t shit talk and most importantly I won’t do the told ya so dance when the fire drill to change the label comes down from on high. Because the only thing worse than a person who has an overwhelming need to be right is the person who does the told ya so dance. 

Now let’s return to the question of expertise. Isn’t it my job to keep them from making this decision wrongly? For a long time I saw a clear yes to this question but after 15 years of doing this kind of work I am starting to think differently. 

After years of trying to be right all the time, I realized it makes me hard to work with. It means teams will be less willing to collaborate with me. It also means that I will be training my team that they don’t need to care about the IA because I will always do that for them. In reality, I want them to care. I need them to care so that we can get to the right solution. By positioning myself as a person who will provide a reasonable approach to proving my case while also making it clear that I am willing to set aside being right, I am telling my team that they can trust me. 

They can trust me to work through hard things alongside them, not just point out the flaws of their approach in an effort to make my approach rise above theirs.  

So the next time you are in a disagreement about how to proceed, ask yourself how many times you have gone up to bat. Ask yourself if you have tried different approaches each time or if you are just a broken record in your teams’ ears. Because you need their trust as much as you need if not more than you need their agreement.

This brings us to partnership. My best advice is to be sneaky, find advocates in unusual places

One of the hardest things about persistent problems is finding the right partners to build the case. In many cases, I have found that the most obvious owners for one of these persistent problems is not actually the best partner to start to make sense with. In many cases the most obvious owner is actually the main purveyor of this persistent problem. And if not the main purveyor, the one who is most actively ignoring or working around the problem day in and day out. 

In these cases finding other partners, maybe non obvious or even unusual partners is a powerful tactic you can explore. 

Some of you might remember when Jenny Benevento and I talked at IA Summit in Chicago about how we approached the refresh of the global category navigation at Etsy. We hadn’t improved our category navigation for 3+ years, but we had added and added and added links to the point where those poor mega menus were so heavy that users felt overwhelmed and started comparing us to un-cool brands like JCPenney. Now the obvious owners for such a problem would be product, right? But time and time again the funding for improving the navigation was thwarted. It was the thing that everyone knew needed to get done eventually but it just seemed really big and hard to attach to financial ROI so product just kept not doing it for years.

But then one day, I got a meeting invite from an SEO consultant who wanted to talk to me about reducing the navigation by 50% because other eTailers had seen major SEO returns from having done so. Suddenly there was daylight on this persistent problem. And while the ask was different, the task at hand was the same. So we took the project, and used an unlikely partner to see the project under a different marquee. 

Persistent problems sometimes need us to break the traditions of how things get done – hence the overwhelming need for bravery. 

The most important and overlooked tool in our toolbelt that is needed when dealing with persistent problems is kindness – which is in my humble opinion the basis for all cooperation. We cannot cooperate without first being kind. We must build trusting relationships with those around us to make the world go around. Wr must foster relationships that are based on shared respect for each other’s practice. We must stop the blame game, the shit talking, the finger pointing and turn inward. We must look at others through the lens of assuming best intentions. 

And lastly and most importantly: We must be kind to ourselves. Pandemic or no, you are each facing a unique combination of trends and forces that are causing a lifetime worth of joy, pain  and anger. Be kind to yourself as you pursue your work making sense of messes for yourself or for others. Remember that the journey you are on isn’t predictable. 

When I was gathering the bravery to deliver this talk in these new circumstances, my friend Jorge Arrango reminded me about the importance of resilience when it comes to persistent work.  Like someone floating over the edge of the waterfall – if you relax your way through it you’ll be fine. And you know what Jorge – today, I am fine. 

I hope my thoughts on persistent problems have been useful to you in whatever messes you might be facing at this incredibly strange time to be doing anything at all. I hope that I gave you some new frames to look at some of our collective challenges through. And I hope I left you with the feeling like persistent problems can be persisted through, they just take bravery, trust, partnership and kindness to make sense of. 

So sure, Mess + Time = Messier, is a scary reality.

But I am starting to believe that Mess + Bravery, Trust, Partnership & Kindness multiplied by the gift of time equals a clearer future. This isn’t a simple equation – it’s taken me some time, bravery, trust, partnership and kindness to realize the true nature of these persistent problems. 

I think that we too often use lack of time as our reason not to make sense of a persistent problem, yet it is more than time that we need. The time given to us to work on persistent problems often feels out of our control, but if we look to the rest in this equation we are in more control than we admit. Time may be a material we are granted by others when it comes to our work, but the rest of these variables are earned. And when you earn those things, time is more often granted. It’s a virtuous cycle that creates the optimal conditions for making sense of persistent problems.

It has been an honor to speak to you today, even in this weird medium. This community has been like a family to me over the last decade and the idea that you all see my words as wise is one of the things I am most proud of in my life. We are a resilient group of people working on a really important problem. 

Let’s continue to be persistent towards our goal to make the world a clearer place.