I'll summarize some of the information and advice I got from Gunner:
Ecology of the nonprofit tech sector:
- Paid positions
- Dedicated tech staffers at nonprofits
- "Accidental techies": nonprofit staffers who wear the techie hat out of circumstance or neccesity
- Nonprofit and for-profit companies that provide software or tech services and whose primary customers are nonprofits
- Self-employed contractors/consultants whose clients are nonprofits
- Unpaid positions
- Tech volunteers
- People who work on open source software for nonprofits
- Build a portfolio of websites, on a volunteer basis if necessary.
- As an intermediate stage, offer flat-rate projects. These are attractive to nonprofits because of the fixed cost, but note that you assume all of the risk of cost/time overruns. (Flat-rate projects are also a good option for more experienced people who are good at estimating exactly how much time the project will take.)
- It takes years to build a reputation.
- Experience in the nonprofit sector is important: if you have built websites in the for-profit sector, nonprofits may believe that you are capable of building websites, but they may not necessarily trust you to be able to do it in the very under-resourced nonprofit sector.
- Radical Designs - web development shop based in SF
- Picnet - has an office in SF; consider applying as a support/maintenance engineer for entry-level experience
- Democracy in Action - Java house. East Coast HQ, but they have a small West Coast office in SF.
- Fire drill websites - Build a nonprofit website in two weeks; let them know up-front what functionality they can and cannot expect from the website.
- Technology selection - what is the right stack for a particular nonprofit to use, given their size and characteristics?
- "Intake" work for birthing a website - see below
- $75-100/hr: "Activist" rate for web work; people who are not in it for the money and who want to keep it affordable for the nonprofit community
- $100-125/hr: High-end "activist" rate for web work; Groovy development
- $125+/hr: "Capitalist" rate; charging what the market will bear
- $200-$400/hr: (!!!) "Capitalist" rate for Ruby on Rails development
- This was a pleasant surprise for me. Combined with a live-below-your-means lifestyle, these rates should be sufficient for me to make a non-negligible income while also having enough time for other pursuits and volunteer projects. I do need to take the extra tax bite for ICs into account.
- Many need organizational development
- Know when to walk away. Identify no-win situations and relationships that have reached the end of their useful life.
- Nonprofits can play mind games - they are masters of the passive-aggressive guilt trip and may try to guilt you into continuing a relationship as a volunteer/employee, even if it's not working out
- Organizational politics - as in any org, there may be internal groups that wrangle, oppose each other, and want completely different outcomes
- Not brutally efficient like the for-profit world
- Set your own terms. Be proactive and propose a project/task, rather than waiting for them to assign you something. Make sure the scope of the project is limited and well-defined, rather than open-ended. (This advice may not necessarily apply to all volunteers, but it definitely applies to someone in my situation, who has a strategic purpose for volunteering and needs to make sure that the unpaid volunteer engagement is a fair exchange of my time for valuable experience that I need.)
- If you leave the nonprofit, don't screw them. I.e., if you decide to part ways (because the situation is not working out, you have been offered a paid job, you need to acquire other types of experience, or any other reason), leave their website/technology in a good enough state so that they can continue to use it and so that it will be easy for someone else to pick up where you left off. Be professional, don't burn bridges, part as friends.
- Technology audit
- Website audit
- Volunteer and pro-bono work can build your reputation with the org, add to your experience/skills, and help you get to know each other and see if it's a good fit.
- However, you don't want it to erode the possibility of future employment
- Choose a high-value deliverable
- Limit the time frame and scope. Don't make it open-ended, you may open yourself up for exploitation.
- Be ready to walk. It's like dating: even if you like them a lot, you shouldn't act too desperate :)
- If the pro-bono project ends and they ask you to continue working with them but don't offer to pay, there is code language you can use in such situations that basically tells them "I need to pay the rent"
- Even if you like the org a lot, there is value in working with a variety of different orgs.
- Most nonprofits still don't have a website! (Then again, many nonprofits don't have the funding for one! Or, they might be all-volunteer shops run by a guy or two in their spare time.)
- Good consultants are booked 3-6 months out!
- Technology stacks are now mature enough that nonprofits can safely adopt them (e.g. CMS)
- If you can apply technology to facilitate fundraising, you are golden! (e.g. fundraising widgets)
- Facilitation. Asking questions. Gathering requirements. This requires more time and effort than in the for-profit world
- Dealing with organizational politics
- "Intake" work (requirements gathering, etc.) - there is a great need for people to do this, since a lot of techies shy away from it and prefer to just do implementation
- In the for-profit software world, "QA Engineer" is one entry path for eventually becoming a "Development Engineer".
- In the nonprofit software world, "Support Engineer" and "Maintenance Engineer" are the analogous entry paths.
- Nonprofits that come to you and say, "We need technology X". Why?!?! Start with needs and requirements, not with technologies.
- Overengineering; custom code. Techies who come in and create a custom code website just for experience, then leave (and leave the nonprofit screwed).
You may have skills you didn't realize you had. For example, as a developer I have gone through several release cycles for a large-scale enterprise product - this translates to project management experience! Be on the lookout for transferable skills that I already have, and chances to acquire new ones.
Most nonprofits don't need the full-blown "scalable robust" solution. Most nonprofits can't even afford the solution that actually addresses their needs. So, there is an art to choosing and delivering a solution that 1) meets a few of their most pressing needs, 2) is maintainable by non-tech-savvy staffers (or future consultants), and 3) leaves them a path for growth.
Nonprofits make decisions at a glacial pace - including hiring decisions. Be patient and be prepared to wait.
"M*A*S*H" model - stabilize the patient. When you start with a nonprofit to do their IT work, first attend to the places where they're bleeding. E.g. are they doing backups?!?! Cheap/easy/kludgy backups are better than no backups at all.
If you are weak in graphic design, you can partner with someone with strong design skills.
I should go look at the resumes of other nonprofit techies.
Get some skin in the game! Gunner has connections with a lot of nonprofit web consulting groups and can hook me up with shops where I can get experience.
I need to consult my internal compass and decide what I'm passionate about: nonprofit engagement ("intake" work may be the best fit), nonprofit impact (there's a high-impact opportunity at a Drupal shop), or technology (there are opportunities for Ruby on Rails developers to create all sorts of custom bells and whistles for nonprofit websites).
If I go the Drupal route, Gunner knows C. from Floatleft on the East Coast who could be a great mentor for work/life balance issues in the nonprofit web development.
Gunner put me in touch with someone who's doing Drupal/CiviCRM websites for nonprofits who needs some extra help and is willing to work with someone with my experience (or lack thereof). I need to set up a meeting with him to see if we can work out a mutually agreeable arrangement. I also need to think about what I want to get out of this experience so that I can bring it to our discussion.