Pro Bono Work
Not all organizations that would like my services have the budget for it. To address this, I set aside ten hours every week for pro bono work.
This started long before the consultancy did, when I was a volunteer for Code for Pittsburgh. Many organizations do valuable work but do not have the budget for paid software engineering services. If my work can make their organization better, I believe I should offer it whether or not they can pay for it.
That said, ten hours a week only goes so far. Here's how I decide what qualifies.
What doesn't qualify
- You already have paid software engineers. I understand that no organization has infinite budget. But I personally cannot justify doing work unpaid that someone else is being paid for.
- Open-ended support requests. I can't commit to work where I don't know the extent of the ask. Open-ended work prevents me from helping other organizations.
- Urgent or on-demand work. Paid clients, by nature, take precedence. I can't guarantee that I can complete a task in an ambitious timeframe, or be available on short notice. If the task is critical, I can't offer pro bono work.
What qualifies
- Scope-bound and short term. A defined project with a finish line and a relatively short time horizon. Something that can be scoped, delivered, and handed off.
- Non-urgent work with flexible timelines. Pro bono work fits around paid commitments, and naturally moves at a different pace. If the work is beneficial but not critical, it's a good fit.
- Fills a gap that wouldn't be filled otherwise. If I wasn't there to do it, the work would either not be done or be done by staff with limited technical experience.