Tips on technologist collaborations for resource-constrained organizations
Here are some of the north stars that Philadelphia Young Playwrights and I used to orient our work together through the Greater Philadelphia Cultural Alliance’s Techniculture residency.
Don’t let perfect technology be the enemy of good technology.
When you feel you’ve got a lead on a solution, figure out the quickest and lowest cost way to validate it. Don’t wait for the grant to come through, or the perfect person, or any other excuse you might have for delaying.
Prototyping solutions with whatever tools you have available results in deepening your understanding of the problem, resulting in opportunities that are “riper” for a technologist than they might be if PYP had waited to find a developer before trying to implement the solution. With free tools like Google Docs, Zapier, WordPress, and Trello, a minimal viable solution is usually in reach with a bit of elbow grease.
Know yourself, but entertain doubt too
The beauty of mission driven organization is that the ‘why’ of our work usually feels more meaningful than the ‘why’ of a typical for-profit.
It might sound counter-intuitive, but willingness to entertain doubt is a big factor here. Working with PYP I always felt they had a good sense of their goals, and were helpful in explaining to me how they saw technology supporting outcomes.
But as technologists, we also have a design imperative, to come up with the best solution possible, and sometimes the easiest way to refine a concept is drilling into the root why.
I found that 9 times out of 10 when asking ‘why’, the Playwrights had some key insight, organizational, pedagogical, or otherwise that helped me better conceptualize what they were trying to do, and that collaboration would not have been as effective without their clear sense of goal outcomes and willingness to entertain doubt.
Reduce your bus factor
Technology planning can be a confusing process. We’ve all been in an organization at one time or another that was blessed to have an uber geek in the fold for some period of time. These people are great! But sometimes they leave unexpectedly, and then the organization is left with technology that no one understands. Worse yet, maybe they had source code that was only saved on their computer, and now you have to update a website but you have no idea how to do that in a structured way.
As a technologist our first order of business when we enter an organization should be to assess and if necessary reduce the “bus factor” – that is, if you were to be hit by bus this afternoon, how would your organization rebound without you?
To me as a developer this means version control, clean code, and documentation. While it’s not vital that someone in the organization understand the tech, they should at least understand the setup well enough to brief another developer, with the confidence that the stack will be in a condition that they find reasonable and passes the “doesn’t suck” test.
Default to open source and self-hosted technologies
It might be easier to pay a service so you can get a piece of technology done for the organization quicker, but that could be a new recurring cost for the organization to bear. The same can be said of one-off builds that aren’t easily replicable by the existing non-technical staff. WordPress was central for PYP and we really wouldn’t have been able to do this project without having benefitted on other projects in the WordPress community.
Photo credit: @Youngmoo