Becoming Manifesto-y, Telling Stories
A couple weeks ago, my advisor counseled me to make the research statement I was writing for a job application "more manifesto-y." A few days later, we elected Barack Obama President of the United States, spurring at least one manifesto [story from the Boston Globe]. This week I have watched an embarrassing number of episodes of The West Wing on DVD. The characters on The West Wing are constanting publicly declaring their intentions. Today, my brother sent me a Tom Peters manifesto from ChangeThis. Manifesto seems to be the theme of my life for November.
man⋅i⋅fes⋅to
[man-uh-fes-toh]
–noun, plural -toes. a public declaration of intentions, opinions, objectives, or motives, as one issued by a government, sovereign, or organization. (from Dictionary.com)
This definition from Dictionary.com seems to be missing some of the "flair" I normally associate with a manifesto. For me, a manifesto is not just any public declaration of intentions, opinions, objectives, or motives, but an energetic, empassioned public declaration. Without passion, it's just a statement.
Why blog this? Well, I'm worked up. My guy won the White House. A close friend wrote something that was entered into the Congressional record and may find a public outlet for other important work. My brother sent me something from non-academic workplace literature that made me sit up and pay attention while I read. President-elect Obama. We millions who voted for him. My friend the policy researcher. Tom Peters. These people made public declarations of their opinions and objectives, and they did so with passion.
It seems silly to compare those actions to the kind of effort my advisor asked me to use in my research statement. I don't think I really understood when she told me to "be more manifesto-y." I definitely improved my statement after that advice, but it did not turn into a research manifesto. It's probably too early in my career for me to be writing research manifestos. After all, I need some political capital in order to get a job. I don't have the protection of tenure to shield me in the event that my manifesto is unpopular.
I don't think my manifesto would be unpopular though. My manifesto would be about doing research that helps us change the world by working together. Research that helps us solve problems like AIDS, bioterrorism, crumbling civil infrastructure, and the uncertainty and pain of starting new careers. Those are the problems the people I study are solving. My research will be useful to them. My research will help us work together better. My research will help us organize our projects so that we can accomplish more together than on our own. My research will help us feel better about our work, about what we can accomplish, about our relationships with our colleagues. My research will enable us to get more from ourselves.
That is the research statement I can make here, on my blog, after regaining hope in my country, after watching my friends do their best to change the world, after reading about how to succeed. I make it here because it's not appropriate for my job packet. I make it here because while reading #17: Work on Your Story in Tom Peters' manifesto, I was reminded of my frustrations about presenting and discussing academic work. Tom Peters claims that "he/she who has the best story wins!" He claims that telling stories is better than simply giving presentations. I am a great story teller. Ask my friends or the people who come to my parties. My friend Caroline, for sure, will vouch for me. I want so much to believe Tom Peters that being a storyteller will help me succeed. The trouble is, I'm not sure my audience can handle it. I'm not sure my conference presentations go over that well when I try to be a storyteller. I know reviewers get frustrated when I don't stick to intro, method, results, discussion and bullet points. I'm pretty sure a hiring committee would rather I send them the statement I did than something like the paragraph before this one.
Am I asking too little of my conference audiences, of those hiring committees? Would I be better off if I showed them the passion I have for the study of collaboration? I'm not sure. I do know I want to be more manifesto-y. The stories about the work I've done and seen could inspire. I don't know who would listen to them though. I don't know what audience would match my energy. The dry, monotonous style of academic publishing, both in print and at conferences, does not lend itself to manifesto. We academics are reserved; sometimes we are cynical. When I'm all worked up like this, that reservation, that cynicism is troubling. I see some value in a cold, passive, rational approach. I do. Just not tonight.
NSF Award
Stephanie Teasley, Erik Johnston, and I teamed up this spring to propose a study of post-docs joining virtual science teams. NSF awarded us funding at the full amount this week. Our project kicks off this September and runs through (at least) August 2010. I'm very excited about this project. To read more about it, visit NSF's site.
A Productive Summer
Andrew Begel and I had a very productive summer. We conducted 95 interviews with 26 people, and spent 7 days onsite observing new remote employees. We'll be presenting a poster titled, "How will you see my greatness if you can't see me?" at CSCW in November. The poster session is Monday night, Nov. 11. Come by to hear more about our study, especially our findings about how excellent work is and is not observable from a distance. Stay tuned; we're submitting longer papers to two other conferences, and I'll post here when they get accepted.
Related links:
Human Interactions in Programming Group at Microsoft Research
ACM's Computer Supported Cooperative Work Conference (CSCW08)
Special, so special
Earlier today, I was plowing through some old emails, and I came upon a link Cory sent me a couple months ago. He knew I was off to Microsoft to study new software engineers and thought I might be interested in a post from Paul Johnson's blog about how there is no process for programming. I commented on some of the details of his post, namely that I thought professionals deserve a little more respect than I thought he gave them by saying, "Think about other important areas of human endeavor: driving a car, flying a plane, running a company, designing a house, teaching a child, curing a disease, selling insurance, fighting a lawsuit. In every case the core of the activity is well understood: it is written down, taught and learned." What a load of crap. (On my own blog, I can say that. On his, I thought I was polite.)
I was excited to get an email response from Paul about my comment; he addressed specific points within my comment and clearly took some time to consider his responses. The gist ended up being, "If you tried programming, you'd know I'm right, and then I would respect you." Another load of crap. Clearly he thinks programming is different in kind from other professions. While I agree that it is, I don't think programming is different because it doesn't follow a process or isn't easily described as a process. Instead, I think it's different because it requires an approach to thinking about problems (Paul made a nice comparison to mathematics) that seems procedural to an untrained, inexperienced eye. I think what Paul's missing is that the same is true about professions like management and medicine. What looks to outsiders like process is often not at all. Software engineering is not alone. Many professions include something akin to "write the code" where the magic happens, and we should respect that.
I could've titled this post, "Why I Should Never Comment on Blogs." I appreciated that Paul took the time to reply to me, but I did not appreciate the slapping he gave me. Perhaps I'm being overly sensitive, but the stress I've felt since reading his email and then responding and now blogging is disproportionate to the importance of our conversation. I love studying people, especially at work, because I get to learn how different they and their jobs are. And today I stood up for similarity. Now, I'm schizophrenic. Sigh.
Formative interventions and design research
Discussions of method don’t often sound all that sexy, but I love them anyway. My first two sessions of the ICLS 2008 conference have been about method (maybe process is a better term). First, Yrjo Engestrom talked about formative interventions, an activity theory-style approach to research, and then Ilya Zitter described her process for using Educational Design Research in her doctoral work.
Not surprisingly, Engestrom railed against the “gold standard” of randomized controlled trials as the best and only way to properly conduct research. He mixed in a couple jabs at the U.S. – one for emphasizing such studies and one for making unpopular interventions. I’m with him on both. Randomized controlled trials (RCT) shouldn’t be the gold standard for all kinds of research, and the U.S. shouldn’t have intervened in Iraq. At least not the way we did. But, I digress. I was talking about method.
In contrast to the positivist RCT program, Engestrom recommends a different process entirely. His process, we’ll call it formative interventions (that was on his slides), engages the research site as a participant in the project rather than as a passive recipient of a designed intervention. It differs from ICT (and even from Design Research – an approach gaining popularity in education research) in three main ways:
- starting point,
- process, and
- outcome.
The starting point for formative interventions are poorly understood objects. RCT and design research start with some goal in mind. Having a goal presupposes that the goal is desirable. I dislike the arrogance behind starting a project from, “I know how it should be,” and so it’s no surprise that I like formative interventions’ starting point.
Engestrom calls formative interventions’ process “double stimulation.” That term doesn’t really work for me. I think what he means is that the research introduces and recognizes changes in the research environment over time. Whether those changes are planned by the researchers or not is not terribly important. The process of studying a changing phenomenon differs dramatically from the “execute, refine, repeat” approach RCT takes.
Lastly, the outcomes of the two methodological approaches differs. For Engestrom, the outcome should be “new activity concepts” and for RCT, it’s “solutions.” I’m often frustrated by “solution” terminology – because I’m uncomfortable labeling social phenomena as broken, because I’ve seen too many “solutions” that don’t have clear “problems”, because I just don’t see the world that black and white.
So now we have an outline of Engestrom’s preferred methodological approach. I like it. It’s engaged, rigorous, and embraces the ongoing and changing nature of social situations. Trouble is, it’s hard to sell, in the U.S. especially, and even harder to do.
Enter Ilya Zitter. Ilya is a PhD student at Utrecht University, and she uses a method she calls “Educational Design Research” in her doctoral work. Basically, she uses research, design, and practice approaches to study undergrads in a projects course. Hooray for higher education at ICLS! It’s almost as satisfying for me to engage as adults’ informal and workplace learning. Anyway, Ilya gave a short talk in a firehose session where she described how she conducted her research. This is exactly the kind of talk I like to attend at conferences. I can read papers, but papers about how the research was conducted are hard to come by. Sure, papers include methods sections, but those don’t often tell you the nitty gritty details. Ilya talked about her struggle to balance research, design, and practice in her work. This is a struggle I get to avoid in my dissertation but which is central to my life at Microsoft Research.
At MSR, we’re engaged in a formative intervention study of sorts. We’re working with HR and managers to adjust social and technological tools used in onboarding at Microsoft. I’m often uncomfortable in the “design” and “intervene” portions of such studies. I much prefer to be a fly on the wall. That’s not immediately useful (or publishable) though. I, like Ilya, am struggling to find balance and to negotiate relationships among researchers and practitioners all while gathering and analyzing data. It’s hard, but at least I’m not alone.
What is an actor?
Some colleagues and I recently submitted a paper to a conference, and last week I sent in our rebuttals to the reviewers' comments. Our paper introduces some terms from actor-network theory (ANT) to an audience that isn't terribly familiar with ANT. I like ANT as a method, not really a theory, for helping sort through really dense, unfamiliar data. For instance, you can use ANT to help you figure out where to focus. If you enter a scenario as an ignorant sponge (as many qualitative methods ask that you do), it can be difficult to figure out what's important. It's also impossible to pay attention to everything all the time. ANT can help you find some important actors on which to focus your attention. Actors seems like a familiar term - we know of many in Hollywood, we understand what it means to act even off screen. That's not what ANT means though. For ANT, actors are something like things that cause change, or things that other actors say are actors. You can probably see why some of our reviewers got a bit confused.
I use ANT in my dissertation to talk about what had to happen for a specific bridge to be built. I couch the study in terms of actors who did work to produce the bridge. I borrow actors from ANT in that I consider non-human actors (e.g. bendable concrete) symmetrical with human actors. Objects and ideas can do work even though they're not human. They're identified as important by other actors. For instance, using bendable concrete in the bridge deck required changes in how the sidewalk was connected, how the deck connected to the regular concrete deck on either side. The bendable concrete was acting in that it was creating change. Other actors, such as a construction consultant, identified it as an actor by saying things like, "If we use that bendable concrete, then we can't use rebar there. We'll have to use something else." In that excerpt, he identified bendable concrete as the thing that caused a change. Bendable concrete has some agency. Had we entered the construction project without knowing anything, we'd know from the way the consultant talks about the bendable concrete that it is something important, that determines what other actors may or may not do (e.g. use rebar).
I think our paper does a good job of describing how ANT can help identify the important things in a set of data. When I find out if it got accepted, I'll blog about the conference itself. I have pretty strong feelings about the conference to which we submitted, and they will either grow stronger or remain in check, depending on the outcome of our submission. Oh, that drama! The intrigue! Stay tuned.
A new vocabulary
I'm lucky to be the kind of researcher I am. I get to observe and interview people who do really cool work and to learn about what they do. A couple years ago I learned how vaccines for Black Plague get made. My dissertation lets me learn about how bridges (real ones, not just metaphorical ones) get built. Now, at Microsoft, I learn how software is built. Over the last couple of weeks I've been interviewing managers of developers and testers at Microsoft in an effort to recruit them for my study on remote onboarding and to learn about what they do.
Years ago, before I came back to grad school, I had the illustrious title "Developer" at a web start up in Chicago with about 100 employees. A "software team" there was a project manager, a developer, an architect, and a designer. We built websites. My job was to write ASP code that made the designers and project managers happy. Towards the end of my career, I wrote ASP.NET code. Somewhat more complicated, still produced a website. "Developer" at Microsoft means something a bit different. Developers at Microsoft build stuff that matters - Windows, for example. They do it in teams using tools such as Source Depot, Razzle, test harnesses, RSOPs, WTT, and TFS. They meet in scrums, war rooms, Live Meetings, Office Communicator, one-on-ones, and code reviews. Those 12 phrases and acronyms are new to me. Not one of them had I ever heard before. I now know what 5 of them mean. I'll leave you to guess which 5 I know.
Learning the vocabulary of my subjects is just one part of my research, but it's been a while since I had so much specialized vocabulary to learn. The phrases and acronyms the engineers I study use seem a bit more intuitive to me, things like "pancake test" and "aggregate" are nearly self-explanatory. Granted, "code review" means about what you think it does but "scrum"? No, developers are not playing rugby.
Being a new employee while studying new employees is so meta I can hardly handle it. Perhaps next week when I meet my first new employee subjects I'll start to feel like I have a better handle on the situation. For now, while I'm meeting with managers, I'll just keep typing as fast as I can and hope that I'll know when to ask for help.
Learning about visas
I'm just starting my third week as an intern at Microsoft Research, and I'm still figuring out how to blog this experience. I'm working in the Human Interactions in Programming group studying remote onboarding of new employees in the Microsoft Canada Development Centre (MCDC).
We originally defined remote onboarding as a process new hires who are geographically separated from their teams go through when joining a new company. After interviewing managers and HR professionals, it makes more sense to think of remote onboarding as a process the organization goes through to help new employees be productive. We use remote instead of distributed because only one person is physically separate from the rest (sometimes called a "one-off"). For me, distributed refers to a group whose members are in a number of different places, either together in groups or apart in one-offs or groups. Basically remote is a subcategory of distributed and a special enough category to get its own name. Microsoft uses a similar term, remote management, to refer to the kind of management leads and other managers must use to work with employees who are far from them, whether at MCDC or in India, Ireland, China, etc.
I'm conducting a comparative case study in order to understand how remote onboarding works and how various interventions impact onboarding experiences. Of course some part of my energy is directed at identifying areas for growth so that Microsoft can improve their onboarding, but it's too early in the study for me to talk about improvements. That said, I think I'm ready to say the U.S. has some serious room for improvement in its visa and immigration rules.
Many people are working from MCDC while they await an H1-B visa. Others are planning to stay in Canada for some time. A third group are waiting for L visas. As I understand it, both H1-B and L visas are work visas; people who hold them are able to work in the U.S. H1-B's are the visas awarded through lotteries that we hear and read about while Congress and the Presidential candidates debate immigration reform. Microsoft has been pretty open about its feelings about immigration laws. They want to hire more foreign workers because they are qualified, but the U.S. won't let them in the country. Enter MCDC. Canada apparently likes the idea of highly-skilled workers with good salaries living within its borders. L visas are internal transfer visas and are not part of a lottery system. Basically, if you work for Microsoft in another country for 365 days, you can then get an internal transfer and L visa to come live in the U.S. and work for Microsoft for 5 years. The H and L visas differ in their rules for getting them, the rights you and your family members have in the U.S., the length of stay, renewal, etc. I'll be learning all about visas in the next couple of months. I'm pretty sure I'll think we need some reform though. 65,000 H1-B's clearly aren't the right answer to the global competitiveness challenge.
Call for Participation – ICLS Workshop
I'm hosting a workshop at ICLS 2008 with Stephanie Teasley, Volker Wulf, Eric Cook, and Jude Yew - The Missing Chapters: Learning Sciences Beyond the Classroom.
This workshop will provide momentum toward building a community of Learning Sciences researchers who focus on learning that takes place in non-traditional contexts with learners of any age. Our goal is to bring together researchers who might otherwise be on the fringe of learning sciences to discuss their work and help generate publications appropriate for new chapters in the next Handbook of the Learning Sciences or a special issue of a Learning Sciences journal.
More information about the workshop is available on our blog.