Behind "Talking to Executives"

Some backstory for story three.  After trying to set up the context for "Talking to Executives", I've gone a bit too deep into the justification of why - without actually saying much interesting at all.

When I was at university I did the software engineering program.  It was a cool program because it taught me how to organize my work into a bigger picture and then break down the big job into smaller achievable chunks.  It added all sorts of other goodies like appropriate human-computer interface design, testing throughout the development process, and how to write documentation that average people could understand.  I did very well.  Originally I started in the hardware program, microchip design and asynchronous circuits, but after a year I realized there was no way I would ever get a job here in Calgary in this field.  To get our chips made we had to send our designs off to Edmonton, a city five hours drive north of here.

 It’s strange in hindsight changing from something I loved to something that would provide a better career.  I loved building physical things.  When I was in senior high school I won a national science competition building a robot.  I cobbled it together from TTL chips from a local electronics store, some toy car variable speed motors, and some old fashioned keyboard keys for pressure sensors.  The thing would roam about a room until it hit an obstacle and then change course.  The cool thing is that it had a basic memory and logic to remember where it had been to pick a new route to get unblocked.  It could figure its way out of simple mazes.  It never occurred to me to attach a dust-buster and make millions of dollars as a household aid.

But my love of building complicated hardware did translate into software.  It also started to translate into the real world.  Organizations are big complex things with swarms of moving parts.  Software is the end of the journey, not the beginning.  A company needs to figure out its business processes first in order to build functional system requirements.  Though many of my classmates didn’t care about end users, I felt that to build better solutions I needed to have their knowledge.  I couldn’t do that without building relationships.  And I was a specialist in building software, like the client was an expert in their business.  There needed to be some way we could all play nicely together so that I could enable them, b building things they actually wanted.

A well-defined business process leads to a well-defined software solution.   Effectiveness comes from seeing how well the solution maps to the process.  Efficiency comes from how aligned, integrated and streamlined they are.  To get maturity, processes need to be repeatable.  That means you need to have consistent guidance on how to do things, and people need to cooperate to follow the guidance.  Most important; people need to communicate.  And so I was introduced to continuous improvement philosophies and performance excellence. 

It doesn’t matter at all if the environment in which these things exist isn’t nurturing or condusive to success.  Sure as a skyscraper needs blueprints and is built from the bottom up, a ship needs a captain and is led from the top down.