Humanz

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.

The New CIO?

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.

Not Your Average Joe

Average-Joe

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.

Products over Projects

hh 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.

WDWHTDTHS

softskills 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.

Why I protect the Dev Team

DSC_8958 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).

Terrible performance yet no change

A colleague once called it dying from the “ism”s: nepotism, seniority-ism, boy’s club-ism, best friend-ism and the like. I know you have seen it before. Organizations sometimes suffer from this cancer – undiagnosed in their self-diagnosis (outsiders can see it and call it fairly easily).

In amazement, I have watched a local not-for-profit organization suffer from these ills. At first I thought it was this strange lack-of-profit model and its inherent motivation (or lack thereof) that defined this organizations challenge. Until this weekend, when a CFO friend explained that the “Midas Rule” – He who has the gold makes the rule - can apply to all organizations large and small, with and without profit goals.

I have watched as 2 guys have operated above the law and rule on decisions as long as it satisfies their own agenda as opposed to that which is best for the organization.  I have watched as these two rationalized and justified each and every decision against each and every question or challenge to their decisions.  I have watched them systematically eliminate anyone that would dare challenge their decision with the most innocent of reasoning shielding their true agenda – to rule; because it defines them; because without the ability to rule, they themselves become irrelevant.

Proper approaches, industry best practices and industry standards do not require a moral defense.  Transparent models and exposed business practices do not need spin and rationalization.  Fairness does not have any use for secrets and closed door shady deals.

Luckily, I have nothing to lose or gain in this equation. I am simply watching from the sidelines.  But an entire community is losing and losing badly.  When logic does not apply and reality is ignored and politics rein the organization and in this case the community it serves, is the one that suffers.  And suffer for years.  You see, a community does not have quarterly objectives to serve as traffic signals to where it is versus where it should be.  A community does not cater to monthly profit projections as a warning sign of reckless leadership and boardroom ADHD.  A community is not forced to publish an annual report such that its shareholders – its citizens – can reward great performance or opt for change.  So it fails to notice as it slowly diminishes into a ghost town and a “remember what used to be there” town.

Did I mention, the very purpose of this, organization (for lack of a better word), is to cater to the needs of about one thousand kids every year?

Your children.

The ism’s … are a cancer.

1 Year 10 Times

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.

Preferable Differences …

I would not want to imagine a company with more than one of me.  That would be  – annoying.  I was reminded yesterday of the many different differences between us all.  And it is these very differences that make it all work.  Could you imagine a world full of extroverts?  No introverts to balance us out – that would be insane. 

There is more at play here than a simple tolerance of differences.  I am referring to more of a celebration of differences; an understanding that these differences are the “secret sauce” that should be embraced and celebrated.  I would even go so far as to suggest the appropriate affection of these differences could make or break a project or even a company. 

The next time you are faced with a guy that simply does not possess your appreciation for logic or the next time you are around a finance guy who does not share your passion – thank your lucky stars and trust the fact that these differences are the oil in the engine.

May I take your order …

I envy the Sports Industry. While no statistics represents an absolute (other than GPA + SAT pretty much = your academic potential plus or minus an essay here or there for college entry) the Sports industry has it a lot easier than we do. Let’s see the RBI for code delivered to production for an individual; or the rebounds per game for a Project Managers; or maybe the career scoring average for the COO?

Having been around this business for a while I think I have heard it from all sides: business leaders that just cannot understand why IT can rarely deliver projects on-time and within budget; developer ego that cannot understand why they are forced to worked with these incompetent business leaders who cannot make up their mind or define their requirements appropriately; QA caught in the middle who cannot understand why developers cannot write perfect code. And at the end of the day, it seems I must remind myself everyday that I am here solely to solve business problems and not to generate code for the sake of generating code. Now, not everyone struggles like I do. But look to your left and your right – it’s a lot of us.

So I was not entirely surprised when I was asked to join a meeting to help a colleague, and watched in amazement as a business leader discussed their “requirements”. They knew they wanted “agile” development. They knew they wanted Java. They knew they wanted a PM, 1 senior developer and 2 junior developers – to go – with a large fry. And I am certain, in the end, they probably got exactly that.

You can not motivate a pig to fly …

Like all of you I have read and heard the overwhelming fear-based projections surrounding the next or the X or Y generation and their seemingly consistent … attributes (to be fair).

I was recently made aware of an applicant for a development position that declined the opportunity to interview due to the dress code (business formal) of the potential employer. It reminded of “this” generation and what I see as their simple lack of maturity. It also reminded me of every generation and our tendency to be narcissistic at times. In fact, it reminded me of me.

Here was a position that represented a developers dream. Or, at least what I would have constituted as a dream when I actually did the fun stuff – writing code. The position? First, the position involved full horizontal involvement and responsibilities throughout the entire lifecycle from vision to scope to requirements to BPR to design to development to UAT to deployment. Secondly, the position involved full vertical involvement and responsibilities throughout the technical spectrum from data integration/EDI to reporting and OLAP/MOLAP to UI technologies (the latest by the way) to middleware SOA development to database design/development. The intersection of these competency paths is pure gold. I would have waited overnight in line for this position – or would I?

The fact is at different stages of my maturity I probably made equally bad decisions. You could not have made me fly until I grew wings. You could not have made me think until I learned reason. Sometimes, looking for Ms. Right is a futile effort until you become Mr. Right.

From Lebron to the board room everyone is efforting to master the ability to build and manage the highest producing team. One of its core building blocks just may be the simplest (as in straight-forward as opposed to easy) of all – developing the professional maturity of the individual.

Elephant Gun Meeting

Working in the lawn this weekend I purchased some of the new (or at least new to me) instant, grow anywhere grass … patch … thingy. I have seen these things grow grass on concrete (marketing – GOT ME!). I literally laughed out loud when I remembered sitting in a meeting years and years ago – but more about that later.

I thought of the absolutely rich environment that must exist in that bag. The potential is stored in the bag and maintained such that when you pour the contents – anywhere – it grows. Wow! Perfect for someone like me who is – horticulturally challenged.

Now back to the meeting. This company had a time honored tradition of ideas presented to a committee in a meeting ironically titled the “Elephant Gun Meeting”. Conceptually, one would present their ideas and the committee would put the idea through the paces and if it – survived the shooting – they would pursue the idea. I am a metrics guy so I asked the percentage of presentations moved through to next steps. The answer was unknown but one member remembered an idea that “made it through” a couple of years before that meeting (I really don’t make this stuff up).

What kind of nutrients are stored in your bag? Can your ideas grow on concrete? Is your environment that rich with ideas and risk taking that ideas simply grow in all departments and in all circumstances? We all know the shades and sunny spots that occur in business; the rain and floods that come. The huge, seemingly immovable competitors that take aim at your market share. The new, quick and nimble competitors that crop up like weeds in your front yard. The M&A activity that makes many strategies a moving target. There are always many reasons to squelch and shot ideas full of holes.

The is only one reason your ideas are a rich green with deep roots that grow all over – because you create that kind of environment.

Back to the lawn …

Evidentiary Culture

What are the most important keys to success in your organization?

I was in a discussion with a few colleagues surrounding the hierarchy of key performance indicators and someone introduced the KPI’s of culture. In this Six Sigma, management by metrics era we live in – one does not think of the KPI’s of culture. But, as my statistics professor used to say, just because you do not interpret the statistics does not mean they do not have meaning (if a tree falls …).

So lets try on a few just to hear the tree fall. Average length of tenure. If the average length of tenure is high it could mean a high degree of loyalty [great!]. It could mean a low degree of experience [1 year 10 times versus 10 years – bad!]. It could very well mean corporate leadership and HR are doing a fantastic job on the retain portion of “attract and retain” great talent [good!]. Or, it could mean leadership is resistant to change, prune or improve [GE bottom 10% – bad!].

And how about average training hours per employee per year? If this number is low it could mean people are repeating the same efforts over and over and expecting different results. It could be an indication that some much needed outside training and experience could increase the overall competency of the department or organization.

There are a number of weird and interesting data points that could really provide objective non-biased insight into the true culture of the organization as opposed to the stated culture of the organization – number of internal emails versus number of external emails, number of BCC emails, percentage of clients who answer feedback questionnaires, etc.  If you really want to look into the mirror, a quick analysis of numbers could provide the evidence-based answers you are looking for.  But be careful, many a man has stared into the abyss and left wanting!