Faster to Market is not always the best policy -not what you think

Received a humorous, but truthful, comment on yesterday’s post.  A colleague of mine pointed out my poor grammar: “Brian I love this! Can I be your blog final editor though before you post these – the grammar errors are killing me 🙂.”  The comical excuse is that “I’m an architect or engineer, not a lit. major….”  or the neurological excuse: Asperger’s Syndrome.  –No, I haven’t been officially diagnosed, but those crazy online quizzes suggest I should.  Other’s chalk it up to calling me, whatever reason, a typical scatterbrain genius. Yes I’ve got a high IQ, but that nor any of the other explanations are valid excuses for not trying to improve.     

However, the plain fact of the matter is I’m always 100 miles ahead in my mind to what I’m writing down. Two of my mentors at Microsoft once commented separately: “Brian, you’re going to have a difficult time here in that you can go from A to Z in seconds in your head while others are having trouble just getting to B on paper”.  This causes me to skip words, sentences, and even whole paragraphs.  This post is an example I’ve had to go back several time to ensure I haven’t skipped something, etc.  Those that follow my word may already notice the long, well extremely long sentences….well punctuation are just friendly suggestions like road signs right 😉  The results of which is a reliance on proofing software which doesn’t always catch everything or an editor. 

As such I’m often in too much of a hurry to get my ideas down before these vanish from my current thoughts then push it out there. [Faster is not always better]  

What I’ve been doing about such 

A few years back I rejoined Microsoft’s MCS organization in an interesting role “IP Development Architect”.  The mission for such was basically empty my head of experience on various EA topics, develop approaches for the field to use to help our clients**. Basically as one of my mentor’s called it “being a brain on a stick for sale, lease, or rent”  

I took that role as a challenge to improve my writing and presentation skills; similar to the reason I took a role at IBM to learn marketing, sales, and become more outgoing (I’m an extreme introvert though you’d never know it).  During the years that followed I’ve been fortunate enough to have friends and colleagues point me to resources to help, as well as technical and grammatical editors to patch up my mistakes.

During that time I started investing in books (e.g., Peter Ingle’s Organized Writing Course, Nancy Duarte’s and Martin Sykes/Nick Malik’s books on presentations, etc.) that have taught me to put together great structure to my writings and presentations.  I actually get people asking me to do such for them or critique their work(specifically not grammar); which I’ve gladly done for many.  So I guess I’ve overcome some portion of my communication gap. 

This next twelve months with the help of my colleague, yes I’ll gladly take you up on your offer, I’ll work on the grammar portion of my writing.   

             

 ** I say clients rather than customers because I’ve always believed the company should establish long term relationships rather than transactional sales. Given the company’s strategy pivot to cloud services, I hope they are successful adopting such a philosophy.  The consequences of not doing so will be a loss of renewals in a future that depends upon good service and strong relationships.      

Enterprise Portfolio Management

Updated the CMM and Capabilities Roadmap yesterday still have a few more items to add.  The roadmap is slowly coming into shape.  Hope to have presentation and tools ready by February conference

Like the original CMM this version for Portfolio Management has 5 levels.  Taking a page from the CMMI work I did in the Marketing Domain for IBM/Samsung, et al. It will contain an assessment tool to help enterprises do it themselves.

I’ve been developing a CMMI for Enterprises Architecture similar to the Software CMMI.  Enterprise Portfolio Management will be the first subsection of the EA CMMI which will be part of the Structure in Threes book in works. 

Structure in Threes: Positioning and Lessons not Learned

Had great discussion last night at Starbucks on Mercer Island with some former Microsoft Alumni.   One is at a Microsoft competitor now working at developing a competitive service to our mutual former employer’s.  The change in strategy at Microsoft has yielded a large shift in the Architecture domain enabling competitors to move in and eventually succeed.  My colleagues and I rather than sit around the table discussing what could have been are busy creating the future; spending several hours mapping out the landscape and what pieces need to be build or remodeled.  Sounds like Enterprise Architects at work.  However, unlike the paper mill approach that was being pushed we’ve been taking a more engineering design approach looking at how the methodologies we’ve each been developing yield implementable designs specific to client’s needs using modular componentry.

Discipline Maturity Lifecycle

I was wondering how much longer it would be before Enterprise Architecture would reach the next stage in its’ maturity.  I’ve been watching TOGAF, ZACHMAN, COBIT, ITIL, etc. for the past several years ideate and mature into a robust collection of heuristics waiting for the day these take the next step towards modularity. last night’s discussion inferred the time was rapidly approaching, both my colleagues began discussing their specific domains in context of creating a reusable component based approach.  That is to say having a set of design rules as to how to choose what components from a library or catalog of components to achieve design goals.  I was really pleased with the direction the discussion was talking.  Had I had my copy of Jon Lang’s Creating Architectural Theory –I leant it out to another peer at Microsoft this past month– I would have pointed out we’re finally making some progress.  However, that most likely would have confirmed in their eyes I was an academic (odd considering I spend more of my time building tools and applying these concepts than doing primary research in the area).

At different times during the conversation I was frantically searching for documents on my Windows Phone to point out some of the pieces I’ve already built or are in the process of building.  Unfortunately, this is where the promise doesn’t measure up to reality.  I could not get to my Office365 Small Business Online site or SkyDrive (it couldn’t recognize ANY or the Userids I entered).  Microsoft has a lot of work to do to get Services right before they can compete effectively with Amazon, Google, and Apple.  Sure individual components run, however, when combined in a system which is where the Services business is, they’re having challenges.  This systems approach is still elusive to the culture at Microsoft.  

We parted with a plan for a plan which could either mean this will result in just an nice academic discussion or that we will really start assembling a next generation of Architectural practice that will take one step closer to a engineering-like discipline rather than a artist colony debating about aesthetics of design.  In either event the discussion confirmed to me I am on the right track with ‘Structure in Threes” and creating the design methodology that enables using modular componentry at all levels of abstraction.

Mastery: Opinion and a Review of Robert Greene’s book of the same title

Going past capable to mastery

Started Mastery by Robert Greene this past week.  My objective in reading this book was to develop a roadmap to continue my professional development.  Despite being labeled the “Go to Guy for Knowledge and Research” by friend and colleague Sarah Moche (Microsoft Community Director) and Subject Matter Expert (SME) on numerous technology topics by others, I always feel I can learn and develop better skills in those areas or help others to do so.

What is Mastery?

I was happy to see Greene’s definition of mastery was similar to mine.  When I was working on reengineering processes at IBM a decade ago this topic leant itself to a heated debate between several executives and I.  The rating system for competencies had a fairly loose hierarchy of determining at what level one had achieved.  The system at its core was not a problem with the exception of the fact that it contained no mechanism to judge application. The system had a scale of one to five with five at the highest level.  However, demonstration of achievement at this level was not on the ability to apply the knowledge in a useful way or determine and resolve problems in the domain.  It was all about demonstrating a good memory for facts, terms and professing expertise.  Through such a mechanism one could delude oneself into believing competence as a brain surgeon because you read a book or as the commercial stated you stayed at a holiday inn.

To myself, mastery of some competency or skill goes beyond such a low bar.  In order to demonstrate and thus prove mastery I believe that three components are needed; Knowledge, Skill, and Behavior:

• Knowledge, the ability to recall and use the appropriate information;
• Skill, the ability to perform using that knowledge (e.g., adding to numbers, hammering a nail, etc.);
• Behavior, the consistent application (usage) of that knowledge and skill to achieve an  objective the competency is designed to assist in providing

Summary and Recommendation

Greene’s book covers these topics but not directly as stated above as well as strategies for pursing a path towards mastery of a domain.  Executing on these strategies will not ensure mastery but will likely improve your probability of attaining such. Included in his book are topics similar to Gartner’s multiple intelligence theory and Kotter’s concepts on transformation and change on a personal level.  Overall despite other critics on Amazon of the book being a rehash of his other books, I found it useful and informative.  The text is rather long –300+ pages– and feel he could have covered the topics more concisely making it a better read.  Even with those minor flaws I would give it a recommended read.

Why is Mastery Important

During reengineering activities of several of the business processes mentioned before, part of my usual approach is to perform an analysis of the existing processes.  The equivalent to a product Failure Model Effect Criticality Analysis (FMECA).  In that analysis I examine what the process is suppose to achieve, how it achieves results, what elements contribute or inhibit results, and how efficient and effective the entire “system” is.  Often during examination I discover the processes are just fine, its the level of competency of the people using the processes and tools is at issue.  In some cases this is an easy fix with some training  [In today’s corporate ecosystem, this often becomes an issues as employers are less and willing to invest in training of employees, expect where compliance is involved].  And in others it requires determining whether to reorganize staff or restructure the processes and job aids to meet the current competency levels. In plain English; hire different people or reduce the skill and knowledge needed and reinforce compliance behaviors of people through creating more comprehensive computer driven processes.

This then becomes a strategy decision for Executive Management to make.  Automating processes enables one to scale quicker, cheaper, ( typically at a cost of flexibility**) and retain knowledge assets easier as computer systems don’t walk out the door to your competitors.  However, relying on automated systems has its liabilities also.  The maxim “Computers make excellent slaves but poor masters” comes to mind.  -In most cases in order to automate effectively  you need to understand the domain you are automating.  An executive placing his or her trust blindly into a computer system is placing both their career and potential freedom at risk today.  SOX legislation does not give Executives an out for accountability because they used a computer system and EULA agreements are written such they hold harmless the software companies.  Which falls back to why Executives, Board Members, and Investors should be looking to find and develop mastery in their employees (a cheap insurance policy when considered as insurance companies often due not cover negligence).  Which based upon current ecosystem is exactly counter to what they are doing.

[ **The reason why people get so frustrated with telephone response systems.  If the path to resolving your issues is not readily apparent…well you get the picture.  Such conditions cause employees, management and work to enter into a death spiral:  Employees work around the system in order to achieve their measurements and goals.  This causes move issues elsewhere in the system.  Which causes more management actions such as increasing collection metrics.  This further reduces employee’s attention to the real process to enable gathering and “conditioning” reports to achieve measurements and goals.  This continues until the impact of this death spiral shows up in the balance sheet.  However, often it is hidden in a similar activity of “conditioning” project and financial reports for several quarters until the yearly close of the books require a full and complete accounting. ]

Intellectual Arbitrage Group: Website Redesign

intellectual Arbitrage Group’s Office365 Small Business Premium website V0.7

Spent a few minutes each day this week working on Intellectual Arbitrage Group’s new public website.

It has taken a little while to get some time on my schedule to work this activity.  Like other small consulting firms,  Time to work on marketing, backoffice systems, and practice development is always in short supply when you don’t have a dedicated people working each task.  Fortunately, using most of the Office365 Small Business Premium templates means I can focus on content and customers instead of presentation.  Only wish it had more flexibility or useful help on how-to customize like WordPress.comto is very minimal.  While the library of SharePoint web parts is helpful, the flexibility of these parts is minimal or not very well supported by documentation.

This past Sunday, I asked my DNS Hoster [ZoneEdit] to build new records to forward my URL and Mail over to my Office365 site.  Both Registrar [DomainPeople] and DNS name service [ZoneEdit] were very fast and responsive, I switched over to new services in less than two hours.  I only hope Microsoft can match that Service Level, though I didn’t see a clear Service Level Agreement (SLA) from Microsoft when I signed up.  But then again they are still new to Services.

Creating Workflow for Modern IT Portfolio Management

On this week’s agenda is building out the workflow for the IT Portfolio Management Practice.  Unlike how IBM, DMR, and Microsoft accomplish practice implementation, I plan on creating a semi-automated workflow using SharePoint, MS Access and Excel.  While using PowerPoint and Word templates may capture content and present it in a “pretty” way, it does nothing for ensuring the quality of the output.  That was one of the reasons I created B.A.S.E. years ago.  I had gotten disgusted back then with the quality of analysis peer consultants were performing, choosing to spend all their time on formatting.  I guess I shouldn’t complain about such, as it created a market for me back then; fixing all the poor engagements and projects these people performed.  I’ve see lots of “pretty” engagements go bad due to poor analysis and thinking which creates the ultimate consulting sin in my book; doing harm to the client.  Having a structured process and supporting system may not guarantee perfect results or avoidance of harm, but it sure reduces the probability and provides better visibility to detect such.