Software Craftsmanship – Letters from the Road No. 4

Assembling a Team of Effective Software Craftsmen

There’s a lot written about craftsmanship, but I haven’t come across much from a manager’s point of view. On the one hand, we all agree that deploying quality products rapidly is job one, which is what I mean by effectiveness. But the other hand is more controversial: what is software craftsmanship and, more salient to me, how in the world can one manage for craftsmanship?

The answers to the questions on both hands surely merit their own treatises. So let’s start with a smaller outset concern: how do you assemble a team of craftsmen from the ground up? Assuming you couldn’t hire a complete team of software engineers who obviously embrace craftsmanship ideals, here are a few indicia that I might look for:

A whole person who’s fun to talk to, work with, and generally hang out with. If we’re going to think of ourselves as working together in a workshop and we want our engineers to be communicating (a lot, right?) then we need to have engineers who are fundamentally good people, people who are easy to talk to about all kinds of things and open to changing their points of view on code and anything else. By this, I seriously don’t want the team to be a monoculture; I just want each member to be friendly and good-natured.

Dismiss this point as obvious or “soft” at your own risk. This species of human resource — if you want to express it in inhuman terms — is a seriously scarce resource in our economy of software engineers. Still too squishy for you? Would you agree that a big, unspoken, factor in team communication failures (and therefore, project or business failures) is that some people are exquisitely horrible talk to or work with? Sometimes it’s so bad that other engineers want to work from home all the time. Slack can’t fix an asshole no matter how clever the giphy.

Works (or wants to work) in small increments. These days I’m of the perspective that craftsmanship is not a “thing” so much as a state of mind manifesting itself in the team’s process of crafting code. So in building a team of craftsmen if I can, somehow, surface during an interview that an engineer is focused on building small, shippable increments then it might be evidence that he or she has the habits of a craftsman.

I’ve tried a few different approaches on this point in the past with mixed success. Maybe I’ve been more successful looking for the reverse — the engineer who wants to design everything and every corner case before writing any code, let alone shipping anything. This habit is easy to detect and very difficult to change.

Self-directed, fascinated by great code, and fully engaged. My ideal engineers aren’t waiting around for stories or tasks from a scrum master nor are they seeking to score political points by taking potshots at a befuddled product owner in a grooming session. They’re dedicated to making their mark on the product by actively engaging (and truly educating) product owners and/or bringing in a great new method, technology, or something cool they learned at a coderetreat (or meetup or whatever) last weekend. I know this means that my ideal engineer is putting a lot more than forty hours a week into the job as well as his or her career, but I’m just stating my ideals here.

I could have made this a laundry list with a million ticky tacky points but I think broad strokes are more effective with human “resources” than punch lists. Also, one thing you won’t ever find on my list is any kind of quantitative measure.

My objective for this  list is to help identify a team of software engineers who could grow into solid (or even great) craftsman who ship code. In summary, I think my list might capture the raw material if each individual on the team is (1) a great person to work with, (2) works in small increments, and (3) is self directed and fully engaged.

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *