The CRY Principle

Most software engineering managers (including myself) start as software engineers themselves. Being technical means they can always jump back into work or better understand a plan devised by someone on the team, both of which I do routinely. However, managers need to learn when it makes sense to continue applying some of the same techniques that got them here and when they need to change their strategy for the changing kinds of work they handle.

One such technique is the DRY principle:

DRY—Don’t Repeat Yourself

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This sage advice comes from my favorite book on programming: The Pragmatic Programmer by David Thomas and Andrew Hunt (you should definitely pick up a copy). There's more to it than the above, but most engineers hear this and take it to heart and their area of responsibility is all the better for it. Then they apply it to documentation, and the people around them know they can trust that the single source that they find is at least mostly correct and won't conflict with a secondary source. But then, they internalize that they don't need to repeat themselves to others and that's where things go wrong.

As a manager, you'll have a team of people listening to you and your direction. Your job is delivering clarity. However, those people who are supposed to be listening may have missed it because they were checking Slack. Maybe they were sick. Maybe their doorbell rang. Whatever. The thing is, they missed what you said and if you don't plan on repeating yourself, they may not hear that really important thing you just said. Find another time and, even better, another medium to repeat the message. Said it in a team meeting? Send a Slack message later repeating everything. Sent an email about it? Follow up in all of your 1:1s and mention it there. My team has heard me say the words "sorry if I've already told you this before" dozens of times, but I'll keep saying them and repeating as necessary.

This isn't just a management technique—this is a good skill to practice as a crafter too. I'm always recommending to my reports that they share what they learn and what they build. For my team that means recording demos or writing blog posts and sharing them on Slack or our corporate intranet. But don't share it just once, share it multiple times in different channels and on different days. Give the message time to breathe and spread things out somewhat organically. Not everyone has time on Tuesday, but maybe they do on Wednesday or Friday.

The overall advice here is to use DRY when it makes sense: writing code and creating a consistent, cohesive message. But once you have that message ready, repeat yourself until the message is clearly heard (usually three times, in my experience).