Monday, October 13, 2008

What is wrong with developers?

It is so hard to fight clichés. The ones that have been hurting me personally are:

  • Developers cannot/should not manage
  • Developers should not drive features of a product

Of course, like anything else, there are good reasons and bad reasons for what those are. An efficient developer in my opinion should focus on one task at a time and avoid all distractions like the plague. Anything which does not fit this requirements affects productivity and quality. It is not that simple of course, but not a bad generalization.

I think the main issue with developers being promoted to management is two fold. First they should really want to and not being pushed into it because that is the only way for their career to progress (meaning to get a decent pay raise). Second, this represents a big mental shift and some people are just not very good at adapting to new situations. I would not say developers are worse at it than any other label you can put on people. Two very important skills a developer would bring would be analytical skill and strong organizational skills. Those are needed and I would say required. A manager to me is someone who brings order into Chaos so his/her team can achieve their goals as best and as efficiently as possible. Of course you need more than that, but those are in themselves hard skills to learn.

The other one is that developers should not be driving requirements. I understand the stereotype of technology for the sake of it and bla bla bla. But I have met lots of developers with strong usability skills, user empathy and good ideas. I am all for analysis of the market and creating features that people want and would bring the money and all. I am sold on it, I agree it is tough to be heads down into a product and not have time to check the market and all. A product manager role is, in my opinion, welcome and  required. But I also find that a bit of input from technical people on usability and  ingenuity would not hurt either. Some of the best differentiators in my industry came from developers. Of course not everybody is creative same as not every product manager is a good one. I have had to live through some seriously bad ideas in my time. A good way to build a product should be a combination of market drivers and a free for all approach from all sides of the spectrum of people participating in the product. I fear otherwise we are only creating bland products with no real differentiator. Because let's face it, your competitors have access to the same market researches. Yes, there is a trick in knowing which ones to attack first and potentially how to attack them (although I have seen product managers decide their job stop at the what and don't bother with the how), but in the long term, when replying to an RFP, everyone will be able to say yes to most things. There is a need to go beyond a purely reactive approach to building those products.

I suppose the conclusion is that not all developers live in their own bubbles. No more than anyone else. Provide training, perspective, enough room to fail here and there and we will surprise you. What works is collaboration of disciplines anyway, include your technical people in some of those decisions. They will understand why they are doing things a lot better (that can only help) and might give your product that edge that will make it stand out from the competition.

Saturday, October 4, 2008

Contact and Document Management

I have been involved in creating a search application for a while. The application was hinging on also becoming a document management system while it enabled users to collaborate on the documents in order to create intelligence based on the raw data contained in the documents. The application did not really make it that far, but after I had taken a step back and thought about what I had been doing for a while. I came to the conclusion that at the basis of all information gathering and collaboration is good contact management.
  • We needed some security of course, that is the easiest one of all, but you need to make sure every one is well identified. So that is the mostly easy part. Of course combine this with groups and roles and the like and you are covered. It is of course not as easy as that, but everyone can do at least that much, so it is not that hard.
  • What comes next is that not everyone creates data with the same skill and quality of content as everyone else. You must identify who you experts are and what their field of expertise is. Of course one of the issue it that this will change over time. If you have just recruited a new assistant and he is creating documents reflecting his training in a given field, you would want to give priority to the more senior and experienced resources when searching data on that field. You could even go further and privilege any efforts made when several experienced resources collaborate together.
  • Of course this seem to apply only at a company level where that information is well known and understood. It seems a bit more difficult to achieve this at the Internet level. We have lots of information about one single document, and potentially about a site as well. I believe we could also collect information about the documents a single person has written and what the subjects are. I believe we collect a list of keywords for each document and who references those documents (for Google anyway). Those keywords could be cross referenced (or not) with fields of expertise.
  • The next stage would be to combine that with user feedback. Present them with a top list of expertise they declare themselves to be cognizant about and then have them rate articles, and by extension the authors of those articles. The last stage, or at least the last one I can think of, would be to include social information. I suppose I mean for you to be able to generate a graph of trusted sources for specific subjects. It would be great to be able to be able to use that information for future searches and being able to visualize it as well as customize it. Based on previous document feedback, we could already build such a graph already, but being able to customize it would increase its efficiency. I could define an author I have heard of, without knowing whether there are any articles written by that person. But we could also recommend other authors who have recommended him and are recommended by her.
  • The other thing that would be great, would be to be automatically notified when a preferred author has published, but only if the web site is actually related to my interests. If I publish a new picture in Flickr or if I publish a new entry in my blog about the latest coding practice, they do not speak to the same interest and to be honest my photographic skills and not really worth keeping track of.

This is probably too complex to ever be understood by everyone or not many people will actually bother setting all those filters. There must be a compromise here somewhere.