During a recent conversation, a service provider equated our product to a "bullet." The implication is that 6th Sense can arm customers with information that can injure a relationship.
I was shocked.
I've heard our product described many ways, yet this was a first. I challenged his charge, and he explained that some customers simply don't understand how to use the data and will misinterpret.
Sadly service providers are driven by risk-mitigation -- not how to build a stronger long-term relationship with their customers. I discussed the importance of the truth in a previous post. Service providers need to treat their customer relationships like personal relationships, and trust is the cornerstone of all successful relationships.
I don't need you to be evil
In an early customer meeting, a manager declared, "I don't need this product to be evil." If a customer is searching for a reason to end a relationship, they will find it. They don't need 6th Sense. They don't need any other tool to do this. And the bigger question is "why is the customer unhappy?"
Service providers need to embrace transparency -- not simply market it. Transparency is scary but will ultimately lead to stronger relationships with customers. If a customer is unhappy, locate the source and eliminate it. If a customer is simply impossible to please or "evil", consider having a candid discussion or revisit whether the customer is the kind of customer you want.
Regardless, don't shoot us -- we're just reporting the truth.
A few months ago I sat down with Michael Nygard (
http://www.michaelnygard.com ), author of the Jolt Award winning book
Release It!. We discussed what developers should be aware of in the next year and the number one career tip he's like to pass onto you.
This is a Neal Ford quote that sums up so many software shops. We know we should be writing automated tests. We know that continuous integration is something we should run and keep clean. Peer code reviews? Uninterrupted work time? Check and check.
We know many, many practices we should use everyday. But we get caught up in the urgency of the moment. We fall into crisis management. Bug driven development. "Shut up and code!" becomes the unwritten rule of the shop. No one says that writing automated tests is bad, but everyone is constantly driven to add new features instead.
We confuse activity with progress.
Just because you're working hard doesn't mean you're heading in the right direction. It only means you're sweating. It takes a bit of time to step back and ensure you're headed in the right direction.
It's like driving to a meeting. It's an important meeting and you don't want to be late, so you drive as fast as you can without getting a ticket. You're running questionable yellow lights. Then at some point your spouse points out that the car is nearly out of gas and you've still got a long way to drive. Your response?
"We can't stop for gas. We're already running late."
It sounds dumb when we say it that way, doesn't it? Running out of gas takes far more time than re-fueling ever would. But that's how we develop software. We continue our mad dash and long hours until the team or project runs out of gas... and that's one of the big reasons 75% of all software projects fail.
Take the time to stop for gas. And even directions... (when's the last time you read a software book?). Call it stopping for gas or sharpening the axe... but do it! Tools like 6th Sense can be used to pick out practices for your team. So can a process coach, or a good talk at a conference.
If you focus too much on driving, you might not make it to your destination at all. Pull over and recharge.
Are you working on your Jack Nicholson? I hear far too many comments like this. Apparently others do as well.
"What will my customer think if they realize we only spend 50% of our day developing and spend the rest in email and other tools?" -- a common question from service providers
"You're better than average," I typically respond.
In the past 30 days here's the breakdown of tool usage in our development community:
- Web Browsers: 47%
- IDE/Editors: 16%
- Email: 14%
- Office: 9%
- IM: 6%
- ...rest...
So if your developers are spending a majority of their time outside of a development environment, they are normal.
True Transparency
True transparency is a scary concept especially when it's contrary to the status quo. Right now customers have very little visibility into the software development process. They've been living with "trust us -- it's 75% complete" for a very long time. Sometimes this is correct -- some times it is grossly inaccurate. Regardless, it is the way things are often done.
Maybe I'm naive, but I feel that customers / business folks can handle the truth. Of course, the truth needs to be accompanied with explanations and examples. I also believe that the truth could improve predictability in projects and vastly improve relationships.
Concern about customers learning the true is simply due to the lack of education. A key part of education is having the facts and metrics to back up assertions. Developers ( and development teams ) complain about scope creep all the time. It's definitely the top complaint I hear. Do the development teams ever graphically illustrate the time waste in scope creep? Do they have spreadsheets with the time ( and $$ ) lost? Sadly, they rarely do. Most would rather simply complain at the water cooler.
The Truth Hurts
I searched online on why it's hard to tell the truth and found a nice thread on it. However, in software development the truth doesn't necessarily hurt anyone, but I agree that folks often don't want to hear it. They want their software 2 weeks early, under-budget and bug-free.
Alas, this is usually unrealistic, so it's better to start telling the truth to appropriately set expectations which will lead to far less disappointment for everyone.
Data where you want it
I'm pleased to post a new video demonstrating how to mash-up 6th Sense data into Google Spreadsheets. Internally, we are proud Google Apps customers and have moved many of our spreadsheets online. We're excited by the opportunities presented by marrying our development data with our traditional spreadsheets.
This is just the first example of many to come on how we can bring our data to the places you want and need it. We hope you enjoy this capability.
Click Here for Video
