From 9d8ef270f1cec2993e88bef95d65fc39e94ac6d5 Mon Sep 17 00:00:00 2001 From: moanos Date: Tue, 23 Dec 2025 19:30:23 +0100 Subject: [PATCH] feat: Add not on commitments --- content/notes/commitments.md | 94 ++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 content/notes/commitments.md diff --git a/content/notes/commitments.md b/content/notes/commitments.md new file mode 100644 index 0000000..5b6ff9a --- /dev/null +++ b/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. \ No newline at end of file