Problems or Opportunities? Where should you focus your effort?

One of the smartest things I did as Interim VP of Engineering for Padcom was let Don talk himself into coming to play with us over the course of several hours overlooking the Puget Sound one weekend morning. Padcom was a small tech company with some unique internetworking technology in the process of building-out into the bigger-time. The unique IP was in software but one of the challenges was shipping a next generation ruggedized client as a delivery vehicle to access markets in public safety.

My thoughts about the book … If you don’t have the book, get it. If you have the book and haven’t read it, do so now.

“Why doesn’t my manager listen when I explain the details?”
“Why doesn’t the developer just give me what I ask for?”
These questions popped out during the Tutorial at this year’s AYE Conference. Realizing the energy, Steve and I held an impromptu discussion on the topic.

Re-reading my blog titles occasionally leads to interesting thoughts. Many titles mention change, and most entries have something to do with change. But after all these entries no one has asked me, “Don, what do you mean ‘change’?”. Until recently, I haven’t asked me either.

Engineers make the darndest assumptions. I made one such assumption in “Change and Stable Systems”. The unstated assumption involved starting with a stable system. But what do you do if your system (as in team, project, company) is unstable?

Today I had the opportunity to remember that “context is everything”. Hurricane Frances continues her slow crawl up the eastern United States. It started raining here in North Carolina yesterday (Tuesday 2004.09.07). This morning my radio crackled with reports of accidents and emergencies. Fortunately, none were in our response area. Then the pager tones sounded. “Squad 86 respond with the local VFD to a one car roll over. One adult and two children confirmed entrapped.” I arrived just before the rescue truck. The SUV lay

In Changing Quicker we looked at reducing or removing system delays to reduce the time delay between realizing a change needs to be made, and when the change’s effects occur. Another way to change quicker involves learning to change. Learning is a process that depends on experience and leads to long term changes in behavior potential.

Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change?

Several years ago I found out that I was not really in charge of everything, or in control of very much. This lead me to

Don’s Dismal Dilemma: How will I achieve my goals, when I’m not in charge or control?