Why the world is not flat

We have been working with some of our clients primarily via email, phone, and IM. It’s certainly possible to have a business relationship this way, but recently we had the opportunity to meet a long time client face to face for the first time, and boy – what a great experience.

We spent an amazing 2+ hours talking about not much – industry, general business, a bit about current and future projects together, but really just a nice, general conversation. I’m sure the business relationship will be even stronger now that we have actually “met”.

Many of our clients have the option of working with firms that do their development remotely. One thing we hear repeatedly is how much they like the fact that we are local. Certainly most of our communication is electronic, but whenever possible we like to meet in person, preferably early in the relationship. One of our advisors is fond of saying “people do business with people.” In our business, this is absolutely true, and once you have the opportunity to shake someone’s hand and look them in the eye, the relationship changes.

"Speed Dating" for professionals

Last night I attended the most interesting networking event I've been to in quite a while – it was called “Power Match” but to me it was speed dating for executives. Now to be fair, I’ve never been speed dating, but I do have single friends that have, and this sounds very similar. You spend ten minutes with one or two other people, and then a bell rings and you switch. What a great way to meet a lot of people, if only for a few minutes.

I do a lot of networking, and most of it follows the same format – a bit of unstructured time followed by a meal and a speaker. I enjoy it, but being slightly introverted by nature I wind up talking to just a few people at each event - sometimes people I feel comfortable with, or sometimes people I get “trapped” with. In any case, I know I don’t always make the most of these situations.

Well, this format was great for that. I had the opportunity to meet almost everyone in the room, and there were some fascinating people there. The best part is that now I can follow up with those that are the most interesting contacts. For anyone that is new to networking, slightly shy, or just wants to try something different, I would highly recommend something like this.

Can a vacation really be a vacation

Remember when we used to go on vacation and not actually work?  Maybe you don't, but I do, back before the days of the Blackberry and even email (I know - I'm dating myself).

I've just returned from an eight day vacation, where I checked in via phone a few times, but did nothing more.  Did not check email, did not work, did not even read business books or magazines, which I do constantly.  I returned to 300+ emails, which frankly was less than I expected.  It took me all day Sunday to get through them, but for me it was worth it just to turn off work for a week and play.

My partner is now on vacation, and he has a different approach.  He's been on IM with me on and off all day.  He's also responded to almost all of my emails - even the ones that did not require an immediate response. The benefit to this approach is that he will not have the catch up that I had when I get back.

Now, I get that there are emergencies, and that client issues and opportunities need to be addressed, but for me personally, if I can spend the extra time up front to handle things proactively, arrange for coverage, and be somewhat available for the few things that can't be addressed by others, that's preferable.

I love my job, and I'm passionate about my business, but I also love my hobbies and my time with my friends and family.  I've tried it both ways - working every spare minute on vacation (my husband hated it!), and this last time not, and found this last vacation to be one of the most fun and relaxing I can remember in ages.  For me this worked, but I respect my partner's decision to do it another way.  At least he won't have hundreds and hundreds of emails to read on Sunday!

Results vs. Face Time

Every time we hire a new team member my partners and I have a conversation about whether or not, and how often, they should be in the office.  I'm of the opinion that as long as they get the desired results it doesn't matter. One of my partners feels strongly that they will not become a "real" member of the team if they are not in the office.  I understand this point of view, certainly it is harder to form a relationship with someone you don't see on a regular basis, but I don't think it's impossible.

We currently have a team member that works offsite more than 90% of the time.   This individual is a great communicator and has a TON of personality.  He calls and IMs all of us regularly (multiple times a day).  Even though I can count the number of times he's been in the office, I feel like we're all forming a good, strong relationship with him.  Sometimes I wish he was here more often, (he's an absolute riot) but I know he's more productive at home, and truthfully we're probably all more productive when he's not here.

Who knows what it would be like if he was here on a regular basis, but I really believe that with modern communication tools (VPN, IM, etc.) we can have the best of both worlds.

Project Turn-around – Crisis Intervention

Several years ago a client of ours was on a collision course with a brick wall while developing a new product. As usual the project was 6 months behind schedule, the client’s customer was extremely unhappy with no delivery and no one had had confidence that the project would be complete at all.

That is when I was hired. Fortunately I had worked with this client before so I knew who really knew what was going on. I was able to obtain copies of the specifications and project schedules. As expected both were incomplete. The project schedule was based upon delivery dates not the actual level of effort to perform the individual tasks. I asked management what leeway I had to effect changes. Quite a bit, actually, as long as the project was completed “successfully”.

I gathered the development team around and asked why is the project where it is. There were so many reasons but the main thread was that no one knew exactly what was expected of each and none believed or bought into the published schedules. Of course the requirements specification was weak, aren’t they always, but surprisingly the team seemed to have a pretty good idea of what the product was supposed to do. They also wanted to succeed.

Following a review of the documentation, code base and the issues stated by the development team, I was able to formulate an approach not yet a project plan. I recommended to management that all software development stop immediately. That we needed to complete the requirements definition ASAP, get management buy-in and then focus on the architecture. Fortunately the underlying technology was not an issue. Once those two items were taken care of we could produce a new schedule with buy-in from each developer. I was also able to determine if we had the right mix of skill levels. I noticed we needed a senior DB designer and a Software Quality Assurance person to be embedded in the team. Management was agreeable.

Finally the personnel were in place and a new project plan was published. Not exactly the dates management wanted but they were prepared to give us a chance to prove the turnaround. A key component of the new schedule was demonstrable milestones that could be shown to management and to their customer to gauge progress. I believe that was essential in management’s decision to approve the schedule. So how did we do? Well, there were many bumps in the road but the process was transparent so we could address issues early. The product was ready for delivery very close to the schedule’s published delivery date and the end-user was NOT ready. Finally the product was installed and turned over to the end-user.

Then I took a vacation!

You haven’t worked in our Industry

Here is a question I hear when working with new clients in different industries. How can you help us if you don’t know our market? Over the years I have tried to be vertical market agnostic in the pursuit of technology solutions. So when I come across this question I am ready.

My reaction is that domain knowledge does matter however the application of technologies that work to solve similar problems in different industries could be just as helpful. I find that just by mentioning a related problem encountered elsewhere and discussing how we solved it and the technologies used really brings the client on-board fast.

Technologies come and go quickly, much faster than typical product innovations. Companies used to certain communication mechanisms or display devices may not see the exciting changes happening. Certainly not all technologies are applicable in every market however many are and the challenge is to choose carefully.

Is source code control for everyone?

Sometimes I encounter clients who do not have source code control. Actually they say they do because ALL of the source code is on the programmer’s computer. It is all in one place, we can agree on that!

Most developers would agree that when a team of programmers is working on a project you need to have managed source control. But why not even for a single programmer project? It is true you don’t have to worry about merging changes from multiple programmers, but you do need to know exactly what code was included in each release. It is also helpful to be able to roll-back to earlier versions for the solo programmer when looking for the impact of changes that may have introduced bugs.

Today there are many source controls tools to choose from, including open source versions. There really is no software development project too small that would not benefit from source control.