“The Boy Who Cried Wolf” is a classic tale of what happens when a person lies too much. Another classic tale in the technology space is “We have a big demo next week and we need to demo this new feature.” The new feature is always the thing that will clinch the deal and so development works late nights and weekends to churn out something that can be shown. How many times can it be said that a new feature will clinch a sale before people ask the question about the validity of the old features. If the old features were so critical too then why is it that customers don’t see them as compelling enough? How long before engineers and managers simply groan at the cry of wolf?

The notion that one feature can close a sale alone appears silly at first blush. How can a single feature be so critical to closing a sale? Small software companies can sometimes have as little as five or six customers, each worth several hundred thousand over a million dollars in annual revenue. These kinds of software companies often have a hybrid product and services business model where there is a core product and customization or consulting being added to the offering. This model is not very unusual and you’ll find them everywhere. Some of them work on outsourcing product development for companies that need software to supplement existing products, like text book publishers.

The small number of customers and the need for consulting or customization services requires that you are more attentive to the way the customer works from day to day. First, you have a small number of customers that are each worth a lot of money. Losing one means losing a lot of revenue. Lost revenue sometimes means little more than a leaner year or losing a couple employees. Clearly, its better to have a happy customer.

Second, keeping focused on the day to day work of a customer means that you have to keep the product focused on the customer and less on what you want. Every shop has a few pet features that seem like they will expand the customer base. These pet features are important. It’s also important to keep the customer happy and build the features they are looking for. The balancing act is to keep the product moving forward while satisfying the needs of the current customer base. That’s not as easy as it sounds if the customer is worth a lot of money, they can bully you around, especially if there are competitors.

This is where the sometimes frantic meetings of “we need this feature for a demo next week” come into play. You may be trying to expand your existing business with a customer or just solidify your position in a space that has competitors. The need for getting a feature into the product that really improves the relationship with the customer can be terribly valuable and is something to always explore.

Developers don’t always like these features and there is plenty of reason not to. Ad hoc features almost always sound easy to implement, it could seem like you just need to add a button here and a tree control there and suddenly you have a new way of organizing content in your CMS. The developer sits there and promptly reminds you that you have to build the back-end to support the new structure, tie it into security, test it across three browsers, make bug fixes and test other components to be sure there are no side effects. Once the education of what is involved sinks in you find yourself with the too common problem that the demo is a week away and the feature solves a huge problem for the customer but it’ll take two or three weeks to implement. Clearly, you are going to rally the engineers together and get it done by working nights and weekends.

This wolf cry is pretty common and people groan into action. They dutifully work until the feature is implemented, tested and done. The problem is that some companies have a steady flow of ad hoc features and meet heavy competition. They cry wolf every month and it takes a toll on engineering. So what is a developer or a manager to do?

Let’s start with the manager. The goal is to complete the feature on-time and meet quality expectations. You can cancel a weekend and vacations and deal with upset developers. There is a risk though in wolf-crying companies and that’s if the cry is made every couple of weeks. Canceling a weekend or a vacation on a team of singles may be tolerated with only mild grumbling.

People with families don’t always have the luxury of being able to cancel weekend activities or vacations. They may not even be able to work very late on a regular basis. They are also usually the most experienced developers on the team as they are often a bit older and in the industry longer. Keeping these people away from their families too long usually results in their families wanting the developer to find a new job somewhere more family friendly.

Some managers may argue that this is the life that developers signed-up for. That these developers are just being wimps and their families should know better. Family support is widely believed to be a critical factor in entrepreneurial activities. You can start a successful business alone too, but if you are married and your spouse is mad that you are always gone then you are pretty much doomed to divorce, quitting or going through some very troubling years. Developers solve problems and so pressure from work and at home will lead the developer to resolve the issue by finding a new job which eliminates the pressure at home and at work, and maybe gets a raise too. Sure, a manager can say the developer was just not cut out for the field, but then again, the developer is happy and the manager has to hire someone and is upset that the developer left. Who got the better deal in that scenario?

Other managers understand that software development is a marathon with sprints. The on-going features have to be developed and released while the ad hoc features have to be slipped in and released faster. Ways of accomplishing this are varied. One way is to divide development into two teams where the first team acts as customization services while a core team pushes the product forward. Larger companies with bigger development teams can do this as they have the staff and money. There may be very little weekend work because the staffing level is correct for the amount of customization.

A second method that works for smaller companies is to rotate developers into the ad hoc features. The goal being that a developer should not have to be actively implementing consecutive ad hoc feature cycles. This is not to preclude designs and reviews, just the hands-on work of implementation and debugging. The idea is to keep developers feeling important, which they are, and to alleviate the constant pressure of having to perform at peak levels for months on end.

Some managers also believe that the entire team should be present during crunches. The idea is that if two or more people have to work the weekend then everyone should be in the office too. This is usually an unwise idea as it can quickly breed animosity toward managers and the teammates that actually need to work the weekend. There is a belief that developers and engineers crave justice a little more than other occupations. It may be viewed as fair to have people behind on their tasks come into work on a weekend, provided that the schedule is actually reasonable. However, bringing in everyone is immediately unfair to the people that are hitting their milestones. Better to bring in the people that need to be there and no one else.

Developers, on the other hand, handle these sprints in a number of different ways. Some come in at the crack of dawn and others work into the late night to avoid the loss of a weekend or a vacation. Some login from home after having dinner with the family. Others show up on the weekend dutifully because they need to. How many days, nights and weekends they do this is a function of family and benefits.

There is cost for everything. You could put a dollar amount on every hour of the day and use that as a reference for the value of that hour and compare that to what you earn. Money lets you “buy back” time by getting laundry, cleaning and lawn services to free up more of weekend time. Of course, not everyone can afford to buy services, they are stuck with work gobbling up personal time and no way to adjust the way their limited free time is used. It can quickly become the case that the free time is more valuable than the work time. That the money brought in by working becomes so offset by the lack of free time that the developer leaves. Constant sprinting, or constant development crunches, almost push developers out the door.

Some developers stick with it though. They have hope that things will get better. They also may like the team a lot and want to see their friends. Some have also come to realize that certain kinds of companies are sprinting all the time and the developer enjoys it. A similar group of developers that believe that their stock options will make it all worth while too.

Yet another group of “stick with it” developers are more fatalistic. They believe that all companies are miserable and they work there because no place is any better. They will not move on even if the company mandates them to work 12 hours a day seven days a week. They are the same guys that say a sunny day is too bright, that a great meal wasn’t worth the money, that a ten minute drive from home to work is a “commute”, that puppies are born to die, etc.

There is a very self-destructive kind of developer that may choose to try to get back at the company by promising to work the weekend but then chooses not to do it. You’ve probably worked with one of these developers. They have the attitude of “screw the company, I’m not paid for this.” They may have this attitude about working late, doing testing or doing anything that is marginally outside of their job. They feel like the company is sticking it to them every day of the week.

They may say that they are going to work on the weekend but they don’t do anything and then brag to their friends about it. The problem is that people are waiting on the developer’s work and his catchup time may lead to having to work the following weekend. Their attitude puts development at risk as well as risking valuable customers. This can create a great deal of tension.

The “screw’em” attitude is a very odd one too. If the company is so bad then these people should be the first to move on. However, you’ve probably worked with a few that have been there for years on end. They say they hate the job but they actually need someone else to leave before they have the courage to do it themselves.

Finally, there is you. You have the common sense to try to balance work and personal life and to find solutions when they are in conflict. Most managers are good people and will work with you to figure out a schedule that works. That is where the small company shines: they are often more flexible with how people schedule their days.

I was talking to a VP of Engineering one day about balancing personal and work life. He had some interesting comments about how one’s salary eventually grows to a point where the company is really buying more personal time. That once you hit the top 1% for your area’s salary that you are now being paid beyond the usual work week. He also told an interesting personal story. He said that he worked at a startup as a VP of Engineering which required tremendous hours, entire weekends and late nights every day kind of affair. Monetarily the job worked out as the company succeeded and had an excellent exit. Personally it was a disaster as his wife left him. He got married again but felt his first marriage was a tragedy that he could have avoided by shifting his values.

Sometimes the cry of wolf is just a lie too. I worked for a company that decided totest the team by creating a fictitious emergency opportunity that required an entirely new product based on a common core within two months. It was supposed to prove that the professional services group really was whining about the core product. However, it turned out that the core team could not accomplish the task because the professional services team was correct, the core product was not designed for rapid customization. The test was only known to 3 managers. The effect was that the team struggled for nothing and that was found out at the end of the project. Many of the developers quit or transferred out of core within a year. While core was no longer packed with old guard developers, it was also without any experienced in developing that code anymore. The lie was demoralizing and the company suffered.

Crying wolf every month clearly has some very negative aspects and working in one of those companies is challenging. The first challenge is understanding that these cries are often genuine and are meaningful. The second challenge is to ensure that work and family life stay balanced. The third challenge is to never lie about the importance of a feature to a customer. Balancing these sounds like a difficult job and it is, you may have to work a weekend or two to figure out the answers though.