Month: April 2014

Owen Barder on taking control of email

obI’ve just come across this post from Owen Barder, from back in 2012, providing his tips on managing email a bit more effectively.

Owen has a triage system for email which is based on four D’s:

  • Deal with it –
    If I can deal with an email in less than four or five minutes, I do so right away. For example, some emails only need a quick, one-line reply. It is better to do this right away than to have to deal with email again later.
  • Defer it –
    There are some tasks which will take longer than five minutes, or which cannot be dealt with immediately because they require additional information or some action by someone else. These I tag with the date on which I want to deal with them – either today or on some future date. That gets the email out of my inbox and ensures that I’ll be reminded of it again when I need to come back to it.
  • Delegate it –
    If I am going to delegate a task, I try to do so immediately when I am triaging emails. That way I can give as much time as possible to whoever I am asking to do the job. I usually then defer the original incoming email to the time that a response is due. When that email reappears in my inbox, it reminds me to check that it has been dealt with.
  • Delete or file –
    If an email does not require any action, but I want to keep it to refer to later, I either delete it or (more usually) file it.

Owen runs through this process only three or four times a day, and has switched off any realtime notifications of new email, so it doesn’t cause an interruption.

Another key part of Owen’s workflow is the use of a folder called ‘Today’ where all the email that needs to be actioned on the current day is kept.

Owen lists the reasons why this system works for him:

  • A trusted ‘to do’ list –
    There are few things more uncomfortable than the feeling that you may have forgotten to do something. It is very stressful trying to keep everything in your head at once, and it makes it difficult to concentrate on the thing you are working on at the moment. We need to park those tasks somewhere and be confident that they will come back to us in good time to handle them. By putting a particular date on each email, I can get the email out of my ‘inbox’ and off my desk, secure in the knowledge that it will reappear on my screen on the day I need to do something about it.
  • Zero inbox –
    For many of us, it is important to keep an eye on our inbox, and to deal with urgent emails as they arrive. But if our inbox is also our to-do list (and, in some cases, a filing cabinet), this means that every time we turn to our inbox, we are also confronted with an unsorted list of all the things we need to do. With the triage system, the inbox contains only recently arrived, unread emails. There is something very satisfying about having a generally empty inbox.
  • Avoid reading emails again and again –
    Emails used to sit in my inbox for weeks – I wanted to do something about them, but I was not yet ready or they were not yet urgent enough. I would read them again and again – sometimes several times a day – to check what was important or approaching a deadline. With the triage system, I read each email when it comes in. Many of them I deal with there an then; the others are put aside until the day that I have designated to handle it. I still read many emails too many times, but it is much less often than it used to be.
  • Create space for today –
    Because I live mostly in my ‘Today’ box, not my inbox, I have more time to concentrate on the work that I should be doing. I do not anxiously monitor incoming emails, because I know I will look at those later in the day.

Hopefully there are some useful tips in here that others can pick up for your own email productivity and workflow.

What’s your preferred system?

Founders at Work

foundersatworkAm currently reading, and very much enjoying Founders at Work by Jessica Livingston of Y Combinator.

It’s basically lots of interviews with founders of companies that were once startups about what life was like in the early days.

The book’s blurb sells it well:

Founders at Work is a collection of interviews with founders of famous technology companies about what happened in the very earliest days. These people are celebrities now. What was it like when they were just a couple friends with an idea? Founders…tell you in their own words about their surprising and often very funny discoveries as they learned how to build a company.

It’s an impressive list of people, too, including:

There loads more too. What I like is the mix of new digital startups and some stories from earlier in the story of the technology based startup, particularly around the time of the birth of the personal computer and software industry.

Funnily enough, as I started typing this post, I got notification that Tim Dobson had written a book review post of this very tome! It’s well worth a read through his detailed notes, but his concluding paragraph sums the whole book up well:

As a book, it comes across as well written, and is full of genuinely interesting interviews. If you’re interested in the history, or how some of these companies and startups came into existence, or you’re interested in learning what people feel they did right… and wrong, then have a read through it.

What is always interesting to think about when reading this type of material is what those of us working in larger organisations can learn from startup culture and the way these scrappy little companies work.

A common theme of Founders at Work is the role that luck can play in the success of a startup. However, equally important is determination – a refusal to accept failure – and linked to that, flexibility – so when one route looks like it won’t work, pick another and have another go.

Markup rules

texteditterminalI like to use plain text when I can. Plain text is just text without any formatting, which you edit with an app called a text editor, like Notepad on Windows or TextWrangler on a Mac. It’s pretty much a universal format – it can be opened and edited on pretty much any system or hardware you can think of.

One of the things that makes a simple plain text file useful is the ability to ‘mark up’ text within the document.

Markup languages have been around a long time. Perhaps the most famous one is HTML, one of the foundations of the web. An HTML file in reality is just plain text, with the use of HTML tags to mark up how bits of the document should behave – such as formatting and linking to other pages, for example.

Another example and one I use a lot is Markdown, a simple markup language for use in creating documents of all kinds. By simply using characters such as the hash sign (#), asterisks (*) and so on, a document can be made to include italic and bold text, headings at various sizes and bulleted lists, for example.

The key thing is that the document format can be used on pretty much any device and in any application. It’s just plain text, after all. The use of the markup language however enables that document to do more interesting things.

What’s more, you don’t have to be a developer or anything to start your own markup based project. You just need to define a few rules, and get going.

todotxt-apps_lrgI’ve just started playing with another great example of this. It’s called todo.txt and is a way of managing a todo list in a plain text file.

The rules are straightforward. Each task exists on a single line of text. Markup in that line can add information about the task, so for instance a word following a + sign is the name of the project that task belongs to (allowing you to group tasks by project, for example). You can also add a context to a task by following the @ sign with a word. Priorities can be added to tasks by using (A), (B) and so on to the beginning of the line.

Here’s an example of what a todo list looks like:

(A) Call Mom @Phone +Family
(A) Schedule annual checkup +Health
(B) Outline chapter 5 +Novel @Computer
(C) Add cover sheets @Office +TPSReports
Plan backyard herb garden @Home
Pick up milk @GroceryStore
Research self-publishing services +Novel @Computer
x Download Todo.txt mobile app @Phone

You could just manage your list in the plain text file using an editor – and many people do. However, because of the open nature of the format, other options are possible.

First, saving your todo list text file in a service like Dropbox makes it available across the web, so you can pick it up and edit it across many devices, which is helpful.

Even better, there are apps for mobile devices to help you manage your todo list. These present your todo list as a more traditional task management app would – but all the time they are just updating the text file using the markup rules.

This means all your tasks aren’t locked up in some database you’ll never get access to. You can take your text file todo list away any time you like and manage it in a different way.

As well as being a neat hack, todo.txt makes me wonder what other applications could be based on the simplicity of a plain text file and a few markup rules.

Any suggestions?

Collaboration – 10 steps to success

collaborationDigital tools provide great ways to collaborate online. Whether working with a smallish team to co-create a document, or engaging the wisdom of the crowd to build a list of ideas, the net allows us to work with people at a previously impossible scale.

But how to do so effectively? There’s nothing more depressing than a collaborative project that nobody wants to collaborate with you on; or a popular collaboration that runs out of steam, or drifts off at tangents.

Here’s a ten step process I’ve come up with to help your project succeed.

1. Identify who might be interested

There’s no way you will pinpoint every person who might be interested in what you are collaborating on. However, you should be able to spot the people you are aware of who will definitely get things going. This might be because they have a track record of getting involved on this issue, or that they know their way around these kinds of processes. Either way, they are useful people to have around.

Reach out to these folk and let them know what you are planning to do. Keep the specifics around the tech side of things vague, but recommend they encourage others to get in touch, so you can use other people’s networks to create a bigger list of initial collaborators.

Also find out at this stage roughly what level of tech-savvyness there is among this initial gang. Find out how they like to communicate – do they prefer email, discussion forums, or are they happy getting their hands dirty with a wiki? This will help inform which platforms you choose.

2. Put a platform together

Bearing in mind what you found out in step 1, decide at this stage what system you want to use. The fundamental factor is to keep things as simple as you possibly can. Other issues include whether you want to host it yourself or are happy for the content to be sat on someone else’s server, and whether you need to restrict access.

On the first point, by and large hosted platforms are far easier to set up and use and often are more functionally rich than those which you manage yourself. On the second, make it as open as possible, so that there are few barriers for people to get involved.

Make sure your decision on platform and process matches the research you’ve done with your initial user group in terms of the way people collaborate. Are they happy editing other people’s work? Would they prefer commenting, or submitting ideas?

Getting this right is important, but it shouldn’t get in the way of starting your project. Pick something that will hopefully work, but be flexible to allow for change in the future.

3. Get the content on the platform

It’s very hard to begin a collaboration with a blank page. You do need some content to get people talking and give them something to work with.

This, depending on your starting point, can be a quick or a very labour-intensive job. Copying and pasting text from other documents is fine, but when it is from (say) a PDF some cleaning of the formatting is likely to be necessary. Make sure you factor the time in to get this done.

Don’t forget your users when adding content. Consider adding some consistent header text to the top of each page, explaining what the content is, how it can be edited or discussed, and how the project administrators can be contacted for help, etc. Ensure that you take into account what people told you at stage 1. If people say they like to respond by email, make sure there is an email address they can send comments to, and a process for getting those comments onto the platform.

Ensure that the navigation for the platform makes sense and that people will be able to find the bits they are interested in easily. Test it out on some of your initial group to get their thoughts. Maybe find a complete web-novice in your organisation to take a look and see how they get on with it.

4. Set the rules of engagement

Having rules is boring, but a lot of people like them. Part of this will come into the page heading text I mentioned in step 3, but it is probably worth explaining again on a separate page. Make it explicit who should have view and edit rights to the content and also how vandals will be dealt with.

It might also be worth explaining exactly what will happen to people’s content that they add, who it ‘belongs’ to and under what licence it is published online. These things shouldn’t matter to most people, but those that do care often do so loudly.

It probably is also a nice idea to explain what the aim of the whole exercise is – what is the eventual output likely to look like? And how will those who have collaborated on it be credited?

5. Invite and manage contributions

Now invite your initial group to come onto the platform to start collaborating on the content. Keep it to this gang as much as you can to start off with. Any problems in the structure of the site or the way content is made available will soon be spotted and fixed.

Other things will be bound to go wrong at some point. People will accidentally delete entire pages of content, for example, and panic about what to do about it. Make sure you and your team are keeping a constant online presence to monitor what’s happening so you can react quickly to a) calm down the person who has just ballsed things up and b) put things right so the project retains at least a veneer of professionalism.

6. Figure out some roles

As part of the initial work with the smaller group, take the opportunity to identify some roles on the project and fill them with some of your early volunteers.

Roles can include:

  • Community manager – someone to keep everyone engaged and motivated on the project
  • Social reporter – a content creator who
  • Curator – collecting relevant content and useful information from around the web and bringing it together into one place
  • Gardener – a person who likes to keep your project tidy, cleaning up formatting errors, ensuring links work, and navigation makes sense
  • Evangelist – someone willing to go out and recruit new people to come and collaborate on your project

7. Market it

To get people involved beyond your core group of volunteers, you need to get eyeballs. Post to relevant forums, blogs and mailing lists about what you are doing. Telephone other contacts and get them to sign up. Stick a link to the project in your email signature. Mention it in every letter you write.

Don’t forget that you are asking people to give up their time to help you out for nothing in return other than the kudos of actually being asked for their opinions. Some will jump at the chance, others will need more persuading.

8. Get everyone in a room

At the very least, have a party at the end of the exercise to thank everyone. But even better, have one towards the beginning too. Even online networking fanboys like me appreciate that to get trust in a community, you have to meet one another face to face first. OK, you don’t have to, but it really does help.

Maybe you could have a collaboration hack day – a big room with lots of laptops, wifi, flipcharts and post-its, where everyone does their best to get as many quality edits done as they can, chatting to each other and developing ideas in real life. Plenty of coffee and sandwiches would probably help too.

9. Let go

Involvement in any activity like this one will involve the acceptance of a significant loss of control and messiness in the way things develop. This is good, don’t try and fight it.

Do moderate offensive or stupid content – that does no-one any favours. But if things are developing in a direction you didn’t expect, or don’t like, let it. Have a conversation about it. Examine your own preconceptions and assumptions and see if things can be worked out another way. But don’t go round reverting pages because you don’t agree with them.

10. Get the output sorted

Finally, make sure there is a recognised output at the end. Hopefully this could be some sort of document that people who like documents can read. Make sure it is full of links back to the wiki so that people can see who developed what idea, and how that idea changed from the original.

Make sure that a description of the process is included in the final document, and that everyone who contributed is credited. Go back to those forums, blogs and mailing lists that you punted the idea around on and let them all know how it finished. Make a fuss about the fact that this stuff works!

Do you have any tips for making collaborative digital projects work?

Writing apps – the software I use to get words on a page

writingI probably think about this sort of thing far more than I should – after all, doesn’t everyone just use Word? – but I like playing with different tools for writing.

After all, for me, typing words into a computer makes up probably 75% of my job. That’s a lot of typing and so it’s worth making it as little of a painful experience as I can.

So here is a list of the different tools I use to write text with.

Byword

Byword is a ‘distraction free’ writing application which works on my Mac and iPad, syncing through Apple’s iCloud service. It’s a very simple editor, that pretty much just lets you type in text in plain text format. You can do some formatting with Markdown, which you can then export, but I tend to use it when I just want to bash some words down, without thinking too much about how it looks.

Find out more about Byword

MarsEdit

MarsEdit is the app I use to write my blog posts. It’s a bit of desktop software that lets me bash in the content for my posts offline, using a very simple plain text editor. I’m able to add tags and categories to my posts, which I then send up to my blog in draft, ready for a final check, adding images and hitting publish.

I don’t know why, but I just find writing posts in MarsEdit more comfortable than using the WordPress editor – hence why I class WordPress as a publishing tool rather than a writing one. A big part of it is probably down to the keyboard shortcuts I use to quickly enter and mark up content in MarsEdit, rather than having to constantly switch to the mouse to select icons.

Find out more about MarsEdit

Apple Mail

An awful lot of the words I write are emails, and so my email client has to feature in this list. I use Apple Mail mostly by default nowadays – previously I have used Gmail’s web based interface, but I do find using a desktop client helps me pace myself a bit and be a little more thoughtful. It’s basically ok – I have no complaints but then I’m not exactly a huge fan either. It works.

Find out more about Apple Mail

OmniOutliner

This is a seriously good outlining tool, which I mostly use for drafting pieces of writing or presentations. Outliners let you build up bullet style lists of content, indented at various levels of a hierarchy, which you can then drag around and reorder. It allow you to structure a document really well in the planning stage – to figure out your ideas and how they slot together.

Find out more about OmniOutliner

Google Docs

When I need to collaborate in the early stages of preparing a document, I usually turn to Google Docs. Due to the fact that it is online, it does tend to stress me out a bit – I prefer desktop apps with local copies of files when possible – but Docs is the best solution to working on something with others, particularly at the same time.

Find out more about Google Docs

Scrivener

I occasionally work on longer pieces of writing, although they almost never get published anywhere. Scrivener lets you write chunks of content for a larger work, which you can then reorder, drag around and so on. It also lets you save research notes in the same place as your draft document, which can be helpful. At the end, Scrivener spits out a rich text file that sticks all your chunks together, for a final edit, or formatting exercise in a word processor.

Find out more about Scrivener

Evernote

The writing I do in Evernote differs wildly, from meeting notes to pasting in web addressees to check out later, to

Find out more about Evernote

Pages

Pages is Apple’s own word processor, which I use occasionally for more graphical documents. It just has a more creative, desktop publishing type feel to me, which makes it ideal for that kind of work. It’s really easy to use, and I find it the best tool to work with when a document has a lot of graphical elements.

Find out more about Pages

Vesper

A super iPhone text editor. It does one thing very well, and that is writing short notes on my phone. It has a beautiful design and is incredibly easy to use and for when I just need to quickly write something without worrying about it syncing up anywhere else, Vesper is perfect.

Find out more about Vesper

Simplenote

Yet another cloud-syncing text editor. I use this to quickly get text onto my phone from another device. It’s fairly niche, but stuff like when I look up an address for a meeting on my laptop and want to get it to my phone – I’ll usually use Simplenote rather than creating something in Evernote.

Find out more about Simplenote

Word

OK, so I do use Word. Quite a lot, actually, in its various incarnations – Mac, Windows, online (via Office 365) and now, of course, on the iPad. When it comes to needing to share a document with others in a format they are likely to be able to edit, its still the best option.

Find out more about Word (really?)

What are your favourite writing tools? Do you use as many, or even more, than I do?

Load more posts!