Quiet Work and Make Work

One of my first tasks at my new job was to set up source control and a test server for the client. Previously, the client had relied on their development company’s servers to provide this, but with their new approach of bringing all the development in-house, it was necessary to create these environments.

The creation of these servers, however, is not particularly satisfying work. It involved buying the appropriate hardware, installing some software, and configuring a few scripts. As the only developer currently working on the system, there was limited satisfaction in completing the tasks – there was no other person who would actually notice the work that I had done.

However, I did not find the work to be tedious, for the following reason – it was all necessary. A sign of a job well-done in this case is the fact that it was not noticed by anyone. The job satisfaction is in the fact that no one did, in fact, detect that I had done any work. At the same time, I had the realization that sometime in the future, others will be appreciative of my having done this work properly.

Contrast this with what has been termed make-work, where the purpose of the work is to keep people busy. The result of the work may be noticed by others, but it is neither necessary nor permanent. For example, a report might be requested in order to keep someone busy, but at the end of the day, the contents of the report may become quickly irrelevant. Additionally, it may be that the report itself is never read.

Assigning people to make-work is disrespectful to those asked to do it. While it keeps them busy, it also shows that there is little respect for the person’s skills and time. While people do like to be idle, they like even less to have their work disregarded, and to do work which they know will be disregarded.

If you find yourself assigning people to work for the sake of keeping them busy, you might be better off asking those same people what they would rather be doing – make-work, or to be left to their own devices until necessary work becomes available.

I Missed It

I just got back from a trip to Israel a few days ago. Knowing that my internet access while away would be limited, I wrote the articles to be published while I was away before leaving. Prepared for jet lag on my return, I also wrote a couple articles for the days after my return.

Today, as you may have noticed, this article was published about an hour late.

I’ve written before that one of the best things you can do for your site is to provide regular updates, and on a schedule. Since January 1, 2010, I’ve posted an article Monday through Friday at 7:45 AM Toronto time. Holiday? I posted anyhow.

I kept this aggressive schedule by always posting in advance, usually several days before the article would be made public. It took the pressure off.

Today, I ran out of articles. I was tired last night, and didn’t realize that there was nothing scheduled for today.

Keeping a schedule is one thing. Remembering to look at your schedule is quite another.

Time management techniques will talk about priorities, making lists of things to be done, of organizing your day, and of keeping a calendar. But if you don’t remember to look at those things constantly during the day, it won’t help you to have any of that.

Protecting Data

When it comes to data, most people are aware of the importance of protection – we are constantly reminded to select secure passwords, not to share them, to make them difficult to guess. But what about making sure the data doesn’t get lost?

I’m currently in the middle of setting up a development environment for my new client, and had to go through this exercise. It is just as important to ensure that the data continues to exist as it is to ensure that the wrong people cannot access it. Depending on the state of the project, in fact, this concern might be greater than preventing unauthorized access. For example, during initial development of any large application, it is critically important that regular backups be made. That way, when something changes so drastically that it negatively impacts the project, you still have the ability to go back to a previous version of the project.

This segregation of changes, and the ability to retrieve older versions of data, results in the following simplified structure (this is for a programmatic project in particular):

Production

This should be backed up as often as it changes – that is, the programs should be backed up whenever a change is made to the Production version, and the data should be backed up on a daily basis at a minimum.

Testing (Quality Assurance)

This environment is for the purpose of ensuring that the changes being made to the Production version are complete and stable – essentially, a last check before making the final push to production. As such, it may have minimal amounts of data, or at least, data which does not change frequently. A normal backup schedule here would be to create a version every time the programs are changed, and to back up the data at the same time.

Testing (Integration)

This environment is usually undergoing frequent changes, often several times per day. Backups of such environments should be done on a schedule, often daily. However, this can often be bypassed by merging the backups for this area with those being done for the source code for the project, as discussed below.

Development

This is the responsibility of the developers working on the project, and should generally be done as often as major changes are being made to the project. However, the discretion of the developers is usually sufficient to be relied upon, though this will often only be sufficient once the first loss of data occurs. We learn the hard way, but we do learn.

Source Control

No program should be developed without source control to ensure that versions of the project, especially when involving multiple developers, can be kept up to date across all developers. As well, this will usually be the means that versions of the program are being pushed to the different regions – developers start from what’s in the code repository, Testing (Integration) uses this as a basis, Testing (Quality Assurance) takes specific versions from here, as does Production. As a result, the code repository should be backed up at least once a day, as without this, in the event of a system loss, restoring all information becomes exceedingly difficult. Additionally, source control provides not only a view of what the code looked like at a particular point in time, but also how it changed over time, making the locating of bugs which are introduced a little easier to do.

Summary

It is only with a proper backup system that you can ensure that you are able not only to prevent a total data loss from occurring, but also that you are able to ensure that in the event of the loss, that you can restore your systems to the point immediately prior to the loss. Naturally, the backups need to be protected from unauthorized access, but it is the fact that they exist, preferably in a location distant from their origin, that ensures your business’ ability to continue its operations even when the unexpected happens.

All About the Product

With the growth of social media over the last few years, more companies are coming to the realization that creating a reputable business that attracts customers is about more than the product. There is now a demand for interaction – consumers want to know who they are dealing with, and they want to be treated as individuals.

That’s not to say, of course, the quality is no longer an issue. It’s just no longer the only issue.

In the past, the greatest issue a company had to deal with was the quality of their product at an affordable price. Businesses had to deliver results, but could be completely impersonal.

This has, perhaps, given rise to the Hollywood representation of bankers, doctors, and so on. We can envision such characters with impersonal stereotypes. Think about how, in Ocean’s Eleven, Brad Pitt impersonated a doctor, and yet, no attention was drawn to him because the profession was not a portrayed as a personal one.

This is no longer the case. A doctor will now find himself being researched on a site such as Rate MDs, similar sites exist for other professions (my latter years of university had courses selected only after vetting the instructors on Rate My Prof). Questions are bounced around cyberspace like a spastic reindeer on an ice rink getting feedback, not always factual, usually opinionated. However, the result of this is that businesses have been learning to address impressions as well as reality.

I recently had occasion to express this thought in a formal setting. One person’s perception must be treated as reality when discussing it with them. As an example, I might assume that Brand X is inferior in quality to Brand B. Whether or not this is true is not really relevant – to convince me to purchase Brand B, you must start by dealing with my own reality.

Being successful as a business is now about so much more than just the product – it’s about the experience of working with the company. It’s about perceptions, and about interactions. The sooner a business figures out this concept, the sooner they’ll be able to understand what it is their potential customers are looking for and provide it to them.

Promise to Deliver

I ordered Chinese food last week, and my fortune cookie read:

Only promise what you are sure you can deliver

Of course, this is common sense, but as with many of the articles on this site, that’s exactly what I discuss. After all, common sense isn’t all that common.

All too often, we are tempted to make a promise, because it will bring us something. In fact, for many small businesses, we grow because of it – we act like we’re bigger than we are, because it’s the only real way to get to the next level.

Often, however, we will discover that the promises made are beyond our ability to deliver. The motivator for the promise is no longer relevant, but delivering on that promise is.

You now have a choice – admit that the promise cannot be honored, and arrange an alternative. Or persevere, and figure out a way to deliver the expected result. At the same time, you must learn from the event as to what you can and cannot promise, so that you don’t end up in the same situation again. It is not uncommon to see someone who fails to deliver on a promise to do so repeatedly, since they have not learned from their earlier errors.

More importantly, you need to learn not to promise too much in the first place. You may want to act larger than you are to help grow your business, but there’s a fine line between acting bigger, and promising bigger.

As an example, I may be capable of delivering a product of comparable quality as a larger company, in the same amount of time. But I cannot, and do not, promise support 7 days a week, 24 hours a day because I cannot deliver on such a promise. In general, I try to understate my ability to deliver, which helps ensure that I do deliver on my promise, and can, on occasion, exceed the promised expectation.

How about you? Do you promise more, less, or exactly the same as what you can deliver?

Universal Imaging

In a recent article about my choice of photo for my online presence, I discussed the fact that one of the criteria I had for the image was that it be universal. I wanted something consistent between the various sites I’m on – that if someone is looking for me, they will always see the same picture.

This applies beyond just a photo of a person, though. It applies to the entire image of who and what you or your business are.

Your image, or brand, is that which will evoke the desired reaction from people. If you have a chain of coffee stores, for example, you will want to brand consistency (just look at Tim Hortons as an example of a really consistent cup of coffee). If you’re a tailor, you want to brand a perfect fit.

In your business, when choosing a brand, you need to look at both what you’re known for, and what you would like to be known for. Often, the two are not the same, but hopefully, neither is patently false about your business.

Once you’ve decided what those two ideas are, you need to create some sort of image that will help people recognize you (what you’re known for) and generate the reaction you’re looking for (what you want to be known for). The result of that is the image you need.

The other factor you need is an image that can be portrayed in a variety of media without significant deviation from a common theme. For example, an image that revolves around motion won’t make a good newspaper ad, while have lots of text in your image makes for something difficult to portray as a TV commercial.

Once you’ve selected your image, adapt it universally in your business, and give it a chance to provide feedback. An experiment with your image can take months before its effects are clear, so patience is a required factor here.

What do you consider to be your brand? How have you managed to get it portrayed in various media?

Making Mistakes

It is amazing how often people will make mistakes, and then continue along that path rather than admit their error and move forward. It happens to people in a variety of situations, for a variety of reasons. It happens in business, in politics, in personal situations. It is near universal.

As an example, in Ontario, the provincial tax, PST, is to be merged with the federal tax, GST, to create a new single tax, HST. The total tax is the sum of the two individual taxes. The idea behind the merge is that it would reduce the costs of administering the tax, thereby saving money without costing anyone more.

The flaw is that there are some items exempt from GST, but not PST, and vice versa. When the taxes merged, some of those items remained exempt, while others did not. Additionally, while in the long-run it might be more cost effective to have fewer taxes, there is a cost up front to convert systems over to the new tax rates.

However, despite people being quite vocal about the tax, and the fact that it would cost the end-consumer more, it was not until about 2 months before the tax took effect that the man behind the tax, Dalton McGuinty, admitted that it would, in fact, cost people more. At that point, he started talking about the personal sacrifice people would have to make (during possibly the worst recession in recent history). He held on to the false promise of saving money, until it just wouldn’t hold any longer.

This is typical of what happens when someone errs, and is not, as they say, man enough to admit the mistake.

I had a teacher in high school who would say it takes a big man to admit he made a mistake.

There’s nothing wrong with making a mistake, provided you have learned from the event. Admit the mistake, and improve yourself with it. Or continue to deny it, long after it’s clear that the mistake was made, and suffer the ignominy of the error.

What will you do the next time you realize you’ve made a mistake?

Quick Fixes

As I wrote yesterday, there’s nothing more permanent than a temporary solution. Yet, we continually come across situations where a temporary solution has made itself permanent, and we are left to deal with its after-effects. This article will be focusing on the reason we still employ such fixes, and when they are justifiable, or even preferred.

In a situation where a fix is needed, there are three ways to address the problem:

  1. Remedy the symptom and ignore the cause
  2. Remedy the cause and ignore the symptom
  3. Remedy both the cause and the symptom

Naturally, our first instinct would suggest that the third option is the ideal one – after all, the first two clearly ignore parts of the problem. However, there are times when any one of the three choices can be the correct one.

Remedy the Symptom

This solution would fit a scenario where the problem is unlikely to repeat itself, or remedying the symptom can resolve the problem temporarily. An example from IT is to reboot a system to deal with a program failure. While it fails to address why the program failed, it does fix the problem (the server being non-responsive) and potentially avoid the need to spend time researching the root cause.

If, however, the same symptom shows up repeatedly, further investigation into the cause would not only be recommended, but required practice in any large organization.

Remedy the Cause

This solution would be ideal for a situation in which trying to remedy the symptom itself might be an exercise in futility, or cannot be done until the cause has been identified and resolved. However, in this case, the symptom itself is being ignored temporarily, perhaps because its continued existence is providing information that can be used to resolve the cause.

Remedy Cause and Symptom

This solution often is the most time-consuming, because it requires both an understanding of what is causing the problem, as well as the impact of that problem. Trying to address both simultaneously can be complicated. Additionally, the solution for one might preclude a solution to the other (solving the symptom might make resolving the problem more difficult for the reason discussed in the previous section).

As a result, what often happens in this situation is what has been termed a quick fix whereby as much of the problem as possible is addressed, though not necessarily in an ideal manner. If this solution is sufficient, then that’s fine, but often the solution just stops there.

What must be remembered is that when employing a quick fix for a problem, care must be taken that it does, in fact, permanently solve the problem, or that a more complete solution be employed in the near future. A quick fix should always be considered temporary, and one should not wait until the issue is forced to replace it with something more complete and permanent.