Capacity Versus Competency


This is a lesson in hiring software developers in Africa where, for the past two years I’ve run an incubator/software company called Appfrica Labs. As a social venture, the blended model was designed to give East African graduates jobs in tech and allowing them experience the ‘real world’ of development. The secondary goal was to help NGOs, non-profits and local businesses to avoid hiring from abroad when hiring local means creating jobs, knowledge transfer opportunities and it encourages local participation.

That’s a logical approach to a logical problem. However, the world is not a textbook, so here’s what I’ve learned from actually working with individuals, NGOs and businesses respectively. Most of this actually applies to managing software teams all over the world, but I’m talking mostly about my experiences in Uganda.

Developers…

…often over underestimate the time it will take to finish jobs because they overassess their own skills. This article proposes that programmers have four levels of competency: 1. unconscious incompetence, 2. conscious incompetence, 3. conscious competence, and 4. unconscious competence. Developers falling into category 1 are the most common to exemplify this behavior. It’s not intentional, it’s just the nature of inexperience.

…sometimes are offended when asked if they have basic skills (“Do you know how to use Excel?”). However, not asking those questions is asking for a disaster so testing for things your organization needs up front, is definitely necessary. Skills, Logic and Communications tests.

…can be extremely late. In Africa especially, test people on timeliness. I’ve never met an employer in this country (Uganda) that hasn’t had problems with people not showing up on time or not explaining absence.

…have a hard time telling you when they don’t understand something, can’t complete a task or aren’t making any progress. Again, it goes back to 1 and 2 on the programmer competency scale. I’m not sure whether it’s pride, fear or learned behavior, but at least with the people I’ve met, questions are rarely volunteered.

…for some, it takes a long while to figure out that deliverables aren’t necessarily delivered when they’re late. If the client needs it by the 5th and you give it to them on the 15th, there’s no guarantee the client still needs the work.

…tend to consider attention to detail a chore as opposed to simply part of the job. Chores can be passed off, ignored, and forgotten. This creates a huge disconnect with people who consider even the tiniest details part of the job.

…need a full time project manager who understands tech, and understand how to manage developers. If your company can’t afford one, I’d think twice before hiring a single developer. Instead contract, and even then proceed with caution in how you do manage projects.

…often realize way too late that working for themselves doesn’t just mean working on all the fun apps they’ve always wanted to build.

…can burn out. It’s not enough to ask them to take breaks and vacations….force them to take a week long paid vacation every now and then. Think of it like watering your plants more frequently rather than less frequently (do not pour water on their laptops)!

NGOs…

…need to understand that capacity building is a longterm investment that will sometimes conflict with short term goals.

…aren’t really looking to simply ‘build capacity’ unless they have an explicit grant to do so. This is because they too have deliverables and non-delivery is just as bad for them as with their management as it would be in a for-profit business.

…even if they want to contract locally, it sometimes conflicts with their given mandate. It’s the capacity/competency conundrum. Do they do things that work now to save time and money? Or do they put in the extra time and resources to make sure the task is done right, locally? Neither is right or wrong. It’s a choice.

…often don’t understand when they lowball on pricing, they’re inadvertently creating unforeseen future expenses when things go wrong later.

Businesses…

…often have a difficult time balancing costs vs. desire. They want ‘x’ for the price of ‘n’. Usually ‘x plus n’ for the price of ‘x minus n’. This is true all over the world. ;-)

…need to pay you in portion on contracts, up front. When two parties enter into a contract together, they are both taking a risk — the risk that the other party will default. If you do work and you don’t get paid, you’ve taken a risk and lost. If the business pays you and you are never seen again, they’ve taken the risk and lost. Thus you should meet each other half-way.

…should be reasonable enough to make concessions when the problem is their fault. In my own case, running a company that offers client services, I’ve offered to return the money of a handful of unsatisfied clients, not because it’s ever easy, but because it’s the right thing to do. If you put your customers first, it’s an easier decision to make. They may not work with you again, but they’re definitely less likely to run around slamming your staff or your company. Clients that can’t recognize when their vendors are looking out for their best interests, in my opinion, aren’t good clients.


At the end of the day, capacity building is an explicit choice. I chose to do social entrepreneurial work here with local developers because of the long term impact. However, this sometimes is in direct conflict with running a business — which usually entails the most competent, educated, loyal, dependable, respectful and efficient people you can afford. Where is the balance?

In a double bottom-line business, the money and the mission can end up on opposing sides of an impossible chasm, especially when you have limited resources. My advice to people looking to build local capacity in tech, in developing countries, is to essentially a draw line somewhere in the sand and decide how much of each matter to your vision. You don’t need a pie chat, but have a mission and adapt where necessary. But don’t budge just because you’re stressed or scared you’ll fail. Long term investments require long term resolve.

If all else fails, just add water.

Photo by CaptKodak


Share and Enjoy:
  • Twitter
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • muti
  • StumbleUpon
About the author: Jonathan Gosier is a UI designer, software developer and writer. He currently lives in Kampala, Uganda where he incubates and invests in East African entrepreneurs as the CEO of Appfrica Labs. He's also a TED Fellow.
This entry was posted in Business, Culture, Development. Bookmark the permalink. Trackbacks are closed, but you can post a comment.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comment moderation is enabled. Your comment may take some time to appear.