It’s been a long time…

My last post on this blog was an announcement that I had started a new job as the Software Engineering Manager for FillZ.com, a subsidiary of AbeBooks.com (itself a subsidiary of Amazon.com). The last seven months has been a terrific whirlwind of activity, learning, and adjustment to the new role, and I’m happy to report that I’m loving it.

One of the most interesting activities over the past few months has been the evaluation of a new tool set (languages, frameworks, deployment tools, etc) for our upcoming projects. I’ve decided to write a series of posts about the evaluation, our decision, and how that choice is working out for us.

First up: the evaluation process.

2010 Blog-Stats in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 2,300 times in 2010. That’s about 6 full 747s.

In 2010, there were 24 new posts, not bad for the first year! There were 7 pictures uploaded, taking up a total of 158kb.

The busiest day of the year was March 4th with 98 views. The most popular post that day was A Walk Through the Past – Google Style.

Where did they come from?

The top referring sites in 2010 were facebook.com, forums.pragprog.com, twitter.com, blog.cliffmccollum.com, and linkedin.com.

Some visitors came searching, mostly for this meeting has 22 minutes, leading software, genologics financial performance, “jochen stier”, and michael artemiw.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

A Walk Through the Past – Google Style March 2010
4 comments

2

This Meeting has 22-Minutes (or does it) March 2010
6 comments

3

About Me January 2010

4

Boredom – know thy enemy March 2010
5 comments

5

Share Shamelessly April 2010
8 comments

Slides from past presentations

Back in April and May of 2010 I gave two presentations to the VIATeC Software Development Managers’ Roundtable. The April presentation covered many of the topics from this blog prior to that date, and the May presentation focused on planning good meetings and holding great retrospectives.

I finally got around to posting the slides from those presentations online. You can now view the April and May presentations at Slideshare.

Creating Universal iOS Applications

Last night (September 29, 2010) I gave a presentation to the Vancouver Island iOS Developers’ Group. The topic was Creating Universal iOS Applications (iPhone + iPad). While attendance was intimate with only seven people there, it was a great discussion. I have posted the slides from my presentation online. Check out the slides at Slideshare.

It was also a terrific way to see what other iOS developers are doing around town. I was blown away by Sound’s quick demo of a new game he is working on for Cedar Hill Games. It’s a 3D RPG-style title they hope to release around year-end. My prediction is that it will get rave reviews.

This was only the second meeting for the group. I know there is an increasing amount of iOS development activity in Victoria, so I expect the group to grow significantly in the coming year. If you’d like to check it out, learn more about the event schedule on Facebook.

Conflict Resolution

Conflict. It’s something you probably deal with every day. Sometimes it’s minor and doesn’t draw upon skills any more advanced than those you learned in your first few years of grade school (fortunately, shoving the other person to the ground is not an acceptable practice once you’re an adult). Sometimes however, the problems are more difficult and cannot be solved with simple tools. When you meet these kinds of problems, you need something more formal.

As a Software Development Manager, the most common cause of conflict shouldn’t be between people on your own team. Hopefully your teams run smoothly enough that you don’t have to solve those kinds of problems regularly. Instead, most of the conflict you likely encounter is with your customers.

Let’s make time for a quick side-note here. Just what do we mean when we say “conflict”? As it turns out, there is a pretty precise meaning for this word. It means quite simply that one person’s view of a situation is not aligned with someone else’s view of that same situation. The beauty of this definition is that it highlights an interesting point: one person can be in conflict with another, without the other person being in conflict in return. If you think your partner should feel a certain way about a particular issue, but your partner doesn’t care about the issue in any way, you might be in conflict, but your partner isn’t.

How can you use your understanding of conflict to resolve challenges with your customers? Well, any time you or your customer disagree about the view of a particular situation (say a scope document, or the timeline for a project) you have a conflict. I can already hear you saying to yourself “thanks Cliff, as if that wasn’t painfully obvious.”

But here’s the less-obvious point. Once you are in a conflict with a customer, the tendency is for everyone to focus on resolving the conflict before allowing any other progress to be made. If you feel you need to invest fifteen man-weeks of work to resolve that conflict, or your customer feels they have to accept a multi-month delay to resolve the conflict, you are playing a high-stakes game. Everyone ends up on the defensive and true progress becomes very challenging.

The next time you are in this situation, try something different. It starts with remembering that conflict is about each person’s view of the situation. You might genuinely want different outcomes from the situation, but that’s not the conflict; the conflict lies in each person’s views. If you can resolve the conflict of views, you can remove a very real source of stress and difficulty, and put the project in a better position to find a solution both parties will accept.

Enter the Gap document.

This is a document that articulates the points of a conflict, turning what was a disagreement into something two parties can agree on. Once everyone agrees on the gap, it breaks the conflict’s momentum and allows everyone to start finding paths forward.

Gap documents are essentially very simple things. They state, point by detailed point, what each person in the conflict believes to be the truth, and describes the gap between those two positions. For example, one entry in your Gap document might be:

Customer: The product must collect dollar amounts in any number of international currencies.

Developer: The product was only specified to support US and Canadian currencies. It does that well.

Gap: The product does not support non-US and non-Canadian currencies. The customer requires additional currencies to go into production.

Why is a document full of this stuff useful? Because it gives both parties a single item they can agree upon. If you have captured the customer’s expectations properly, they will readily agree to the statement about their needs. If you have captured your corporate position properly, you can readily agree to that statement. If you are honest in the document, and don’t use heavily biased language, both parties should be capable of agreeing on the Gap between the two statements.

The beauty of this document is that nobody has given up their position, yet both parties now agree on a common statement. From this document there is a clear path forward: you take the Gaps one at a time and work out a path to resolution. The document doesn’t make the resolution steps any easier, but it removes the conflict, which is often a huge part of the problem in the first place. Now you have two parties agreeing on what is wrong and working together on the solution.

If you aren’t convinced this can work with your customers, try it inside your team first. If you’ve never used a method like this before, I am confident it can make a difference.

About Leading Software

I am writing a book.

This book is about being an effective Software Development Manager. It’s not about how to follow a particular process. It’s not about how to build great teams. It’s not about how to estimate and schedule better. It’s not even about being a good Team Lead. There are already great books about those things and I’m happy to let them be. Instead, this book is about the hundreds of tiny things that make success in the role of a Software Development Manager so unique.

It’s a bit of a wonder that you’re reading this on a blog. I had no shortage of personal struggles getting here. I knew that I wanted a lot of input into this book and that a blog would be a great way to do that. But I found myself seriously questioning my philosophy about openness. What would happen if I provided every chapter of my book, out in the open, at no charge, long before the book is published? Would it make it harder, or impossible, to find a publisher? What would it do to the eventual sales numbers?

In the end, I decided to forge ahead and I’d like to thank a friend at work for convincing me that I had no real choice. If my book’s presence on this blog guarantees that I don’t make any sales, then it probably isn’t a very good book anyway. If it is a good book (as I sincerely hope it will be) then the readership will be far broader than a blog and people will pay to have a copy in their own hands. If I’m wrong, then I may have to join all those old-school publishers who claim the openness of the Internet is killing their business. Let’s hope it never comes to that.

I hope you like it,

Cliff McCollum,  21 Jan 2010