Superheroes are not real!

posted by ryan on June 29th, 2007

Time & money, traditionally these are the two biggest areas of conflict between client and developers. The reality is that with a little planning and instinct these problems don’t have to be yours alone.

Remember, when you are doing work for customers you don’t own the budget or the timeline, they do, so you should never be the only one making choices about them.

Stage 1: Planning The beginning of a relationship its great, butterflies, the promise of money, the feeling of accomplishment and start of something grand. These feelings along with money troubles and developer desperation often are the root of under estimated budgets and irresponsible timelines.

This is where sense-memory comes in. When I put together a budget and timeline I try to take myself back to special place that I call “the last week of my most challenging project”. I have several of these moments. It’s the time when you realized that you underestimated the money and time and now are up against the wall, + your customer is questioning every hour and is late paying their bill. Now if they asked me for another big chunk of work how would I estimate it.

When you put you self in that place you make much more realistic and prudent choices about how long and involved things will be and thus end up with budgets you can meet and timelines that won’t force you to spend all night working.

Ok now that we have a good budget an timeline what happens when things change or we are just plain wrong.

Stage 2: Listen to your inner [your name here] We have all had those moments where look at the what’s left to do and the deadline date and think, this is not gonna be easy. The problem is we usually ignore the voice until we have a week left and a dribble of hours in the kitty by which point a BIG conflict is inevitable.

Invent a crisis and invent it early. Crisis can be very positive as long as it’s small. When you have 8 weeks left and tell a client the timeline won’t work they have time to make some hard choices if they want to make the date. They can remove features, increase the budget, bring in other resources. The key is to allow them to have the time and remaining budget to make their own choices.

The only way to have a successful customer relationship is to have them deeply invested in all the key choices of the project. At the end of the day it’s their product.

Again this is why you need to have client contact every billable day. The second you feel the timeline/budget is not enough you need to deal with it.

If you look a project that had issues you can always remember the first moment your know things were not right as well as the moment much later when you voiced your concerns.

Don’t be a super-hero, they are fictional.

First Impressions

posted by ryan on June 26th, 2007

A key thing I have learned with meetings is you need to know your outcome before the meeting starts. This is especially important the first time you meet a potential customer. What does a successful outcome mean? I think a lot of time we tend to wing things and end out wasting hours of time talking about unnecessary items and trying to make points that are not relevant to the matter at hand.

My outcome when I first meet a client is to learn as much about their business in the shortest amount of time possible. I try not to talk about our business or technology unless repeatedly prompted, but instead focus on listening to them. When you are a small consulting shop picking a great client/project is the most important thing you do and the only way to accomplish that is by sublimating your ego and immersing yourself in their world for 45min to an hour.

The next time you leave a 2 hour meeting, ask your self how much of that was you talking, you leading and how much much was you listening. You will find that you could have halved the time by staying quiet.

A big goal for me is to ask lots of questions and avoid making statements as much as possible.

Avoid negative absolutes like “We don’t, I never, that doesn’t, we can’t” and instead use your experience as a guide “We tend not to, We don’t often recommend”.

I don’t expect to make a sale in the first meeting, wow them with our past work or give them a rundown of our business process. If it naturally happens or they ask I am more than willing to go though it. My only outcome in the first meeting is to decide in my head whether or not this is a client or project that I want to work on.

The first meeting also sets the tone for the project and that tone becomes part of the choice to take the work. You should all look forward to a client coming in the door, if you don’t you should take a hard look at whether you should be doing the project.

There are other elements that make up a great project (reasonable budget, responsible timeline, domain knowledge and business experience) but at the end of the day if you don’t look forward to spending hours and hours of time with them the rest doesn’t really matter.

You can’t get caught up in trying to pay your bills because one bad client will cost more in time and stress than 5 good clients.

At Unspace 12% of our customers account for over 50% of revenue.

That forced us to spend more time picking the next great customer as opposed to pitching our services and in the long run made our cash flow stable and our developers happier.

Reading is not listening

posted by ryan on June 24th, 2007

At the end of the day every great relationship requires great listening skills. When you sit down with a customer face-to-face the listening in inherent in the setting. The challenge comes with email as the sender has no idea you are listening unless you answer. I am going to use Hampton as a sample case :)

From John @12:00 --------------------------------------------------- Morning Gents,We're working on a potential deal with ####, but find ourselves facing a technical challenge.... In terms of resolving this issue, a potential option might be to... What are your thoughts in terms of level of difficulty and time to execute? Thanks, J. --------------------------------------------------------- From Hampton @12:45 ---------------------------------------------------- Hrrrm... I'd have to think about that. I wouldn't have a different URL... it would be the same page... and it would just look different. It would probably take about ... Basically what I'd have to do is ... However, once that's done once, its much easier to ... -hampton. --------------------------------------------------------

So in an ideal world that's great response right? If you only have one customer than yes, but most of us have several customers that rely on our expertise. As a developer you often do you best work when you are un-interrupted and you need to make sure the constant client emails and calls don't interfere with your development work. On the flip side when you don't respond your customer has no way to know that you have heard their request. I suggest:

From John @12:00 --------------------------------------------------- Morning Gents, We're working on a potential deal with ###, but find ourselves facing a technical challenge.... In terms of resolving this issue, a potential option might be to... What are your thoughts in terms of level of difficulty and time to execute? Thanks, J. --------------------------------------------------------- From Hampton @12:45 ---------------------------------------------------- Hi John, I got the email, that's an interesting challenge. I will gather my thoughts on it and get some numbers/possibilities to you tomorrow afternoon by 3:00pm. -hampton. --------------------------------------------------------

In the first example Hampton sets a high expectation, that if John needs an estimate he can get it in 45min. This impresses John for now, but the next time when it takes 24 hours to get numbers because Hampton is on a crunch for another customer John won't understand why and will start getting annoyed. He will always expect that speed and anything less will feel sub-par. There is no way to sustain that expectation. Also Hampton dropped everything and thought about the problem and how to solve it. That means whatever work he was doing suffered the loss of focus. My suggestions means you scan the email to make sure it's not an emergency, quickly respond so they know you are LISTENING and schedule time to address the issue in the future. This is where an application like Highrise is really helpful. You can reply to John and then fwd the email to your Highrise tomorrow box then archive it. This will help keep your customers happy, and keep you sane.

Why support is so important

posted by ryan on June 21st, 2007

In most software scenarios support is seen as a second tier process, generally assigned to second tier resources. As a small company without a second tier team, support often becomes a non-priority as developers much prefer building solutions over supporting customers.

I believe support should be a priority one task for any company especially if you are small. Small shops rely almost exclusively on referral and word of mouth for business which means you need a constant set of happy and contented customers.

What makes support seem hard to do?

• Requires strong social interaction skills
• Means to need to think like your customer
• Patience
• Distracts you from other development tasks

What good support gives you

Long and fulfilling customer relationships

While @ M7/Unspace I was often invited to customers office Xmas parties, employee going away parties and would always be the only contractor present. Before I left customers had going away parties for me, can you imagine that!

A built in sales team

When you have strong support you stand out from every other experience customers have had with technology. They tell everyone they know how great you are. And it's not the VP's that matter, many of our referrals came from receptionists, office admin staff and assistants. Plus many of our new customers have come from when an employee from an old customer changes companies and upon arriving at their new employer wants to bring us along as well.

Better Software

What better way to know what users need that by supporting them. It's the doorway that lets you into their office lives and connects you to their business.

So how can you give strong support and still have time to build great software?

Support Lessons Learned #1

At M7/Unspace we had a great take on the development cycle. There are many more reasons for the following approach but I will start with support. The following samples are for compare and contrast purposes only.

Traditional

The most powerful outcome of support is that by connecting you to the customer it bring our new and creative ideas about what the software needs to do. Most often these "wow" ideas only come when the software is actually being used, which in this case means it's much too late to change it. Again support an app built this way would be tedious since all you could do is say, maybe next version.

Agile (Not any particular methodology)

This is getting better, now we have integrated the support, testing and launches into the process thereby integrating a better feedback cycle and actually being able to take new customer needs into account. There is still one problem, customers are busy doing their jobs so with this pace there is not space for them to provide quality feedback and have the time to reflect needed.

M7/Unspace

By combining an agile style with a staggered schedule we give the project some breathing room, this means customers will have the time to test things out well and give their feedback early which results in software that not only have less bugs but required much less support because most issues have been resolved before the project finished. This method has allowed M7/Unspace to not have to write detailed manuals, run long training sessions or maintain onerousness FAQ's as the core users have been using the system for months before it's finished.

The Rise and Fall of the Rails Contract Labor Market

posted by pete on June 19th, 2007

Dan Grigsby has posted the result of his ongoing observations about the long term employment/adoption trends seen in the Rails world:

My hypothesis is that the rate for undifferentiated Rails labor probably peaked six to nine months ago – marking the entrance to the third phase – and has been on a downward slide since then.

Read the article here and if you like it, feel free to vote it up on Reddit:

Dan says some really nice things about us, but to be up front, that’s not why you’re reading this here.

Javascript is not widely understood.

posted by pete on June 13th, 2007

The spectacular Dan Grigsby is visiting Toronto from Minneapolis/St. Paul this week. Dan is one of those mavericks that really sees beauty in code, and I learn tons from him by osmosis.

I was giving him a quick overview of how the Prototype library “extends” objects to include new functionality. It’s simultaineously an elegant hack, and boils down to the basic idea that complex objects are nothing more than name: value pairs, where the values happen to be anonymous functions.

The typical best practice when Javascripting is to use the Object.attribute or Object.method() syntax:

location.hash = 'bob'
location.hash #=> bob

window.alert('jim')

Dan took one look at the syntax and speculated that one could possibly address attributes or methods by calling them as if they were a named array, like so:

location['hash'] = 'alex'
location['hash] #=> alex
window['alert']('jim')

It makes complete sense, now. It’s perhaps a more explicit, “pure” syntax in the CompSci sense. I love that the lookup doesn’t differentiate between say, a String and a Function(). It still requires at least an empty () if it is a function, too. I’ve never seen this syntax referred to, but perhaps I wasn’t looking.

From a practical standpoint, I still prefer my Ruby-like syntax, but I feel like this little gem of insight maybe leveled me up, if you will. Perhaps you will enjoy a similar Aha! moment.

Haml on the Horizon

posted by pete on June 11th, 2007

Jim Weirich, the creator of rake, just posted an interview with Bruce Tate, who is one of the most high-profile converts from Java to Ruby.

In the interview, he makes reference to Haml in a flattering light:

“You can easily imagine one of the HAML-like languages putting a dent in HTML.”

Now, what’s most interesting to me about this is that Bruce has essentially named a class of languages after Haml, and that’s quite the honour for a markup syntax that has yet to be adopted by more than one platform, even if a PHP version is in the works.

Hampton and Nathan are clearly on the right track. Thanks to Geoffrey Grosenback for the hot tip!