Live Mesh saves the desktop

I installed Microsoft Live Mesh a couple weeks ago. I thought, “that’s a pretty icon; what now?” It didn’t revolutionise my life immediately.

First I discovered that it’s a nice way to shift files between home and office. I created folders on the desktop of both computers that stay synchronised automatically — and glow blue (indicating the proximity of grues?). And I can access these folders over the web from the Live Mesh web site. Nice.

One of my favourite Microsoft apps is OneNote. I use it as a to do list, for writing ideas, as an ad hoc bug tracker for simple projects. I pretty much start organising anything in OneNote then switch to a more formal solution as needed. In this sense it is much like a blank sheet of paper — versatile for any purpose but not specialised. The big problem with this application is that I open it at work and see one set of information, then I open it at home and see different information. This doesn’t help me if I have the wrong idea in the wrong place, which I do constantly as I’m always thinking around things.

So the Live Mesh epiphany came when I discovered I could add my entire “OneNote Notebooks” folder to the Live Mesh. This was, I should add, a slightly terrifying experience, and in retrosppect I should have taken a copy of the folders first. But it worked. And now my notes are synchronised everywhere. That’s how it should be.

When a company is as devoted to the desktop as Microsoft, and when its competitors seem to be delivering “your information anywhere” via web apps, you can see why they need this technology. Unfortunately, they needed it several years ago.

Try it out: http://www.mesh.com/

Interestingness

Just what is it? Flickr seem to know how to define it, but I’m not sure. When you have a community site that has a quantity of material added to it every day, how do you pick out a few things to highlight? Sure, you can show all the new content, but it whizzes by so fast, and one interesting article could be buried by another user uploading 20 pictures of their cat. You could constrain it to one item per user, but that only scales so far as well. At a certain point, the application needs to start deciding which stuff to promote.

I have been thinking about interestingness recently. What is it? A person can look at a picture and say “that’s interesting” but a computer can’t do that. How can it gauge interestingness?

• Novelty. New stuff is more interesting. OK, but on its own this is not much.
• Demonstrated interestingness. If an article is getting a lot of views, comments or ratings, then it’s probably interesting and worth highlighting.
• Reputation. If a user has produced interesting content in the past, then chances are that thier new content is interesting too.

The problem with just relying on demonstrated interestingness is that content might be buried before it has a chance to prove itself. The fundamental problem with the whole concept is that it is all self-fulfilling. If the application decides item X is interesting, then item X is promoted. Item X receives more attention, so the application decides it must be interesting….

One way to address this is to demand growth in attention. If attention is growing then it’s interesting, but if attention has peaked, then it’s time to promote something else.

I am not sure of the answers, but I feel that two factors need to be calculated daily: user reputation and object interestingness. Reputation is really an aggregate of the user’s objects’ interestingness. Interestingness is based on newness, “buzz”, and the author’s reputation.

How bad infrastructure destroyed a business

This is a little old, but still interesting: the unfortunate demise of Ma.gnolia. Ma.gnolia became a global link management and sharing application. Yet it was run out of one MySQL database and a few Mac Minis, with a staff ranging between 1 and 4. It never turned a profit. However, when the database became corrupted and the backups failed, the entire service disappeared.

As a small web entrepreneur, you spend a lot of time thinking about cool ideas and how to serve the community, a bit of time thinking about how maybe one day you might be able to make some money, and zero time thinking about infrastructure. It’s all about personality types (and it’s also all about just not having time). However, it’s worth thinking about what could destroy your idea.

A  25 minute video interview with the creator of Ma.gnolia:

• Here: http://ma.gnolia.com/
• Or here http://vimeo.com/3205188

Product road maps: excitingly controversial

You just know that when something seems sensible, 37signals will come along to explain why it’s not. Take product road maps.

I am starting a programme of engaging product managers who will be in charge of product road maps for all the in-house applications here. We have many applications which do, and don’t do, many things. How do we decide what things to shift from the “don’t” to the “do” part of the Venn diagram? Well, the developer can make ad hoc decisions when they have time. Or we can implement road maps, where the product manager can gather opinions then make judgements about development priorities, then lay it all down as a “road map.”  It’s just a way of remembering what to do next. What could be wrong with that?

37signals argue that you are making flimsy promises to customers that are based on inadequate research and that lock you into a particular development path:

You get to reap the glory of announcing desired features without even a downpayment of work. It takes no design, no consideration, or even discipline to respond to feature requests by making them a bullet point on a road map. It’s like buying goodwill on credit, but what you don’t pay for now, you’ll pay for later with interest.

Sure, but that’s only if you publish your road map. In comments on their article, they further argue:

A road map for an individual product that doesn’t have strong dependencies to other releases is a lot more questionable in value. What exactly are you getting out of deciding 3, 9, 18 months in advance what to work on? What extra powers are you gaining? I’d say very little.

On the other hand, I think you give up a lot. First, you succumb to the belief that you actually know where you’re going that far out in the future. Which is likely to give you blinders on for where you could be going, opportunities you could be pursuing.

Old guy is right in a sense. No functional specs, no product road maps, all these artifacts are about trying to pin down the future by elevating guesswork and fingers in the air to “science”. I think that’s an unfortunate, and mostly unnecessary, way to drive product development. So we push back against this fortune teller-driven approach in all it’s shapes and forms.

 And later:

We certainly have ideas of stuff we’d like to get done in the future, but we never schedule more than a few weeks of work and we rarely even bother writing ideas further out in the future down. I don’t think that qualifies as a road map.

While I agree that publicising or sticking too rigidly to your vague future plans could be misguided, I feel that 37signals’ aversion to future thinking and planning is pathological.

Further reading:

• TechRepublic: “Product road maps drive internal development projects“, November 2002
• Signal vx Noise: “You don’t need a product road map“, November 2007

The problem with bonuses

The Catch-22 – the fatal flaw with all numerical targets and quotas – is that to be understood and acted on, incentives must be simple. But if they are that simple, in any organisation with objectives more multidimensional than a whelk stall, they are simplistic: inadequate to carry the information necessary for the accomplishment of other goals. It’s impossible to specify a simple target for a complex organisation. Hence . . .  the lament of Andy Grove, formerly CEO of Intel, that for every incentive the company devised it had to implement at least one more to mitigate the harmful effects of the first.

[I]t’s death to the co-operation and teamwork on which overall organisational performance depends. From sports teams and university departments to publicly quoted companies, the greater the pay inequalities the worse the results, whether in terms of collaboration, productivity, financial performance or product quality.

– Simon Caulkin, “However good the pay, it doesn’t buy results”
http://www.guardian.co.uk/money/2009/feb/22/pay-bonus-financial-sector

Bad apples in teams

This American Life recently looked at the research of Will Felps, discussing “bad apples” on teams — slackers, depressives, and jerks — and how these individuals can have a disproportionate negative impact on the team.  In all but one research team, the bad apple (played by an actor) decreased the team’s ability to deliver on its goals dramatically. The one team that succeeded by performing as well as the control teams also happened to have the son of a diplomat in its membership. The thesis is that negative participants can impact teams adversely, but that strong facilitation can manage that impact.

For me, there are several angles:

• Keep bad apples out of teams. In a small workplace, that’s just not realistic. However, nurturing alliances with other members outside of meetings could help.
• Help these people work better in teams . For negative blockers, use the “OK so what’s your suggestion?” approach that Derek Powazek discusses.
• Am I ever that person? If I’m not helping, I should learn to opt out. If I have a criticism, do I have an alternative suggestion?
• How is my facilitation? Can I manage the impact of undermining staff?
• With blockers around, is consensus decision-making a bad idea? The flipside of consensus is that every participant has the potential to veto any positive step. I favour an informal consensus approach works in the office. Where we discuss and hopefully everybody is convinced — that way we attain the best ideas and buy-in. And if that doesn’t work then the mob rules.

[Note: I don't want to imply I work with "bad apples" but I think we can all be guilty sometimes of being a little too negative, and it's all too easy to sap the productivity of other staff. Productivity in the workplace is a team event.]

References:

• This American Life episode 370: Ruining it for the rest of us
• Derek Powazek: What’s your suggestion?
• Consensus killed the cat, Bettina Grassman

Word 2007 Subversion

As a note a propos of nothing, we recently discovered at the office that Word 2007 documents behave interestingly in a Subversion repository. You can see version differences in side-by-side views right inside of Word, for example. This is useful as we now store all our documentation files alongside application files in a Subversion repository. I understand that Word previously have some kind of document versioning built in. I wonder what it all means.

Resilience

Resilience is the capacity for a system to absorb change and return to its original state or stabilise in a new state. In a business environment, resilience is a goal of management, and might be translated as the ability to accommodate changing and competing demands by changing plans. The result of resilience is decreased business risk. I spend time every week planning the time of other developers. It’s something like piecing a puzzle together. However, it is more complicated than that:

• I need to ensure it is a participatory process: Developers like to be involved in negotiations over their work queue, and that leads to a better result anyway.
• The pieces change size: I need to allow projects to run over time without impacting other projects.
• New pieces appear: I need to allow for queue jumpers. It is not unusual for a developer’s work to be planned out six months in advance. But I need to ensure there are gaps in that period for work that has not yet become known. 
• Starting over: There is no fixed puzzle solution, although there is an optimum one at any given week. Every week I reconfigure the plan, sometimes shifting work around. I try to avoid this as it is inefficient and demoralising for developers to be given work then have it taken away again. It is important that they are part of the decision process so that they agree it is the best solution rather than just having it thrust upon them.

Here are the factors that provide us with resilience:

• Regular review of and changes of plans. It is essential that developers are involved in this so that they buy into the change rather than resist it.
• Staff redundancy. If only one staff member can wortk with a particular client then that reduces our resilience. A goal is to distribute knowledge and skills. While specialisation is valuable, a degree of redundancy is also valuable.
• Time redundancy. Staff are assigned only 20 hours per week of planned project work, so that the remaining time is available for unplanned work. Gaps are inserted between projects so that overruns do not impact the next project. Internal projects are spliced between client work. If necessary, the internal project can be moved in order to accommodate client desires.
• Interruption management. We employ support staff in order to handle the day-to-day hassles and keep the senior developers focussed. Support staff have projects of their own, but we allow greater timeframes for these projects.
• Training and learning. We run seminars, share knowledge and try to select projects for developers that will help them diversify their skills.

With all this in place, we are still only moderately resilient. Problems we face are:

• Resources: low staff numbers limit redundancy.
• Expertise: the distribution of knowledge about our most technical clients is low.
• Project commencement lag: delayed commencement of planned projects undermines my planning and ties up a developer unnecessarily for weeks.

Resilience is a discipline of study, and Brian Walker has done some interesting work in looking at ecological resistance. What is striking about this work is that it applies to the business management environment just as well as it applies to an ecosystem.

• Wikipedia: Resilience (Ecology)
• Big Ideas: Resilience Rules. Audio lecture by Brian Walker.
• Resilience, Adaptability and Transformability in Social–ecological Systems. Short article by Brian Walker et al.

Translating:

• A state is a plan, planned delivery dates and staff assignment to projects.
• Latitude is the amount things can change without needing to revise the plan. This is provided by time reduncancy above.
• Resistance is the difficulty in changing the plan. This is reduced by actually having a written plan as the impacts of a change become known. Redundancy and consultation reduce resistance.
• Precariousness is the degree of closeness to a threshold and therefore the likelihood of imminent change. It is important to minimise the amount of precariousness (i.e. to boost decisiveness) as it reduces efficiency by having staff either unable to start work or investing time in learning about the wrong work. Precariousness also leads to a sense among staff that work simply isn’t being planned at all, and this undermines staff satisfaction with management.  Involving staff in changes of plans is critical.
• Vulnerability is the degree to which a system is unable to change, and is the reverse of resilience. If we simply have to decline work then that is a business vulnerability.

Creating a killer website, literally, kinda

So I just poked around in Google Analytics to discover that visitor numbers for Tramper.co.nz are up 30% on last year. From the number of visits and average time spent per visit I found that the site is consuming 13,374 hours of visitor time per year — that’s 6.7 human work years (or “full time equivalents”) per year, and far greater than the amount of time I spend working on the site. Over the course of its lifetime, this site could easily fill several aggregate human lifetimes, and it’s not an expecially busy site.

Figures like this are a good reminder of the responsibility we have to create usable, clear designs: Confusing design is killing FTEs. I know: shocking.  Beyond that, it’s a humbling reminder that we need to think about quality: people are spending their valuable time on the stuff we produce.

And, of course, spam = mass FTE murder.

Gallup Q12

The Gallup Q¹² is a set of 12 simple questions designed to measure employee engagement in the workplace. The employee answers each question on a scale of 1 to 5. High scores in this survey have been correlated with lower employee turnover, better productivity,  improved customer relationships, and increased sales growth.

The result reflects not on the employee but on the quality of management. It covers issues that are generally remediable, so the results form both a numeric gauge as well as an actionable hit list. Qualities considered are: 

• Resources, clear direction and guidance
• Feedback, and acknowledgement of successes
• Empathy and caring
• Listening and valuing input
• Commitment to assisting with professional growth
• Being part of a team

As the survey is copyrighted, I’m simply going to link you to it. The questions themselves are here: http://gmj.gallup.com/content/811/Feedback-Real.aspx , where you can read some stories about the simple test in action.

Engagement, engagement, engagement.