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.


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?


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


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.


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

The Santayana Theorem

Those who cannot learn from history are doomed to repeat it.
Those who do not remember their past are condemned to repeat their mistakes.
Those who do not read history are doomed to repeat it.
Those who fail to learn from the mistakes of their predecessors are destined to repeat them.
Those who do not know history’s mistakes are doomed to repeat them.


Remember when we tried to take the fat client app and do a limited browser version and called it a web app? Remember when we took our sloppy LAN “worst practices” and blamed the “speed of the Internet” for performance problems.

Remember when we tried to “evolve” OO to SOA yet we were still copying and pasting the same code all over the app.  Remember when a web app was a marketing splash page.  Remember when we thought about browser independence after the fact?

Remember how browsers and browser versions wreaked havoc on basic code stream and release management.


We are doing it again. It’s just a phone now. A smart one, but still just a phone.

Leaders Stand Alone

Technology is a thankless service.

Let’s try maintenance and support – the part most of us would rather be done by someone else. If we do our job correctly, we make it look far too easy and people rarely know it is happening. The business result of these efforts? Uptime and lots of it.  Stability and reliability – how often do you think about breathing? The cultural results of these efforts? Well it would not be the first time that some CFO wonders what “all of those people” do down there all day.

Let’s try new functionality. Time to market is always longer than what someone wants it to be. Additionally, as soon as it makes production (70% of IT projects never make it to production) its resulting impact is typically not managed and measured thus its overall impact to the organization is typically not understood or realized.  No wonder some organizations deliver the exact same functionality with 32 developers what other organizations deliver with 12.  Who knows the difference?

You do. 

Let’s not play the victim here.  And please, let’s keep our professional immaturity in check.  We are paid well for this “miserable plight” we are forced to contend with and we ought not need a pat on the back every day or exhaustive training to go along with our high salaries.  70% of the nation makes less than your average technician with just 3 years of experience. 

The top and the best and the greatest are often led by an internal drive and driven by a force not clearly understood by others.  Whatever you may want to call it (that in and of itself could raise a 3 hour debate with IS folks) re-capture, renew and re-energize more of it within yourself because you are going to need it.  Don’t expect your boss to get what you do and don’t expect the CEO to value your contribution over the contributory efforts of the most average (defined here as the median not the emotional lexicon of average) salesperson.

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.

Blocking and Tackling

I was speaking with a colleague from Finance about Customer Service: yep – Finance … Customer service. She was remembering how her father had his own company and how they (the kids) were well trained on how to answer the phone politely and with respect and how her mother would be in the middle of “ripping them” (ripping is what parents used to do when parenting was the in thing) but quickly convert to Customer Service 101 when the phone rang. Just to proceed to uninterrupted “ripping” when she hung up the phone. I loved it and I loved from whence it came – Finance needs customer service too.

In technology we always have 2 sets of customers – internal and external customers. And if finance is working on their customer service skills then why not technology? Are we above the need to listen to our customers and exercise a little or a “lottle” patience and understanding when dealing with our internal customers? And why do we treat our external customers with such grace and finesse and tear apart our internal “children of a lesser god”? Is it beneath us to use complete sentences and elongated paragraphs when communicating with our customers? Is the extra time really that much of a drain on our overall productivity?

I have heard a lot of the “reasons” for how we treat our customers and the reality is this – if we don’t treat our customers like customers, someone else will and they will not be our customers anymore. And yes, that applies to our internal customers as well. It is simply blocking and tackling. I was watching the Monday night game last week and the announcers were discussing Bill Belichick’s practice and how they cover every detail. What does he get for that? 4 Super Bowl appearances in 10 years with 3 wins and the only team to ever go undefeated in the regular season – ever. Yes they did lose the Super Bowl that year but that is completely irrelevant – you cannot ignore the only team to ever go undefeated in the history of the NFL.

Customer service is like blocking and tackling – if you do it well – and by well I mean do a fantastic job at it religiously and fanatically – you will every opportunity to impress the world with your elegant technical architectural designs and efficient code writing and scalable infrastructure. If you do not do it well, no one will ever know how great you really are.

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.

Contract Renewal Strategy?

Free Agency took on a whole new meaning lately. Did not Amazon re-define the way we see books? Did not Google re-define the way we see information? Did not Michael re-define the way the game is played? Introducing Lebron James – re-defining the way we attract and retain top talent.

The Decision and it’s resulting media frenzy not only gave us some insight but also taught us some lessons – if we were paying attention. There is no doubt Lebron is the most dominant player in the NBA (sorry Kobe – accept it). Additionally, will he not hold that crown for the foreseeable future? Everyone has an equal salary cap it is simply a matter of where to spend the money. 1 team attracted 2 players, convinced them to leave their own teams and come to Miami. Could not the Raptors had done the same? Why couldn’t Wade and Bosh move to Cleveland? Is it because Riley’s tossed his “bag” of 27 championship rings on the table and told Lebron to try one on (He has a gold, silver and platinum copy of each. What? He must match – right)? And how did Cleveland lose him and be the last to know? And finally, when was the last time this happened to you?

Lebron clearly had a well-planned and better executed contract renewal strategy. First of all he based his own individual assessment and development on the open market. He was not content to be the best at his company but the best in the league – the world. Next, he accomplished the stats the conference titles and the league titles (not the big one) to ensure everyone else knew he was the best. The rest is, as they say, history. What is your contract renewal strategy?

Are you comparing your talents to that of the open market? Are there 100 people working within 25 miles of you that make 20% less than you make yet have more capabilities and competency and have the stats and titles to prove it? Are you shooting 500 free throws a day after practice? Or, are you simply relying on your organization to train you and develop you?

The more you know, the more capabilities you have, the more intellectual horsepower you bring to the table the more valuable you are to yourself and to your company. In sales there is a great saying that if you do not develop the solutions required by your clients – your competitors most definitely will. The exact same principle applies to each and every one of us. If we are not growing and developing the skills required to take our organizations into tomorrow, someone else is and someone else will.

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.