The Gift Of Negative Feedback

“Success is a lousy teacher. It seduces smart people into thinking they can’t lose.” – Bill Gates

One of the hardest things to do as a consultant is to admit I screwed up. After all, I’m brought in to solve problems that the client could not or would not address. I’m paid a lot of money (compared to employees, not hedgies). I have a reputation to uphold–that’s how I sell myself.

But, of course, I’m human, and make mistakes. One of the greatest gifts a client can give me is honest feedback on how I erred. It’s a gift because

  • I learn something
  • it takes the client’s time
  • it takes the client’s emotional energy
  • it would be so much easier for the client to just say nothing and not use me again

Did you catch that? Instead of the usual transaction which is trading my knowledge and time to the client for money, the client is giving me knowledge.

It’s precious.

But don’t think it’s easy!

I screwed up recently and was given the gift of negative feedback. My first instinct was to reach for the requirements, or review emails, or figure out some other way to prove to the client that I was not in the wrong.

But the simple fact is that, if the client isn’t satisfied, a consultant is not in the right (I’m leaving aside clients that you should fire). It’s easy for me to think I’m selling hours and knowledge, but what I’m really selling is satisfaction. I don’t want to take a red cent from someone who isn’t satisfied with my work.

So, I had to sit and breath, walk and think, and just generally process this gift. After having done so, I communicated with my client, re-iterated my goal of his satisfaction, and proposed a compromise on my invoice. He was happy with that and we went on to do another project. I’m hoping he’ll consider me for more work in the future, but even if he doesn’t, the lessons I learned were well worth the cost of the compromise.


Squid cache log configuration thoughts

I have found that debugging squid, the excellent web proxy, is difficult.

I believe this is for a number of reasons, but primarily because I’m a developer, and just want to get squid working. I’ve found that I do this with a lot of tasks that are required of the small independent developer with time pressures–CSS/UI development, database design, system administration. All these are things that can be done well by competent specialists, but my clients often don’t have the money to hire them, or time to find them, so they get me. What they get is not in depth CSS knowledge and in depth knowledge of the entire user interface problem domain, for example. Rather, clients get my ability to figure out the problem (based, to a large extent on internet knowledge and to a lesser extent on my deep understanding of web applications and how they should behave) and my tenacity to test and test again to ensure that corner cases are dealt with. It’s a tradeoff.

Regardless, squid is hard for me to debug, and I found this page which lists all the options for the cache.log debugging parameters useful. However, not all that useful–‘client side routines’, number 33, apparently includes squid ACL parsing. Rather, I’ve found the Squid FAQ to be the single most helpful document in terms of my understanding squid enough to ‘get things done’. However, this time I ended up viewing the access log of my http server, while deleting my browser cache multiple times, to confirm that caching was set up the way I thought I had configured it.

Technorati Tags: ,


IP Crash Course For Entrepreneurs

This past Wednesday, I went to an interesting talk sponsored by Silicon Flatirons (an organization worth knowing about). Jason Haislmaier gave the talk, and the subject was intellectual property (IP); it was titled ‘Intellectual Property “Crash Course” for Entrepreneurs’ and was packed! I got there 10 minutes late (parking on the CU campus is no fun at all) and sat in the back on a heater. Good thing the fire department didn’t come by, as I’m sure we were over capacity. (Incidentally, I heard about this via the Boulder Denver New Tech Meetup mailing list but it was also on the Colorado Startups Events calendar.)

Jason said the presentation and possibly a recording of it would be available, but I was unable to find it by looking around his blog or the Silicon Flatirons site. I took some notes, but his presentation, if and when it becomes available, will be a great introduction to what entrepreneurs need to know about IP. (Note that all mistakes herein are mine, and I am most definitely not a lawyer. Consult your friendly attorney for serious advice. I marked things I thought I remembered with a ‘?’.)

There are 4 kinds of IP: patents, which are ideas or inventions, trademarks, which are about branding, copyright, which deals with creative expression, and trade secrets, which is know how. The overall emphasis on his talk was that you may not need protection from one or any of these forms of property, but that you, as an entrepreneur should be aware of all of them and make a conscious choice to pursue or not to pursue them. Which makes a lot of sense to me! (Incidentally, he repeatedly mentioned that the US was different in IP than the rest of the world, in a lot of ways, so if you plan to do business internationally, you should definitely think about that sooner rather than later.)

Trade secrets are pretty much anything–data, methods, software, etc. The protection is dependent on keeping them secret. Jason was working with a $10-20 million company that had only one patent; its valuation was almost entirely based on trade secrets. NDAs and employment contracts are the front line of trade secrets. He emphasized that you need to read NDAs and think about how they affect you and your relationship with the NDA signer. In particular, you can’t expect a signer to forget everything they’ve learned after a relationship ends, but you can expect them to return all the tangible forms of information. NDAs should have remedies (injunctions). If the other side won’t sign an NDA, that’s fine, just don’t tell them anything that you wouldn’t want to see posted on the Internet.

Copyright is protection for an original work or authorship in a tangible form from which the work can be perceived, not an idea. Apparently, there was a famous case (Feist) which basically outlined the limits of copyright–anything more creative than the White Pages qualifies for copyright protection. There are five rights, which I didn’t note because I thought the presentation would be up. Copyright can be unregistered (just about anything–these notes and this blog post are unregistered copyright) or registered. Registering costs something, but means you can sue folks. Under the DMCA, the copyright owner no longer has to show infringement–the possibility of infringement is enough (?). There are safe harbors though, one of which is the service provider harbor(?). You have to register with the Library of Congress and take things down if notified, but if you are providing any service with user generated content, you should pursue this safe harbor.

Trademarks (or service marks) are about branding. They’re easier to file for than patents. Use in commerce generates rights. He had a great slide showing the protection levels of trademarks from the fantastic (Kodak, Exxon) to the arbitrary (Apple) to the suggestive to the descriptive (World Poker Tour) to the generic (aspirin, escalator). The more the trademark describes what it represents, the less protectable it is, and trademarks can be lost (as escalator was).

Patents–the big one! Patents are the right to excludes others from making, using and selling a new, useful and non-obvious invention. There are a number of reasons to patent–defensive, offensive, ego, source of revenue (a secondary market is developing for patents. Offensive patents are getting riskier recently (courts are narrowing down patent infringement). But, investors are starting to ask why patents weren’t filed, and “we didn’t think to do so” is a poor answer. The answer to the question “Is it patentable?” for almost any value of “it” is yes, but you need to think about why–the better question is “How relevant and valuable will a patent be for the business?”. Lack of knowledge or independent development is not a defense against patent infringement.

All in all, it was a lot of ground to cover. Jason did a good job making things very applicable to the audience he was talking to. It kinda sucks that you have to think about such things, when all you want to do is develop killer software. (Brian made an offhand comment about patents and long running servlets almost 4 years ago, incidentally.) As Jason said in closing, if you don’t have an intellectual property strategy, your competitors will give you one (and, I inferred, you probably won’t like that one very much).


Find (or found) a consulting support group

I work on my own most of the time, out of my house. This means that I have regular email and phone contact with other people, typically clients, but only occasional face to face time. This style of work suits me, though I have friends who say it drives them batty. I enjoy the short commute and the freedom to order my day as I see fit (as long as I deliver).

However, sometimes it’s nice to have contact with people who aren’t paying you money. Users groups (such as BJUG) and meetups (such as the New Tech Meetup) can be informative and through provoking, but the presentation focus makes it hard for me to connect with other people. What I’ve found works best is a small regular lunch group with other consultants.

At lunch, you can discuss business problems, sometimes related to people who aren’t paying you money, but should be. You can get referrals for professional services that you may need–accountants, lawyers, etc. The group can be a source of business for you, as well as a place you can find someone to refer clients to for projects beyond your expertise. I always find it interesting to hear what other people are doing: one of my favorite lunchtime activities is the ‘new project go around’, where everyone talks about what new project he or she is working on.

In short, gathering on a regular basis with a set of consultants who you know and trust can be very useful. I have found once a month works just right for me–we always have plenty to talk about. We have also met semi monthly, and that was alright too–a bit harder on the schedule. A group of 4-8 people is about the right size–less and you don’t get as much cross pollination, more and you start to lose track of people. If you can, try to have people from different parts of the technology world in the lunch. The group I belong to has development managers, UI folks, project managers, developers and designers. This means that if I have a problem to discuss, I can get a lot of different viewpoints.

How do you start such a consulting support group? I think the best way to do it is to pick a restaurant and time, and invite 10 colleagues that would find this type of networking both useful and geographically convenient. At the restaurant the first time, see if people are interested. If so, set up an email list, and pick future dates. Don’t try to pick a time to meet that always works for everyone–part of the reason to invite 10 or so people to start the group is so you have enough people for a good conversation when someone inevitably can’t make it.

My group wrote up some bylaws–the most important of which was that no clients would be invited, except with prior notice to the email list. The reason for that was to allow the sometimes frank discussion of issues. Other than that, just set up a recurring event in your calendars and ping the email list when the lunch is near. And let the discussion commence!


Is the tech contractor to salaried employee ratio a sign of the tech business cycle?

Nat Torkington seems to think so: “…when the clever contractors head for salaried positions then bad times are coming.” (The last paragraph is cut off due to an HTML error, but basically asks if a shortage of engineering talent affects this indicator in one way or another.)

It is a complicated problem because there are a lot of other factors influencing whether being a contractor or an employee is a better fit for a person’s situation: need for income stability, contacts in the industry, demand for a given skill set, even preference for new situations. Even so, it’d be interesting to look back and see what the ratio was over the last, say, 20 years.

I took a look at the BLS web site, but couldn’t find any reports delineating contract employees and salaried employees.
Via Infectious Greed.

Technorati Tags: ,



Business Process Crystallization

I’m in the process of helping a small business migrate an application that they use from Paradox back end to a PostgreSQL back end. The front end will remain written in Paradox. (There are a number of reasons for this–they’d like to have a more robust database, capable of handling more users. Also, Paradox is on the way out. A google search doesn’t turn up any pages from corel.com in the top 10. Ominous?)

I wrote this application a few years ago. Suffice it to say that I’ve learned a lot since then, and wish I could rectify a few mistakes. But that’s another post. What I’d really like to talk about now is how computer programs crystallize business processes.

Business processes are ‘how things get done.’ For instance, I write software and sell it. If I have a program to write, I specify the requirements, get the client to sign off on them (perhaps with some negotiation), design the program, code the program, test it, deploy it, make changes that the client wants, and maintain it. This is a business process, but it’s pretty fluid. If I need to get additional requirements specification after design, I can do that. Most business processes are fluid, with a few constraints. These constraints can be positive: I need to get client sign off (otherwise I won’t get paid). Or they can be negative: I can’t program .NET because I don’t have Visual Studio.NET, or I can’t program .NET because I don’t want to learn it.

Computerizing tasks can make processes much, much easier. Learning how to mail merge can save time when invoicing, or sending out those ever impressive holiday gift cards. But everything has its cost, and computerizing processes is no different. Processes become harder to change after a program has been written or installed to ‘help’ with them. For small businesses, such process engineering is doubly calcifying, because few folks have time to think about how to make things better (they’re running just as fast as they can to stay in place) and also because computer expertise is at a premium. (Realizing this is a fact and that folks will take a less technically excellent solution if it’s maintainable by normal people is what has helped MicroSoft make so much money. The good is the enemy of the best and if you can have a pretty good solution for one quarter of the price of a perfect solution, most folks will choose the first.)

So, what happens? People, being more flexible than computers, adjust themselves to the process, which, in a matter of months or years, may become obsolete. It may not do what they need it to do, or it may require them to do extra labor. However, because it is a known constraint and it isn’t worth the investment to change, it remains. I’ve seen cruft in computer programs (which one friend of mine once declared was nothing but condensed business knowledge), but I’m also starting to realize that cruft exists in businesses too. Of course, sweeping away business process cruft assumes the same risks as getting rid of code cruft. There are costs to getting rid of the unneeded processes, and the cost of finding the problems, fixing them, documenting them, and training employees on the new ones, may exceed the cost of just putting up with them.

“A computer lets you make more mistakes faster than any invention in human history – with the possible exceptions of handguns and tequila.” -Mitch Ratcliffe, Technology Review, April 1992

A computer, for the virtue of being able to instantaneously recall and process vast amounts of data, also crystallizes business processes, making it harder to change them. In additional to letting you make mistakes quickly, it also forces you to let mistakes stand uncorrected.



© Moore Consulting, 2003-2017 +