Long, long ago in a company not far from here I worked for a company that was full of smart, capable people.  We did good things without any defined process.  Knowing what I’ve learnt since and especially reading about the experience of others it was amazing.  Either we were incredibly lucky, super smart or there was something else stopping us from creating nothing but train-wreck software.  I’m voting for something else since the luck thing doesn’t sound right and I don’t think I’m super smart.

So what do I think this something else was?  I think it was related to putting a capable person, who cared about almost nothing except for getting a good project out the door at the centre of the project.  Because I was at the company for a while (more than 10 years) and was interested in nerdherding I paid attention to the leadership/management of the teams and was able to correlate project success with the different team and project philosophies used on each project.

The most interesting failure in the company was a project that was months late and didn’t seem to be capable of delivering.  In fact, the project team didn’t even have a list of the features that it needed to implement or the bugs that needed to be fixed prior to delivery.  What was interesting was that once we realised that the project was going nowhere we only changed one thing.  We added a person to the project who was responsible for working in the middle of the team to make sure that the project was delivered.  Nothing else was changed - the technology, tools, daily processes and staff all remained static.  The person in the middle maintained a list of tasks that needed to be done, talked to everyone (individually) to find out what they were working on, doled out work to those who needed some, guided features towards simplicity and sought help for people who were struggling.  Think of the role as a task-nazi/coach or an unholy amalgam of a customer representative and a lead developer or perhaps a project manager who worked at a half-day granularity and understood the business.  After this change the project quickly build up a head of steam and finished only a few weeks late.

Other interesting failures at the company had to do with strict functional splits on projects.  You know the thing - business analysts too separated from software developers who are too separated from test resources, etc.  Even if each of the individual functions was communicating well with each other function, unless there was a person who co-ordinated and guided all of the interactions then things went wrong.  The worst example of this was on the company’s biggest ever project.  The project limped along and was delivered, but in the end wasn’t what was needed by the customer and was eventually canned (resulting in lots of job losses and investor money evaporating).  If only a person was put at the centre!

I’ve seen similar failures and successes at other companies often strongly correlated with the presence of a person in the middle.

Now I know that there have been plenty more advances in process and I’d rather use a more complete agile process any day but if you don’t really have a process or you use a waterfall variation then for the love of all things good, please put a single, capable person in the middle of each of your projects.

How’s your bedside manner? Do you think about how you interact with people with less experience or knowledge than you? You should. At a very specific task level nerds almost always know more than everyone about their work. Consider the code feature or document you have just finished. Unless you have paired with someone for the entire task you know the most. In fact, almost everyone is trusting that you have done a good job and that you have done it the best way. This includes most of your colleagues, your boss and especially your customers.

At higher levels of abstraction or with larger tasks the effect is reduced but still there. The chances are that your boss knows much less about your current project than you. Ditto for the customer.

If you are more of a nerdherder than a nerd then your boss and customers are definely at your mercy with regard to information and trust.

When you deal with all of these people who know less than you and are relying on you how do you interact with them? Do you think about the fears they have? Do you respect the trust they are putting in you? Do you take time to ensure they understand as much as they want to and are capable of?

Understanding the goals, fears and concerns of the people who rely on your expertise and judgement will help you do a better job. It will also help you to advance your career - nobody likes working with someone who doesn’t seem to care about others and no (sensible) manager would consider placing such a selfish person in a position of increased responsibility.

One of the more frustrating things that nerdherders (and nerds) have to deal with is omnibus information - those annoying emails or bug reports that contain an often random collection of requests or problems all mashed together in a series of loosly connected paragraphs and long lists of dot points. They are hard to archive/file and if an email reply is warranted then the different issues get in each others’ way. When they are but in front of your more organised and anal-retentive nerds they say to him/her “I am sloppy and don’t care about information, I can’t keep track of my thoughts and don’t really care if you do either”. Basically, this sort of information is less useful that it could be and makes the job of those interpreting it harder than necessary.

Making it easy for your friendly local nerds to serve you better can be done by following a few simple guidelines. So without further ado here is the Nerdherding guide to helping yourself with requests to nerds:

1. If you want to talk about two unrelated issues or problems then send two emails or create two bug reports. They can then be nicely moved through any process without tripping anything else up.
2. If you feel the need to conserve bits and simply must combine multiple unrelated issues then please clearly number or label each separate item. I’m amazed by often in my career I’ve had to deal with work requests containing dot-point lists - its embarrasing for everyone when I have to say “tenth dot point in the second list”.
3. If you have to communicate a high priority issue with other less important issues then please separate out the high priority issue. Its less likely to get lost in the noise and means that the less important issues won’t be ignored.

P.S. I must admit that sometimes I tend towards the “organised and anal-retentive” end of the spectrum.

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.