Sunday, September 26, 2010

My Favorite Monopoly

As an adjunct professor in post-secondary academia for the past 2.5 years, I have taught several business courses at both the undergraduate and graduate levels.  Part of the curriculum includes topics related to economic systems, market types, and competition types.  I can honestly say that in undergraduate level business courses I routinely present the NFL as a contemporary example of socialist markets, monopolies, and monopolistic competitions.

As far as I know, a monopoly is a market condition characterized by many buyers and one seller.  The one seller (or enterprise in this case) can control pricing through its exclusive control on supply.  That sounds like the NFL to me.  I mean really, where can I purchase professional football outside of the NFL, as pervasive as the NFL.  In the past several years the NFL has protested its innocence in government anti-trust proceedings, all the while saying that its individual teams act as separate businesses in the respective markets.  Really?  Is our government that stupid to accept that explanation?  Well, reader, don't answer that; it is too depressing.

At a minimum that makes the NFL the key players in a monopolistic competition, maybe even a socialist enterprise system.  Where is the socialist-hating tea-party in this argument?

In these economically distressed times, the NFL continues to force its monopoly on consumers by steadily increasing  ticket prices.  Now, one could argue that the laws of supply and demand should kick in at some point and ticket prices would start to shrink when supply exceeds demand.  Meaning, at some point, the consumers will stop buying tickets until the NFL teams start reducing ticket prices.  However, the NFL has another monopolistic technique.  Since the NFL virtually owns the major networks, the NFL actually forces television blackouts in local team markets when ticket sales are poorer than expected. So, again, the consumer is at the mercy of the monopoly.

Monday, September 6, 2010

From the files of "You can't make this stuff up!"

This was so strange that I had to share it.  And I swear that I did not make it up.

While I was working for one company, I started to look for alternative employment with another.  It just so happens that I had an interview with a company to be a technical lead on their Java team.  I interviewed for several hours, talking to individual contributors, architects, and managers. In the end they passed on me; according to them, I was not a good fit.  Now mind you, this was after I had been writing Java web applications for decade and I was running my own development team of about 30 people.

A few months later a new position with that same company came up and I was contacted by a local recruiter.  I informed him that I was already bypassed for the first position, but he still wanted to try.  He returned to me with feedback from the company that they were not going to pursue an interview with me due the last interview I had.  Nice!

At about that same time, my manager's manager came to me with a request to help one of his colleagues.  It seems that his friend was getting ready build a new development team, and since I had managed a very large team with disparate technologies my Mgr's mgr thought that I would be a good mentor for this person.  I said yes without even thinking to check out who this person was.  It turns out that this friend in need was the manager that passed on me (twice) from that other company.

So, I went ahead with the mentoring session with this guy.  All the while I was wondering if he knew who I was, and if he did know why was he still asking my advice after he passed on me (Did I say twice, yet).  He finally let on that he did know who I was, and that is where it got even stranger.  He still wanted my help, and he still thought I was not a good fit in his organization.  So, even though I did not fit into his "new" organization, I was helping him design it.  I could not make this up.

Sunday, September 5, 2010

Tired of Pushing Rope - A Cathartic Rant

I left my last position with a major PC manufacturer and services company because I was simply tired of pushing rope, a.k.a. "Hacking Work".  Everything that I tried to do for the organization or our customer seemed hopelessly complex and laborious as though I was trudging threw quicksand or trying to push rope.  I really started to doubt that I was the right person for the job.  I felt as though I was failing.  Now that I have had time to reflect on the recent past, I realize that what i thought was my failure really resulted in a success:  I walked away with my integrity, and work ethic (not to mention ethics in general).

Since then I have talked with friends, colleagues, and customers.  It wasn't just me. However, no one is harder on me than me.  So I know that I did not walk away from that position clean.  I failed to deliver all the value that I wanted, to the team I managed and to the customer I supported.  In fact, when I stepped down from managing my team, it was because I no longer felt adequate and I was burned-out.  That was somewhat of a selfish motive I guess.

During my time there, I witnessed how we as a delivery and outsourcing company failed to deliver.  In fact our delivery methodology was broken.  Several customers came to me and told me that we were too slow and too expensive.  I know that I did not have all the right answers, but I did know that since I was there we routinely delivered late and mostly with reduced customer satisfaction.  Therefore, I pursued Agile/Scrum training.  I was very excited about the iterative approach and I put together a pitch to my management about this approach.  It was shot down immediately.   Never mind that we were not delivering late and sometimes not at all, never mind that our delivery was essentially broken and over-priced, no one wanted to hear what I had to say and business went on as usual.  Our technical project teams were exercising a "Hope-Driven" approach.

In my opinion we were more afraid of what the customer would think about our new approach.  We could not show that we knew something was wrong with our approach, no matter how inadequate it really was.  We were also afraid to introduce any new process to the customer as we thought we were already perceived and heavily process laden.  I continue to say we, as I did fail to convince anyone of the virtues of changing our delivery model.

One of the major issues was how we traced requirements to testing and sign-off.  We actually had no formal requirements traceability.  Sure, we collected the requirements, but we never linked them directly to verifiable and repeatable test cases.  This became evident when I witnessed ad-hoc  testing as part of the System and User Acceptance testing cycles.  In my opinion the customer simply signed off on the projects when they were satisfied that we could deliver no more value if we continued.

As a benchmark, I consulted with some of my colleagues that also work in the IT Application Services and Consulting industries.  I described how we did business with regards to requirements linking to testing and user acceptance.  They were shocked, as I expected them to be.

Thursday, September 2, 2010

My Time as an Application and eCommerce Architect - Why, What, How

A friend of mine asked an interesting question earlier:  Can you tell me about your experience as architect with Dell/Perot? How did you position yourself to be considered for the role? Did you enjoy the job? Was the role more technical/hands on in nature or more conceptual/framework oriented (Zachman/TOGAF)?

As far as the Dell architect gig goes, I loved the role of trusted adviser to the customer and CIO.   It was less technical and more conceptual.  I was one of several architect types focusing on their own experiential domain.  My domain was fairly wide, containing non-mainframe applications including web and client/server.  As you can guess, this also included various messaging architectures as well (MQ, WS, ESB, SOA).  I guess my knowledge and experience was part of the positioning that I relied on for this role, but I actively sought time with senior management before I was in this role, to recommend that I actually get this role.  I found myself selling the virtues of the role as well as my unique qualifications for it.  It took over a year of lobbying to get into it and get the autonomy that I needed to succeed.

As an architect, I got more face time with high level business folks, as well as the CIO and his VP of innovation.  I routinely found myself in the CIO’s office or in meetings with him, vetting his latest technology direction or decision.  Even if there was a full crowd in the meetings, the CIO and I would be the main two discussing the topic on hand.  Since I moved in to the role from a development team manager role, I had a perspective on development activities as well.  However, this also worked against me as directors and VPs would come to me directly for their needs and try to circumvent the change control process.  I got the reputation for getting things accomplished, but my management wasn’t always happy about that informal process path.

I spent considerable time writing architecture documents that described direction, or assessment of technology, or even documenting our position on a particular technology.  In those docs I used mostly the enterprise, technology, and systems model layers of Zachman.   I really had to understand to whom I was trying to communicate to craft my docs appropriately.  I wrote docs to guide the teams as well as to elaborate to senior management.  

I used TOGAF to help guide me toward a target architecture, though none of my peers used it.  I am no expert myself.  The TOGAF ADM was helpful in so much as it laid out a process for achieving a target architecture.  When I left Dell, I was in the middle of developing a “building permit” process for our technology projects.  As an architect I was cognizant of the lofty positions I could take on technology and tools.  I wanted to be an enabler to the business as well as to the development teams, and the last thing I wanted to do was introduce more process and obstacles to the technology delivery cycles.  The building permit process was going to be a contextual checklist that developers and leads would fill out, in order to proceed with a design.  Based on the answers on the checklist, architecture design reviewers would know how deep to dive into the design based on how pervasively the design affected the published enterprise architecture.  I never delivered this tool, but I still think it is a good idea.

My technology experience and knowledge was very important to my architect role, but more importantly was how I communicated.  I needed to know my topic well enough to remain confident when I delivered a decision or recommendation.  I tried to never be heavy-handed, but I also needed to be firm to exude confidence and decisiveness.  I was looked upon as a leader and I needed to function as one within my domain.  I also worked on my listening skills as well as adapting my non-verbal communication techniques.  I consciously tried to lessen the negative non-verbal communication; it was not easy.