Single Point of Responsibility

I was just reading this post by Guy Kawasaki and love this little nugget of management advice:

Establish a single point of responsibility. If you ask your employees who is responsible for a goal, and no one can answer you in ten seconds, then it means that there’s not enough accountability. If more than one person is responsible for the achievement of a goal, then no one is responsible. Good employees accept responsibility. Great employees seek responsibility. Lousy employees avoid responsibility.

I think he is absolutely spot on – all of it. I was working with a client once and there was a large amount of diversity in the team in terms of their work practices. One day a team member came to me and said:

“I found this problem in the system, it was X’s code so I let them know about it but it really needs to be fixed before this afternoon – would you like me to fix it?”

That right there is an example of someone identifying a problem, making sure they take it to the person who is supposed to be responsible, realising that they had dropped the ball and accepting their greater responsibility to the product – especially under a deadline – the witchhunt can wait until later.

In this case we had a team goal of getting a good build out in the afternoon but that really broke down into a bunch of individual goals for team members to make sure they had cleared out as many bugs from the system as they could before we hit the build button.

Anyway – I highly recommend you read the post.

Become a Micro-ISV? Sure – just don’t build software for geeks.

Two links to Mike Gunderloy’s blog tonight. This time Mike has posted up with a review of Bob Walsh’s book “Micro-ISV: From Vision to Reality”. I have been reading Bob’s book after hearing him talk on the G’Day World podcast last week and I really recommend it if you have ever considered striking out on your own and delivering your own product.

I have to admit the idea of starting a Micro-ISV really appeals to me, but I am no thickie, it is a lot of hard work (late hours) to do IP development in a self-funded model.

Over the weekend and in the evenings this week I have contemplated what kind of software I would build if I was a Micro-ISV trying to make a crust. I’ve got lots of ideas but after discussing the idea with a few people I can now make the following observations.

Don’t build software for geeks!

This is an important one. While you may stumble across an idea that your average geek might get out there credit card for its far more likely that they will have NIHS relapse and think they can build it themselves. The thought process goes something like this:

1. Thats cool!
2. I wonder how they built that?
3. That doesn’t seem that hard!
4. I’ll build it myself, better faster stronger.
5. Bah – couldn’t be stuffed!

There are lots of different kinds of analysis!

I had this observation when I was talking to someone tonight. My original idea was very simple in scope, but depending on who I shared the idea with it was either so simple that I should just go out and build it, or spend quite a bit of time doing analysis about the target industry.

The interesting thing is depending on how you approached it the software would morph to suite the situation. I think the issue here is that certain kinds of analysis ask different kinds of questions and those questions help you shape your view of the product.

Once you come through the analysis both answers are completely valid because whilst they were the same idea at the root they are completely different solutions for different problems.

Sometimes I feel like I have a whole meta-conversation going on in my head Its my blog, I’ll waffle if I want to . . .

MockupScreens and some random thoughts.

I picked up a link to this MockupScreens utility from Mike Gunderloy’s daily grid blog. This software is interesting because it attempts to simulate the paper prototype look inside a structured environment.

It got me thinking about the kinds of tools that a business analyst needs. This is something that a business analyst can sit down with the user and use. But you really need to tie it into the whole development process (putting my VSTS dude hat on for a moment).

Instead of a VS Team Architect edition I sometimes wonder whether Microsoft would have been better off putting together a VS Team BA edition which a suite of designers for building different types of documents – off the top of my head I can think of:

• A paper prototype builder/manager
• A persona builder/manager
• A scenario builder/manager
• A business rule builder/manager.

With some of the process templates as they are out there at the moment many tools are just relying on fairly loose word documents to capture what could be very highly structured information.

Certainly lots of potential here.