FEEDS

Feeds on Writing Effectively

Feeds on Blogging Effectively

  • Thu, 22 Aug 2019 13:30:11 +0000: The Untapped Power of Vulnerability & Transparency in Content Strategy

    In marketing, transparency and vulnerability are unjustly stigmatized. The words conjure illusions of being frightened, imperfect, and powerless. And for companies that shove carefully curated personas in front of users, little is more terrifying than losing control of how people perceive the brand.

    Let’s shatter this illusioned stigma. Authentic vulnerability and transparency are strengths masquerading as weaknesses. And companies too scared to embrace both traits in their content forfeit bona fide user-brand connections for often shallow, misleading engagement tactics that create fleeting relationships.

    Transparency and vulnerability are closely entwined concepts, but each one engages users in a unique way. Transparency is how much information you share, while vulnerability is the truth and meaning behind your actions and words. Combining these ideas is the trick to creating empowering and meaningful content. You can’t tell true stories of vulnerability without transparency, and to be authentically transparent you must be vulnerable.

    To be vulnerable, your brand and its content must be brave, genuine, humble, and open, all of which are traits that promote long-term customer loyalty. And if you’re transparent with users about who you are and about your business practices, you’re courting 94 percent of consumers who say they’re more loyal to brands that offer complete openness and 89 percent of people who say they give transparent companies a second chance after a bad experience.

    For many companies, being completely honest and open with their customers—or employees, in some cases—only happens in a crisis. Unfortunately for those businesses, using vulnerability and transparency only as a crisis management strategy diminishes how sincere they appear and can reduce customer satisfaction.

    Unlocking the potential of being transparent and vulnerable with users isn’t a one-off tactic or quick-fix emergency response tool—it’s a commitment to intimate storytelling that embraces a user’s emotional and psychological needs, which builds a meaningful connection between the storyteller and the audience.

    The three storytelling pillars of vulnerable and transparent content

    In her book, Braving the Wilderness, sociologist Brené Brown explains that vulnerability connects us at an emotional level. She says that when we recognize someone is being vulnerable, we invest in their story and begin to develop an emotional bond. This interwoven connection encourages us to experience the storyteller’s joy and pain, and then creates a sense of community and common purpose among the person being vulnerable and the people who acknowledge that vulnerability.

    Three pillars in a company’s lifecycle embrace this bond and provide an outline for telling stories worthy of a user’s emotional investment. The pillars are:

    • the origins of a company, product, idea, or situation;
    • intimate narratives about customers’ life experiences;
    • and insights about product success and failure.

    Origin stories

    An origin story spins a transparent tale about how a company, product, service, or idea is created. It is often told by a founder, CEO, or industry innovator. This pillar is usually used as an authentic way to provide crisis management or as a method to change how users feel about a topic, product, or your brand.

    Customers’ life experiences

    While vulnerable origin stories do an excellent job of making users trust your brand, telling a customer’s personal life story is arguably the most effective way to use vulnerability to entwine a brand with someone’s personal identity.

    Unlike an origin story, the customer experiences pillar is focused on being transparent about who your customers are, what they’ve experienced, and how those journeys align with values that matter to your brand. Through this lens, you’ll empower your customers to tell emotional, meaningful stories that make users feel vulnerable in a positive way. In this situation, your brand is often a storytelling platform where users share their story with the brand and fellow customers.

    Product and service insights

    Origin stories make your brand trustworthy in a crisis, and customers’ personal stories help users feel an intimate connection with your brand’s persona and mission. The last pillar, product and service insights, combines the psychological principles that make origin and customer stories successful. The outcome is a vulnerable narrative that rallies users’ excitement about, and emotional investment in, what a company sells or the goals it hopes to achieve.

    Vulnerability, transparency, and the customer journey

    The three storytelling pillars are crucial to embracing transparency and vulnerability in your content strategy because they let you target users at specific points in their journey. By embedding the pillars in each stage of the customer’s journey, you teach users about who you are, what matters to you, and why they should care.

    For our purposes, let’s define the user journey as:

    • awareness;
    • interest;
    • consideration;
    • conversion;
    • and retention.

    Awareness

    People give each other seven seconds to make a good first impression. We’re not so generous with brands and websites. After discovering your content, users determine if it’s trustworthy within one-tenth of a second.

    Page design and aesthetics are often the determining factors in these split-second choices, but the information users discover after that decision shapes their long-term opinions about your brand. This snap judgement is why transparency and vulnerability are crucial within awareness content.

    When you only get one chance to make a positive first impression with your audience, what content is going to be more memorable?

    Typical marketing “fluff” about how your brand was built on a shared vision and commitment to unyielding customer satisfaction and quality products? Or an upfront, authentic, and honest story about the trials and tribulations you went through to get where you are now?

    Buffer, a social media management company that helped pioneer the radical transparency movement, chose the latter option. The outcome created awareness content that leaves a positive lasting impression of the brand.

    In 2016, Joel Gascoigne, cofounder and CEO of Buffer, used an origin story to discuss the mistakes he and his company made that resulted in laying off 10 employees.

    In the blog post “Tough News: We’ve Made 10 Layoffs. How We Got Here, the Financial Details and How We’re Moving Forward,” Gascoigne wrote about Buffer’s over-aggressive growth choices, lack of accountability, misplaced trust in its financial model, explicit risk appetite, and overenthusiastic hiring. He also discussed what he learned from the experience, the changes Buffer made based on these lessons, the consequences of those changes, and next steps for the brand.

    Gascoigne writes about each subject with radical honesty and authenticity. Throughout the article, he’s personable and relatable; his tone and voice make it obvious he’s more concerned about the lives he’s irrevocably affected than the public image of his company floundering. Because Gascoigne is so transparent and vulnerable in the blog post, it’s easy to become invested in the narrative he’s telling. The result is an article that feels more like a deep, meaningful conversation over coffee instead of a carefully curated, PR-approved response.

    Yes, Buffer used this origin story to confront a PR crisis, but they did so in a way that encouraged users to trust the brand. Buffer chose to show up and be seen when they had no control over the outcome. And because Gascoigne used vulnerability and transparency to share the company’s collective pain, the company reaped positive press coverage and support on social media—further improving brand awareness, user engagement, and customer loyalty.

    However, awareness content isn’t always brand focused. Sometimes, smart awareness content uses storytelling to teach users and shape their worldviews. The 2019 State of Science Index is an excellent example.

    The annual State of Science Index evaluates how the global public perceives science. The 2019 report shows that 87 percent of people acknowledge that science is necessary to solve the world’s problems, but 33 percent are skeptical of science and believe that scientists cause as many problems as they solve. Furthermore, 57 percent of respondents are skeptical of science because of scientists’ conflicting opinions about topics they don’t understand.

    3M, the multinational science conglomerate that publishes the report, says the solution for this anti-science mindset is to promote intimate storytelling among scientists and layfolk.

    3M creates an origin story with its awareness content by focusing on the ins and outs of scientific research. The company is open and straightforward with its data and intentions, eliminating any second guesses users might have about the content they’re digesting.

    The company kicked off this strategy on three fronts, and each storytelling medium interweaves the benefits of vulnerability and transparency by encouraging researchers to tell stories that lead with how their findings benefit humanity. Every story 3M tells focuses on breaking through barriers the average person faces when they encounter science and encouraging scientists to be vulnerable and authentic with how they share their research.

    First, 3M began a podcast series known as Science Champions. In the podcast, 3M Chief Science Advocate Jayshree Seth interviews scientists and educators about the global perception of science and how science and scientists affect our lives. The show is currently in its second season and discusses a range of topics in science, technology, engineering, and math.

    Second, the company worked with science educators, journalist Katie Couric, actor Alan Alda, and former NASA astronaut Scott Kelly to develop the free Scientists as Storytellers Guide. The ebook helps STEM researchers improve how and why they communicate their work with other people—with a special emphasis on being empathetic with non-scientists. The guide breaks down how to develop communications skills, overcome common storytelling challenges, and learn to make science more accessible, understandable, and engaging for others.

    Last, 3M created a film series called Beyond the Beaker that explores the day-to-day lives of 3M scientists. In the short videos, scientists give the viewer a glimpse into their hobbies and home life. The series showcases how scientists have diverse backgrounds, hobbies, goals, and dreams.

    Unlike Buffer, which benefits directly from its awareness content, 3M’s three content mediums are designed to create a long-term strategy that changes how people understand and perceive science, by spreading awareness through third parties. It’s too early to conclude that the strategy will be successful, but it’s off to a good start. Science Champions often tops “best of” podcast lists for science lovers, and the Scientists as Storytellers Guide is a popular resource among public universities.

    Interest

    How do you court new users when word-of-mouth and organic search dominate how people discover new brands? Target their interests.

    Now, you can be like the hundreds of other brands that create a “10 best things” list and hope people stumble onto your content organically and like what they see. Or, you can use content to engage with people who are passionate about your industry and have genuine, open discussions about the topics that matter to you both.

    The latter option is a perfect fit for the product and service insights pillar, and the customers’ life experiences pillar.

    To succeed in these pillars you must balance discussing the users’ passions and how your brand plays into that topic against appearing disingenuous or becoming too self-promotional.

    Nonprofits have an easier time walking this taut line because people are less judgemental when engaging with NGOs, but it’s rare for a for-profit company to achieve this balance. SpaceX and Thinx are among the few brands that are able to walk this tightrope.

    Thinx, a women’s clothing brand that sells period-proof underwear, uses its blog to generate awareness, interest, and consideration content via the customers’ life experiences pillar. The blog, aptly named Periodical, relies on transparency and vulnerability as a cornerstone to engage users about reproductive and mental health.

    Toni Brannagan, Thinx’s content editor, says the brand embraces transparency and vulnerability by sharing diverse ideas and personal experiences from customers and experts alike, not shying away from sensitive subjects and never misleading users about Thinx or the subjects Periodical discusses.

    As a company focused on women’s healthcare, the product Thinx sells is political by nature and entangles the brand with themes of shame, cultural differences, and personal empowerment. Thinx’s strategy is to tackle these subjects head-on by having vulnerable conversations in its branding, social media ads, and Periodical content.

    “Vulnerability and transparency play a role because you can’t share authentic diverse ideas and experiences about those things—shame, cultural differences, and empowerment—without it,” Brannagan says.

    A significant portion of Thinx’s website traffic is organic, which means Periodical’s interest-driven content may be a user’s first touchpoint with the brand.

    “We’ve seen that our most successful organic content is educational, well-researched articles, and also product-focused blogs that answer the questions about our underwear, in a way that’s a little more casual than what’s on our product pages,” Brannagan says. “In contrast, our personal essays and ‘more opinionated’ content performs better on social media and email.”

    Thanks in part to the blog’s authenticity and open discussions about hard-hitting topics, readers who find the brand through organic search drive the most direct conversions.

    Conversations with users interested in the industry or topic your company is involved in don’t always have to come from the company itself. Sometimes a single person can drive authentic, open conversations and create endearing user loyalty and engagement.

    For a company that relies on venture capital investments, NASA funding, and public opinion for its financial future, crossing the line between being too self-promotional and isolating users could spell doom. But SpaceX has never shied away from difficult or vulnerable conversations. Instead, the company’s founder, Elon Musk, embraces engaging with users interests in public forums like Twitter and press conferences.

    Twitter thread showing an exchange between Elon Musk and a user

    Musk’s tweets about SpaceX are unwaveringly authentic and transparent. He often tweets about his thoughts, concerns, and the challenges his companies face. Plus, Musk frequently engages with his Twitter followers and provides candid answers to questions many CEOs avoid discussing. This authenticity has earned him a cult-like following.

    Elon Musk gives an honest, if not flattering, response on Twitter to a user

    Musk and SpaceX create conversations that target people’s interests and use vulnerability to equally embrace failure and success. Both the company and its founder give the public and investors an unflinching story of space exploration.

    And despite laying off 10 percent of its workforce in January of 2019, SpaceX is flourishing. In May 2019, its valuation had risen to $33.3 billion and reported annual revenue exceeded $2 billion. It also earned global media coverage from launching Musk’s Tesla Roadster into space, recently completed a test flight of its Crew Dragon space vehicle, and cemented multiple new payload contracts.

    By engaging with users on social media and through standard storytelling mediums, Thinx and SpaceX bolster customer loyalty and brand engagement.

    Consideration

    Modern consumers argue that ignorance is not bliss. When users are considering converting with a brand, 86 percent of consumers say transparency is a deciding factor. Transparency remains crucial even after they convert, with 85 percent of users saying they’ll support a transparent brand during a PR crisis.

    Your brand must be open, clear, and honest with users; there is no longer another viable option.

    So how do you remain transparent while trying to sell someone a product? One solution employed by REI and Everlane is to be openly accountable to your brand and your users via the origin stories and product insights pillars.

    REI, a national outdoor equipment retailer, created a stewardship program that behaves as a multifaceted origin story. The program’s content highlights the company’s history and manufacturing policies, and it lets users dive into the nitty-gritty details about its factories, partnerships, product production methods, manufacturing ethics, and carbon footprint.

    Screenshot of the Collaborating for Good website

    REI also employs a classic content hub strategy to let customers find the program and explore its relevant information. From a single landing page, users can easily find the program through the website’s global navigation and then navigate to every tangential topic the program encompasses.

    REI also publishes an annual stewardship report, where users can learn intimate details about how the company makes and spends its money.

    Screenshot of REI's stewardship report

    Everlane, a clothing company, is equally transparent about its supply chain. The company promotes an insider’s look into its global factories via product insights stories. These glimpses tell the personal narratives of factory employees and owners, and provide insights into the products manufactured and the materials used. Everlane also published details of how they comply with the California Transparency in Supply Chains Act to guarantee ethical working conditions throughout its supply chain, including refusing to partner with human traffickers.

    Screenshot of Everlane's page about the factory in Lima

    The crucial quality that Everlane and REI share is they publicize their transparency and encourage users to explore the shared information. On each website, users can easily find information about the company’s transparency endeavors via the global navigation, social media campaigns, and product pages.

    The consumer response to transparent brands like REI and Everlane is overwhelmingly positive. Customers are willing to pay price premiums for the additional transparency, which gives them comfort by knowing they’re purchasing ethical products.

    REI’s ownership model has further propelled the success of its transparency by using it to create unwavering customer engagement and loyalty. As a co-op where customers can “own” part of the company for a one-time $20 membership fee, REI is beholden to its members, many of which pay close attention to its supply chain and the brands REI partners with.

    After a deadly school shooting in Parkland, Florida, REI members urged the company to refuse to carry CamelBak products because the brand’s parent company manufactures assault-style weapons. Members argued the partnership violated REI’s supply chain ethics. REI listened and halted orders with CamelBak. Members rejoiced and REI earned a significant amount of positive press coverage.

    Conversion

    Imagine you’ve started incorporating transparency throughout your company, and promote the results to users. Your brand also begins engaging users by telling vulnerable, meaningful stories via the three pillars. You’re seeing great engagement metrics and customer feedback from these efforts, but not much else. So, how do you get your newly invested users to convert?

    Provide users with a full-circle experience.

    If you combine the three storytelling pillars with blatant transparency and actively promote your efforts, users often transition from the consideration stage into the conversion state. Best of all, when users convert with a company that already earned their trust on an emotional level, they’re more likely to remain loyal to the brand and emotionally invested in its future.

    The crucial step in combining the three pillars is consistency. Your brand’s stories must always be authentic and your content must always be transparent. The outdoor clothing brand Patagonia is among the most popular and successful companies to maintain this consistency and excel with this strategy.

    Patagonia is arguably the most vocal and aggressive clothing retailer when it comes to environmental stewardship and ethical manufacturing.

    In some cases, the company tells users not to buy its clothing because rampant consumerism harms the environment too much, which they care about more than profits. This level of radical transparency and vulnerability skyrocketed the company’s popularity among environmentally-conscious consumers.

    In 2011, Patagonia took out a full-page Black Friday ad in the New York Times with the headline “Don’t Buy This Jacket.” In the ad, Patagonia talks about the environmental toll manufacturing clothes requires.

    “Consider the R2 Jacket shown, one of our best sellers. To make it required 135 liters of water, enough to meet the daily needs (three glasses a day) of 45 people. Its journey from its origin as 60 percent recycled polyester to our Reno warehouse generated nearly 20 pounds of carbon dioxide, 24 times the weight of the finished product. This jacket left behind, on its way to Reno, two-thirds [of] its weight in waste.”

    The ad encourages users to not buy any new Patagonia clothing if their old, ratty clothes can be repaired. To help, Patagonia launched a supplementary subdomain to its e-commerce website to support its Common Thread Initiative, which eventually got rebranded as the Worn Wear program.

    Patatgonia’s Worn Wear subdomain gets users to engage with the company about causes each party cares about. Through Worn Wear, Patagonia will repair your old gear for free. If you’d rather have new gear, you can instead sell the worn out clothing to Patagonia, and they’ll repair it and then resell the product at a discount. This interaction encourages loyalty and repeat brand-user engagement.

    In addition, the navigation on Patagonia’s main website practically begs users to learn about the brand’s non-profit initiatives and its commitment to ethical manufacturing.

    Screenshot of Patagonia's page on environmental responsibility

    Today, Patagonia is among the most respected, profitable, and trusted consumer brands in the United States.

    Retention

    Content strategy expands through nearly every aspect of the marketing stack, including ad campaigns, which take a more controlled approach to vulnerability and transparency. To target users in the retention stage and keep them invested in your brand, your goal is to create content using the customers’ life experiences pillar to amplify the emotional bond and brand loyalty that vulnerability creates.

    Always took this approach and ended up with one of its most successful social media campaigns.

    An Always ad portraying a determined girl holding a baseball

    In June 2014, Always launched its #LikeAGirl campaign to empower adolescent and teenage girls by transforming the phrase “like a girl” from a slur into a meaningful and positive statement.

    The campaign is centered on a video in which Always tasked children, teenagers, and adults to behave “like a girl” by running, punching, and throwing while mimicking their perception of how a girl performs the activity. Young girls performed the tasks wholeheartedly and with gusto, while boys and adults performed overly feminine and vain characterizations. The director then challenged the person on their portrayal, breaking down what doing things “like a girl” truly means. The video ends with a powerful, heart-swelling statement:

    “If somebody else says that running like a girl, or kicking like a girl, or shooting like a girl is something you shouldn’t be doing, that’s their problem. Because if you’re still scoring, and you’re still getting to the ball in time, and you’re still being first...you’re doing it right. It doesn’t matter what they say.”

    This customer story campaign put the vulnerability girls feel during puberty front and center so the topic would resonate with users and give the brand a powerful, relevant, and purposeful role in this connection, according to an Institute for Public Relations campaign analysis.

    Consequently, the #LikeAGirl campaign was a rousing success and blew past the KPIs Always established. Initially, Always determined an “impactful launch” for the video meant 2 million video views and 250 million media impressions, the analysis states.

    Five years later, the campaign video has more than 66.9 million views and 42,700 comments on YouTube, with more than 85 percent of users reacting positively. Here are a few additional highlights the analysis document points out:

    • Eighty-one percent of women ages 16–24 support Always in creating a movement to reclaim “like a girl” as a positive and inspiring statement.
    • More than 1 million people shared the video.
    • Thirteen percent of users created user-generated content about the campaign.
    • The #LikeAGirl program achieved 4.5 billion global impressions.
    • The campaign received 290 million social impressions, with 133,000 social mentions, and it caused a 195.3 percent increase in the brand’s Twitter followers.

    Among the reasons the #LikeAGirl content was so successful is that it aligned with Brené Brown’s concept that experiencing vulnerability creates a connection centered on powerful, shared emotions. Always then amplified the campaign’s effectiveness by using those emotions to encourage specific user behavior on social media.

    How do you know if you’re making vulnerable content?

    Designing a vulnerability-focused content strategy campaign begins by determining what kind of story you want to tell, why you want to tell it, why that story matters, and how that story helps you or your users achieve a goal.

    When you’re brainstorming topics, the most important factor is that you need to care about the stories you’re telling. These tales need to be meaningful because if you’re weaving a narrative that isn’t important to you, it shows. And ultimately, why do you expect your users to care about a subject if you don’t?

    Let’s say you’re developing a content campaign for a nonprofit, and you want to use your brand’s emotional identity to connect with users. You have a handful of possible narratives but you’re not sure which one will best unlock the benefits of vulnerability. In a Medium post about telling vulnerable stories, Cayla Vidmar presents a list of seven self-reflective questions that can reveal what narrative to choose and why.

    If you can answer each of Vidmar’s questions, you’re on your way to creating a great story that can connect with users on a level unrivaled by other methods. Here’s what you should ask yourself:

    • What meaning is there in my story?
    • Can my story help others?
    • How can it help others?
    • Am I willing to struggle and be vulnerable in that struggle (even with strangers)?
    • How has my story shaped my worldview (what has it made me believe)?
    • What good have I learned from my story?
    • If other people discovered this good from their story, would it change their lives?

    While you’re creating narratives within the three pillars, refer back to Vidmar’s list to maintain the proper balance between vulnerability and transparency.

    What’s next?

    You now know that vulnerability and transparency are an endless fountain of strength, not a weakness. Vulnerable content won’t make you or your brand look weak. Your customers won’t flee at the sight of imperfection. Being human and treating your users like humans isn’t a liability.

    It’s time for your brand to embrace its untapped potential. Choose to be vulnerable, have the courage to tell meaningful stories about what matters most to your company and your customers, and overcome the fear of controlling how users will react to your content.

    Origin story

    Every origin story has six chapters:

    • the discovery of a problem or opportunity;
    • what caused this problem or opportunity;
    • the consequences of this discovery;
    • the solution to these consequences;
    • lessons learned during the process;
    • and next steps.

    Customers’ life experiences

    Every customer journey narrative has six chapters:

    • plot background to frame the customer’s experiences;
    • the customer’s journey;
    • how the brand plays into that journey (if applicable);
    • how the customer’s experiences changed them;
    • what the customer learned from this journey;
    • and how other people can use this information to improve their lives.

    Product and service insights

    Narratives about product and service insights have seven chapters:

    • an overview of the product/service;
    • how that product/service affects users;
    • why the product/service is important to the brand’s mission or to users;
    • what about this product/service failed or succeeded;
    • why did that success or failure happen;
    • what lessons did this scenario create;
    • and how are the brand and its users moving forward.

    You have the tools and knowledge necessary to be transparent, create vulnerable content, and succeed. And we need to tell vulnerable stories because sharing our experiences and embracing our common connections matters. So go ahead, put yourself out into the open, and see how your customers respond.

  • Thu, 08 Aug 2019 13:45:20 +0000: An Essential Tool for Capturing Your Career Accomplishments

    Imagine you’re ready to apply for your next job. Like most busy professionals, you probably haven’t updated your résumé or your portfolio since you looked for your current job. 

    Now you need to update both, and you can’t remember what work you’ve done over the past few years. (In fact, you can barely remember what you’ve done over the past few months!)

    So you scramble to update your résumé with new content. Then you spend all weekend scraping together a new portfolio using screenshots of whatever work evidence you can find on your laptop. You submit the résumé and portfolio with your application, hoping you didn’t forget to include any major career milestones you achieved over the last few years. 

    This is the process most of us use to approach our job search. We wait until we’re ready to find a job, panic at our lack of résumé and portfolio, and pull together a “good enough” version of each for the job application. (Trust me, I’ve done this many times myself.)

    This is a stressful and ineffective way to approach a job search. There’s a much better approach you can take—and you can start working on it now, even if you’re not on the job market.

    The Career Management Document

    A Career Management Document (CMD) is a comprehensive collection of your résumé and portfolio content. It’s a document you update regularly, over time, with all the work you’ve done. 

    When you’re ready to apply for your next job, you’ll have all the résumé and portfolio pieces available in your CMD. All you need to do is assemble those pieces into résumé and portfolio documents, then send the documents off with your job application.

    I update my CMD about once a week. I start by reviewing evidence of my recent work. I review Slack messages, Basecamp posts, emails, and any other current work-related content. I write my accomplishments in the format of résumé bullets, using the framework of responsibilities and accomplishments from this Manager Tools podcast. Then I add those bullets to the CMD. 

    Here are some examples from my CMD:

    • Coached a student on writing a stronger portfolio story to showcase their advanced UX skills, resulting in the student getting a job interview.
    • Facilitated an end-of-study analysis in under 90 minutes to help the team synthesize user research data from 12 participants.
    • Led a remote retrospective with teams in two offices, developed actionable takeaways, and ended on time despite a delayed start.

    My CMD has several hundred résumé bullets, and it continues to grow. I organize content by year and by project. Within each project are responsibilities and accomplishments.

    I add any content to the CMD that might go into my résumé someday. I include everything I can think of, even if it seems insignificant or trivial at the time. 

    For example, I sometimes help with social media marketing at Center Centre, the UX design school where I’m a faculty member. I include it in my CMD. I don’t plan to pursue social media marketing as a career, but it may be relevant to a future job. Who knows—I may apply to work for an organization that makes social media marketing software someday. In that case, my social media experience could be relevant.

    Include portfolio artifacts with your CMD

    In addition to capturing bullets for my résumé, I capture content for my portfolio. Each week, I gather screenshots of my work, photos of me working with the team, and any other artifacts I can find. I store them in an organized system I can reference later. 

    I also take brief notes about the work I did and store them with the artifacts. That way, if I look back at these materials a year from now, I’ll have notes about what I did during the project, reminding me of the details.

    For example, after I facilitated a user research analysis session late last year, I captured evidence of it for my portfolio. I included photos of the whiteboard where I recorded public notes during the session. I also captured brief notes about who attended the session, the date, and when it took place during the project. 

    You can use whatever tools you’d like to gather evidence of your work. I use Google Docs for the résumé portion of my CMD. I use Dropbox to store my portfolio artifacts. I create Dropbox folders with dates and project names that correspond to the contents of my CMD.


    Résumé content from my CMD. I wrote about coaching a student on crafting a presentation for her job interview. The highlighted areas are where I left comments reminding me of the details of the work. Note that some of the résumé bullets seem redundant, which is OK. When I create my next résumé, I’ll choose the most appropriate bullets.

    I took notes on a whiteboard while coaching the student. I stored a photo of the whiteboard in Dropbox in a folder named with the date of the work and a description of what I did.

    The key is to collect the evidence regularly and store it in an accessible, organized way that works for you. To know if you’re storing work evidence effectively, ask yourself, “Will I understand this CMD content a year from now based on how I’m capturing and storing it today?” If the answer is “yes,” you’re in good shape.

    Update your CMD regularly

    For the CMD to work when you need it, it needs to be comprehensive and up-to-date. As I mentioned before, I update my CMD once a week. I schedule thirty minutes on my calendar each week so I remember to do it. 

    Sometimes I have a busy week, and I can’t spend thirty minutes on my CMD. So I spend whatever amount of time I have. Some weeks, I only spend ten minutes. Ten minutes per week is better than zero minutes per week. 

    Occasionally, I don’t get a chance to update it because my week is so hectic. That’s OK because I’ll probably get to it the following week. 

    I recommend updating your CMD once a week and not once a month or once a quarter. If you wait even a month, you’ll have trouble remembering what you did three and a half weeks ago. Even worse, if you schedule a CMD update once a month and then miss it, you won’t get to it until the next month. That means you have to think back and remember two months of work, which is hard to do. 

    Updating your CMD every week, while the work is fresh in your mind, gets the best results.

    The CMD benefits you in additional ways

    The CMD can help you prepare for your job search beyond your résumé and your portfolio. 

    You can use it to prepare for a job interview. Since you’re capturing work evidence from each stage of the process in your CMD, you can use that evidence to remember what you did throughout a project. Then, you can craft a story about your role on that project. 

    Hiring managers love to hear stories about your work during job interviews. For instance, if you’re a designer, they want to know the journey you took during your design process, from the start of a project to the end. A detailed CMD will help you remember this process so you can share it in an interview. 

    I’ve even used my CMD to write blog posts. I’ve been blogging regularly for the past two years, and I often refer to my CMD to remember work experience I had that’s relevant to what I’m writing. When I wrote the article “How to Tell Compelling Stories During a UX Job Interview,” I used my CMD to remember interview preparation exercises I did with students. 

    The CMD can also help you track work accomplishments for your quarterly or annual performance reviews. Additionally, you can use it to write job ads when hiring for related roles on your team.

    Lastly, I find it rewarding to peruse my CMD now and then, especially when I look back at work I did over a year ago. The CMD serves as a record of all my professional accomplishments. This record helps me appreciate my professional growth because I see how far my skills have come over time.

    Learn more about the CMD from Manager Tools

    At Center Centre, we originally learned about the Career Management Document through the Manager Tools podcast series.

    Manager Tools’ podcasts explain how to use a CMD for your résumé. We expanded their approach to include portfolio work as well. I recommend listening to their podcasts about creating and maintaining your CMD:

    Prepare for your next job search now

    We tell our students at Center Centre that preparing for your next job search is a process that starts early. It’s like saving for retirement—the sooner you start saving money, the more likely you are to be prepared when the time comes. 

    Similarly, collecting résumé and portfolio content ahead of time will prepare you to find your next job whenever you’re ready to do so. It also prepares you for a sudden job termination like an unexpected layoff. If you lose your job without warning, you’ll likely be under a lot of stress to find a new position. Having a CMD ready will relieve the additional stress of building a résumé and portfolio from scratch. 

    If you don’t have a CMD yet, now is a great time to start one. Schedule 30 minutes this week to begin crafting your repository of work accomplishments. You’ll be glad you did when you seek your next job.

  • Thu, 01 Aug 2019 13:45:18 +0000: Getting to the Heart of Digital Accessibility

    Quick! Think of the word “developer” or “coder” — what’s the first thing that comes to mind? Maybe a whiteish male in his twenties living in a busy metropolis, wearing a nerdy t-shirt and hoodie? Someone a bit like Mark Zuckerberg? Or maybe a younger Bill Gates or Sergey Brin? Any of the dudes from the HBO series Silicon Valley, perhaps? Certainly no one like me.

    By tech standards, I’m old. I’m also female and a mother. I live in a midwestern town you’ve never heard of and will never visit — a town where the cows vastly outnumber the people. My hair color is (almost) natural and is no longer part of the ROYGBIV collection, so I have no perceived conference street cred. I own about a thousand geeky T-shirts, but never actually wear them in public, opting for more “girly” attire (or so was pointed out by a male colleague). On the surface, I look more suited to taking notes at a PTA meeting than writing code. I’m a bit of an outsider. A tech misfit.

    So when my 11-year-old daughter finished her recent coding camp and excitedly declared, “Now I’m a real developer, Mom, just like you!” there was the usual parent pride, but also a small piece of me that cringed. Because, as much as I support the STEM fields, and want the next generation of girls to be coding wizard-unicorn-ninjas, I really don’t want my own daughter to be a developer. The rationale behind this bold (and maybe controversial) statement comes from a place of protection. The tech world we live in today is far from perfect. I’ve endured my share of misogyny, self-doubt, and sexual harassment. Why wouldn’t I want to protect her from all of that?

    The (diversity) elephant in the (computer) room

    You’ve heard this story before: there is not enough diversity in tech. This puzzling trend seems to continue year after year, even though numerous studies show that by including more people from underrepresented communities, a company can increase its innovation, employee retention, and bottom line. Even with the recent push and supposed support for diversity and inclusivity from many Fortune 500 companies, women and female-identifying people still only hold 20% of all top tech jobs.

    The data from FY 2018 shows that the number of women in technical roles at three of the top tech giants was 24% for Adobe, 26% for Google, and 22% for Facebook. While these numbers show that there is still not enough representation for women, these numbers do reflect a slight increase from the previous year (FY 2017: Adobe 22%, Google 25%, Facebook 15%). But even with this upward trend of hiring women in tech roles, the marginal growth rate has not caught up with the real world. The tech workforce is seriously out of touch with reality if, in 2019, a demographic (women) that represents more than half the global population is still considered a minority.

    Sometimes this lack of diversity at the top level is blamed on a “pipeline” issue. The logic being: “If there are not enough girls who learn to code, then there will not be enough women who can code.” However, programs aimed at teaching girls how to code have skyrocketed in the past few years. Girls now make up about half of the enrollment in high-school coding classes and are scoring almost identically to their male classmates on standardized math and science tests, yet, young women make up only 18% of all Computer Science degrees. I have to wonder if this steep drop in interest has more to do with lack of representation in the tech sphere, than with girls and young women simply not being “smart enough” or “not interested” in working with code? At the very least, the lack of representation certainly doesn’t help.

    Of course, the diversity picture becomes even more abysmal when you consider other underrepresented groups such as people of color, people from the LGBTQ community, and people with disabilities. And while I really don’t like glossing over these deeper diversity issues in tech, because they are abundant and are much more grotesque failings than the male/female ratio, I also don’t feel qualified to speak about these issues. I encourage you to look to and value the voices of others who can speak with higher authority on these deeper diversity issues, such as Ire Aderinokun, Taelur Alexis, Imani Barbarin, Angie Jones, Fatima Khalid, Tatiana Mac, Charlie Owen, Cherry Rae, and so many others. And for those readers who are new to the topic of diversity in tech, watch Tatiana Mac’s recent conference talk How Privilege Defines Performance — it’s well worth the 35 minutes of your life.

    The four stages in the digital accessibility journey

    However you look at it, the numbers don’t lie. There are some pretty significant diversity issues in tech. So how do we fix this issue before the next wave of young developers join the tech workforce? Simple: teach developers to write accessible code.

    This may seem like a joke to some and stretch to others, but hear me out. When we talk about accessible code, what we are really talking about at its core is inclusiveness. The actual process of writing accessible code involves rules and standards, tests and tools; but inclusive development is more abstract than that. It’s a shift in thinking. And when we rethink our approach to development, we go beyond just the base level of simple code functionality. We instead think, how is this code consumed? How can we make it even more intelligible and easier for people to use? Inclusive development means making something valuable, not just accessible, to as many people as we can.

    That line of thinking is a bit abstract, so let’s go through an example. Let’s say you are tasked with updating the color contrast between the text on a webpage or app and the background. What happens at each stage in the accessibility journey?

    Stage 1: Awareness — You are brand new to digital accessibility and are still trying to understand what it is and how you can implement changes in your daily workflow. You may be aware that there is a set of digital accessibility guidelines that other developers follow, but you are a bit hazy on what it all means in a practical sense.

    Stage 2: Knowledge — You know a bit more about digital accessibility and feel comfortable using a few testing tools, so you run an automated accessibility test on your website and it flags a possible issue with the color contrast. Based on your awareness of the guidelines, you know the color contrast ratio between the text and the background needs to be a certain number and that you need a tool to test this.

    Stage 3: Practice — Feeling more confident in your knowledge of digital accessibility rules and best practices, you use a tool to measure the color contrast ratio between the text and the background. Then based on the output of the tool, you modify the hex code to meet the color contrast ratio guidelines and retest to confirm you have met the accessibility requirements for this issue.

    Stage 4: Understanding — You understand that the accessibility guidelines and tools are created with people in mind, and that code is secondary to all of that. One is the means, and the other is the end. In the color contrast example, you understand that people with low-vision or colorblindness need these color contrast changes in order to actually see the words on your web page.

    This is a bit of an oversimplification of the process. But I hope you get the gist — that there are different stages of digital accessibility knowledge and understanding. True beginners may not be to even stage one, but I am finding that group rarer and rarer these days. The word about digital accessibility seems to be out! Which is great; but that’s only the first hurdle. What I’m seeing now is that a lot of people stop at Stage 2: Knowledge or Stage 3: Practice — where you are aware of the digital accessibility guidelines, have some testing tools in your back pocket, and know how to fix some of the issues reported, but haven’t quite connected the dots to the humans they impact.

    From the standpoint of getting daily stuff done, stages two and three are okay stopping points. But what happens when the things you need to do are too complex for a quick fix, or you have no buy-in from your peers or management? I feel that once we get to Stage 4: Understanding, and really get why these kinds of changes are needed, people will be more motivated to make those changes regardless of the challenges involved. When you arrive at stage four, you have gone beyond knowing the basic rules, testing, and coding. You recognize that digital accessibility is not just a “nice to have” but a “must have” and it becomes about quality of life for real people. This is digital inclusion. This is something you can’t unsee, you can’t unlearn, and you can’t ignore.

    Making digital accessibility a priority — not a requirement

    In my role as an accessibility trainer, I like to kick-off each session with the question: “What are you hoping to learn today about digital accessibility?” I ask this question to establish a rapport with the audience and to understand where everyone is in their accessibility journey, but I am also evaluating the level of company and individual buy-in too. There is nothing worse than showing up to teach a group that does not care to be taught. If I hear the words “I am only here because I have to be” — I know it will be an uphill battle to get them anywhere close to Stage 4: Understanding, so I mentally regroup and aim for another stage.

    In my experience, when companies and their leaders say “Digital accessibility is a requirement,” nine times out of ten there is a motivating factor behind this sweeping declaration (for example, impending litigation, or at least the fear of it). When changes are framed as mandatory and packaged as directives from on high with little additional context, people can be resistant and will find excuses to fight or challenge the declaration, and any change can become an uphill battle. Calling something “mandatory” only speaks to Stage 1: Awareness.

    By swapping out one word from the original declaration and saying “Digital accessibility is a priority,” companies and their leaders have reframed the conversation with their employees. When changes are framed as “working towards a solution” and discussed openly and collaboratively, people feel like they are part of the process and are more open to embracing change. In the long run, embracing change becomes part of a company’s culture and leads to innovation (and, yes, inclusion) on all levels. Calling something a priority speaks to Stage 4: Understanding.

    Some of the excuses I often hear from clients for not prioritizing accessibility is that it is too difficult, too costly, and/or too time consuming — but is that really the case? In the same accessibility training, I lead an exercise where we look at a website with an accessibility testing tool and review any issues that came up. With the group’s help we plot out the “impact to user” versus the “remediation effort” on the part of the team. From group to group, while the plots are slightly different, one commonality is that close to 80% of the errors plotted fall into the quadrant of “simple to fix” for the team, but they also fall under “high impact” to the user. Based on this empirical data, I won’t buy the argument from clients who say that accessibility is too difficult and costly and time consuming anymore. It comes down to whether it’s a priority — for each individual and for the company as a whole.

    What will your coding legacy be?

    The infinite monkey theorem states that a monkey hitting keys at random on a typewriter for an infinite amount of time will eventually type any given text, such as the complete works of William Shakespeare. So by that same logic, a programmer hitting keys at random on a computer for an infinite amount of time will almost surely produce a website that is accessible. But where is the thought process? Where is the human element? While all the things we’ve already talked about — awareness, education, and prioritization of accessibility are important steps in making the digital world more inclusive to all — without intent, we are just going to keep randomly tapping away at our computers, repeating the same mistakes over and over again. The intent behind the code has to be part of the process, otherwise accessibility is just another task that has no meaning.

    Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

    Because when you strip away all the styles, all the mark-up, all the cool features from a website or app — what’s left? People. And honestly, the more I learn about digital accessibility, the more I realize it’s not about the code at all. Digital accessibility is rooted in the user; and, while I (and countless others) can certainly teach you how to write accessible code, and build you tools, patterns, and libraries to use, I realize we can’t teach you to care. That is a choice you have to make yourself. So think for a moment — what are you leaving the next generation of developers with all that inaccessible code you haven’t given much thought to? Is it the coding legacy you really want to leave? I challenge you to do better for my daughter, her peers, and for the countless others who are not fully represented in the tech community today.

  • Thu, 13 Jun 2019 13:30:28 +0000: Responsible JavaScript: Part II

    You and the rest of the dev team lobbied enthusiastically for a total re-architecture of the company’s aging website. Your pleas were heard by management—even up to the C-suite—who gave the green light. Elated, you and the team started working with the design, copy, and IA teams. Before long, you were banging out new code.

    It started out innocently enough with an npm install here and an npm install there. Before you knew it, though, you were installing production dependencies like an undergrad doing keg stands without a care for the morning after.

    Then you launched.

    Unlike the aftermath of most copious boozings, the agony didn’t start the morning after. Oh, no. It came months later in the ghastly form of low-grade nausea and headache of product owners and middle management wondering why conversions and revenue were both down since the launch. It then hit a fever pitch when the CTO came back from a weekend at the cabin and wondered why the site loaded so slowly on their phone—if it indeed ever loaded at all.

    Everyone was happy. Now no one is happy. Welcome to your first JavaScript hangover.

    It’s not your fault

    When you’re grappling with a vicious hangover, “I told you so” would be a well-deserved, if fight-provoking, rebuke—assuming you could even fight in so sorry a state.

    When it comes to JavaScript hangovers, there’s plenty of blame to dole out. Pointing fingers is a waste of time, though. The landscape of the web today demands that we iterate faster than our competitors. This kind of pressure means we’re likely to take advantage of any means available to be as productive as possible. That means we’re more likely—but not necessarily doomed—to build apps with more overhead, and possibly use patterns that can hurt performance and accessibility.

    Web development isn't easy. It’s a long slog we rarely get right on the first try. The best part of working on the web, however, is that we don’t have to get it perfect at the start. We can make improvements after the fact, and that’s just what the second installment of this series is here for. Perfection is a long ways off. For now, let’s take the edge off of that JavaScript hangover by improving your site’s, er, scriptuation in the short term.

    Round up the usual suspects

    It might seem rote, but it’s worth going through the list of basic optimizations. It’s not uncommon for large development teams—particularly those that work across many repositories or don’t use optimized boilerplate—to overlook them.

    Shake those trees

    First, make sure your toolchain is configured to perform tree shaking. If tree shaking is new to you, I wrote a guide on it last year you can consult. The short of it is that tree shaking is a process in which unused exports in your codebase don’t get packaged up in your production bundles.

    Tree shaking is available out of the box with modern bundlers such as webpack, Rollup, or Parcel. Grunt or gulp—which are not bundlers, but rather task runners—won’t do this for you. A task runner doesn’t build a dependency graph like a bundler does. Rather, they perform discrete tasks on the files you feed to them with any number of plugins. Task runners can be extended with plugins to use bundlers to process JavaScript. If extending task runners in this way is problematic for you, you’ll likely need to manually audit and remove unused code.

    For tree shaking to be effective, the following must be true:

    1. Your app logic and the packages you install in your project must be authored as ES6 modules. Tree shaking CommonJS modules isn’t practically possible.
    2. Your bundler must not transform ES6 modules into another module format at build time. If this happens in a toolchain that uses Babel, @babel/preset-env configuration must specify modules: false to prevent ES6 code from being converted to CommonJS.

    On the off chance tree shaking isn’t occurring during your build, getting it to work may help. Of course, its effectiveness varies on a case-by-case basis. It also depends on whether the modules you import introduce side effects, which may influence a bundler’s ability to shake unused exports.

    Split that code

    Chances are good that you’re employing some form of code splitting, but it’s worth re-evaluating how you’re doing it. No matter how you’re splitting code, there are two questions that are always worth asking yourself:

    1. Are you deduplicating common code between entry points?
    2. Are you lazy loading all the functionality you reasonably can with dynamic import()?

    These are important because reducing redundant code is essential to performance. Lazy loading functionality also improves performance by lowering the initial JavaScript footprint on a given page. On the redundancy front, using an analysis tool such as Bundle Buddy can help you find out if you have a problem.

    The Bundle Buddy utility demonstrating how much code is shared between bundles of JavaScript.
    Bundle Buddy can examine your webpack compilation statistics and determine how much code is shared between your bundles.

    Where lazy loading is concerned, it can be a bit difficult to know where to start looking for opportunities. When I look for opportunities in existing projects, I’ll search for user interaction points throughout the codebase, such as click and keyboard events, and similar candidates. Any code that requires a user interaction to run is a potentially good candidate for dynamic import().

    Of course, loading scripts on demand brings the possibility that interactivity could be noticeably delayed, as the script necessary for the interaction must be downloaded first. If data usage is not a concern, consider using the rel=prefetch resource hint to load such scripts at a low priority that won’t contend for bandwidth against critical resources. Support for rel=prefetch is good, but nothing will break if it’s unsupported, as such browsers will ignore markup they doesn’t understand.

    Externalize third-party hosted code

    Ideally, you should self-host as many of your site’s dependencies as possible. If for some reason you must load dependencies from a third party, mark them as externals in your bundler’s configuration. Failing to do so could mean your website’s visitors will download both locally hosted code and the same code from a third party.

    Let’s look at a hypothetical situation where this could hurt you: say that your site loads Lodash from a public CDN. You've also installed Lodash in your project for local development. However, if you fail to mark Lodash as external, your production code will end up loading a third party copy of it in addition to the bundled, locally hosted copy.

    This may seem like common knowledge if you know your way around bundlers, but I’ve seen it get overlooked. It’s worth your time to check twice.

    If you aren’t convinced to self-host your third-party dependencies, then consider adding dns-prefetch, preconnect, or possibly even preload hints for them. Doing so can lower your site’s Time to Interactive and—if JavaScript is critical to rendering content—your site’s Speed Index.

    Smaller alternatives for less overhead

    Userland JavaScript is like an obscenely massive candy store, and we as developers are awed by the sheer amount of open source offerings. Frameworks and libraries allow us to extend our applications to quickly do all sorts of stuff that would otherwise take loads of time and effort.

    While I personally prefer to aggressively minimize the use of client-side frameworks and libraries in my projects, their value is compelling. Yet, we do have a responsibility to be a bit hawkish when it comes to what we install. When we’ve already built and shipped something that depends on a slew of installed code to run, we’ve accepted a baseline cost that only the maintainers of that code can practically address. Right?

    Maybe, but then again, maybe not. It depends on the dependencies used. For instance, React is extremely popular, but Preact is an ultra-small alternative that largely shares the same API and retains compatibility with many React add-ons. Luxon and date-fns are much more compact alternatives to moment.js, which is not exactly tiny.

    Libraries such as Lodash offer many useful methods. Yet, some of them are easily replaceable with native ES6. Lodash’s compact method, for example, is replaceable with the filter array method. Many more can be replaced without much effort, and without the need for pulling in a large utility library.

    Whatever your preferred tools are, the idea is the same: do some research to see if there are smaller alternatives, or if native language features can do the trick. You may be surprised at how little effort it may take you to seriously reduce your app’s overhead.

    Differentially serve your scripts

    There’s a good chance you’re using Babel in your toolchain to transform your ES6 source into code that can run on older browsers. Does this mean we’re doomed to serve giant bundles even to browsers that don’t need them, until the older browsers disappear altogether? Of course not! Differential serving helps us get around this by generating two different builds of your ES6 source:

    • Bundle one, which contains all the transforms and polyfills required for your site to work on older browsers. You’re probably already serving this bundle right now.
    • Bundle two, which contains little to none of the transforms and polyfills because it targets modern browsers. This is the bundle you’re probably not serving—at least not yet.

    Achieving this is a bit involved. I’ve written a guide on one way you can do it, so there’s no need for a deep dive here. The long and short of it is that you can modify your build configuration to generate an additional but smaller version of your site’s JavaScript code, and serve it only to modern browsers. The best part is that these are savings you can achieve without sacrificing any features or functionality you already offer. Depending on your application code, the savings could be quite significant.

    A webpack-bundle-analyzer analysis of a project's legacy bundle (left) versus one for a modern bundle (right). View full-sized image.

    The simplest pattern for serving these bundles to their respective platforms is brief. It also works a treat in modern browsers:

    <!-- Modern browsers load this file: -->
    <script type="module" src="/js/app.mjs"></script>
    <!-- Legacy browsers load this file: -->
    <script defer nomodule src="/js/app.js"></script>

    Unfortunately, there’s a caveat with this pattern: legacy browsers like IE 11—and even relatively modern ones such as Edge versions 15 through 18—will download both bundles. If this is an acceptable trade-off for you, then worry no further.

    On the other hand, you'll need a workaround if you’re concerned about the performance implications of older browsers downloading both sets of bundles. Here’s one potential solution that uses script injection (instead of the script tags above) to avoid double downloads on affected browsers:

    var scriptEl = document.createElement("script");
    
    if ("noModule" in scriptEl) {
      // Set up modern script
      scriptEl.src = "/js/app.mjs";
      scriptEl.type = "module";
    } else {
      // Set up legacy script
      scriptEl.src = "/js/app.js";
      scriptEl.defer = true; // type="module" defers by default, so set it here.
    }
    
    // Inject!
    document.body.appendChild(scriptEl);

    This script infers that if a browser supports the nomodule attribute in the script element, it understands type="module". This ensures that legacy browsers only get legacy scripts and modern browsers only get modern ones. Be warned, though, that dynamically injected scripts load asynchronously by default, so set the async attribute to false if dependency order is crucial.

    Transpile less

    I’m not here to trash Babel. It’s indispensable, but lordy, it adds a lot of extra stuff without your ever knowing. It pays to peek under the hood to see what it’s up to. Some minor changes in your coding habits can have a positive impact on what Babel spits out.

    https://twitter.com/_developit/status/1110229993999777793

    To wit: default parameters are a very handy ES6 feature you probably already use:

    function logger(message, level = "log") {
      console[level](message);
    }

    The thing to pay attention to here is the level parameter, which has a default of “log.” This means if we want to invoke console.log with this wrapper function, we don’t need to specify level. Great, right? Except when Babel transforms this function, the output looks like this:

    function logger(message) {
      var level = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : "log";
    
      console[level](message);
    }

    This is an example of how, despite our best intentions, developer conveniences can backfire. What was a handful of bytes in our source has now been transformed into much larger in our production code. Uglification can’t do much about it either, as arguments can’t be reduced. Oh, and if you think rest parameters might be a worthy antidote, Babel’s transforms for them are even bulkier:

    // Source
    function logger(...args) {
      const [level, message] = args;
    
      console[level](message);
    }
    
    // Babel output
    function logger() {
      for (var _len = arguments.length, args = new Array(_len), _key = 0; _key < _len; _key++) {
        args[_key] = arguments[_key];
      }
    
      const level = args[0],
            message = args[1];
      console[level](message);
    }

    Worse yet, Babel transforms this code even for projects with a @babel/preset-env configuration targeting modern browsers, meaning the modern bundles in your differentially served JavaScript will be affected too! You could use loose transforms to soften the blow—and that’s a fine idea, as they’re often quite a bit smaller than their more spec-compliant counterparts—but enabling loose transforms can cause issues if you remove Babel from your build pipeline later on.

    Regardless of whether you decide to enable loose transforms, here’s one way to cut the cruft of transpiled default parameters:

    // Babel won't touch this
    function logger(message, level) {
      console[level || "log"](message);
    }

    Of course, default parameters aren’t the only feature to be wary of. For example, spread syntax gets transformed, as do arrow functions and a whole host of other stuff.

    If you don’t want to avoid these features altogether, you have a couple ways of reducing their impact:

    1. If you’re authoring a library, consider using @babel/runtime in concert with @babel/plugin-transform-runtime to deduplicate the helper functions Babel puts into your code.
    2. For polyfilled features in apps, you can include them selectively with @babel/polyfill via @babel/preset-env’s useBuiltIns: "usage" option.

    This is solely my opinion, but I believe the best choice is to avoid transpilation altogether in bundles generated for modern browsers. That’s not always possible, especially if you use JSX, which must be transformed for all browsers, or if you’re using bleeding edge language features that aren’t widely supported. In the latter case, it might be worth asking if those features are really necessary to deliver a good user experience (they rarely are). If you arrive at the conclusion that Babel must be a part of your toolchain, then it’s worth peeking under the hood from time to time to catch suboptimal stuff Babel might be doing that you can improve on.

    Improvement is not a race

    As you massage your temples wondering when this horrid JavaScript hangover is going to lift, understand that it’s precisely when we rush to get something out there as fast as we possibly can that the user experience can suffer. As the web development community obsesses on iterating faster in the name of competition, it’s worth your time to slow down a little bit. You’ll find that by doing so, you may not be iterating as fast as your competitors, but your product will be faster than theirs.

    As you take these suggestions and apply them to your codebase, know that progress doesn’t spontaneously happen overnight. Web development is a job. The truly impactful work is done when we’re thoughtful and dedicated to the craft for the long haul. Focus on steady improvements. Measure, test, repeat, and your site’s user experience will improve, and you’ll get faster bit by bit over time.

    Special thanks to Jason Miller for tech editing this piece. Jason is the creator and one of the many maintainers of Preact, a vastly smaller alternative to React with the same API. If you use Preact, please consider supporting Preact through Open Collective.

  • Thu, 06 Jun 2019 13:30:51 +0000: Resilient Management, An Excerpt

    In Tuckman’s Stages of Group Development, the Storming stage happens as a group begins to figure out how to work together. Previously, each person had been doing their own thing as individuals, so necessarily a few things need to be ironed out: how to collaborate, how to hit goals, how to determine priorities. Of course there may be some friction here!

    But even if your team doesn’t noticeably demonstrate this kind of internal Storming as they begin to gel, there might be some outside factors at play in your work environment that create friction. During times of team scaling and organizational change—the water we in the web industry are often swimming in—managers are responsible for things like strategy-setting, aligning their team’s work to company objectives, and unblocking the team as they ship their work.

    In addition to these business-context responsibilities, managers need to be able to help their teammates navigate this storm by helping them grow in their roles and support the team’s overall progress. If you and your teammates don’t adapt and evolve in your roles, it’s unlikely that your team will move out of the Storming stage and into the Norming stage of team dynamics.

    To spur this course-correction and growth in your teammates, you’ll end up wearing four different hats:

    • Mentoring: lending advice and helping to problem solve based on your own experience.
    • Coaching: asking open questions to help your teammate reflect and introspect, rather than sharing your own opinions or quickly problem solving.
    • Sponsoring: finding opportunities for your teammate to level up, take on new leadership roles, and get promoted.
    • Delivering feedback: observing behavior that is or isn’t aligned to what the team needs to be doing and sharing those observations, along with praise or suggestions.

    Let’s dive in to how to choose, and when to use, each of these skills as you grow your teammates, and then talk about what it looks like when teammates support the overarching direction of the team.

    Mentoring

    When I talk to managers, I find that the vast majority have their mentor hats on ninety percent of the time when they’re working with their teammates. It’s natural!

    In mentoring mode, we’re doling out advice, sharing our perspective, and helping someone else problem solve based on that information. Our personal experiences are often what we can talk most confidently about! For this reason, mentorship mode can feel really good and effective for the mentor. Having that mentor hat on can help the other person overcome a roadblock or know which next steps to take, while avoiding drastic errors that they wouldn’t have seen coming otherwise.

    As a mentor, it’s your responsibility to give advice that’s current and sensitive to the changing dialog happening in our industry. Advice that might work for one person (“Be louder in meetings!” or “Ask your boss for a raise!”) may undermine someone else, because members of underrepresented groups are unconsciously assessed and treated differently. For example, research has shown that “when women are collaborative and communal, they are not perceived as competent—but when they emphasize their competence, they’re seen as cold and unlikable, in a classic ‘double bind’”.

    If you are not a member of a marginalized group, and you have a mentee who is, please be a responsible mentor! Try to be aware of the way members of underrepresented groups are perceived, and the unconscious bias that might be at play in your mentee’s work environment. When you have your mentor hat on, do lots of gut checking to make sure that your advice is going to be helpful in practice for your mentee.

    Mentoring is ideal when the mentee is new to their role or to the organization; they need to learn the ropes from someone who has firsthand experience. It’s also ideal when your teammate is working on a problem and has tried out a few different approaches, but still feels stumped; this is why practices like pair coding can help folks learn new things.

    As mentors, we want our mentees to reach beyond us, because our mentees’ success is ultimately our success. Mentorship relationships evolve over time, because each party is growing. Imaginative, innovative ideas often come from people who have never seen a particular challenge before, so if your mentee comes up with a creative solution on their own that you wouldn’t have thought of, be excited for them—don’t just focus on the ways that you’ve done it or seen it done before.

    Managers often default to mentoring mode because it feels like the fastest way to solve a problem, but it falls short in helping your teammate connect their own dots. For that, we’ll look to coaching.

    Coaching

    In mentoring mode, you’re focused on both the problem and the solution. You’ll share what you as the mentor would do or have done in this situation. This means you’re more focused on yourself, and less on the person who is sitting in front of you.

    In coaching mode—an extremely powerful but often underutilized mode—you’re doing two primary things:

    1. Asking open questions to help the other person explore more of the shape of the topic, rather than staying at the surface level.
    2. Reflecting, which is like holding up a mirror for the other person and describing what you see or hear, or asking them to reflect for themselves.

    These two tools will help you become your teammate’s fiercest champion.

    Open Questions

    “Closed” questions can only be answered with yes or no. Open questions often start with who, what, when, where, why, and how. But the best open questions are about the problem, not the solution. Questions that start with why tend to make the other person feel judged, and questions that start with how tend to go into problem solving mode—both of which we want to avoid while in coaching mode.

    However, what questions can be authentically curious! When someone comes to you with a challenge, try asking questions like:

    • What’s most important to you about it?
    • What’s holding you back?
    • What does success look like?

    Let’s say my teammate comes to me and says they’re ready for a promotion. Open questions could help this teammate explore what this promotion means and demonstrate to me what introspection they’ve already done around it. Rather than telling them what I think is necessary for them to be promoted, I could instead open up this conversation by asking them:

    • What would you be able to do in the new level that you can’t do in your current one?
    • What skills are required in the new level? What are some ways that you’ve honed those skills?
    • Who are the people already at that level that you want to emulate? What about them do you want to emulate?

    Their answers would give me a place to start coaching. These questions might push my teammate to think more deeply about what this promotion means, rather than allowing them to stay surface level and believe that a promotion is about checking off a lot of boxes on a list. Their answers might also open my eyes to things that I hadn’t seen before, like a piece of work that my teammate had accomplished that made a huge impact. But most important, going into coaching mode would start a two-way conversation with this teammate, which would help make an otherwise tricky conversation feel more like a shared exploration.

    Open questions, asked from a place of genuine curiosity, help people feel seen and heard. However, if the way you ask your questions comes across as judgy or like you’ve already made some assumptions, then your questions aren’t truly open (and your teammate can smell this on you!). Practice your intonation to make sure your open questions are actually curious and open.

    By the way, forming lots of open questions (instead of problem solving questions, or giving advice) is tremendously hard for most people. Don’t worry if you don’t get the hang of it at first; it takes a lot of practice and intention over time to default to coaching mode rather than mentoring mode. I promise, it’s worth it.

    Reflections

    Just like open questions, reflections help the other person feel seen and heard, and to explore the topic more deeply.

    It’s almost comical how rarely we get the sense that the person we’re talking to is actively listening to us, or focusing entirely on helping us connect our own dots. Help your teammates reflect by repeating back to them what you hear them say, as in:

    • “What I’m hearing you say is that you’re frustrated with how this project is going. Is that right?”
    • “What I know to be true about you is how deeply you care about your teammates’ feelings.”

    In each of these examples, you are holding up a metaphorical mirror to your teammate, and helping them look into it. You can coach them to reflect, too:

    • “How does this new architecture project map to your goals?”
    • “Let’s reflect on where you were this time last year and how far you’ve come.”

    Occasionally, you might get a reflection wrong; this gives the other person an opportunity to realize something new about their topic, like the words they’re choosing aren’t quite right, or there’s another underlying issue that should be explored. So don’t be worried about giving a bad reflection; reflecting back what you’re hearing will still help your teammate.

    The act of reflecting can help the other person do a gut check to make sure they’re approaching their topic holistically. Sometimes the act of reflection forces (encourages?) the other person to do some really hard work: introspection. Introspection creates an opportunity for them to realize new aspects of the problem, options they can choose from, or deeper meanings that hadn’t occurred to them before—which often ends up being a nice shortcut to the right solution. Or, even better, the right problem statement.

    When you have your coaching hat on, you don’t need to have all the answers, or even fully understand the problem that your teammate is wrestling with; you’re just there as a mirror and as a question-asker, to help prompt the other person to think deeply and come to some new, interesting conclusions. Frankly, it may not feel all that effective when you’re in coaching mode, but I promise, coaching can generate way more growth for that other person than just giving them advice or sharing your perspective.

    Choose coaching when you’re looking to help someone (especially an emerging leader) hone their strategic thinking skills, grow their leadership aptitude, and craft their own path forward. Coaching mode is all about helping your teammate develop their own brain wrinkles, rather than telling them how you would do something. The introspection and creativity it inspires create deeper and longer-lasting growth.

    Sponsoring

    While you wear the mentoring and coaching hats around your teammates, the sponsor hat is more often worn when they’re not around, like when you’re in a 1:1 with your manager, a sprint planning meeting, or another environment where someone’s work might be recognized. You might hear about an upcoming project to acquire a new audience and recommend that a budding user researcher take it on, or you’ll suggest to an All Hands meeting organizer that a junior designer should give a talk about a new pattern they’ve introduced to the style guide.

    Sponsorship is all about feeling on the hook for getting someone to the next level. As someone’s sponsor, you’ll put their name in the ring for opportunities that will get them the experience and visibility necessary to grow in their role and at the organization. You will put your personal reputation on the line on behalf of the person you’re sponsoring, to help get them visible and developmental assignments. It’s a powerful tool, and the one most effective at helping someone get to the next level (way more so than mentoring or coaching!).

    The Center for Talent Innovation routinely measures the career benefits of sponsorship (PDF). Their studies have found that when someone has a sponsor, they are way more likely to have access to career-launching work. They’re also more likely to take actions that lead to even more growth and opportunities, like asking their manager for a stretch assignment or a raise.

    When you’re in sponsorship mode, think about the different opportunities you have to offer up someone’s name. This might look like:

    • giving visible/public recognition (company “shout outs,” having them present a project demo, thanking them in a launch email, giving someone’s manager feedback about their good work);
    • assigning stretch tasks and projects that are just beyond their current skill set, to help them grow and have supporting evidence for a future promotion; or
    • opening the door for them to write blog posts, give company or conference talks, or contribute open-source work.

    Remember that members of underrepresented groups are typically over-mentored, but under-sponsored. These individuals get lots of advice (often unsolicited), coffee outings, and offers to teach them new skills. But it’s much rarer for them to see support that looks like sponsorship.

    This isn’t because sponsors intentionally ignore marginalized folks, but because of in-group bias. Because of how our brains (and social networks) work, the people we’re closest to tend to look mostly like us—and we draw from that same pool when we nominate people for projects, for promotions, and for hires. Until I started learning about bias in the workplace, most of the people I sponsored were white, cisgender women, like myself. Since then, I’ve actively worked to sponsor people of color and nonbinary people. It takes effort and intention to combat our default behaviors—but I know you can do it!

    Take a look at the daily communications you participate in: your work chat logs, the conversations you have with others, the process for figuring out who should fix a bug or work on a new project, and the processes for making your teams’ work visible (like an architecture review, code review, launch calendar, etc.). You’ll be surprised how many moments there are to sponsor someone throughout an average day. Please put in the time and intention to ensure that you’re sponsoring members of underrepresented groups, too.

Trackback URL for this entry