Reactor vs. Anticipator

I noticed a pattern in my life that gets at one of my fundamental algorithms. I pounce on opportunities as they present themselves. I don't expend much effort on trying to stay a few steps ahead of the situation. I react when the situation demands it. This approach has its advantages. I spend most of my time working on things that have a good chance of turning out well. On the other side, my propensity to react rather than anticipating may come off as passive and uninterested. I need to force myself to take the initiative.

My wait and see approach is particularly irksome to somebody who has the opposite tendency. While I tend to watch things evolve and react accordingly, my wife is always working hard to stay one step ahead of the game. Her mind is always racing ahead to figure out what needs to happen next. She'll make preparations and then proceed. I will proceed and figure out how to make everything work later. 

This situation has the potential to create some serious misunderstandings. My time horizon is pretty short. Long term planning is not my bag. This can be very irksome when your spouse wants to know what's going on well in advance so she can anticipate and plan. She wants to be aware of something as soon as possible so she can plan around it. 

I may do things that are considered hasty in her estimation. She's usually flabbergasted when I confess that I haven't thought something through all the way before I take action. I prefer to improvise rather than plot and plan. Admittedly, this is not always the best way to go about things when you have a family and other responsibilities, but it's a big challenge to shift how you approach and think about the world.  

Release

I was struggling a bit during my run today. I was pushing it, trying to run my planned pace for a 10K that is three weeks away. I was trying to get a feel for where I am physically (and mentally). I was about 4 miles in when I reminded myself to just let go of the effort and the pushing and trying that I was doing and just surrender.

Rather than telling myself to hang tough or focusing on how far I've gone or trying to distract myself with music, I imagine myself drawing energy from the sun or the friction of the air against my skin. Freeing myself from the responsibility to keep pushing makes it easier to just plod along. When I did this today, I felt better after a few minutes and finished my run at race pace.

It's like just letting go while struggling with a complicated problem. Sometimes the best ideas come when you stop trying to force it. Trying harder can hurt your performance.

Do what it takes

I've been going over a clash that I had this morning for the last couple of hours. It wasn't a screaming and yelling kind of thing. It was much more subtle than that. It was the collision of two very different orientations towards learning in a corporate environment.

I stand for doing what needs to be done to make the project a success. I favor a proactive stance, picking a simple system that we can understand in minute detail and build further capabilities onto that knowledge. The first thing we make may not be a product that other parts of the organization feels is ready for the market, but this is our project. We should pick a system that we feel we can manage. We're not driving the project if we let somebody else tell us what we should do. The stakes are high. Why should we leave the success of our venture in the hands of another entity?

My standoff was against a colleague who seeks the path favored by our managers. His sole intention is to do what they think should be done in the manner that they feel it should be done. The answer to every question requires looking at the problem from the perspective of whoever has responsibility for this project at a more senior level. Any proposal must pass the muster of the manager's expectations. Possible objections are the end of the discussion. Nothing risky is allowed. Stick with what's safe and expected. Deviations are the quickest route to failure.

Every point that I raised today was refuted with some variation on the theme of "because the manager's said so." What if they're wrong? That was my point. Why should we go off and do something just because they said to do it that way? If we recognize a significant problem in the approach, isn't it our responsibility to raise those concerns? We're the ones in the thick of the problems. We're going to see trouble long before the managers will. They're relying on us to deliver a totally new capability. Part of delivering that capability is ensuring that we can perform every step of the process.