Showing posts with label motivation. Show all posts
Showing posts with label motivation. Show all posts

Monday, June 22, 2015

The Problem With Engagement

by Melissa Tullio RSS / cpsrenewalFacebook / cpsrenewaltwitter / creativegov

I left a comment on Kent's recent post (See: The Future Of Online Communities) that was probably out of scope of what his post was about, and started reflecting on engagement in digital spaces versus in real life. Here's a challenge question I started thinking about: "How might we make the best use of technology/online systems to capture public sentiment and insights in a deeper way?" (I'm not going to attempt to navigate that one in this post, but maybe a future post.)

I think the key to this is something Kent also asked, which got me thinking in a different direction: "The question [about online collaboration] will move from 'How can we get people to engage?' to 'Who actually needs to engage, and why would they, in particular?'"

There's an assumption we make in government, especially in the communications world where I work, that whenever we make an announcement or hold a consultation, people are engaged and interested and will come. This isn't generally a bad assumption to make. We do get engagement; we do get people at the town halls and consultations we run. But the people who attend often represent people who we've heard from, time and again, over the years. The outcome of these consultations is almost completely predictable - we issue management the hell out of it; we can anticipate responses, and come up with plans to "mitigate" them.

So my next challenge question would be, "What's the point?" If you're doing a consultation and you know what you're going to hear, isn't it a big waste of time and resources to do it? Can't we do it in a more meaningful way that generates new solutions or ways to work together?

Beyond the Usual Suspects

One thing about design thinking that's different than other problem solving methods is taking time to interview and empathize with extreme users. It's crucially valuable to do this because taking time to reach out to, and empathizing with, extreme users helps to reveal the deeper, more systemic challenges in the design of your service/program.

This type of ethnographic research is not something we normally do enough of in government. We tend to create policies/programs that end up working for the mainstream user. The way we come to create programs is based on well researched best practices (i.e., existing solutions), which inevitably leaves some users behind in the process. This approach doesn't include extreme users in the problem definition stages (or problem solving stages), so we assume that what we design is good enough, without examining all those hidden assumptions we're making. The kind of research and deeper understanding that you need to do to really empathize with service users requires time, and in a lot of our work in the policy making environment (and exponentially more in the communications space), time is (artificially) something we don't have1.

Another challenge isn't just the process/resource barrier in government work from doing this kind of research. Even if you design a program/policy to include time for this kind of deep dive research, how do you make the case for people who you don't normally interact with to gain your trust and let you into their spaces?

What's In It For Them?

When I previously worked in an HR role for Ontario, I was one of the people responsible for the formal employee recognition program. Something we constantly struggled with was how to tap into people's intrinsic motivation for doing things. There are a lot of smarter people than me who have done research in this area, and the short answer is, "it's complicated." I was most interested in what motivates people to engage and interact with online spaces because another file I worked on was an ideas management system, and I was curious about why these kinds of systems often fail.

Something my team learned is that online engagement is limited. Taking idea generation to the next level requires an in person component that can't be replaced by online platforms (not yet, anyway). An ideas campaign, followed by observational/ethnographic research to figure out what you're missing, followed by a hackathon/jam/competition of some sort to test some theories, followed by an experiment/prototype-making stage, followed by reflections/sharing lessons to improve something, is what you need to make the campaign work through the full spectrum of engagement.
Stanford dschool design thinking steps

That goes back to the old constraint: who has time for this?

Online and in-person engagement

From everything we learned, online platforms simply aren't enough; some tangible, shared outcome from the ideation or consultation stage is needed in order for people to believe you're doing something for them, or else they lose faith and you lose credibility (See: Pulling the Trigger on Chekhov's Gun). Many people are happy with engaging online at the front-end - it's low-friction and easy (also less valuable to gain deeper insights); extreme users, the ones we need to take time for to understand better, need more (and so do we if we want to reach those deeper insights to design things better).

Any online or offline engagement platform not only needs to ask the question, "who needs to engage?" but "who else needs to engage who isn't already raising their hand to volunteer?" Knowing how to answer the corollary question, "how do we motivate them to?" is definitely the tougher one.

1. I'd say resources (people/funding) are something we have less and less of in a more real way than time; time for empathy/good design can be worked into our processes (assuming we've taken a good look at our culture and we're able to move towards changing it to include mindsets like human centered design in our work).

Wednesday, January 21, 2015

The Villainy of Talk


by Kent Aitken RSS / cpsrenewalFacebook / cpsrenewalLinkedIn / Kent Aitkentwitter / kentdaitkengovloop / KentAitken



Showing is better than telling. Actions speak louder than words. Or, paraphrasing a much-retweeted line from Twitter today, stop talking about the shit you're going to do and just do it.

It's a great slogan for errands, to-dos, or exercise. I'm less sold on it when applied to work, starting a business, side projects, or in Peers' example above, urban planning.

It's tempting to vilify talk.

We have this tension between springing into action and being methodical. In 2013 a tentative theme for Collaborative Management Day was Borrow and Build: rather than re-inventing the wheel, the idea was to introduce people to all of the currently available wheels, to help them round out their toolkits for problem solving.

Which has its own issues. Building on the work of others, and helping existing projects and organizations, is often the most efficient approach. Yet, so many people start from scratch, rationalize a differentiating ideology, and do their own thing. Why is that?

In many ways, we ought to be able to feel a sense of agency over others' work when we get involved. But that feeling pales in comparison to how we feel about an idea that's uniquely ours. For a while I tried to square that circle, and figure out how to get people emotionally involved in others' missions; to have continuity of projects without continuity of people.

Now, I'm starting to suspect that the alternative - the frequent, theoretically inefficient, starting from scratch - is often better, or at least, okay. If that's what motivates people and gets them working on something? So be it, build from scratch. Get shit done.

But. I think it behooves us to talk about what we're scheming. Otherwise, it's impossible for others to point to similar projects, challenge your ideas, or suggest building on someone else's work instead. 

Sometimes, the feedback will crush the project. If it's a bad idea, or if the problem has been solved elsewhere, great. Many ideas are bad, duplicate, or at least incomplete. Most shouldn't actually happen. Most are not the absolute best use of someone's time. So airing out these ideas should not be seen as a passive act to be frowned upon. It should be seen as a reasonable step towards getting something good done.

So talk about it. Then, do whatever you want: help someone else's idea in motion, accept feedback or help, scrap it and move on to something else, or run with it. Get shit done. Just get the right shit done.





Friday, November 18, 2011

Public Sector Microtasking

Given our propensity for micromanagement I suspect many will look at the idea of micro-tasking with come skepticism, but I think the idea is worth exploring (as do others).

A primer

For the uninitiated, micro-tasking is simply the breaking-down of more complex tasks into smaller, more manageable chunks. The most widely talked about micro-tasking service is Amazon's Mechanical Turk (MTurk); which according to Wikipedia is:
a crowdsourcing Internet marketplace that enables computer programmers (known as Requesters) to co-ordinate the use of human intelligence to perform tasks that computers are unable to do yet. It is one of the suites of Amazon Web Services. The Requesters are able to post tasks known as HITs (Human Intelligence Tasks), such as choosing the best among several photographs of a store-front, writing product descriptions, or identifying performers on music CDs. Workers (called Providers in Mechanical Turk's Terms of Service) can then browse among existing tasks and complete them for a monetary payment set by the Requester. To place HITs, the requesting programs use an open Application Programming Interface (API), or the more limited MTurk Requester site. Requestors are restricted to US-based entities.

Requesters can ask that Workers fulfill Qualifications before engaging a task, and they can set up a test in order to verify the Qualification. They can also accept or reject the result sent by the Worker, which reflects on the Worker's reputation. Currently, Workers can have an address anywhere in the world. Payments for completing tasks can be redeemed on Amazon.com via gift certificate or be later transferred to a Worker's U.S. bank account. Requesters, which are typically corporations, pay 10 percent over the price of successfully completed HITs to Amazon.

In short, corporations post tasks that computers can't do, other people do them, and in so doing earn some small modicum of compensation. (Note if you are interested in learning more about microtasking and Amazon's Mechanical Turk, I suggest watching Aaron Koblin's TED talk: Artfully visualizing our humanity)


In practice

Aphid Farm by binux
Common public sector tasks such as translation, document formatting, fact checking, and basic editing could all be tested in a microtasking environment. While these tasks aren't necessarily sexy they are probably the easiest to manage at the outset. They can be easily broken up into smaller bits (e.g. translate this paragraph, format this 5-page PowerPoint presentation, fact check this page, etc) and are directionally straightforward. In order to ensure some modicum of consistency, users could take qualifying tests prior to being granted access to a particular category of microtask.

That said, microtasking shouldn't be limited to strictly perfunctory tasks. Service providers and policy makers could leverage the same system by presenting scenarios and asking people to complete questionnaires, say evaluating proposed changes to service delivery models or interpreting legislative or regulatory changes. There is an important caveat here, that obviously not everyone in the organization would have the requisite specialized knowledge to provide an in-depth analysis on a given topic. Meaning that feedback acquired from microtasking is more likely to be a better proxy for the general public than it is to be for a specific or specialized stakeholder group.



The motivation

One of the most common criticisms levied against microtasking is the incentive structure; why would people bother completing any of these tasks? First let me start by stating that I don't think that the problem of motivation is a deal-breaker when it comes to public sector microtasking. The answer to the problem is gamification.  If we could create a system that leveraged game mechanics while allowing users to engage the system on their own terms it offers them an opportunity for greater autonomy, mastery and purpose; qualities that Dan Pink argues are the hallmarks of motivation.

I've argued in the past that:

An increasingly diverse workforce coupled with an increasingly diverse scope of work means our organizational models have to contend with increasingly jagged edges, wider gaps and unforeseen overlaps. Upon closer reflection, my gut tells me that if we took the time to examine our organizational structures more closely we would find conflict at the jagged edges, delays at the gaps, and duplication at the overlaps.

It also means that many public servants oscillate between periods of hyperactivity and lethargy in the workplace. I think the most compelling benefit of a microtasking system would be that it would help alleviate the pressure of both ends of the spectrum. Those who were incredibly busy could more easily surge as required because they could gain access and expertise from those whom were less busy at that particular moment in time.

Some of our most basic performance issues stem from the fact that few of us have things we can work on when everything else has been accomplished. If you have ever heard anyone say that they had to stretch their workload over the week you know what I am getting at. The problem, at its core, is that we (public servants) don't have a common place to aim our cognitive surplus.

Imagine what we could do if we did.






Originally published by Nick Charney at cpsrenewal.ca
subscribe/connect
RSS / cpsrenewalFacebook / cpsrenewalLinkedIn / Nick Charneytwitter / nickcharneygovloop / nickcharneyGoogle+ / nickcharney