Nerdherding for Beginners

This is one of those chicken and egg problems.  You are a nerd working on a team and you think that you’d all do well if there was someone responsible for the architecture (or design or builds or tests or…).  In fact, you think that you are the perfect candidate.  There isn’t a job opening.  Nobody has announced the need.  What do you do?

Should you talk to you boss and suggest that you starting doing it?  What if she says that she can see that such a role might be needed but that you don’t have any experience?  What if she says that your teammate Max would be better at the job and calls him into her office?

As you might guess I think that the best thing to do is to starting doing the job on the side.  It will probably mean extra work.  It will probably mean needing to convince co-workers that your ideas are worth it.  However, the best way to show that you can do something and that its needed is to do it.  Be careful not to be sneaky and be sure that you aren’t stepping on anyone’s toes too hard.  Unless you work in a toxic environment your efforts will be appreciated and rewarded even if you aren’t successful in changing you role.

I’ve just started leading an internal workshop on Incremental Development. In the workshop I describe and delve into the difference between orienting development vertically (by use case) versus horizontally (by software layer or service). By use case is the clear winner since it allows progress to be tracked in a user meaningful manner and encourages a smooth flow of client value.

Johanna Rothman describes the different orientations as implementation by feature and implementation by architecture. These are clearer phrases.

I think I’ll be making a few minor edits tomorrow.

Software development training courses are a waste of time, money and effort and don’t equip people to do meaningful work. Supposedly they pass on new skills and knowledge to developers. In reality training courses are about:

• padding resumes,
• allowing managers and staff feel like they can tick the “staff development” box in a yearly evaluation form,
• sucking money from companies,
• giving people a 3-5 day break from work,
• letting developers off the hook for not doing their own professional development, and
• “rewarding” developers in a low-effort (for developers and managers) way.

In my experience as both a nerd and manager of nerds I’ve never attended a training course that has taught me anything that I hadn’t already known or that I couldn’t have learned in a fraction of the time with a little bit of effort. When I’ve sent developers on courses they often admit the same thing.

Lets look at some of the things wrong with training courses:

1. Training courses are aimed at the lowest common denominator - this is why they are so mind-numbingly slow, otherwise the guy in your course who can’t turn on his computer will complain and the training company will lose money.
2. Training courses are often inconveniently timed - how often is the right course run? Probably not when you need it.
3. Training courses are often a poor match for the actual need at hand - ever seen a course about the replacement of a Java servlet application with a PHP-based blogging tool to provide a corporate intranet? Me neither. But I have seen plenty of kitchen sink courses with lots of irrelevant junk.
4. Training courses are generally expensive. ’nuff said.
5. Training courses have a short retention half-life - unless you teach yourself or put into genuine practice things you learn you will forget stuff. Quickly.

Instead developers should be given time and resources (the Internet, books, self-paced learning CD’s, mentoring and guidance, access to others, etc) and a goal relevant to their upcoming work and asked to teach themselves. Does this take more effort? Sure. Is it more effective? That’s the wrong question - it will actually be effective where training courses aren’t.

We all need to stop pretending and bite the bullet. Managers should create customised training plans for developers that provide a combination of on-the-job activities, self-paced learning and guidance from existing experts. Developers should expect that they need to apply effort. Its okay to ask for help to create your training plan but its up to you to do it. You are a professional and its your career. Sitting in a room with a bunch of other bored developers really isn’t going to do the trick is it?

Over the past weeks I’ve been watching a team form. Its been a joyful experience. They’ve gone from being a set of individuals with no commitment to each other and very little trust to a true team that trusts each other’s expertise and motivations.

I think that a few things have helped this particular team form:

1. The team members realising that while they worried about each other the project was getting late.
2. The addition of a new team member who shook up the existing relationships enough to allow the team to re-form.
3. The acknowledgement and recognition by the team that it was up to them and that they have the freedom to decide how they will do their work. Nobody else was going to do it for them.
4. The injection of some agile management principles and ideas (courtesy of Crystal Clear).

The new team member is going on a long holiday in a couple of weeks. Hopefully, this won’t drop the team back into its old habits. I’ll keep you posted.

P.S. Perhaps someone should phone Steve Yegge and ask for his opinion on whether this is good agile or bad agile. I guess it must be bad agile since I don’t work at Google.

So you find yourself in your boss’s boss’s office. He’s sitting there in his nice suit and cufflinks smiling nicely. Its been about 5 seconds since you finished answering his question about that troublesome project you’re managing and he hasn’t said a word. Not one. Maybe you didn’t answer the question? Perhaps he’s annoyed at you? Maybe he didn’t understand? Perhaps you explained yourself so poorly that he’s stunned?

Probably not.

He’s probably just an arrogant jerk playing power games with you. You see there’s this technique that “important” people sometimes use on those who they are sure are in awe of their power and all round importance. They stay deliberately quiet when you indicate using non-verbal or verbal queues that you’ve finished talking. The hope is that since you are a normal person inbued with social graces that you’ll pick up the slack and keep talking. Then, as you grope around your little brain, you’ll spill the beans on your secret plans or whatever. After all you’ll be so flustered.

What should you do. Don’t panic and choose one of these two options:

1. Talk about anything even obliquely related to the subject. Go into enormous, banal detail. If you’re talking about a project schedule then list every task you can think of. Don’t forget to give a history of which people have had anything to do with each individual task. Most importantly, try not to pause for too long for at least a few minutes. The idea is to apply a bit of aversion therapy. He goes silent. You babble.
2. The alternative is to sit there quietly as well. After all he asked a question and you answered. If Mr Bossman has more questions then he should be able to ask shouldn’t he? After a while if he doesn’t get a flustered reaction from you he’ll probably not try it any more.

Hopefully you’ll never face the situation. I’ve only had it tried on me a few times. The first time I was flustered and madly groped around for a while trying to answer the question. By the next time I’d worked it out by reflecting on how uncomfortable I was the first time. I used the babbling technique which worked - no more attempts from that guy. The last time, with a different person, I tried the going silent technique. I also tried to smile knowingly at him. He gave up on the discussion (probably because he thought I was a deranged axe murderer).

P.S. If you’ve ever used this technique on someone then please stop reading my blog. We don’t want your kind around here.

Everyone knows that managers are clueless. They set impossible deadlines, they can’t delegate properly, they keep changing priorities and so on. Google has 1.8 million pages when searching for clueless manager. Clearly there is a lot of cluelessness going on. In fact managers are so clueless that most nerds don’t bother waiting to see if you’ll turn out to be clueless or not - they simply flip the clueless bit as soon as you are introduced.

New manager’s manager: Hi everyone, this is Manager, your new manager.

Everyone: [Clueless. Another bloodly manager the last one was so clueless. This one looks the same.]

New Manager: Hi everyone, as NMM said I’m your new manager. I’m looking forward to working with you all and finding out how I can help.

Everyone: [Clueless. Just as I thought empty platitudes. Clueless]

Now since you are reading my blog you clearly aren’t clueless are you. Unfortunately, unless you are joining an extraordinary organisation the chances are that lots of people will assume a lack of capability based upon their experience with others. Of course given your boundless ability you’ll turn these people around. Eventually. Until then you’ll have to deal with the consequences.

People who assume you are clueless will be less likely to come to you for help. Why would they bother? You’ll have to work hard to discover when people need help and be careful to actually provide genuine help.

People will assume that you aren’t equipped to understand their nerd problems. Be prepared for lots of slow explanations about how computers work or what XML is.  Worse, you’ll find that people will assume that you don’t care about quality and will sacrifice long-term benefits for short term “progress.

Good luck.

I have a simple test that tells you a lot about the culture of any organisation.  There are two questions you need answer:

1. If you are talking one on one in their office do managers generally answer the phone when it rings (thereby interrupting your conversation) or do they leave it for voicemail?
2. Do managers regularly choose to delay or stand-up multiple subordinates when summoned by their superordinates?

If your answers are interrrupt and stand-up then you have a management culture that believes that they are central to getting things done.  This is, of course, pretty bogus, selfish and arrogant.  If you have only one of interrrupt and stand-up then you have a warning sign.  Hopefully, things are trending away from the arrogant management culture.  Managers exist to enhance the performance of others - if they do their job then they become less necessary.

Today at work we decided to shelve a project. It was an update to an existing web content management system and was due to be released in a couple of weeks. Things appeared to be going okay until the project approached release. The project is pretty traditional (i.e. waterfall) and is/was in the “testing” phase. The development and testing environments have always been flakey (crappy architecture and people putting up with less than ideal situations) until about a week ago when they took a turn for the worse. Was it the code? Some problem with one of the servers? Nobody knows - the configuration control of the servers is out of hand - nobody can really work out what is going wrong. All up there was just too much risk floating around so we decided to bite the bullet and halt the project until we get the environments under control.
Lessons? I’ve got lessons:

1. If something smells bad for a long time then it probably is. I wish I’d dug deeper into the smell earlier and ignored the advice that things “will be okay” or that the problems aren’t linked and are just a long series of individual, unrelated minor mishaps.
2. If migrating between environments is done by manually repeating steps then stamp your feel and insist that it be automated. Don’t let the developers tell you that it has always been done that way and has always turned out alright.
3. Go back to lesson one - remember to follow your gut.

Its a pity that we got so far and so much effort has been (potentially) wasted. Its embarrasing for us all. Worse, after the news of the project being shelved was shared with the developers they asked for one more day since they were sure they were close to fixing the latest problems. Now they think I don’t trust or believe them. That’s not true - I just don’t think that we can continue to dig ourselves deeper.

P.S. I started working on a new contract last year - its almost the exact opposite of my last role - big, very traditional organisation. The opposite of agile and not very fashionable technology or development processes (not much, if any, source code control, waterfall style testing, no real unit tests, etc).  Email me if you want to know about why I left my last job. I don’t think I’ll be blogging about it - at least not for a few more months.

There were a couple of comments on my First make someone responsible… post that I’d like to highlight.

Ian from Financial Cryptography (a subject so complex I can barely spell it) chimed in with his usual wisdom to say:

…It’s a mess of contradictions - the job is mostly communications, but you need to be a technical expert otherwise the techies will snow you. The job is about compromise, negotiation and swallowing ones ego; but getting the technical skills required to face up to the people you are managing requires the reverse of that…

The ability to be able to smell obfuscation in nerds is something that most reasonably experienced managers develop. Being able to challenge, or better, work with a nerd to come up with an improved and acceptable (to the nerd) solution is something that can only come from people who have themselves been nerds. As Ian notes finding such people and keeping them in the middle is something that can be a challenge. Having a role model doing the same job somewhere else in the company helps.

Tarun from Musing of an Iconoclast added this:

…if you have a late or overbudget project then this is probably the only thing you can quickly change that will make a significant difference…

So true. Even if a process is being followed the absence of someone in the middle will probably bite you. As I said in the original post, adding someone is great experiment - showing whether or not the addition has helped.

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.