Overpromising
Hey!
Welcome back to another week of musings. I hope you had an uneventful weekend and managed to rest!
I did some rest, and we spend the weekend playing with our adopted senior dog.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
Software architecture decisions: who should be involved? This is a Q&A with Andrew Harmel-Law, who published a book (which I recommend reading).
I've been very interested in developer productivity recently, and I saw this episode of The Pragmatic Engineering with Dr Nicole Forsgren (of DORA and SPACE).
I've been working long enough to have failed others by overpromising. While we might know that overpromising can be dangerous, it's easy to fall into the trap.
Between meetings, crafting documents, and creating POCs, it feels as if you're slowly chipping away at the projects. In other cases, some initiatives might be long-term, and it's hard to notice that you're not progressing toward the goal. Whenever I catch myself overpromising, saying yes to too many things, or seeing people asking me for updates "more regularly" than expected, I take a step and assess where I stand regarding deliverables and projects.
Sometimes, there's too much work
I know "logically" that I shouldn't be overpromising, but sometimes, there's that much work that I'm supposed to be looking at.
Calendar management can only do so much if tasks are more significant than the work week. In those cases, delegating more is possibly the only option. Other times, letting go is the only option. Create tickets in Jira and let another team handle the issue later.
Understand where you're standing
Once I realize I'm overpromising, I need to figure out where I am and, hopefully, how I got here.
I've asked some peers how they manage their tasks and priorities, and some categorize their roles in each of the projects they participate. Categorizing makes it easier to understand where to focus more vs less time during a given week. Some of the frameworks I've heard about are the Amazon Principal Engineer Roles Framework, RASCI/RACI, and the Eisenhower Matrix. The main point of these frameworks is to help us understand the role we should be playing depending on the projects we're working on.
Singular Goal
After categorizing my work into buckets, it's time to come around the hard choices. What's the most important task? If there's a singular impactful thing to be done, which one is it? All the other functions might need to find new owners or wait until we're ready to pick them up. These are the choices and discussions we need to have with our leadership.
What I'm doing here?
After choosing my most important goal, I look through the rest of things, but I also ask myself how I ended up in this state.
Sometimes, we get assigned to it because it's in our ownership domain. Other times, we might be required to determine why it's delayed or blocked. Some of my tasks also boil down to implicit expectations. I'm asked to participate in one or two meetings, and without clear ownership of tasks, there's some assumption that I'll take it from there or fix it. In practice, I talk with engineering managers or program/project managers and clarify expectations, what I have done, what I will deliver for the project, and where they can take it over.
I tend to be very hard on myself because, in some cases, it's hard to let go of tasks that might be in my ownership or expertise. So, this is a reminder to give yourself grace! We're not perfect, and we occasionally fall into these traps; it's better to recognize them and correct them than to ignore them and burn out.
Your turn!
Have you ever overpromised your tasks? Or do you tend to be tired from all the tasks you're asked to do? It might be time to assess if you're trying to do too much! Let me know your thoughts by replying to this email.
Happy coding!
website | twitter | github | linkedin | mastodon | among others