Amplify Your Effectiveness (AYE) Conference: Day 2
Morning Session: How Do I Communicate With You? (Don Gray)
This session explored interpersonal communication, in particular how to identify communication styles and preferences and apply this knowledge to communicate more effectively.
In one of the exercises, we broke into pairs and exchanged stories from recent memory. While one person told their story, the other observed their language, noting the types of predicates used (visual, auditory, kinesthetic, olfactory/gustatory and “unspecified”) as indicators of the speaker’s representational system. We used this data as the basis for a discussion about cues which indicate a person’s preferences, ranging from word choice to eye movement.
Another exercise divided the group into two based on personality type (Myers-Briggs “N” and “S”). Both groups were given identical objects (Starbucks paper coffee cups) and asked to write down descriptive phrases. The “N” group’s descriptions were wide-ranging, exploring the possible uses of the cup, the memories and meanings it evoked in them. The “S” group focused more on the physical properties of the cup, and where there were some comments on the ideas associated with it, these were carefully separated on a separate list.
A third exercise had us folding a piece of paper according to instructions read aloud. The instructions were ambiguous, and would be interpreted differently depending on how the person happened to be holding the paper, how they turned it as they folded it, or how they interpreted the sentences. Unsurprisingly, everyone ended up with a different pattern.
There was then some free-flowing discussion about communication styles where people in the group shared experiences of communication challenges. I learned more from these scenarios than from the exercises, which were covering familiar ground. The challenge, for me, is applying what I know about communication theory, by raising my awareness of patterns in real life situations. Practicing this through discussing examples was more helpful to me than exploring more theory.
Finally, the group was presented with a choice of whether to explore a canned scenario (a new executive looking for feedback from others in the organization) or a real-world scenario put forward by someone in the group. The latter option prevailed, but the scenario was a price negotiation with few details, which I didn’t think would be valuable for me. I excused myself and left early, purchasing a copy of Tom DeMarco’s Slack from the book table.
Afternoon session: Beyond the Org Chart Illusions (Jerry Weinberg)
This session alone would have made this conference worthwhile. In it, we explored the structure and dynamics of organizations from a first person point of view. The idea was to discover the tacit structures which make up organizational culture. Setting aside the “objective” description provided by an organizational chart or other such tool, we instead created individual representations of the organization as we experienced it.
To do this, we used an exercise based on Virginia Satir’s technique of family mapping. We each selected an organization we were familiar with, and drew a picture with symbols: first ourselves, then other people (both with no names or words), then physical objects and structures, and labels. We then overlaid the points of pain, pleasure, problems, plans, performance (high and low) and power in the organization.
Unsurprisingly, the diagrams were all vastly different in symbolism, structure, order, level and technique. Jerry focused the group on a pair of diagrams created by two different people in the same organization. The creators explained the meanings of the symbols they used, illustrating the problems faced by the organization. This spawned a discussion about how to address those problems, which occupied the rest of our time.
This discussion really got me thinking, and drawing parallels with my own experience. In particular, i identified with some of the fears and other roadblocks which prevented the people from taking action. One memorable point from Jerry was that you will never convince someone with logic to change something they did not arrive at through logic. I make that mistake a lot.
I also gained some insight on how companies can be successful despite poor management, at least for a time. For example, circumstances may favor the company, such as having little or no competition. Advantages like that don’t last, though, and when things change, the management gap can cripple the company.
I can’t describe here much of what I learned in this session, but I found it extremely valuable.
Amplify Your Effectiveness (AYE) Conference: Day 1
Morning Session: Project Patterns
I chose to attend a session entitled: Is this the Way We Really Want to do Things? Seeing Project Patterns and Changing What You Don’t Like (Johanna Rothman). My goal was to explore the causes of the troublesome patterns I see in projects at work. In particular, I see:
- Too many projects starting up at once
- Projects being instantiated without enough consideration for the probability of success (“is this a good idea?” rather than “can we realistically achieve this?”)
- Key people finding out too late about projects which affect them
All of these patterns lead to increased project risk, communication bottlenecks, low motivation, and high stress.
In the session, we conducted a simulation of a team, with engineers, a project manager, a senior manager and a customer. I took on the role of the senior manager.
In the course of the simulation, we received requirements from the customer, implemented them, and delivered products. While the team was working on implementation, I talked with the customer about what was coming next: what would happen when we delivered, what the next project would be, and so on. Part of the simulation was that I had to be separated from the group while they were working.
When we delivered the first batch of products, and the customer was happy with them, it was time to decide what to do next. We gave the customer a choice of two projects we had discussed, one of which was similar to the previous one (but larger scale and more involved), while the other was different. Despite repeated attempts, we could not persuade the customer to prioritize one over the other.
So, I decided that we should change gears and start work on the “different” project. It seemed to be of greater economic value to the customer, and simpler to execute. One of the engineers disagreed with this decision, but didn’t explain why. The project manager seemed to agree, and I left the team to work. They produced a prototype, which the customer liked, and with a few small changes it was accepted as a finished product.
To my surprise, though, I found out later that the team was in fact working on both projects at once, delivering two different types of products. The decision hadn’t actually been made. These unexpected products were delivered to the customer, but didn’t meet the expanded requirements, and that work was wasted.
The debrief which followed was unfortunately too short, and I didn’t feel that we were able to fully explore what the simulation had revealed. The project manager indicated that he hadn’t understood the decision to have been made, pointing to a communication failure.
This reminded me that while we often think of a decision as an event which happens at a point in time, it is more commonly a process of change, which takes time and must be revisited in order to check progress and evaluate. A decision is really just an idea for a change, and there is more work to be done in order to implement that idea. This can be true even when there is a very explicit “decision point”: it still takes time for that message to be received, interpreted and accepted.
One of the tangents we followed during the debrief had to do with how humans think about numbers. Jerry asked each member of the group to write down a random number, and then we wrote them all on a flipchart. They were: 8, 75, 47, 72, 45, 44, 32, 6, 13 and 47. This reminded me of the analyses of election results which indicate fraud.
Afternoon Session: Saying No
After lunch, I decided to attend Jerry Weinberg’s session, Saying No That Really Means No. This was much larger than the morning session, with over 40 people sitting in a large circle.
The subject of discussion was the variety of difficulties that people face in saying “no” to things which don’t seem right for them. For example, saying “yes” to a project which is doomed to failure. This seemed like a good follow-on to the morning’s exercise.
Jerry began by asking the audience to name some of their difficulties, and tell stories of times when they had trouble saying “no”. One of these stories was role-played and analyzed as an example. Most of the time, though, was filled with storytelling and discussion.
This is a deeply complex topic, because this problem is rooted in self-image, social norms, egocentrism, misperception, and other cognitive phenomena. There was no key insight for me, just a reinforcement of the necessity of self-awareness. The only way to avoid patterns like this is to notice when they are happening, and that can be challenging, especially in a stressful situation.
Once you realize what’s happening, there are all sorts of tools which can be applied to the problem: negotiation, requests for help, problem-solving, even simple inaction.
Ubuntu Server Edition 9.10: No hardware required
In the 9.10 release of Ubuntu Server Edition, we introduced something new for people who are exploring cloud computing using Amazon’s Elastic Compute Cloud (EC2).
If you haven’t tried it yet, EC2 is essentially an API for managing virtual servers. Using a command line tool or script, you request a new VM, and moments later, it is ready for you to ssh in, preconfigured with your ssh public key. When you’re finished, you shut it down, and receive a bill for only the time and Internet bandwidth you used (about $0.10 per hour and $0.10-$0.17 per gigabyte). There is no downloading, no installing, and no hardware required for you to set up a server. The first step is to boot it up.
Starting with release 9.10, every release of Ubuntu Server Edition is simultaneously available on EC2. This means you can have a new Ubuntu server up and running using your EC2 account with a single command. Ready-to-run Ubuntu machine images are published on EC2 whenever a new Ubuntu release or milestone is available. All you need to know is the AMI, a short string which uniquely identifies the image you want. The AMIs for the 9.10 release are on the download page, in 32- and 64-bit versions for US and Europe zones.
Similarly, all Server Edition development builds are available on EC2 as well. When the first builds of Lucid (Ubuntu 10.04) are created, there will be AMIs for those as well. If you want to test drive a new feature, or check compatibility with your application, just fire up a new instance on EC2, do your work, and then terminate it. The whole process can be completed in less than a minute. If you find a problem in our development builds, just run ubuntu-bug on the virtual machine as you normally would, and apport will automatically attach the relevant EC2 details to your bug report.
As I mentioned above, EC2 does charge for Internet bandwidth. It does not charge for local bandwidth within your EC2 zone. For this reason, Canonical has set up Ubuntu archive mirrors within EC2, so that you can download all Ubuntu packages and updates for free. Ubuntu virtual machines inside EC2 are automatically configured to use the appropriate mirror, so you don’t need to think about it.
This is an exciting step forward in making Ubuntu more convenient and powerful to use on EC2, and I encourage you to give it a try. If you’ve never used EC2 before, just follow our Starter’s Guide to get set up.
Amplify Your Effectiveness (AYE) conference: Day 0
The AYE conference is an annual conference “designed to increase your effectiveness—in leadership, coaching, managing, influencing, and working in teams, whether you work in systems development, testing, product development, quality assurance, customer service, or consulting.” It starts tomorrow, and I’ve arrived today eager to meet the other attendees and see what the conference is like.
My work involves all of those things, but the main reason I decided to attend was that I learned a lot at the Problem Solving Leadership workshop, which I attended in January and wrote about on this blog. When I heard about this event, organized in part by the same people, and realized I would be in the US that week anyway, I seized the opportunity to attend.
The 2009 program is overflowing with sessions on topics I’m interested in, some of which I have written about here previously.
The speakers are all people whose insight I’ve appreciated through their writing, speaking and teaching, so I expect I’ll have a tough time deciding where to spend my time these next few days. The sessions are said to be experiential ones rather than lectures, so I don’t think that I’ll be able to hop between them, but I’ll see tomorrow when the main program starts.
Multivac emerging
Science fiction writer Isaac Asimov envisioned a computer called Multivac, powerful enough to process all of the planet’s data. Humanity painstakingly collects massive quantities of information to submit to Multivac on a daily basis, in exchange for the opportunity to ask questions of it.
With so much information at its disposal, Multivac is capable of amazing feats of analysis and prediction, which guide humanity to resolving global problems of war, poverty and so on.
The corporate mission statement of Google, Inc. is to organize the world’s information and make it universally accessible and useful. Google constantly processes information from the web, books, and photographic imagery from space and from the surface of the planet. Its famously simple search interface invites humans to ask it about anything, and it provides instantaneous answers in the form of references to information it has collected.
Google is not yet capable, in general, of providing meaningful answers to natural language questions, though research is ongoing, and systems like Wolfram Alpha hint at more abstract manipulation of data at a global scale.
We seem to be edging closer to Asimov’s vision of Multivac. What would you ask Multivac, given the opportunity? How will our future reality differ from science fiction?
Open vs. open vs. open: a model for public collaboration
Introduction
In the course of my work in Canonical and Ubuntu, I hear from a lot of folks who want to start an open software project, or have started one and want to make it work better. Some of them represent companies, while others are working on a volunteer basis. It’s great to see so much interest in this area, and I’m excited to see so many projects wanting to become more open.
The trouble is, people don’t always mean the same thing when they talk about “opening” their project. The focus of this article is to establish a basic model for open collaboration which I hope will be useful in future discussions of this type. In the spirit of openness, rather than creating a document for my own use, I’ve opted to develop this on my blog instead. This is not a how-to document, just a map of the problem space.
I’ll use examples from software projects, because I’m most familiar with that field, but I believe these principles are more broadly applicable.
Open (available)
In order for your project to be open to anyone, they need to be able to find out about it and experience it for themselves.
Being open, in the sense of availability, is about ensuring that the people you want to reach have access to your content. The types of access that people need will vary depending on the content, but the basic principle is enabling people to obtain and use the content in an appropriate way.
For software projects, this means that the code is released under a free software license. This allows all the various denizens of the free software ecosystem to make use of your software as appropriate for their role: developers can inspect and improve it for themselves, packagers can standardize and distribute it, and users can download and run it.
Availability seems to be the most well understood type of openness. Even so, many project leaders still hesitate, and delay availability as long as possible (“until it’s ready”). What’s more, many projects simply stop there, and never explore the other dimensions of openness.
Open (transparent)
The next flavor of openness is about transparency. This means enabling people to find out about what is happening in your project. This means moving beyond the end result (e.g. software), and starting to involve people in the creative process behind it.
In an open software project, this means allowing read access to discussion forums, source code history, bug reports, and so on. It means letting people see into the “sausage factory” where the software is made.
This is much harder than slapping a license on your source code. Not only does it require the infrastructure to store, process and present this information, it also means revealing yourself. Creating products is about simplifying things for its consumers, letting them get on with their work without worrying about how or why the product exists. Successfully opening a project means going beyond this producer/consumer relationship and letting them see inside. This gives people the opportunity to get excited about what’s coming next, and to build on it.
This can be a very difficult adjustment to make. Becoming transparent means letting people see the problems with the project as well as the solutions. This opens up the project and its members to criticism, which they will need to process and even respond to publicly. This is a whole new level of accountability which may be unfamiliar to people working in private industry.
Another challenge of transparency, at least in a corporate scenario, is maintaining confidentiality where necessary. While most discussions and activity should be transparent, customers, partners and management will require that some information remain confidential. Care needs to be taken to ensure that neither transparency nor confidentiality is compromised.
Transparency enables the formation of a true community, made up of more than just consumers. Community members can begin to feel involved in the project, and build relationships with project participants.
Open (for participation)
The third type of openness is open participation. This builds on transparency by creating a feedback loop: people observe activity in your project, react to it, and then actually change its course. The change might be a small one, like helping to improve your work in progress, or a large one, like helping to redefine project goals.
In a software project, this means things like opening up read/write access to the source control repository, design documents, and bug reports.
This type of involvement promotes a sense of shared ownership for everyone involved in the project, not just its founders. It becomes “ours” rather than “yours”. This can be psychologically challenging, as it means giving up full control, and being subject to checks and balances of power. Corporate projects seem to have the most difficulty with this.
A fully participatory project will support open participation in even the highest levels of decision-making, for example through leadership elections which are open to anyone. The community becomes central, rather than auxiliary, and the success of the project will depend on it.
Conclusions
People and organizations who want to truly “go open” need to see this as a journey, one which will require that they change their methods of communication and decision-making, not just how their content is published. The extent to which they are able to fully embrace the open paradigm will determine the potential benefits to the project.
Problems expand to fill available space
At any given moment, I have a set of open problems in my life. On my good days, I’m working on the most important one, aiming to solve it as quickly as possible. Otherwise, my most important problem is that I’m not working on my most important problem!
From time to time, I manage to solve a problem, and can remove it from the list. As a side effect, my #2 problem “gets a promotion” and becomes #1 (thanks to Jerry Weinberg for this analogy).
The problem at the top of the list, by virtue of being a focal point, can easily seem bigger than it is. As humans, we normalize our point of view based on what is happening to us. If we apply conventional productivity wisdom and focus exclusively on our most important task, that task consumes all of our attention. Being constantly in this state can be very productive, but also create a problem orientation. I experience this as a feeling that I am constantly surrounded by problems and never “catch up”.
At times like this (if I’m aware and realize that it’s happening), these are some of the things that help me recenter myself:
- Devote some attention to reviewing what I’ve accomplished recently, to remind myself of progress
- Ask myself if my #1 problem is actually urgent, or if I’m just on a roll. If it’s not urgent, consider taking a break from problem-solving and work on something else important for a while
- Give away some problems that I’m holding onto but don’t need to own
- Remind myself that this feeling as a side effect of where I focus my attention, and I can therefore influence it
- Laugh
Free software is so easy…you don’t even need a keyboard!
For some time now, I’ve been using a LinkSys NSLU2 as a file server for my home network. It’s very small, has no moving parts, and uses relatively little electricity. Combined with a large USB-attached hard disk, it has worked very nicely overall. My only issue has been that it is somewhat underpowered: with a 266MHz CPU and only 32M of RAM, it just wasn’t as responsive as I would like.
This weekend, I finally got around to replacing it with a newer unit based on the Babbage 2 design, with an 800MHz CPU and 512M of RAM. This should be much faster, and let me run more services than just Samba and rsync.
The only trouble was, the console interface on the new system is VGA and USB. I have a VGA monitor at home, but I don’t have a keyboard. I used to be the sort of person who had cabinets full of spare computer parts at home. Before my transatlantic relocation, I lightened my load substantially, and have only one small box now. This box did not contain a USB keyboard, and our only computers at home are laptops and netbooks.
Fortunately, the unit had a build of Ubuntu installed on its internal flash, configured to log in automatically to a graphical desktop. Using a dust-covered USB mouse I found in the bottom of the parts box, I copied and pasted letters from the gnome-terminal help files to install openssh-server, so that I could login over the network and finish setting it up.
It has now replaced the NSLU2 and is much snappier.
Explaining to girls
There has been some discussion recently about Mark Shuttleworth’s keynote at LinuxCon, in particular a comment he made in passing about the need to explain to “girls” about free software. I haven’t had much time for writing since then, but a few people have asked me what I thought about it, so I thought I should say something.
First, a few things to note:
- Yes, I was there, in person, at the event, in the audience, during the keynote
- Mark is my direct manager at Canonical, and occupies various positions of authority in the Ubuntu community
- I am speaking mainly for myself, and in part on behalf of the Ubuntu community (not Canonical)
- I briefly spoke to Mark in private about what he had said, shortly after his talk, before saying anything publicly
The remark in question was sexist, and although it may seem small in itself, it is representative of an attitude which is harmful to the community.
I think that Mark cares about the health of the free software community, and the Ubuntu community in particular. I don’t think that he set out to exclude and alienate women, but he did so without meaning to. It was a mistake. It was a mistake which very likely had deep, unconscious roots. I make such mistakes myself, more often than I would like. My own mistakes are the most difficult to see and grapple with, so I can identify with his situation. I, too, care about the health of the community, which is why I’m speaking up.
Mark probably didn’t realize that he was othering, or invoking a pattern of men explaining things to women. His intent was to make his (overwhelmingly male) audience laugh, and they did laugh. Now, it’s clear that some people didn’t find it funny, and were made uncomfortable by it, some to the extent that they want nothing to do with Ubuntu because of this attitude. The fact that it was “only a joke” doesn’t change that. They know it was intended as a joke, and they still feel this way.
This sort of mistake is very common, common enough that there is handy reference material which explains how to handle it without making it worse. There have been much more severe incidents in the free software community this year, with more lasting effect than passing comments. This one is pretty easy to correct, and I hope that Mark does so. It would send the message that we mean it when we say that a community where people feel uncomfortable or threatened is not a productive one.
Quick quote: population growth
This is too long for identi.ca and Twitter, but too good to pass up:
“It’s no coincidence that most of those who are obsessed with population
growth are post-reproductive wealthy white men: it’s about the only
environmental issue for which they can’t be blamed.”
Quote from Stop blaming the poor. It’s the wally yachters who are burning the planet in the Guardian.
(via Kevin Smith)
