I am David McCann and I’d like to tell you that UNICEF Uganda is hiring. If this job description seems dauntingly ambitious, that’s because it is. The Uganda office must quickly replace the software lead for their three RapidSMS deployments, which have in the past years achieved unprecedented scale and complexity within the RapidSMS community.
With little time to ensure a seamless replacement, UNICEF Uganda are attempting against all odds to find someone who can hit the ground running to manage a small software team with large goals. The current senior software engineer, unfortunately, is being poached by the prospects of competitive compensation. Poached, ironically by another UNICEF country office.
What Happened?
The cause of this quandary is directly linked to the difficulties of navigating the bureaucratic processes surrounding fair pay and promotion, a problem that isn’t unique to UNICEF but rather common to many large donor organizations. The U.N.’s system is quite complicated, including pay levels, pay “steps”, and different scales for consultants and general staff. While it does make most pay scales for staff positions publicly available, the specific formulae for arriving at a final, often non-negotiable figure of compensation for a particular position remain opaque.
At the heart of the matter in Uganda is a rule governing the distinction between “national” and “international” hires. But this is merely an illustrative example of the many symptoms and associated problems throughout the rules governing hiring and compensation.
The Problems Start with Country-Based Cost-of-Living
Calculating the cost of living within each country is the first obfuscated step in the process. In this case, it is at least feasible to collate and compare the U.N.’s figures (albeit with a large amount of free time or automated web scraping tools). Comparative data for cost-of-living between different countries is difficult to accurately quantify, so the reader can draw their own conclusions about the 3130% discrepancy between the hourly pay of New York and Malagasy staff at the lowest pay levels.
Faulty Heuristics
Another wrinkle to the proprietary compensation calculation occurs during the assessment of an applicant’s specialized skills in order to assign pay level. Giving preference to advanced degrees or professional experience is an acceptable first cut, but is typically accompanied by two flawed practices: the preferential weighting of specific skills (typically 10 years too old to be “cutting-edge”), and an interview process that is all-too-often conducted by non-technical staff with no experience of the field within which they are hiring. This leads to “a very warped marketplace” as one technology specialist termed it.
The complementary elements of this marketplace are a few consultants and companies within a very small pool of potential candidates who rely solely on their ability to reverse-engineer the pricing and bidding process, using donor funding to keep their sub-par work afloat. Other paperwork down the chain also contributes to the continuation of the status-quo: it often seems easier just to pay out a delinquent contract and vow never to hire the company again rather than prove they were delinquent (by a bureaucrat’s definition of delinquent, not an expert’s). The problem with this rationale is that the next project will be pulling from the same pool of resources and using the same selection process.
The Joys of Being “International”
The final straw, in the case of Uganda, occurred due to a refusal to budge on the distinction between “national” versus “international” consultancies. Data for this disparity are more difficult to find (see notes). In theory, this calculation is preceded by a “justification” step, in which it is first proven that a position cannot feasibly be filled by a national. One simple example of where this process fails and did fail would be a position that must initially be filled by an international hire, who then successfully transfers skills to a national hire.
In theory, the skills transferred have an implicit value, as is the case in most large tech shops. In practice, the skills at this point cease to matter as much as the rules governing “national” vs. “international” hires. This seems completely at odds with notions such as “capacity building,” and indicates extremely presumptive attitudes regarding foreign versus local labor.
Open Source as a Core Principle
These rules surely were put in place to promote fairness and deter favoritism, but a side-effect is that one UNICEF country office will poach the contractor of another because they can offer “international” rates where the other can only offer “national,” as happened in Uganda. Nothing could be more indicative of the current impossibility of building a software (or any other technologically innovative) shop within a large donor-funded organization.
While recent attempts are commendable, it’s clear that these organizations have faulty selection criteria and a lack of in-house technical skill for finding talent, and a completely broken model for retaining it if they succeed. Software projects especially hinge almost solely on their ability to locate and retain talent. If large donor-funded organizations truly want to innovate, this is a problem that must be solved.
In software development, if a particular software feature were to fail so thoroughly at its intent, or present a flaw so fundamentally absurd, it would typically involve intense debugging (with many eyes helping to find the problem) or a complete re-write of the logic to blame. In the administrative space, there are analogous solutions, the most incendiary of which would involve a complete overhaul of the process and the replacement of any administrative and HR staffers who have completely failed to grasp their organization’s overall vision of innovation.
As a software engineer, I admittedly don’t fully understand what true policy reform looks like, but I know this option would require a level of sweeping change and managerial buy-in that most large organizations can’t accommodate. I can, however, offer a software engineer’s solution to the problem, one where a top-down acceptance of the facts presented here isn’t required: “open-source” the processes used to hire specialized staff, and allow them to be scrutinized, streamlined and “debugged” by donors and those with pertinent expertise.
Publicize the rules by which technical staffers are allocated to pay levels. Document the particular companies that are surveyed to determine so-called competitive rates for specialists. Document experiences working with “Big Aid dependents,” the over-priced companies who exist solely to game the system, so that everyone can learn from past mistakes.
This is a strategy that can be implemented by anyone willing to publicize their experience with administrative processes while working at any donor-funded organization who claims to support innovation in development and to practice open-source policies with their software, while refusing to provide the same transparency to their bureaucracy.
In the long run, this will at best result in a better strategy for hiring and retaining specialist talent, and at worst demand the attention of those who are subverting progress in these organizations. After all, one must scrutinize the motives of any staffer (or consultant) within these organizations who would deliberately choose to maintain the status quo at best, or at worst actively sabotage projects like the one in Uganda.
Notes:
- http://icsc.un.org/resources/webapp/jde/login.asp?req=251364695 : Job evaluation system fails on modern browsers (chrome and firefox), requires “internet explorer 5.5 or later.
- http://www.unops.org/english/whoweneed/contract-types/Pages/Individual-Contractor-Agreements-ICAs.aspx : Vague Language
- http://www.un.org/Depts/OHRM/salaries_allowances/salary.htm#pr : Methodologies are over 80 pages, no clear descriptions
- http://www.sas.undp.org/portal/alias__SAS/lang__en-GB/tabID__3592/DesktopDefault.aspx : No explanation of p levels and steps, no explanation of “hardship/mobility” calculation, or “post adjustment.” The shortest navigation path to this document is from a Google search is via another open-sourcer’s article: http://www.rottmair.de/2011/01/04/contract-types-and-job-grades-in-the-un-system/
Thanks for passing this on. While I agree with many of the issues raised, I noticed that the option to procure the services of an software development organisation rather than recruit individual technical specialist was not mentioned. This is not always the best option however it does address some the points mentioned.
Ayman, thank you for reading! I think successfully navigating the hiring process, in the UN especially, is a broad and complicated problem, and the disparity in pay scales between national and international pay scales is just one facet of that problem.
That said, I did try to (extremely) briefly mention my personal experiences with hiring a company versus an individual. To elaborate a little, I would say my experience with companies was quite varied. While we received truly quality work from some, others certainly priced high and delivered low-quality (sometimes even incomplete) work. The “warped marketplace” discussion I link to has some subtext about this, to some degree.
The simple fact is that it’s often hard, within the UN framework, to withhold payment after you’ve hired a company, regardless of their output. It’s harder still to accurately evaluate the quality of the work without an in-house specialist to weigh in, which is why I ultimately see outside companies as a supplementary resource, and why I tried to emphasize the need for a staffed software specialist role at UNICEF, if for no other purpose than fulfilling this ongoing advisory need.
You have a point about the need to put the overall arrangement on a more sustainable grounding by having fitting internal competencies. It seems that the real problem is lacking quickly disposable and scalable internal software engineering and development manpower one call pull. Not by having them on stock piecemeal country office by country office. And as you are writing so well, not for doing all of the actual work, but for providing high quality oversight in specification, project management/monitoring and quality assurance etc stages.
Hi Stefan, thanks for the input. If we take as a given that things need to be reformed (and if I understand you, I think you do), the critical questions in my mind are:
1) What are the real needs/requirements of UNICEF (or any other organization) as a whole, and country-by-country?
2) What can realistically be changed about the hiring/procurement process, and
3) Of the things that can’t be changed, what is a particularly inflexible HR department likely to accommodate?
I think “quickly disposable and scalable,” if I understand you correctly, speaks to #1. If one of UNICEF’s requirements is “to provide better, more efficient aid through the use of technology”, i.e., to innovate, ongoing software development is a need that’s here to stay, continuously, and not as an intermittent request for one-offs. Unfortunately, many of those in HR don’t seem to understand this concept. While maintaining 3 websites with a team of 3 counting myself, I was asked, when trying to hire another developer, “Why do you need another developer? Don’t you already have two?” and also “how long is this project [referring to ICT4D in general] going to last?”
I’d agree with you that “piecemeal, CO by CO” is probably not the way to go, and speaks to #2: I have no idea what UNICEF is willing to reform within their current system. As a background to the uninitiated, I’ll admit that my proposed solution, a software engineer staff position, would require that such a position exist within every single UNICEF country office, according to existing protocols, as Stefan is pointing out. But then, I’d also argue that’s a broken way of doing things, and that protocol itself is part of the problem.
Which leaves #3. One way to achieve a “quickly disposable and scalable” source of personpower might be to build a cache of Long Term Agreements (LTAs) with a number of companies across a breadth of specializations. However here, again, the selection process is flawed (and resulted in us hiring many low-quality organizations), and I doubt that any HR department would allow what would be such a seemingly circuitous route to avoid more conventional procurement processes.
It’s a multi-dimensional problem, for sure. I would love as many insights as are out there, especially into the answers to question #2.
Excellent article – Spot on
“it’s clear that these organizations have faulty selection criteria and a lack of in-house technical skill for finding talent, and a completely broken model for retaining it if they succeed”
what about appealing to the hoards of people that generally waste their time on RHOK and CrisisCommons opensource efforts?
Witness the success of giscorps.org. Folks like myself that want to contribute would gladly volunteer online time if it would make a difference. Given bandwidth for Skype, WebEx, and GotoMeeting, I gotta believe you could get a huge amount done if you somewhat restructured more towards project management than competing for scarce software talent.
Hi Chris, thanks for the comments. I strongly agree that engaging open source communities is a must! I’d go on to make an even stronger statement that any software artifacts produced by donor-funded organizations should always be open source. UNICEF Uganda is good about always open-sourcing their work, and in general I think does a fairly good job of avoiding re-inventing the wheel.
That said, I see two major issues with leveraging FOSS communities for all the technological work for a particular project. The first is common to all “outsourcing”-style solutions, and that’s one of oversight. The problem isn’t typically that a good open-source solution doesn’t exist, but rather than many open-source solutions exist, and it takes some in-house expertise to be able to evaluate and choose. For new development work, it takes the same expertise to evaluate the quality of the output before incorporating it into an existing solution.
Second, more unique to FOSS, is that most people donating their time (myself included, these days) tend to be far less interested in spending their free time fixing bugs in an issue tracker, or building features that are heavily customized to one particular project. People like building frameworks, and the open-source movement is, as you said, extremely successful at doing so. Unfortunately, I’ve yet to see a turnkey solution that provides 100% of UNICEF’s (or any aid organization’s) project requirements, and I’d wager a guess we’ll never see a product that hits even 90%. There’s always going to be a need for someone to do that additional customization, and I tend to see that as an ongoing need, not a one-off.
[…] be huge pay discrepancy between local and expat employees of international organisations. Here is a Unicef case in point where pay got in the way of outcomes in […]