6 ways I enjoyed STC12 (summit wrap-up)

STC Summit 2012 was everything I looked forward to and more. Three weeks ago, I blogged about my Top 5 reasons I look forward to the STC12 Summit which have since grown to 7. I’m happy to say that I accomplished 6 of my objectives:

1. Learn about new trends

I took valuable insights from several sessions, even though many of them were new ways of looking at things, rather than new trends. Here are just two examples:

Change management done differently. I’ve long thought that typical change management processes (as John Kotter and others advocate them) often don’t work for tech comm, because the sense of urgency is hard to achieve in an environment where documentation is not seen as mission-critical. James Conklin in his session “Overcoming Change Resistance” presented a new, more conciliatory way of addressing change which makes sense to me and may work where more conventional means fail.

Content models: Context, not templates. We’ve introduced a content model at the company I work for (we call it “information model”), and we’ve come across a couple of hick-ups in the implementation. Andrea Ames and Alyson Riley’s session on “Modelling Information Experiences” presented solutions to both of them: Our model will be more effective in the context of a use model – and using it in a template doesn’t necessarily work…

2. Find inspiration and solutions

Inspiration came from Scott Berkun’s opening keynote about how “creativity works sideways” (scroll down in the target post).

Solutions a-go-go for project management issues were provided courtesy of Leah Guren’s session of Tales of Terror: Avoiding Project Disasters.

3. Present my own session

I’m kinda confident that attendees got something out of my presentation – but I know what I learned from my pattern recognition talk.

4. Meet old friends, make new friends

With around 800 attendees, the summit is large enough for serious networking and less than serious drinking, karaoke, etc.  Whether the hallway track between sessions, the official summit receptions, drinks at the hotel bar, an afterhours party in the hotel’s executive suite or outings for dinner, I’ve met new and old friends from all corners of the US and Canada, England, Australia, Finland and several places I’ve forgotten.

A special highlight was Tuesday night’s music jam with the Rough Drafts, featuring Tommy Barker on guitar. I got to sing on “The Weight”!

5. See Chicago

I had set aside only a few hours for sightseeing, but got to see the Art Institute (as planned) with some fellow tech writers (as a welcome surprise) for a great outing.

6. Shop around for help authoring tools

This was the one goal that I didn’t achieve – mainly because I’m currently not looking for a new tool.

Instead, I got to talk to the helpful guys at MadCap about our implementation project of Flare. I’ve found out that I used hyperlinks in one project, though cross-references would be better – and that Analyzer can help me convert the links to references automatically. Someone who can point out a poor implementation – and its automated solution – in the space of 5 minutes is my kind of vendor… 🙂

7. Deep dish pizza

Thanks to Larry Kunz who suggested adding this important item to my list of objectives. A bunch of us had deep dish pizza delivered to the hotel, and it was delicious (if rather filling – but that seemed to be the point… 🙂 ).

Shoutouts

Many thanks to everyone who made this STC summit such a success:

• The organizers for inviting me to speak and running the summit so smoothly
• The STC Chicago chapter for the helpful, cheerful hospitality table
• Everybody who tweeted and blogged about sessions I could not attend or dinners I would’ve missed – especially Sarah Maddox who takes the cake for most comprehensive, lightning-fast blogging coverage!

Thank you all for a wonderfully energizing and enlightening time – I’d be a less competent, less happy tech writer without it!

Advertisement

A. Ames & A. Riley on info experience models at STC12

Andrea Ames and Alyson Riley, both from IBM, presented a dense whirlwind tour on “Modelling Information Experiences” that combine four related models into a heavy-duty, corporate information architecture (IA).

While the proceedings don’t include a paper on this session, Andrea posted the slides, and the presenters published a related article (login required) “Helping Us Think: The Role of Abstract, Conceptual Models in Strategic Information Architecture” in the January 2012 issue of the STC’s intercom journal.

The session proceeded in six parts. First, Alison explained IA models in general and how they work. Then Andrea described each of the four model types that make up an IA specifically.

IA models as science and art

Information architecture relates to science as its models draw on insights and theories of cognition. And its models relate to art as they aim to create a meaningful experience. Both aspects are important. Only if IA models manage to blend science and art can they touch the head and the heart.

The session focuses on IA models instead of theories (which are too vague and abstract) or implementations (which are too specific and limited). Thanks to the in-between position of IA models, we can use them to

• Ask the right questions to arrive at a suitable, feasible IA
• Tolerate the ambiguities of “real life”

Models present descriptive patterns, not prescriptive rules. They don’t say how stuff must be, but how it can be represented. They differ from real life, but real life is still recognizable in them.

That means you cannot simply implement a model on autopilot and get it right. Instead, you have to

• Think how to implement the model
• Vary the model for your users’ benefit
• Listen to the right knowledgeable people when implementing

Models help you think

To arrive at your concrete IA, you take the model’s abstract patterns and apply your project-specific details to them, the who, what, where and when.

This task is less mechanical and less copy-and-paste than it sounds. It’s not so much a question of following rules and recipes, but of making abstract patterns come to life in a coherent, flexible whole. (If you’ve ever tried to create meaningful concept or task topics by following an information model, you know it’s more than just filling in a DITA template. You need to use your own judgment about what goes where to achieve and maximize user benefit.)

Since there are four related models, you need to think carefully how each of these models should benefit your users. And the models help you think, they scale and adapt to:

• How your business and its information requirements develop over time, how they grow and expand in desired directions
• How your customers find, understand and apply the information they need

The four IA model types

The IA model that Andrea then explained consists of four related model types:

use model (content model + access model = information model)

Each of these model types needs to be developed and validated separately.

The use model defines how users interact with information. It describes standard scenarios for optimal user experience within the product or system context. It outlines what information users need and why and how they use it. It includes use scenarios for the entire product life cycle and user personas that outline different types of users. Fortunately for us technical communicators, Andrea pointed out, describing all this is part of our core skill set.

The content model defines how information is structured effectively. This could be DITA (in the case of the company I work for, this is what we call our DITA-derived “information model”). It includes the granular information units and their internal structure, for example, task topics and their standard sequence of contained information. It also describes how these granular units are combined into deliverables.

The access model defines how users access the information efficiently. It makes provided information useable, thanks to a navigation tree, a search function, a filtering function to increase the relevance of search results, an index, etc. Artefacts of this model type are wireframes, storyboards, a navigation tree and the like.

The information model defines how users get from one stage to the next. It uses the other three model types as input and fills in the gaps. It combines the content and access models which probably work fine during the installation and configuration processes, but may not yet carry a user persona from one stage to the next. As such, the information model is sort of the auxiliary topic that you sometimes need to insert between concept, task and reference topics to make a complete book out of them. At the same time, this model type is more detailed than the use model and closer to the other two types.

My takeaways

I was extremely grateful for this session and rank it among the top 3 I’ve seen at the summit – or any tech comm conference I’ve been to! Yes, it was fairly abstract and ran too long – my only complaint is that it left only 2 minutes for discussion at the end.

As abstract as much of the session was, it actually solved a couple of problems I couldn’t quite put into words. After designing and teaching our company’s DITA-derived information model (which is a “content model” by this session’s names), I thought our model was applicable and useful, but it had two problems:

• Our model lacked context. – Now I know that’s because we haven’t mapped out our use model in the same detail and failed to connect the two.
• Our model was baked into a template for less experienced writers to fill in – with varying results. – Now I know that’s because the models are not supposed to provide templates, but require writers to use their own judgment and keep in mind the big picture to deliver effective information.

Another lesson I learned is that many structured information paradigms seem to include a less rigid element that sweeps up much of the miscellaneous remnants. In DITA, there’s the general topic which is used for “under-defined” auxiliary topics to give structure, especially to print deliverables such as manuals. In this IA model, there’s the information model which fills the gaps and ensures a more seamless user experience than the other three models can ensure.

– For an alternative take, see Sarah Maddox’ post about this session.

What I learned from my pattern recognition talk at STC12

My session on pattern recognition for technical communicators was a very rewarding experience which taught me a lot. I thank Paul Mueller, Conference Manager, and Alyssa Fox, Program Committee Chair, for inviting me to speak, even though this was my first summit. Their friendly, indefatigable support set the tone for a high-energy, well-run conference.

If you want to revisit the session, here are the slides and the article from the proceedings. (If you haven’t attended the session, the article will probably be more helpful, for reasons explained below.)

Here’s a look behind the scenes of my talk and what I learned:

Two different roles

Attending a conference is not the same as speaking at one. Well, duh…

But what I mean is this: I took care to be an observant attendee before my own session, so I could gauge expectations and behaviors of attendees. Bluntly put: As attendee, I want my money’s worth. As speaker, I need to give my audience their money’s worth. Observing and knowing the first helped me achieve the second – or so I hope.

When I was still in academia, I was often put off by conference presenters whose ignorance of the audience’s interests and demands could be quite arrogant – and usually didn’t help the conference as a whole, either. So I wanted to avoid that.

Plus, one of the mantras of technical communicators is: “Know your audience!” How could I afford to ignore it at a tech comm conference?

“Unusual” works

I was unsure about my topic, because it was a bit unusual and off-the-wall: Tying the psychology of perception to technical communications – only to confirm what we do anyway, such as topic-based authoring and parallelism?

(Photo courtesy of Jamie Gillenwater)

On the other hand, I know from attending previous conferences, how much I enjoyed and benefitted from such sessions. A-ha moments are fun and enlightening, they work in TV science programs, so maybe they’ll work at a conference as well…

During the session, I was too busy to count heads, but I’m guessing I might have had an audience of 70 people maybe. There were other sessions to choose from. Or breakfast, since I was in the 8:30 slot. So I decided early on to get over my worries and trust in the general curiosity of tech writers. 🙂

Rehearsing pays

So practicing helps… Again: Well, duh…

Specifically, it allowed me to move beyond bullet points. I’ve seen many a session (less so at the summit) where presenters mainly read their slides. To me, those are usually not the best presentations. I don’t need great showmanship, but reading the slides seems as if the speaker serves the slides rather than vice versa.

I’ve tried to make at least the a-ha moments less reliant on words and bullet lists and more like an illustrated story. And I’ve found that decent images will remind me of the story just fine. (The last section about actually applying pattern recognition in tech comm has more bullet lists, so people could take notes.)

In addition, I found that rehearsing also helps me to “know time” (a pet obsession of mine; I even have a blog post about it). I’ve seen excellent presentations, but it peeves me a bit if they take up 58 of 60 minutes. I also learn by asking questions and by engaging with the speaker or others in the audience. And to me, it seems a bit careless to mar an excellent session by running overtime.

Budget your energy

I am really glad (and almost a little proud) that we’ve had such a lively, engaging discussion after my presentation. People suggested additional sources, propped up some of my arguments and ran with others, bringing up evolution, Edward Tufte’s information graphics and – privately afterwards – even Immanuel Kant!

My one regret is that by that time I was a bit exhausted and didn’t always do justice when repeating the question or comment for everybody in the room and for the recording. Not sure how I can achieve it, but I want to save not only time, but also energy to facilitate the discussion afterwards.

But all in all I think the session went well, I’ve really enjoyed the experience and am glad to contibute to our curious, friendly and supportive tech comm community!

Leah Guren’s Tales of Terror: Avoiding Project Disasters at STC12

Leah Guren presented a spunky, fast-paced session of project train wrecks that offered many lessons to managers and writers in tech comm projects. She presented disasters in five categories: Communication, people, politics, implementation and global issues.

“Failure to communicate”

When poor communication derails tech comm projects, it’s often due to missing information. Specifically, a project may have failed to ask the right questions (almost like performing due diligence) or failed to insist on getting the questions answered by the subject-matter experts or the specifications.

To prevent this problem, don’t write blind! Ensure that the project is clear not only on the product, but also on the users, their scenarios and workflows. This is a tricky issue that it afflicts even experienced tech comm’ers who may be tempted to wing it. But a checklist can help you to cover all your bases.

Of monster managers and quirky SMEs

People can jeopardize documentation projects, especially if they bring together people who don’t work together in projects very often. As a tech communicator, you might deal with an annoying monster manager breathing down your neck one minute and placate a quirky subject-matter expert the next.

Leah’s advice was straight and matter-of-fact: You can’t fix crazy, so don’t take it personally. You might even find yourself documenting irrational processes and workflows.

Of stakes and turf wars

Politics can endanger projects when agendas clash and turf wars arise between fiefdoms. This is actually the reason why so many organizations still run a balkanized business where development proceeds in distributed siloes. The resulting documentation often perfumes the pig though it can hardly help being inconsistent or disparate.

Consider carefully whether it’s worth the extra effort to try and clean up broken workflows and GUIs after the fact – or if you even have the leverage and the clout to be successful.

Of implementation constraints

Implementation can throw a wrench into a well-planned project, when you find you lack skills, resources or access to such. Sometimes you’ll see warning signs, such as “scope creep” when a project quickly becomes more complex than you thought originally. For example, Leah talked about a project which was to cover a complete product overhaul – and an SAP integration on top of it.

This is a case for a senior stakeholder or manager who needs to assess the situation and who can hopefully reschedule tasks or reassign resources.

Of intercultural complexity

A recent, often unexpected problem in tech comm is complexity due to globalization. Global business often doesn’t scale seamlessly, and tech comm (as all culturally contingent practices) even less so.

If your project involves countries, markets and languages you haven’t been involved with yet, take extra care. However, as companies find out again and again, there seems to be no fool-proof way to address this issue, other than trying to look at similar case studies.

Solutions and remedies

Leah held off suggested solutions until the end. The good news is that many projects can address many of the issues to an extent with standard project management tools and best practices.

• Use a project check list that defines scope, deadlines and involved participants, incl. their roles, goals and expectations. Include also SMEs and other stakeholders.
• Track project status meticulously and insist on regular reporting – from participants and to the steering committee.
• Have a contingency plan, if at all possible, which can buy you extra time or replacements for people if you need them.

Salvaging wrecks

But the best-laid plans don’t always guarantee success, so you might find yourself with a project train wreck that needs salvaging. Leah’s advice, at least to me, wasn’t revolutionary or new, but rather an encouragement to stay honest:

• Don’t hide from problems or difficult people. They won’t get better and they won’t disappear by themselves. Face them and address them as soon as possible. If nothing else, you’ll sleep better.
• Cut your losses, if you have to and find the right time to cut your losses, before you throw good money after bad. If you, be clear to everyone (including yourself) what went wrong and why.

The assurance of coaching

After her presentation (which already included several case studies that I have omitted above), Leah solicited further case studies and problems from the audience. This rounded out the session quite well which felt like coaching on speed.

For me, the most important take-away was that projects can and will go wrong for all kinds of reasons that are beyond our control. But if we are alert and honest to ourselves, we can salvage most of them, wrap them up with decent success and saved face.

James Conklin, Overcoming Change Resistance at STC12

In “Understanding and Overcoming Resistance to Change”, James Conklin focuses on change, rather than on management as most change management seems to do.

Why change fails

The problem with many change management initiatives is that they fail. Too many of the involved people perceive change as a thing that is “out there”. So instead of embracing the new, they resist this “external change thing” on several related levels:

• Fear. Change threatens to undermine the skills, power and security that people have built up.
• Reason. People argue rationally against the change because it contradicts their goals or because they simply do not understand how it will improve things.
• Personal attributes. People may resist change because it doesn’t address their age group or their learning styles or their cultural or ethnic background.
• Psychology. Change can incite strong emotions that leads to denial and, once again, to fear.

Why the explanation fails

James points out that these reactions involve a significant “attribution error”. We tend to blame other people’s resistance to change on them, their attributes, their lack of skills, their stubbornness. But we often blame our own resistance to change on our situation, lack of time or resources, etc.

What resistance is

There’s a more constructive, alternative perspective on resistance which is compatible with both sides of the attribution error: Resistance is one of the ways we make sense of life, specifically of our experiences in the workplace.

If we perceive resistance as a clash of narratives of different experiences, we can get away from an opposition of stubborn persons and towards an open-ended, negotiable inquiry – without losing sight of the goals! We can focus on fixing the situation by redistributing power and autonomy instead of blaming people and transforming their tasks.

What sounds very theoretical up to here, has been born out by studies from Canadian nursing homes where nurses and caretakers had initially resisted changing their procedures. I’m also reminded of other successful changes in the workplace, whether it’s Best Buy’s ROWE initiative or schemes that empower people to work remotely and still manage to hold them accountable for their work and results.

What this has to do with techcomm

For many in the audience (myself included), it was obvious that James speaks about change that technical communicators find themselves in. But James also points out that technical communicators play an essential part in shaping narratives of change.

We set the tone in customer-facing documentation: If we know their situation, we can join their conversation, explicitly compare their current situation to a new way of doing things. Then we take them seriously and address a change in processes constructively. We can even engage in their conversations directly, for example in forums or other user feedback.

If we recognize the importance that our users place on the purpose and value of their work, if we reflect not just the metrics of their work, but also the quality they attribute to it, we can improve the user experience and help to facilitate change with technical communications.

Neil Perlin, Developing for the Unknown at STC12

It’s of course impossible to develop techcomm content for formats that don’t exist yet, but Neil Perlin shows how you can prepare for them to future-proof your work – and job.

Problem

The problem he addresses is that content formats will change, we just don’t know yet how. The answer is generally to create solid content by setting and using open standards. By doing that (and avoiding proprietary standards, hacking code and tweaking our tools), we can ensure that our content will have a good life and be relatively easier to use in any future formats that might come down the line. And keeping with developments is important, so we decide which standards and tools can help us in the future.

Better structure

On the structural level, you can best standardize your content by using information types (also called “topic types”), such as task, concept, reference, troubleshooting, “show me”, etc. Try to keep your number of types below 10. (DITA, a structured authoring standard has only 1 general topic type and the first 3, I’ve just mentioned.)

Once you have your information types defined, you can create templates that already contain the topic structure plus some explanatory boilerplate text which you and other writers can replace with your actual content.

Multiple output formats

On the technical level, CSS is a great medium to future-proof your content: It lets you create your topics independent of layout. And it is powerful enough to support just about any HTML-based format to make your content (and you as its author) look good on the web, on tablets and on mobile.

Using CSS to future-proof your content means, among other things:

• Keep your CSS definition simple and clear for easier use and better maintenance.
• Define all your output formats in one CSS file by defining different media types for different devices, web and print.
• Check that the most common browsers and devices which you write for support CSS correctly. (If not you may have to live without some CSS features for the time being.)
• Use relative style size units instead of points (“pt”) which are not resizable.
• Use styles for tables instead of hand-tweaking column width, etc.
• Use character styles instead of “Bold” or “Italics” as in Word’s style toolbar.

To migrate your content from more proprietary formats may require some cleanup of embedded and inline styles. Some of this can be scripted, but you may still find yourself with a lot of semi-automatic search and replace.

Adopt, don’t adapt

On a methodological level, Neil advises to adopt a standard because it suits you and your business needs. Adapting your content to a standard because it’s common or new without a business case is not a good idea. So put your company and your job first and build up in-house knowledge about standards, formats and tools, so you can make the right choices.

Verdict

It takes Neil’s long experience to successfully combine general career advice with specific tips about CSS. I really enjoyed this session. I’ve learned a few new tricks and got general confirmation that our strategy to migrate our documentation to XML in a DITA-derived structure was the sensible thing to do.

Things I learned at STC12 on Sunday

Even though I only arrived at the STC Summit 2012 on Sunday afternoon, I learned a lot already, despite missing the pre-conference workshops and certificate courses.

Planning good, worrying bad

My worries about congestion and heightened security due the NATO summit in Chicago were unfounded. Immigration and everything else at O’Hare were as smooth and easy as I’ve ever seen it.

STC Chicago rocks

Separate from the conference registration, there’s a hospitality desk which I believe is run by the Chicago chapter of STC.

They are courteous and competent and point you in the right direction, whether you’re looking for food outside the hotel, directions, transportation options and sights to see.

Use twitter, before and during

Whether I’m attending a rock concert or a conference, I like myself a pre-show buzz where the excitement builds before the event. Following the twitter #STC12 hashtag, I’ve found updates, a pre-show buzz – and lots of faces to meet as I roam the halls! (Many attendees add their twitter handle to their conference badge which also helps to put faces to the names.)

It’s all about community

The opening general session outlined where the STC and the industry at large is at. I’ll just mention one detail that impressed me: The immense work and care of the conference committee who put together a program that ensures that we all get the most out of STC 12. Conference chair Paul Mueller and Program Chair Alyssa Fox did a great job – and still have the time and energy to make newbie speakers like myself feel right at home.

Creativity works sideways

Scott Berkun’s opening keynote was not specifically geared to tech comm, but his session about the myths of innovation was entertaining and engaging.

A common theme for me was how creativity thrives when you look for solutions sideways, instead of staring a problem straight in the face:

• Most ideas don’t come from spontaneous flashes of insights, but from other ideas, whether they’re smaller ideas combining into a bigger whole or an existing idea that you apply in a new domain.
• Most of your ideas won’t succeed because they’re innately brilliant. Look sideways to informercials how you can pitch your idea: Start with customers and their problem for context, then show how your idea solves the problem.
• Many teams who get stuck while implementing an idea won’t benefit from more resources or rules, just like a truck stuck in a rut won’t get out with more people in it and better maps. Instead, make the team smaller, give it more authority, and choose people who thrive in uncertainty.

Don’t forget to party

I had a grand time at an afterhours party. I made friends among seasoned tech writers (Hi, John!) and budding ones (Hi, Elizabeth!). The one mistake of Day 1 was a Sam Adams “Cherry Wheat”. It’s a mystery to me how this can be called beer. 🙂

Top 5 reasons I look forward to the STC12 Summit

I’ll be going to my first STC Summit in a couple of weeks and I’m already really excited about it. Here are my top 5 reasons and motivations:

1. Learn about new trends

The obvious reason to attend a conference: Many of the 80 sessions cover new industry trends – or at least topics that are new to me. We’re currently implementing a new HAT which brings a a lot of opportunities and some challenges, so I’m looking forward to:

• Andrea Ames’ Improving the User Experience by Applying Progressive Information Disclosure
• Nicky Bleiel’s Five+ Ways to Add Interactivity to Online Help
• Peter Lubbers’ Getting Started with HTML5
• Michael Priestley’s Using DITA
• Andrew Thomas and Arte Kenyon’s A Writer’s Firsthand Account of DITA in the High Tech Workplace

2. Find inspiration and solutions

The sometimes unexpected benefit: At previous conferences, I frequently got ideas about improving a broken process or solving an irritating problem, even if that was not the main focus of a session. Such insights might come from an aside comment or something I see on a slide that inspires me to connect the dots. That’s why I’m looking forward to:

• Scott Berkun’s keynote The Myths of Innovation
• Scott Abel’s Turning Technical Documentation into Profit
• Karen Mulholland’s Greatly Exceeds Expectations 
• Neil Perlin’s Developing for the Unknown
• Ellis Pratt’s What Should Technical Communicators Do When Products “Just Work”?

3. Present my own session

A highlight for will be Pattern Recognition for Technical Communicators!

I’ll be on Wednesday morning at 8:30. I know that’ll be difficult after Tuesday’s banquet and whatever after-hours may transpire. But it’s actually a very good time!

• A good time for you, because you can ease into the last day with an entertaining session that gives you a different, thought-provoking perspective on what you do anyway.
• A good time for me, because I can get a feel for the conference on Monday and Tuesday and then get it out of the way firsrt thing on Wednesday. So I hope to see you there!

The conference program

After teasing you about several interesting sessions, here’s the complete conference program:

• In a website, sortable by track, time, speaker or session code
• In PDF, sorted by day and time, with session codes and titles only
• In Excel 97-2003, sorted by day and time, with titles and main presenter

The first two are the official resources from the summit website, the spreadsheet is from me. All three are current as of May 6, but only the first one will be up to date in case of changes (an updated PDF may have a different link…). To be on the safe side, check the official summit website. – Now back to the reasons…

4. Meet old friends, make new friends

The pleasant side effect also called “networking”: As much as I enjoy social media as a virtual lifeline to stay in touch with the techcomm community, nothing beats meeting in person over a beer once or twice a year. So I’m looking forward to meeting speakers and delegates, tweeps and blog readers!

5. See Chicago

The tourist bit: I know Chicago a little bit from when I went to UW Madison in the 1990s. But I haven’t been in a while, and I’m especially looking forward to visiting the Art Institute and the new Modern Wing – or at least new to me. 🙂

6. Shop around for help authoring tools

Your bonus reason. The company I work for is not in the market right now for a new tool, but maybe you are. With more than 50 product and service providers exhibiting, you’ll have an excellent chance to see a lot of products up close and compare them closely. It’s a little like meeting friends: Nothing beats a first hands-on experience, and it’s a lot less daunting when you don’t have to install a trial version and click your way around. Vendor exhibitions at conferences were essential for us when we were choosing our tool.

7. Deep dish pizza

The gourmet reason. Thanks to Larry Kunz for the reminder, see his comment below. I was quite fond of Pizzeria Uno in my Madison days…

– If I forgot a reason to go to a conference, please share it below. If you’re attending the STC Summit, I hope to meet you in Chicago!