feat: Add not on commitments

content/notes/commitments.md

@@ -0,0 +1,94 @@
+---
+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.