IT Bartender

I have been immersed in leadership thoughts lately. It seems the concept of “good” leadership in IT has been surrounding me on a daily basis. And it occurred to me that a basic building block of “leadership” has been missing in some of the examples I am seeing on a daily basis. That basic building block is the Humanz.

We don’t have “human resources” in IT we have Humanz.

People.

You know: kids and adults; mothers and fathers; uncles and aunts; night time coaches and single mothers; night time students finishing their degrees and caretakers for their aging grandparents; people with past and history and a story of “how they got here”. These are some incredible stories. And if you don’t know the story, how can you help the Humanz. Yes … help. Isn’t that what leadership is?

Oh -wait. You didn’t think because someone has career goals that they can not put the “company first” did you? Are we seriously going to demonize career management as narcissistic?

Help!

And in order to help I have to first “give a damn”. I have to legitimately care about the Humanz. And I am not talking about the leadership course we all took on how to demonstrate that you care. I am talking about actually c-a-r-i-n-g and actually listening and actually asking “how did you get here and where do you want to go”.

For me, I have to actually care about the Humanz and THEN I can understand “a mile in his/her shoes” and THEN I can know the Humanz and THEN I can …. help … because help … IS … leadership.

Humility as a primary trait

I remember the passion in his voice and the sheer determination in his eyes. He said, “I will never hire a CIO again”. Here the CEO of a multi-billion dollar corporation was abandoning the IT leadership classical model. Instead, he hired someone from the business, that currently served as an EVP of the “customer engagement” team. The results, quite simply, were staggering. Profitability – up. Revenue – up. Feature and function release to production – up. Number of defects – down. Enabling innovation introduced to production – up. Everything was looking great for this already successful company. Was it just the wrong CIO? One could argue that. Was this EVP simply a star in disguise? One could argue that as well. But this CEO, having hired multiple CIOs over the past decade was determined that “maybe” would not see the light of day. He wanted to be clear – the sole culprit of “what was holding our company back” was the ego of the “Vice President of No“. And that has stuck with me every since.

So here I sat, years later. And now another CEO was asking me: “what is the number one thing I should look for in a CIO”? She had just accepted the resignation of her CIO and was looking to replace her. My response was absolute as I felt it true, deep down in my soul. Humility. With an expected look of confusion sweeping across her face I began to tell her the story above with a particular focus on the results. Business results matter. They are the only thing that really matter.

So if you have an IT team that “authored the requirements themselves because the business …”, the good news is that there are requirements. The bad news is only ego makes an IT department think they know more than the business. If you have a thousand reasons surrounding “security risk” and “costs” and “scalability”, authored by your IT team, and keeping you from going to the cloud, the good news is you are facing a problem well discussed and the answer as simple and as straight-forward as any business challenge you will face this year. If your IT team “approves and denies all business request for technology solutions” the good news is your business is trying to advanced the company forward. The bad news is, well, let’s just say the throne and scepter was removed from the company mentioned above and the business flourished.

It has been a great week.  And for me that means I learned something as I try to do every week – every day is too aggressive for me.  It has been a week of reflection and hard work; of gratitude and perspective.

I was reminded today that I don’t work around your Average Joe.  I am, instead, surrounded by people composed of a different constitution and people that see the world through a different lense.  I am surrounded by … the very people I always wanted to be surrounded by.

I am surrounded by a group of people that don’t always agree but who are always willing to professionally debate the merits of all sides of the argument in order to find the right solution.  I am reminded the right solution rarely fits the square peg into the square hole.  Moreover, the right solution often demands a new structure to contain it –  new processes to facilitate it and new models to explain it.

I guess I was not made that way and I know I was not raised that way = status quo is not meant for me.  I identify when Pam says “culture eat’s strategy for lunch”.  I get that.  It still rocks my very being to this day.  The “customer has the right to be unreasonable”.  That is a cultural icon that I am happy to live beneath.  And “who do we hire to do the hard stuff” compels a different calling.  That sounds heroic.  Let me be clear – we are not the guys with courage that run towards the sounds of chaos and disaster to save the life of a stranger.  Those are the heroes.

But we are indeed marching to the beat of a different calling.  We don’t do the “race to the bottom”.  You can fall gracefully and win that race.

It’s been a good day, because I got my perspective changed today.  Thank you Alan.

I generally stay away from buzzword topics. They are typically marketing oriented and serve only the advertising for which they are intended. It is sort of like presidential campaigns and polls. Have you ever thought about the reason for their existence? The candidates really do not benefit from the polls outright as one’s mercurial behavior can increase the polls just to see them fall later. The public most definitely does not benefit from the polls as they represent disinformation as opposed to any fact-based reality. The polls are created by and substantiated by the media in order to benefit the media. It gives them something to report on – “Breaking News – George Washington Up in the Polls by 7%.” Kind of like ESPN when sports gets boring the Lebron versus Kobe debate starts all over again.

But this particular piece of marketing spin, designed like all others to sell something shiny to an otherwise unwilling participant in the dance, is perhaps the most convoluted piece of disinformation ever (yes, I typically am not a fan of hyperbole but I do engage every now and then).

There are three vastly different business frameworks interwoven into this shiny fabric. The first covers procurement vehicles followed by technical debt finished up by business process evolution.

The business process evolution incorporates one of three basic approaches in making your business perform better over time.
1. Do more with less; 2. Do things differently and 3. Do different things.

A project makes a singular leap through one of these approaches through one iteration. For example, Cisco had multiple “projects” that re-engineered their expense reporting process enabling the “do more with less” approach. These iterations reduced the transaction costs each time and resulted in an significant overall reduction by the final iteration. A product (software product) is designed to encapsulate a business process and enable that process through automation making functional enhancements over time (thinking of my iPhone 6 upgrade of late). So the product approach helps with approach (1) but not in approach (2) and (3). Actually, it could be argued that the product and project are pretty much the same in regards to approach (1).

Procurement is how we buy and their are three ways to buy technological solutions: (1) staff aug, (2) Project Deliverables and (3) Package Software. A product over project discussion embeds a hidden assumption surrounding the procurement vehicle that is both not accurate and not fact-based. The assumption is this: a product approach includes a “package” purchase and a project approach concludes a deliverable purchase.

Finally, there is technical debt. This aspect has many perspectives but the short version includes the debt curve is different for many different industries and verticals. The public sector carries a large debt structure by necessity and this normal and standard model works in direct opposition to most product over project rhetoric. Manufacturing comes in a close second with their well managed technical debt and a host of other industries and verticals manage technical debt as a strategic maneuver that weighs more heavily than product versus project considerations.
Product over project gives a topic and product over project gets a meeting and may even get a speaking engagement at a conference near you. But a wholistic decision leading to a corporate strategy is a little tough for me to imagine.

If I never get to see the northern lights I won’t be happy. The sheer scope and scale of this naturally occurring phenomenon overwhelms and inspires me. I enjoy challenges – the harder the better.

I find some of my experience in this tech-space has been straight-forward but rarely easy. I remember tough projects spending a lot of their time in the “valley of despair”. Large scale and small and highly complex to low-tech – all IT projects have their own particular flavor of “hard”.

The client always enjoys the “luxury of being unreasonable”. There are difficult and arrogant “heads of operations” who “built this same solution at my last shop” (bless their hearts). There is the head of sales who does not see the need for predictive modeling in the solution set and the guy that says he is not sure “mobile” is a viable solution in the healthcare space.  And those that insist that you “respect the title” and those that hold “court”.  There is “kissing the ring” and re-writing that email 30 times versus the short version.

There is the developer who thinks he is the best BA in the room; the BA who took a couple of coding classes; the QA whose next project should include a project manager title and who could forget the aloof and distant architect (not to mention the know-it-all CIO).  As a CIO I sometimes laugh at all of our dysfunction as few of us can actually admit these failures out loud for fear of looking bad – and of course we can not look bad!

But when they come calling … searching for an actual result … who do we hire?  Who do we hire to do the hard stuff?  I call them the IT Seal Team.

Members of the seal team are an elite crew devoid of excuses and blame with nothing but demonstrable results in the wake.  They make mistakes often as they are not afraid to take risk yet avoid recklessness.  And they are ok with mistakes because they know image is nowhere near as marketable as results.  Only in a presidential election are facts completely irrelevant.  In our world, success breeds inheritance and everyone watching knows when IT succeeds and when it fails.

I came across an interesting blog discussing the warrants and interest of farming your own food. It covered some basic yet still interesting perspectives on specialization where a farmer is probably a lot better at farming than a lawyer farming in her spare time. It also reminded me that I would probably get bored with the corn and spinach bacon salads I could grow versus the diversity of Giant Eagle and food options presented there. It was well established by first the manufacturing sector over a hundred years ago and then adopted by pretty much every other industry since that specialization is far more efficient than any other work distribution model.

While every nurse “thinks” they have just as much efficacy as a doctor and every developer “thinks” they can do BA work just as good as a BA my experience says differently. I find BA’s to be the only ones proficient at being a BA. And I have seen the extremely effective SME attempt BA deliverables; I have seen a plethora of finance experts try their hand at BA deliverables (and coding but that is another conversation); I have seen project managers try their BA kitchen talents and while they come close they still can not match the skill and efficiency of a real BA.

But that which explains best why I protect the dev team is the value proposition a BA affords to the enterprise business model simultaneously protecting the business from the dev team and protecting the dev team from the business.

Of all the duties and interest of a BA the relationship management with the business is an ongoing and important function that contributes most to highly efficient and effective technological solutions. The BA also brings an understanding – a translation – of business versus technological interest that I find few developers are capable of balancing. While the developers truly live to serve the end-user (and the best one’s actually enjoy that part of the job the most) the BA simply does a better job of user-empathy and therefore will prioritize the needs of the one over the needs of the many (sorry for the obvious geek reference) when it is necessary whereas that choice would rarely be made by a purist.

The optimal output comes about by letting the developers develop, the architects architect and the BA’s … well … manage the users, educate the SME’s, prioritize the unnecessary request, evolve the business process even where no technological changes are required, transform the training teams, facilitate for the project manager and in their spare time write requirements and design great solutions for the business.

I will take 2 good BA’s for every good developer any day of the week.

And please, don’t talk to the developers directly and don’t feed the animals. I grow my own herbs but that’s about as far as I go (actually it’s my wife that grows the herbs).

A question was posed to me that this “consultese” was overused and lacked meaning.  I was asked what it really meant; and what was the true, demonstrable and quantifiable impact on the delivery of technology to the hands of the business.

I live for this!  Ok, I rather enjoy when posed with a seemingly indefensible position – a strategic approach indeed but mired in flaws as the question in and of itself wreaks of defensiveness and an inferiority complex.  But what I enjoy is this – this question forces me to be exact, specific and avoid the shortcut – the quick answer.

The industry vertical:  An app is an app is an app – or is it?  There are many business scenarios to be learned from a multitude of industries.  Working in the healthcare industry for 10 years writing stored proc after stored proc may or may not be as rich as writing in healthcare and in retail and in financial and manufacturing.  There is a little something to be learned from actually performing in these varying industries is there not?

The SDLC horizontal:  Be it waterfall or RAD or Agile or Lean or SCRUM (I know, I know – just trying to be buzzword compliant) there is a different set of related competencies at use in the varying phases of the SDLC.  Can we not learn a little more about the depth of our industry if we spend some time learning and developing our capabilities in the scope phase or honing our skills in the requirements development arena (come on – what developer has not complained about requirements or the lack thereof)?  Do we not enjoy the frequent and in-depth bashing of architects “not responsible for staying around and coding their lofty ideas”?  Would we not learn a new appreciation from performing that role or would we “finally be the only one to do it correctly”?  And clearly, beyond the development role, would we not understand the thoroughness of requirements traceability and could we not enhance the richness of our expertise by being the one responsible for those test scenarios?  And who could forget the actual operationalization of the elegant code we wrote – would we not see things differently if we were the one responsible for turning it on and actually operating the P&L on a day-to-day basis with the actual tools just written by another competent developer?

The technological dimension: Where have I spent my one year?  Have I spent it in the UI versus the DB or the services layer versus the infrastructural layer?  Maybe I spent 1 of those years in the reporting area deploying the hard and fast parameter-driven reporting platform with a little BI embedding in the application itself.  OR maybe I spent 10 years in the ETL layer bouncing translation files from app to app and from consumer to consumer and from subscriber to subscriber. 

The business functional galaxy:  If you know not a credit from a debit or the purpose of a clearing account how can you design and develop accounting solutions?  Knowing the different drivers behind sales confidence and commission models may or may not enhance the ability to design and code lead management automation. 

For me, I would prefer to cram as much in-depth richness and experience into ten years as I can.  The more depth the more contributory value I can create and deliver to the organization.  And in a results driven economy, delivered value is priced at a premium.