I am a little under the weather this weekend. That means spending lots of time pointing my sinus-irritated face at my shiny new 32 inch Samsung 4k monitor and watching Netflix instead of writing code or web content. Yes, that is an Amazon Affiliate Link. Click on it. Buy it. Love it.
At any rate, I want to talk about decision making.
I helped a friend of mine build an application that he uses to help make decisions. Users add deadlines, priorities, and a variety of other category tags for things they need to get done, and the app reduces that to a number in order to prioritize them. I was hoping to get him to be a guest writer for a week, and it does not look like it is going to happen in the near term. In the process of developing the application, he introduced me to the concept of the Eisenhower Box as the basis for his “get stuff done” formula.
Rather than provide a detailed definition or explanation, I am going to just include this pretty picture of what the Eisenhower Box is.
I am not paid by the word here, so I am not going to include a page of explanation for each of these—Google is your friend!
I decided this would be a nice, lightweight post because I found myself spending a little bit of time explaining “urgent” to a few people in the past few months.
I also want to call out the “Not-important not-urgent” quadrant. Engineers have a genuine tendency to wrap themselves around an axle here. It is easy to have an idea that sounds really good and to decide to spend cycles on it because it is new and fresh in your mind. There have been moments in my career where I have been guilty of this, and later was asked by an executive “Why did you spend time on this?” “It was shiny” is not a very good answer. Delete might sound a little extreme as an outcome, but it is probably the right thing to do. If people fixate on something that is not important and not urgent, and refuse to accept that it should be deleted, then you should concede the point and put it on a backlog—probably somewhere near the bottom. It is a good idea to keep a catalog of ideas and their relative priority. It is also good because it lets additional stakeholders look at the ideas on their merit and reinforce the business priorities.
Engineering teams occasionally put urgent technical items that are hard for stakeholders to understand into the backlog. One of the important jobs of engineering leadership is making sure that those tasks get addressed in a timely manner. This can be accomplished by asserting a window of time that this work ought to be done, or by negotiating with stakeholders by discussing the risks associated with the work being discussed. This is important because if a stakeholder decides that it is “Not Important” then it should be deleted. If this is erroneous, then it is important to educate them about why they need to upgrade it to “Important”, or else assert that it simply needs to be done.
As a final thought, be sure to invest the time in educating stakeholders as much as possible about items that are “Important” on the backlog. You will burn goodwill by asserting engineering leadership privilege and doing something that is important to your team. I would recommend keeping the frequency of these events to two a year at most, even if it means clumping together a few unrelated technical tasks.
Thank you again for reading along, and sorry for being a bit brief this week. I am not well. I hope my sinuses are back to normal again next week so I can be appropriately angry at things instead of feeling sorry for myself.
