Feb 2018 Learning

Books Read (related to work/professional development/betterment):

Creativity, Inc.

The Mythical Man Month

Articles:

pm@olin 10 Most Likely to Succeed and pm@olin 11 Capstone

  1. “ A lot of being a PM is rolling with what doesn’t cost very much, and helps make the team happy. You don’t always get the most done by optimizing.”
  2. “For a PM, It’s figuring out how to find a little extra time for the easter egg. It’s doing the extra work to get a cool side project into the product. It’s helping someone else learn a new skill. It’s the thank you cards or the day off after shipping.”
  3. Sometimes something as simple as colored markets to annotate pros and cons helps whiteboarding

Manager Energy Drain

  1. You can color-code your calendar based on what mental energy you will need (eg. 1-on-1 brain, teaching brain, planning brain) to manage that piece and defrag accordingly
  2. The best give you can give direct reports is a messy unscoped project with a bit of safety net to teach them -> give them guidance
  3. Say no to focus energy – don’t be afraid to go back and say no

The MVP is dead. Long live the RAT.

  1. RAT = Risk Assumption Test – after MVP is not a product, but a way of testing whether you’ve found a problem worth solving. RAT emphasizes on building on what’s required to rest beyond your largest unknown
  2. All about rapid testing rather than creeping into perfect code, design, and danger of becoming a product
  3. It’s about maximizing discovery and removing temptations of putting resources on creating a more polished product

Scaling Agile At Spotify: An Interview with Henrik Kniberg

  1. “Autonomy is one of our guiding principles. We aim for independent squads that can each build and release products on their own without having to be tightly coordinated in a big agile framework. We try to avoid big projects altogether (when we can), and thereby minimize the need to coordinate work across many squads.”
  2. “By avoiding big projects, we also minimize the need to standardize our choice of tools.”
  3. The technical architecture is hugely important for the way we are organized. The organizational structure must play in harmony with the technical architecture. Many companies can’t use our way of working because their architecture won’t allow it.
    • We have invested a lot into getting an architecture that supports how we want to work (not the other way around); this has resulted in a tight ecosystem of components and apps, each running and evolving independently. The overall evolution of the ecosystem is guided by a powerful architectural vision.
    • We keep the product design cohesive by having senior product managers work tightly with squads, product owners, and designers. This coordination is tricky sometimes, and is one of our key challenges. Designers work directly with squads, but also spend at least 20% of their time working together with other designers to keep the overall product design consistent.”

Product Management Is Not Project Management

  1. Product management is not about making sure products ship on time – it’s about knowing the customer needs and defining the right product and evangelizing that internally
  2. Too often, Product Managers spend time writing specs, Gantt charts, and workflows instead of on customer problems, customer data, and articulating that to the company.
  3. Measuring Religiously means both analytics + talking to customers

When should you hire a Product Manager?

  1. Toxic things to a Product Management team: when it is too large and has overlaps in responsibility, it results in politics, land grabs for credit, and no clear owner on how t to make decisions
  2. Don’t hire until there’s a pain point – eg can’t prioritize backlog, slow shipping bc of mismatched priorities and poor communication between teams, people don’t know why they’re building what they’re building
  3. “My least favorite way to slice a Product team is “I’ll do the high level strategy and they’ll do details” — it makes it hard for the detail-level person to make good calls. It also makes it harder for the high level person to connect with the rest of the team.”

Continuous Improvement + Quality Assurance

  1. Minimum viable feature set: releasing a feature is decoupled from deploying code. Large features deployed piecemeal over time.
  2. Debugging is twice as hard as writing code in the first place. Focus less on the mitigation of large, catastrophic failures – optimize for recovery rather than failure prevention. Failure is inevitable.
  3. Exploratory testing requires an understanding of the whole system and how it serves a community of users. Customer Experience is as much about technology as it is about product requirements

Building Your Personal Brand Where You Work

  1. Make your boss aware of what you’re doing – women often doers who don’t make it a point to highlight their accomplishments or how busy they are at work. Great tool is informal email reports. Template can be: weekly wins, areas of improvement for my team, what was coming next week, what you need from boss.
  2. Build brand equity with coworkers, because you will need people to defend you. Being liked matters more sometimes. You want an ally at every level, your boss should respect you but it’s also important entry level employees respect you too.
  3. Keep track of your success, remember you wins. Eg. tracking weekly, monthly, bi-annual, annual wins

Product Manger versus Product Owner

  1. “Product Owner is a role you play on a Scrum team. Product Manager is the job”
  2. Product Owner should spend half the time talking to customers and half working with the team is an ideal but should vary. External v internal work will shift depending on maturity and success of product
  3. Product Managers in senior roles should concentrate on defining vision and strategy for teams based on market resarhc, company goals, and current state of products. The ones without Scrum teams or smaller teams can help validate or contribute to strategy fo future products.

How to Run an Effective Meeting

  1. Set the agenda so there is a compass for conversation. Start on time and tend on time.
  2. End with an action plan that has next steps.
  3. Be clear, light bulb or gun – you have an idea or you want people to do it. “Your job as a leader is to be right at the ending of the meeting, not the beginning of the meeting.” Let people speak so you’ve heard all facts and opinions.

Managing Software Engineers *This is totally an article clearly from 2002 and all problematic attitudes therein about not considering people might have things like families

  1. Create work environment where best programmers will be satisfied enough to stay and where average programmers become good
  2. “One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can expect to fall in line with a good strategy developed by someone else. As for the good programmers who are in fact supremely capable, there is no reason to expect consensus to form among them.”
  3. Ideals to steal
    1. people don’t do what they are told
    2. all performers get the right consequences every day
    3. small, immediate, certain consequences are better than large future uncertain ones
    4. positive reinforcement is more effective than negative reinforcement
    5. ownership leads to high productivity

The What, Why, and How of Master Data Management

  1. Five kinds of data in corporations:
    1. “Unstructured—This is data found in e-mail, white papers like this, magazine articles, corporate intranet portals, product specifications, marketing collateral, and PDF files.
    2. Transactional—This is data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and non-monetary interactions.
    3. Metadata—This is data about other data and may reside in a formal repository or in various other forms such as XML documents, report definitions, column descriptions in a database, log files, connections, and configuration files.
    4. Hierarchical—Hierarchical data stores the relationships between other data. It may be stored as part of an accounting system or separately as descriptions of real-world relationships, such as company organizational structures or product lines. Hierarchical data is sometimes considered a super MDM domain, because it is critical to understanding and sometimes discovering the relationships between master data.
    5. Master—Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types. For example, within people, there are customer, employee, and salesperson. Within things, there are product, part, store, and asset. Within concepts, there are things like contract, warrantee, and licenses. Finally, within places, there are office locations and geographic divisions. Some of these domain areas may be further divided. Customer may be further segmented, based on incentives and history. A company may have normal customers, as well as premiere and executive customers. Product may be further segmented by sector and industry. The requirements, life cycle, and CRUD cycle for a product in the Consumer Packaged Goods (CPG) sector is likely very different from those of the clothing industry. The granularity of domains is essentially determined by the magnitude of differences between the attributes of the entities within them.”
  2. Deciding what to manage it and how it should be managed depends on some of the following criteria: behavior (how it interacts with other data, eg customers buy product- which may be a part of multiple hierarchies describing how they’re sold), life cycle (created, read, updated, deleted, searched – a CRUD cycle), cardinality, lifetime, complexity, value, or volatility, reuse
  3. Master Data Management is the tech, tools, and processes required to create and maintain consistent and accurate lists of master data, including identifying sources of master data, analyzing metadata, appointing data stewards, data-governance program, developing master data model, toolset, infrastructure, generating and testing master data, modify producing and consuming systems, implementing maintenance processes, and creating Master List similar to ETL below:
    1. Normalize data formats
    2. Replace Missing values
    3. Stnadardize Values
    4. Map Attributes
    5. Needs versioning and auditing

Treehouse Learning:  

Object-Oriented-Javascript

  • An object is a container for values in the form of properties and functionality in the form of methods
    • Methods on values can return objects, but they don’t have to return anything at all
  • Accessing or assigning properties is known as getting and setting
  • Native Objects: no matter where your JavaScript programs are run, it will have these objects eg. number, string, object, boolean
  • Host Objects: provided by the host environment, eg. the browser, such as document, console, or element
  • Own Objects: created in own programming eg. characters in a game
  • Objects hide complexity and organize code – known as encapsulation
  • An object literal holds information about a particular thing at a given time – it stores the state of a thing.

Eg.

var person = {
            name: “Lauren”,
            treehouseStudent: true,
            “full name”: “Lauren Smith”
}

Access using dot notation or square brackets

person.name;
person.treehouseStudent;
person[“name”]
person[“treehouseStudent”]
person[“full name”]
  • Each key is actually a string, but Javascript interpreter interprets them as a string
  • Encapsulating code into a single block allows us to keep state and behaviors for a particular thing in one place and code becomes more maintainable

Adding method to an object

var contact = {
  fullName: function printFullName() {
  var firstName = "Andrew";
  var lastName = "Chalkley";
  console.log(firstName + " " + lastName);
  }
}

Anonymous Function

var contact = {
  fullName: function() {
    var firstName = "Andrew";
    var lastName = "Chalkley";
    console.log(firstName + " " + lastName);
  }
}

We don’t know the name of variable to access its properties. Depending on where and how a function is called, this can be different things. Think of this as owner of function, eg. the object of method that is called.

Eg.

var dice = {
            sides: 6,
            roll: function() {
                var randomNumber = Math.floor(Math.random() * this.sides) + 1; // this means object literal of dice in this case
                console.log(randomNumber);
            }
}

var dice10 = {
            sides: 10,
            roll: function() {
                 var randomNumber = Math.floor(Math.random() * this.sides) + 1; // refers to dice10 variable
                 console.log(randomNumber);

            }

}

Object  literals are great for one off objects, if you want to make multiple objects of one type you need constructor functions:

  • Constructor functions describe how an object should be created
  • Create similar objects
  • Each object created is known as an instance of that object type

Constructor function example and new contact instances (an instance is the specific realization of a particular type or object)

Function Contact(name, email) {
    this.name = name;
    this.email = email;
}

var contact = new Contact(“Andrew”, “andrew@andrew.com”);
var contact2 = new Contact(“Bob”, “bb@andrew.com”);

You can create as many object of same type as you like, eg. real world example of:

Media Player

  • Playlist object (initialized by constructor function)
  • Song objects
Advertisements

Dec 2017 Learning

Less reading and off-time Treehouse learning this month. Want to timebox at least 10-15 minutes a day for these.

Treehouse AJAX Basics:

  • Make sure classes correspond with html
  • Use removeClass() say after something, like a button, is selected so not all the buttons are selected for example
  • Passing data to set-up API example:
$(document).ready(function(){

  $('button').click(function () {

    $("button").removeClass("selected");

    $(this).addClass("selected");

    var flickerAPI = "http://api.flickr.com/services/feeds/photos_public.gne?jsoncallback=?"; // adding JSON callback to query string

    var animal = $(this).text(); // this refers to button and text() gets text from html element

    var flickrOptions = {

      tags: animal,

      format: "json"

    };

    function displayPhotos(data) {

      var photoHTML = '<ul>';

      $.each(data.items, function(i, photo) {

          photoHTML += '<li class="grid-25 tablet-grid-50">';

          photoHTML += '<a href="' + photo.link + '" class="image">';

          photoHTML += '<img src="' + photo.media.m + '"></a></li>';

      });// loop through the array applying the callbackfunction

      photoHTML += '</ul>';

      $('#photos').html(photoHTML);

    }

    $.getJSON(flickerAPI, flickrOptions, displayPhotos); // three arguemnts, URL to resource, data we want to send with URL, callback function

  }); // function will run each time button is clicked

});

Treehouse UX Basics Tools UX-ers Use

  • Card Sorting: all different pieces of content on card and ask users to group the cards. Optimal Sort or Remote Search can be used to do remote.
  • Search Logs: understand what users are looking for
  • Content Inventories: Excel, etc. so there’s one way to look at all it
  • Beyond Philosophy defines UX as “an interaction between an organization and a customer as perceived through a customer’s conscious and subconscious mind. It is a blend of an organization’s rational performance, the sense stimulated, and the emotions evoked and intuitively measured against customer expectations across all moments of contact.”
  • Customer or User Journeys – Mapping out phases of customer’s journey and touchpoints. Identify opportunities, etc. through this process
  • Flow Diagrams: Steps user take
  • Wireframes: Diagrams or blueprints to show information relationships on pages and views
  • Comps: Showing details of specific moment of context. Think wireframes + aesthic
  • Prototypes: Show working relationships, aesthetic, and interactivity
  • Usability Testing
    • Moderating means there’s a facilitator asking questions and assigning questions
    • Unmoderated: puts together tasks while users go on their own

Treehouse UX Basics: Strategic UX

  • UX as a strategic initiative: see it at organizational or strategic level rather than immediate goals for users and see how important a task is to overall company, eg. how does getting auto quotes impact overall org’s bottom line?
  • UXers and non-UXers alike don’t agree on how to define UX
  • Your value is partnering with business and technology to emphasize with users and creates better experience and better user loyalty that brings more to bottom line
  • Selling UX means 1) Understanding what your business and technology partners value 2) Describe to them how UX meets those values in tailored responses to them by finding root causes, eg. what are the roots of wanting conversion rates. Don’t explain hows of UX but the Whys so you’re not an expense but a necessity

How to Build an Engineering Culture that Focuses on Impact

  1. Share with the engineers the value they’re creating, even if it’s “grungy but critical tasks” to let them know they’re being valued at the company
  2. Daniel Pink argues motivation comes from three key elements: autonomy, mastery, and purpose
  3. “Shape your culture through conversations and stories,” simply writing values doesn’t really mean anything

13 tips for product leaders on distributed teams

  1. Have an insider on your leadership team that can bridge cultural gaps and understand context of both languages and cultures and can mentor colleagues on both sides when it comes to improving communication
  2. Geographic gaps can multiply specialization gaps, eg business versus R&D that is compounded with distance and cultural differences
  3. If your engineers and business people look down on each other it’s your fault, create transparency and appreciation: “It might seem irrelevant to show your messaging and positioning documents to engineering or to show complex technology architecture to your sales people, but trust me, people learn to appreciate the challenges of the different roles when you surface the complexity. Animosity among colleagues usually stems from a general lack of understanding. Let members of each team shine and teams will show each other more support and respect.”

Three questions to ask yourself, before speaking to your users

  1. “What do you need to learn?”
    1. The big picture questions: who are customers, what’s their biggest problem, what do they want?
  2. “What do we need to learn right now to make progress?”
    1. Outcome of research that immediate action can be taken on
  3. “What’s the best way to learn?”
    1. Focus on doing minimum effort or method (interview versus user test) to learn

pm@olin Metrics (Class 8)

Continuous Improvement

  • PMs can create detailed factual timeline for post mortems – everyone should add what’s missing and note patterns as well as things done well and things that can improve on next time

PM Hack Panel Notes

Two weeks ago, I got to go PM Hack for a hot second, a hackathon for PMs and aspiring PMs put together by Jason Shen and Johanna Beyenbach and hosted by Wayup. I’m really bummed I actually only got to stay for maybe half the day because my actual PM job called me in on a Sunday, but it was definitely unique and one of the cooler initiatives I’ve seen to get people’s hands dirty on Product Management work. In a previous life, I’ve gone to hackathons as a developer, and there is something really inspiring, educational, and rewarding about working with a group of strangers to create something workable in a matter of hours or days.

One thing I did get to stay for an enjoy was a panel by some esteemed folks in the business so to speak – so I thought I’d put down my notes here to keep top of mind:

pmhackpanel.jpg

Some awesome Product Managers: Elan Miller (Midnight), Inga Chen (Squarespace), Lauren Ulmer (Dormify), and Joan Huang (Flatiron Health)

  • Emotional intelligence > IQ in PM roles
  • You need to understand yourself and your vision first
  • Constant tension at work between tending to firedrills v longer range thinking -> one key to working on this is working internal marketing for buy-in on longer term strategy
  • Good pms are always obsessing or communicating and good listening
  • Status update at right level of context – know how to communicate to junior level devs to executives
  • Saying no is a part of your job
  • Your job is to also bring the team and org together
  • Be cognizant of what step of the product life cycle are you able to work in and think about what is possible to change and is it possible
  • Team Cultures (build it out) + Users (joy)
  • Managing different dependencies across teams is key
  • Your job is to also define and interpret metrics correctly
  • The bigger the org the more stakeholder communication versus direct time to users
  • Be careful not to over optimize for the negative vocal batch of users versus the majority of users
  • As with everything, it’s right place right time with right skill set so you gotta angle to make to happen
  • GV Design Sprint can be a useful problem solving process
  • When you’re interviewing for a PM job: communicate you know a company’s business when you interview :
    • Mini deck to intro yourself, how you can solve company’s problem, and show you’ve done your hw and are more than your resume
    • Understand levers to business model (how does business makes money)
    • Apply to fewer jobs and make sure you’re interested in problems the product is trying to solve
    • Find side projects outside of your typical product development life cycle
    • Treat yourself as a product
    • Having a POV and being polarizing can be an advantage
    • Remember you can help them with particular problem you’re trying to solve even if you aren’t from that vertical – you could be bringing a fresh perspective to their problems

Oct Learning

Just my “three key points” notes from various reading I thought was work helpful this month:

PSFK Advertising Playbook Overview

  1. Experiential marketing now is the most critical tool
  2. Shift from ads to customer relationships and decline of online ads
  3. Emotional connections realign brands -> engineered enjoyment, contextual calibration, and third space communities are opportunities

 

Knowns vs Unknowns — Are you building a successful company or just typing?

  1. First known unknown is that you envision a product that solves a problem that a small group of users have
  2. Engineer’s primary job isn’t really writing code per se, but improving product for you users
  3. “What I often hear from CEOs is that “my CTO thinks we need to rebuild the backend so it’s scaleable.” The reality is that if you haven’t yet solved for the product’s scaleable and repeatable growth, you don’t know what the backend needs to be. If you’ve hired people that care more about the programming languages/frameworks and not the KPIs of your product, you’ll constantly have this internal battle. Remind them that writing software is the easy part. Building a company that scales isn’t.”

6 lessons learned about technical debts management in Silicon Valley

  1. Product always needs to be improved and have tech debts happening at once (80/20 rule)
  2. Top Down vision on the importance of these debts “It is not about the money you can make, it is about the money you won’t lose”
  3. Before you kill features, identify who are using it, find an alternative, and explain why you are killing a feature

IGNORE EVERYTHING BETWEEN THE CLOUDS AND DIRT

  • “This is because the vast majority of people tend to play the middle—they focus on the vague minutiae that doesn’t matter”
  • Two things happen when you’re too focused on the middle:
    • You’re only successful to a certain level and then hit a plateau
    • You get stuck in one of two extremes: you get stuck either because you become too romantic on ideals and neglect the skills you need to execute or you get tied up in minutiae or politics and lose sight of the bigger picture.

Unit Economics

  1. “Unit economics are the direct revenues and costs associated with a particular business model expressed on a per unit basis.” Eg Lifetime Value, Customer Acquisition Cost (CPA)
  2. What you want to do as a product manager is increase average rev per user (ARPU), increase customer lifetime, and drive expansion revenue from existing cusotmers
  3. Make sure you know what your most profitable segment is and what their composite is of the user base

pm@olin: Buildiing (Class 5)

  1. Understand your personal work and productivity style
  2. Understand the style of your team and tailor your project management to the team – being cognizant of your personal style
  3. Understand your software processes (eg. Waterfall or Agile) and bug triage

Offshore Development: Pluses and Minuses for Product Managers

  1. Hard part is to learn and understand the team and learn what makes them tick and how you can leverage all this and control for issues such as different work cultures and different accents over conference phones
  2. Get to know them and make sure they know you
  3. Keep them informed, establish routines (especially communicating with remote team lead and holding them accountable, hold all-team meetings semi-frequently), and leverage tools

How we develop great PM / Engineering relationships at Asana

  1. Semi-formalized way for sharing leadership and credit
  2. Remember mantra product owns the problems and engineering owns solutions
  3. ‘Clarify roles and reinforce them with mutual respect’

Learning Tracking September 2017

I’m trying to give myself at least half an hour during the workdays (or at least blocking two hours or so a week at least) to learn something new – namely taking classes on Treehouse, which I still have a membership to, reading job related articles, and reading job-related books. Tracking notables here as a self commitment and to retain in memory.

Treehouse

UX Basics Key Takeaways

  • Gather data about user behaviors, goals, and needs
    • Do this with user interviews, quant data (logs and analytics), and surveys
    • Be sure to analyze behavior types, and not just audience segments
  • Always answer the Q: “What is it the product we are working on provides for this behavior type?”
  • Manage content inventory: What exists (eg form values), gaps, and analyze

Ajax Handling Errors Key Takeaways

  • XHR request object contains important info about errors

Articles + Three Takeaways

Paying Down Your Technical Debt

  1. “If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets.”
  2. “Accumulated technical debt becomes a major disincentive to work on a project. It’s a collection of small but annoying things that you have to deal with every time you sit down to write code. But it’s exactly these small annoyances, this sand grinding away in the gears of your workday, that eventually causes you to stop enjoying the project.”
  3. Becomes a source of fear, dread, and loathing for teams so you should periodically service your debt

Evidence Based Scheduling

  1. Break tasks into hours (nothing longer than 16 hours) so it forces you to figure out what to do
  2. Keep timesheets tracking data for historical use
  3. Simulate the future

“But you can never get 4n from n, ever, and if you think you can, please email me the stock symbol for your company so I can short it.”

Reddit and Facebook Veteran On How to Troubleshoot Troublemakers aka “Debugging Coders”

  1. Job is not getting stuff to do people for you, it’s figuring out how to do something together.
  2. ‘The exact behaviors that make it so that the organization can stay alive, move fast, be scrappy can be exactly the same actions that cause a negative disruption later in the life of your company,” says Blount. “Troublemaking brings signs of large tectonic shifts, releasing pressure into the atmosphere. Specific rumblings are almost all borne fundamentally of some kind of frustration: moving too fast, not moving fast enough, taking too few or too many risks. These are signals — and opportunities — to assess underlying changes and growth in an organization.”’
  3. For nostalgia junkies (people who like the company that ‘way it use to be’), focus on the question: “What about next week bothers you?” and for the Trend Chasers – gotta measure the risks, what happens with this route over the next year, deploying it and rolling it out?

How do managers* get stuck?

  1. Failing to manage down: need to delegate, train team, pay attention to process, and say no
  2. Failing to manage sideways: build peer relationships, look for additional tasks, create a vision, become someone you’d like to report to
  3. Failing to manage up: attend to details, complains but doesn’t fix, drags outside of comfort zone, show yourself professionally to higher ups

How do individual contributors get stuck?

  1. “Everyone has at least one area that they tend to get stuck on. An activity that serves as an attractive sidetrack. A task they will do anything to avoid.”
  2. “When you know how people get stuck, you can plan your projects to rely on people for their strengths and provide them help or even completely side-step their weaknesses. You know who is good to ask for which kinds of help, and who hates that particular challenge just as much as you do.”
  3. “Knowing the ways that you get hung up is good because you can choose to either a) get over the fears that are sticking you (lack of knowledge, skills, or confidence), b) avoid such tasks as much as possible, and/or c) be aware of your habits and use extra diligence when faced with tackling these areas.”

Run Towards Something, Not Away. Learning from Talks Summary: C-Suite Meet with Jacki Kelley, COO, Bloomberg Media

I went to the C-Suite Meet with Jacki Kelley, Chief Operating Officer, Bloomberg Media with She Runs months ago in May, but I’ve thought a lot about her advice and carried these notes in my bag and mentally for the last few months.

The biggest takeaway, “Run towards something and not away.”  

This year, I had the opportunity to buy a dream co-op in NYC and job opportunities that would have paid more than I am making now. I walked away from those because deep down I knew it wasn’t the right thing to do, remembering these words and with the encouragement of friends and mentors. It was really difficult, especially as a daughter of immigrants and as someone who never thought I’d have what I have now and these opportunities. Sometimes the opportunities are wrong. Listen to your gut.

Much better opportunities and life paths have presented themselves to me in the interim, and I’m so glad I did the hard thing to walk away.

This piece by public intellectual Ta-Nehisi Coates resonates me with a lot:

Some people come up expecting to win. We came up hoping not to lose. Even in victory, the distance between expectation and results is dizzying for both. The old code remains a part of you, and with it comes a particular strain of impostor syndrome. You have learned another language, but your accent betrays you. And there are times when you wonder if the real you is not here among the professionals, but out there in the streets.

Obviously, I have to caveat that the specific experience he writes about has clear differences from mine, I’m from a much more privileged context, but it expresses the disorientation of how I feel in my circumstances now as Manhattan professional versus what my life could have easily been had I taken a few wrong turns and people didn’t intervene at key points in my life. (And to all the Women of Color who might be out there reading this, yes I still feel like I don’t fit in these spaces everyday, and probably never will. I still do it for the culture though).

My mentor told me in my moments of self-doubt this year, “There’s better for you. And you deserve it.”

I think most of us at least moderately-successful professionals will come upon these inflection points, where you can feel like you need to check-off certain life boxes (degree, house, ring, kids) or are presented with opportunities that are good for the money, but don’t feel right. Most people chose to do what they think should do because of societal or cultural expectations, because it’s hard to walk away from that. I’ve done that before, taken jobs to just to get away from a current situation, and and almost did all that again this year, but I’m glad I held out for the better even though it’s caused considerable existential dread, Asian guilt, and feeling of being ungrateful, especially in these sour times we live in politically and economically.

Some other key points from the talk/handwriting clarification:

  • She also mentioned “Life is not a to do list. Smell the roses.” Cliché, but at this phase of my life and career, I’m no longer in my frenetic twenties grasping at opportunity, but rather settling into a life and career that’s a marathon and not a sprint, and to enjoy the journey.
    • Also be there for the stuff that matters and plan out personal and professional life in tandem. She specifically mentioned planning out having kids (this isn’t something that’s a make or break for me), but we have all different milestones and wants to not be neglected
  • Sponsors v Mentors: need to find both. Sponsors are those people who advocate for you in your company or industry. Coaches/Mentors are your sounding boards and give advice, etc
  • Build cultures and processes to remove obstacles and allow people to do their best work
  • Understand people’s desires in a company and try to align with your goals and that of the organization
  • Ask yourself, how have you invested in someone you believe in?
  • Pick Learning > Promotion
  • Find work you love with people you love to work with
  • Connecting data, communication, and media is the key to survival for agencies (I’m not as bullish on this one and the agency model as it is, but it’s an insight worth thinking about)

Weekly Data Decomp: Country Quiz

Weekly data visualization decomps to keep a look out for technique and learning.

This week is the Guardian’s How Well Do You Know Your Country Quiz

Decomposition of a Visualization:

  • What are the:
    • Variables (Data points, where they are, and how they’re represented):
      • Numerical values on a x-axis scale using position
      • Lines showing gap in perception
    • Data Types (Quantitative, Qualitative, Categorical, Continuous, etc.):
      • Continuous
    • Encodings (Shape, Color, Position, etc.):
      • Position
      • Line Length
      • Color Hue for position
  • What works well here?
    • Showing difference between three possibilities
  • What does not work well and what would I improve?
    • Being able to compare with a filter of different countries side-by-side
  • What is the data source?  Do I see any problems with how it’s cited/used?
    • Ipsos Mori survey
  • Any other comments about what I learned?
    • I like how this is a combination of what would traditionally be a survey or quiz with data visualization elements for interactivity and exploration