The Five Qualities of a Successful Practice

I recently changed roles with my company: No longer am I a day-to-day consultant, working down the stories in the backlog for a customer, but instead have moved into practice leadership. Naturally, I’d like the practice to become as successful as possible, but quickly discovered that “success” is an ambiguous definition, and that I’d be learning quite a bit about what makes a practice successful as I try to build this.

We’ve all seen or heard of the stories that say what a good engineering practice is not. It’s most often framed as a “training program” where the corporate messaging is “here’s your internal corporate training website, feel free to ask your manager to take a course” but no one does because managers don’t know what it means to sign off on the requests and even if they did the site is written in flash and doesn’t work on anything but IE6, and even if an engineer can get around that the most relevant course was written five years ago and is fundamentally dependent on something called an XML file.

So we can recognize a bad practice from a mile away. But what makes a good practice? I’d like to start by not saying what a good practice is, but what a good practice has, and address the causality at a later point.

1. A Culture Around Experimentation* and Learning

In short, this is about having practitioners who want to improve. And to encourage their teammates to improve. And reward their teammates who are improving. And collaborate with their teammates when there is learning to be done.

This motivation is internal, yet positively enforced by the team itself. “The stick” is not a great motivational tool in a practice that has a good learning culture. Force me to take a class, and I’ll do the bare minimum to pass it then forget everything I learned as quickly as I can. Obscure 80s movie references take up a lot of space in my head, and I don’t like giving that up. But a “carrot” — the opportunity to engage with like-minded engineers on novel solutions — well, that might be worthy of ejecting some Ice Pirates trivia.

2. A Place to Conduct Experiments

A (paraphrased) quote I’ve loved for years is “If you don’t give your developers a place to play, they’ll use their production environments to experiment.”

We’ve all seen it happen — an engineer is interested in technology X, so they write a new module in X and manages to get it to production — then moves on to technology Y for the next module. Lather, rinse, and repeat. You end up with an alphabet soup of technologies, none of which had a great plan for operations or monitoring or high availability or reliability and it becomes a steaming dung pile that requires extensive handholding until someone suggests a perl script full of regex to solve some of the handholding and everyone goes home and updates their LinkedIn profile.

Developers need compute resources and platforms where they can experiment. And these need to be easy to access and also to have some semblance of permanence — no one wants to have to bootstrap a Kafka instance if they just want to play with a reliability annotation.

3. The Time to Conduct Experiments

We all know how it is. We just got done with eight tough hours of (remote) pairing and our brain is completely empty. We’ve been ignoring the other humans in our homes and should really go spend some time with them, and maybe have a nice meal together. The absolute last thing on our minds is firing up the computer after dinner and trying to figure out how Spring Security and the SSO tile work well together with some obscure federated provider. And besides, Bridgerton isn’t going to watch itself.

Even if we have the culture aspect knocked out of the park, engineers still need to have time dedicated to level up, and still maintain a healthy work-life balance. There has to be a commitment from practice leadership to create that time, whether on a few-hours-per-week basis or through extended time between assignments.

4. A Place to Share Results of Learning

If a tree falls in the forest, does it make a sound? If an engineer creates a novel solution and doesn’t tell anyone about it, does that solution exist?

It is imperative that any learning should be shared with the greater team, and that learning is celebrated. Practice leadership needs to not only create a space where engineers can talk about what they’ve discovered, but also remove barriers to that space. That space can be an active, searchable blog, or a podcast channel, or working with user groups to provide opportunities for speaking.

5. A Strong Mentoring Presence

Somebody has to be steering this ship. If a practitioner comes up with “Hey, this huge data set for customer X should yield some intelligence. I’m thinking of some ML time to get going on this” then that makes a lot of sense and we should pair that practitioner with an ML expert to see where the fruit is. If someone else comes up with “My customer Y is using Spring Boot everywhere in prod and achieving success, but I think there’s a lot of room for RPC and PASCAL” then maybe we should have a chat.

The idea isn’t that mentors would be gatekeepers and approvers for experiments. If someone has to get approval to experiment, they won’t bother (or even worse, go cowboy in a customer’s code base). But if a mentor can help get to the root of the desired learning, then we can create experiments and find interested pairs that can pay good dividends.

Conclusion and Next Steps

Great banjo players have overalls. I own a pair of overalls but I don’t think anyone would confuse me with Bela Fleck. A successful practice will have these five qualities, but simply having these qualities may not make a successful practice.

The next steps for this are to find some way of quantitatively measuring progress against these. I’m certainly open for any kind of feedback on this. Some of it can be really difficult: how can you quantitatively measure a culture? But knowing where we are and tracking against these KRs gets us closer to having these qualities and hopefully having a successful practice.

I’m going to continue to blog on this, initially at a weekly-ish cadence, for a few of reasons: a) to (selfishly) improve my writing skills and 2) to share results with the team, giving iii) a place for practitioners to engage with feedback.

* I will use the word “experiment” often in this post, because it is an important concept. Practitioners want to try things out, with a general hypothesis in mind and a set of expected results, controlling for variables outside the scope of the experiment.