Be Intentional

My old manager used to always say, “Be intentional.”  It took me a long time to comprehend exactly what he meant by this, but eventually I did and have come to appreciate the advice.  What he meant was to always make active, conscious decisions rather than just letting things happen.  It also means to verify things rather than assuming they are a certain way.  For example, if you don’t have enough time to do everything on your plate, think carefully about which items will not get done rather than just working on items in no particular order.  It should be your intent which specific items go undone.

This is a good principle to act by.  All too often people think about what they *are* doing but don’t consider what they *are not* doing.  It is just as important to be conscious about what you are not doing as it is to be aware of what you are.  If you don’t actively choose that which is not done, it is likely that the wrong things will drop off your plate.  It is easy to be busy working on something that is important to the detriment of something that is really important.  It is best to make all decisions, both positive and negative, conscious ones.  I’ll often ask my team when something goes undone whether that was intentional or not.  If there is only time to do 3 items and there are 4 that should be done, I’m fine with the 4th being dropped.  It is a poor manager who is upset when the impossible isn’t accomplished.  I do, however, hold my team accountable for that 4th item being something they intend to not get done rather than whatever just happened to be left at the end of the day.

I’ve seen this come up in testing features.  I recall a time when a report of mine was testing a particular feature with two aspects to it.  For good reasons he started working on the first part, a complex parser for device attributes.  Being complex, this took a long time to thoroughly test.  In fact, it was taking long enough that he was not going to be able to get to the second aspect of the feature at all.  I inquired whether this was really the right approach.  Did he think it was better to thoroughly test the parser and test the other part none or would it be better to test the parser to some level, then test the other aspect, and finally return (in the future) to cover the less important parts of the parser.  Upon reflection he decided it was a better idea to cover both to some extent than one fully and the other none.  The trouble here is that he wasn’t acting intentionally.  The test plan called for testing both aspects thoroughly.  The plan didn’t call for ignoring the second part.  It was just because of the unexpected difficulty of testing the parser that the second was going to be missed.  He needed to step back, re-evaluate, and decide intentionally rather than just letting events dictate what was going to be dropped.

This principle is also good to apply when dealing with other people.  Instead of just assuming that the other party will do the right thing, being intentional means specifically outlining expectations of them.  It is easy to think you’ve told someone what to do without them realizing that you did.  Being intentional means verifying that your assumptions were communicated and following up later.  It means being explicit when handing work to another person.  Make sure they understand that it is your expectation that they now have the action item before you clear it from your to-do list.