« All Episodes

Backlog Psychology - Practice Requires Rhythmic Predictability

Published 10/3/2023

In this episode we continue a little mini-series called "Backlog psychology."

How do you get better at anything? (Hopefully you said "practice" almost instinctively.) What does good practice look like?

Your team has an opportunity to practice every meeting and every day. But if your days look different from one to the next, how will you ever have the opportunity to actually do that practice?

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

Transcript (Generated by OpenAI Whisper)

today we continue our discussion on backlog psychology if you haven't listened to the last couple of episodes this is a series of episodes about various parts of psychology that might affect the way you think about work that is to be done work that is yet to be done and we talked a little bit about uh you know things like the zygarnik effect i recommend if you're interested in this topic if you enjoyed this episode to go back and listen to those previous ones they are not in any kind of uh any kind of order so you can go back and listen to them i believe we've had two so far and this is the third one in this episode we're going to talk specifically about something that most of us don't know about and that is the fact that we managers take for granted most managers take this for granted think about anything that you would like to get better at doing whether that's playing an instrument maybe speaking in public maybe you just want to get better at uh you know adhering to your your habits or pick something that is meaningful to you something that you want to do that you want to do that you want to do that you want to do something that you want to improve at. Now imagine the most basic advice that you could hear. Let's say if you're a child growing up and somebody is giving you advice on how to get better. If you imagine any kind of sport that you might want to take part in, how do you get better at that sport? Hopefully all of you who are listening fill in the blank with the advice to practice. To continue practicing. Practice over and over and over. Practice to the point where it almost feels grossly repetitive. You're so used to whatever this motion is, whatever this particular way of thinking is, and it starts to become such second nature. You've worked it in to your kind of muscle memory, if you will. Practice is something that we know is a critical part of improvement. It's a critical part of improvement in almost any task that we want to improve at. Which is why you almost universally would hear that advice. And so if we are supposed to practice, we could look at what practice tends to look like. Usually practices are structured very similarly from one to the next. You're likely to try to do the thing that you did before again. Incorporating the adaptations that your brain or your body has made since the last practice session. And you continue with this iteration process with minor adjustments. Now you might add something new, but overall practice is repetitive. You do very, very similar things from one week to the next, one practice session to the next. Now let me ask you a question. If you are a software engineering manager, if you're managing a backlog, if you're a scrum master, are you creating an environment where your team is able to practice? Think about this question for a second. Are you creating an environment where your team, is able to practice. What does this mean? It means that the environment is predictable, it's stable, it's repetitive enough, it is consistent enough. You're doing the same things over and over enough that your engineers, your ICs, your team is able to adapt, make small adaptations and get better over time. That doesn't mean that you never have an extra meeting, that you never have something that colors outside of those lines, something that keeps things a little bit dynamic, but overall your team is only going to be able to practice if your ceremonies, if your team's scheduling, if it looks similar to the last iteration. One week to the next looks very similar. So the easy way to evaluate this is to ask a couple of your team members in your next one-on-one or for your lead engineer, send a message to a team member and say, can I take a look at your calendar, at your work calendar? And can I look at the next couple of weeks on your calendar? Look at the last couple of weeks on your calendar. If you are establishing a practice, you should be able to do that. If you're doing a practice, you should be able to do that. You should see some consistency, some rhythmic consistency from one week to the next, or maybe every two weeks is your cadence. Whatever that cadence is, there should be rhythmic consistency to it. And here's the thing, what this is going to provide is a low overhead, a low cognitive overhead for preparing for and engaging in meetings. Meetings are not where you are going to see practice occurring. Meetings might be the venue for practice, but if you keep on holding ad hoc meetings, if you keep on calling random meetings and one-off, you know, on the day of, this is akin to telling your team that it's time to practice on a new court today. It's time to go down the street and practice in a different way than you did yesterday. And suddenly, without warning, it's time to practice right now. If your team is engaging in these meetings, this is the venue, this is the kind of format that you might want for practice. But if it's not predictable, then they have to prepare all of a sudden for this new thing. The cognitive overhead does not allow them to get into any kind of flow state. It doesn't allow them to move past the pretense of the meeting. It doesn't allow them to move past the pretense of the meeting. It doesn't allow them to move past the pretense of the meeting. And instead of practice, all they're doing is preparing. All they're doing is figuring out what do I need to do for this next meeting that I'm about to be a part of. That's not a valuable output from a team. Focus on consistency with your team and allow them to get into a rhythm. Try to avoid calling one-off meetings and instead focus on bringing as much as you can into a rhythm. If you're not able to do that, then you're not going to be able to do that. into your recurring rhythmic meetings. Thanks so much for listening to today's episode of Developer Tea. I hope this was an enjoyable, insightful episode of the show in this series about backlog psychology. Hopefully this hits home for some of you. If you are an engineer, I encourage you, if you have some kind of influence over your meeting structure or over your own calendar, try to implement this. Try to create some kind of rhythmic structure to your weeks, to your days. I can almost guarantee that you're going to improve at a much faster rate if you do it this way. Thanks so much for listening. If you enjoyed this episode, please join our Developer Tea Discord community. Head over to developertea.com slash discord. And until next time, enjoy your tea.