Capability and Motivation

Sure, I could do it, but why bother?

Every so often we hear stories of genius children. A levels at 3, IQ off the scale, mastered 7 languages before they were potty trained. You’ve seen those stories. But when I was a kid, the story that struck with me was about what happened when they grew up.

One guy in particular had won various competitions and was very smart, and he could do whatever he wanted. Once he grew up, he ran his own bakery. There was a suggestion in the article of how dare he waste his talent like that, as if the job wasn’t worthy, even though he was doing what he wanted.

He was capable of solving big problems, apparently. But having an aptitude for a particular set of skills isn’t enough. If you’re not motivated, you won’t be capable of achieving. Just because you wrote the last set of requirements, or you did that reporting training course doesn’t mean that’s what you want to do for the next 5 years. It’s not just an interview question. If what you’re doing now doesn’t get you to where you want to be in 5 years, you aren’t going to be at your best, unless your leader can contextualise it into your longer term goals.

As a leader, it’s not enough to know who has the skills or the aptitude. Foster motivation and Joy.

A checklist is the first step to automation

↑ ↑ ↓ ↓ ← → ← → B A

My first big responsibility at my current job was to package a release and deploy it to the customer. Back in those days (2007), that involved creating a set of installers (server, desktop and tablet client – Windows XP tablet), burning them to a CD then driving to the client site on the day all the mobile workers returned to base for their monthly meeting, and installing into all the machines.

I remember my dad telling me how he taught others. Let them sit at the machine. Let them take notes. And be patient.

There weren’t many notes to work from at the time, and I wanted to be confident I could do it myself next time, so I wrote the steps down as a series of checklists, one for QA and build, one for media prep and one each for installing onto each target device.

And I noticed something. As soon as it was written down, I started to see where things were duplicated or could be automated. Within a couple of releases, I’d got the checklist down from 5 sides of A4 to 2. I probably could have done more, but 1 sheet felt right, and that project was coming to a close.

I thought every project had a way to visualise their release process, it sounded obvious. It wasn’t always the case, as I discovered when I started working on legacy projects with ad-hoc procedures and distributed troubleshooting guides, a SQL script here, a helpdesk ticket there, or an appendix in the technical architecture. It seemed crazy to me. You’re dealing with a legacy system, with a complex deployment process, or build process, scattered throughout various machines, and various people’s heads. It’s error prone and you want to improve it.

The first step to improvement is understanding, and the first step to understanding is to visualise it. If you don’t know what you’re doing, make it visible.

Bootstrapping new developers

Start of a new day

When things are tough, do them often, to get more practice, as Sky Betting discuss in their recent blog post. It’s certainly something that I’ve noticed as we’ve moved to more regular releases, more regular planning and reducing feedback cycles.

One big thing I’m still learning how to do, where that doesn’t apply, is adding new developers to a team. I’ve been thinking about this after hearing The Improv Effect talk about onboarding to a company on .Net Rocks 1253 : Onboarding is Culture with Jessie Shternshus

My usual approach doesn’t apply, because good teams are stable, so onboarding is rare, which makes it harder to know how to bring new people on to the team. I always try to write a short introduction, on a wiki, to introduce the project and list the useful urls, and the getting started steps, and I ask new developers to update it with any differences they find, to keep it up to date.

Most of the team knowledge doesn’t come from there. It comes from the rest of the team. So the team needs to be built so that the onboardee collaborates with other members of the team from day one. Getting involved in code reviews, asking questions. I’m sometimes tempted to give as little information as possible to encourage asking questions, but that’s not how psychology works, and I’ve had more than a few gotcha moments where someone who’s been on the team for a while says “I didn’t know that was there” or “oh, so that’s why we do it that way”, and I have to revisit the onboarding story again, and wait for the next chance to validate it.

So, assuming your company has a good story for onboarding employees, how to you take a fresh start, or a start from another project, and build them into your team?

DDD Scotland 2016

The DDD Scotland 2016 conference CFP is open, so if you’ve ever wanted to present at a conference, now’s your chance. This is the first conference I presented at, and it’s a friendly, community conference. I notice there’s a Code of Conduct this year, which is a great sign, as other conferences have unfortunately found that some people need to be told not to be dicks. I’ve never seen any problems at DDD, but that’s another thing to help persuade you if you’re nervous about attending.

All talks are voted on so the content will be things people definitely want to see, and most topics and languages have been covered one way or another, so long as you can convince developers it’s interesting.

I’ve got a couple of talks I’m thinking about submitting, pulling threads I’ve been blogging about last year, but if there’s anything you want to hear more about from my posts, let me know and I’ll see what I can do about getting a talk written. I’m also thinking about topics for open conversation sessions.

Now, go submit, and I’ll see you there.