Scriptorium Publishing

content strategy consulting

Managing DITA projects (premium)

July 11, 2014 by

A DITA implementation isn’t merely a matter of picking tools. Several factors, including wrangling the different groups affected by an implementation, are critical to successfully managing DITA projects.

Note: This post assumes you have already done a content strategy analysis, which determined the DITA standard supports your company’s business goals.

Wrangling people

Good content addresses its audience at the right level. During a DITA implementation, you must do the same when working with the different groups affected by the DITA project. Talk to them about their particular concerns and requirements in language they understand.

circus tent

Managing DITA projects is a lot like running a three-ring circus (flickr: Nathan King)

For example, engineers who occasionally provide bits of content don’t care about all the fancy features of the XML authoring tool used by the tech comm group. The engineers are far more interested in contributing content as quickly and easily as possible (through a simple web interface, perhaps). Also, engineers will understand the value of DITA’s topic-based, modular approach when you compare DITA to object-oriented programming.

Content modeling

Even though you’ve chosen the DITA standard as your XML model, you still have to do content modeling. You can start by creating a spreadsheet cataloging the tags in your current template and then list out the DITA equivalents. Seeing how existing information works in DITA is a good way to learn the DITA structures—but be careful not to focus exclusively on how you created content in the past. You probably didn’t follow DITA best practices in your old content, so be aware of what you may need to change—or throw out altogether—to develop quality DITA content.

You also need to figure out how to track metadata—data about your data. In DITA, much of your metadata goes into element attributes. You can use those attribute values in many ways, including filtering what content does and does not go into output (conditional text), narrowing your searches of DITA source files, and including processing instructions for particular forms of output (for example, the IDs for context-sensitive help).

Metadata isn’t just at the topic or paragraph level, either; you need to think about its application at the map file level. (The map file is what collects topics together for an information product such as a PDF book, a help set, an ebook, and so on.) In map files, there are elements expressly for tracking publication-level information: publication date, version, release, and so on. Don’t fall into the trap of thinking metadata = attribute.

There are other content modeling considerations. Do you need to create a new element or attribute type through the process of specialization (creating a new structure based on an existing one)? Also, how are you going to use special DITA constructs, such as conrefs (reusing a chunk of text by referencing it) and keywords (variables for product names and other often-used words and phrases)?

Evaluating tools

Choosing a tool is not a content strategy. Choosing tools that support DITA does not mean you have a DITA strategy.

Ensure those evaluating tools aren’t suffering from “tool myopia.” They should not use their current tool’s capabilities as benchmarks for a new tool, particularly when a group is moving from a desktop publishing tool to an XML editor.

Also, tool requirements go beyond primary content creation. Think about the entire workflow; get input from all the groups affected by your DITA implementation, and remember that a tool for one group may not be a good fit for another.

Create a weighted spreadsheet so that the really important requirements get precedence during ranking. Also, you don’t have to limit your requirements to “yes or no” questions. If necessary, create short narratives that explain specific use cases and ask vendors to demonstrate how their tool supports those use cases.

Parse vendor claims carefully. Ask specific questions about a tool’s support of DITA constructs: How does your tool support the use of conrefs? If you’re not comfortable with the answers you get from a vendor during the evaluation process, you’ll continue to be uncomfortable (and unhappy) after you purchase a tool from them.

Strongly consider involving a third-party consultant (yes, Scriptorium!) in developing requirements and vetting vendors. The consultant can help you cut through the bunk and also act as the “bad cop.”

Understanding outputs

Default outputs (PDF, HTML, and help) generated from the DITA Open Toolkit are hideous—but fixable. Don’t be scared off by the ugliness of default output, and don’t let project naysayers use the default formatting as a cudgel: See, we can’t use DITA because the Open Toolkit doesn’t create decent output!

Take a software development approach to your outputs. For PDF content, you can create requirements that specify the formatting for different heading levels, admonishments, body paragraphs, steps in procedures, tables (both for table formatting itself and the text in the table), and so on. If you want to re-create what you have in a template file for your current text processing tool, you can take all the formatting aspects (font, line spacing, indent, color, and so on) from it. Detailed specs are going to make it easier to modify the stylesheets that transform your DITA XML into PDF, HTML, and other outputs.

Get significant budget for modifying the transformation stylesheets. PDF transforms are the most complex and expensive; transforms for web pages, ebooks, and so on may run less, but that depends on their complexity. Even if you have transform experience in house—and most companies don’t—you still need to block off that person’s time, and that is an expense as well.

Considering conversion

Before you even think about conversion, research DITA best practices. Reading the DITA spec won’t help you with that. Instead, get a book such as The DITA Style Guide (download the free EPUB edition) that offers advice on the best ways to implement the many elements and features in the DITA model.

If your legacy content is not tagged consistently and has lots of formatting overrides, you cannot convert that content cleanly through scripting. Also, if your content is not easily broken into chunks that are the equivalent of DITA topics, you may be better off just starting over.

Even if you’re not going to convert legacy information, you still need content to test your DITA model and the transforms for output. Create what I call a “greatest hits collection” of DITA files that represents real-world content you create and distribute. I’d recommend 50 to 100 pages of content to be sure you’re thoroughly testing your processes and outputs.

I have yet to see a conversion project completed without some sort of complication: there is going to be bad tagging, layout quirks in your source, or some other lurking horror that will pop up. Resign yourself to dealing with these surprises, and give yourself lots of lead time so you can handle those issues.

Read more tips on converting legacy content to DITA.

Have questions about managing your DITA project? Contact us. Also, watch this recording of my webcast on DITA implementations:



From soccer balls to content strategy: the kick of change resistance

June 10, 2014 by

Your content strategy can learn a lot from soccer ball manufacturing plants in Sialkot, Pakistan.

The town produces 40 percent of the world’s soccer balls, and it’s now in fierce competition with other Asian companies eating away at Sialkot’s dominance in the soccer ball market.

soccer ball being kicked

Yes, a soccer post just before the World Cup (flickr: Michael Johnson)

When economists offered the plants technology to decrease the amount of wasted synthetic leather, they thought the plants would jump on the chance to adopt the innovation and save money.



“I told the owner that it’s not going to work,” says Mohammed Iqlal Urfnana, a worker at one of the soccer ball firms. He is a cutter, meaning he operates a die-press to cut out the hexagons and pentagons that are sewn together to make a soccer ball. Like many workers, Urfnana didn’t like the new die. “For us cutters, this means lower daily wages.”

That’s because Urfnana, like most cutters in Sialkot, is paid by the piece. Learning how to use the new die would slow him down, so he would make fewer pieces and therefore less money. While it was in the factory’s interest to save money by cutting the fake leather more efficiently, it was not in the worker’s interest.

Change resistance has a long, storied history of wrecking innovation in the workplace—whether it be in soccer ball manufacturing or in the creation and distribution of content. Workers become accustomed to The Way Things Are (TWTA), and talk of higher corporate profits isn’t an enticement for those doing the work to change TWTA.

In the case of the soccer balls plants, the economists offered a bonus for workers who learned about the new die. That incentive realigned the workers’ self-interest (money) with the company’s goals to reduce wasted leather. With the bonuses in place, about half of the plants implemented the new die system.

Despite the fact that money talks (and quite loudly), I’m not recommending paying content creators bonuses to learn about the tools and processes for a new content strategy. Staffers in tech comm, marketing, and support departments aren’t usually paid on a per-topic or per-paragraph basis, so that model doesn’t make sense.

However, there are other ways to gain support for new processes. Employees are often concerned about productivity loss when changing tools —reduced productivity usually means late nights at the office to meet deadlines. Simple gestures (ordering in food during those long workdays, for example) can make a huge difference in workers’ perceptions. It’s also unfair to hold employees accountable for hitting productivity benchmarks during process change, so give content creators time to adjust to new systems before calculating metrics and using them in performance evaluations.

Further mitigate change resistance by pinpointing and communicating the value of change for all the different groups affected by proposed process modifications. For example, if there is manual drudgery that everyone in a particular department hates, ensure the new process automates those tasks. Making unpleasant things go away is powerful force in gaining support. You should also offer training and establish strong communication channels for addressing inevitable pushback.

Forcing process change from the top just doesn’t work. You must align the company’s goals with workers’ self-interest. Otherwise, your strategy will end up in tatters—like scraps of synthetic leather swept from the floors of soccer ball factories.


Beware the monster of change management: THE MAGNIFIER

April 15, 2014 by

For his 1959 horror movie The Tingler, director/producer William Castle had movie theater seats rigged with buzzers to scare moviegoers during a scene when the Tingler creature is loose in a theater. Patrons in those seats probably didn’t enjoy the jolt—or making a spectacle of themselves because of the Tingler’s “attack.”

If you’re managing the implementation of new processes and tools as part of your job, you’re in a hot seat of your very own—and you need to be on the lookout for another horrifying monster: THE MAGNIFIER.

Poster for The Tingler showing a chair and the words, Do you have the guts to sit in this chair?

Poster for The Tingler (Columbia Pictures)

When you’re determining how changes will support corporate goals and calculating the potential return on investment (ROI) for process improvements, it’s easy to get caught up in the excitement generated by the positive things that new processes and tools will bring.

But don’t be lulled into a false sense of security by all the goodness. Lurking in the darkness is the Magnifier, and it will pounce on you if you let your guard down.

So, what is the Magnifier? It’s a phenomenon I’ve witnessed again and again on process implementations: the very act of process change can magnify existing personnel problems in an organization.

For example, if employees do not have a significant understanding of the company’s products and goals, they may create a lot of busy work to mask their lack of domain knowledge. When it comes time to update processes, “busy worker bees” want the details of their unimportant work codified as part of the new processes to make themselves relevant and indispensable (at least in their own minds) in the new workflow. These employees are less interested in the company’s goals than saving their own skins, and that trait becomes even more evident in times of change.

Employees with control issues are highly inflexible and want everything done their way. During process change, they will take a “my way or the highway” approach. For example, if they are dead set on a particular tool set, they will sandbag the tool selection process by exaggerating the feature set of their favored tool and by overemphasizing “problems” with other tool solutions.

Before you think I’m wallowing in unproductive negativity here, please understand I have witnessed the preceding poor behavior on multiple consulting projects (and I’m not even close to cataloging all the bad stuff I’ve seen). As the manager of a process change project, you must be prepared to fight the Magnifier. Effective weapons against it include:

  • Outlining clear business goals for process change. If a proposed tool or process does not support the company’s end goals, it should not be part of the solution.
  • Establishing clear communication among all parties. Start the communication channels up early as possible, and involve everyone, even those who are indirectly affected by the process changes. The company’s business goals should be front and center as part of all change-related conversations. As the project manager, you need to differentiate between legitimate concerns and outright recalcitrance during conversations. Pushback from others can help you identify weaknesses in the proposed workflow that you had not considered.
  • Hiring a consultant, even just part-time. A consultant has seen the Magnifier do its evil thing on other projects and can therefore help you locate and dispose of it early—before it does too much damage. Because consultants come from outside the company, many employees give what they say more credence, even if the consultants end up repeating the very things you’ve been saying all along. A consultant can also act as the “bad cop” in unpleasant situations, particularly ones involving personnel changes (detailed in the next bullet).
  • Realizing that successful change management may depend on personnel changes. Implementing new tools and processes is not going to magically transform poor employees into model workers. In fact, bad employees will have a negative impact on process change. If an employee’s recalcitrance is having significantly detrimental effects, consider reassigning them to another project (for example, maintaining the legacy system), placing them on a performance plan, or even terminating their employment. You must weigh the employee’s value to the company against the drag he or she is creating on the project.

Have you fought off the Magnifier in past projects? Please detail your battle scars in the comments below.


Tools, the content strategy killers

March 17, 2014 by

Quick! What’s the first thing you think about when you want to change your content strategy (the way you produce and distribute content)? If your answer is “tools,” you’re in good company.

First considering the technical aspects of a project is a common and understandable reaction. However, focusing too much on the tools can be the very thing that kills your content strategy.

Image of Jack killing the giant

Jack killing the giant (from The Chronicle of the Valiant Feats of Jack the Giant Killer, 1845)

Soft—or non-technical skills—are essential to evaluate when you’re hiring new staff. By extension, the non-technical aspects of new processes require your attention, too.

You can implement a rigorous tool selection process and spend a lot of time vetting tools, but those investments are useless if you don’t communicate the value of process change. Getting buy-in from all affected parties means you need to offer tailored messages to the different groups. For example:

  • Executives: increased revenue because of shorter times to market.
  • Middle management: cost reduction through more efficient workflows.
  • Content creators: eliminating tiresome manual chores and learning new skills for career longevity.

Your well-selected tool will make it easier to justify process changes to all parties, but it is not going to introduce itself to the different stakeholders, explain its value to them, or train users.

That’s why your content strategy team’s soft skills—particularly in communication—are as important as the tool itself.


Greatest hits for your listening content strategy pleasure

February 10, 2014 by

Transitioning to new publishing processes? Release your greatest hits collection first!

Fortunately for the vocally challenged like myself, I’m not talking about songs. I’m talking about a compendium of samples representing the content moving into the new processes.

On content strategy implementations, the lack of a good file testbed is a big obstacle to thoroughly testing how well new processes work. You can use sample files provided with your new tools, but how well do those samples correspond to your content and requirements? Not at all, based on my implementation experiences.

So, it’s up to you to create a useful, relevant greatest hits collection.

Here are a few tips for developing your collection:

  • Album cover for Bach's Greatest Hits

    flickr: bjornmeansbear

    If you have content for multiple audiences, collect samples for all audiences. For example, if you have content for users and administrators, pull some sections for both groups. It’s likely that content for different audiences contains unique constructs you need to maintain in your new processes.

  • Identify common content elements as well as outliers. You probably have a core group of styles, formatting, or elements that occurs across all information types. That core will be easier to identify. What’s not as easy to figure out is what outliers you need to preserve as you move forward. Are special constructs merely overrides that rogue writers created to do things their way, or do they provide value worthy of consideration for the new workflow?
  • Album cover for Donna Summer's On the Radio

    flickr: exquisitur

    Work with someone experienced in the new workflow to adapt your samples for the new processes. As part of your move to another workflow, you may have hired someone experienced with the new tools, or maybe you have a consultant on board to help with the transition. It’s critical that a seasoned user of your new processes have a lot of input into moving your samples from the old process to the new workflow: creating testbed files from samples is not just a matter of conversion. For example, if you are moving from desktop publishing to an XML-based workflow, there are multiple combinations of XML elements you could use to create a valid version of a particular sample. However, valid content doesn’t always equate with best practices. It takes an experienced user to know the difference.

  • Exact re-creation of your samples in the new workflow isn’t always the right goal. If you’re working in a regulated industry, you probably don’t have a lot of wiggle room in how to present information. Standards dictate organization, appearance, and so on. Your sample files should therefore look the same in both old and new processes. If you’re not constrained by regulations, however, a slavish devotion to the old way of doing things may not serve you well. Evaluation and guidance from a third party—a new employee or a consultant—can help you figure out what’s working in your old content and should be preserved (and what should be banished forever).

Have you released a set of greatest hits files? Please leave your tips in the comments.

“You don’t own me—or your content!”: the motivated consumer’s mantra

January 13, 2014 by

I love Downton Abbey. I love my Honda Fit.

And I will consume content about those things—even when their creators would prefer I not.

Today’s digital world means that information is global. Sure, ITV can release Downton Abbey in the UK during the last quarter of a year, and PBS can rebroadcast it in the US just a few weeks later. But if ITV and PBS think they can keep the show from American audiences during the initial UK broadcasts, they are very mistaken.

I saw information about the fourth season of Downton Abbey in my Facebook news feed while it was airing in the UK, and headlines about the show from UK-based sites made their way into my RSS feeds. Also, I’ve heard it’s not too hard to find the latest episodes on various not-entirely-legal file sharing sites. Die-hard fans in the US aren’t going to let intellectual property concerns block their immediate access to the Dowager Countess’s sharp tongue and poor Edith‘s latest jilting. Many folks over here watch the show pretty much in real-time as it airs in the UK, even though I’m sure PBS would strongly prefer that Americans watch the official US broadcasts—which seem to correspond with pledge drive season (ahem).

Meanwhile, in Japan, Honda released the third generation of its compact hatchback, the Fit (known as the Jazz in some markets),  in September. That new model won’t be available in the US until later this year, and Honda just launched a site to give US residents a glimpse of the new model. If I kindly give Honda my email address and phone number, they will send me more information on the new model. Oh really, Honda?

I don’t need to cough up my personal information to see photos and specs for the new Fit. I can check out non-Honda sites and blogs (such as this post from July 2013) to get information on the car and what I can expect in the version released in the US.

As content creators and managers, we have to realize that motivated consumers are going to ferret out information through unofficial (and even legally dubious) channels—particularly in situations where releases are staggered across different geographical markets. While there are legitimate reasons for releasing products at different times across world markets (and localization lag time is not a good reason, BTW), our product and content strategies must account for those who really want information—and don’t give one whit if it comes first from an unofficial source.

You cannot control the flow of content once it’s out there or pretend like it doesn’t exist because you didn’t release it. Copyright issues aside, you can’t hold on to antiquated notions about “owning” information in the Internet age. Consumers will speed right by you if you’re not giving them the information they want when they want it—and they may never turn back to your official content again.

P.S. My apologies to Lesley Gore for appropriating the title of her hit song:

Marginalizing tech comm with four little words

December 16, 2013 by

“I’m just the writer.”

For your 2014 New Year’s resolution, please stop yourself from verbalizing those words if they pop into your head. I ask this as someone who has both thought and said (doh!) those very words, especially during my early tech writing career.

Many companies are grappling with a common problem in their technical content. The content covers the what but it is light on the why and how. As a result, frustrated customers call support and create a financial double-whammy: a great deal of money is wasted on shallow, unhelpful technical content, and that costly failure is compounded by the additional support costs.

One way to deepen the context in your content is by providing rich, real-world examples that illustrate the why and how. Unfortunately, the only way you can develop those examples is by truly understanding the products you’re documenting.

Does this mean you need to become a product developer? Nope. But you do need to communicate and collaborate with product developers/SMEs more on their level. These days, a lot of SMEs are being asked to contribute content, so it’s not unreasonable for you to contribute your brainpower to a deeper understanding of your employer’s products.

So, next time you feel yourself flailing in a mire of technical detail about the product you’re documenting, take a deep breath and fight the temptation to fall into the trap of “I’m just a writer.” You must be more more than a stenographer and desktop publisher for product developers. Don’t let anyone—particularly yourself—marginalize tech writing in such a manner. If we act (or are merely viewed) as stenographers, there is little value placed on the content we create.

And that is when tech comm becomes expendable.

Cover from record for practicing stenography. Shows record player, typewriter, and rotary phone.

Stenography in tech comm is as forward-thinking as record players, typewriters, and rotary phones (flickr: epiclectic).

Are you ready to rumble for your content strategy?

November 19, 2013 by

If you can’t handle some rough-and-tumble adversity, you are not ready to manage the implementation of a new content strategy.

Implementing new processes of any kind is rarely a pleasant experience. Even the most meticulous planning won’t eliminate every bump (or enormous sinkhole) in the road. HR consultant Bruce Clarke says:

A normal person sees struggle or failure and averts their eyes. They want neither to be a witness nor part of the cure. They are simply grateful it was someone else.

That means you need to be one of those abnormal managers who is willing to address struggle head-on, even when it is tempting to take the easier route of avoiding difficulty or conflict.

Rock'em Sock'em Robots photo

Flickr: Jeff Sandquist

What’s your biggest adversary in the ring of content strategy implementation? New tools and technology are certainly formidable challengers, especially when you’re just learning about them as you are evaluating them. It’s very easy to get overwhelmed with tools, but you can rely on the advice of a consultant to coach you through the tool rounds of your content strategy fight.

As tough as new technology can be, don’t fall into the trap of thinking that tools are your biggest challenge. People are.

In general, people in professional environments do not like change. They become proficient in the current processes and comfortable with routine. So comfortable, in fact, they often can’t see how the inefficiencies of current processes do not support the greater business goals of the company.

Managing people’s resistance to change is by far the most important thing you will do during your content strategy implementation; conflicts will inevitably arise as changes are discussed and then put in place. You can address those challenges with:

If you go into the ring without these things, you’re going to find yourself knocked out in a very early round.

Years ago, a coworker at another job said to me, “People! Who needs ‘em?!?” after witnessing some colleagues behaving badly.  Well, as the manager of an implementation project, you need people, even if their behavior is sometimes less than stellar. Your colleagues can become your biggest advocates and evangelize process change to those who don’t buy in early on.

With additional advocates communicating about—and fighting for—the implementation, you can more easily overcome resistance and win your content strategy fight.

Impressions of the tcworld conference from a jet-lagged mind

November 11, 2013 by


That’s my first impression of the tcworld conference, from which I just returned. I’m still jet-lagged from my trip, but I wanted to briefly share my experiences with those—especially from the US—who are considering attending in the future.

  • Even if you are warned ahead of time that the event is big, you still will be overwhelmed by its sheer size. We heard there were roughly 3900 attendees at the tcworld/tekom/trade show events. (See Kai Weber’s blog for an explanation of tcworld vs. tekom and the trade show.) That number is 4 to 10 times the number of attendees I usually see at US-based conferences. The number of exhibitors and halls for vendor booths is also way beyond what I see at US-based tech comm conferences. The booths are big and elaborate, and some featured bartenders and baristas serving drinks. There was even a blimp floating around.
  • You’ll learn about vendors you know nothing about. Take a look at the list of vendors attending, and you’ll quickly realize there are different ecosystems of tools and vendors in Europe and Asia than the US. (Yes, there is some overlap with the US, but not as much as you might think.) After one of the workshops Sarah O’Keefe and I did, I talked to an attendee who knew nothing about Scriptorium and what we do. It was a humbling and eye-opening experience. Never, ever assume everyone knows—or even cares—about what your company does.
  • The focus on standards is much greater in Europe and Asia than in the US. There were many presentations devoted to different standards that can affect tech comm, and I had never heard of many of them. The presentations I attended on standards were not particularly exciting, but I needed to attend sessions on topics that were new to me.
  • Learning about and experiencing other cultures is as important as attending the event. You can learn a lot about different cultures by merely talking to vendors and participants about topics other than tech comm. Also, I recommend that you make time to visit the city around you. Yes, the conference schedule is very full, but you can have dinner out during the evening (or maybe even miss a particular time slot at the conference so you can walk around the city during the day). I walked around Wiesbaden in the late afternoons just to soak up the city a bit. I was fortunate to have a free Saturday after the conference to visit the nearby city of Mainz, which has a beautiful, 1000-year-old cathedral and the Gutenberg Museum. Being inside a building that’s stood for a millenium should give anyone pause, but it was particularly affecting to me as a citizen of the US, where our historical buildings are generally less than 300 years old.

Special thanks to everyone who gave me really great advice before I left for the conference. I was glad to meet many of you face-to-face.

P.S. Ellis Pratt, I never saw a Flachspüler, and I can’t say I’m unhappy about that!

Help this first-time tcworld attendee, please!

October 29, 2013 by

Whew! I’m just back from the excellent LavaCon event in Portland. I have (mostly) recovered from that trip, so now I’m focusing on the upcoming tcworld conference in Wiesbaden, Germany. And I need your help!

tcworld 2013 logoNext week will be my first visit to tcworld (and to Germany). Veteran tcworld attendees are accustomed to seeing Sarah O’Keefe there,  and Sarah’s already given me some great pointers on what to expect. I’d like to get some advice from you, too, on:

  • Choosing sessions. Do you have a strategy for picking sessions? What’s on your must-see list?
  • Visiting the trade show. What should I expect from vendors? I’m bracing myself for a bit of cultural shock on two fronts. Scriptorium won’t have a booth at this event, so I won’t have my usual booth duties. Also, I’ve heard booths are a bit more elaborate at tcworld than many of the events I attend in the US.
  • Networking. I’m attending the International Networking Dinner on Wednesday, where I’m sure I’ll meet many, many people. Any other networking suggestions?
  • What to wear. Any article of clothing you wished you had brought (or left at home)? I’ve seen photos of past tcworld events, and it looks like tcworld attendees dress a notch more professionally than those at US-based tech comm events, where I see more casual attire. Is my assessment accurate?
  • Food, food, food. If you follow Scriptorium’s blog or my Twitter feed, you probably know I like to eat (and I’m partial to good pastries and chocolate). What culinary adventures do you recommend in the Wiesbaden area?
  • General travel advice. I’ve been to Europe before for business and vacation, but this will be my first visit to Germany. Any travel tips? (My years of studying Latin have helped me somewhat with Romance languages, but they won’t be so helpful with German!)

I look forward to meeting you next week—especially those I’ve known for years through blog interactions, Twitter, and webcast events but have never met in person. Also, I’ll be helping Sarah out during The Game of Content Strategy presentation, which runs on Wednesday and Thursday. Hope to see you there!

P.S. If you’d like to schedule a meeting with Sarah or me during the conference, send us a message through our contact form.