Feedback sessions
Posted: July 3, 2007 at 8:11 pm in conversation, management, people ~ Permalink

Feedback sessions are a powerful tool for generating forward progress in any aspect of life. Even though I determined that iteration and feedback don’t work as a management tactic, I still think feedback sessions are important.

One simple benefit is that regular feedback sessions force you to take action. It almost doesn’t matter what form the session takes - it could be a daily status meeting, a one-on-one with your manager or mentor, or even a journal update that you write for yourself. You can keep yourself moving forward by regularly being evaluated on what you’ve done since your last session, and what needs to be done for the next one. I feel like I have drifted less since starting the five minute daily journal report suggested by Gerald Weinberg. There’s no implied consequence in failing to accomplish my daily goals, but getting into the habit of setting goals and recording whether I reached them has kept me more focused and disciplined.

Another benefit of regular feedback sessions is to confirm which direction is forward. One tactic I use in rapid prototyping situations where direction is unclear is to create a first draft just to have something to criticize. I don’t spend a lot of time on that first effort because I’m not trying to solve the problem with it. Its point is to elicit criticism, and by analyzing and understanding that criticism, I learn where I should be spending my design efforts and what the final goal is as of today. By getting early feedback, I don’t waste time polishing a solution that doesn’t fit the situation. Because I intentionally didn’t spend much time on that first attempt, I’m not personally invested in it, so I am open to exploring other options in response to the feedback I get. With regular feedback sessions, I can work with my teammates in shaping our work even as goals change.

To take a specific counter-example, I once worked at a company where a software team interviewed end-users about what they needed, drew up a specification and disappeared for six months to code to that specification. They came back with software that did exactly what was requested and found that circumstances had changed drastically over the six months since the specification was written, making their software useless. But because they had spent six months writing that software, they were emotionally invested in finding a use for it, so they spent another couple months trying to fit it into what the end-users were doing. If they had re-evaluated the specification every two weeks with the end-users, they could have evolved the software in response to the changing landscape and not wasted their time or the time of the end-users.

Feedback sessions also allow us to overcome our innate desire to keep doing what we have always done. We humans are subject to the consistency principle described by Cialdini, where once we say we’re doing something, we become more committed to doing it. We don’t want to find out that we made the wrong choice, so we either don’t evaluate the results, or interpret the evaluation results in order to support the choice we made. Feedback sessions allow us to verify that our choice is having the intended effect.

In an environment where feedback is valued, the review informs what will happen next. If everybody involved has agreed to take action in response to feedback, designing the evaluation process is in some sense more important than designing the work itself, because the evaluation process will determine how the work evolves. This is the idea behind test driven development, where the evaluation (test) is actually written before any work starts on the software itself. This is also why students always clamor to know the grading scheme at the beginning of the term - they plan their work by knowing how they will be evaluated. A good evaluation process creates a good end result.

Feedback sessions play a large part in why I currently function better as a team player. I do not yet have the self-discipline to re-evaluate myself with brutal honesty on a regular basis. I’m working on that with exercises like the daily Weinberg journal. I’ve also started setting up regular phone calls with trusted friends to talk about my life goals, and even though they are friends, I feel a responsibility to have made some progress towards those goals between calls. These feedback sessions are increasing my ability to move forward and execute, and I think that is a good thing.

P.S. I wrote this post on a bus on the way to Cornell. Yes, the bus has wi-fi. Luxury!

~ 1 Comment ~

Iteration and feedback in management
Posted: June 27, 2007 at 8:52 am in management ~ Permalink

My recent post on fixing the real problem reminded me of an earlier post on the rapid prototyping of life, where I said “The qualities which point towards rapid prototyping are where the final goal is poorly defined, where only experimentation, not theory, will help define that final goal, and where there are no irreversible consequences for trying something.”

Can we apply these iteration and feedback tactics to management? It seems like an appropriate solution, as managers are often in situations where the real problem is “poorly defined”. Perhaps the only thing a manager can do is to guess what the problem is, try something to fix it, see what happens and then repeat the process.

Unfortunately, people are involved, and people have memories. My statement on the applicability of rapid prototyping included a clause about “no irreversible consequences”. That doesn’t apply here. If a manager decides that the problem is that employees aren’t working hard enough, and the real problem was a technology issue, then that manager loses credibility in the eyes of the employees, opening an irrecoverable breach of trust.

Another problem is that the feedback received as a manager may be untrustworthy. In rapid prototyping, evaluation is an integral part of the process, because the feedback drives the direction of the next iteration. In a management situation, the relevant feedback would have to come from the employees being managed, and that feedback is inherently suspect because of the power differential. Very few employees will provide critical feedback to their manager, even in anonymous forums, for fear of retributive consequences. Even positive feedback can’t be trusted because employees may be deceivingly flattering in hopes of currying favor.

I think there are ways in which iteration and feedback can be incorporated into a management setting, but they depend on a having already built a team. When there’s a problem with a project, the manager can’t unilaterally make a decision without risking losing the team. He has to consult the team to collect possible ideas and create a consensus around one of those proposed solutions. There has to be a foundation of trust between the team and the manager for iteration and feedback to work, and for the employees to believe that their feedback will be included in the next iteration. That trust takes time and several iterations of projects to establish, so hopefully you’re not a bungee boss.

There’s also an element of iteration as a new manager. You’re going to mis-read situations and make the wrong choice sometimes, and you have to learn from those mistakes. The team also has to see you accept feedback and change your behavior, which will make it easier to get better feedback the next time, creating a virtuous circle of trust and improvement. One critical tactic for earning that trust is to take the blame, not only for yourself, but for the team.

Wow, this post ended up in a different place than where it started. I meant to write about how to use rapid prototyping and Trust but Verify methods in management and spent an hour yesterday on a draft that wasn’t working. But after writing a comment about trust this morning, I realized that the whole approach was bogus, so I ended up writing a post about how those tactics _won’t_ work. Ah, the joy of thinking in public.

~ 1 Comment ~

Fixing the real problem
Posted: June 23, 2007 at 9:28 am in management, people ~ Permalink

When I worked at Signature BioScience, there were ten other software developers, all of whom wrote better and more sophisticated code than I did. Yet I survived through multiple layoffs as Signature spiralled into bankruptcy, and I was the only developer re-hired by MDS Sciex when they picked up the pieces from Signature’s carnage. Seem peculiar?

It was actually an easy choice for Sciex. At the time Signature went under, I had written the vast majority of the code actually being used by the company. The difference was that the other developers went to the biologists, asked them what software they needed, put together a specification based on what they were told, and coded to that specification. Yet somehow, even though they delivered code that did exactly what was requested, it never did what what the biologists wanted.

My skill as a software developer was not in my programming skills, but in my ability to identify and fix the underlying problem. When a biologist asked me for software that did A, I’d talk to them, realize that they were actually trying to solve problem B, and give them software that solved problem B by doing C. When I worked as a consultant, one of my clients said in admiring bewilderment, “You never give me what I ask for, but it always does what I need!” Similarly, the biologists at Signature eventually said “Eric just reads our minds!” when asked why they used my software over the software delivered by other developers.

I was thinking about this recently because identifying and solving the underlying problem seems to be a general concern of management. To take a concrete example, if sales aren’t meeting expectations, what’s really going on?

Is it that

  • salespeople aren’t working hard enough to generate leads?
  • the product doesn’t meet the needs of potential customers?
  • the wrong customers are being targeted with this product?
  • the advertising campaign doesn’t appeal to the targeted customers?
  • a competitor has better features?
  • a competitor has a better advertising campaign?

As a manager facing this situation, it’s important not to dive into fixing the problem without first determining which of these possibilities apply, because you could end up like those developers at Signature, doing a lot of work with nothing to show for it. It’s also important to not to get too attached to a single solution (like making your people work harder), because that’s the “everything looks like a nail” situation.

As an aside, I think this is the idea behind the theory of constraints in manufacturing, as described by Eliyahu Goldratt in his books The Goal and Critical Chain, but I haven’t read those yet.

This idea of first identifying the real problem also applies in the softer side of management. When somebody isn’t doing a task assigned to them, what’s going on?

  • They don’t have the technical capabilities to do the task.
  • They’re waiting for somebody else to finish a prerequisite.
  • They’re doing other things they think are more important.
  • They don’t think it’s a good idea, so they’re just not doing it.
  • They’re having issues in their personal life.

It would be easy to assume any of these and take action, but picking the wrong one could exacerbate the problem.

As an aspiring manager, I believe it’s impossible to distinguish between these various possibilities without actually talking to the employee in question. All the project management software in the world won’t help you figure out what’s really happening - such software can only provide an idealized abstraction of the situation. Five minutes of conversation can often identify the obstructing issue, and make it clear what the appropriate response is. I also believe that such conversation shows interest in the employee and makes it clear to them they are valued, but that’s a personal bias.

The difficulty of identifying the underlying problem is why the characteristics of reflection and thoughtfulness are so important in a manager. It’s too easy to jump on the first solution presented and spend resources without having any impact on the problem. You can tell the companies that do this - they unquestioningly adopt the meme-of-the-year from Re-engineering to Six Sigma to Total Quality Management to Agile Programming, hoping that this time it will solve their problems.

So when faced with a problem, don’t assume you know what’s going on and immediately start yelling out orders in an attempt to exude authority. Take the time to talk to everybody associated with the problem, figure out what they think is going on, get agreement on the problem and possible solutions, and go from there.

~ 9 Comments ~

Team player
Posted: June 22, 2007 at 8:45 am in journal, management ~ Permalink

This has been a week of reflection for me for several reasons. I’ve been thinking about what constraints are necessary for me to be successful. After reviewing situations in which I achieved great things in the past, I realized that a common element of those situations was being part of a team I cared about.

I like being on teams. It makes sense because I think by talking, and being on a team means I always have somebody to ping with ideas. Being part of a team means I’m part of a cognitive construct that is larger than just myself, and the construct literally has to talk to think (that’s a bit of a stretch, but think of Cognition in the Wild, by Edwin Hutchins, where he uses the case study of a navigational team to study cognition).

I work best on teams for other reasons. One of my strengths is an ability to bridge communication gaps between different disciplines. I can serve as an “impedance matcher” by talking to everybody on the team and making sure that information gets to where it needs to go. Obviously, this skill lies unused when I work by myself.

When I’m on a team, I feel a responsibility to others that I don’t necessarily feel to myself. If I’m performing an individual task and I don’t do a good job, then I’m only affecting myself. I can decide that I don’t care enough about the impact on my standing and give up or slack off. When I’m on a team, I have a responsibility to my teammates to do a good job that motivates me far more than my own welfare. It’s probably unhealthy, but my psyche is constructed such that disappointing others is worse than disappointing myself.

To take a specific example, Junior Lab, an experimental class for physics majors, was among the hardest classes that MIT had to offer. And I crushed it. Even though I struggled to get Bs in many of my other physics classes, I got a solid A and a recommendation for grad school out of Junior Lab. Part of it was that the class emphasized lab work rather than theory, but the real difference was that Junior Lab was done with a partner. I was willing to put in 40 hours a week on that class to make sure that Kent and I got good results, whereas in my other physics classes, I’d give up at a certain point because I just didn’t care enough about my own grades.

I had a similar experience in sports. I was a tennis player in high school. Tennis is a brutal sport for a perfectionist, because every point matters. A one point swing is huge in a game to four points. And each game matters because the set is only to six games. So every time I made a mistake and lost a point, the consequences loomed large. And I would stress so much about those consequences that I wouldn’t be able to function in competition. On the practice court, I could hold my own with our high school’s best player. In match play, I couldn’t even beat our worst player.

In college and later, I switched to team sports, first volleyball and then ultimate frisbee. Having teammates calmed me down, because I couldn’t afford to freak out and throw a tantrum when I had teammates counting on me. I had a responsibility to others, and that made all the difference.

I also like being part of something greater than myself. I don’t know if it’s being brought up in a Midwestern culture where showing off is frowned upon, but I’m uncomfortable with bragging about achievements, or sometimes even with the idea that I’ve achieved anything at all. Being part of a team means that I can take pride in sharing its achievements without triggering those neuroses about showing off.

Good teams are more than the sum of their individual members. The CellKey team was forced to work cooperatively because none of us knew enough about each others’ specialties for a leader to take charge. Developing that trust in each other allowed us to create something that leveraged all of our collective expertise. Such team success is a dual achievement - not only did the team succeed in its goals, but building a successful team is an achievement in itself.

Similarly, my favorite team in the two years I played in SFUL was a team without any stars (Hot Pink Optimator!). There was nobody on that team that was recognized as a great player in that league. But we each had skills to contribute and we figured out how to put those skills together. Plus, we liked each other and hung out after games together, which helped create camaraderie. In the season championship game, we were up against a team that had two of the best players in the league, a team that had rolled its way through the playoffs to that point. And we crushed them. We knew that if we could shut those guys down, their team would stop functioning because their teammates were reliant on them. Whereas our team was far more distributed, because everybody on our team played an important role.

I need to remember I function best and achieve more when I’m part of a team I like. If I want to do something, I should join a team that’s trying to do that rather than trying to go it alone. I’m also placing this in the management category because it reminds me of the motivational power of teams in getting people to do better work. It’s tricky creating teams that are more than the sum of their parts, but wonderful things happen when it works.

~ 3 Comments ~

Embracing constraint
Posted: June 8, 2007 at 12:33 am in journal, management, people ~ Permalink

A friend recently told me about his vacation where he felt surprisingly productive despite not having access to his normal resources (he only had a carry-on bag of clothes, a laptop and a couple books). Because he had fewer choices about what to do, he just picked a task available to him and started working on it.

In a similar vein, I read harder books when I’m on vacation. If I’m on a plane flight, my only choice is to read the book I have, so I will read it and enjoy it even though it’s difficult. When I’m at home, I’ll start it, but then I’ll check my email, watch some TV, or re-read a favorite sci-fi novel, and then it’s time for sleep.

It’s the inverse of the paradox of choice, which is when you become paralyzed by having to choose from among too many choices. When you have no choices, you can just get started.

It reminds me of a story from Zen and the Art of Motorcycle Maintenance. Pirsig was teaching composition in a college in Bozeman, Montana, and gave his students a 5,000 word assignment. One student came to him at the deadline and told him that she was unable to complete the assignment because she couldn’t think of anything to write about her chosen topic, the United States. He told her the U.S. was too big a topic for this composition, and to try again, with the topic of Bozeman. She remained stuck. He suggested the city hall of Bozeman. She remained stuck. Finally, in exasperation, he told her to write about the front of the city hall, starting with the top left brick. When she was constrained to that extent, she was forced to start writing, and ended up with a 50,000 word essay.

Sometimes it’s better to give ourselves constraints, to give ourselves less choice. It goes against our instincts - Stumbling on Happiness cites studies showing that we tend to choose options that give us more choices in the future. But the book also demonstrates that having those choices doesn’t make us happier. Sometimes the right thing to do is to embrace a lack of choice.

We’ve all done it. When you needed to study for a big test in college, you didn’t try to do it in your dorm room - you went to the library where there were fewer distractions. Writers don’t sit at home all day - they go to cafes where they’re alone with their manuscript (or laptops these days).

Giving yourself less options puts you in position to succeed. One of my beliefs about management is that good managers put their employees in roles where they are more likely to be successful. What I’m saying here is that we need to manage ourselves in the same way, and maximize our chances of success.

When I have a hard book to read, I need to head to the library or the park or a cafe where I won’t get distracted by easier pursuits. When I need to get a paper done, I need to turn off the Internet connection. When I plan to exercise, I need to prepare by getting all of my gear in one place so it’s easy for me to get myself out the door before I lose my momentum. Twyla Tharp’s “rituals of preparation” are the same idea - get oneself in a place, both physically and mentally, where you can do the task.

It’s similar to my idea about an attention management system. To-do lists can be overwhelming because there are so many things on there that we feel like we can’t make a dent so we never do anything. One of the key ideas was that the to-do list would only gave you one task at a time. No choices. Choice introduces uncertainty and the cognitive overhead of trying to make a good choice.

I need to remember this idea. Pick one thing, forget about my other options, then put myself in an environment where I can only do that one thing so I’m not tempted by the other options. Get away from my pathological need to increase my options and start choosing some of those options and getting things done. Something to think about.

~ 7 Comments ~

Artful Making, by Rob Austin and Lee Devin
Posted: May 29, 2007 at 9:15 am in management, nonfiction ~ Permalink

Amazon link

Subtitled “What Managers Need to Know About How Artists Work”, this book addresses the question of managing knowledge workers who are more independent than ever before. The authors study how a dramatic troupe puts together a performance for ideas on how to assemble talented and creative free agents into a coherent effort.

In the industrial age, people were given assigned roles and were told to behave like automatons, repeatedly reproducing the same movements, which led to the rise of Taylorism. But in the world of the Creative Class, such notions are no longer applicable. If a worker is a free agent that can choose where to be employed, treating them like a robot is sure to drive them away. Also, in a world where the pace of change is increasing, doing the same thing repeatedly is a recipe for failure.

To find a suitable analog for a free agent world, Austin and Devin turned to the world of the theater, where the entire team is thrown together on a per-production basis. Each team member has their special talents that they bring to the production. And no production is the same. Even when the same production with the same cast and crew is repeated on consecutive nights, the performances vary - the crowd is different, one actor may be in a different mood, the understudy may be needed, etc. Theater has had to incorporate change.

Austin and Devin see the process of art as being one of iterations, of trying different things to find out what works. Rather than try to replicate exactly what happened last time, artful making seeks to reconceive during each iteration, incorporating what was learned in previous iterations but trying something new each time. Whether it’s the weeks of rehearsal time needed for a play, or the dozens of sketches an artist does before the painting, or the different drafts a writer throws away before the final novel, iterations are key to finding the artful way through. To achieve “Artful Making” therefore requires reducing the cost of iterations in business, a point also made in the book Experimentation Matters.

Another key component of “Artful Making” is taking advantage of the specific resources available. As the authors point out, the goal of putting on a play is not to follow the script exactly because “the script is a wholly inadequate specification, lacking sufficient detail to control the rehearsal process the way plans and specifications control industrial processes.” The script is just a starting point, and it’s up to the company to adapt it to the actors, to the theater space, to the lighting and sound available, etc. This requires iterations and experimentation, trying to find out what works and what doesn’t. A scene may have been played one way in previous productions, but it doesn’t work with the actors in this production, so a new way of conceiving the scene must be found.

Directing a production is different than managing an industrial-era process, according to the authors. In Frederick Taylor’s world, the authors describe management as “Tell them what to do; fire them if they don’t do it.” But in a rapidly changing world, the workers may know more than the managers about what they should be doing - “Forcing workers to comply with preconceptions often hinders the overall making process.” So the manager/director needs to find a way to focus and harness the talents of their crew without restricting them from discovering innovative solutions.

One analogy I particularly liked illustrated different conceptions of control.

Lee borrowed a pen from a student, gripped it tightly in his hand, and waved that hand in the air. “See this pen?” he said. “I’m controlling it.” He swooped it around like a fighter plane. “It’s doing exactly what I want it to do.” Then he held the pen out in front of him. “Now look; I’m going to control it some more.” And he dropped the pen. It fell to the floor and bounced. He picked it up and repeated the gesture. The pen bounced again, quite differently. “See that? It did what I wanted it to, each time.” (attributed to acting teacher Milton Katselas)

I love this because I think it strikes to the essence of how to manage a diverse group of talents. Micro-managing somebody who’s an expert in their field is stupid because then you’ll only get out what you put in, so you might as well not even have the expert. But if you give them an environment that drives their actions, you can benefit from their expertise while still moving towards your goals.

To get that benefit requires creating a secure environment for experimentation. This means reducing the cost of iterations so that your team can try different things without fear of failure. Failure’s a misnomer in this case, because iterations that don’t work inform the reconception of the next iteration. The only failure is when an iteration doesn’t teach the team anything new.

Furthermore, the team needs to know that they can push the edge and not get punished. True innovation requires trying new ideas, stretching oneself past the point of comfortable ruts, and that requires management that supports such experimentation.

One last benefit of iterations is that it prepares the team for unexpected changes. Industrial replication processes are brittle because if anything changes from the expected inputs, then the worker doesn’t know how to react - they have not been prepared. In “artful making”, the team has been experimenting continuously through different iterations. They may already have tried something that will work in the new changed environment, and even if they haven’t, they can adapt and improvise because change has been part of their process. The iterations have laid the foundation for them to react at a higher level, where they aren’t thinking about how to just do the task, but how to achieve the greater goal of the ensemble.

Iterate more. Create the environment and the focus, but give up control to your team. It seems like it would mean chaos and no hope of making deadlines, but theater companies regularly get their productions on stage on time with a success rate far higher than most technology teams. Ideo’s process has similar elements, and they’re regularly recognized as one of the most innovative companies. I think it’s only a matter of time before such management techniques become ubiquitous. We’ll have to see.

~ 0 Comments ~

Laying the foundation
Posted: May 27, 2007 at 11:09 am in management, people ~ Permalink

Twyla Tharp, in her book The Creative Habit, tells the story of working on the musical Moving Out, set to Billy Joel’s work. She listened to all of his music, watched all of his music videos, read or watched every interview with him, watched iconic movies of the Vietnam war like Full Metal Jacket, read and watched correspondence of the war, watched TV dance shows from the era to remember what the dances looked like, reviewed news clippings from the era, etc.

Do all of these influences make it into the final work? Probably not. Do they play a part in how the final work evolved? Almost certainly.

It reminds me of a conversation I had a few months ago with Joel Johnson, a professional blogger and freelance journalist. I was picking his brain about the craft of writing, and we were talking about the ruthless process of editing. He told me that great journalists do interviews with everybody associated with the story and spend time in the library, accumulating an enormous amount of background material. Their challenge isn’t finding enough words to fill their piece. It’s finding the room for all the words they want to put in, so they have to cut every unnecessary word, every sentence that doesn’t contribute to the central idea of the piece.

Joel claimed you could tell the hacks because they hadn’t done the research and could afford to ramble. Alternatively, they went in with an idea, and only did the bare minimum of research necessary to find supporting evidence. The good journalists do the research, collect all sides of the story and then sift through their accumulated material to find the core of their piece. Once they have that core, it gives them the focus to cut away everything else.

As an aside, he recommended the work of Gay Talese, especially his profile Frank Sinatra Has A Cold, where he never actually got to interview Frank Sinatra but made the piece work anyway.

This approach also applies to the business world. While working on my master’s project, my mentor kept on pushing me to dig deeper, researching the competition, reading more material, etc. He reminded me that while the nominal deliverable was a brief business plan and a ten minute presentation, those were just the visible results. The real deliverable was an expert in the field, somebody who had done the research and could be trusted to make the right decision.

My mentor emphasized finding the core of the idea. The research was a necessary precondition to finding the idea that filled a market need by positioning the proposed product in the market, and that core idea evolved as I did more research. But finding that idea is what allowed me to construct the final presentation and business plan deliverables. I had too much to include in my ten minute presentation, so I had to pare away everything that wasn’t relevant to that core.

That “extraneous” research wasn’t wasted, though. I needed to have done it to find the core idea, and it informed what I ended up doing. It definitely made it easier to answer questions at my presentation because I had considered other options and knew why I had rejected them.

I find it fascinating that the same process is used in three seemingly divergent fields like art, journalism and business.

  1. Do directed but unbiased research
  2. Find and develop a core idea
  3. Edit away everything that doesn’t contribute to that core idea.

Doing that research up front lays the foundation for everything that comes later. You can’t find the best ideas unless you have considered them all. If you go in with a preconceived idea, your research will necessarily be limited to what will support that idea. And while it seems wasteful because that research isn’t used directly in the end resuit, it informs all of the creative decisions in the process of developing that result.

Research requires discipline, to keep seeking new sources and confirming that you aren’t missing anything. It can be drudgery, but it makes the end result better by laying a solid foundation. And so we return to the theme of discipline. Discipline is needed to not take any shortcuts, and to do the work necessary for the desired final result.

Are we sensing a theme yet in what I’m concerned about in my life right now?

P.S. We’ve been asked at work to start writing a corporate blog. If you want to know what I sound like in salesman mode, you can go read my articles about the company and its products.

P.P.S. I circumnavigated Manhattan on my bike yesterday for the first time. It’s about 30 miles and most of it is a nice ride, as there’s a bike path that goes about 90% of the way around the island. Yesterday was the first time I tried to maneuver my way through the 40 blocks of Harlem where there’s no bike path - I found a way through, but it wasn’t pleasant and I’ll probably just turn around and avoid it in the future.

~ 1 Comment ~

“The Guy” theory
Posted: April 10, 2007 at 7:57 pm in management, people ~ Permalink

[Apologies in advance for the sexism inherent in calling it "The Guy" theory - the people with whom I was having these conversations were all male, so it made sense in those instances, and I can't think of an appropriate gender-neutral term right now]

So I’ve been referring to “The Guy” theory in several recent conversations so it’s time to blog it up. Wes and I fleshed it out at breakfast last month. It starts with Phil Agre’s advice on becoming a leader in your field, where he says you need to pick a issue and become the locus of information for that issue.

Once you’ve talked to a couple experts and made a few contributions, other people start to hear about your work and contact you first. And then the process feeds on itself in a virtuous circle - you have a good network on the issue, so more people come to you to get in contact with the people you know, which increases the power of your network. To put it informally, you have now become “The Guy” that everybody else consults for that issue because you know everybody there is to know in that area.

The one time I became “The Guy” at a company it happened by accident. I got frustrated with our management team and spoke out about it. Other people at the company who didn’t feel comfortable speaking up in public then started getting in touch with me with their frustrations, so I became the mouthpiece for them. The more I spoke out representing others, the more people told their stories to me, and I was suddenly the equivalent of a union foreman for the company, representing the interests of the workers to the management team.

Charlie O’Donnell has had a similar experience of stumbling into “The Guy”-hood. Last year he started the nextNY networking group because he wanted to meet other tech people in New York, and now he’s considered one of “The Guys” of the technology scene here because nextNY has grown to 700+ people on the mailing list and he’s the titular leader.

So those are nice, heartwarming stories, but how does that help me moving forward? How do I become “The Guy”?

It almost has to be accidental because if you are trying to become “The Guy” in an explicit bid to gain power, nobody will trust you. You have to be genuinely interested in the people you are talking to and in what they have to say. You have to love talking about the issue so that your enthusiasm will infect your conversation partners and get them excited and talking to other people they know. They’ll remember who got them interested in the issue and come back to you when they have questions about it in the future.

So this post may not be useful for the Machiavellian pursuit of power. You can’t fake this stuff. It may be useful for centering ourselves, though. I’ve been thinking about this topic because I’m trying to figure out an issue where I can become “The Guy”. What issue do I care about enough to become the nexus? The theory and practice of management is a definite possibility considering that I spend so much time talking and thinking about management, here on this blog and in conversations with others.

Part of the reason I’m obsessed with this topic is that I’ve learned over the years that there are many issues where I can’t be “The Guy”. Physics. Programming. Sports. Art. Music. I don’t have the depth of interest to keep up with the people who really follow those topics. Again, the interest can’t be faked. I have a foodie friend who keeps track of the movements of chefs between restaurants the way most guys track their favorite athletes. I have other friends who read the reviews at Pitchfork with similar devotion.

One possibility is for me to try to become “The Guy” as a generalist. This is a really tricky one to pull off, but the idea is that if I have contacts in enough different areas, then I’m a great person to talk to when you have no idea who the first person to talk to is. If I can be the first link in any chain, then I’m always the right guy to start the conversation. I don’t have that sort of all-encompassing network now, but maybe that should be something I strive for. It certainly appeals to my tendency to dabble in many areas rather than focusing on any particular one. This actually reminds me of my post about innovation and community, where I suggest that because it’s so much effort to be at the center of a community (aka “The Guy”), innovation will come from those who can tie different communities together. As I say in that post, “there’s a real incentive to establish links to as many insiders as possible, to hear what’s happening first and see if you can figure out how to tie it all together.” I’ll have to think about that some more.

The take-home point? Pay attention to your interests. Seize upon opportunities to collect information and contact people about those interests. Talk about those interests with everybody you meet because you never know who might be a useful contact to expand your network. Before you know it, you’ll be “The Guy” and people will be contacting you. Revel in it for a while. Then as Agre suggests, find a new issue and start the process over.

~ 3 Comments ~

The Role of Context
Posted: April 9, 2007 at 11:09 pm in management, people ~ Permalink

Today’s topic on Scott Berkun’s mailing list for project managers was surprisingly divisive. The story: the project manager has a star programmer who is utterly pessimistic. The programmer does his job well but infects the rest of the team with his cynicism, leaving the project manager having to improve morale.

The first several responses all said “Fire him”. These responses all claimed that this person clearly was a cynical negative person, and that he was dragging down the performance of the team. No matter how good a programmer he was, he was a net negative contributor to the team. As a former cynical programmer (my cubicle was dubbed the nexus of the “Corner of Negativity” at one company), I immediately sympathized with the programmer, so I was shocked at the vehemence of these responses.

It also got me thinking about why the programmer might be so negative. Maybe he is seeing problems that the management team is ignoring (that was certainly a factor in my negativity at that company, which went bankrupt a year later). It’s possible that the programmer really is a hopeless pessimist who will think that the sky is falling no matter what, but I felt that it was extreme to jump to that conclusion.

Another interesting story crossed my bitstream today. A Washington Post staff writer convinced Joshua Bell, one of the world’s premier violinists, to act as a busker in the Washington Metro one morning during rush hour. He stood there, playing virtuosic violin pieces on his Stradivarius for 45 minutes, and got completely ignored by 95% of the passersby.

Why are these two situations linked? Because they both demonstrate the importance of context when evaluating something or someone. The Metro riders saw and heard a busker. Sure, he was good, but without anything to place him, they just hurried on by. Joshua Bell can command sellout crowds at concert halls, but without a marquee and wearing a baseball cap, he was just another violinist.

I believe in the power of context to reinforce behavior. When we’re in a Metro station commuting to work during rush hour, we behave in a certain way, regardless of what other elements are introduced, even if they’re utterly fantastic. We perform the same sequence of events each morning, we walk to and from work by the same paths, we eat lunch at the same places, etc. It’s only when we are ripped from our accustomed environments that we even examine our own behavior.

Which gets us back to that pessimistic programmer. By placing all the blame on the programmer for being “passive-aggressive” and “cynical” and “flawed”, I feel that the managers who were calling for the programmer’s head are ignoring the corporate environment. I mention this tendency in a post viewing art as a web where I dubbed it the object-oriented perspective, where we try to place “all of the properties of an object into the object itself rather than the network of relationships surrounding the object”. In other words, I think that it’s over-simplifying to blame the programmer without examining the environment as well.

Maybe the programmer really is beyond hope. Or maybe they’ve just seen things go wrong at other companies, and had their observations been consistently quashed by management, leaving them in a state of learned helplessness where they feel incapable of doing anything about the situation but be cynical. But I would think their experience is a resource that should be leveraged rather than dismissed.

My suggestion was that the programmer’s concerns should be addressed openly and publicly, and turned around on the programmer for ways to deal with those concerns. It would have helped me back when I was that programmer if somebody had said “Okay, genius, if things are going to go wrong, how are you going to help us fix them?” Instead it took me several years and a few different companies (contexts) to figure that out. Hopefully, if/when I become a manager, I’ll be able to figure out how to create the right context to make my employees productive and happy. We’ll see.

P.S. I felt compelled to post just because I love observing cross-connections like these. How many other people would see a connection between the Joshua Bell story and a project management issue?


just another violinist: When I first read the story, I thought I would probably have just walked on by like the rest of the commuters, but when I watched the embedded videos, I realized that I wouldn’t have. He’s _good_. I mean, like, wow. I played the violin for over ten years as a kid, and I could only dream of playing even one of the lines in the Chaconne as well as he was playing both simultaneously.

Interestingly, many of the people who stopped to listen to Bell turned out to be classically trained musicians, including several violinists. Perhaps it takes a certain level of skill to appreciate the difference between good and great, because only somebody who has attempted something knows the difficulty involved. I often feel that way in other areas where I don’t have the same sort of experience, such as art or jazz.

I’ve mentioned this before, but this story illustrates yet again that art does not exist in isolation. Art is a connection between the artist and the audience. In this case, without the surroundings of a concert hall and without an appreciative audience, Joshua Bell really was just another violinist.

~ 2 Comments ~

The Discordant Element
Posted: March 23, 2007 at 11:17 pm in management, music, nyc ~ Permalink

This evening I went to go see So Percussion perform Music for 18 Musicians by Steve Reich. Long-time readers will remember that I’m a complete nut for Reich’s work, so I was looking forward to seeing it again, especially since the other So Percussion concert I’d been to was enjoyable. Alas, I was incredibly disappointed.

My expectations were clearly too high going in. I’d only seen 18 performed by Steve Reich’s ensemble, a group that has been performing the piece for 30 years, and has it polished to an incredible level of perfection. Their total mastery of the piece and comfort with its rhythms allowed them to move beyond the performance into this whole other space of art and meaning.

Given my recent posts, it’s probably not surprising that my thoughts during the performance tied this back into management. It’s another illustration that no matter how great the plan is, the team must execute for the plan to work. In this case, I know this is a great piece, and I love the ways in which the chords build on themselves and the interplay between the different instruments. And when it’s performed as intended, it’s a spiritual experience for me. But when the same piece is performed short of perfection, it falls apart into a disjointed set of bangings. Execution matters. Experience matters. Deliberate practice matters.

So why did the performance not work for me? A few things I noticed:

  • The tempo was set just a bit fast, and they seemed to do each element the minimum number of times, so everything felt rushed rather than deliberate.
  • The performers were excited, which is normally a good thing, but they overplayed their excitement to the point of hamminess.
  • The sound mixing was off, so that the singers were sometimes inaudible and sometimes overmiked, making it hard for them to stay in tune with each other.
  • The violinist was out of tune - there was one exposed string section, where her A-string was painfully flat, and she kept on playing it and I kept on cringing.
  • The coordination wasn’t as tight, which isn’t surprising since the performers had come together for this one set of performances, but there was some noticeable awkwardness compared to the Reich ensemble.

Nothing major. No one thing that leaped out at me and ruined the performance. It was a combination of little things that didn’t quite fit.

This relates to one of the points I made in my last post, where I stated that a team can be greater than the sum of its parts. And when everything locks into place, the results are amazing. The musical analogy I came up with is the overtone series. When a chord is perfectly in tune, you can actually hear the higher order harmonics audibly. If any element of the chord is just slightly out of tune, the chord will still sound okay, but you lose the spine-tingling harmonics. Listening to a chorus like the Tallis Scholars is great because they nail their chords and all of the overtones just pop out of the texture. There are more notes being heard than are actually being sung.

Something similar happens in a well-functioning team. When everybody is pulling together and perfectly aligned, extra output just appears from the synergistic effects of the team. One plus one plus one somehow equals four. But here’s the downside - like the overtone series, if anything is even slightly out of alignment, you lose all of that bonus.

It’s interesting to me as a student of management because it demonstrates that getting 90% of the way there means nothing. It’s only when all aspects of an organization are aligned 100% does it really take off. This reminds me of Built to Last, where the authors point out that the successful companies have built the core values of the company into every aspect of the company. Doing 90% doesn’t cut it because it raises the expectations and then doesn’t fulfill them. To take a made-up example, a company could put all the elements of an employee empowerment program in place, but if one manager micromanages their employees, it may be even more demotivating than if the company had done nothing.

I think that’s what happened at the performance tonight. It was a solid performance, and most of the audience enjoyed it. But having seen two perfect performances, where I’d seen the synergistic effect of the performers and the piece feeding on each other, this was far short of that experience. And because it was almost good enough, it was almost more frustrating than if it had been just terrible. I wanted to like it. I almost liked it. But I ended up being disappointed.

The take home lesson is contained in the post title. Notice the discordant elements in your company. If something doesn’t align with the company goals, remove it. It might seem minor, but it could be preventing synergistic organization overtones from forming. It’s like Peopleware’s description of how to build a team - first avoid all the ways in which you can prevent a team from forming, avoiding teamicide. It’s also similar to the Broken Windows theory, where fixing the little things makes it easier to fix the big things because all elements of the system are then in alignment.

Of course, the first step to figuring out which elements are discordant is figuring out what the goals are. Until you know where you want to go, you can’t align everything else. But if you know what you want to accomplish, and you remove all the obstacles, even seemingly minor ones, then great things can happen. You’ll hear those overtones pop into existence and the company will achieve greater things than you thought possible.

~ 5 Comments ~