Category: Coaching

Reflecting on the Tech Lead Skills for Developers Course in Brazil

Earlier this month, I visited our Brazilian offices to run some internal training, called Tech Lead Skills for Developers. The trip felt a bit full circle as I had visited Brazil several years ago for the same reason and needed to develop the material. Instead of the handful of people I coached, I ran two full classes with a mix of people currently playing the Tech Lead role and those who might be stepping into the role.

The course I run uses a mix of training styles (short presentations, lots of time for story sharing, discussions, interactive exercises, brainstorm and lots of time for question time). In general I’m really happy with the overall result with a good balance of covering lots of material, making it personalised and relevant, and giving people an opportunity to practice, gather feedback and have a go at applying it. The feedback for the course was quite consistent with those in the past, telling me that the balance was just about right.

One of the great opportunities I have had, running this course in different places is seeing some of the cultural implications and differences between continents. I learned, for example, that Brazil (traditionally) has a higher Power Distance Index (PDI on the Hofstede Dimensions), which means that, at least compared to the United Kingdom or America, authority is viewed a bit more strictly. In practice, this meant that a lot of the developers, working in more collaborative environments seemed to almost take an extreme anti-leadership position, where any mark of authority was viewed poorly, or that there was a reluctance to be seen taking on a title.

I also discovered that the word delegate in Portuguese had a negative association. As we discussed how effective leaders scale themselves through effective delegation, it was almost interpreted as a manager telling people to take care of the bad tasks – which, of course, wasn’t the intent! In the end, I tried to express effective delegation as a way of ensuring that all important responsibilities were being taken care of.

I am running this course again later this year in both Thailand and Singapore and look forward to seeing some more of the cultural differences that emerge during the discussions.

The Well Rounded Architect

In this blog post, I explore the six different dimensions I covered in my recent talk at the O’Reilly Software Architecture conference in London called “The Well Rounded Architect.”

The elements of the well-rounded architect

The Well Rounded Architect

Acting as a Leader

Good software architects understand that their role as a leader is not necessarily telling developers what to do. Rather, good architects act like a guide, shepherding a team of developers towards the same technical vision drawing upon leadership skills such as story-telling, influencing, navigating conflict and building trust with individuals to turn their architectural vision into reality.

A good leader, and thus, a good architect, will listen carefully to the opinions of each contributor, fine-tuning their vision with feedback from the team. This leads well onto the next point.

Being a developer

Making good architectural choices is a function of balancing an ideal target architectural state with the current state of a software system. As an example, there is no sense in adding a document database to a system if the problem domain is better suited for a relational database, even if that’s boring. An architect may feel tempted to impose technologies or architectural choices without considering the fit for the problem space – AKA behaviours of the “ivory tower architect.”

The best way an architect can mitigate this is by spending time with developers and time in the code. Understanding how the system has been built up, and the constraints of the system as it stands today will give the architect more information about the right choices for today’s environment.

Having a systems focus

Seasoned developers know that code is only one aspect to working software. To make code run, a seasoned developer understands there are other important quality attributes necessary for code to run well in its production environment. They consider aspects like deployment processes, automated testing, performance, security, and supportability. Where developers may approach these quality attributes ad hoc, an architect will focus on understanding not just the code but also the quality attributes necessary to meet the many needs of different stakeholders such as support, security, and operations staff.

The good architect focuses on finding solutions that can satisfy as many of these different stakeholder needs instead of choosing a tool or approach optimised for the preferences or style of a single contributor.

Thinking like an entrepreneur

All technology choices have costs and benefits, and a good architect will consider new technology choices from both perspectives. Successful entrepreneurs are willing to take risks, but seek ways to learn quickly and fail fast. Architects can approach technology choices in a similar way, seeking real-world information about short- and long-term costs and the likely benefits they will realise.

A good example is when the architect avoids committing to a new tool based on reading a new article, or having heard about it at a conference. Instead they seek to understand how relevant the tool is in their environment by running an architectural spike to gather more information. They don’t pick a tool based on how good the sales pitch is, but what value it offers, given what they need for their system. They also look for the hidden costs of tools such as how well is a tool supported (e.g. level of documentation, community adoption), how much lock-in the tool brings or the extra risks it introduces over the long-term.

Balancing strategic with tactical thinking

A lot of teams build their software reactively with individual developers choosing tools and technologies that they are most comfortable with, or have the most experience with.

The good architect keeps an eye out for what newer technologies, tools or approaches might be useful but does not necessarily draw upon them immediately. Technology adoption requires a considered approach looking at a long-term horizon. Architects will seek for a good balance between agility (allowing the team to move fast) and alignment (keeping enough consistency) at both a team and organisational level.

An exercise like the Build your own Tech Radar is a useful tool to explore technologies with strategy in mind.

Communicating well

Architects know that effective communication is a key skill for building trust and influencing people outside of the team. They know that different groups of people use different vocabulary and that using the technical terms and descriptions with business people makes communication more difficult. Instead of talking about patterns, tools and programming concepts, the architect uses words their audience will be familiar with. Communicating technical choices to business people with words like risk, return, costs, and benefits will serve an architect better than the words they use with their development team.

An architect also realises that communicating within the team is just as important as outside, and will use diagrams and group discussions to establish and refine the technical vision, and use a written log like an Architectural Decision Log or a wiki to provide a historical trail for future generations.

Conclusion

Doing the job of a well-rounded architect is not easy. There are so many elements to focus us, each drawing upon many skills that a developer often doesn’t focus on practicing. What is most important is not necessarily the ability an architect has, but that they have enough expertise in each of these different areas to be effective. An architect who is skillful in only one of these six areas described above will not be as effective as an architect who has a good level of expertise in all of them.

Making Change Stick

A gym instructor told me yesterday that it was the day that most people statistically give up their new year’s resolution. Whether or not it is true, it got me thinking about what works when changing behaviours, whether individually or in an organizational context. What follows are some of my favourite approaches to making change stick.

1. Keep it small

In my experience, the bigger the change is, the more likely it is to fail because old habits come back, or the change hits too many barriers. A more significant change means less chance of success because it requires more time, energy and motivation to accomplish – all of which can easily run out.

Five years ago I was unsure about whether I could be a full-time vegetarian. Rather than commit to being full-time vegetarian, I kept it small by deciding to trial it for an entire month. In this time, I made myself experience as many activities I enjoy in the trial period (eating out, traveling) to work out being full-time would not suit me. In the end, I decided a 2-day per week vegetarian habit would work instead.

If you want to make a change, find smaller steps towards the end goal.

2. Build on an existing habit

I have a friend who gave up smoking but took up a running habit instead. After talking to him, I realised a lot of his success was described in the book, “The Power of Habit.” In this book, they describe how we often build responses to stimulus as rewards, which eventually becomes a habit. Our first approach to change is to simply stop the response but habits make that difficult because they are automatic.

The book explains that stopping the habitual response hard. However replacing the response with a different response can be a lot easier.

3. Keep it social

One of the many reasons fitness websites like Runkeeper want to connect you with your friends it that social pressure and acknowledgement from family and friends is a really powerful mechanism for instituting change. Websites like Runkeeper fail because they treat every connection the same, even though we have different types of relationships with people. Acts such as making a commitment to a group of close friends, or training regularly with the same group of people is great motivation to maintain a new change.

I saw this most recently when a bunch of friends and I signed up for a Tough Mudder. Before the event, a friend of mine didn’t regularly train. They knew the event would be a challenge so hired a personal trainer and went regularly several times a week. In the course of six months until the event, they built up the fitness, strength and skills required by Tough Mudder and finished it brilliantly.

4. Visualise the end state

One of the wonders of our human mind is our ability to influence the future simply through belief (or what’s commonly known as the Placebo Effect). In organisations and in personal coaching, I find the Futurespectives activities of the most powerful practices because it helps people imagine what the future state could be like.

All too often people fail at change because they focus too much on what is blocking them rather than focusing on what they can do to move towards this end state. An exercise I know used by a few friends is the Letter from the Future to visualise their desired end states.

5. Celebrate, celebrate, celebrate

With my experiences using appreciative inquiry, I have found that celebrating the small achievements for what is working is often a more powerful motivating factor than focusing on what didn’t work. It leads into a positively reinforcing loop that can establish new habits and make lasting change as pictured in the diagram below.

Cycle of celebration improving motivation

Conclusion

There are many other opportunities to make change stick I find that these five steps are the techniques and practices I draw upon the most. Books I have found useful on this topic include

What do you do to make change stick?

Book Review: Difficult Conversations

Conflict, negotiation and difficult conversations are hard, but there are plenty of good books help. I often recommend Crucial Confrontations, Getting to Yes and Getting Past No. Someone recommended Difficult Conversations, a book that I recently finished reading.

Difficult Conversations
Difficult Conversations

Where the other books I read tended to take a more mechanistic view of steering the conversation, I really appreciated the slightly different take with this book, which I felt more humanistic because it acknowledged the emotional side to difficult conversations. The authors suggest that when we have a difficult conversation, we experience three simultaneous conversations:

  1. The “What Happened” Conversation
  2. The Feelings Conversation
  3. The Identity Conversation

The “What Happened” Conversation

We often assume we know what happened, because we know what we know (Our Story). The authors (rightly) point out, that our story may be completely different from the other person (Their Story). A good practical tip is to focus on building the Third Story as a way of building a shared awareness and appreciation of other data that may make a difference to the conversation

The Feelings Conversation

As much as we like to think we are logical, we are highly emotional and biased people. It’s what makes us human. We manifest this by saying things based on how we are feeling. Sometimes we don’t even know this is happening. The book helps us understand and gives us strategies for uncovering the feelings that we may be experiencing during the conversation. They also suggest building empathy with the other person by walking through the Feelings Conversation the other person will be having as well.

The Identity Conversation

I think this was the first time that I had thought about when we struggle to communicate, or agree on something, we may be doing so because have difficulty accepting something we may not like, or something that threatens our identity. This is what the authors call out as the Identity Conversation and is a natural part of successfully navigating a difficult conversation.

Conclusion

I found Difficult Conversations a really enjoyable read that added a few new perspectives to my toolkit. I appreciate their practical advice such as stepping through each of the three conversations from both your and the other person’s perspective and avoiding speaking in different modes. I like the fact that they address the emotional side to difficult conversations and give concrete ways of understanding and coping with them, instead of ignoring them or pushing them aside.

5 Tips for Accelerated Learning

I spent all of last year in Berlin, where I focused on learning the German language. After years learning different programming languages like Java, C#, Javascript and Ruby (not to mention all the tools, frameworks and libraries) and several years training and teaching I figured I could “eat my own dog food” and apply what I learnt about learning to a real language.

Enter to Learn stone sign
Stone sign: Enter to Learn. Image take from flikr under the Creative Commons licence.

Since that year, I talked to numerous people impressed that I can speak fluent German after living in Berlin. They often ask me, how did I found my experience. This post is a good summary of what I found myself repeating. Firstly, if you really, really want to learn German, Berlin is probably not the best place since there are so many foreigners living there and the level of spoken English is ridiculously high. You can easily fall into hanging out with the English-speaking crowd, enjoy the city, and fail to pick up more than rudimentary German.

Although I have very specific tips for learning the German language, this is more focused on what helped me learn the most that I think applies to any subject.

1. Find different teachers

At the start of the year, I spent the first three months doing an immersive language course at the Goethe Institute. Over the two classes, I experienced four different teachers, each with their own style and emphasis on what is important to learn. Although I wished that I had spent less time with one of the teachers, I found their point of view was sometimes useful. Each teacher focused on different aspects and it made my learning all that richer.

Over the rest of the year, I found other avenues to teach me, guide me and give the feedback I needed to grow. If I had stuck with a single teacher, I would have missed out on a number of other valuable perspectives.

2. Have a goal, and keep focused on it

Unlike many European people, I was never bilingual as a child. Moving to England from Australia, I came to appreciate how useful a second language was by meeting many other bilingual people. Although I learned Japanese in school, I believe it is more important to have the ability to use it.As they say:

Use it, or lose it.

A whole year to learn a language was a once in a lifetime opportunity and my goal was to be fluent by the end of the year. I had a whole bunch of other personal reasons to learn German, but figured many things came into alignment and I would make the most of this opportunity.

I reminded myself throughout the year about my goal, and why it was important to me, and it helped me keep focus on the learning. It helped me in particular when the going got tough, and it will get tough!

3. Celebrate progress

After a year passed by, I met with some of my colleagues again who were impressed that I could now speak with them fluently in their native tongue. Although it’s easy to celebrate that final result, there were many times along the way that I wanted to give up because it was hard, and I felt frustrated that I felt like I wasn’t learning as fast I wanted to.

I was sharing a flat with a German, who knew that I was wanting to speak fluent German. Although he could speak English very well, he spoke only to me in German even if it would have been easier for him to communicate in English. I remember coming home one day, exasperatedly asking, “Can we just speak in English?!” His answer, “Nein!” (No, in German).

Although there were bad days, there were also good days and I made sure to sit back and acknowledge these small milestones, such as watching my first film in German with subtitles (and understanding most of it), completing my first German novel, and going to the Town Hall to register myself without speaking a word of English!

Each small step moves you towards your final goal, and celebrating progress will help you overcome the learning hurdles you experience along the way.

4. Vary your learning activities

One problem with a long-term learning goal, is that you will get bored and distracted. At the start of my year, I was naturally doing a lot of grammatical textbook exercises which was useful for the classroom. However I couldn’t see myself continuing to do just these exercises for the rest of the year. I wanted other ways to learn but would help me keep engaged. Therefore I combined learning German with other activities that I enjoyed, such as meeting with people (the German Stammtisch the language school organised was a good one), watching movies and reading books I liked in German (thanks library!), meeting with a tandem partner, and listening to the radio.

A friend gave me the book, “111 Orte in Berlin, die man gesehen haben muss” which roughly translates to, “111 must see places in Berlin.” The book has two pages for each place, one with a short description and the other with a picture and was perfect for dipping in and out. I could read about a place I wanted to visit, and because I lived in Berlin, could go and see what it was talking about. At the same time, it helped me deepen my vocabulary and help me experience the unique experiences Berlin had of offer.

Later in the year, I spent some time traveling around in Germany, where I did a number of tours in German. Each of these experiences kept the learning alive for me and I never grew bored about “learning German” because I was doing it at the same time as I was doing other activities I was enjoying.

5. Accept you’ll never be perfect

Early on in my career, I discovered the idea of the Beginner’s Mind (Shoshin). For me, part of this accepts that I do not, and cannot know everything and that means there are new things to learn. In learning German, I found that my vocabulary will never be as rich as it is in English because there are situations I have never found myself in.

A good example of this was talking to a friend of mine when we first worked in a German-speaking office. She told me this story:

Although I studied German at school and was very fluent, I was shocked the first time that I was running a project kickoff for a German-speaking client. Not only was I learning new German words for the domain (transportation) but I was also learning new German words for technology terms I had taken for granted.

Our experiences shape who we are, and we cannot possibly be experts at everything, and that’s perfectly fine. I found it was more productive to focus on getting better than worrying about how close to mastery I was.

Conclusion

After years of coaching, teaching and training technology, I have many techniques that I consider useful as learning strategies. I found last year was a great opportunity to try applying some of them to a completely different skill and see how far I could go. Happily, it seemed to have worked.

I hope you found this article useful and that you will find these tips above useful. In summary, try to:

  1. Find different teachers
  2. Have a goal, and keep focused on it
  3. Celebrate progress
  4. Vary your learning activities
  5. Accept you’ll never be perfect

What other learning strategies do you find work for you?

Tech Lead – Circles of Responsibility

One of my projects this year is a training program for developing Tech Leads. In preparation for the course, I developed this diagram below to explain what areas we focus on and found the model resonated very well with people who interact with Tech Leads, but probably don’t really know what Tech Leads do. I also found it has been a useful model discussing it with new or current Tech Leads about areas of potential growth. This model explains the Tech Lead role as intersection of three other roles – A Developer, a Leader and an Architect.

TechLeadCircles

A Tech Lead is developer who is a Leader

A Tech Lead wouldn’t be the same without being technical and there are a whole bunch of development skills I would expect any capable Tech Lead of having. In today’s age of agile development practices, there are a whole set of engineering practices, I would expect Tech Leads capable of doing such as refactoring and Behaviour/Test-Driven Development.

What makes a Tech Lead different from developers is their breadth and depth using leadership skills to help the team move towards a goal. Unlike developers who can avoid giving feedback to their peers, a leader must be able to give and receive feedback to help people develop and be more effective. This means not only focusing on the technical aspects, but also the team and people aspects such as relationship building, motivating, delegating, and influencing.

Tech Leads must work to resolve conflict. Conflict itself is a sign of a healthy team, but only when the Tech Lead creates an environment where conflict is resolved.

Developing skills in the Leader role

Developers have little opportunity to practise leadership skills. Tech Leads are fortunate to have many resources that address the leadership circle. Leadership skills are important to all leaders regardless of industry or position and you can find a plethora of books, training courses and websites.

A Tech Lead is hands-on Architect

I have written in the past that I expect effective Tech Leads and Architects to have some level of coding ability. I have even gone so far to suggest they should ideally spend a minimum of 30% of their time in the code.

Developers spend much of their time in the code, but unless they start thinking of the bigger picture, it is difficult for them to start thinking beyond that. Tech Leads must help the team to:

Build systems, not software

This mindset shift helps developers think about a lot more than just the software – to start thinking of the quality attributes of software systems (or the Cross-Functional/Non-Functional Requirements) as well as the whole interaction with the deployment environment in which the software lives.

When someone plays the Architect role, they are naturally taking a broader view of the software – how long it’s going to last for and how it is going to evolve over time.

Developing skills in the Architect role

The Software Architect role is much newer compared to general leadership and although there are some resources available, I cannot recommend many of them because they either focus on the tooling, or they teach little that help people bridge the gap.

Although people are writing books, articles and training courses that address this circle of skills, more still needs to be done.

What I’m doing about it

Most training courses that exist focus on a single tool, a single approach but rarely focus on a broad view that also gives developers a better understanding of the Tech Lead, particularly the Architect side to the role. I have run a hands-on course for Tech Leads that helps people build more awareness and gives people and opportunity to practice some of the skills outlined in the model above.

Although we touch about some of the skills in the “Leader” role, I focus the contents more on the “Architect” role because there are fewer resources available. If you’re interested in this course, please get in touch and I plan on writing another blog entry detailing what we cover.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Booklist from the Retrospective Facilitators Gathering 2014

The Retrospective Facilitators’ Gathering is the only conference I planend on attending in 2014. Like many conferences, I end up with many books to read, and thought it’d be worth sharing the list I accumulated here:

Book Review: The Coaching Bible

I’ve had this book sitting around for a while, but I thought I should get around to reading it. The snow in London and the cold weather gives me a perfect reason to get through a little bit more reading. The Coaching Bible: The essential handbook focuses on some of the skills an effective coach requires, and introduces a few tools that a coach can use.

The Coaching Bible

The book is largely domain agnostic, although the coaching examples they use tend to be focused on a business context (i.e. not life coaching, sports coaching or agile coaching). I think that makes it quite accessible to any person interested in developing coaching skills, but aren’t necessarily looking to be a full-time coach themselves.

They introduce this “Multi-modal” coaching model made up of four different perspectives a coach can focus on:

  • Logical levels – Beliefs (why), Environment (where, when), Behaviours (what), Capability (how), Identity (who). A good point is that an effective coach considers which logical level to focus on and where their efforts might have the most impact. Doing so at the wrong logical level leads to frustration and an ineffective coaching relationship
  • Remedial versus Generative Continuum – Coaching falls along a spectrum, of whether or not it needs to be targeted at a specific instance (remedial) or outcome, or help with exploring options (generative). Once again, consider what is most appropriate for the situation.
  • Systemic Context – With a strong nod to one of my favourite books on systems thinking, The Fifth Discipline: The art and practice of the learning organization: Second edition, the idea here is that coaches are working with people who are working in a larger environment that drives their behaviour. It’s useful to step back and view this larger context, and explore it as part of the coaching conversations
  • Interpersonal-intra psychic continuum – Lastly, and the one I understood the least, is the idea of trying to not simply focus on external relationships/observations but also to think about exploring the inner beliefs and internal drivers of the coachee.

I agree with quite a number of the other chapters in the book and I think they offer quite a number of practical examples and advice on items a coach focuses on, such as “Building the Alliance” with a client (agree on how/when to meet, develop an agenda, establish goals and how to measure progress) and the importance of identifying the “Mind-Body-State” necessary for both you as a coach, and the coachee to have a healthy conversation.

One of the most useful resources for a new coach is also found in the appendix, referring to core competencies outlined by the International Coach Federation.

Reflections on Agile 2012

Another year, another agile conference. It’s time for reflecting on the conference and uncovering lessons learned. Dallas, Texas hosted this year’s Agile Conference. More accurately, the Gaylord Texan Resort in Grapevine hosted this year’s Agile Conference. Loved by many at the conference (notably less so by Europeans) the resort reminds me of the Eden Project and a weird biosphere (see picture below) that is self-contained and fully air-conditioned. Although maybe this wasn’t such a bad thing with a West Nile virus outbreak in Dallas.

Needless to say that I stepped out quite a bit to try to get some fresh, if not, refreshingly humid air.

Onto the conference. It was very well organised, very well run and even rapidly responded to feedback (such as moving rooms when demand proved too much for some of the anticipated sessions. Food came out very promptly in the different breaks. We didn’t have to queue too long and the variety was pretty good. The only breakdown was probably the Tuesday lunchtime where it wasn’t clear we had to get our own food and with a limited number of on-site restaurants in our self-enclosed bubble world, proved to be a bit of a tight squeeze in schedule.

The people at the conference seemed to be a bit of a mix. Mainly lots of consultants like myself sharing their experiences, but as one person noted, an extraordinary number of agile coaches all apparently looking for work. On the other extreme there seemed to be lots of companies adopting agile and lots of people selling tools and training to help them.

Lots of parallel tracks meant lots of choice for many people but I often found it hard to find things that worked for me. I’m less interested in “enterprise agile adoption”, and more interested in the practices pushing the boundaries, or the deep insight offered by people. The few technical sessions I went seemed to be aimed at a bit more of an introductory audience. I particularly avoided any of the “do this with scrum” or “do this with kanban” as these appeared by be pushing.

In terms of keynotes, I thought they did a great job of assembling some diverse and interesting sessions. Although Bob Sutton (No A**hole Rule author) felt like he didn’t do much preparation for his keynote from the text heavy slides that jumped at different paces, he had some good anecdotes and stories to share. My biggest takeaway from that session was thinking about taking away practices just as much as adding practices, something that I think I do implicitly but should try to do more explicitly. The other keynotes were pretty inspiring as well, with Dr. Sunita Maheshwari behind Telerad talking about her accidental experiment moving into doing remote radiology to support the night-shift need of hospitals in the US and the interesting growth of their business. The other really inspirational keynote was by Joe Justice, the guy behind the amazing Wikispeed project taking sets of agile practices and principles back into the car-making industry. I felt he really knew his stuff, and it’s amazing how you can tell someone who really understands the values and trying to live them in different ways and then translating them into a different world. Very cool stuff that you should check out.

In terms of other workshop sessions, I left half way through many of them as the ideas were either too slow, or not at all interesting (such as one on Agile Enterprise Architecture that spent 30 minutes trying to go back to the age-old debate of defining Enterprise Architecture.)

Two of my most favourite sessions was one by Linda Rising who gave a very heart-felt and personal Q&A session that left many people in tears. Her stories are always very personal, and I really admire her ability to look beyond someone’s words and really uncover the true question they are asking with a usually insightful answer as well! The other session was listening to the great work that Luke Hohmann of Innovation Games has been doing with the San Jose government to change the way they make decisions about where the money goes through the use of games and play. Very awesome stuff.

I had my session in the last possible slot on the Thursday and had a large number of well known people in competing slots such as Jeff Sutherland, Esther Derby and Diana Larsen. I’m very happy with the turn out as we had a lot of fun playing games from the Systems Thinking Playbook including a number of insightful conversations about systems thinking concepts and how they apply to our working life. One of my most favourite exercises (Harvest) that demonstrates the Tragedy of the Commons archectype played its course and we finished in just three years (iterations) only due to a constraint I added early into the game. I love this exercise for its potential for variation and the insightful conversations about how this applies to agile teams, organisations and functions.

You often can’t come away from conferences without new references, so here’s the list of books and web resources I noted down (but obviously my summary is without actually reading into it, so YMMV):

Thoughts from Øredev 2011

Keynote 1: Alexis Ohanian

The first keynote titled, “Only your mom wants to use your website” came from Alexis Ohanian, a geek who helped create Reddit, Hipmunk and a few other sites. He’s passionate about users and you can really see how that manifests itself and very appropriate for a conference with a theme of Userverse. He told the audience, “As geeks, we’re at an advantage. There are so many bad websites out there so if you focus on creating an awesome experience, it’s very easy to compete.” It just came back to treating your customers and really delighting your customers.

He uses some really great examples about how he engaged users with a couple of his websites. For example, with Reddit, there’s the mascot in the top hand corner of the page and talks about doing a 30-day animation series that really connected with dedicated reddit users who were so concerned when, during one the days, the mascot went missing and they emailed in constantly to find out where he went.

With hipmunk, he recounts the story of personally stuffing envelopes with handmand hipmunk travel stuff to send off to some of his users. For no good reason other than to surprise them. In return, people sent photos of the hipmunk in all sorts of places and travelling around. It’s the little things that really delight.

Keynote 2: Neal Ford

Neal’s a really awesome speaker and would highly recommend any technical person to watch his very strong presentations. Fortunately it looks like JFokus just published the same speech Neal gave at Øredev so you can see. The focus of his topic was really about Abstraction Distractions and is a really important key message for us technical folks. It also really relates well to this XKCD comic.

The whole premise about his talk is that users don’t really want to hear the techncial reasons why something does or doesn’t work. You have to make them undersatnd the impact of what it has. He seeds the presentations with lots of pro-tips including things like, “Don’t confuse the abstraction with the real thing” giving the example of wanting to store a recipe and concerned about how to store a recipe that will last many technologies, that even its representation isn’t quite the same thing as the recipe itself.

The ImageThink graphic facilitators had trouble keeping up with the pace that Neal speaks at. He’s definitely the sort of high energy, many idea kind of guys.

Keynote 3: Dan North

Dan is a great an entertaining speaker than everyone really enjoys. He spoke on “Embracing Uncertainty – the Hardest Pattern of All.” I guess a lot of his entertaining anecdotes and stories were really focused around our human bias for closure.

Keynote 4: Jeff Atwood

I’m glad to hear Jeff present this keynote, “Social Software for the Anti-Social Part II: Electric Boogaloo” as he handed over one of his speaking slots to an employee of his in a talk on a previous day that turned out to be a bit of a disappointment for many people. His keynote carried on from a previous talk, carrying on with lots of lessons learned, particularly about how they built Stackoverflow with game mechanics in mind.

It’ll probably be online soon, but it’s one definitely worth watching as it’s an interesting balance between democracy, openness yet some directing behaviour thrown in.

About the conference

I’m constantly impressed by the organisation and the the quality of the conference. I’m really surprised it doesn’t attract more people from Europe and what I call, a little bit of a hidden gem. It has some really wonderful speakers, great topics and the venue itself is pretty good (although there’s poor noise isolation between the different rooms). There’s plenty of interesting events in the evenings and a great place to chat to people both during and after the conference, although I think the “unofficial” Øredev pub needs to grow a bit to accomodate so many geeks.

Other talks of significance

I went to quite a number of talks but will write up some of the more interesting ones (for me).

  • Copenhagen Suborbitals – This was a bit of a surprise talk. It was very late in the day, ending almost at about 9pm or 10pm and was a guy based in Copenhagen who’s attempting to build his own spaceship to launch him into suborbital. It’s a really amazing tale and one I can appreciate for a guy who’s serious about following his passion. The talk started off quite entertainingly about how building a spaceship was a bit ambitious, so he started off by building a submarine! He’s a really engaging speaker and I don’t want to ruin too many of his good stories. I suggest going over to his blog (he’s still building his spaceship) and seeing where he is. He relies on donations to keep this project running and I love the fact it’s such an open-source project as well with people offering their advice and expertise in many different areas. He’s got lots of great lessons to share that are completely relevant to everyone.
  • Aaron Parecki on his startup story for Geoloqi – I listened to this guy talk about his startup, and similarly along the same lines at the Orbitals, he told the tale of what started off as a hobby eventually turned into a real startup opportunity and shared a lot of his lessons along the way. It’s an interesting start up that you can read more about on gizmodo here
  • Jeff Patton – Jeff had a great session introducing people to the UX stage and trying to set the stage for lots of the other speakers. Jeff has a wealth of wisdom and experience to share and what was really powerful was him sharing images and stories about the different roles and techniques people use to build useful software and integrating it into agile processes. Really powerful stuff that I think every developer should really go through.

Reflections on my talk
Titled, “Collaboration by better understanding yourself”, I presented on the idea that we have lots of in built reactions as developers that really hold us back from collaborating more effectively. My goal was for people to go away, thinking more about the things that effect them and why they don’t collaborate as much as they should. I got some great feedback and was particularly nervous because not only did I have a good number of people but I had many other presenters I really respected in attendance including Portia Tung, Doc List, Johanna Rothman, Jean Tabaka, Jim Benson and more.

Although I’d practiced, there’s a few more tweaks I would make to this, but was very happy with some of the people who came up to me throughout the conference who felt that they really connected to the topic and felt really enthused to do something about it. Exactly what I wanted. 🙂