It’s important to not let that scarcity drive you to making an questionable hire.  Here are 4 simple things you can do to reduce your risk when hiring new developers:

1) Find the developers’ apps at the various app stores, download them and try them out. Look for the attention to detail and the overall quality of the app.  Does it look clunky or can you tell it’s really well done?

2) Does the developer have experience on more than one platform?  Do you need more than one platform?  How well can you deliver your intended experience on various mobile platforms and how can the developer help you with decisions and tradeoffs?

3) What’s your strategy for deciding between native or web apps, and does the developer you’re looking at match up well with that strategy?

4) Do you want the app to be created with tools that can accelerate development? The Titanium platform from Appcelerator is a good example.

Writing a Fixed Contract for an Agile Project

Or you hired a big consulting firm, who studied your business and your market, made some predictions about the future, and then spent months and meetings to get the specs right.  Then more months and meetings to create a beta version.  Then more months and meetings to revise the beta.  Two or three years (and lots of dollars) down the road you got software that was now a year or two too late.

I gotta say, there is a better way.

I think every software development project deserves to have a champion, someone who will sit down and look at the cost and time ramifications of your decisions, our decisions, the whole decision process.  I call this champion a Program Director.  Rather than get snagged by short-term pressure and near-term worrying, Program Directors can zoom out, see the long view, and ask: “What would happen if we did A in this iteration but saved B for the next iteration.” In other words: let’s pause long enough to determine the best way to do this. Are there some use cases we’re already developing that accomplish what you’re getting at? Does the situation require that we build a whole new feature, or does it just require changing the existing use case a little bit? That bigger picture thinking is what the project manager provides.

Working with “far-located” teams – as we do in the globally-sourced world of software engineering – there needs to be a hub, a central person holding everything together.   Program Directors become the “glue” that binds all the far-flung elements working on a project into a cohesive whole.

Like so many things in business, you may not always see the need for that extra managerial layer when everything is working smoothly. Program Directors may appear to be doing little more than taking notes and sending emails about what’s already happening. But the minute you suddenly need something that you didn’t realize you need—a new upgrade you weren’t expecting or a new platform that you hadn’t planned for—those are the moments when having a manger with technical expertise advocating for your needs to the programmers is an invaluable asset.

Likewise when something fails. When you need to figure out why it failed, it is invaluable to have somebody who was neither on one side or another. Then your Program Director can be the referee or—better yet—an ombudsman. Can you get the job without that ombudsman? Sometimes, yes, but sometimes you really can’t. And that’s the point. What is at stake far exceeds the cost of having an ombudsman. On a lot of projects his primary role is to coordinate the flow of info. But on every single project, as we all know, there’s what you plan and there’s what happens.

A scientist knows he needs a built-in safeguard to protect against confirmation bias; it’s basic to any research design. A good scientist will actually spend quite a bit of time trying to disprove his hypothesis. He may even go so far as to enlist another scientist with an objective point of view.

So why don’t we do the same in business? Sometimes we do. We hire consultants who don’t share our presumptions, beliefs and expectations. This is a large part of the value a consultant brings; he or she is able to challenge the prevailing belief system. Too often, though, people who don’t share our biases make us squirm. We question their loyalty, wonder if they’re team players, and spin our wheels defending our existing beliefs instead of simply sitting with the discomfort and taking action, based on the facts. In fact, we sometimes avoid fact-finding all together if the implications are more than we’re willing to look at. This is how business activities—and business relationships—get backlogged or sidelined.

We’re somewhat predictable, we humans: people will opt for a pleasant thought or pleasing future-scenario over an unpleasant one any day of the week. And we’re also over-stimulated. Who doesn’t take in far more information and detailed bits of data than s/he can realistically process in a day? This is also part of the puzzle. No wonder we push aside unpleasant details that conflict with our preferred view of things. It’s a problem that’s as old as the hills… or at least as old as the Greeks. As Thucydides wrote nearly 2500 years ago: “it is a habit of mankind… to use sovereign reason to thrust aside what they do not fancy.”

In software engineering, the playing field is the process called implementation. When software engineers test run new software, each play revolves around a “user story” and the equivalent to game footage is the QA feedback loop that helps engineers work out the bugs. Success in this game is a bit more complicated than a simple score, of course, but it is all about getting a team to work together to turn client ideas into great software.

Chief Methodologist Scott Ambler (Agile and Lean with IBM Rational) recently conducted a survey to evaluate just what constitutes “success” in terms of the Agile software development model.

Of particular interest to me was his evaluation with regard to geographical distribution of software engineering teams. Although disappointed in the response to his survey (he’d hoped for 1000 responses but only got 279), Ambler drew some interesting conclusions regarding “far located” vs. “co-located” teams. Far located teams are those with developers and stakeholders working together from various locations around the globe, whereas co-located teams have key team members and interested parties situated in a single workplace. Ambler’s survey showed that co-located teams were measurably more successful (70% compared to 55%) at implementing user stories than far-located teams.

These results piqued my curiosity so I decided to investigate using his research to measure our success. I took a look at four months of recent software iterations for our biggest client and discovered the following:

As you can see the success rate of our far located development team was higher than Ambler’s surveyed teams that are co-located. Curious. What makes our team different? And are the conditions they work under replicable?

Ambler has identified the main problems far located teams face by boiling them down to these three: communication, time zones and cultural differences. In other words: put a bunch of non-native English speaking engineers from a distant land to work on your project while you’re fast asleep on the other side of the globe and you will be hard- pressed to achieve a high success rate. This seems obvious to me and is exactly why I developed the structured business model I’ve been refining for decades: globally source the highest quality developers, and locally source the highest quality client account and program management professionals. That’s how you overcome the communication, time zone and cultural difference challenge.

There you have it: my recipe for success.

It’s nearly impossible to live in Silicon Valley and not be privy to Steve Jobs stories—how great the man was, how difficult he could be. Like so many people in our industry and around the world, I feel his death as a personal loss even though I never formally met the man. Perhaps his influence on my own career explains this personalization of the loss. Long before I stepped foot on peninsula soil, my college roommate and I drove down from Providence Rhode Island on an exciting excursion: to see the new Mac. It was like nothing anyone had done before. It broke the rules. What a turn on. Shortly thereafter, I took a job at a small Mac software company that was eventually acquired by Claris. The next thing I knew, I was pulling up my east coast roots and moving to California.

Remembered as much for his iconic presence as for the remarkable role model he was and is, Steve Jobs showed me—and all of us—an inspiring way to live. A way that trumps setbacks and small thinking. A way that leads with the heart and pursues wild dreams. A way that proves the value of staying on course, true to ones’ vision. A way that shows how clear, critical thinking is absolutely key to innovation and creativity. Steve proved that the desire to build something great was a revolutionary act that could turn the world’s head and make it a better place. He also showed us about tenacity, about looking beyond the next quarter or the next year into a future that only emerges when failure is not an option.

Steve showed us that being down or even out doesn’t have to stop you from moving forward and taking what comes, for better or worse, in terms of public and private opinion. Steve did what he believed in, even when detractors and critics reviled him. His was a truly visionary eye, one not easily blinded by ups and downs. Daily stock prices? Who cares when you really are the coolest dude on the planet? I suspect that Apple rose to being the world’s most valuable company as a result, not as a goal. Steve’s leadership made that possible. I also suspect that what mattered to him most was creating things that pushed the envelope. But what I, personally, will always remember most is a comment he made about the heaviness of success and the lightness of being a beginner. Would that we could all remember to look at the world fresh every day. It’s a great way to live and a smart way to do business. I’ll hold onto that thought in my memory of Steve—a remarkable man who showed all of us the way forward.

Problems arise when “vision” turns into tunnel vision, however, and acts more like a blinder than a guiding light. I was recently taken by surprise and blindsided in just this manner. After several years of dedicated focus, I began to realize that my vision for my company had actually altered my perception. Like most of us, I saw what I wanted to see and, in so doing, misread incoming information. My selective listening caused me to miss important details in both internal and external communications. Having missed a few key signals altogether, I didn’t ask the right questions, didn’t see the proactive steps I could have taken, and imagined everyone was aligned with my vision. That assumption is now an open question, and this is a perfect time for a “reality check.”

Of course, hindsight always has a broader frame of reference than vision, so it’s important to keep moving and not get stuck. The past cannot be changed; it can and does inform the present and helps us see what’s up ahead. Engineers know that the best way to improve software is to try it out, find the limitations and re-make it stronger. I have a sense the same is true for vision.

This week I am reminded that business is just a shared idea.  In the short run, life and death will trump business every time.  This week we memorialized and remembered that awful day, 10 years ago, when thousands of people who showed up for work on a Tuesday morning were senselessly destroyed.  Whole businesses ceased to exist.  Fathers, mothers, children, friends, all were caught up in a life and death tragedy that was, through no fault of their own, maliciously imposed on them.  In those horrifying events, and for days, weeks, sometimes months after, all thoughts of business and contracts and corporate objectives and departmental strategies became meaningless.

Also this week, a client of our enterprise took his own life.  I don’t know why, I may never know why, but I know that his demise eclipses all our mutual business plans and needs for awhile.

So, instead of blogging about outsourcing and software engineering services today I want to remind myself, my employees, my clients, my associates, anyone who is reading this, that in the end, the asset we are managing is people, the inventory that matters is people, the word “business” describes a human-relationship-centered activity.

If you have kids, hug your kids tonight.  If you have a partner, tell your partner what they mean to you.  Call your parents, have a drink with your friends.  Celebrate life.  There will be time to get back to business later.

You follow the proper channels, working with the managers, and the same story – not much is happening. Now the whole cycle repeats. You start to wonder, “do you WANT to work with these guys?” Will they treat you this way when (and if) you are actually working together?   Maybe you’re not going to be able to get your backlog worked on in a timely manner despite lots of risk analysis from your PM team.  Maybe these are not the guys you really want to work with after all…

When the basic product you deliver is code, it’s crucial to remember that people create the code. You can manage people. You don’t have to manage code. Code doesn’t complain. Processors can run all night, every night and never kvetch. If they’re deemed too slow, they can be replaced by faster processors. Unfortunately, none of that is true of the people who write code and the people who build the processors. Unlike code, software engineers need time to sleep and eat. In a ideal world, they also have leisure time to spend with their families, go on vacation, and enjoy the simple things in life. Unfortunately, the average IT department sits on a precarious precipice: one that verges on toxic for the average family man or woman. I see it all the time when visiting a customer’s location. Management puts pressure on the tech department, knowing full well the typical geek is predisposed to overwork. Sadly, the ripple-effect of this bad habit hits the shore later as one or many from a list of undesirables:

Staff turnover

-       Reduced productivity

-       Resentment

-       Bugs and errors, and

-       An unpleasant work environment

I got into this business for one reason and one reason only: it’s fun. I hire people who share that enjoyment. I’m a big fan of leisure time and know how to make the most of mine. I encourage the people who work for me to do the same. I think that is one big reason we enjoy the challenge of software engineering so much. The satisfaction that comes with solving a problem nobody else has been able to solve is hard to beat. Likewise building a piece of software that’s never been built before.

I hope our  customers never forget that we are people, not code.