Jon Plummer

On Friday last week I deleted a chunk of the wiki. All of the product management pages, in fact. The work of a team of fifteen, organizing and guiding the work of a hundred people, gone. I’ve managed to avoid being fired, so far. People have been very nice about this, so far. But I don’t expect their good will to last: as they trip over the lack of things that were once in place they will learn the painful extent of my big mistake.

There were many failures involved in this big mistake, but the biggest failure belongs to me.

What happened

The design team, which I lead, had been putting our recent work on the design system, user research, interaction guidelines, etc. in the product management space for quite a while now, but there was a disused old space that contained similar but outdated content, penned by past designers, that cluttered up search results and created confusion among the design and product teams. I was working through the contents of this area, moving some pages to the product management space and marking them as old work, archiving other pages, and deleting “stubs” (pages devoid of content) outright. So I was working in two spaces at once.

At some point the disused old space was effectively empty, so I thought I’d delete it. From the homepage of the disused space I went to space administration, and chose to delete the space. And since I had just done a lot of work there to clear it out, and thought of that work as now safe in the product management space, I didn’t pay super-close attention to the confirmation message that warned that the deletion was not reversible. But that confirmation was attempting to warn me that I was deleting the product management space. I blithely confirmed the deletion, then a progress bar appeared, and grew, and was not cancelable.

As the progress bar grew I realized what I had done and panic rose in my chest. I quickly opened a new window and quickly did an export of the product management space, which was in the process of being deleted. I got 22MB of data, so not nothing, but that export is likely partial; I have no idea how large a full export would have been.

Expecting that I had just caused my imminent firing, I immediately Slacked someone in IT for help, my VP of Product to tell her what I had done, and the product team as a whole to apologize and point out that I would do my best to find a solution. As I said, people have been very nice about this, so far. I hope I can act in such a way that preserves at least some of that good will.

I hope they reduce my rights on the system significantly.

Lessons for me

I was working in two spaces at once, so the likelihood of “pedal error,” choosing the wrong action believing it is the right one, was high.

I’ll probably never know if it was pedal error or a bug that caused the wrong space to be offered to me for deletion. I believed I had selected the correct space for deletion. But sure of myself in that moment I skimmed over the confirmation step. Others have had this same complaint, if the support site is to be believed, that they selected one space for deletion and were offered a different one. Even so, I should have:

• Read and heeded confirmation messages. Failing to do this was the core of my big mistake.
• Taken a moment before doing anything momentous or destructive. A bit of time can be room for your brain to catch up to your hands.
• Taken my own steps to make destructive acts recoverable. I could have done a full export of both spaces before deleting anything. Had I bothered to actually read the confirmation message I may have thought to do so. Had I paused I may have thought to do so. It would take only a few minutes and be free insurance against catastrophe.
• Made use of archival or “logical delete” rather than destructive processes. When available, archiving a page or a space or other record is inherently more recoverable than deleting. It’s not clear if this was an option in my case, but it’s a good idea. If you find you never visit these archived items, you can choose to delete them later.

I’m happy that I had already learned these lessons:

• Hang a lantern on your problem. Had I not started communicating immediately, I’m sure things would be much worse for me. Worse, had I said nothing, I would eventually have been found out and fired not for the mistake but for the cover-up. In my panic it did take a half a beat to recall this lesson.
• Form a plan with multiple paths to success. It’s not safe to rely on a single path to disaster recovery. How many paths to success can you think of? Can you pursue all of them? How can you maximize your chance of success? If you have just one plan, and it fails, then what?

Lessons for interfaces and systems

If you would like your system to be kind to me and other normal folks, you’ll want to arrange things so mistakes are harder to make, or easier to recover from, or both. There are a lot of things you can do, roughly in order from least to most difficult:

• Offer recovery preparation activities alongside the destructive action. It’s straightforward to add a reminder to make an export or backup to your confirmation message. Would it have helped me? Who can say.
• Offer recovery preparation activities alongside the confirmation message. It’s a little less straightforward to offer an export at the point of confirmation. But it’s not that hard, and that reminder will catch some folks before they make a mistake.
• Make confirmation of destructive acts require reading to complete. You’ve seen this in Figma and other places, where you are asked to type something to confirm the action. The best of these ask you to think a little bit; “Type the name of the space to confirm that you want to delete it” is better than “type DELETE to confirm that you want to delete this space” as it requires a bit more attention. In this case, a little cognitive load is your friend.
• Make lengthy or multi-step destructive acts cancelable. Even if part of the information is saved it is better than watching the system slowly put your mistake into practice with no recourse. In my case, deleting a space involves several transactions – making each page a hidden page, removing the association of the space with its home or overview page, deleting each page, then deleting the now empty space. Stopping at any point in that chain of events would have spared some fraction of the data.
• Offer archival or logical delete in addition to outright deletion. Users are more likely to mishandle their data if alternatives to deletion are not available.
• Offer archival or logical delete instead of outright deletion. Users can’t delete if they can’t delete This increases data storage costs, and signs you up to write more interfaces to browse and change the status of archived records, but major mistakes become minor ones.
• Automatically perform recovery preparation activities. An automatic export prior to deletion adds time and storage cost to the process, but can save someone’s day by giving them the tools needed to undo a mistake.
• Make destructive acts easily recoverable. This is the most expensive yet most polite way to handle user data. Let any act be undoable. It’s not easy to architect, much less to implement, but the level of comfort it offers to users is extreme. Mistakes in word processors used to be costly and painful, but today they are trivialities. And the effort it takes away from users is likely worth the design and engineering costs.

Lessons for organizations

A prior IT regime read about the backup practices of our vendor and felt that they were sufficient protection. They read that the vendor makes nightly backups and retains them for thirty days. But there they stopped reading, not noticing that these backups are not offered to clients and are only for vendor-level disaster recovery. So while a backup technically exists, it is no protection from client-caused mishaps. There are several lessons in this one fact:

• Do not expect your users not to make mistakes. See “lessons for me” above to learn of typical mistakes.
• Read the whole contract.
• Do not leave backup solely up to your vendor, even if their backup plan sounds adequate. if you aren’t in control of your data, you aren’t in control of your data.
• Do not believe you have a working backup unless you’ve practiced recovering via that backup. What does it take to recover from a disaster? How do you know? Are you really ready to accomplish this? One way to find out.
• Do not believe you have a working backup unless you’ve verified its contents. Ah, you have a backup. Your’e covered! Unless…drat, the backup is corrupted, or incomplete, or old because the job has been failing for a while, or a thousand other problems.

There’s also the small matter of roles and privileges:

• The less safe the data is, the fewer people should be allowed to harm it. No backup? Restrict deletion privileges to relatively inaccessible people, not day-to-day editors. Yes, they’ll grumble. But it is for their own good.

My plan, and what I’ve done so far

I’ve got a partial export, a backup locked up at the vendor that I allegedly do not have access to, an unknown level of inconvenience caused to coworkers, and an unknown amount of time and effort between now and whatever level of recovery I am able to effect. Above I mentioned having and putting into practice multiple paths to success. The possible paths to success seem to be

• restoring the export and finding out what is in it, in hopes that it meaningfully reduces the loss
• appealing to the vendor to have access to their backup, which should be complete
• scouring the existing IT infrastructure for any possible existing export or backup we might have

I am pursuing all of these in parallel. In the meantime I have

• communicated this plan with my supervisor, with my employees, and with my peers and others on the product team
• apologized to the design and product teams and individually to select people, especially those who had recently contributed or shared work via the wiki
• shared my plan with the current IT regime so that we can help each other
• opened a temporary space for the teams to use to avoid namespace pollution or any untoward effects of a possible full, partial, or botched restore

I am also communicating the emerging status with team members daily.

I know that with all of this, the likelihood of a full recovery is slim. And I know that at a certain point, some organizations will fire an employee for the effect of their mistakes regardless of the circumstances. If that comes to pass I will understand. But I will pursue multiple paths to success until that happens.

Update

The product management area of the wiki is back. My export was not usable, but the vendor agreed to help by rolling the wiki back to the moment prior to deletion, allowing us to export the data for the product management space, rolling it forward again, and allowing us to re-import the exported data. Thanks be to the IT person who convinced the vendor to help and who worked on the problem after-hours so that on the morning of day six we had the data back in place.

A side-effect of this is that every inbound link to pages in this area is broken. But so far this seems surmountable. Another side effect is that we now have a backup strategy that we are in charge of, and will not have to appeal to the vendor for further help if additional mistakes are made. I expect a security/privileges audit will come soon.

I don’t like either of these options. Of course, the employee in me wants to be rewarded for producing efficiently, and the manager in me wants to take advantage of that efficiency to improve the business overall; this is the simple conflict that the question hinges on. But Daniel’s question and its two options miss the mark entirely because they assume that the employee is being paid either for their time, i.e. selling hours, or by the task or piece, i.e. selling some number of completions of a well-defined task.

This is not how I want to arrange my work or the work of the people I support. I am not paying them for their time, and I am not paying them by the piece. And I can’t really; as knowledge workers

• our work is not so well-defined as to be sensibly thought of as piecework, and
• our time is not a good unto itself, rather it is the way we apply that time that produces results that are valuable.

Knowledge workers negotiate and accept anticipated results they are to participate in producing, and then act largely as they see fit to do so. They are paid a salary and evaluated based on their contribution to these results. It’s hard to do a good job without some amount of continuous improvement, as we are learning as we go, and a valued contributor will find ways to do a little better than last time.

That improvement has a few rewards:

• it produces a sense of accomplishment,
• it creates success for the team and organization, and
• it makes the job easier over time,
• it frees up some effort to work on more interesting things,
• it makes space for the employee to make decisions about balancing their ambition and their need for rest.

In the ideal case, all five of these rewards are produced.

There are a few ways these meetings might be organized depending on where we are in the design-development process.

• early concept: help me think about the problem
• late concept: help me choose among these ideas and develop one
• early detail: this is where we are going, what caveats remain?
• late detail: here’s a the detail, what questions do I need to address?

These depend on the thought that there are a few phases/horizons to product design work, namely

1. Problem Framing (aka Research or Horizon 3), in which we learn about the challenges and needs of users to understand and select a problem to go after with concepts,
2. Concept (or Horizon 2), in which we develop concepts and select among them with the help of users and engineering, and
3. Detail (or Horizon 1), in which we develop the selected concept and test the fitness of our more detailed work with users as we go.

It’s a common anti-pattern that engineering gets involved only when we are in detail, but we’d like to pull them into the other phases to be informed about the available problems and to help us develop and select among concepts.

Some Agile purists will decry this phasing as anti-agile, but that requires a blinkered view of what Agile means, which often comes about when one confuses Scrum for Agile. (The dirty little secret of Scrum is that there’s a lot of hand-waving about the large quantity of work that needs to happen outside of sprints to make Scrum possible.)

I tend not to be in favor of output metrics like these; they’ve been shown to be counterproductive for developers (lines of code, commits, bugs crushed, etc.), for example. But I am thinking about how best to apply the process maturity scorecard to the work of the individual designers to try to coach them on their projects. If a designer is helping to improve the process maturity of their product team(s), that’s a good sign.

On the other hand, some anti-metrics (trouble indicators) are pretty obvious – if there’s a lot of rework coming back to a designer, if deliverables are sloppy, if product managers and engineers are dissatisfied or under-involved, then we can tell there is a problem. But the opposite of these are not great metrics for individual performance, as a certain amount of rework will be technically driven, we don’t want to create an inspection-heavy situation where each deliverable is scrutinized for lack of sloppiness, etc.

I do have expectations that designers will bring work to and contribute to critique, seek my counsel on design challenges, press for collaboration, etc. But do I want to count these behaviors? Probably not.
The ideal thing would be to peg team performance to the product metrics we hope to install. The metrics we really care about are user success metrics in a product, and these are team metrics, not individual performance metrics.

So when it comes time to evaluate a designer, I like to use four Cs – customer, collaboration, culture, and content.

1. Customer – is the work produced by the designer informed by the customer, appropriate to the customer, accepted by the customer?
   1. Informed a leading indicator, evidenced by their participation in research and testing. They are or are not doing this. Exactly how much is situational, nonnumeric.
   2. Appropriate is somewhat evident in testing, and ultimately evident in adoption, a lagging indicator (and highly dependent on product and engineering decisions, the appropriateness of the feature idea in the first place, etc.).
   3. Accepted is essentially adoption. The same caveats apply.
2. Collaboration – is the designer an effective collaborator on their project teams? Do they work well with their peers and their project teams?
3. Culture – what is the designer’s contribution to the culture? Are they intellectually and emotionally engaged in a way that improves their teams and the org, is neutral, or detracts from their teams and the org? Are they improving and helping the culture improve?
4. Content – is the designer’s work organized, communicative, complete, insightful, timely? Are their skills and attention to detail usefully on display in their work?

The best articles out there about measuring designer performance are a) not very good and b) old, such as Measuring Designer Performance, or How do I create KPIs for my design team. So I’ve been content to use those four Cs, which are similar in concept to how IDEO evaluates their creative and engineering staff.

At work there’s been a move afoot to tag items in our roadmapping tool as “globalization,” “internationalization,” “localization,” or “translation.”

The executive level thinking here is that we are not offering our products globally, and need to be. So what do you do about that? You globalize!

To my thinking, though, there are universal requirements, things that the underlying product should do everywhere, and requirements borne of local data formats, terms of art, regulatory environments, etc. Universal versus local. Then there’s the work of offering interfaces and commendation in a newly-supported language, and the things you must do technologically to make your application able to deliver these universal and local requirements and serve interfaces and documentation in the correct languages.

To my thinking, a universal requirement is just a requirement. The special ones, therefore interesting to tag, are

• localization: things that need to be done differently due to a locale’s needs – preferred data formats, regulatory environment, terms of art, etc.
• translation: the actual translation of interfaces and documentation into a newly-supported language or English variant
• internationalization: things that must be done technologically to enable us to address either of the above

A tag that would be applied to all or almost all of the items seems like it might not be that useful. Globalization is the goal, not a specific type of work. It probably doesn’t make sense to separately call out universal requirements, as these should be numerous. Most work should be universal.

Meanwhile, globalization also includes marketing and sales and support and other things. Trying these terms on wrt marketing: we want to globalize our marketing, so we consider the universal messages we want prospective customers to understand (which should not be a special effort), then we look at how these might need to be localized (made locally specific/applicable) and translated (in the right language), and what processes we need to internationalize (tech/process/people to enable the above) to make conveying these messages possible.

I might be thinking about this wrongly, but this is my current understanding.

Heather asked me yesterday “who owns accessibility?” That’s a fun question. I replied:

Accessibility is not owned. Who owns quality? It’s a team responsibility. To the extent that accessibility compliance, or release date, or the P&L is a “feature” of a piece of software it is owned by the PM, but each function has its responsibilities in accomplishing accessibility. Making these responsibilities explicit is necessary.

The folks with responsibilities mainly include UX (designing for accessibility), FED (engineering for accessibility), QA (inspection), and PM/PO (prioritization). These aren’t collected in one person’s purview around here until the CEO, so that’s not the answer to your question.

If we are to be product-led and not sales-led, PM has to insist on it (and manage competing priorities), maybe that’s part of the answer.

The “ownership” urge seems to sometimes dilute or deprioritize the responsibilities of others, which is a shame because we must work in concert.

As of nine weeks ago I have a new job at Cayuse. But how do I explain my accomplishments on LinkedIn when I’m so new?

Maybe I don’t. What if I instead explain what I am there to do? What would that be like?

I am building a design and research team to support the collection of 25+ disparate built and acquired products into a single coherent suite. Since I’ve recently begun, here’s what I plan to accomplish:
• Develop UX and UI design capacity and capability
• Add and develop UX research capability
• Install formative usability testing during design to de-risk detailed design decisions
• Install user insights research, concept design and validation
• Stand up a team and processes to build and improve a design system in visuals and code, for the product suite
• Gather and improve product personas to be an informative smaller set of personas for the entire suite
• Begin instrumentation of new features, to measure outcomes, by determining desired outcomes at the epic level
• Help the product team take advantage of existing pre-customer and post-launch data, such as customer success contact data, support forum and knowledge base behavior, RFP mining, sales demo feedback, etc.

https://www.linkedin.com/in/jplummer/

I suppose over time I could exchange some of these for my accomplishments and my new plan. I’ve not seen this anywhere else. Good idea? Bad idea?

In her post on LinkedIn, Laura Cotterill (one of my new coworkers) refers to Eric Chan’s post about teamwork and wonders why such a seemingly obvious mode of work is out of reach so much of the time. To which I responded

My impression is:
1) When we pressure people to overproduce we encourage them to defend themselves in ways that seem locally sensible but turn out to be anti-collaborative.
2) Financial planning, especially when the business is not self-funded, tends to require a forecast; that forecast hangs from a roadmap, effort estimates, and sales targets.
3) When a business sees the sales team as its economic engine rather than the product itself (sales teams tend to be good at preserving this impression), opportunities detected by sales get pushed onto that roadmap with less discussion than necessary.

Of these I find the first the most pernicious.

In the Design Thinking group on LinkedIn, Sara Bermúdez asked:

I would love to hear your opinions on which are the most important mindsets for the future of work.

Naturally, I had a take on this:

I find I often have to nudge people out of what I’ve come to call constraint-based thinking. Focusing on and reacting to the apparent constraints in a situation can lead to a poor solution and a feeling of being stuck with that poor solution, a double-whammy of negativity. “We couldn’t do X because of A, we couldn’t do Y because of B, so we’re stuck with Z, like it or not.” Chances are good that there’s a way to meet the goal that manages or makes irrelevant these constraints that you’ll be happier with than where you are seemingly stuck, but it requires exploring ways to meet the goal rather than rattling around in a box of obstacles.

Steven Forth responded:

Are there skills we can cultivate that helps us escape from the self-imposed constraints of constraint based thinking?

So I elaborated a bit:

Sure. Some are implied above.

1) Identify and articulate a goal as a benefit (where a benefit is the happy result NOT expressed in terms of exactly how it is delivered).

2) Consider a person’s needs and a business’s needs together rather than separately.

3) When confronted with a problem or pain point, learn about and offer possible benefits (some folks call them “gain points”) rather than solutions, at first. Later you can design or select a way to deliver that benefit.

4) Think in scenarios: who arrives in what situation, when and where, with which need or goal to address or accomplish, and what can the system (or organization, etc.) offer them?

Note that most of these thoughts require a positive wording of the situation or aim rather than a negative wording. This might be the key skill, broadly useful but not sufficient on its own. You’ll see this in health fields when practitioners take a wellness perspective—rather than cease some harmful behavior like smoking, they’ll talk about replacing the habits associated with smoking with healthier rituals, moving nicotine delivery to a less-harmful medium where it can be managed, etc.

There are many other good comments there.

Gentle people,
I recently complained to the directors and project managers about meeting invitations

• without agendas, or
• without a clear goal, or
• without a sense of what a person might be expected to do in a meeting, or
• without a sense of what person might need to do to prepare for a meeting.

It turns out that, generally, the project managers aren’t to blame here. The VPs and directors are to blame more than we should be, but especially the populace—most folks are not that great about helping the folks they invite to a meeting be ready for that meeting.

This is a thing that design folks can be especially good at. We’re accustomed to thinking about others and their needs. All we need to do is remember to think about these at the moment we are scheduling the meeting.

The people who are coming to your meeting need to know what the meeting is meant to accomplish and how they are going to be useful. Please tell them by including that information in the invitation.

If we get good at this, others will notice.