ColdFusion Muse

Business Referral - don't forget

A week ago, in my post, The Muse Has Cash... I started a new program to reward community members for leads. Thank you for all the input and for the many leads generated already. We really appreciate it and we'll make you proud! After a quarter or so I will report on the success of the program.

Meanwhile, a few have pointed out that the previous post is lengthy so I wanted to put up the "express checkout" version. It's simple, if you refer a lead to us (email cfleads@cfwebtools.com) that results in new business, we will pay back to you 8% of the gross revenue from that customer in the first 10 months of working with the customer. If the customer spends 10k with us, you make $800.00. Simple and easy. So hook the Muse up. We are looking for another record year!

Note: In the past the Muse has offered bonuses for referring developers to us. This program is for new business, not developers - although as always if you are looking for work send me your resume. We typically hire several times a year.

The Muse has Cash and He's Not Afraid to Use It!

The hardest thing about running a ColdFusion development shop is getting in front of the people who might need your help. Thousands of companies could use the expertise we offer but it can be very difficult to approach them. In spite of our culture, our transparency, our chameleon-like flexibility, our unique reputation, our high competency and our focus on communication and productivity, CTO's and CIO's tend to lump CF Webtools in with the outsourcing crowd. That's just not who we are. The truth is, once we gain the ear of someone who needs us we have an amazing record at closing the deal and retaining the customer. We alleviate the pitfalls of ColdFusion (oh yes, there are pitfalls) and allow the benefits to shine. We simply bring too much to the table to ignore.

So that's the Gordian knot the Muse has been trying to unravel for the last 18 months or so as we have doubled and tripled in size. How do I get the name and reputation of my fantastic company in front of the folks who need us? I mean, besides a holocaust cloak ("...Then why wasn't it listed among our assets?") what do we have to work with? My executive team and I have spent a few weeks mulling this over and we have concluded that perhaps our greatest asset is our connection with developers within the ColdFusion Community.

The truth is that when a developer who has developed for a decision maker recommends us to that individual he or she is far more likely to listen and take our pitch seriously. After all, finding good ColdFusion talent is difficult. In our experience it is referrals that seal the deal. We began thinking, both the Muse and the CF Webtools staff tends to be engaged in user groups, forums, lists, and events focused on ColdFusion. Instead of dedicating a big chunk of money to a marketing budget (of dubious return) we had an epiphany. Why spend money on promotions and ads when the connection we need is right in front of our cfnose. Let's pay our friends in the community for their referrals.

The Big Plan

So our big plan is simple, we are going to generously reward any developer who refers a company to us that subsequently becomes a customer. The rules are simple. First, you need to be a part of the ColdFusion developer community. We are not looking to line the pockets of recruiters. But if you are in IT and work with ColdFusion you are a candidate. Finally your lead must result in a sale for you to get paid. In short, for forwarding a name to us you could get a check in the mail - that's it! Read on for the nitty gritty details.

[More]

Resistance is not Futile: Why Change is so Hard

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.

Great New Systems Still Face Resistance

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.

Campaign

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.

Engage Early

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.

No Implementation By Fiat

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:

  • Insure that all voices at the table are heard.
  • Find ways to alleviate concerns by stakeholders and users - and do it in a way that makes it clear you are investing in those concerns because of the input given by those individuals. In other words, they have to feel empowered to make a difference in the solution.
  • When changes in responsibility are needed due to automation, find ways to organize responsibilities, titles and job descriptions to take the sting out. For example, if your customer service manager can no longer approve an RMA without a new gate, give them the ability to provide free shipping or incentivize staff in some other fashion. The idea here is to provide for a lateral move with regard to status and responsibility.

Conclusion

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.

The Journey: Winning the Clone Wars Part 1

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.

[More]

The Journey: Phase II - The Clone Wars

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:

  • Work Hard and Be Patient
  • Be a People Person First
  • Avoid Perfection Paralysis and Do What You Can Do
With those thoughts in mind I'd like to talk about Phase One of your consulting business - building Clones.

More of Me

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.

[More]

The Muse on the Radio

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.

The Journey: Three Attitudes to Sustain Your Dream

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.

[More]

How I started in ColdFusion

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.

[More]

Google Wave: Real Testing Delayed by Marketing Ploy

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.

Estimating Part 3: Explaining the Costs to Customers

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:

[More]

Estimating Part 2: Quality, Quantity and Visual Blinders

In our first post on this topic, Red Lobster Eyes With a Happy Meal Wallet, we began the discussion of the difficulty involved in estimating projects for startup companies. We took the time to chat about the nature of the bright people with big ideas who choose to try something new on the Internet. Our main point was that Big Idea people often underestimate the time and money it takes to complete a project. Today we will talk about one of the principle pitfalls that arise in reaction to lack of resources.

[More]

Red Lobster Eyes With a Happy Meal Wallet

If you have read my post, Great Expectations, you know that I spend a good percentage of my time helping entrepreneurs outline requirements for brilliant new ideas as well as helping them figure out the cost. I am the "chief estimator" at my growing company. Creating an accurate Estimate is an extremely important part of running a company like CF Webtools - a large project can affect our profitability (or lack thereof) for the entire year. My goal in estimating is to charge enough to pay for the development - salaries, expenses and infrastructure - and of course to make a profit. A second, equally important goal, is to give the project its best chance for success for the customer.

In the next 2 posts we will take a look at the dynamics of this task and in particular the importance of managing the relationship between the customer and the developer or development company. But let's start with the role of the development company - or in my case, my role in particular.

[More]

Great Expectations: What Make's Money on the WEb

About two or three times per month I am presented with an idea from a visionary business person who wants to start something new. Some of these ideas are unique and some are not. Many of them involve a web based application or service that the individual wants to sell. Whether it's an actual product, information, or a service of some kind, this person has convinced themselves that the idea has the potential to become a thriving and profitable business. They come to me for general advice and possibly, to see if CF Webtools would like to develop the product for them.

In some cases they are underfunded and they ask if we would take an equity stake in the venture in lieu of some or all of our development fee. I have declined to do so up to this point - mostly because we need projects that are profitable and funded to meet our own business goals, and any capital we want to risk we tend to use to expand CF Webtools. In any case, all of these ideas have something in common. An individual or group of individuals believe they can leverage the web to make a pile of money.

Now let me say at the outset that I am sometimes amazed at the ideas that end up succeeding. CF Webtools has built a few crack-pot applications that we felt had no chance of success, only to see them take off and exceed expectations right out of the gate. On the other hand we have seen some applications that we thought were startlingly innovative die with a whimper. Still, there are some hard earned lessons that we try to share with our customers to give them the best shot at success.

So this series is designed to help consulting companies or independent contractors better assist their clients in making good choices. It is also an excellent read if you are one of those visionaries and would like to know exactly what you should focus on to get your idea off of the ground. Unless you are a follower of motivational speakers Anthony Anthony (If You Can Do It Any Idiot Can) or Walter Mollusk (Seize the Self-Help Book of the Day), you will know intuitively that there is no one formula for success. But there are some obstacles you would do well to avoid.

Listen Here

[More]




Blog provided and hosted by CF Webtools. Blog Sofware by Ray Camden.