EuroIA 2020: Charting a Course Through Murky Work
In this talk for EuroIA 2020, I shared 5 lessons learned as an information architect at Microsoft to better facilitate murky projects with higher stakeholder confidence, less churn, better meetings, noticeable progress, and happy teams. As information architects, we are often involved in sprawling, ambiguous projects that pull together a wide panel of stakeholders and cross many organizational boundaries. Projects like this often get messy and stall due to disagreement between parties. Consider this: how many of us have ever grimaced at the politics involved in managing a navigation project?
When we “do IA” we are asking our colleagues to engage with us on abstract concepts, working across siloed teams, with limited time, on some murky problem. We’re taking on our colleagues’ assumptions, hopes, and beliefs, and translating those into things like website navigation, content models, and taxonomies. This isn’t about politics – this is about discomfort, uncertainty, and fear.
The IA’s role in creating clarity goes far beyond producing deliverables – we must also attend to the emotions of those we are shepherding through the abstract world of IA. We can guide our colleagues through the uncertainty and into a lighter, brighter, more confident collaboration space.
Slides
Transcript
A lot of the work we do as information architects is complicated and opaque to others. This is to be expected, after all, we mostly take complicated and opaque things and make them less complicated and less opaque. Naturally, we end up in very murky and ambiguous situations. We do “Murky Work”.
What is murky work? Murky work has three identifying characteristics:
The focus of the work itself is specialized. Think "designing taxonomies" or "content modeling" or "navigation design". It requires some domain expertise (that you have).
The project requires you to collaborate with many others who do not have your expertise in order to implement it. It requires broad collaboration across domains.
The work takes a while. Long enough for people to forget what we are doing, or why, and to wonder why it is not done yet. Long enough for people to completely lose the narrative between meetings and forget the decisions that have been made.
This is an intentionally broad definition. As an IA at Microsoft, most of my work is murky work. We do things like: put structure around blobby things, through content models. Make large piles (very large piles) of content findable and navigable with metadata and taxonomies. We also do things that seem pretty straightforward, relative to everything, like updating header navigation on a single website.
A few months after I joined Microsoft I had the opportunity to help one team re-think the navigation on their particular website. Now, among all the things I was tackling in my new role, website navigation was quite possibly the most concrete, straightforward, non-opaque thing I had been confronted with. If there was one thing I was super prepared for, it was a navigation project. Thanks to Stuart Maxwell at REI, I knew to expect some politics and some churn, but technically speaking, I was confident I had the chops to knock this one out of the park.
You know what they say about pride and hubris, right?
I think you can see where this is headed. Let’s break down the project against our definition of murky work:
Navigation benefits from the expertise of an IA. (check: requires some amount of expertise)
A group of roughly 30 stakeholders overseeing the project at various altitudes, across 2 different organizations (with 2 different reporting structures), and a team of IA, design, marketing, SEO, experimentation, and engineering to get this thing from strategy, through design, to implementation (checkbox: requires collab with non-SMEs)
A timeline of over 1 year (that’s 260 business days during which we can have meetings about this thing!) (checkbox: more than a few weeks of work)
There are so many things that can go wrong during murky work: Stakeholders and project teammates get confused, or angry because they feel confused. Goalposts move. Decisions get made, then un-made, then remade...projects get paused, cancelled, because nothing gets done. The complicated stuff stays un-usable, complicated, and we have not improved the world in any way, even after all that effort.
But! It doesn’t have to be this way. I’ve learned a few major lessons in navigating murky work, and I want to share them with you today.
--------
When I joined Microsoft, there was a lot of stuff I did not know about Microsoft, or developer documentation, or the intricacies of our platform. My second week there, my friend and teammate Sarah Barrett, took parental leave to go have a baby (so rude!). I was exceptionally nervous that my lack of knowledge would mean I couldn’t help my colleagues. But then I realized that the questions I was fielding weren’t actually specific to developers, or documentation, or Microsoft -- they were IA questions. How should this work? What’s the best practice? Why should we care? How do we decide what to do next? How do we untangle this mess? Now these I could handle...
This brings us to Lesson 1: Those who can, teach.
Teaching empowers others to build alongside you. It invites others to join your headspace and stand on equal footing as you work through a challenge. We’re going for this IKEA effect, “a cognitive bias in which consumers place a disproportionately high value on products they partially created”. I had a hand in building this Billy bookshelf therefore I love this bookshelf.
An added bonus of teaching is that it’s a powerful tool for pitching your own ideas, and improving them by showing them the light of day. When you have to codify your thinking to the degree that you can teach it to someone else, it really forces you to vet your assumptions and clarify your beliefs. Why do you think I do so many talks? It is a forcing function for me to codify my approach to a thing.
So, how do we teach on the job?
Keep a 101 handy at all times. It just takes a little prep work. Assume that any meeting you walk into, any idea you have, you’re going to have to do a little teaching in order for it to be understood. Assume that there is a toddler nearby asking “Why?” a thousand times.
After teaching a 6-week introduction to IA class, I now have a miniature library of slides, worksheets, and diagrams I use to teach basic IA concepts at the drop of a hat.
While arguing over what role navigation plays in the user experience, I brought out the ‘dimensions of expertise’ diagram, which entertains me to no end because I pulled in characters from The Big Lebowski to illustrate differences in information behavior and needs.
When I was helping someone think through their user interview guide, I brought out my worksheet for learning how to practice interviewing.
While debating how to move forward on an ambitious IA Project: Vetted processes (the IA set, nate davis).
While trying to explain to everyone what an IA does, and how we can help the product team, I pulled out my colorful description that I use with beginning design students.
I keep these ready as teaching aids, and frequently shout the words, “teachable moment!” in meetings. What are the most common questions you get? Make a 101 about those things. Hand it out like candy.
Teaching isn’t always about presenting materials - it can be as simple as taking a moment to clarify something. Define words, even if they seem obvious. While getting confused about the difference between a some content types on our site, I pulled up our definitions. We’ve also added a “terminology” section to our feature specs to define words and concepts we are throwing around in meetings. I will pause discussions to ensure everyone is agreed on the definition of a word like “navigation”. This doesn’t take a lot of prep work - it just requires you to pay attention.
--------
We’ve all fallen prey to the belief that If you want something done right, do it yourself! If all of our murkiest work requires subject matter expertise, then it seems like you might have to do everything yourself, right? How many of us have had this instinct that in order to make sure things go well, you have to control what’s going to happen, and when, and how?
It turns out that doing everything yourself is a very good way to rob your colleagues of input, autonomy, and happiness, and it’s also a very good way to burn yourself out.
Perhaps you say, yes Rachel, we know that lesson, the key is to delegate! Delegation, in which I plan everything out and then tell other people to carry out the tasks.
Simply asking people to do things they neither care about nor understand doesn’t really work so well, either.
This brings us to Lesson 2: “Steer, don’t row.”
There’s an article called “Policy Entrepreneurship at the White House” which is required reading for our IA team, written by Thomas Kalil, a policy advisor who served under the Obama and Clinton administrations. It turns out that policy entrepreneurship and IA in the enterprise have a surprising number of parallels. In this article, Thomas writes about getting things done in government when you have influence, but no authority. One of these lessons is “Steer, don’t row”, and I think it’s so important that I decided to include it here. Thomas writes that policy entrepreneurs should understand “influence without authority” as a job description, that many of the things policy entrepreneurs want to accomplish are actually done by someone else. The same holds true for my role as an IA. I don’t ship code. I don’t publish content. I don’t get to single-handedly sign off on a navigation structure. But I influence all of those things.
Behzod Sirjani has a different take on steering and rowing when it comes to democratizing work as a user researcher. Behzod writes: “we democratize our work by choosing to navigate, rather than drive, and knowing when to become a passenger.” A good navigator provides directions, plans ahead, and envisions a route but does not hold the steering wheel. A good passenger encourages the driver and shares feedback.
Sometimes we hear the word “steering” “and “influencing” and it comes off as “manipulating”...or maybe that’s just me. Instead of steering, navigating, or influencing, I actually prefer to think of this as coaching. There are a few ways that we can coach-to-steer:
Do your homework. Kalil suggests that we always have an agenda, instead of reacting to someone else’s agenda. Question the status quo - what would you do, if you could? If you had 5 minutes with the president -- no, scratch that, 5 minutes with Oprah -- what would you tell her is the most important thing she should accomplish? How would you suggest she do it? Have that ready.
Gather your team:
Surround yourself with experts and tap into their knowledge
Find your “doers” and make it easy for them to help you. (credit: Lara Hogan)
Develop relationships with other agencies, teams, or orgs. Keep in mind that relationships are 2 way streets. They are not a way for you to get what you want out of someone; they are a way to exchange value with another team, as long as the conditions are right. Relationships work when there is
Mutual understanding
Trust
Candor
Reciprocity
Remember your ABCs: Always Be Curious. Never set out to be “right”. Ask many questions. Ask interesting questions...but do not dictate the answers.
Finally, as a coach, it’s your job to provide a framework for the team to help focus. Facilitate the team through a transparent process, framework, or set of principles to help the team focus their thinking. Whatever that is, remember that your role is to provide scaffolding, not do all the work yourself.
Back to this navigation project I mentioned earlier…Before we jumped into a navigation design project, we knew that this work would set a design and IA precedent for our other sites (of which there are over a dozen in our little corner of Microsoft). So, we needed a set of vetted, powerful navigation principles to operate under, that would reliably translate across sites, and more importantly, across team silos and their projects.
Rather than just making those principles up on my own, or with the IA team alone, I set up a working group with colleagues from all over the org to come up with these navigation principles. I brought together program managers, designers, researchers, product managers, business analysts, marketing managers, and IAs. I set up the framework for this working group, and identified some goals to hit, but I didn’t do all the rowing myself. Coming to these principles together took a couple months. These principles ended up influencing several navigation projects in the pipeline; they serve as a north star to guide our decisions and clarify our beliefs about what navigation should do, how it should work, what role it should play.
Now, could I have made these navigation principles this alone? Could the IA team have done this? Sure, and they probably would have been accurate, and true. But...Would they have had the same weight, and effect? Absolutely not. Because I steered the working group through defining those principles and all the discovery work to get there, but did not do all the rowing myself, the principles are now a shared belief system. We all own those principles - there’s that IKEA effect happening. We all believe in those principles, even though we are not all IAs, or even designers. And those principles shape decisions being made by IAs, designers, marketers, engineers, and on and on.
—------
How many of us have been in a situation where we asked for something from our colleague and got a totally unexpected result? How often have we been that colleague, asked for something unclear, and left to struggle in the resulting murk alone?
The modern business psychology powerhouse Brené Brown writes that “not getting clear with a colleague about your expectation because it feels too hard, yet holding them accountable or blaming them for not delivering, is unkind.”
This brings us to lesson 3: “Clear is kind.” -Brené Brown
Earlier this year during the Sofa Conf 2020, Richard Banfield at Invision spoke about better teamwork, and he said “Ultimately, building anything is an exercise in trust.” He went on to explain that Trust is built when the team reaches agreement, there are confirmation signals that the agreement is being honored, and round and round we go.
In order to reach agreement, we have to be clear about what we are agreeing to do together. Sure, oftentimes, what we do as IAs is unclear. How many of you have tried to explain a knowledge graph? The difference between a taxonomy and a dropdown menu? The definition of “information”? We’ll come back to this later.
But the process of how we do our work should not be unclear. It’s not magic. Let’s not pretend that it is. Let’s be clear about what we are going to do, how we are going to do it, how we will work together, and how we will know when we are successful.
Concretely, this means that we are going to “save the world, one document at a time.” -Kalil, Policy Entrepreneurship at the White House
Create, and commit to, a team charter together. This might require some maturity, but I don’t think that’s a bad thing to stretch for. A team charter is a “social contract that you’ve had those hard conversations. You’ve decided what you’re trying to do together and you’ve also decided what could potentially go wrong.” (Richard Banfield, SofaConf 2020).
“Write it down, make it happen.” (Kalil) Ideas are fun. But the world at large operates on concrete actions - this is how stuff gets done. Writing it down makes it real, and it also creates a shared decision trail when, at some point, the path gets fuzzy.
But Rachel, you shake your head. Rachel this is all lovely but how do you expect me to get a team of strangers together to commit to a charter? To write anything down? What if this team is not mature enough to draft a charter?
You’re right. It’s not easy. But, if you are wearing your coaching hat, then you are well-positioned to create a safe collaboration space for your peers so that these things are possible. We create safe spaces by:
Employing curiosity, like we talked about earlier.
Being humble
Getting clear about our expectations for our colleagues, for our teams, for our projects
Your charter can be however mature or immature you want to make it. I don’t care if it’s a 10 page document or a set of sticky notes in a shared digital whiteboard. Make it your Zoom background. Whatever form it takes, a charter should accomplish a few important things that go a long way towards CLARITY:
Acknowledge conflicting priorities. It’s ok for the marketing team and the UX team to care about different things. It’s not okay to pretend that is not going to impact the design of the header navigation.
Document your guiding principles. What is that shared set of beliefs you are all agreeing to work under, that will guide your decision-making?
Establish the rules of engagement - how are you going to work together? Commit everyone to communicating as a team. Commit to not backchanneling. “Talking to someone is kind. Talking about someone is unkind.” -BB Are you going to work asynchronously? What form of collaboration does everyone expect? What are the expectations for your meetings, are they open books or safe cones-of-silence?
Use plain language. Say what you mean and mean what you say, do not cloak your language in jargon and corporate speak.
—------
One of our initiatives at Docs is to put a content model around approximately 40 million pages of documentation & training content. This is a huge amount of work, and it’s a lot to wrap your head around no matter how adept you are at working with content, structure, and the Docs platform. I often get asked by colleagues all over the org, as they hear rumor of this work, “wait, that sounds insane, what are you doing and why???” To answer this in under 5 minutes, I usually end up talking about the jasmine vine in my backyard.
I have this jasmine vine. It’s very healthy and robust. It grows incredibly quickly. It grows so well that one winter, a strong wind came through and the whole vine toppled over. The trellis holding it up was no longer able to support the plant. The plant needs a new trellis, and soon.
Microsoft Docs is a jasmine vine; it’s robust and growing like an extremely healthy plant. The current content model, the trellis, was not designed to support a plant this large and healthy. We need to build a new trellis that can support the plant, and we need to put the plant on the trellis without hurting it.
This silly little story doesn’t explain everything, but it helps my colleagues get the general idea of the issues we are facing, and how we might solve for them. A jasmine vine and a trellis.
(For more thoughts on gardening and IA, I highly recommend Dylan Wilbanks’ article in UX Booth, “On Tending the Garden (and Fighting Kudzu IA)”)
Lesson 4: “Every act of communication is a miracle of translation.”
One reason I love my job so much is that it requires a very specific kind of thinking...and regardless of how you feel about where IA fits into the spectrum of user experience, it’s arguably a specialty, an expertise of sorts. The downside of this is that it often requires translation.
We all do this, every day, but perhaps not intentionally. Last year at this very conference, Rob Scott & Emily Heath presented a brilliant talk about navigating the ladder of abstraction, and I had this transformative moment -- we all translate from concrete to abstract and back again every day, we slide up and down this spectrum, and if we acknowledge that, plan for it, and navigate that ladder intentionally, it’s so much easier to do this “miracle of translating”!
The ladder of abstraction is a concept from S.I. Hayakawa’s book, “Language in Thought & Action”. Essentially, it’s this idea that we have language and concepts that range from abstract (“airy, and open to interpretation”) to concrete (“grounded, solid, certain).
If we apply this ladder in our universe, it might look something like this, where ‘strategy’ is at the most abstract level (“what should the navigation do? How should it fit into our ecosystem?), and implementing real world things (pushing the new navigation live; adding words to a taxonomy) is at the most concrete level. Principles and models may sit somewhere in the middle.
Without going into too much more detail, I think the takeaway here is this: learn about the ladder, identify where your stakeholders are on it, where the project mandates you should be on it, and navigate to the part of the ladder that helps your stakeholders or the project move forward. Sometimes this is in defining principles, or models. Sometimes it’s guiding a product strategy. Sometimes it’s just doing the work. This is a form of translation.
Using the ladder of abstraction as a framework, we can see that various translation tools we deploy may work better at the abstract end, or at the concrete end:
My jasmine vine analogy for the content model we are developing is a very quick and dirty way to shimmy up the ladder of abstraction for those colleagues of mine who don’t need to understand the details, but just grasp why it’s important and how it will impact the site we all work on. I use analogies a lot.
IAs love hanging out in the middle of the ladder, by modeling things, don’t we? I could hang out there all day, happy as a clam...
Often, in murky situations our inclination is to inadvertently jump to the most concrete end, because it feels, well, the most concrete (remember that human brains aren’t great with abstract concepts, so we tend to run away from it). So, we do things like make wireframes, design the interface, sketch it all out, show people the taxonomy spreadsheet, etc, but we say things like, “Now, don’t get attached to this, it’s just an example!” How often does that ever actually work? Now, if you’ve examined your situation and find that concrete is the place you need to be, great! But be forewarned - going concrete too soon makes it difficult for your colleagues to navigate back up the ladder.
--------
Earlier this year I was reviewing some feedback from my coworkers, I noticed an unexpected pattern: they were all telling me to “speak up! Let us hear from you more!” This was surprising, because I’m not really known for keeping my thoughts to myself.
I reflected on this for a while, and realized, yeah, I was being quiet. I like to listen. I also don’t like to step on people’s toes. I grew up in the midwestern plains of the US, where we are extremely concerned about the comfort of others above ourselves.
But more to the point…I realized that I was being quiet because I was afraid…I was afraid of making mistakes. I was afraid of taking people in the wrong direction, giving them the wrong advice, doing the wrong thing. As a result, I was keeping all of my expertise to myself and missing a lot of opportunities to help my colleagues, and to help our customers.
This brings us to my final lesson, the hardest lesson, and the most important one: Be Brave.
In her keynote talk at IA Conference 2020, Abby Covert touched on the need for bravery in our work and I wanted to highlight that here:
“You have to be brave to sort out something that the people around you might assume is un-sort-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.” -Abby Covert
Navigating through murky work requires a brave captain. Information architecture is murky work We have to be willing to try, to be wrong, and to pick up the pieces and try again. Once I realized how timid I was being, I went all the way to the other end of the spectrum. I spoke up constantly. Whenever anyone asked for help, I said yes! I’m going to carry us over the finish line to Good IA!
And you know what happened? I was exhausted. I was burning out. I found this note from a July 1:1 with my manager: “hero mentality - it is braver not to be the hero”
Bravery is not heroism. Heroism is ego, heroism is martyrdom, heroism is a sure path to burnout.
Bravery is about resilience; it’s about gearing up for the long haul and continuing to show up, because the work of an IA is a looooong haul and we must continue to show up. Bravery is about knowing how to teach your craft, how to steer-not-row, how to show kindness with clarity, and how to translate and bring others into the fold, so we may build better things together and navigate our way through murky work.
Resources
Banfield, Richard; SofaConf 2020 https://vimeo.com/showcase/7295448/video/431008671
Brown, Brené https://brenebrown.com/blog/2018/10/15/clear-is-kind-unclear-is-unkind/
Covert, Abby; IAC20 Opening Keynote https://vimeo.com/407827483/407827483
Hayakawa, S.I.; Language in Thought and Action
Heath, Emily & Rob Scott; EuroIA19, Navigating the Ladder of Abstraction
Hogan, Lara https://larahogan.me/blog/running-working-groups/
Kalil, Thomas https://www.mitpressjournals.org/doi/pdf/10.1162/inov_a_00253
Sirjani, Behzod https://yetanother.studio/blog/democratization-is-our-job
