Staying Current on Technology for your Organization

As a Technical Professional, your company, firm, group or organization looks to you for guidance on their technical systems. You're expected to apply the best technology solutions that you can to a given business or science problem or opportunity.

That can be quite difficult to do. If you are in a vertical knowledge role, expected to know a lot about a given technology, you have fairly clear boundaries on keeping current with your area. My approach when I'm in a role such as developer, database administrator or systems administrator is to leverage these sources:

When I'm in a role that is more breadth-oriented, such as I am now, I'm expected to know several technology stacks, not just one in depth. This is common in Architect roles, lead developers, researchers and analysts. And it's also true in "The Cloud", specifically Windows Azure for me in my current Worldwide Role here at Microsoft. Since Windows Azure is a platform that contains everything from IaaS (VM's, Storage and more) to PaaS (including Open-Source languages and Platforms) and even a kind of SaaS (such as Web Sites and Hadoop or HDInsight) it can be difficult to stay up to date.

So in addition to the resources listed above - meaning that those things are assumed, I have two primary approaches: Feature/Function, and Problem/Solution (or Opportunity/Solution if you prefer).


In this approach (again, assuming that I've used all the resources listed above first) I evaluate all of the components within a platform or system to discover:

  1. What they do
  2. What I know about that
  3. What I do not know about that

For instance, I use the Windows Azure Portal screen to simply walk through every single click, and then I create a OneNote ontology answering those three questions. From there I research until I have references and an understanding of what the feature does and where it can be used.

With that knowledge laid out, I then locate a source that keeps me up to date on the changes for that platform, and then I evaluate that source when it is released, adding to the OneNote notebook. For instance, for Windows Azure, I use this source:


While you can evaluate a system by a component approach - and I usually do - it's often helpful to discuss where a platform can be used to solve a business or organization problem, or if you want to flip that around, present an opportunity. It's really the same thing, but does color the way you approach the material. For instance, the first two responses are problem-focused and the others are opportunity focused.

Problem: Glass contains 50% water

  • Optimist restatement: Glass half-full
  • Pessimist restatement: Glass half-empty
  • Engineering restatement: Glass designed improperly - I'll architect a smaller glass
  • Opportunist: I'll just drink the water while you guys sort this out

And of course the chemist thinks there is no problem at all - the glass is completely full (50% H2O with 50% Oxygen and other trace gasses). In any case, instead of focusing on the platform or system, I'll focus on where I might use it - the problem or opportunity. I'll lay out a matrix with decision points that are important to the organization and then lay in various options, applying them to those criteria. Whichever solution meets the criteria is the one I'll dive into in more detail.

It's important to note that other than perhaps the Spork, there are very few tools that are perfect for their opportunity. There are always tradeoffs, and some of those are not necessarily technical. In an architectural role there are sustainability and practicality aspects, as well as budgetary and political aspects.