CF Webtools does more than 3000 hours of consulting every month. As you might imagine there launches, releases and deployments happening constantly. One thing we run into constantly is resistance to change. When users are confronted with a new screen, new functionality, or (especially) a new system there is always resistance. It can range from a mild teeth gritting to kicking and screaming depending on the depth of change. Developers and managers are often nonplussed by this resistance. In virtually every case developers see the changes they have made or the systems they have created as enhancements or improvements over the "old way of doing things." They usually see resistance as futile and self-defeating - not to mention a little absurd. I think this is one of the reason's that developers often have a negative view of end users who are not technical. They simply don't understand the dynamics at play because they are not thinking through the human dimensions.
Take a deep breath and listen to the muse - resistance to your improvements is not based on the quality, appeal, innovations or the time saving nature of your improvements. In other words, the fact that it's the greatest thing since your mother's apple cobbler is not going to make users like it or want it. See if this rings true for you. You are presenting a new system to stakeholders. Say you re-engineer the process for approving a manufacturer's wholesale orders. You create a slick application that interfaces with the companies ERP system. You add approval gates and requirements that must be met to move the process forward. The CEO is ecstatic. It used to take 2 weeks to get an orders done because so many folks had to sign off on the pricing and the deadlines. Now the request won't sit around in someone's inbox or on their desk. The system will move it forward and acquire the needed vetting and approvals. Decreasing the time it takes to get bulk orders approved improves cash flow and the bottom line.
Sales folks are unhappy about it however. Why? Doesn't it mean faster commissions, more time for sales? Well maybe, but what you will hear from them is "We have always done it this way." Let's call that the WHADIT Way. Now before you get all huffy and accuse them of intransigence you should look a little deeper. There's a good reason that folks fall back on the WHADIT Way and its Cousin the WNDIT Way (i.e. "We've never done it that way before"). Consider for a moment how regular users of a system differ in perspective from you. When you got your new IPhone it was a splendid day right? You spent hours noodling with it and figuring out all the bells and whistles. That's because as a developer or IT pro you are a technology adapter. Far from being intimidated by new systems, hardware, phones and devices, you embrace them and revel in learning how to make the most of them. It's not a trial for you to learn. Indeed it's only a minor investment for you. Why? Because your day is filled with climbing up to the cutting edge of technology. You are oriented toward the new.
Now let's talk about the broad masses that include everyone else. Yesterday my wife (who is not technical) was frustrated trying to send a picture from her iPhone. She has a 5s and she was sending via email to her own email inbox. She was doing this to get the picture from her phone to her computer. She would take a picture and when she wanted it on her computer she would forward it to herself, then check her email on her computer to pull it up. Because of some network issue or whatever the email would not leave her outbox. I said to her, "Use the synch cable and copy it directly." The fact that she could do this was news to her. Given one solution to getting a picture out of her phone, it did not occur to her that there might be several.
So here's the question. What is it about me (and you Muse reader) that is different from my wife Ann? Why did I have a ready solution? Is it just because I'm smarter? I can tell you that this is not the case (my wife is extremely smart and savvy). The answer is that I envision technical solutions to problems and I assume that such solutions exist because "that's what I would have done" if I was building a UI, a site or an interface. I knew that the cable would work of course, but let's suppose I did not know. I have no doubt I would simply assume that there was a way to connect and copy images off of my phone. Why? Because it "stands to reason" - not Ann's reason or a regular user's reason - a technology worker's reason.
But this is not the case for the majority of folks who have to use your system (unless you are building it for IT, in which case they will pick it apart long before you get to brag about it in a meeting). Most people can't make leaps and confident assumptions about what something should do or can do or ought to do. They are tethered to what they know. They have made a major investment in knowledge to get things done surrounding their job. This knowledge might be how to fill out forms or which requests should go first or who to contact to get prices changed or how to navigate a legacy menu. It will almost certainly include some knowledge that they feel makes them important and is a source of status.
This idea of status is one we often forget. Consider how your technical knowledge makes you feel about yourself. Doesn't it heighten your sense of worth at the workplace? When people stop by your desk to ask about their hard drive or printer you get exasperated but inside aren't you secretly gratified that they depend on you? Non technical users are not so different, they just have different realms of knowledge. The WHADIT Way is really a ritual that binds users together. The current process might be byzantine and require lots of hoops, but knowing how to get it done is part of the power invested in competent employees. Once that power resides in an automated system it no longer requires special knowledge.
So new systems very often have this downside - they diminish the sense of value that employees feel when doing their jobs because they take things out of their hands.
So the Muse always recommends to board room types that they take a different approach when implementing new systems. Here are the Muse tips for stakeholder buy-in.
Start with a sort of marketing strategy. Advertise the new system. Gather testimonials from pilot users. Put screen shots in the newsletter. Find a way to project a positive image for your new system prior to roll-out. This will make adoption easier and it will be harder to criticize.
Early on in the process of outlining the new system, engage your stakeholders and get their input. Make sure the system is not just solving problems that are seen by management. Get real input from users and solve their problems as well. If you get early engagement from the end users they will feel invested in the outcome and grease the skids at release.
CEO's and CIO's are famous for saying "They'll just have to live with it." This simply never works - at least not in the U.S. Here we value creativity and innovation. We are looking for thinking, energetic employees who solve problems, not automatons who do things by rote. Valuing creativity and innovation comes at a cost for the manager. He or she cannot afford to force feed employees a solution. When it's tried it is a matter of weeks before there are workarounds and alternate paths for tasks that circumvent the new system. Instead, managers must find a way to:
In reality user Buy-in is probably more important than the slickness or usefulness of the system itself. So for all you techies in my audience, have a care with those users. Remember who writes the checks in our world. Take time to help them out.
In my last post on this topic back in September, Phase II - The Clone Wars, I discussed the first phase of our business development. We talked about how I tried to duplicate my own skills and energies by hiring likeminded folks, and how this led to a lack of diversity and innovation. In this post we will pick up on some of the solutions to those issues. Let me say at the outset that some of these issues (founders syndrome for example) are systemic and require constant vigilance and an ongoing effort to resolve. After all, we didn't come up with this list overnight at Denny's and pop in the next morning with neat and tidy solutions to all of them. Some of the items on our list (the need for sales, the value of diversity, the importance of management, team building etc.) required some convincing and cajoling and even some hard knocks to move us in the right direction. But I can say that in spite of "peaks and valleys" (which was incidentally my nickname in high school) we are moving in the right direction. So let's talk about solutions for moving off of the clone model and to something more workable for a larger, team-oriented staff.
Read More
I was recently chastised by a twitter follower (a beat down in 140 characters or less) for starting series that I fail to finish. So I'm coming back to my "Journey" series to add to the CF Webtools story a bit. When last we met on the subject I spoke of the 3 attitudes you need to succeed in the consulting business:
Anyone who's ever been successful as a contractor and thought about expanding has thought to themselves, "If I only had 2 of me." Aside from the obvious stress it would put on my wife you would think that having 2 of the Muse would be exceedingly useful. But knowing me, I would doubtless be playing golf right now leaving me behind to do all this work. That's just like me. It would make me so angry I'd be beside myself. Still, the idea is compelling when you are starting out - so compelling that you think about it a great deal when contemplating that all important first hire.
Consulting businesses are often started by knowledge experts with little or no business experience. When expanding such a business the first choice is usually "more of the same". In my case since I worked a certain way, I geared all my documentation, proposals, and estimates to the skill set of the Muse. So what did I look for in my first hire? Muse II of course (same level of action with a weaker plot I guess). It made sense to expand the current way of doing business by simply gathering similar skill sets to myself and dividing the work up amongst them. My first hire (Jason Herbolsheimer who is now CF Webtools VP of development) was an energetic can-do programmer able to find creative solutions to difficult problems. He worked at a similar speed to my own and was (and still is) a terrific people person. It was a great fit. Suddenly we were able to do roughly twice the work as before. In fact, my first 3 hires where like that. They were proven CF developers who I had known previously. Two of them had worked with me at my previous Job. The 4 of us divided up our customers and simply worked them in the same manner that I had worked them when I was an individual contractor.
This approach reminds me of that moving company "2 men and a truck" (would that be a "Mac" truck?). My guess is they started out as 2 men... and a truck. When they decided to expand they were probably considered changing their name to 4 men and 2 trucks, then 6 men and 3 trucks. There's some magic to this approach. It actually works well in many cases - especially if you assemble the right folks. If your team members work well independently and have the right soft-skills (inner-directed, owning problems, eclectic skill set, customer driven etc.), it can work quite well. The 4 of us did fine and had a great time along the way. I know of 3 or 4 consulting companies who operate at this level and intentionally stay at this level. And why not? They make good money, have very low overhead, and the level of responsibility is less crushing. Still, if you plan to expand beyond a handful of developers, the "clone model" (not to be confused with cloning an actual model which my wife says is out of the question) comes with some penalties.
Read More
I was privileged to appear on a local radio show called "Success in Action" on Saturday March 25th). The host is popular local business Coach Jim Barger. He works for "Action Coach" - an organization with which I was unfamiliar. But I found his low key approach (devoid of the usual Rah-Rah marketing hype) refreshing, and he had many insightful comments for me both on and off the air. The show explores strategies for successful business growth. It was fun and exciting to be able to talk about where we have been and where we are going. Check it out.
As I mentioned in my last post, I'm starting a series about my journey in building a consulting company. It's my hope that a transparent look at some ups and downs of growing my company will benefit other aspiring business owners and generate discussion that we may all find useful. Now just to be clear, I am not covering tax laws, employment laws, accounting or incorporation. Get a good accountant and a good attorney - that's business 101 in my view. Outsourcing payroll and relying on an accountant will allow you to breathe easier and concentrate on other things (where your skills are no doubt of more use).
With that in mind let's start at the beginning with 3 hard earned attitudes that you will do well to settle in your mind as immutable. They are essential to your success. They aren't technical and they haven't changed since history began. If you don't have them, put your dream away until you do.
Read More
In 1995 after 9 years of pastoring I left the ministry. Why I left is a long story of a self-destructive man hitting rock bottom and almost drowning - but finding redemption and new life through faith, family and the love of God. We won't dive into that here, but it's pretty compelling stuff I have to tell you. Meanwhile, the Muse had no skills other than piano playing and public speaking (and a penchant for Greek and Hebrew). Oh... and I could type like a banshee. So while I was trying to figure out what to do with my career (and trying to hold my marriage together), I took assignments with a temp agency. I collated and typed and copied while I scratched my head wondering what the heck I was good for anymore.
At some point I was given an assignment working the night shift at a credit union. I watched batch jobs run on a big DEC Alpha/VMS mainframe. Reports came out on 2 big green bar track printers. I watched for errors, updated reports and answered the phone. I decided I kind of liked being around all this technical stuff. I also discovered I had a knack for troubleshooting terminals and modems and the like. I checked out a "dictionary of computer terms" from the library and read it cover to cover while sitting in the lonely data center at 3 am. One of the ways I learn is by simply increasing my vocabulary and making connections. Pretty soon I knew how to ask the right questions to gain more knowledge. I believe God had given me the skills I needed to "start over".
To make a long story short, I read a bunch of books and took tests to become an MCSE and ended up working for a fellow named Jay at DTN financial services. I supported infrastructure for our division - sales tools, news feeds, laptops and desktops. Jay saw potential in me and I loved making him look good. One day Jay came to me with a ColdFusion script he needed to run. And that's where our story begins.
Read More
I have been looking forward to Google Wave and I was excited to at last have my invite. I got signed up and imported my contact list and created a wave and then.... then.... well... in the words of the dinosaur in the animated movie Meet the Robinsons, "I've got tiny arms and a huge head... I'm not sure you thought this plan through very well." Ok, not the tiny arms part, but this whole invitation thing, while a neat way to create Internet buzz in the lighting world of social media, doesn't really lend itself to useful testing - at least not for a company.
Sure, I'm seeing a few folks in my contact list who have a wave account. They are mostly tech savvy developers. I know I could create a wave and collaborate with them. But what I really need is to be able to roll my company developers and select customers into a wave for testing. I'm not trying to chat about the weather or review movies. If I want to waste time I can Facebook or Twitter. Instead I'm trying to see if the new wave paradigm can enhance my current project management processes (maybe even supersede some of them). I sent out a passel of invites but I've yet to have any of them approved. I guess until I get the right folks on the inside I will sit here and wave to myself. If I ever do get a legitimate test going - and more importantly if I can figure out how to tie Wave into my tracking and billing system - I will make sure and post a full report.
As we have discussed in our earlier posts on the Business of Web Development inexperienced customers (ones who have never done an IT project) are often surprised at the cost associated with a project. This is partially the result of the reputation that the web has for being cheap. Customers look at services like godaddy.com for example, and they see that they can register and host a site for the cost of skipping a couple of frappuccinos a month. While this is true, it is really not the same as professional design and development services and high performing, scalable, redundant, mission critical hosting services.
In fact, if I could digress to hosting for a moment, customers often fail to see the cost benefit of a more complete "managed" hosting setup. They spend thousands on development and then try to save a few hundred dollars a year on hosting. Having settled on hosting "on the cheap" they often have to pay someone a high hourly rate to do things like troubleshoot an underperforming server or handle DNS settings or figure out their mail services for them, or (worst of all) alter their code to conform to a changing server environment - like when a host recently disabled createobject() on a server causing an application to fail for someone who is now our customer. Any savings they might have gained is eaten up in support costs and they are actually losing money on the deal. In the words of Jesus they "strain out a gnat and swallow a camel" (email me if you don't know exactly what that means - I'll enlighten you).
Of course when it comes to development costs there are other things that mystify customers. As we have discussed before, customers often only account for the visual "up-front" items of a web application. They see forms, lists, charts and displays when the reality is that the bulk of the work on many complicated projects goes into coding, revisions, Q/A and Project Management. Here are a few fallacies that range from the hair-brained to flights of fancy:
Read More