I rarely write about S3, but when I do, it is long and boring. :)

Below you will find my experiences with the S3 effectiveness review  – an idea that I borrowed from S3. I hope that maybe some comments that I share will help you to run yours. 

Ah, names of people are changed in order to “protect the innocent”.

So, there is this team, that was going some reconstruction, meaning people changed roles. And I thought, that maybe this is a good point to introduce some new practices (and I have to admit I was looking for some opportunities to introduce selected S3 patterns since I attended an S3 training with Lily & James).

Fortunately, John, who was appointed team lead, agreed to become my guinea pig. So here is what we did plus some comments/improvement ideas:

  • Started with the driver (why this team lead is needed) and with role description. All written down by John & me, and later reviewed and enhanced by another member of the team. We ended up with 1-page doc (used google docs which is nice for collaboration/sharing).
  • Decided to run effectiveness review once a month.
  • Asked Joanna – an agile coach from an agile consulting company (with some S3 experience) – to facilitate the meeting and help us prepare.
  • From the very beginning we planned (and John agreed) that this event will be opened to observers – I wanted few leaders of other teams to join us so they could observe and learn how it looks like (and hopefully want to introduce effectiveness review for their teams as well).
  • Since we had no previous experience, we tried to plan it very carefully. Joanna & me worked (shared doc again) to list all things to be done – like what kind of materials should be printed, who the scribe will be, what should we tell the participants beforehand etc. In short, we wanted to make sure this event will be well prepared, so that it runs smoothly.
  • I talked with every participant (selected by John) explaining the idea and their role. Also, I talked with all the observers. All received an email with links to:
  • We set the room so there was a circle of 6 chairs (for the main participants) and some places outside the circle (for the observers). We decided to take notes on flipchart.
  • The scribe, wrote down every appreciation & every improvement suggestion on the flipcharts. Tip: We used two different colors alternately so each idea was well visible.
  • We ended up with some action points for John (all related to the gathered improvement suggestions) for the next weeks.
  • After the event the scribe sent around all the notes gathered during the event
  • The whole event took us ~55 minutes. I think we can cut the length of this meeting by at least 10 minutes next time.

The results / comments / improvement suggestions:

  • Reception
    • In general this was well received both by team members and by observers.
    • I asked some team members how they feel about it. They say it seems really valuable.
    • Some comments from the team members like “a pity we haven’t used this approach earlier” (this team has quite a troubled past, so maybe such effectiveness reviews could had been useful).
  • What was good
    • Friendly attitude is IMHO crucial. The fact that our facilitator (Joanna) was beaming with positive energy helped a lot.
    • Asking “external expert” – Joanna in our case – to facilitate this event was a good idea.
    • It is very valuable to have different people participating – in our case we had 3 team members, a product owner, and IT recruiter. All of them had recently worked a lot with John. Thanks to this diversity John received very different comments. Good.
    • A note about transparency: as I said before we sent around the notes from the event. Surprisingly, this helped another team member (who wasn’t participating) to understand his situation in the team (do not want to go into details here, only stressing out the fact, that unexpected – and good – things happen after you let the information flow.
    • Flipchart notes worked very well. Recommended.
  • Emotions
    • One person told me he would probably die if it was his achievements being discussed in such public setting. This is an important information to me – maybe for some individuals we should go with something less public (kudo cards?).
    • John is a very open person, but I observed that he was nervous before we begun. Fortunately, he was doing a really good job recently so he received a lot of appreciations and this relieved the tension.
  • Next steps
    • I talked with the observers trying to persuade them that maybe, possibly they could also benefit from establishing roles and running such effectiveness reviews. One person wants this very much, others are more cautious, but in willing to give it a try.
    • And yes, we will definitely run the next session for John in one month time.
  • From the discussions with some observers we have this idea, that such effectiveness review might not be feasible for some roles – for example, we were wondering if for regular devs, this would give anything more than what they learn during daily code reviews & architectural discussions. Not sure about this one, will see.
  • When discussing the idea of organizing such effectiveness review for a specific person I heard that “in case of this particular person, such a very positively-aligned meeting could make things worse”.
    • The context here is that the person in question has a very high idea of his skills/quality etc. And since effectiveness review is pretty much about positive feedback it could result in even bigger ego.
    • Also, in this particular context, the idea that the person selects participants seems kind of dangerous – we could expect this particular person would select only those, who would praise him. I guess in such cases the list of participants should emerge from some discussion among e.g. person and his boss, and not based solely on person’s opinion.
  • Improvement suggestions
    • We should focus on the driver and role description more. We drifted too much from John’s responsibility to general ideas of team improvement. It was also valuable, but not exactly what we hoped for. Next time I want to have the driver/role visible all the time (overhead projector).
    • We need also to help people prepare even more than what we did this time. I think it is crucial to first have a good discussion about the driver and the role with the whole team. Also, all participants should understand that the meeting is about helping someone fulfill his role better. However, as for the first time I’m really happy with what every participant brought to the discussion.
    • We will probably ask Joanna to facilitate few more events but then we want to do it ourselves. After all, it doesn’t seem such a big deal.

That is all folks. Comments/questions welcomed! Cheers!

Recently I had few interviews with graphic designers. This was definitely outside my comfort zone because my knowledge of the topic is… well, very limited. However, my task wasn’t to check their graphic skills. This was already done by my colleagues. My task was to get to know them better. To see whether they “fit here”. I was wondering how should I go about this interview, and finally I decided to use the moving motivators cards (from Management 3.0).

If you aren’t familiar with the concept then I will describe it shortly. There are 10 cards. Each of them represents a (potentially) motivating factor like power (ability to influence what happens around you), status (being recognized for who you are and what you do) or mastery (challenging tasks which are within you reach but you have to sweat a little to perform them). The task is to set them in order so that the things which motivate you the most are on your left, and those which are less motivating are on the right (there is more to it, but for the sake of this post this should suffice).

You would (normally) use these cards to learn about the motivation of your team mates, but I wondered what would happen if I used it during the interview. So I tried it.

moving motivators

Image from http://management30.com

The nice thing is, that there is no expected result. Each of us is driven by different factors and this is OK. So giving this task to a job candidate isn’t really a test: I treat it rather as a very effective discussion-igniter. The point is to hear some some explanation about values represented by cards.

Also, for most of the people (and I have played on different occasions – not only during interviews) this task is challenging. It occurs that most people struggle to decide which of the motivator should go where.

And while the candidate shuffles the moving motivators cards you ask questions. There are thousands you could ask, and they pop in your head as you observe the candidate. Why would you choose acceptance over relatedness? What does status means to you? Is it the title on your business card or maybe something very different? And, if given the choice between status and power which one would they rather have? So, you put the freedom as the most important factor, but power is on the other end. How do you think these two relates to each other? Could you give an example when the task you had clashed with your honor? I see you find it hard to choose the more important of these two – why is that? There are no two similar answers to these questions and each discussion goes along different paths.

Every time I used these cards I was very happy with the result: they tell me a lot about the person. Also, they let me verify what the candidate said about himself during some initial small-talk (I usually ask about his previous experience etc.).

Also, by what the candidates told me, this was a nice experience. I guess this is because I really tried to make it so. I began with the explanation of what are the moving motivators cards, and what we gonna do with them. Also, I made it clear there is no catch: that I’m not a shrink so I can’t read them through by observing how they do with the cards. By keeping atmosphere friendly I think I am able to make this task a kind of a game of self-discovery, and not a strict interview psycho test.

Of course, as with every tool, you can use it in a wrong way. I have heard stories about interviews which also used moving motivators cards but were horrible. The antipattern is to request the interviewee to order the card. And then to sit and observe him with the stern face. And the poor soul thinks this is some kind of a trap and he tries to find the right order (that would please you), and he wonders what would you think if he puts power or status as top priorities – would you hire such a person? Obviously, this leads nowhere..

The task: explain what you do at work to a group of 6 years old kids.

Level: high (my own daughter was among the kids).

challenge_accepted

Many people shared their ideas of such “lectures” – you can find some really interesting examples on Stack Overflow (e.g. here). Many of them are based on the idea of presenting how computers are stupid and that you need to tell them very precisely what and how to do things to succeed. Fun guaranteed, but I seriously doubt if afterward kids understand anything about programming.

My ideas for a successful presentation were:

  • Keep them engaged by asking questions and drawing. The original drawings were pretty big (flipchart) and I draw them while talking – which BTW is a nice way to keep a young audience engaged (they had so much fun laughing at programmer straw man or pointing out that Peppa Pig doesn’t look like this, etc).  I do not have the original drawings (forgot to take pictures) but I draw them once again so you get the idea.
  • Build upon what they already know (YouTube, laptops, tablets, DVDs). Nowadays every kid watches cartoons on YouTube, plays games on tablets and observes mom or dad working on their laptops. They also know the movies are kept on CDs/DVDs and that the smartphones and tablets are pretty similar (when it comes to games and movies).

I started with the basic question “who knows what a programmer does?” I knew they had some discussion about this yesterday so I wasn’t surprised they had some idea. I gave them my own definition: “Programmer is someone who writes computer programs, who knows the languages used to tell the computer what it should do. A programmer knows a lot about computers.”

Then I draw a programmer at work.

programista

The next step was to discuss computers. All kids started talking about laptops of their parents (it is really lovely how they mention the same thing over and over again). I interrupted after some time pointing to them that there are many computers in different places – like smartphones or watches, but also in cars and lifts. I draw each of the mentioned items and discussed in few words what a computer is used for in each case. I also asked them how they think the weather forecast works (one smart kid answer “the satellite knows what will be the weather next day”) and told them about computer calculating the prognosis based on data coming from thousand of measurement devices.

komputery

I wanted to move to computer programs next so I mentioned that computers do what they do thanks to the programs which instruct them to do certain things.

I moved to YouTube cause I knew they will know a lot about it. I started by drawing UI that they are all familiar with.

I asked how many movies there are on YouTube. Some of them were confused but few shouted “millions” or “infinity”. So I asked if it is possible that all the movies fit on one discs. Then I draw many discs and asked “how it happens that after you tell YouTube to watch certain episode of Peppa Pig it finds the right disc?”. They responded with silence so I draw a database and quickly described its role.

youtube

I wanted to give them some idea that what they see is only a tip of an iceberg and that the programmers are responsible for much more. I explained how we must take care of various stuff like:

  • protecting the movies against bad people (“what would happen if someone changed the database so that instead of Peppa Pig you would see some football match?” – answered with horror silence)
  • making backups (“what would happen one disc broke? then you would never be able to watch this Peppa Pig episode in which Daddy Pig tried to hang a picture?” – horror silence again)
  • so that YouTube works on different devices (smartphone, tablet, laptop)
  • presenting ads
  • counting the number of people watching each movie
  • showing thumbnails of similar movies, etc.

This was a good time to remind them that the programming is a teamwork. The programs are big and demand knowledge of different areas so that many people are involved in their creation. At this point, I updated the first drawing adding another programmer so that two were sitting close to each other.

The next topic was how computers work – very roughly of course. All I told them was that:

  • mouse and keyboard are for people to give commands to a computer
  • a computer screen is for computers to respond
  • inside every computer there is a processor (you can think of it as of a brain of the computer)
  • there is also some disk which allows computers to store information

procesor

I concentrated on processor telling them that it uses a funny language which consists only of zeros and ones. Then we had a bit of a fun when I pretended to talk in a language using only As and Bs. Then I explained that the programming languages used by programmers were created so that it is easier to talk with processors.

I followed with the simplest possible examples of programming languages statements (using some pseudocode). I wanted to show them some more but I felt they were losing their focus so I haven’t even presented the for loop.

jezyki

To finish my lecture I draw once again symbols of what we talked about. I draw them one by one and asked questions like “what is this?”, “what do you remember about it?” and so on. It went pretty well.

przypomnienie

Additional comments, do’s and don’ts, tips & tricks:

  • It was more fun than I expected! I treated this seriously and I was well prepared, and it paid off. The kids were interested and I think they might even remember something. :)
  • Drawing pictures is the right way to go. It grabs their attention and lets me remind them about things we have discussed few minutes ago by pointing to a certain drawing.
  • Be prepared for them repeating things over and over again. When I asked about languages they know then one guy raised his hand and said: “I know a little bit of English”. And then his colleague did the same. And then one more. And another. And then rest of the group joined one by one (or few at once). All saying exactly the same about English. It gets even more chaotic when you touch the subject they love like cartoons.
  • Some kids will get bored no matter what you do. Their attention span is simply too short.
  • Write carefully – e.g. they will protest when you write 1 so it looks like 7.
  • During the presentation I understood that there is no point in correcting them – for example, I think they understood that YouTube keeps cartoons on DVDs and when you ask for one then computer selects the right disc and plays it. I think this is perfectly fine. I wanted them to understand the concept (how the search looks like and what does a database do) and not the technical details. I feel this is the right way to go.
  • The presentation took me ~25 minutes. No sense to make it longer.

My findings from the 7th ACE! conference (Krakow, Poland).

They say that “When the student is ready, the teacher will appear.” So maybe I was ready, and ACE! appeared in the right moment to teach me a gazillion of things. Frankly, I can’t remember any other event that I finished with so many new pointers, new ideas, new things on my TODO list or inspiring quotes. I can’t possibly list them all here, but at least I will share some of them with you.

The order is pretty random. The quotes are not really quotes but close to it. :) Some things were never mentioned directly, but I read them (imagined them?) somewhere “between the lines”.

  • Naomi Ceder – Antipatterns for Diversity
    • Impossible to see a problem when you belong to the privileged group.
    • If you are privileged you find ways to justify that you belong there
    • Compliments are often nicely wrapped up stereotypes.
  • Shu Ha Ri – mentioned all over the place
  • Experiments – yes, you should
    • be really crazy about it: Popcorn Flow by Claudio Perrone 
    • you experiment more, you learn more, you learn faster, you outsmart your competition etc.
    • reminds me of Mngmt 3.0 Celebration Grid (silly name, BTW)
    • You should know what you expect, how you decide whether it was a victory or a failure.
    • If you are not ashamed with your first release, it means you waited too long. Claudio Perrone
  • You and your team are parts of the system. Complaining about the system is stupid, you are part of it, you can affect it, so work towards changing it.
  • Causal Loop Diagram,  Current Reality Tree, Cynefin
  • You can copy solution, but not the context (AKA, “we are not Spotify!”). Yeah, read what others do, be inspired, but find your own solutions. Your context is different.
  • Mary Poppendieck is awesome. Can’t get enough of her lectures. :)
    • on a downside, her workshop wasn’t a workshop but the continuation of keynote lecture
  • The process often stands in the way of a passionate team. Forget the process. Let them work independently. They will do great.
  • The art of scrum mastering / agile coach is to disappear.
  • A team should have a mission. Easy to say when you work for NASA Moon program. But what about a team that works for normal business? How to create an exiting motto for such a team? Maybe start small, with something different. Try to find (together) some working principles, identify team values, list things the team won’t tolerate.
  • Sketchnoting is not for me. Yes, I learned that I can draw a happy guy and a tired lady, and even a grandpa with mustache, but how on earth could I use it to make notes? You gotta be kidding me! (But I will show my new skills to my kids, and I bet they will appreciate!)
  • Thing is really done when:
  • Real options – delay the commitment
  • Do not start working on a story until you know how to measure its impact.
  • Creators should be immediately connected with what they create.
  • Put your money where your mouth is. E.g. do you promote kanban boards? Fine, so where is yours?
    • …ouch! where is mine?
  • Teams should solve problems, not deliver features.
  • PO – build a hypothesis, team – build and experiment ASAP.
  • Deploy (technical) and release (marketing) are different things. Feature toggles help.
  • Constraints can be pretty helpful, they help you to do only important work. (That is why I limited the time to write this blog post.)
  • Peer coaching (peer-feedback, peer-to-peer review) should be separated from promotions, salaries etc.
  • Do’s and don’ts when you attend a conference
    • Coaching sessions are a must.
      • BTW. There were coaching sessions with some great coaches and not all were taken. I don’t understand it. You prefer to see a presentation when you can have a 1on1 conversation about your issues/problems/situation with some Guru?!
    • Open Space discussions are great. Especially when the owner is prepared.
    • Don’t take a laptop with you. Don’t bother with tweets. Be there, listen, talk. Pen & paper will be enough.
    • The food at ACE! is delicious. Prepare a box next time, take some cookies home. 😉
    • Talk with people. Talk with the speakers. Talk. They won’t bite you.
    • Write a blog post right after the event is finished. Otherwise you will never do it. (Yeah, I did it!)

Recently I had an opportunity to meet some people working in big corporations. One of the things we discussed was role of leader/manager. They used the term “shit umbrella” to describe the role of such person. If you are unfamiliar with the term, here is the definition from urban dictionary:

It’s the unofficial title for the person/role above you at work, who takes the heat from management/owners.

This individual takes the shit, while the people below him/her are shielded from management’s crap, trouble, finger pointing, etc..

My view is different. While I agree with the idea of “protecting your people” I think that standing there with an umbrella is not good enough. There is more to be done. IMHO your task as a leader is to go up there and clean the mess so no more management’s crap happens again.

When I think about this, I think there are two major differences between me and my corpo colleagues. First of all, they perceive their organisation as something evil. Their teams, their departments are kind of surrounded by the armies of darkness (upper management) so it is only natural they want to defend their people. This is not my case – my organisation is not evil and there are no monsters outside my team’s room. I do not need to protect anyone.
Second, they do not believe they can change the way their organisation works. This thing is way too big, too rigid, too hierarchical (and has been like this for decades) to change anything. All they can do is to stand their ground and protect. And they do. They survive onslaught of stupid requests day after day. They are valiant and stubborn. On the contrary, my organisation is very small and it is still growing, evolving and changing every day. And we – me and all teammates – can influence the direction we grow. If we see bad things happen we can act and change them. This is how small size, trust and flat hierarchy (or almost no hierarchy at all) works.

So while I appreciate what my fellow corpo-leaders do for their teams, I wish they could do more for them.

All in all, lucky me. :)

The Internet is full of “10 Rules For Effective Meetings” blog posts so why not create my own? Sure, why not?

These are the guidelines I try to follow when organizing meetings. They work fine for me in the context of the company I work for (flat structure, ~80 people, no managers, no corpo-bullshit). I have no idea what happens if you apply them to your workplace (but I bet, it would be something positive).

 

Meetings People Love

Meetings People Love

A Meeting? Seriously?

Sometimes it is enough to visit your colleague in the next room, sometimes all you need is a short discussion on group chat with few people, sometimes simply wait till certain people are having coffee break and join them for a five minutes discussion.

Meeting is a heavy, time-consuming, corpo-smelling, commonly disliked thing – look for a lighter solution.

Save People’s Time

As an organizer make sure you do everything possible to save people’s time. This means you make sure that:

  • all important people will show up,
  • the room is ready (see below),
  • all participants  know what they should prepare for the meeting (if anything), and that they really did,
  • lead the meeting so that it is worth being there

One minute of your preparations can result in few minutes saved for each participant. Do the math.

Organize the Room

Always be there at least 5 minutes before the meeting. This gives you time to reorganize tables and chairs, tweak the air conditioning, bring missing markers, clean the whiteboard, check the projector works etc. Make sure the flip chart, markers, magnets, pencils, cards, or whatever else you gonna use is there.

They way the tables and chairs are organized is important. Make sure you know what type of meeting you want (a lecture? an open discussion?) and put the chairs so that people have no choice but sit according to your plan. If it doesn’t work just like that, ask people to rearrange so they sit the way you intended. Really, do it. If not, you will end up with weak discussion only because people sit side by side and can’t really talk to each other. Or you will have two hostile tribes on two other sides of the table. And it will be your fault.

Action Points

A meeting without Action Points (AP) is a waste of time. Make sure everyone knows what was decided (remind them right before the end of the meeting). Every AP should have an owner. For every AP it should be clear what the next step is, and when this next step should be finished.

Meeting Notes

Keep them short – usually the APs is all that matters. Add pictures of whiteboards notes, sketches, diagrams etc. – a good reminder of what happened during the meeting.

Send the notes ASAP (to all interested parties) after the meeting is finished.

Make Fun of It

If possible make some fun around the meeting. Yes, do it. The invitation can be funny or you can put some funny accents into the meeting notes. I’m trying to do it for (some) meetings I run at Codewise and I think it works. From discussions with my colleagues I suspect some of them take look at the notes because they want to find out what kind of stupid stuff I put there among serious notes. Good! – at least they will scan through the notes looking for hidden gems and will inhale some of the essence (if they want it or not).

I will give you one example of what I’m talking about. This is an email invitation to developers to take part in our weekly “devs meeting” – which is a gathering of interested individuals from each development team to share business and technology news. So usually the invitation email is “standard”, but from time to time, I try to tweak it a little bit. For example, like this:

meeting_code_monkeys

Facts First

For problem-solving meetings always start with the facts. Even if you think people know the full picture. They usually don’t. It is your task to learn about it before the meeting, and then present it in a concise way. Or – even better – ask the participants to list them. If not, you risk all kind of misunderstandings (like people discussing different issues, while thinking they all talk about the same).

OK, here comes a story. So once upon a time we had this meeting. And I explicitly asked participants beforehand to prepare a list of facts so we start discussion with them. Once the meeting started one person gave like one fact and immediately followed with a general solution, which, in his opinion, solved all problems related to the discussed topic! I stopped him in the middle of a sentence and refused to discuss the solution until we learn about the whole picture. We continued with the facts and listed 12 of them on a whiteboard. After 30 minutes of a discussion we agreed on some action points. The solutions we discovered were completely different from what the first guy suggested. I would also say they were much better. Can you guess why?

Do Not Distract People

Do not turn on the projector too early, and make sure you switch it off when it is not needed anymore. For some reason, people will stare at the screen even if nothing happens there (instead taking part in the discussion).

Switch off all communicators/calendar reminders when presenting. First, it distracts people. Second, it can be pretty embarrassing. :)

Transparency

For problem-solving meetings always leave the door open. Invite crucial people and let other know that such and such meeting will be held. And don’t worry – only few (if any!) will come. But those who decide to join you will probably have something interesting to say. Good for you, right?

Similarly, publish the notes so that all employees can read them. You have nothing to hide, do you?

As Attendee

  • Come prepared. If asked to read something, read it. If asked to think about some idea beforehand, think about the idea. Simple, isn’t it?
  • Don’t attend a meeting if you do not feel like going there. Your absent-presence won’t help anyone.
  • Think about other people who could help and discuss inviting them with the meeting host.
  • Always inform the organizers if you attend or not. A simple click in the calendar is all they need – and it really helps them to prepare a meeting.

Tips & Tricks

  • If we chit-chat instead of discussing it means the meeting is over. Finish it.
  • For recurring meetings, change the meeting host once in a while. It helps to fight the boredom.
  • Throw away empty markers immediately. Have no mercy!

Ending Quote

For all programmers out there, who love all kind of meetings :)

delete_emails_and_avoid_meetings

During the Unexpected Meetup: 1st Open Space I had an opportunity to discuss the topic of changes with fellow Scrum Masters / Team Leads / Agile Coaches. Here are some notes (subjective and incomplete):

  • Books to read:
    • Our Iceberg Is Melting
    • More Fearless Change
  • You shouldn’t expect that your team will come with new change proposal every day. It will be rather your task to help them to discover that some changes are required and decide that they are worth the effort.
  • External experts can really make a difference. Somehow people from the same company are less credible (“No prophet is accepted in his own country’)
    • New hires – especially if they are seniors – are treated similarly to external experts. At least for some time.
  • Imposed changes are much less effective than grassroot changes.
  • No sense to order changes (e.g. “you will do the pair programming 100% of time starting today!”). Much better is to show the idea and let people use it at their own will.
    • Onboarding (especially with fresh devs) is a great time to inject some desirable behaviours.
  • A nice way to introduce a change is to run an experiment (e.g. “Let us do the pair programming 1 hour per day for 2 weeks. Then we decide whether we like it or not”.) Be prepared that people might not like the change. But this is fine.

 

I was addicted to email checking. Or maybe I should say that I still am the same way an alcoholic doesn’t stop being alcoholic, he merely doesn’t drink anymore. So let me say I’m still emailoholic who checks email in controlled manner. Or at least, one who tries to achieve the inbox zero.

Checking email often was exhausting, pointless and stupid. I didn’t like it, so I decided to put an end to this bad habit. In fact, there were two goals I wanted to achieve:

  1. stop checking my email account too often,
  2. don’t let the unanswered emails pile up in my Inbox.

Interestingly these 2 things come together – at least for me. The thing is, that I used to check my email when I had no time to handle it. This had two very negative effects. The first, and an obvious one is, that I was thinking about answering my emails right after I checked my mail account. This disrupted my work, family life or whatever else I was doing at the moment. The second, less obvious effect is, that sometimes I hadn’t answered to emails at all (or I did this after very long time). This one is harder to explain, but my theory (uh-oh, big word!) is the following. There seems to be a certain good time for some things. A book should be read right after you buy it. If you don’t start reading it immediately, you probably won’t read it at all. Similarly, an email should be answered right after you see it.

So, in order to improve the situation I took one resolution: I will check my email only if I have time to process it right away. This means saying no to:

  • email checking while my code compiles,
  • grabbing tablet on my way from dining room to the kitchen only to check my email and put down the tablet on the table,
  • no quick checks in between other activities.

I started with the cleaning of my inbox. This wasn’t very hard, I had like ~40 emails there. Then I removed pinned tabs from my browsers. And hid the email icon from the front page of my tablet and phone.

Since 2 weeks I check email rarely (compared to what I used to do) – sometimes only once a day, sometimes few times a day, but the important thing is, that every time I do this, I make sure my inbox is empty before I switch to other tasks.

meme_email_inbox_zero

There are some issues, though. First of all, my email is also my personal database of various things. Sometimes I need to look there searching for something. To do it, I need to break my promise and take a look at email, even if I do not have time to clean it. Secondly, sometimes I have time to process email, but for some reasons I can’t – e.g. I need to consult something with my wife before answering, or I need to check something at home before I answer. Fortunately, neither of these happen often. Another issue, is that sometimes I wait for an email answer which I need ASAP – e.g. will I meet with X today or not? Then it is hard not to check my email every 30 minutes or so.

But all in all, it works pretty good for me. I’m not so obsessed with my email anymore. People who contact me by email should be also happier as they receive answers much faster than previously. I enjoy email-free evenings, and email-free-thoughts. My inbox is often at zero, and I hope to keep it this way.

Some time later

After 2 weeks – To get rid of unwanted emails I spent some time signing off from all kind of customer survey etc. This takes time (usually you need to log in to change your notification preferences) but I believe it is worth the trouble when thinking in the long term.

After 2 months – It is much easier (at least for me) to keep inbox at zero than to restrain myself from constant email checking!

After 2,5 months – I have never checked my email using phone or tablet. Yes!

After 3,5 months – Block site helps to fight the urge to check my email often. Not ideal, but helps.

I performed a Journey Lines team building activity (as described by Lyssa Adkins) with various teams. In general, I was really happy how it went (and so were my colleagues).

The idea of Journey Lines is that each of the participants draws a line showing ups and downs of previous jobs. Each chart contains also some additional information like technologies used, skills acquired, names of companies they worked for, or any other comments that people find important. This activity:

fosters self-organization and cross-functional behavior because it reveals a person’s skills, experiences, background, etc. This way, the rest of the team knows what this person “brings to the party.”

Some observations:

  • Some people need to check LinkedIn to help them remember all the places they used to work (especially freelancers with short-term contracts really need such reminders),
  • The time required to tell the story differs – some people needed 6 minutes, for others even 15 seemed to be not enough (next time I will probably put some time constraints). The whole exercise took an hour (for 4 people team) and more than 2 hours for 8 people (including 15 minutes pizza break).
  • Even though this activity is intended to be used when forming a team, we played it a long time after the team was created and it was also fun & informative. Team members learned a lot about each other, even though they worked together for a long time already.
  • Personal things (marriages, kids) showed up rarely.
  • It was very interested to see how many different ways lead us to this particular company that we work for now. Also, it was funny to notice that in the past we all went through similar stages (e.g. freelancing during high school, hacking games etc.).
  • Some people draw really beautiful charts with nice fonts and additional drawings.
  • There was a lot of new things about each team member that no one knew before.

Probably the most interesting for me was to learn about the “down” moments (where the line of journey went down, down, down – often very abruptly and usually resulted in job change). There were few reasons for this:

  • people issues – stupid team lead / manager / boss can ruin even the best place,
  • stagnation – nothing new? maintenance and bug fixes for too long? people will look for a different place to work,
  • people leave their jobs when put in a position they did not want (e.g. someone was appointed a PM, another dev ended doing some office-management tasks).
  • a lack of vision (“why are we doing this?”) or lack of business impact (“we did it, but then they started to argue if they really need it, and it never went to production”) is a serious motivation killer

One more thing. I like this activity because it creates a symmetrical situation – “I show you mine, you show me yours”. Also, each participant can decide how much he wants to reveal. The only potentially intimidating thing is that at some point you need to stand in front of your colleagues and tell your story. But somehow, it hasn’t been an issue for any of devs I worked with.

P.S. Ask participants to write neatly on their charts so that later all can read it! :)

It is almost the end of January, but I believe it is still a good time to make some New Year’s resolutions. Today I want to describe one of mine, which I believe could be a good fit for many of us.

As you know, it is very simple to make resolutions but much harder to fulfill them. So before I reveal it, let me tell you why I believe I will keep it:

  • it is not hard to do,
  • no special equipment/weather/mood required,
  • doesn’t take much time
  • requires only a little bit of preparation
  • I have heard many people saying it is a very valuable habit
and last but not least:
  • I have first started doing it and I already like it (and only later decided to make it my resolution – usually first you take a resolution and then you start).

And the resolution itself is very, very simple: I decided to perform a short (5-10 minutes) retrospective of my work achievements each week. Have I done what I promised (to myself or to others)? Have I worked on really important stuff or maybe I spent my time doing 2nd rate stuff? Have I started new tasks without closing the older ones? And so on.

In order to be able to do that, I take notes every day before leaving the office: few bullet points with major things I have been busy with. Then, on Fridays (I set up a reminder so I don’t forget it) I go through the notes from the last wee and ask myself questions. And then I write down some TODOs – like “do X – don’t wait any longer” – but also I praise myself – e.g. “good job with Y!”.

After three weeks I already have few observations and ideas:
  • Maybe Monday would be better, so my TODO list was kind of fresh and I would be able to jump into the action without waiting for the weekend to pass.
  • Why only work achievements? Why not introduce the same idea to my family life?
  • A week is kind of long, at least in some cases. Wouldn’t it be better to have it twice a week or daily to shorten the feedback loop? I’m not sure.
  • I do not have a good way of reminding me about the TODOs I created during the review. A sticker on the monitor doesn’t work for me – somehow after an hour it is like I don’t notice it anymore. Maybe I should set up a reminder for this as well so e.g. every day I got reminded about things I decided to do?
  • I have already been able to achieve some small victories (e.g. doing some stuff I have been putting off for weeks…) so I can say it works for me. So I plan to continue.
There is still time to change this year into something more valuable. Why don’t you give a try to this self-retro idea? I hope it helps you.

Cheers!