In the past I have worked with various non-profit association, helping them with their IT. I have amd mixed experiences how productive and rewarding that was. After two particularly bad experiences I have decided I need a change, specifically I need more commitment.

The problem

The main problem boils down to indecision and missing capacity/priority. As an example: A group wrote an extensive google doc, detailing about 15 pages on a website that is to be created. After implementing this in a few weeks (mainly due to necessary changes of already outdated information) a section of the website was ready for final approval, another one was in a Proof-of-Concept phase. This was finished in September. Since then, I repeatedly asked for review so the site could go live. One person reviewed parts, but wanted another person to give feedback as well. Now, end of December, the finished section is still not live. I refuse to put more work in until the existing work is reviewed.

The solution

Tackle such projects, like I’d tackle a project in my day-job: Define stakeholders, a timeline and force decisions when necessary. Demand commitments.

Scenario 1: Basic Website

I believe the most common first step for organizations is to set up a website and be reachable via e-mail. For a first website there need to be the following things:

Homepage with short description and one Call-to-Action
Imprint
Data privacy statement

A typical process to set up such a website should be

Kick-Off call: Discuss basic content and style elements, clarify technology, cost and timeline
Basic implementation: The developer will set up a website with the basic style elements and sections for the content (not filled with real text yet)
Content generation The organization provides text for the website
Implementation: Content is added to the website by the developer
Testing: The organization checks the result, the dev will make minor adjustments
Go-Live: After confirming a successful test, the website will go-live

In order to keep risk low, the time between Kick-Off and Go-Live should be planned to last not longer than 6 weeks. Otherwise, there is a risk that one side puts in a lot of work that is then not rewarded with a Go-Live.

Here are some other commitments, one could think of:

Organization	Developer
Provide text within two weeks after basic implementation	Provide basic implementation within two weeks
Take not more than one week for testing	Make minor tweaks within a week
Provide actionable items when test result hinders Go-Live	Document infrastructure
Define central person for functional questions	Only implement what others could also maintain

Scenario 2: Joining an existing IT team

Another common scenario is joining an existing IT team. I’ve been on both sides of that process and here is how I think it should work

Welcome call: Who is everyone, who is responsible for what, how is the team organized? Define a first task that the new person can reasonably do. The smaller, the better.
Technical onboarding: Create admin users, invite to password manager, put SSH keys on server
Getting started: Newbie starts the task, knows who to ask when they need help - someone needs to be available to answer questions, otherwise frustration and mental overload will settle in soon
Integration in regular work Newbie is assigned responsibilities and part of the group

Ideally documentation already exists for the new person to learn. If not, this is a great opportunity to add it! If the Newbie has a question: Answer the question in detail and past the answer in your documentation. It will benefit you in the future, I promise!

So this seems reasonable right? But there are many ways to fuck it up.

Reasons for failure

Missing access: This is something I have experienced time and time again. From data protection concerns to trust issues, the problem was always power: Existing admins did trust the newbies with the power they have. And that is the core problem: if someone has access, they can mess up things. Even the most experienced admins. That’s why you should have backups and written agreements on data protection. If you don’t then your existing admin is more of a threat than the newbie.
Unclear processes: So often it’s unclear how decisions are made, whome to communicate a downtime, and so on. Newbies are overwhelmed because they don’t know what to do, existing teams are annoyed by newbies because they “don’t fit in”
Missing capacity: When you onboard people, this will take extra effort. There must be time made for that, you need new people to succeed. If you don’t do onboarding right, the new person will never become part of the team, will eventually leave and your team will shrink more and more until it fails.