Remember Veruca Salt from Willy Wonka and the Chocolate Factory?
She was the stuck up little girl who was spoiled by her wealthy father and wanted everything right now – specifically a golden goose. When her father asks Willy Wonka how much for a golden goose he replies “she can’t have one.”
This sends Veruca into a musical spoiled brat rage, until she ultimately meets her demise going down the goose egg chute.
Despite the seemingly over-the-top portrayal of spoiled brats, this depiction is not too far from how some companies act when they need a solution to a problem.
Veruca Salt being an annoying brat
Frequently the tone is “I want it now” with the powers that be pressuring employees to deliver projects immediately, without understanding the repercussions of that demand.
Typically, if the tone is “I want it now” it indicts a greater problem with mixed priorities. In that tone, the priority is not creating a good solution that solves the correct problem, the priority is developing a solution – any solution – to prove that the objective was met.
Unfortunately, the objective should not be developing a solution, the objective should be developing a solution that solves the correct problem. The solution is not the objective, it is exactly that – the solution. And by definition you cannot have a solution without a problem.
Oftentimes, the “I want it now” mentality is driven by a need to spend money. The end of year comes and you have extra dollars to burn, this can happen for a variety of reasons, but if it happens often it can signal poor planning at the enterprise-level.
But even if this occurs infrequently, it is typically executed poorly. Solutions are rushed, requirements are not gathered, and ultimately a poor piece of software is developed. Instead, work with the service company that develops your software, they will gladly let you pre-pay for a bucket of hours that you can utilize in the new year for a thoughtfully designed approach.
I’ve seen the “I want it now” mentality from within the walls of a Fortune 500 company, and from the outside at a service company, it is a common mentality, and I oftentimes think that if we could overcome it a new era of innovation and productivity would be unlocked.
Think about all the solutions developed that are poorly created, and the impact they have on business. The problems they are intended to solve remain unsolved, which creates more problems. Employees grow frustrated by a solution they have to rework or learn to work around, and while their previous process may have been manual and inefficient, frustrated employees working around a piece of technology is just as inefficient.
Additionally, there is a contingent of IT folks trying desperately to make the technology work, despite its flawed design. This typically occurs when a company has spent a large amount of money developing and rolling out a solution. The larger the time and money invested, the less likely a company is to squash a poor solution.
This syndrome of “I spent so much money, so dammit we are going to make this work” baffles me. Even when everyone knows the solution is poor and causes more problems than it solves, the powers that be refuse to squash it dead.
It is one thing to be a Veruca Salt, it is another to be stubborn and not willing to admit when a poor solution was created.
So, how do you avoid being a Veruca Salt?
Create a group that plans technology one, three, and five years out
If you do not have an Enterprise Architecture group that oversees all technology planning organization wide, you are bound to become a stubborn Veruca Salt.
In typical IT teams, there are support groups for every aspect of the organization; one for Marketing, Sales, and any other business critical team. This is great for diving into granular details of supporting that portion of the business, but it is awful for creating efficient processes and technology, without overlap.
I’ve heard countless tales of groups designing, and even developing, a solution only to find out that it already exists within the organization, or is being developed by another group in parallel. To avoid this, someone in the organization needs an enterprise-wide view of the technology roadmap.
This group should then influence the capital dollar allocation for each supporting IT group. This ensures there is no overlap in development, and one group can piggyback off another group’s development.
They can also plan several years in advance and be forward looking, constantly adjusting their plans based on the latest innovations. This practice has to be fluid, because today’s hypotheses for technology in three or five years, are typically inaccurate. But someone in the organization needs to be responsible for zooming out and not focusing on the day-to-day granularity.
Reward Good Solutions, Not Just Big Ones
Most groups in charge of technology have some reward system for the work they do. This is good, it plays into employees intrinsic need for reward and recognition, and provides something for employees to work towards.
However, these awards are typically polluted by politics and the size of the solution. They are awarded to solutions that involved a large number of people, instead of ones that were successful.
This isn’t to say that large solutions cannot be successful, of course they can. And when they are, they should receive reward and recognition. However, too often the litmus test for receiving an award is the size of the solution and the group that worked on it.
Instead, consider smaller solutions that achieved their goals and objectives and solved their problem with great success, even if these solutions were only led by ten, five, or even one person. This will set the precedent that well thought out solutions that solve the problems they were designed to solve will receive reward and recognition.
In fact, rewarding a large group of people for a large project can actually have a negative impact on employee morale. When I was working in Corporate America, I was given two CIO Excellence Awards – the highest honor of the department. They were both for massive projects for which I had little impact. Of course I was grateful to receive the honor, but I felt there were several other smaller projects I worked on where I had a more meaningful impact.
Hire Problem Solvers, Not Just Subject Matter Experts
Conventional wisdom is to hire subject matter experts for certain roles. IT needs to focus on mobile technology, social media, and email marketing, so they hire people that are “experts” in those areas.
The problem with experts is that they come with natural biases. Their experience can oftentimes cloud their judgement of problems and solutions. This typically manifests itself in putting the solution before the problem; in other words, recommending a solution before the problem has been properly defined.
Problem Solvers, on the other hand, are chameleons, they can adapt to a variety of roles because they focus on problem definition and have a laser focus on solving the problem, with a neotenous view.
Of course there is still a place for subject matter experts, they should work alongside the problem solvers to find the correct solution and define the real problem, but organizations should build an army of problem solvers they can pull from when a new solution is needed.
Juggle Patience with Impatience
Regardless of the implementation of the above recommendations, it will all be for naught if there is not some cultural transformation in the organization. The culture needs to shift from immediate results and immediate gratification, to one of patience and understanding that the right solution takes time to design and implement.
However, you cannot wait forever, and there needs to be some sense of urgency when developing software. That is a fine line to walk, it is not easy to be patient and impatient at the same time; but it can be done. It all starts with setting realistic deadlines. Steve Jobs was famous for setting tight deadlines, but delaying launches until the product was perfect.
Jobs understood that deadlines were important for work to get done. Our brains are designed to work within the framework of challenges, and a directive and deadline provides just that – get “x” done within “y” timeframe. However, Jobs also understood that launching a subpar product was unacceptable and detrimental to Apple’s long-term success.
Long-term thinking is a culture shift by itself. The current mindset is the short-term gain is easy, but betting on the long-term is risky. But the truth is both are risky. Take for example the cell phone industry.
Carriers are designed to bank on short-term gains, they are prepared to nickel and dime customers at every turn, risking the long-term loyalty of those customers. Every time a decision is made to take the short-term gain, a long-term risk is taken.
Weighing the long-term with the short-term is vital. It takes patience, but it typically pays off in the end.
Veruca Salt was impatient, she wanted the golden goose and she wanted it now. Meanwhile, Charlie was patient and honest. He sought the long-term benefits instead of the short-term rush of revenge. He waited and was presented with a fantastic situation, ownership of the chocolate factory.
Patience reaps rewards, but it has to be juggled appropriately with the increased demands of the business world. That juggling act is no small feat.
But it pays much larger dividends than being a Veruca Salt.