Below are some links to interesting articles I came across over the last week or so.

Article: 10x Productivity Myths: Where’s the 10x Difference in Compensation? by Steve McConnell at Construx

Quote: When someone says, “I’m 10x as good a programmer, therefore I should be paid 10x as much,” they’re assuming that their value to the business is based on their programming capability/contribution. That is part of the story, but not the whole story. Some mediocre programmers might be better at interacting with customers. Some might have better potential to move into management. Some might have less personal output but a wonderfully positive influence on overall team output. There are lots of other factors that influence “value to the business” besides raw programming output.

“My overall conclusion is that paying for productivity on any more than a very-rough-approximation basis is a panacea that cannot practically be achieved.”

Article: Is Your Failure Rate High Enough to Succeed? by Todd C. Williams at Back from Red

Quote: “This concept is more than learning from our mistakes, it is stepping out our comfort zone into area of known risk in order to get higher returns. After achieving success, we must repeatedly push our bounds to create more failures in search of even loftier goals. This requires leadership that tolerates, or even celebrates, the right kind of failure—failure as part of a plan to move the company forward in new and bold ways.”

Article: Three Balances For Resilient Groups. Why Every Group Will Collapse. by Bas De Baar at Project Shrink

Quote: “In general people prefer like minded people. In an environment that changes this means that homogeneous groups would become larger. It is more comfortable to be among “your own people”. So, a changing environment the natural balance would shift toward homogeneity.”

"I just signed the sales contract yesterday. This needs to be up and running by the end of this week!"

In talking to others recently, we’ve discovered an unfortunate pattern across multiple companies where the partnership between the business units and IT isn’t particularly strong. When I say “partnership” I mean the level of collaboration on business activities that involve IT in some manner. Prior to contracts being signed, has IT been directly involved in the new business opportunity? Does IT have a voice in the major initiative delivery date setting process? Is IT’s resource capacity considered at the same time the business’s resource capacity is being evaluated in moving forward with a major effort? Does IT have access to the business’s multi-year plan? Are IT initiatives peppered throughout that multi-year plan?

There are a seemingly endless list of articles available on the Internet that talk of the need for a strong partnership between IT and the business units IT supports thus I won’t extol those benefits here. Rather, what can an IT manager do in a company that is taking strides towards but is still working on forming a strong business and IT partnership? Or …

What to do when the Business wants “Instant IT Gratification”?

By “Instant IT Gratification” I mean the corporate culture where IT is expected to delivery what the business is asking for, how they are asking for it and when they want it done all without collaborative dialog. Contracts are signed without IT. Due dates are determined in advance and IT is expected to meet these deadlines without being consulted. The results of such interactions between IT and business requesters varies, but the thematic results are the most frustrating:

• Sub-optimal technology implemented: Instead of matching the need with the optimal technology, the quickest/fastest must be chosen to hit the date.
• Many post-deployment follow-up activities needed: Instead of having a healthy collaborative discussion about all the “requirements”, only what the business shares is implemented requiring many “oops, we forgot we also need X”
• Inability to upgrade/enhance existing technical capabilities: always focusing on the urgent needs of the business without allocating a percentage of time to invest in more current technology assets.
• Work never done: Constantly jumping to the next hot request leaving only phase one of Y implemented from the previous hot, now cooling request.

What can an IT manager do in this kind of culture?

Anyone who skimmed the above bullets and identified with even one point knows these are cultural problems that a single IT manager won’t be able to solve over night. So how does one not pull their proverbial hair out of their head trying to get anything proactive accomplished in such a re-active business model? Consider some of the options below; just know that none is a silver bullet of success.

• Leverage the formal charge back model.

If your organization has a formal IT work charge back model, become intimately familiar with how the process formally and informally works. Employ the charge back model in every possible situation to ensure there is fully accountability and record-ability for all business requested IT work.

• No formal charge back model, then use time as the “IT currency”.

If no formal charge back model exists to leverage, then the only real charge back model or IT “currency” is time. Make sure you have full data based reporting on all the work your team is performing. When a new “hot” request comes in, update your single view of the work and present the new “hot” request alongside all the previous “hot” requests and ask the business to prioritize.

• Like it or not, get some formal work estimation model in place

If all the business requests “just get handled” then the business has no governor for making requests. Without a charge back model to where the business has to make the conscious decision to spend on one thing compared to something else, there is no barrier for the business to make every conceivable request to IT. One approach is to “just handle it” and try to service every request as quickly as possible so to not have to engage in any prioritization or work break down discussions. But as I have written prior, having some formal work estimation process allows for an intelligent, data and date based discussion with the business. When presented with duration and possible delivery dates, business users can more easily take low priority work off the request list. Low priority work can easily be removed once it is known by all what is consuming time and delaying the delivery of what the business truly needs in a hurry.

• Don’t blindly start working on requests, ask probing questions

From a previous article on my learning in attending a formal Agile training class, asking why multiple times (per the instructor, ask “why?” five times to get to the bottom of the need for a request) in order to dig into the real reason for making a request for work to IT. You will be amazed how many times the request hasn’t been fully vetted by the business. Asking why to get to the real business case to support a request will help to reveal what is truly a priority that IT is in the best position to deliver on compared to a frivolous request that if not executed, actually reduces technical debt without harm to the requester. Invest 40 IT hours in order to avoid a situation that happens maybe once a year and consumes 4 hours of the business’s time? Assuming all costs being equal between the business and IT (usually IT costs more per hour) , a ten year return on investment? It would seem those 40 IT hours should be invested elsewhere.

As I said, these clearly aren’t silver bullets that eliminate the challenges of a less than strong partnership between IT and the business units. Yet, by consistently improving ones capability to work with business requesters through careful implementation of the bullet points above, one can establish a level of credibility for your team’s services back to the business to better align the limited IT resources with the highest priority work for the company as a whole.

Building structure without command and control ... isn't that an oxymoron?

I can’t say enough positive things about the stimulating agile management views shared in Jurgen Appelo’s new Management 3.0:Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn)) book currently available here on Amazon.  Jurgen has assembled an extremely thought provoking text that covers the breath of the challenges to effective team management today.  From the basics of self-organization to leading people to effective communication to competing management models, Jurgen has provided chapter after chapter of excellent insight into what is needed to manage in today’s dynamic business climate.  Even though I could go on and on about my interpretation of each chapter, this article will focus on one aspect of Jurgen’s “Martie the management model” depicted in the below graphic and introduced in Chapter 16 labeled “grow structure”.

Even though my background is focused on working in corporate IT departments rather than tech startups or consulting, I found great validity in Jurgen’s “views” outlined in his management model including his own admission that it is “wrong” (p.371) to some degree as all models are inherently wrong in being comprehensive and time proven.  Some may say that corporate IT and in particular, large corporate IT departments are unable to be “agile” and thus such an agile management model is less relevant.  I disagree in that there is a constant barrage of blog articles and news stories pressuring corporate IT to be more nimble, deliver more value quicker and with less people.  Thus, managing less people who are expected to wear even more role and functional “hats” requires a more progressive management style compared to the more traditional command and control approach.

With all that being said, wouldn’t one conclude that to “grow structure” one would have to invest in even more command and control management techniques?  Quite the opposite is proposed in Jurgen’s model.  Covered in depth in chapter 13, Jurgen suggests that in order to be in a position to efficiently adjust to the changing demands of the overall organization, technology, products and people, a manager must institute concepts he identifies as “generalizing specialists, wide job titles and informal leadership” as summarized on page 309.  I interpret, from a corporate IT perspective, the structure he is proposing to be one of recognizing the multiple hats and positioning the team to best adapt to change.  Examples in my mind include working with that technical expert in one narrowly defined domain to assist them in appreciating the need for expanding outside of their discrete technical silo through coaching, mentoring and stretch assignments.  Additionally, challenging team members that have been previously placed in narrow job definitions to think of delivering more expansively; while at the same time, providing some structure to that expansiveness in order to provide a level of focus so team members can actual accomplish a task or function.

So, implement wide job titles, push team members to take the lead on assignments (informal leadership) and stretch specialists to become generalists … this doesn’t sound like creating structure?  I encourage you to pick up a copy of Jurgen’s book and explore how he eloquently presents a compelling argument for why such destruction of traditional command and control management is most effective in being an effective manager and leader in today’s business climate.

Below are some links to interesting articles I came across over the last week or so.

Article: Tomorrow’s Project Manager

Quote: “The key to the future is acquiring the soft skills to aspire to new levels of management.”

Article: Mending Wall: Matches and mismatches in IT stakeholder expectations

Quote: “Make no mistake about it: mending walls is hard. Doing just one or two of the above approaches will cause you to fail as surely as if you did none of them. And in my experience, absence of the appropriate balance almost always causes a company to devolve into systems chaos.”

Article: Don’t Start a Project with Scarcity

Quote: “Do not, under any circumstances, commit to an end date if you feel you must start a project with scarce resources of any kind. Do NOT.”

Article: What being in a band taught me about management

Quote: “Trust is Key … Similarly, as a manager, my effectiveness is directly related to the trust within the team.”

Article: Can a CIO be successful without IT experience? Define your terms!

Quote: “Only actual work experience, grappling with juggling priorities, making tradeoffs, and satisfying multiple constituencies, tends to teach people how to maximize the value from IT-related investments made by the company.”

Article: The Consultant’s Lore

Quote: “In nearly all cases, the consultant’s job is to simply listen. Everyone on the project has an opinion, someone needs to poll the individuals, understand their concerns, and use this data to identify the problems.”

How did you get started in programming?

In catching up on my regular blog reading I was struck by a recent post by Dave Swersky over on his blog {get; set;}: CODE! titled the same as this post.  Dave answers a meme he discovered “floating around” (per Dave).  My About Me provides a quick professional overview of myself but Dave’s post triggered me to consider answering the same questions myself.

How old were you when you started programming?

Similar to Dave, I probably started around seven or eight years old on a TRS-80 computer] with a cassette tape drive for storage that my father, a middle school teacher, would bring home on school breaks for me to tinker.  Yes, a geek at an early age when geeks weren’t cool, I enjoyed wandering into a Radio Shack store and quickly typing in a program that would wait about 3 minutes (enough for me to get back out of the store and take up a remote vantage point), then change the full screen to random colors and emit random beeping sounds at the same time as the screen color changes.  Yes, an extremely geeky prank but still it was mildly humorous to watch the store clerk have to find the noisy computer and stop the program.  I wasn’t mean enough to disable the break key, but the thought crossed my mind.

How did you get started in programming?

I started out professionally on the infrastructure side of IT but was always drawn to creating my own programs to demonstrate certain technical capabilities beyond the infrastructure bane of stringing vendor provided technologies together optimally for maximum end-user functionality and up-time.  I finally made the professional jump in the dot-com days to work on the first online corporate treasury/banking web application for a large financial institution.

What was your first language?

It was BASIC on the TRS-80, then the Apple II.

What was the first real program you wrote?

Besides all the demonstration programs of various sorts in my professional career, the help and user administration portion of the corporate online banking application would be the most comprehensive and production deployed application.

What languages have you used since you started programming?

I dabbled in 6502 and 68000 assembler.  After BASIC, I taught myself C, then C++ then Java.  I guess I can say I am really a dabbler.  Additionally I have explored VisualBasic/ASP, .NET, and PHP.

What was your first professional programming gig?

After ten years in infrastructure it would have to be that financial services development gig.

If you knew then what you know now, would you have started programming?

Yes … even though I am presently drawn to managing IT development/delivery teams, without that heads down experience of working in a large (14 person) development team in an n-tier systems environment with heavy and complex transactional requirements and need for strong security, I don’t think could relate directly to the developers I manage.

If there is one thing you learned along the way that you would tell new developers, what would it be?

The one thing would be to dedicate some time to understanding how a developer fits into the overall corporate and company value structure.  I find too many developers focus 100% of their energy on learning their craft and get frustrated when management doesn’t recognize them for purely writing elegant and efficient code.

What’s the most fun you’ve ever had … programming?

Fun?  I would have to say the most fun would be a tie between all the learning programs I wrote in my youth on the TSR-80 and Apple II systems coupled with all the corporate development “experiments”.  By experiments I mean demonstrating various capabilities that supported or jump started management championed projects to deliver real solutions.  I once showed that support technicians could use a Palm VII (remember those?) to receive help desk trouble tickets and provide updates/statuses while off site.  This kicked off a management effort to get more technicians Palm VIIs to enable more 24/7 communication on production issues.  I once whipped up a crude browser based reverse auction demonstration application that assisted management in going forward with a capital equipment based reverse auction business process.  My demonstration solidified the technical approach to the overall business case and ultimately leads to a commercial reverse auction product being purchased and developers hired to support/customize it.

Fun stuff!

Statistics for 2010

Being late to the blogging scene, 2010 represented the first full year MidWestITSurvival.com was in operation (originally live in August 2009).  I thought it would be interesting to share some statistics from 2010:

(Per Google Analytics)

3,626               Total unique visitors

5,275               Pages viewed

Viewer traffic sources:

I personally enjoy that 27% of visitors that come directly here to read articles and the additional 33% that come here from other sites that link people here.

The top 3 articles in terms of number of unique visitors reading them are:

1.      Is the Gantt Chart Useless in Agile Projects?

2.      Organizational Structure and Enterprise Architecture

3.      Managing Infrastructure Compared to Software Development Teams – Part 2

Note:  Interesting that Part 2 is more viewed than Part 1 on my thoughts on managing the two different technology teams.

A total of 42 articles were published in 2010 with a total of 28 comments submitted to those articles.

All in all, having no goal of X number of comments per article or Y number of unique visitors per month, etc., I’m rather pleased with the blogging experience overall.  The interaction of blogging plus the social media outlets of Twitter, Facebook and LinkedIn have lead to my appreciation for the rapid changes impacting the marketing industry today.  I’ve discovered a number of fellow bloggers that provide excellent incite and thoughts on challenging topics I face every day in my attempt to survive a career in corporate IT.  As a direct result of my blogging work, I have had the great privilege to review and provide feedback to authors of two books soon to be published in 2011.  Without this blog I wouldn’t have ever had those opportunities.  Through this blog I enjoyed a number of thought provoking interactions in the social media space in 2010.

Here is to 2011 and all the new challenges ahead!