I’ve often pondered the idea of founding a co-working space in Visalia so as to be done with the grind of finding good office spaces for a small, mostly-virtual team.  Rather than being deskbound and isolated in less-than-ideal space, why not be in a more open and communal space?  Why not work amongst fellow geeks and creatives?

40 miles north, in Fresno, folks were apparently thinking the same thing, only they actually got up and did something about it!  That something is called Hashtag Fresno, a collaborative workspace that will be opening on May 15.

I encourage everyone who is local and not deskbound to go check it out.  This is a very, very cool move, and frankly I think it’s long-overdue.  This news is the first thing that has ever made me wish I lived in Fresno, that’s no joke.  Fresno has more of a creative & tech presence than one might suspect, and a fair number of individuals are trying to help that tech presence gain greater traction.  I wish them all the success in the world.

In the meantime, I’ll continue pondering the idea of one day seeing a co-working space open in Visalia, too.

2009 has been a rough year at Cogeian Systems for a number of reasons.  Financially, it’s all rosy, and we’re growing.  But that growth has come in overwhelming waves and from time to time, I’ve felt as though I was losing control of certain details of our operation.

One of those details was marketing – I felt like the company’s marketing presence had gone stale (it has!), so I decided to do a new site design.  In a moment of monumental stupidity, I decided not to use my own design guys, because I wanted an outsider’s perspective, thinking it would result in something fresher than what would come about if the design were done by someone too close to the company.  I chose a young designer – a recent graduate with a good solid portfolio who seemed to see eye-to-eye with me on the importance of having the right design and what that design should be – to do the work on a freelance basis.  So, after providing a creative brief and taking a few meetings to hash ideas out, I set him to work.

The design he came up with was OK.  We did a few revisions and one revision in particular stood out as being different f didn’t think it was the right design for Cogeian Systems, and was prepared to start the project over, but more than that something just seemed off somehow.

Here’s the design (click for full-size):

I wasn’t feeling it, but at the same time I wasn’t sure how to articulate my concerns.  As I sometimes do, I took to browsing the CSS gallery sites (cssremix.com, cssbeauty.com, etc.), both because I enjoy beautiful design and because I like to be aware of the current trends in front-end design.  I was hoping that I could find something that would help me clarify the unease I was feeling about this design.  And oh brother, did I ever manage to clarify my unease – the reason something bothered me about the design was that I had seen it before on a css gallery site!

It turns out that the designer had straight-up lifted the design of a web development agency named Paramore-Redd.

Here’s Paramore-Redd’s design (click for full-size):

Just a little bit of similarity there, don’t you think?  And, just to break the irony meter, the blog post that was on the front page of Paramore-Redd’s site at the time was about design theft!

Just to make sure I wasn’t completely crazy, I decided to do an overlay of the two designs, to see exactly how much congruency there was between the two.  Here are the two designs overlaid and made semi-transparent (this was done using a screenshot of Paramore-Redd’s site at the time, in April or so):

There was a very high degree of congruency in the layouts.  The log and nav text are 100% in phase with one another, along with the headline and frames.  The main text area and the call to action were within pixels of being perfect overlaps.  He even borrowed some of the copy.  There is no way on God’s green Earth that I was going to be convinced that this was a case of independent inspiration.

Needless to say, I was not pleased.  If I had gone through with OK-ing this design, I’d have been guilty of design theft by proxy, and my designer knew it.  Web & software development is a small world and everybody knows everybody (in fact, I believe that I have at least 1 friend in common with the Paramore-Redd folks).  Imagine what it would have done to the professional credibility of my firm if I’d gone live with another’s firms’ design?  I’d have been shredded and laughed right out of business, and deservedly so.

So, I called the young designer on his transgression, and of course he protested that he had come up with this design 100% on his own, out of his own head, and that he had the developmental sketches to prove it.  I wasn’t buying it – there’s just no way that this was accidental – so I cut him loose and scuttled the project for a few months (we’re working on it again, this time with a designer who is in the family, right now).

Now, I realize that the wrongdoing was on the part of the designer, but at the same time I have to acknowledge a few mistakes.  First off, deciding NOT to use my own crew of regulars was a mistake; that business about wanting a ‘fresh perspective’ was silly.  I work with the same designers over and over, nobody has a better grasp of what Cogeian Systems is about than those guys.  Second, I hired a recent graduate.  His student portfolio was excellent, so much so that I boggled me that he’d feel the need to resort to design theft, but he was green, so so very green.  I’d never hire a developer that green and not expect a disaster, but for some reason I just felt like this kid had the goods, despite what 15 years in business tells me about hiring people so green.  And third, I broke my own rule by not issuing a firm no the instant he delivered a design I was lukewarm to.  I went along for a few revisions, thinking we’d hit on something magical along the way, but the reality is, as the old saying goes, you can’t polish a turd.

It’s amazing to me that even after 15 years in the business, I still make the occasional bad decision (or three!).  Maybe it’s the universe’s way of keeping me humble.  But in this case, I came very close to design theft by proxy, and all the negative consequences that would have had for my business.

All is not lost, though.  Soon I’ll be able to reveal some UI teases from our NEW new design for Cogeian.com.

One year.

365 days.

8,760 hours.

That’s how long it’s been since I wrote anything for my blog.

Wow.

Note to nit-pickers:  yes, I know my last post was published May 21 of last year, but I wrote it on May 18 and let it stew a couple of days.  So there!

2008 was a huge year for me and for Cogeian Systems, and I mean that in both a good and a bad way.  I intend to share the story of 2008 here, in the hopes that it will be useful to other small consulting shops, or even developers who are looking to make the leap into running their own firm full-time.  It’s been a wild ride.

Roughly speaking, each quarter of 2008 had one big event:

• The Rush – there was a HUGE influx of projects at the start of 2008, both new and from existing clients.  There was so much work to do, it almost sunk the company, believe it or not.
• The Move – I moved the company into new office space, which was a huge PITA, but very educational.
• The Team – I took on a (very green) assistant to help me run the office, and it worked out in ways that I didn’t even foresee.
• The Skills – I personally fell into a project that required me to learn C# on the fly, which had some unintended consequences for me.

Those are the broad strokes; I’m still writing up the detailed accounts and trying to articulate what I learned.  In a lot of ways it was a Year in Hell, but in other ways it was awesome; for example, my company is still in business and doing well.

More on all this later.  For now, let me just say, it’s good to be back!

P.S. I’m eager to start churning out more installments of Monday Consulting Questions, so if anyone has a question regarding me, my career, my company, or running a boutique consulting firm in general, Go ahead and send me an e-mail.

I just finished reading Productive Jealousy on Signal vs. Noise.  David Heinemeier Hansson insists that jealousy need not be an angry or destructive emotion.  I tend to agree with him – in fact, negative emotions are my primary motivation.  I suspect that there is a conception out there that in order to be productive and successful you have to be all sunshine & rainbows, hoping to make the world a better place.  In truth, just as much productivity is fueled by “I’ll show you!” as it is by “Gee, guys, isn’t this spiffy?”

David is right – for a lot of people jealousy, envy, etc. is a very powerful motivator to improve, to excel, to do more.  There is no reason why, upon seeing others achieve success by some metric, that you can’t do something similar yourself.  And if negative emotions will fuel you on the way, there’s nothing wrong with that.  In response to the question posed by the title of this post, I am reminded of an old saying – “there is enough sun for everyone to get a tan”  I know that many people don’t believe this, but I do.

I can honestly say that in my own professional career, negative emotion has been a tremendous driver of productivity and improvement.  I’m more of an “I’ll show you!” than I am a “Gee, isn’t this spiffy?, and I wouldn’t trade it for anything.  Rather than letting anger, jealousy, etc. fester and eat you alive, or drive you to do negative things, use it for fuel.  Use it for growth.  Use it for improvement.  Use it for excellence.  Use it to make yourself strong.

Q. I am not a techie.  I work for a small business in a real-estate-related industry.  I have been put in charge of having a new website created for our company.  We will need it hooked up to a database of some kind.  I’ve never run a technology project before.  Where do I start, and how do I keep from being taken advantage of?

A. Welcome to the world of technical project sponsorship!  To answer your first question – where to start – I suggest you start by reading my article The 5 Laws of Choosing a Software Developer.  All the same issues apply to choosing a freelance web designer/developer as well.  Let me recap the article here, in case you don’t have time to read it.

1. Demand Experience. Past performance is a great indicator of future results.  Make sure you get someone with at least a few years of experience doing the kind of work that you want to end up with.
2. Demand References. Trust, but verify.  Make sure the person or firm you hire can really do (and has really done) everything claimed.
3. Demand Value. Be as wary – if not more so – of the guy who charges too little as you are of people who seem to charge too much.  You really will get what you pay for, and both the too-low and too-high providers are telegraphing their flaws.
4. Demand Communication Skills. Don’t hire anyone who is so wrapped up in their domain – whether that is the domain of the programmer or of the artist – that he is unable to speak to you like a normal human being.  There are a lot of broken individuals in this industry for one reason or another.  Don’t bet your project on someone who is incapable of returning your calls.
5. Demand Availability. Try to find a freelancer or firm that is dedicated to their business full-time.  There are a lot of very talented folks out there who do work “on the side” in addition to their day job, but if you’re not accustomed to managing technology projects you will find them exasperating to work with because they will be out-of-sync with your schedule.

To answer your second question – how to avoid being taken advantage of – is a little tougher.

If you adhere to the guidelines outlined above, you will find a competent provider.  But will you find an ethical one?  That’s the real question.  Because the barriers to entry are very low in the freelance design/development business, there are a lot of what I call “transient professionals” milling about.  They generally have the technical skills to do the work but lack the intangibles (such as drive, ethics, or time-management & planning capabilities) that are the real mark of a useful provider.  It is not hard to find and hire one of these types and end up watching your project disappear into a black hole.

The best advice I can give you is to push hard on the references and verify both the portfolio and work habits of the provider.  This goes for firms as well as individual freelancers – you need to make sure that the provider has actually completed projects like yours, not simply worked on them.  It is an important distinction.

Q. I see that your LinkedIn profile photo is actually a South Park-style avatar of yourself.  That doesn’t seem very professional.  What do you think that says about you?

A. That despite my dry blog and (some would say) boring professional niche, I’m a guy who has a sense of humor?  That I want my LinkedIn profile to be a bit more memorable than just another real-estate-style headshot?  I don’t consider business to be a humor-free endeavor, and I hope you don’t either.  Note that even when I’m trying to be humorous, I can’t completely let go of professional rigidity – in the un-cropped version of the graphic, my avatar is wearing a tie. 

Q. I’m kind of new to consulting.  I have a new client who is asking me to do a small project for free, while promising that if I do well, they’ll have a lot of other projects for me to do at my full bill rate.  Am I being set up to get screwed?

A. First off, welcome to consulting.  It looks like we have a first-timers theme going today, perhaps I should put you together with the first-time project sponsor above. 

Second, I absolutely guarantee that you are being set up for a screwing.  What you are being asked for is called “spec work” (the spec stands for speculative, meaning you have to do the work first and then the client decides if they want to pay for it or not), and it is absolutely the bane of the industry.  I want everyone reading this who has ever been subject to the same kind of “work for free now and get real work later” proposition to stand up.  Go on, right now, stand up.  Now, I want everyone who has ever made this kind of a proposition work out favorably in the end to sit down.  Ah-HAH!  You’re all still standing, aren’t you?  Of course you are, because speculative work arrangements never work out favorably.  Not for the provider of the work, at least.

Now, I can see giving a new client a little bit of a price break as a “get to know you” rate on a limited part of your first project together.  I don’t necessarily like the practice, and my company doesn’t do it, but I can at least understand it when you’re starting out.  But never, ever, ever work for free based solely on someone’s promise that doing so will result in you being rewarded with paying work later.  Just.  Don’t.  Do.  It.  The odds are overwhelmingly in favor of “there is no paying work later.”  I – and every other freelance consultant out there – have seen it happen a million times.

Q. a) Is this really your new blog design?  b) Are you trying to be a designer now?  c) I thought you were a programmer.

A. a) It appears so. b) No, but I am trying to increase my design IQ. c) So did I, but then I went and turned into a businessman.

I haven’t had much time for writing these past few months.  In fact, I haven’t had much time for anything other than work!  I’ve been hanging on to this beast for dear life, trying not to let things grow too fast.  So, in order to soothe my soul, I’m playing with some design ideas that I had for my blog.

I’ll probably do a serious article in the near future.  But for now, I’m just experimenting with design.  Let me know what you think!

Q.  How do you handle your workload when your key man is out/unavailable?

A. Cogeian Systems is basically my vision of how software development ought to be done, implemented by my team.  In some ways, I am the key man.  In other ways, my team members – every one of them – are the key men.  In a small firm, you don’t have the ability to pull in an anonymous dev from another department to cover a staffing shortfall in your own.  We are a small team; we thrive together and we suffer together.

That said, in any firm there’s always at least one project going on that is significantly more vital to the firm than any other project.  Whoever is leading that project is the key man.  I lost a developer to a bigger firm around this time last year, and it definitely qualified as a key man issue – I had him developing a lot of long-term stuff and although coverage was decent, it was still a blow to have a primary producer leave.  To be honest, we’re still feeling the crunch; business has increased but the team has shrunk.  This has forced us to become even more effective than before.

I make sure that at least 2 devs are familiar with every project.  I make sure that at least 2 devs are known to every client, so that if someone has to step in, they’re not completely foreign to the client.  I make sure that all my project management notes are accessible to every dev.  I make sure, in short, that there are no secrets regarding what has been promised, what is being built, what is broken, or who is responsible for what.  In a small shop that’s about all you can do.

Q.  I have a client who wants me to do some really dumb things with their web app.  They keep pulling out the “we could do this ourselves” argument, like I should be thankful to be here.  What do I do?

A.WARNING:  Client trash-talk ahead.  If you are a Cogeian Systems client who has given me a hard time recently, I am about to talk about you.  Don’t worry, I still love you.

First off, you should be thankful for their business.  However, that doesn’t mean you should be a pushover and allow the client to disregard your expertise.  We do a lot of business with small businesses, and almost to a person we have found that small business owners fall into the “just do what I say” camp at first, showing little interest in allowing us to exercise the expertise that led them to hire us in the first place.  It’s a huge issue, and it threatens to badly derail a lot of projects before they get started.

The software remediation clients tend to be the worst in this regard – they’ve already been burned by another dev firm, they’ve probably already expended their anticipated budget, they’re aggravated and suspicious, and they try to soothe themselves by being very draconian with us.  This never helps the project.  About half of our small business clients give us this type of attitude – “just do it, I already know what needs to be done.”  We’ve also heard the “I could do this myself, but. . .” argument.  They’re completely wrong a lot of the time, and we try hard to educate, lead and reason with them.

I run a small business too, so I understand their fears – every dollar spent on software/web work is a dollar that could have gone into the business owner’s pocket.  Now, you could argue that this is a short-sighted view, given that good software or web work will more than pay for itself quickly, but that is human nature.  People – especially people coming to us after being hosed by another firm – are often afraid of what might go wrong if they hand over a big sweaty wad of cash and everything goes wrong.  I get that, and I try to talk to clients on an owner-to-owner basis whenever possible to make it clear that we’re on the same page.

Ultimately, the sad truth is that if a client is not willing to get past their own fear or suspicion in order to play ball, we refund the deposit and suggest some other local service providers.  As I’ve written before, being a professional means saying “no” to your client sometimes.  Of course, the upside is that the clients we tend to retain are the ones who either get it right away, or who come around after initially being resistant to letting us be the expert.  This is a beautiful thing, because it means we have great client relationships, even if they start out shaky.

I look at it this way – I didn’t build this firm so I could help my clients to do the wrong thing, and thankfully there is plenty of business out there, so when a project is clearly not a fit for whatever reason, I don’t feel bad about walking them.

Cogeian Systems is mostly a virtual team, with the project management office in central California directing the efforts of developers/designers in southern California, Brazil, New Zealand, and on the East Coast.  However, things are quickly coming to the point where I need to get a few folks into an office here in central CA.  So, I’ve been looking around town for office space recently.  The search has not gone well.

In general, it seems that renting office space is a game that has been polarized to cater to two types of folks: solo operators who can get by with a 12′ x 12′ executive suite, or mid-size+ firms who can actually make use of 2500 square foot office suites.

My little company is on the low side of the middle in terms of space requirements; I only need space enough for 3 people, with maybe some flex space for folks who drop in to perform recurring duties from time to time (my wife, the bookkeeper, the PC tech, etc.).  So, we need maybe 500 square feet.  After speaking to some other local tech guys, it seems I am not alone.

This morning, I noticed that Andrey Butov of Antair Software is having a similar problem in his locale as well.  From Andrey’s blog:

The few hours a week that I can spend perusing the locals for office space are not proving to be very fruitful. Everything available is either a 100 sq ft shack, or a 10,000 sq foot store front. Honestly, why is it so difficult to find a nice, clean, networked building with a space for, say 3-5 developers working comfortably?

I couldn’t sum it up any better.  I’ve found spaces that could house 3 people with some flex space left over, but most of those spaces were shabby.  I’m not looking for the Taj Majal here, I just want a “clean, networked building” that’s neither 40 years old and crumbling nor brand-new and still in its “inflated honeymoon pricing” period, charging double what anyone else is charging.  The quality of most spaces I have seen doesn’t seem to justify the rent.

I can’t help but wonder if other small tech firms have similar problems finding smallish office space?  Is it a location problem?  Mt HQ is in a small town in central CA, a primarily agricultural area that is, frankly, not the best place in the world to locate a tech business.  Andrey is in New York City though; I’m surprised that’s he finding it hard to find good space.  I guess that just proves I don’t know anything about New York’s commercial realty market.  Out here, I’ve looked north and south to larger cities – Fresno and Bakersfield, specifically – and have found a fair amount of suitable space. So, perhaps it IS simply a matter of location.  Or is it simple a matter of having a business that is a tweener size-wise?

I have considered starting up a co-working space in Visalia, using Cogeian Systems as the anchor and inviting other independent small firms & consultants to join the space.  It would be a super cool environment to work in, but I’m not sure I want to be in the landlord business.

I’d love to hear form other small-firm operators who are having the same problem – do you find it difficult to find suitable space for a 3 – 5 person firm?

I’ve been saving up questions for a while, so without further ado let me welcome another installment of Monday Consulting Questions.

Q.  What is your position on working on-site?  I have a new client who is pressuring me to work 100% on-site, and I don’t know what to tell them. A. When you say “working on-site” I’m going to assume you mean actually developing software on-site.

The general rule I’ve set for Cogeian Systems is that we do not do development work on-site.  We have our own work spaces, our own machines, our own software and everything else we need to complete a project.  We primarily do work at our own locations.  Now, we do travel out to see clients for various reasons – meetings, installations, training, etc., and these things are work.  However, it is not our generally our practice to generate work product (software) on-site.  There are a couple of reasons for this, and I suggest that you as a consultant think long and hard about them.

First, my experience has been that developing on-site devalues your expertise in the client’s eyes.  Back in the early days when it was just me, I had a couple of clients nastily refer to how I was “just typing all day” and that they didn’t understand why they were paying my rate – this despite the fact that what I was building was demonstrably saving them 3x my bill in labor costs each month.  But for whatever reason, this client didn’t care – all they knew was that a typist should cost $10/hour, yet there I was, “just typing all day” while being paid almost 10 times that.  However, take that same client, go away for a week or two, come back with a big fat feature to install, and they’ll think you were off working miracles for them.  It’s lame but it does happen.

Second, working on-site introduces the danger of the client treating a consultant like an employee.  You’re there every day, sitting at a desk like an employee, arriving at 8 and leaving at 6 like an employee, taking an hour for lunch like an employee, hell, they may as well treat you like an employee – that is to say, micromanage, second-guess, interrupt, and generally stop you from being effective.  I know, I know, this sounds terrible for me to say, but I’ve called clients on this before and they admitted that I was right.  There is nothing more dangerous than for a client to take an expensive consultant too casually and give them the employee treatment, thereby working against their own best interests.  The most effective (and happiest!) consultant is going to be the least encumbered.

Third, working on-site prevents you from doing the things you need to do to grow your practice.  If you’re stuck behind the client’s desk for 8 hours a day, when are you going to market?  When are you going to recruit?  When are you going to make or take prospect calls?  Sure, you could do all these things after hours, but isn’t it better to NOT do it that way?  This is the kiss of death for anyone trying to found a consulting practice that they intend to grow beyond a 1-person operation.

So, the over-reaching meta-reason for not working on-site is simple:  it is not an effective practice.  It’s not an effective way to get a project done (which is bad for the client) and it’s not an effective way to grow your business (which is bad for you).

Now, the exceptions.

For certain remediation projects, there is no way to avoid working on-site.  Although we do 90% of our work via some sort of remote services, there are times when you need to be physically at the location, and that is fine if that is what the job requires.  We’re just not going to work on-site for every little mundane task.

Personally, I think that a client who wants a consultant to be on-site full-time has a trust problem.  And if a client cannot trust my team and I, then we probably shouldn’t be working together.  Again, this is a hard line I’m taking, but I think it is a useful one.

Of course, there are folks out there who don’t really want to be a consultant, they want to be a contractor – that is, contracted labor meant to augment the client’s W2 staff.  There’s certainly nothing wrong with this kind of arrangement, as I know a few guys who make it work with some combination of on-site and off-site development work.  I simply don’t recommend this as a long-term method of operation for anyone who is looking to build a consulting firm.

Q. What do you do when a project requires technology that you are not familiar with?  A. Now, this is an interesting questions.  I have always said that my company specializes in the Microsoft platform of technologies; if someone called us to do, say, a PHP project, I’d have to politely decline.  However, I have recently decided that this stance does not mesh with my oft-repeated claim that we are actually in the business-problem-solving business.  So, I’m currently looking for competent PHP and MySQL resources so that I can apply my take on effective development practices and extend my company’s offerings to include the LAMP ecosystem.  I might even pick up some PHP skills myself (more on this later).  But, I’m digressing.

When faced with a project that includes or requires technologies that neither I nor my team are up to speed on, I do one of a few things:

If the unknown technology is a strong majority of the project, I will refer the client to someone else.

If the unknown technology is a strong minority of the project, I will accept the project and subcontract the parts that include the unknown technology.

If the unknown technology is a minimal factor in the project, I will strive to understand it (or have one of my team members strive to understand it) to the degree that is required to complete the project.

Do you have questions about the custom software/consulting business?  Email me your question and I’ll try to use it in a future installment of Monday Consulting Questions.