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

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?

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.

Remember?

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.

Brutal Gang of Facts

It has been an interesting year for me – a learning year. To be honest I started off last year full of confidence in what I knew and how I planned to impact clients in a positive manner. Since then it has been an interesting ride as I have survived an onslaught of a gang of brutal facts.

It is said, one of the greatest tragedies in life is the murder of a beautiful theory by a gang of brutal facts. We truly do hold strong and fast to our way of thinking – human beings do not like change a whole lot. But, while the resulting growth is beautiful, the attack is intensely painful. My mentor once taught me companies fit into one of 3 levels of performance – 1) Doing more with less, 2) Doing things differently and 3) Doing different things. So lets look at the brutal gang of facts through the perspective of the first level of performance.

I find it hard to believe that Jamie Dimon is a genius – although I think a lot of his capabilities. But, surely if there is a billion dollars worth of fat laying around then someone else had to have noticed it. It is probably over-the-top to assume it was intentionally ignored but what is probably more accurate is the existence of a beautiful theory held onto tightly by a great many people. Someone was doing the best they could with what they had. Someone was making the very best decisions available to them at that point in time. And one would probably have had a hell of a fight on their hands to contradict those theories.

But in walks “the gang” to upset the apple-cart. The “more” part of more with less is not exactly what we imagined it would be. The changes we thought we needed were not necessarily the “pill” we asked the good doctor to prescribe. The “facts” present themselves as contradictory to our way of thinking as light to darkness.

If we allow this light in, the growth we experience and the lessons we learn can and will far exceed those old trivial goals of progress originally intended. Moreover, a new paradigm of performance can be achieved and what we may have thought impossible at one time, is suddenly in our reach.

Bring it on!

Results -

In the year 2000, then Bank One posted $511 million in net losses as they hired Jamie Dimon to take over the reigns. Over the next 6 months Jamie Dimon cut $500 million in costs ($1 billion in his first year) in what was called “waste reduction efforts”. Can you imagine the comments when he announced his plan of action? I am sure he was called chicken-little, over-reacting and the other packaged responses typically used by those who lack action. Dimon pushed profit and loss reporting and analysis down through the organization to increase the understanding and change the management approach at all levels. He changed compensation structures to more appropriately align leadership decision-making with results. He walked away from non-profitable customers and even told long-time sacred cows to pay for their own Wall Street Journal. Many said he was the wrong guy for the job and was a prolific deal maker but that was the limitation of his talent. Boy were they wrong (remember, this is the guy that proactively and independently gave himself a 93% pay cut when he accepted the bailout funds). Hindsight is most interesting if we chose to view the past with objective lenses.

Stage 1: Define the strategy. Dimon could have asked for a 6 month analysis of where they could cut the “fat” or “waste”. Dimon could have sent out RFP’s to consulting companies for 6 months deciding which consulting company would execute a project to find the “fat” or “waste”. He could have then followed that up with a series of SWOT analysis on alternatives surrounding “how” to cut the fat. It could have taken 2 years. He knew there was inefficiency. He knew the inefficiency was fat and he knew he could get rid of it.  Not everyone agreed – but he knew it.  Go after the fat that you know exist and simply get rid of it.  The developer that is counter-productive.  The great developer that is ambivalent to estimation accuracy.  The process rich with churn and low in productivity.  If you know where it is – make a plan to go get it.

Stage 2:  Just Do It!  Imagine a “waste reduction” that will save the organization $10 thousand dollars a day.  Now, urgency ought not be confused with recklessness or panic.  But, delaying that gain by 2 weeks just cost the company $100 thousand dollars – the cost of indecision.  Was the risk mitigated by the analysis equivalent to $100 thousand dollar exposure?  Fear and hope are not proper leadership strategies and if you know it – just do it.

Some people see inefficiencies as a part of their core vision.  They are just wired that way.  It reminds me of the Matrix – they just “see it”.  Obviously, all aspects of a process and impacts must be taken into proper consideration in order to mitigate risk.  But sometimes “fat” or “waste” is relatively obvious.  In consulting, did we not call that “low hanging fruit”?

The last time I checked, I think Gartner still indicates only 40% of all code actually makes it to production; only 40% of every IT dollar spent actually realizes ROI.  There is enough inherent “waste” in our business – go after the “low hanging fruit” and increase your own individual numbers.

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 …