Thanks for the writeup! One comment is that there are a few downsides of agencies which are worth exploring. Some of those are:
Less embedded in the org = typically less likely to suggest projects/software solutions to business problems than an in-house dev would be
Slightly less reliable for situations where high priority work can come up. An in house dev is always available to jump on an issue. That may well not be the case with an agency. E.g: Your website crashes in the middle of a busy weekend. Your agency project finished months ago. You now need to get back in touch with the agency in order to source someone to fix your site. While it is true that you can get around this kind of issue with longer-term retainer type contracts, this is an added level of complexity to manage.
There’s additional overhead in managing the relationship/demands of clients. This is true regardless of whether you go with an person hour or project deliverable billing model.
This is not to say that it’s a bad idea or unlikely to be successful, just that it’s worth considering the downsides and possible ways to mitigate them in an EA context.
I think those are all true, but the goal is to maximise good done, not to maximise the on-paper efficiency of any particular organisation. Through that lens, there’s a counterpoint to each of these:
More embedded in the movement overall = more likely to suggest projects/software solutions to movement problems than an in-house dev would be
Capable of triaging across the movement. If your website goes down and something comparably urgent is going on elsewhere, the agency can prioritise whichever is the most important issue (much more true of a donor-funded agency—a low-bono one will be bound to honour its contracts to the best of its ability even in the face of new data)
There’s reduced overhead in managing demand across the movement vs an uncoordinated approach (though the third bullet in both our cases is arguably a restatement of the first two)
Thanks for the writeup! One comment is that there are a few downsides of agencies which are worth exploring. Some of those are:
Less embedded in the org = typically less likely to suggest projects/software solutions to business problems than an in-house dev would be
Slightly less reliable for situations where high priority work can come up. An in house dev is always available to jump on an issue. That may well not be the case with an agency. E.g: Your website crashes in the middle of a busy weekend. Your agency project finished months ago. You now need to get back in touch with the agency in order to source someone to fix your site. While it is true that you can get around this kind of issue with longer-term retainer type contracts, this is an added level of complexity to manage.
There’s additional overhead in managing the relationship/demands of clients. This is true regardless of whether you go with an person hour or project deliverable billing model.
This is not to say that it’s a bad idea or unlikely to be successful, just that it’s worth considering the downsides and possible ways to mitigate them in an EA context.
I think those are all true, but the goal is to maximise good done, not to maximise the on-paper efficiency of any particular organisation. Through that lens, there’s a counterpoint to each of these:
More embedded in the movement overall = more likely to suggest projects/software solutions to movement problems than an in-house dev would be
Capable of triaging across the movement. If your website goes down and something comparably urgent is going on elsewhere, the agency can prioritise whichever is the most important issue (much more true of a donor-funded agency—a low-bono one will be bound to honour its contracts to the best of its ability even in the face of new data)
There’s reduced overhead in managing demand across the movement vs an uncoordinated approach (though the third bullet in both our cases is arguably a restatement of the first two)