A Celebration of the Fastest Growing Companies in CT

This week the Connecticut Technology Council held one of my favorite events – the Marcum Tech Top 40 – celebrating the 40 fastest growing technology companies in Connecticut. It’s so much fun spending an evening meeting such successful people and reconnecting with old friends. We have been lucky to have the opportunity to work with many of the people in the room.

The diversity of the companies is amazing: from online travel service Priceline.com, to oil-drilling equipment manufacturer APS Technology, Inc, to vaccine maker Protein Sciences Corporation, to IT Services provider OpenSky, the overall winner with 18,221% growth!

One thing I can’t help but ask myself is: what makes some companies so successful while others struggle? Listening to the speeches of each category’s winner, there was one common answer – the team. I’ve always believed that a small, talented, focused team can accomplish amazing things, and these CEOs were saying the same thing.

Congratulations to this year’s Tech Top 40, and to all those who aspire to join them – my best advice – surround yourself with the best and brightest you can find.

Making the same mistakes

I hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or - fill in the blank.

Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!

Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”

Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?

A sad yet preventable story of software failure

I read an article today reporting that Nokia had announced that it was abandoning its development of its own Smartphone platforms and APIs. By itself, that’s not so sad. It’s smart to know when to cut your losses, right? The reason this story makes me sad, is that it was entirely preventable.
According to reports from insider Mark Wilcox, “there was no proper requirement spec for this new framework.” Aggghhhh! This makes me crazy every time I see it, and I see it a lot.
Companies think they can save time, or they don’t want to be “locked in” or say, “We’ll just tell the developers what to build.” In 20+ years of personal experience, I’ve never seen this work well. In the very best cases, tons of time is actually wasted by long meetings, miscommunications, and do-overs. Usually the end result is not really what the project sponsor wanted, but they settle. In the very worst cases, like this one, companies spend 2000+ man-years (yes, you read that right) developing something no one wants! In this case, they had two competing teams (I’ll have to address that in another post – just too much to say on that one!) and according to Wilcox "both teams had built the wrong thing.” Both teams! (This post may be my personal record in use of exclamation points.)
Another comment he makes is that “the engineers were incompetent. Now by that I don't mean that they're incompetent engineers – far from it. They were incompetent at designing APIs for 3rd party developers (a very specialist engineering skill) and they were incompetent at designing UIs (which most engineers are, myself included). Unfortunately they were doing both.” These could have been very bright engineers, but as Clint Eastwood said in one of my favorite Dirty Harry Movies, “A man’s got to know his limitations.” This also happens frequently and is an error made both by engineers (ego, desire to learn, fearing for their job security) and management (don’t want to hire specialists, over estimating their engineers). Again, in the best cases I’ve seen, the engineers can muddle thru and get something passable. On the other hand, it can be a train wreck as in this case.
The aspect that makes me the most upset about this story is the effect on all those engineers. They worked hard, I’m sure long hours at times, to develop basically, nothing. We engineers develop software and products because we take pride in our work and want to build things that people love to use and these engineers spent years not doing that. I can’t even imagine how unfulfilling that was.

How to tell your customers they’re wrong

We often find ourselves telling our clients they’re wrong. Of course, we don’t say it like that – “You’re Wrong! Mr. Client!” No.

Sometimes they have a problem and already have a solution in mind. Our engineers can often tell very quickly their solution is not going to fix their problem. These discussions are usually easy. The engineers can come up with better solutions and it’s obvious we’re working in our customers’ best interests.

But what if you think they’re solving the wrong problem? This is a much more difficult conversation. Especially, if they are passionate about solving a problem that you don’t think is a problem. Maybe you’re not the one having this problem, but other’s are. Maybe they’d appreciate the solution. Who’s to know?

I heard a great suggestion on how to handle this just the other day (Thanks CS!). I love it because it’s open, and honest, and all about starting the relationship off right. Just ask – at the beginning of the relationship, or conversation, or wherever you happen to find yourself, just ask if they’re open to questions about their assumptions if you hear something that does not make sense. It might sound something like this “You know, Mr. Customer, sometimes I’m talking with other CEOs and they say things that just don’t make sense, they find it very helpful when I question these statements. Is that something you would find valuable?” I’d be shocked to get a no, but whether they say yes, or no, at least you know where you stand. And who know, you may just learn something.

KAUST: An Amazing Example of Project Management

As part of my experience with the Global Women's Leadership Institute, we were treated to a presentation on the creation of King Abdullah University of Science and Technology (KAUST) by Nadhmi Nasr, the Executive Vice President of KAUST. What an amazing story!

This incredible, 9000 acre, state-of-the-art University was built and operational in approximately 1000 days. Mr. Nasr was asked to take on the leadership of this important project by the King in July of 2006. He assumed that he was responsible for building something that had already been designed, but within a week, discovered that it was just a concept. He quickly brought in partners, consulting firms with various specialties to help with the planning, which he attributes as one of the keys to his success.

Mr. Nasr is very humble. It was apparent in his presentation that his unwavering focus on the vision was, in my opinion, by far the most important reason for the success of the project. I know software companies that have not been able to build a product in 3 years. This man was able to create a magnificent oasis in the desert, taking it from an idea to a thriving high tech community. On September 5, 2009, the first day of classes were held on schedule. Having managed many projects myself, and being here and seeing how incredible this place is, I’m in awe of what he’s accomplished.

Stop Trying so Hard

Last year one of our big initiatives was to find strategic partners – companies we could work with, offer more to both of our clients, and help both business grow. We really did look hard and didn’t have much success.

When doing our business planning this year we decided to try other things. After all, that did not work out so well.

Well funny thing is happening – all those valuable strategic partnerships we were dreaming of seem to be falling into place. Who knows where they will lead, but it sure is funny that they’re happening now. Maybe there’s something to the theory of relaxing and letting things happen. Sure seem to be working for us!

Is the buying cycle different for services vs. goods?

I’m a shopper. It’s not that I like to shop, but when I do, I tend to shop around, read reviews, decide what I want then try to find the best price. But – that’s only for goods – computers, printers, cell phones, cars, an oven, etc. I recently noticed when shopping for services (or hiring which is kind of like shopping for services) I tend to make decisions MUCH differently. The funny thing is that I make those decisions much more quickly with much less comparison shopping, even when the dollar value is higher.

One example – we recently hired a marketing agency (Response Marketing – check them out they’re awesome!) and although my business partner and I had not intended on hiring them, or any other marketing agency, we had made our decision before our contact had gotten into the elevator. Now, we both know of many other agencies and sole practitioners, so why didn’t we shop around? Easy – we like and trusted the owner of this firm, we were comfortable with the price, and we believed that they could help us.

I find comparison shopping for services to be somewhat problematic. After all, you can’t assume that a $100/hour service provider is better, worse, or the same than a $150/hour service provider. It has everything to do with the person or company and their process, and if you feel comfortable with them. On the other hand, an iPhone 3Gs with 16 GB is an iPhone 3Gs w/ 16 GB (not that you’re going to get a deal on that). When shopping for a service provider, I want someone I am confident is going to do an excellent job. On goods – I still love a good deal!

Is Contingent Staffing a trend?

I read an article today that talked about Contingent Staffing, which they defined as the use of temporary or freelance labor, as a trend. I don’t agree with this. This is nothing new; companies have been doing this forever. I think what we’re seeing is a cycle. We have noticed in our business when the economy is booming companies want to hire full time people, to minimize the “brain drain” when the contingent folks leave, and impacts in internal morale from hiring them in the first place. In 2004-2006, we were seeing far more opportunities for full time placements than consulting engagements. Conversely, when the economy struggles, companies still want to complete their projects so they hire temporary or contract labor, as their doing now. I suspect in the coming years, we’ll see the pendulum move back towards a more balanced approach of full time people and contract, temporary or contingent workers.

What do you think?

Feast or Famine in Software Development Organizations?

In so many areas of my life I go thru these cycles of feast or famine – social engagements, work load, car problems, what have you. I either have lots or none, or is that just my perception?

There’s one area that I can think of in which I’ve never had this problem – the software development organizations I’ve been a part of. Sure, we’ve had that with bugs, or turnover, but never, ever, ever workload. There was ALWAYS more than enough work to do. Maybe it’s just the nature of the beast – companies always want to improve their products and there are a wealth of ideas on how to do that. It’s also a positive thing. I love being busy, and if a company can not keep it’s developers busy, why does it need them?

The downside however can be a feeling of overwhelm, or inefficiencies, or continual long, long weeks. What kinds of things can we do to smooth this out a bit, or at least mitigate the negatives? I have some ideas:

1) Prioritization – so many organizations are SO bad at this. The priority is the priority of the moment, based on the loudest customer, one data point, or the whim of an executive. A well thought out prioritization can allow your development teams to get more done, just by finishing what they’re already working on. I’m not saying it should never change, but it certainly should change less frequently than you change your clothes.
2) Focus – knowing the big picture will help with number 1, as well as with coherency of design and team morale. If you’re building something to do x, don’t try to do y. Pick one thing (at least to start) and do it exceptionally well
3) Learn to say “No” – I find that people (not just in development organizations) spend an inordinate amount of time exploring roads not taken, as in “maybe we should have done x”. I once heard a speaker call this “Killing the un-chosen alternative.” I like that, and not because I’m violent – I’m not. I like it because it allows you to devote 110% of your attention to being successful on the path chosen and stop second-guessing yourself, a time wasting distraction if there ever was one.

I for one hope there isn’t a famine of new product ideas or developers to carry them out. Let’s just try to do it sanely.

Self-regulation in Software Development

Senia Maymin (I can’t link to her website for some reason – I’ll update this when I can) has written a bunch about a concept called Self-Regulation. This concept fascinates me. It’s one of those things that’s simple – particularly to understand, but certainly not easy. It’s the skill that you use to do the things you need to or should do. The idea is that self-regulation is like a muscle and the more you use it (in any area) the stronger it gets (in every area.)

It’s easy to see how it applies to my life – go to the gym, make my sales calls, blog, etc. I always thought that once you did those things and saw the benefits, you’d do them again BECAUSE you saw the benefits, but the way she talks about it, it’s less intellectual than that. The more you do these things, the easier it is to do other things. But how does it apply to the field of Software Development?

It’s easy to see the areas where you might need self-regulation, testing, documentation, and perhaps for some, design. Does this mean that if you make yourself do a good thorough design it will be easier to make yourself do the testing or documentation? Well, it’s certainly easier to do those activities for a well designed system, but is it easier to get yourself motivated to do them? Interesting question – I really don’t know…

Hiring engineers now is easy, right?

Wrong!  I’ve run across quite a few people in the past year that have assumed that’s the case, but have found out differently.  Hiring top software programmers and hardware engineers is always a challenge.  Having piles and piles and piles of resumes does NOT make it any easier.

So what’s a hiring manager to do?  Well, the last hire I did for myself (as opposed to the ones that I help our clients with) I had four very clear objective criteria.

1)      The candidate had to have a Bachelors’ degree

2)      The candidate had to have experience with a specific program

3)      The candidate had to have at least 2 years professional experience

4)      The candidate did not require H1-b sponsorship

One of our clients is doing this now with good success.

Now, I know you can make valid arguments against any of those hard and fast rules.  Some of the smartest people I know don’t have college degrees.  In different times I might have made that argument myself (might be good idea for a blog entry next year), but you need some way to get through hundreds of resumes a week.  The nice thing about objective criteria is that a hiring manager can get help – someone to prescreen for him.  So what are your deal breakers?  Knowing that going in will make hiring in these times much easier.

I’m sure all you job seekers out there are saying “That’s not fair!”  You’re right, but as my mother always said, Life’s not always fair.  So what’s a job seeker to do?  Well, I need something to write about next week…

Peer Coaching - Improved

I recently read about an interesting company – The Alternative Board. They provide facilitated peer coaching for business owners and Presidents.

I think this is a great idea. I’ve have good experiences with peer coaching. A group of bright, experienced business people with diverse backgrounds can figure out anything. The only downside for me is that sometimes these groups can go off the tracks. The conversation gets high jacked by one person, or the topic of the day does not really get covered, or all the great contributions don’t get shared.

It seems to me that adding an experienced facilitator would not only maximize the contributions, it would also maximize the benefits to all the participants.

Full Process Review or Quick Fix?

Lately we seem to have so many consultants interviewing for so many opportunities it's hard to keep track of all the details. We do have some tools in place but they're not enough. When the "pain" gets to be too much we've been creating quick fixes to relive the particular difficulty we're having at the moment.

In a casual hallway conversation, we were just about to do this again, when it dawned on me that we had not really looked at our end-to-end process and inter-relationships between Sales and Consultant Services in a while. Certainly not since our business volume has picked up. My Software Development background kicked in and I suggested we take a step back and do just that.

I know that when we're moving so fast, it can be tempting to just address the immediate issue, but sometime a more holistic approach is the way to go. The trick is in knowing the difference. I think, just like in Software Development too many quick fixed can create a mess really quickly. In this case, we had been doing the quick fix thing for a while and it just seemed like time to look at the big picture.

The Value of Business Planning

Today begins our fiscal year. We're just finishing up our third business plan as a team. Not only does it get easier each year, the business plans just keep getting better and better - more realistic, more detailed, and more actionable.

When I was running development projects, I never proceeded without a plan (ok, well almost never). The value was apparent, we needed to know what to do, what we could do by when, and how we were going to do it.

Our business plans have been much more challenging. Certainly, the scope is much broader than even the largest development projects. The subject area is much more diverse, and the external factors (i.e. will anyone buy what we're selling) play a much more critical role.

But the value is indisputable. We execute better and better each quarter. Having those specific objectives and initiatives really focuses us, and the three of us have been great at keeping each other on track. It's so easy to get lost in the day-to-day and forget that we want to move our business forward. The business plan (1 year and 5 year) is the best way we've found to keep moving towards our long range goals. I'd advise any leadership team of any size to develop some sort of plan to help them balance the short term and the long term.

The Dangers of Micro-managing

What’s one sure way to get the least out of your team? Micro-manage them. I’ve seen this again and again – Micro-managing, or supplying every little detail and expecting every little comment you make to be executed literally will quickly shut down their brains.

I saw this with one of our consultants. He was working on a project where the manager had very specific, non-explicit requirements for how the solution was implemented. After two or three of his suggestions were shot down, he stopped making them. The funny thing is that his suggestions would have made the product more robust and maintainable. Even more interesting than that, this senior developer started asking me how to implement specific lines of code. I have not coded in 10 years, but I understood why he was asking and what he needed. He wanted to give the customer what they wanted, and knew they had very specific ways they wanted it coded.

Thinking about my own management style, I think I may err too far in the other direction. I’ve been told, more than once, that I have made my directs uncomfortable because I don’t tell them exactly what to do. I do try to make sure they know I have confidence in them, and that I’m there if they have questions, but sometimes it still seems like they’d like very specific direction. My question is: Is this just because they have become used to being micro-managed, or is there a middle ground that I’m missing?

Virtual Development Teams

Sometimes when I read about trends, I wonder if they are “real.” How many people are actually doing it and is it working for them? I am getting to see one trend in action more and more often lately – virtual development teams.

I’m working with a few companies that are completely virtual – no one works in the same physical location. Right now, I’m even looking for a developer to work with one of these teams. One of the many benefits of this arrangement is that we can look anywhere, and I do mean anywhere.

I’ve managed individuals that worked in remote locations, and teams that were in multiple locations, but never a team where no one was co-located. The most interesting thing about this engagement is that the client is ok with not meeting the developer. I’m not sure I would have been but in this case I can see why. They are looking for someone with Open Source experience. They’ll be able to see real code this person has produced, and see how this person interacts with another virtual team. This is so much more revealing than the typical (or even a good) interviewing process.

The broader implications of this are fascinating. Are we really moving towards a true talent market where we can work with the best of the best, from anywhere in the world?