---
title: "Commitments"
date: 2025-12-18T20:30:00+02:00
draft: false
subtitle: "It's frustrating to work for organizations that don't manage to get something online. How to fix that?"
---

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.

# Conclusion

New contributors are valuable. Don't waste their time, don't let them feel helpless. Then you will succeed.