Blogs, They're Not Just For Marketing Anymore
I was just reading a post on gapingvoid about how a corporate blog is just as much (if not more) about changing the inside of your organization as it is about communicating with your customers. His line about making the membrane between the market and your company more porous and thus make it "easier it is for the internal conversation to inform and align with the external conversation" seems particularly insightful to me. As does the observation that "poking holes in membranes subverts hierarchies." A good thing in my eyes.
In software, no one sets out to write bad code that they're embarrassed of, but all too often I think good people make bad products. This happens for a variety of reasons. Developers and requirements "gatherers" may be too insulated from what is really important to the customer. For the developer, not having to figuratively look the customer in the eye makes it easier to throw bad code over the wall. For requirements, they tend to get deluded that the people they're trying to close the deal with right now are representative of what all of your customers want or that their pet feature is more in demand than it really is.
This problem can be alleviated somewhat through site visits or more support roles for developers, among other things. But, it seems to me, the best way to regularly get your staff talking to your current and potential customers (and to get the customers to talk back) is to add some transparency to things. I truly believe that if your employees know that they're going to be out there justifying their current and future thinking to your customers (which they're probably not having to do right now–not directly at least) they'll try harder to produce something they're proud of. But, more importantly, before it's built, people outside of your company will have a more direct way of telling you you're doing something wrong. And I think blogs are the best way to do that.
December 29th, 2005 at 9:26 pm
I agree that blogs are a good way to accomplish it, but in addition, there needs to be validation that a good developer isn't always a good "gatherer". There is an art to good code, just as much as there is an art to analysis. Too much effort is put into saving money, that developers double as analysts, and vice versa.