Blogs – They’re Not Just For Vanity Anymore

Last week something very interesting happened.  The CEO of a company I’d proposed some work to read my blog, decided that we were a good philosophical match, and gave me the project – before ever having spoken to me or exchanged an eMail with me.  I had engaged in some initial contact with one of the company’s programmers, who forwarded my name on to her CEO.  When I finally got on the phone with the CEO, she spoke as though she knew me already, talking of the fit between our respective outlooks on business and technology.  It was strange, but very welcome, and she was right – we do indeed have a great philosophical fit!

The Scobles of the world who claim that blogs are a relationship accelerator must be correct – if by reading someone’s blog you can get a bead on where that person is coming from and even begin to feel as if you know that person (even if only in the context of their blogged subject matter), then why not?  The internet has changed everything else about how we communicate, it only makes sense that it would help change the introduction/getting-to-know-you dynamic as well.

Anyway, I’m both surprised and pleased.  I have a great new client staffed with people who are pleasant to work with, and the project itself is fun.

My blog closed the deal for me!  I never thought I’d see the day.

More Changes Here At ChristopherHawkins.com

I’ve tweaked my blogging tool so that the main page of this blog only displays the last 10 dates on which I’ve published something.  To see content older than that, you can use the Archive links on the side of the page.  The RSS feed also only goes back 10 days.

We’ll see if these changes help or hinder.  The main page used to display every blog entry I’ve ever made, and the page was well over 100K – far too big, in my opinion.  But heck, maybe people don’t mind loading a huge page as long as everything is on it when it finally loads.

If any readers have an opinion on the way I’ve broken up the content, let me know.  My mission is to make this blog easy to read, not a chore.

Did You Remember to Back Up Your Work?

Not too long ago, a hard drive failed in my primary dev machine.  It turned out that although I had been backing up most of my important files, I had not been backing them all up.  Net result?  The fruits of about $50,000 worth of my labor was gone.  That was a painful lesson.  Since then I have become religious about backups.

I got off pretty light, to be honest.  But suppose something more critical than money was depending upon having a good backup?  Say, something like the outcome of a capital murder trial?  Yes, I’m being serious.  I just read an article about Robert Blake’s attorney and his stolen computer.  Apparently his entire defense was contained on a laptop computer in his office, and  – cue Mr. Murphy – said office was burglarized, the computer stolen.  One sentence from the article was telling:

Schwartzbach declined to comment on whether he had copies of the material on the computer missing from his Sherman Oaks apartment, which was serving as his office.

Who wants to bet money that he’s got zero in terms of backup documentation?  This is really serious.  If I were his client I’d be very, very worried.  M. Gerald Schwartzbach is a high-level attorney, yet he couldn’t be troubled to burn a few CDs to guard against this type of disaster?  Incredible.

What kind of shape are your businesses backups in?  Ask yourself a question – what would you do if you woke up tomorrow to find your most valuable digital property gone?  Could your business survive?  Do you have adequate backups?  Do you even  have a disaster recovery plan?

It seems that IT disaster recovery plans are not just for IT shops anymore – high-priced attorneys appear to need them, too.

The Grass is Greenest on Your Side

I just read an interesting message posted by Pi Guy on Joel Spolsky’s site.  This fellow works as a developer but does not like any of the non-coding aspects of his job:

I’m a “programmer” at a small web development company.  We do web design, asp/asp.net/sql server applications.

I generally like my job when I just stick to coding behind the scenes.  I’m one of those people that can code for 8 hours straight, and it feels like I’ve only been working for 4 hours — I really like coding.  The problem is that my job is shifting more and more away from coding:

Things I don’t like: – I have to go on sales calls as the technical person – I write 90% of the content of proposals (defining the scope of a project — the sales people say they aren’t capable of writing this part). – I’m required to tell my boss exactly how many hours a project will take before we’ve fully gathered requirements.  They base the cost of a project on these hours * an hourly rate.  So, it becomes my job to really gather the requirements because it’s my tail on the line if the hours are wrong. – I have to give out my business card to clients with my direct phone number.  So, they end up calling me first if they think there’s a problem.

Basically, I hate being involved in the sales process in any way.  I feel that the sales people could learn to do what they’re making me do, but they are too lazy.  Before I came here, I had ideas of just coding all day and being left alone.  I end up not developing my coding skills because I feel like I’m wasting my time on other areas that won’t help me to become a better coder.

Are programmers just programmers at other companies in general?  I’m just trying to figure out if the grass really isn’t greener on the other side of the fence.

NOTE: I understand that I have to work with people.  I totally accept that, and I really enjoy working with a team of developers.  My dream job is one where I work with a team of 3 to 4 programmers.  Another team would be responsible for gathering requirements them handing them off to us.

I am of the opinion that his job sounds great.  He gets to code AND be involved with the sales process AND have significant say-so in project estimates AND hear feedback directly from customers.  That, my friends, is a great recipe for being promotable and less likely to be laid off.  True, it would be nice if there were at least one layer of tech support between the customers and the developers, but in a small development shop it is not unusual for the developers to BE the tech support.

His message reminds me of my article Repeat After Me – I Am Not In The Software Business.  Pi Guy doesn’t appear to have the “I am an artiste attitude,” but he certainly does seem to be blind to the incredible opportunities that come along with being involved in the business side of the house.  Due to the huge (and often fragile) egos that inhabit our industry, no developer on earth wants to admit that writing the code is the easiest part of what we do, but it is.  Developers who are able to add value beyond coding by performing functions that translate the business needs into a technical context and back again are the ones who will remain employed in the near future.

Pi Guy, I say you should embrace the non-coding parts of your job.  I’ve been out here for 11 years, and trust me – the grass appears to be greenest on YOUR side this time.

Non-Technical Workers Managing Technical Projects: 3 Keys

Working with small businesses, I often find that the person designated to be my point of contact on a given project is made responsible internally for the success or failure of the project, but has no technical knowledge whatsoever.  I am accustomed to mitigating this kind of situation by translating a lot of the technical aspects of the project into business-speak and by keeping the project sponsor well informed.  But in many cases no matter what I do, the poor fellow just seems overwhelmed, scared and unprepared to communicate with a technical professional.  Over time I’ve come to notice a few things that the best-prepared and most successful non-technical workers have in common when it comes to dealing with technical professionals like myself.

I’m sure this will all seem obvious to any technical worker, but this article isn’t for you; it’s for the non-technical guy whose boss makes him responsible for getting a technical project done, who finds himself besieged by a bunch of geeks speaking a different language and doing things he doesn’t understand.  Hopefully this little bit of advice will help alleviate some of the pain that often accompanies working with a technical service provider.

1) Know Your Business

Before undertaking any technology project, you must know two things:  a) How the portion of your business that will be impacted by the project works now, and b) How you want that part of the business to work post-project.

This may seem so elementary as to not merit mentioning, but it must be said.  I am always amazed at how few businesses have a clear picture of their internal workings.  On more than one occasion I’ve been in a requirements gathering session with clients who are arguing amongst themselves about what their processes are.  Make no mistake – you absolutely cannot get underway with any technology project until you know what is happening today and what you want to happen tomorrow.  This is not to say that you should not also allow your technical service provider to map your processes your own business process knowledge is a supplement to the provider’s discovery process, not a replacement for it.  A third-party analysis of your business can often reveal subtleties that you miss due to the classic forest/trees effect.

If you yourself are a project sponsor, make sure you know your business backward and forward.  And if you are the manager responsible for delegating oversight of a technical project to one of your non-technical employees, make sure you delegate it to someone with good domain knowledge.

The best case scenario is that you select a competent enough provider to simply turn over the entire project without dedicating any of your employees to oversight.  However, this is sometimes not realistic, so be certain to do your homework on your own business.  If nothing else the perspective will enrich your performance at work.

2) Select a Provider Carefully

It can be hard – very hard – to reliably select a technical service provider.  The ubiquity of PCs and computer books have produced a glut of self-described “developers,” “consultants” and “network administrators” who are not truly qualified to do any project that has the operation of a business relying upon it.  This leads to an environment of considerable uncertainty when you area non-technical worker who is tasked with making a technical project happen in your workplace – how do you know who to trust when you don’t have sufficient technical knowledge to verify a potential provider’s competency?

A few months back I wrote an item entitled The 5 Laws of Choosing a Software Developer; in truth, those Laws could apply to choosing a web designer, network admin, or any other type of technical service provider.  I suggest you read the whole 5 Laws article, as each Law is described in depth, but the basic 5 Laws are:

  • Demand Experience
  • Demand References
  • Demand Value
  • Demand Communication Skills
  • Demand Availability

I cannot overstate how important it is to select the right technical service provider.  Not the cheapest one, not the best-dressed one, not even the most talented one, but the right one.  It is very much a matter of fit.  Once you’ve chosen a technical service provider, trust and listen to that provider – if you did your due diligence before making a choice, this should be easy.

3) Demand Outcomes, Not Technologies

I recently saw a discussion on this very topic at Joel on Software.  I am always suspicious of non-technical clients who call me up and say “We need a Java application” or “We need a SQL Server database” and with good reason – when you visit the local car dealership, do you ask for a car built by an ABB industrial robot?  When you buy a computer, do you ask for one whose hard drive heads were cut by an MTI machine?  Of course not – you ask for a car that gets better than x miles per gallon, or that has heated leather seats and a navigation system.  The means and the outcome are two distinct issues, and should be treated as such.

For maximum results, your focus should be on your business and what business-enhancing outcomes you want from your technical project.  You are the expert on your business – the technical service provider you select is the expert on making technology support business needs.  Talk to your provider about your desired outcomes, and then trust the provider to determine the most appropriate means to achieve these outcomes.  Obviously, if you are in a company that has already heavily invested in one particular kind of technology (whether you’re a UNIX and J2EE shop or a Microsoft shop), you’ll need to make this known and it will certainly factor into your service provider’s recommendation.

Once you have communicated a set of desired outcomes, stand by them.  If you have chosen your provider wisely, they will be able to understand your business and deliver the results you’ve asked for.  There is no acceptable excuse for nonperformance.

There are undoubtedly many other things that a non-technical worker can do to be prepared to handle a technical project; the three I’ve listed here seem to be the most common denominators of success amongst the clients I’ve worked with.  Feel free to eMail me with your own stories or suggestions with regard to non-technical workers having to manage or oversee technical projects.