A couple ofpeople have noted that in my responses - titled "It's the Tech Guy Obviously!" and "What about the Business Guy?" respectively - to Ann Bernard's initial post "The Tech Guy vs The Biz Dev Guy" that I've been hard on the BizDev Guy. As in incredibly hard, ripping him to shreds, openly mocking him, and just short of bringing up elderberries. I'm sorry gentlemen, but it's time to take a look at ourselves...

What does the Tech Guy lack?

This is a followup to my previous post - "It's the Tech Guy Obviously!" - which was written in response to Ann Bernard's "Tech Guy vs Biz Dev Guy". As she is my partner in WhyGoSolo, lots of disclaimers apply. An yes, all the pronouns here are male... oh well.

In my first post, I dinged the BizDev Guy pretty hard because - to be blunt - he's ignorant of the technical issues. Which, in my opinion, are the biggest and most fundamental at the beginning. As I noted last time:

The Tech Guy might incorporate as the wrong business structure, he might have a terrible UI, he might not have any market research to support his project. All of those things are easily fixable and since he has a prototype, it's simple to figure those pieces out.

If you're not in the US college/university system, for clarification purposes, a "senior" is someone who is in their fourth and final year while a "junior" is someone in their third year. Got it? Let's go...

On 02 May, I had the opportunity to return to my alma mater - Rose-Hulman - and speak to a class on Software QA. It was a great opportunity and discussion spurred by (hopefully funny) war stories and major screwups that I was more than happy to share.

The most interesting aspect that I saw was the injection of strong Project Management techniques into the curriculum. I don't just mean "here's a deadline... go!". I mean real specification writing, task estimates, milestones, code reviews, deliverables, QA, and overall management. In fact, they get a bit creative in how they do it and even study things such as team psychology and touch on Meyers Brigg. Whoa.

But then they tie it back to the core curriculum...

... is the worst possible thing you can be.

One of the aspects of the work that I do is system analysis. I'm contacted regularly by individuals who are working on a new application or have an application that's about to go into production that they want me to look at. Generally, the focus is performance or scalability, but there's almost always a "is it secure?" comment in there.

When people are just getting started working from home, they go one of two ways:

a) They are wildly productive without the constant barrage of calls, officemates, random PA announcements (yes, some companies do them), and the various other things that interrupt their day; OR

b) They are wildly unproductive with the constant barrage of calls, family, random television shows, cleaning (yes, some people clean), and the various other things that interrupt their day; OR

Can you guess why I'm writing this post. ;)

These are my notes, ideas, and practices from telecommuting extensively over the past 5 years...

My first telecommuting situation was on a government contract back in 2002. Our team was working on 30 day iterations - we didn't call them iterations in those days - but it made for very tangible deliverables and direction and the boss agreed to let us telecommute one day each week. During my first couple telecommuting days, I made a great effort to get things done, but I found it hard to get started and even worse to stay focused. Then it hit me: I needed a commute.

Most mISV's don't need to worry about these aspects. When you're only one person, a great big file or a whiteboard or any number of other tools can probably fit your needs. But once you add a second person or a second project/product, it gets that much more complicated. Now your mnemonics and half-notes aren't as valuable... in fact, some may be a liability.

Hello, I'm Keith and I'm an information addict. I don't seek to catalog all the world's information. I don't even seek to collect it. My goal is to take what I have and make it useful.

That may sound odd but think about it... most information has a few specific properties:

• The most important/expensive information is usually the most time-sensitive;
• It isn't useful if you don't know how to find it;
• Different people will look for the information in different ways depending on the questions they need answered;

Towards this goal, I've been experimenting with different wiki structures - exclusively on MediaWiki - and how to use them to fulfill those requirements. Here are the results of a year of tweaking and refinement.

Blogging about blogging... yes, I hate it too, but this has to be said. In the past few weeks, I've been working with a number of customers on their blogging strategy and have some notes that I found fascinating. With a certain amount of anonymizing and only using public information, here they are:

Organization A is a company fighting to gain market share in a number of different closely related markets. Some of those markets are fiercely competitive but have incredibly high barriers to entry while they're early entrants to other markets with almost no barrier to entry. They have a well-established name and client list but their brand lacks any kind of Focus. Instead of having a series of products, they've been more of a consultantcy but are actively working to change that. Their competitors are easily identified and are largely established and their customers (and customers' customers) are highly connected and often incredibly tech savvy.