raphaelbauer · June 2, 2025 23:00 · Sep 6, 2024 · Jun 30, 2023 · Jun 30, 2023 · Jun 20, 2023
diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -1,6 +1,6 @@
 # IT Department Tech Due Diligence Checklist
 
-Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blueprint.html
+NOTE: An updated version is available over here: https://www.raphaelbauer.com/posts/due-diligence/
 
 ## General organization of the IT department
 - [ ] Do your employees have a purpose. Do they know why they work with you?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -145,6 +145,6 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - Performance of services must be monitored.
   - Site Reliability Engineering book: https://landing.google.com/sre/sre-book/chapters/service-level-objectives/
 - [ ] Are teams able to develop features without being blocked by other teams?
-- [ ] Teams should not be waiting for other teams to implement anything. Best practices like Inner Source can help in that regard.
+  - Teams should not be waiting for other teams to implement anything. Best practices like Inner Source can help in that regard.
   - Inner source commons got many resources on the topic: https://innersourcecommons.org/
   - Zalando's approach to Inner Source for their 1500+ engineers: https://opensource.zalando.com/docs/resources/innersource-howto/
diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -136,7 +136,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - For instance: Is github configured securely and not publicly accessible...
 - [ ] Are services easy and fast to deploy?
 - [ ] Is a proper test strategy in place (eg how google tests software) testing pyramid?
-  - All Pull Requests should have tets. Hotfixes have tests. Bugfixes have tests.
+  - All Pull Requests should have tests. Hotfixes have tests. Bugfixes have tests.
   - "How Google Tests Software" - book by James Whittaker et. al
   - https://testing.googleblog.com/
 - [ ] Are there clear OKRs / roadmaps for each team? (Aligned with product). Engineers have to know their priorities!

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -118,6 +118,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 - [ ] Is a Tech radar in place so that developer have a guidance what to use and what not to use?
   - See Zalando: https://opensource.zalando.com/tech-radar/
 - [ ] Do the teams use pull requests and 4 eyes principle?
+  - Pull Requests should be minimal - ie reformatting should never be part of the PR to make it obvious
 - [ ] Are systems up to date? Have a regular day every quarter where your systems and libraries get updated. We called this Love4TheSystems day. Update your maven dependencies, update your databases, update your build servers...
 - [ ] Are there backup and restore drills for services and databases?
 - [ ] Are services and systems documented (big board with all services and connections).
@@ -135,6 +136,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - For instance: Is github configured securely and not publicly accessible...
 - [ ] Are services easy and fast to deploy?
 - [ ] Is a proper test strategy in place (eg how google tests software) testing pyramid?
+  - All Pull Requests should have tets. Hotfixes have tests. Bugfixes have tests.
   - "How Google Tests Software" - book by James Whittaker et. al
   - https://testing.googleblog.com/
 - [ ] Are there clear OKRs / roadmaps for each team? (Aligned with product). Engineers have to know their priorities!

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -44,6 +44,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing new things. Zuck’s original motto was: "Release fast and break things". But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: "Move fast with stability". (http://venturebeat.com/2014/04/30/facebook-has-killed-off-the-move-fast-break-things-mantra/)
   - Tom DeMarco's book "Slack" outlines why risk and uncertainty is needed for successful companies. Managing risk is therefore essential.
 - [ ] Are post-mortems done on all levels (teams, management etc)
+  - https://sre.google/sre-book/postmortem-culture/
   - In Scrum these are retrospectives
   - https://hbr.org/2015/11/why-organizations-dont-learn
 - [ ] Are pre-mortems for projects being done?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -26,7 +26,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 - [ ] Is a minimum IT team structure in place (Structure Team Zero)
   - Dev teams (cross functional)
   - Engineering leads as line managers for up to 3 teams
-  - Product team (each product dealing with one or two teams)
+  - Product team (each product person dealing with one or two teams)
   - OPTIONAL: Product chapter that syncs
   - Head of development that syncs with product chapter and engineering lead
 - [ ] Is there an organigram with all people and relations between each other?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -14,7 +14,8 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
     - Tom DeMarco's book "Slack". Difference between schedule and goal. Schedule with risk management
 - [ ] Is everyone accountable? Aka - OKRs and goals everywhere (team level, people level)?
   - John Doerr's excellent book "Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth."
-- [ ] Are meetings effective? Every meeting should have an agenda and a document to take notes. Action items are essential to make sure things are happending.
+  - But metrics can be dangerous if they become the target. Must read is: "Measuring and managing performance in organizations" by Robert D. Austin.
+- [ ] Are meetings effective? Every meeting should have an agenda and a document to take notes. Action items are essential to make sure things are happening.
 - [ ] Are minimum meetings for knowledge exchange in place? (Culture)
   - There should be a bi-weekly 1 hour meeting where teams highlight progress, roadblocks insights and what they will work on next. 
   - Is there a meeting where the organization syncs? All Hands, where eg Sales and so on also present?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -14,6 +14,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
     - Tom DeMarco's book "Slack". Difference between schedule and goal. Schedule with risk management
 - [ ] Is everyone accountable? Aka - OKRs and goals everywhere (team level, people level)?
   - John Doerr's excellent book "Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth."
+- [ ] Are meetings effective? Every meeting should have an agenda and a document to take notes. Action items are essential to make sure things are happending.
 - [ ] Are minimum meetings for knowledge exchange in place? (Culture)
   - There should be a bi-weekly 1 hour meeting where teams highlight progress, roadblocks insights and what they will work on next. 
   - Is there a meeting where the organization syncs? All Hands, where eg Sales and so on also present?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -140,3 +140,6 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - Performance of services must be monitored.
   - Site Reliability Engineering book: https://landing.google.com/sre/sre-book/chapters/service-level-objectives/
 - [ ] Are teams able to develop features without being blocked by other teams?
+- [ ] Teams should not be waiting for other teams to implement anything. Best practices like Inner Source can help in that regard.
+  - Inner source commons got many resources on the topic: https://innersourcecommons.org/
+  - Zalando's approach to Inner Source for their 1500+ engineers: https://opensource.zalando.com/docs/resources/innersource-howto/
diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -106,7 +106,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 - [ ] Is there an internship program for devs to put them into the shoes of customer care and into the front line?
 
 ## Engineering
-- [ ] Measure productivity of your teams. The book Accelerate by Gene Kim, Jez Humble, and Nicole Forsgren outlines three metrics to watch out for: lead time, release frequency,and  mean time to restore (failure change rate is another metric that can be used, but did not pass all tests according to Accelerate). Thanks to Sören for bringing this up!
+- [ ] Measure productivity of your teams. The book Accelerate by Gene Kim, Jez Humble, and Nicole Forsgren outlines three metrics to watch out for: lead time, release frequency and mean time to restore. Failure change rate is another metric that can be used, but did not pass all tests according to Accelerate. Thanks to Sören for bringing this up!
 - [ ] Is simplicity paramount? Simple code. Simple services. Simple IT landscape?
   - Actively reduce the amount of technologies used.
 - [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag). Uncle Bob Martin calls this "true continuous delivery". Others call it "trunk-based development". There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -19,7 +19,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - Is there a meeting where the organization syncs? All Hands, where eg Sales and so on also present?
   - Tech talk / lightning talks would be nice
   - More: https://hbr.org/2019/07/why-employees-dont-share-knowledge-with-each-other
-- [x] Is heartbeat of the organization collected? Eg get happiness of the teams every month. => Identify weak spots early on and act!
+- [ ] Is heartbeat of the organization collected? Eg get happiness of the teams every month. => Identify weak spots early on and act!
   - Straight forward tool (caveat: We developed it): https://www.team-climate.com
 - [ ] Is a minimum IT team structure in place (Structure Team Zero)
   - Dev teams (cross functional)

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -19,7 +19,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - Is there a meeting where the organization syncs? All Hands, where eg Sales and so on also present?
   - Tech talk / lightning talks would be nice
   - More: https://hbr.org/2019/07/why-employees-dont-share-knowledge-with-each-other
-- [ ] Is heartbeat of the organization collected? Eg get happiness of the teams every month. => Identify weak spots early on and act!
+- [x] Is heartbeat of the organization collected? Eg get happiness of the teams every month. => Identify weak spots early on and act!
   - Straight forward tool (caveat: We developed it): https://www.team-climate.com
 - [ ] Is a minimum IT team structure in place (Structure Team Zero)
   - Dev teams (cross functional)

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -20,7 +20,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - Tech talk / lightning talks would be nice
   - More: https://hbr.org/2019/07/why-employees-dont-share-knowledge-with-each-other
 - [ ] Is heartbeat of the organization collected? Eg get happiness of the teams every month. => Identify weak spots early on and act!
-  - Straight forward tool (caveat: We developed it): https://www.internal-feedback.com
+  - Straight forward tool (caveat: We developed it): https://www.team-climate.com
 - [ ] Is a minimum IT team structure in place (Structure Team Zero)
   - Dev teams (cross functional)
   - Engineering leads as line managers for up to 3 teams

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -35,6 +35,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
   - STEPS framework from Spotify: https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/
 - [ ] Is there a operating manual (aka handbook) how the department works (with checklists)?
   -  Valve's handbook for new employees: https://www.valvesoftware.com/hu/publications
+  - Gitlab's handbook is another great reference: https://about.gitlab.com/handbook
 
 ## Culture / Establishing a learning culture
 - [ ] Is failure permitted? If you never fail you will never innovate. (The opposite is not necessarily true).

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -105,6 +105,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 - [ ] Is there an internship program for devs to put them into the shoes of customer care and into the front line?
 
 ## Engineering
+- [ ] Measure productivity of your teams. The book Accelerate by Gene Kim, Jez Humble, and Nicole Forsgren outlines three metrics to watch out for: lead time, release frequency,and  mean time to restore (failure change rate is another metric that can be used, but did not pass all tests according to Accelerate). Thanks to Sören for bringing this up!
 - [ ] Is simplicity paramount? Simple code. Simple services. Simple IT landscape?
   - Actively reduce the amount of technologies used.
 - [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag). Uncle Bob Martin calls this "true continuous delivery". Others call it "trunk-based development". There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
@@ -113,6 +114,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 - [ ] Is a Tech radar in place so that developer have a guidance what to use and what not to use?
   - See Zalando: https://opensource.zalando.com/tech-radar/
 - [ ] Do the teams use pull requests and 4 eyes principle?
+- [ ] Are systems up to date? Have a regular day every quarter where your systems and libraries get updated. We called this Love4TheSystems day. Update your maven dependencies, update your databases, update your build servers...
 - [ ] Are there backup and restore drills for services and databases?
 - [ ] Are services and systems documented (big board with all services and connections).
   - Document ownership (teams)

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -107,7 +107,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 ## Engineering
 - [ ] Is simplicity paramount? Simple code. Simple services. Simple IT landscape?
   - Actively reduce the amount of technologies used.
-- [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag). Uncle Bob Martin calls this true continuous delivery. Others call it trunk based development. There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
+- [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag). Uncle Bob Martin calls this "true continuous delivery". Others call it "trunk-based development". There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
   - https://www.youtube.com/embed/BSaAMQVq01E?start=5471
   - https://trunkbaseddevelopment.com/
 - [ ] Is a Tech radar in place so that developer have a guidance what to use and what not to use?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -107,7 +107,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 ## Engineering
 - [ ] Is simplicity paramount? Simple code. Simple services. Simple IT landscape?
   - Actively reduce the amount of technologies used.
-- [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag. Uncle Bob Martin calls this true continuous delivery. Others call it trunk based development. There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
+- [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag). Uncle Bob Martin calls this true continuous delivery. Others call it trunk based development. There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
   - https://www.youtube.com/embed/BSaAMQVq01E?start=5471
   - https://trunkbaseddevelopment.com/
 - [ ] Is a Tech radar in place so that developer have a guidance what to use and what not to use?

diff --git a/it-department-tech-due-diligence-checklist.md b/it-department-tech-due-diligence-checklist.md
@@ -57,7 +57,7 @@ Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blu
 - [ ] Are remote teams working properly?
   - Teams should always use videochat and online tools for collaboration (Google Draw for sketching ideas eg)
   - Working remotely is not a problem and pair programming or mob programming works just fine when the coder shares the screen
-  - Makse sure remote teams participate in your company meetings (Show and Tell, All Hands...)
+  - Make sure remote teams participate in your company meetings (Show and Tell, All Hands...)
 - [ ] Are teams delivering things end-to-end? Product should be able to develop cool products with one team and minimal sync with other teams.
 - [ ] Is there a healthy team culture. Everyone inside a team speaks. Everyone contributes.
   - Having a team lead decide everything is an anti-pattern

diff --git a/it-department-audit-blueprint-10.md → ...epartment-tech-due-diligence-checklist.md b/it-department-audit-blueprint-10.md → ...epartment-tech-due-diligence-checklist.md
diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -1,15 +1,6 @@
-# IT Department Audit Blueprint
+# IT Department Tech Due Diligence Checklist
 
-As IT consultant I work with clients to make cool things happen. 
-My first step in a new project is always to do an audit of the client’s IT capabilities. If the client does not request it I do it anyway - because it is implicitly expected from me to know what is going on.
-
-The following checklist roughly resembles my way of doing the audit. Every client is different, so the checklist is not a one-fits-all solution. But it was always a big help for me to get started. Checklist items on top of a section are more important than items at the bottom.
-
-**The golden rule is**: If an important checklist item is missing then this might already point to a potential problem. For instance - if a global roadmap is missing then this might mean teams and people have no common goals. But you can fix it easily which will lead to great results.
-
-You can also use this audit if you run an IT department. Make sure you do it once a year and follow up on things that are missing or need improvement.
-
-Let me know what you think!
+Linked from https://ars-machina.raphaelbauer.com/2018/12/it-department-audit-blueprint.html
 
 ## General organization of the IT department
 - [ ] Do your employees have a purpose. Do they know why they work with you?

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -73,6 +73,7 @@ Let me know what you think!
   - Also see Google's Aristotle studies about high performance teams (https://rework.withgoogle.com/print/guides/5721312655835136/).
 - [ ] Are there employees that are single points of failure? Is mitigation of single points of failure actively pursued? 
 - [ ] Is there a documented onboarding process for newcomers?
+- [ ] Is there a documented offboarding process leaving employees?
 - [ ] Is there a structured hiring process (aligned with career path and salary)?
 - [ ] Is there a structured process to promote employees (aka clear career paths)?
 - [ ] Is employee churn being benchmarked and acted upon?

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -66,6 +66,7 @@ Let me know what you think!
 - [ ] Are remote teams working properly?
   - Teams should always use videochat and online tools for collaboration (Google Draw for sketching ideas eg)
   - Working remotely is not a problem and pair programming or mob programming works just fine when the coder shares the screen
+  - Makse sure remote teams participate in your company meetings (Show and Tell, All Hands...)
 - [ ] Are teams delivering things end-to-end? Product should be able to develop cool products with one team and minimal sync with other teams.
 - [ ] Is there a healthy team culture. Everyone inside a team speaks. Everyone contributes.
   - Having a team lead decide everything is an anti-pattern

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -63,6 +63,9 @@ Let me know what you think!
   - Kick them out: http://hintjens.com/blog:120
 
 ## People and teams
+- [ ] Are remote teams working properly?
+  - Teams should always use videochat and online tools for collaboration (Google Draw for sketching ideas eg)
+  - Working remotely is not a problem and pair programming or mob programming works just fine when the coder shares the screen
 - [ ] Are teams delivering things end-to-end? Product should be able to develop cool products with one team and minimal sync with other teams.
 - [ ] Is there a healthy team culture. Everyone inside a team speaks. Everyone contributes.
   - Having a team lead decide everything is an anti-pattern

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -14,6 +14,7 @@ Let me know what you think!
 ## General organization of the IT department
 - [ ] Do your employees have a purpose. Do they know why they work with you?
   - How KPMG supercharged purpose: https://hbr.org/2015/10/how-an-accounting-firm-convinced-its-employees-they-could-change-the-world
+  - https://hbr.org/2019/09/put-purpose-at-the-core-of-your-strategy
   - Purpose framework and guide from HBR: https://hbr.org/2018/07/creating-a-purpose-driven-organization
 - [ ] Is there a product roadmap? Short term (next sprint), mid term (up to one year), long term (3 years and more)
   - Okrs, Roadmap and Vision (Facebook example): http://www.sachinrekhi.com/modern-project-management-for-product-managers

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -110,6 +110,9 @@ Let me know what you think!
 ## Engineering
 - [ ] Is simplicity paramount? Simple code. Simple services. Simple IT landscape?
   - Actively reduce the amount of technologies used.
+- [ ] If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag. Uncle Bob Martin calls this true continuous delivery. Others call it trunk based development. There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
+  - https://www.youtube.com/embed/BSaAMQVq01E?start=5471
+  - https://trunkbaseddevelopment.com/
 - [ ] Is a Tech radar in place so that developer have a guidance what to use and what not to use?
   - See Zalando: https://opensource.zalando.com/tech-radar/
 - [ ] Do the teams use pull requests and 4 eyes principle?

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -26,6 +26,7 @@ Let me know what you think!
   - There should be a bi-weekly 1 hour meeting where teams highlight progress, roadblocks insights and what they will work on next. 
   - Is there a meeting where the organization syncs? All Hands, where eg Sales and so on also present?
   - Tech talk / lightning talks would be nice
+  - More: https://hbr.org/2019/07/why-employees-dont-share-knowledge-with-each-other
 - [ ] Is heartbeat of the organization collected? Eg get happiness of the teams every month. => Identify weak spots early on and act!
   - Straight forward tool (caveat: We developed it): https://www.internal-feedback.com
 - [ ] Is a minimum IT team structure in place (Structure Team Zero)

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -12,6 +12,9 @@ You can also use this audit if you run an IT department. Make sure you do it onc
 Let me know what you think!
 
 ## General organization of the IT department
+- [ ] Do your employees have a purpose. Do they know why they work with you?
+  - How KPMG supercharged purpose: https://hbr.org/2015/10/how-an-accounting-firm-convinced-its-employees-they-could-change-the-world
+  - Purpose framework and guide from HBR: https://hbr.org/2018/07/creating-a-purpose-driven-organization
 - [ ] Is there a product roadmap? Short term (next sprint), mid term (up to one year), long term (3 years and more)
   - Okrs, Roadmap and Vision (Facebook example): http://www.sachinrekhi.com/modern-project-management-for-product-managers
   - Make sure the roadmap is realistic and not a wishlist that will never come true.

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -16,7 +16,7 @@ Let me know what you think!
   - Okrs, Roadmap and Vision (Facebook example): http://www.sachinrekhi.com/modern-project-management-for-product-managers
   - Make sure the roadmap is realistic and not a wishlist that will never come true.
     - Gerald M. Weinberg "Secrets of Consulting". Using anonymous votes to gather confidence about the schedule.
-    - Tom DeMarco "Slack". Difference between schedule and goal. Schedule with risk management
+    - Tom DeMarco's book "Slack". Difference between schedule and goal. Schedule with risk management
 - [ ] Is everyone accountable? Aka - OKRs and goals everywhere (team level, people level)?
   - John Doerr's excellent book "Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth."
 - [ ] Are minimum meetings for knowledge exchange in place? (Culture)
@@ -43,15 +43,15 @@ Let me know what you think!
 ## Culture / Establishing a learning culture
 - [ ] Is failure permitted? If you never fail you will never innovate. (The opposite is not necessarily true).
   - There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing new things. Zuck’s original motto was: "Release fast and break things". But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: "Move fast with stability". (http://venturebeat.com/2014/04/30/facebook-has-killed-off-the-move-fast-break-things-mantra/)
-  - Tom DeMarco's slack outlines why risk and uncertainty is needed for successful companies. Managing risk is therefore essential.
+  - Tom DeMarco's book "Slack" outlines why risk and uncertainty is needed for successful companies. Managing risk is therefore essential.
 - [ ] Are post-mortems done on all levels (teams, management etc)
   - In Scrum these are retrospectives
   - https://hbr.org/2015/11/why-organizations-dont-learn
 - [ ] Are pre-mortems for projects being done?
   - https://hbr.org/2007/09/performing-a-project-premortem
 - [ ] Is feedback accepted on all levels? (and also used very very often?)
 - [ ] Feedback must be a habit. After talks. After projects. After everything.
-- [ ] Is there a checklist culture to make things reproducible? (eg scrum meetings, depolyments, but also definition of done and similar artifacts).
+- [ ] Is there a "Checklist Culture" to make things reproducible? (eg scrum meetings, depolyments, but also definition of done and similar artifacts). There's even a book about it: Atul Gawande: "The Checklist Manifesto: How to Get Things Right"
 - [ ] Is there trust between the teams?
 - [ ] Is there a rude tone? People should be nice to each other.
   - No Asshole rule: https://en.wikipedia.org/wiki/The_No_Asshole_Rule
@@ -78,18 +78,18 @@ Let me know what you think!
   - Don't use Acronyms => https://www.inc.com/glenn-leibowitz/in-just-2-words-elon-musk-gave-writing-advice-every-business-leader-should-follow.html
   - Work for the most simple and straightforward solution
 - [ ] Is repeatability paramount?
-  - Use checklists. Everywhere. There's even a book about it: Atul Gawande: "The Checklist Manifesto: How to Get Things Right"
+  - Use checklists. Everywhere.
 - [ ] Is team maturity taken into account? Are immature teams known and do they get the help they need to successfully deliver products?
 
 ## Product
 - [ ] Is the concept of a "Product Owner" clear
-  - There is a difference between someone having authority and driving the product for business success and a mere product task monkey that delegates stuff to the dev team.
+  - There is a difference between someone having authority and driving the product actively and a mere "product task monkey" that delegates stuff to the dev team.
   - From Knitberg (Spotify): https://www.youtube.com/watch?v=502ILHjX9EE
-- [ ] Is there a clear exchange between individual product people 
+- [ ] Is there a good collaboration between individual product people?
   - Product team meets every week in front of a wall with "initiatives" to exchange what is going on?
 - [ ] Product and the development teams strive for simplicity everywhere. Simplicity in product, simplicity in resulting software.
 - [ ] How mature is delivery? The terms "agile" and "MVP" must be crystal clear.
-  - eg delivering (if possible) something that is of value for the user to get feedback as fast as possible. Releasing a big bang project is NOT agile.
+  - eg delivering something to the users to get user feedback as fast as possible. Releasing a big bang project is NOT agile and will massively increase the likelhood of failure
 - [ ] Is user interaction with features / products being measured and tracked?
   - Make tracking of user interactions an acceptance criteria. This is the basis to make your product decisions. Without that data you are guessing.
   - Don't forget to also track APIs that are used by machines (restful json api, graphql etc). Either monitor them or track them in for - instance - Matomo / Google Analytics.
@@ -98,7 +98,7 @@ Let me know what you think!
   - Product knows what can be sold and what the user wants. Development teams know how to make that happen in the best (and fastest way). Usually there is a sweet spot, where 80% of product requirements can be developed very quickly, but making the rest happen will take a lot of development time. The goal for product and development teams is to find that sweet spot.
 - [ ] Is a risk assessment done for product / project? (postmortems / premortems)
   - A failed product / project hurts, but is an important learning opportunity for your teams. Make sure to follow up and get learnings out of it (post-mortems)
-- [ ] Are product owners part of the teams (they should)?
+- [ ] Are product owners part of the teams (they should be)?
 - [ ] Do product owners define acceptance criteria - and are being consulted when developing features?
 - [ ] If people quit your product - is a follow up scheduled to find out why?
 - [ ] Is there an internship program for devs to put them into the shoes of customer care and into the front line?
@@ -109,6 +109,7 @@ Let me know what you think!
 - [ ] Is a Tech radar in place so that developer have a guidance what to use and what not to use?
   - See Zalando: https://opensource.zalando.com/tech-radar/
 - [ ] Do the teams use pull requests and 4 eyes principle?
+- [ ] Are there backup and restore drills for services and databases?
 - [ ] Are services and systems documented (big board with all services and connections).
   - Document ownership (teams)
   - Document riskiness (and make sure to get rid of risky stuff, put that on the roadmap)
@@ -131,5 +132,4 @@ Let me know what you think!
 - [ ] Is performance test strategy in place (SLAs, SLOs)?
   - Performance of services must be monitored.
   - Site Reliability Engineering book: https://landing.google.com/sre/sre-book/chapters/service-level-objectives/
-- [ ] Are there backup and restore drills for services and databases?
-- [ ] Are teams independent - in terms of technology - to develop features independently?
+- [ ] Are teams able to develop features without being blocked by other teams?
diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -42,7 +42,7 @@ Let me know what you think!
 
 ## Culture / Establishing a learning culture
 - [ ] Is failure permitted? If you never fail you will never innovate. (The opposite is not necessarily true).
-  - There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing new things. Zuck’s motto: Release fast and break things. But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: Move fast with stability.
+  - There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing new things. Zuck’s original motto was: "Release fast and break things". But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: "Move fast with stability". (http://venturebeat.com/2014/04/30/facebook-has-killed-off-the-move-fast-break-things-mantra/)
   - Tom DeMarco's slack outlines why risk and uncertainty is needed for successful companies. Managing risk is therefore essential.
 - [ ] Are post-mortems done on all levels (teams, management etc)
   - In Scrum these are retrospectives

diff --git a/it-department-audit-blueprint-10.md b/it-department-audit-blueprint-10.md
@@ -42,7 +42,7 @@ Let me know what you think!
 
 ## Culture / Establishing a learning culture
 - [ ] Is failure permitted? If you never fail you will never innovate. (The opposite is not necessarily true).
-  - There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing a new things. Zuck’s motto: Release fast and break things. But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: Move fast with stability.
+  - There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing new things. Zuck’s motto: Release fast and break things. But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: Move fast with stability.
   - Tom DeMarco's slack outlines why risk and uncertainty is needed for successful companies. Managing risk is therefore essential.
 - [ ] Are post-mortems done on all levels (teams, management etc)
   - In Scrum these are retrospectives