I had a new member of my team join recently and, when I met with them one-on-one for the first time, they complimented me on my standup updates. My team works remotely so standups are an important touchpoint. My colleague and I talked a bit more about what made my updates helpful and I realized that I’ve never actually written a public blog post about this.

This is that post.

The idea is called radiating intent and it’s guided how I show up and communicating professionally for nearly a decade. (I don’t remember where I heard this from initially.)

Here’s how it works: I keep the people I work appropriately aware of what I’m about to do. If they have feedback, concerns, or suggestions, I make sure they know that I do want to hear from them. But I’m not waiting to hear from them; I’m going to take action by default.

Radiating my intent has a few key benefits for me and my team:

It’s not a complex idea. “Keep those around you appropriately aware of your next move.” But the word “appropriately” is key: too much detail and I become a distraction, too little detail and I become a lose cannon. And it really is my immediate next steps, not something I’m planning way in the future.

I try to think about who I’m talking with and what they need to know to give me valuable feedback.

It’s also a cue for me to figure out what I think I should be doing, rather than relying on others to tell me. Now, you might say “that’s all well and good for a staff developer who gets a lot of autonomy, but it won’t work for junior developers.” And I disagree: I think that having a sense for what you should be doing next at any given time is a valuable skill at any career level. Radiating intent helps you hone that skill. And it shows initiative, which is especially distinguishing for junior developers.

Here are some counterexamples and what I would do instead:

“What ticket should I work on next?” -> “I plan to work on this ticket next. Let me know if anyone has something else they need.”

Even at the ticket level, when you find your own next work item on your own it shows initiative. Maybe you get it wrong, but then you get to learn from that. Most managers would rather correct you on this than try to find you a ticket. The extra bit at the end (“let me know if…”) is a hedge in case you made the wrong call. As your experience and responsibility grows, you can use these kinds of hedges less and less.

“Do you think we should find help with this project? We’re at risk of missing the deadline.” -> “We’re at risk of missing our deadline so I’ll be asking Andre this afternoon if he has spare time to help.”

Not only are you making a call here, but you’re being specific with your solution. It’s a bit more senior-level of a call, but this kind of thing happens all the time when building software.

“Next week has a holiday, should we get on-call coverage?” -> “Next week has a holiday and I think we need on-call coverage. I’ll let the exec team know that we plan to cover it, and I’ll make sure whoever volunteers knows our lieu-time policy.”

People-based decisions like this can be tricky. Maybe this wasn’t the right move! Maybe no one needs to be on-call during a holiday! You team can tell you. Or, the exec team will since you’ll be radiating intent to them, too.

Radiating intent works well in small startups and large companies. I know because I’ve used it in both settings.

I’ve heard the expression that “it’s better to beg forgiveness than ask permission” too often in my career. And I get it. No one wants to get stuck waiting on someone else’s approval, we’d rather move quickly based on our own convictions. But if we keep secrets then we risk misaligning our work with the rest of the company. We risk duplicating work that someone else is already doing, closing ourselves off from feedback that could improve our work, or wasting time on low-priority tasks when something more urgent needs to be done.

Begging forgiveness sucks. So does asking for permission. I ask for nothing, but I always remain open to suggestions.