Table of Contents

The VSHN Handbook

1. Information about SARS-CoV-2 / COVID-19

1.1. Summary

2. VSHN’s Culture - How we do things around here

2.1. VSHN’s Culture in a Nutshell

2.2. What’s Next?

3. Decision-Making at VSHN

3.1. Introduction

3.2. Operations vs. Governance

3.3. Consent Decision-Making

3.4. Leadership

4. Operations vs. Governance

4.1. Operations

4.2. Governance

5. Leadership at VSHN

5.1. Developing Leadership

5.2. Leadership in Action

6. Company Alignment

6.1. Aligned Organizational Structure

6.2. Agile Goal Setting

6.3. And where is Strategy in this?

7. Changing Things at VSHN

7.1. Reactive

7.2. Proactive

7.3. Governance Approach

8. VSHN’s Culture - Frequently Asked Questions

8.1. Practical, Real Questions

9. Your First Day

9.1. The Office

9.2. Working remotely

9.3. Working Hours

9.4. Your Mentor

9.5. Your Introductory Blog Post

9.6. Hardware and Software

9.7. Desktop Wallpaper and Virtual Background for Zoom

9.8. VSHN Central

10. Trial Period

10.1. During the Trial Period

10.2. End of the Trial Period

11. Disciplinary Process

11.1. Meta Information

11.2. Procedure

11.3. Communication of this Disciplinary Process

12. Performance Improvement Plans (PIP)

12.1. Definition

12.2. Purpose

12.3. Procedure

12.4. Examples of when a PIP is considered:

13. Salary System

13.1. Salary System

13.2. Salary Evolution

13.3. Deductions

13.4. Benefits

13.5. Employment Termination

14. Employee Benefits

14.1. Holidays

14.2. Work time and flexibility

14.3. Half Fare Travelcard

14.4. Recurring Budget for Workplace

14.5. Education / Training

14.6. Parental Leave

14.7. Phantom Stock Program

14.8. Food and drinks in the office

14.9. Office massage

14.10. Company and Team events

14.11. Swibeco

14.12. Brands for employees

15. Personal Hardware Budget

15.1. General

15.2. Requirements

15.3. Recommendations

15.4. Private use

15.5. Insurances

15.6. Taking over old equipment

16. Personal Workplace Budget

16.1. Joy of choice

16.2. How to get the budget

17. Semi-Autonomous Teams

17.1. What is a Team?

17.2. VSHN Teams

17.3. Fundamental Responsibilities

17.4. Creating or Changing a Team

18. Fundamental Business Principles

19. Interest Groups

19.1. Structure

19.2. Constraints

19.3. How to create an Interest Group

19.4. How to Abandon an Interest Group

20. Working remotely

20.1. Rules

20.2. Socializing

20.3. Tips and Tricks

20.4. Links

21. Working at the office

21.1. Office / Floor Plan

21.2. Security Information

21.3. Different offices

21.4. Dedicated desks

21.5. Desk sharing

21.6. Including remote VSHNeers

21.7. Meetings

22. The Office Life

22.1. Common Tasks

22.2. Cleaning

22.3. Snack Engineering

22.4. Microwave

22.5. Hot beverages

22.6. Coffee machine - the real one

22.7. Expenses

22.8. Technical Orders

22.9. Medical supplies

22.10. Printer Room

22.11. Lunch

22.12. The Light

22.13. The Plants

23. Anti-Harassment Policy

24. Work Hours

24.1. Weekly Work Hours

24.2. Regular working schedule

24.3. Office Hours

24.4. Outside Office Hours

24.5. Public Holidays

24.6. Contractors abroad & EOR

25. Internal Communication Principles

26. Communication Channels

26.1. TL;DR

26.2. Written Channels

26.3. In-Person Channels

27. Emergency Communication Channels

28. Everyday life

28.1. Weekly Company Meeting

28.2. On-Call

28.3. Office Life

29. How to Answer Phone Calls

29.1. Greeting

29.2. Tips for the conversation

29.3. End of conversation

30. Customer Communication Guidelines

30.1. Response Time

30.2. Say Thank You and Sorry

30.3. Professionalism and Tone

30.4. Show Empathy and Attentiveness

30.5. Personalize Communication

30.6. Clear and Accessible Language

30.7. Empowerment and Self-Help

30.8. Follow-up and Closure

30.9. Structure of Emails and Tickets

30.10. Proactive Communication and Readiness

30.11. Invite Feedback

31. Incident Handling

31.1. Sources of Incident Alerts

31.2. Jira Ticket

31.3. Communication

31.4. Get Help and Coordinate

31.5. Distribute Responsibilities

31.6. Close Ticket

31.7. Next Steps and Follow up

32. What to do if someone is behaving in a non-VSHNary way?

32.1. Positive and negative examples of VSHNaryness

32.2. Next steps if someone is behaving in a non-VSHNary way

33. Conflict Resolution Process

33.1. 1. Talk to the other person

33.2. 2. Discuss with the team

33.3. 3. Talk to People Care

33.4. 4. Talk to Management

34. Holidays

34.1. In General

34.2. On the last day

34.3. After a holiday

34.4. Checking your Holidays

35. Pay Slip and Overtime

35.1. How to Get the Payslip

35.2. Overtime

36. Sick Leave

36.1. Checklist on Sick Day

36.2. After Back to Work

36.3. General considerations

37. Company Language

37.1. Does this mean you shouldn’t speak your native language?

37.2. Improving language skills

37.3. Links

38. Time Off

38.1. How to Record Leave Requests

38.2. Time Off types

39. Meeting Rooms

39.1. VSHNtower (8th Floor in Neugasse 6)

39.2. VSHNtower Small Room (Small Room South Side of 8th Floor in Neugasse 6)

39.3. VSHN Meeting Room (Big Room in Neugasse 10)

39.4. VSHN Entrance (Entrance Neugasse 10 Coffee Room)

40. How to do Meetings

40.1. What’s a meeting?

40.2. General

40.3. Attend a meeting

40.4. Schedule and facilitate a meeting

40.5. Links

41. Harmonized Meeting Schedule

41.1. Meeting Times

41.2. Exceptions

42. Time Tracking

42.1. Attendances

42.2. Overtime / Undertime

42.3. Timesheets

43. People Pulse and Feedback

43.1. VSHNeer Surveys

44. Tracking OKRs

44.1. Have a Space in the Wiki

44.2. Creating and Tracking OKRs

44.3. VSHN Specific Guidelines

45. How to Troubleshoot Docking Stations

45.1. Problem: Screen Flickering

45.2. Problem: Screen Is Detected but Remains Black

45.3. Problem: Ethernet Is Not Working

45.4. Problem: USB ports are not recognized by the docking station

45.5. Problem: Mac Does Not Support DisplayPort Version 1.2

46. Weekly Company Meeting

46.1. Rules

46.2. Meeting Notes

47. Learning and Reflection

48. One-on-one Meetings

48.1. Finding a VSHNeer to do one-on-one meetings with

48.2. Preparation

48.3. Format

48.4. Tips for the listening VSHNeer

48.5. Goals

48.6. Non-goals

48.7. Additional reading

49. Personal Coaching

49.1. Structure

49.2. Typical Subjects

49.3. Tips for Coachees

49.4. Tips for Coaches

50. Team retrospectives

50.1. Requirements

50.2. Safe environment

50.3. Plan

50.4. Followup

51. Personal Education

51.1. Individual Education

51.2. How to request individual education

51.3. VSHN Requested Education

52. VSHN HackDay

52.1. Before the event

52.2. The event itself

52.3. Course of the event

53. Licensing Guidelines

53.1. BSD 3-Clause License

53.2. Apache License 2.0

53.3. Server Side Public License (SSPL)

53.4. About the <YEAR>

54. Working with Contractors

54.1. Contractors working for VSHN

54.2. Contractors working for VSHN customers

55. Swiss VSHNeers working and living in Canada

55.1. Job and responsibilities

55.2. Requirements

55.3. Transition to Working in Canada

55.4. Expenses and travel

56. VSHNeers Flat in Vancouver, BC

56.1. House Rules

56.2. Processes

57. Working at the Vancouver office

57.1. Office

57.2. Security Information

57.3. Desk sharing

57.4. Meetings

58. Visiting Headquaters from abroad

58.1. Foreigner work in CH without work permit

58.2. Travel and expenses

59. Collaboration with VSHN Canada

60. Apprenticeships at VSHN

60.1. Organization of current apprenticeships

60.2. Planned apprenticeships

61. VSHN

61.1. Organization Canvas

62. Vision of VSHN

63. Key Drivers of VSHN

63.1. Companies that need to run software

63.2. Software developers and system engineers

63.3. VSHNeers are VSHN

64. VSHN Key Drivers FAQs

64.1. Why infrastructure and platform isn’t part of our key drivers?

65. Key Deliverables

65.1. Transition to Cloud Native Software Operations

65.2. Continuous Cloud Native Software Operations

65.3. Investment in our Organization

66. Customer Segments

66.1. Revenue through Online Application

66.2. Instances at Scale and SaaS

67. Unique Value Proposition

68. Key Challenges

68.1. Technology choice & keeping up

68.2. Partner Choice

68.3. Quality and stability of our service

68.4. VSHNeers, and how we are organized

69. Company Alignment

69.1. Aligned Organizational Structure

69.2. Agile Goal Setting

69.3. And where is Strategy in this?

70. VSHN Connect

70.1. Purpose

70.2. General

70.3. Planning

70.4. Format

70.5. Travel expenses

71. Company values

71.1. Values

72. Tech Strategy

72.1. Main Technology Beliefs

72.2. Make or Buy

72.3. Kubernetes First

72.4. Service Providers

72.5. Further Documents

73. Organizational Structure

73.1. The Domains of VSHN

74. Brand Guide

74.1. Logos

74.2. Mascot

74.3. Color Codes

74.4. Font

74.5. Desktop Wallpapers

74.6. Virtual Backgrounds for Zoom

74.7. Company Description

75. VSHN Central

75.1. First Login

75.2. Odoo API Access

76. Odoo 16 Tips and Tricks

76.1. Open Search Menu

76.2. Timesheet View

76.3. Formatting

76.4. Tasks / Tickets

77. Domains

77.1. What is a Domain

77.2. Creating and Delegating Domains

77.3. Reviewing Domains

77.4. Domain Descriptions

78. Domain Reviews

78.1. Summary

78.2. Review the Team and their Domain

78.3. Review a Role and their Domain

79. Role: Strategist

79.1. Purpose

79.2. Key Responsibilities

79.3. Stakeholders

79.4. Key Deliverables

79.5. Skills and Mindsets

79.6. Dependencies

79.7. Role Assignment

79.8. Evaluation Criteria

80. Role Customer Support Lead

80.1. Purpose

80.2. Key Responsibilities

80.3. Key Deliverables

80.4. Dependencies

80.5. Delegator Responsibilities

80.6. Mindset, Skills and Capabilities

80.7. Monitoring and Evaluation

81. VSHN Canada

81.1. Purpose

81.2. Key Responsibilities

81.3. Key Deliverables

81.4. Organization

81.5. Constraints

82. General Manager VSHN Canada

82.1. Purpose

82.2. Key Responsibilities

82.3. Key Deliverables

82.4. Monitoring and Evaluation

82.5. Constraints

83. Central Services

83.1. Key Responsibilities

83.2. Constraints

83.3. Evaluation Criteria

83.4. Accountable Team

84. Corporate IT

84.1. Purpose

84.2. Key Responsibilities

84.3. Key Deliverables

84.4. Key Resources

84.5. Constraints

84.6. Evaluation Criteria

85. DevOps Engineer

86. Office Management

86.1. Key Responsibilities

86.2. Dependencies

86.3. Evaluation Criteria

87. Finance

87.1. Key Responsibilities

87.2. Evaluation Criteria

88. Legal & Compliance

88.1. Key Responsibilities

89. Procurement

89.1. Key Responsibilities

89.2. Evaluation Criteria

90. Business Management

90.1. Purpose

90.2. Key Responsibilities

90.3. Key Deliverables

90.4. Delegator Responsibilities

90.5. Dependencies

90.6. Monitoring and Evaluation

91. Compensation Domain

91.1. Purpose

91.2. Stakeholders

91.3. Key Responsibilities

91.4. Key Deliverables

91.5. External Constraints

91.6. Key Resources

91.7. Delegator Responsibilities

91.8. Dependency

91.9. Mindset, Skills and Capabilities

91.10. Monitoring and Evaluation

92. Domain Application Catalog

92.1. Purpose

92.2. Stakeholders

92.3. Key Deliverables

92.4. Key Responsibilities

92.5. Definition of Done

92.6. External Constraints

92.7. Delegator Responsibilities

92.8. Dependencies

92.9. Key Resources

92.10. Mindset, Skills and Capabilities

92.11. Monitoring and Evaluation

92.12. Accountable Team

93. Domain APPUiO Managed OpenShift 4 & APPUiO Cloud

93.1. Purpose

93.2. Stakeholders

93.3. Key Deliverables

93.4. Key Responsibilities

93.5. Definition of Done

93.6. External Constraints

93.7. Delegator Responsibilities

93.8. Dependencies

93.9. Key Resources

93.10. Mindset, Skills and Capabilities

93.11. Monitoring and Evaluation

93.12. Accountable Team

94. Domain Canada Operations

94.1. Purpose

94.2. Stakeholders

94.3. Key Deliverables

94.4. Key Responsibilities

94.5. External Constraints

94.6. Dependencies

94.7. Key Resources

94.8. Mindset, Skills and Capabilities

94.9. Monitoring and Evaluation

94.10. Key Challenges

94.11. Accountable Team

95. Domain Managed Server based Services

95.1. Purpose

95.2. Stakeholders

95.3. Key Deliverables

95.4. Key Responsibilities

95.5. Definition of Done

95.6. External Constraints

95.7. Delegator Responsibilities

95.8. Dependencies

95.9. Key Resources

95.10. Mindset, Skills and Capabilities

95.11. Monitoring and Evaluation

95.12. Accountable Team

96. Domain AppOps & AppFlow

96.1. Purpose

96.2. Stakeholders

96.3. Key Deliverables

96.4. Key Responsibilities

96.5. External Constraints

96.6. Definition of Done

96.7. Delegator Responsibilities

96.8. Dependencies

96.9. Key Resources

96.10. Mindset, Skills and Capabilities

96.11. Monitoring and Evaluation

96.12. Accountable Team

97. Domain Marketing

97.1. Purpose

97.2. Key Responsibilities

97.3. Key Deliverables

97.4. Key Metrics

97.5. Dependencies

98. Domain Marketing & Sales

98.1. Purpose

98.2. Stakeholders

98.3. Key Responsiblities

98.4. Key Deliverables

98.5. Key Metrics

98.6. Dependencies

98.7. Key Resources

98.8. Delegator Responsibilities

98.9. Monitoring and Evaluation

98.10. Accountable Team

99. Domain Product Management

99.1. Purpose

99.2. Key Responsibilities

99.3. Key Deliverables

99.4. Key Challenges

99.5. Constraints

100. Domain Sales & Account Management

100.1. Purpose

100.2. Key Responsibilities

100.3. Key Deliverables

100.4. Key Metrics

100.5. Dependencies

100.6. Definition of Done

101. Deciding to Deliver: Sales Offering

101.1. Driver for this Agreement

101.2. Summary

101.3. 1. Preparation before the Meeting

101.4. 2. The Weekly Meeting

101.5. 3. Follow-up after Meeting

101.6. Responsibilities

101.7. Constraints

102. Customer Project Management

102.1. Driver for this Agreement

102.2. Process and Responsibilities

103. Domain Customer Support

103.1. Purpose

103.2. Stakeholders

103.3. Key Responsibilities

103.4. Key Deliverables

103.5. Dependencies

103.6. Key Challenges

103.7. Monitoring and Evaluation

103.8. Accountable Team

104. Requirements Engineering and Solution Design

104.1. Summary

104.2. Process Description

104.3. Monitoring and Evaluation

105. 24x7 Operations

105.1. Key responsibilities

105.2. Key Deliverables

105.3. Dependencies

105.4. Constraints

105.5. Risks

105.6. Evaluation Criteria

106. On-Call

106.1. Important wiki pages

107. Rulebook for Planned Work Ticket Workflow

107.1. Purpose

107.2. General Principles

107.3. Issue Types

107.4. Workflow Diagram

107.5. Preparatory Phase: New to Ready (Backlog)

107.6. Implementation Phase: Ready (Backlog) to Done

107.7. Customer Portal Rules

108. Sales On–Boarding Process

108.1. Introduction

108.2. Explanation of the Steps

109. How to do Avior Triage and Support

109.1. Jira

109.2. Important Links

109.3. Your Duties

110. People Operations

110.1. Key Responsibilities

110.2. Recruiting

110.3. Constraints

110.4. Evaluation Criteria

111. People Care

111.1. Key Responsibilities

111.2. Key Deliverables

111.3. Dependencies

111.4. Constraints

111.5. Key Challenges

111.6. Evaluation Criteria

112. Debt Collection Register and Criminal Records

112.1. Overview

112.2. Responsibility People Operations

112.3. Employee’s Duties

112.4. Based on

113. Annex to the Declaration of Confidentiality

113.1. Preamble

113.2. Swiss Criminal Code

113.3. Federal Act on Data Protection (FADP)

113.4. Swiss Federal Act on Banks and Savings Banks (BA)

113.5. Federal Act on Financial Institutions (FinIA)

113.6. Federal Act on Financial Market Infrastructures and Market Conduct in Securities and Derivatives Trading (FinMIA)

114. Recruiting

114.1. Importance and principles of Recruiting

114.2. Forms of Recruiting

114.3. Key responsibilities

114.4. Dependencies

114.5. Risks

114.6. Evaluation Criteria

115. Recruiting Process

115.1. Workflow in Recruitee

115.2. Open Positions

115.3. Job Ads

115.4. Handling Applications

115.5. Interviews

115.6. Contract and Paperwork

115.7. Onboarding

116. Reverse Interview

116.1. Tech

116.2. The Team

116.3. The Company

116.4. The Business

116.5. Remote Work

116.6. Office Work

116.7. Compensation

116.8. Time Off

117. Recruitment Pre Screening

117.1. One-Way Video Interview

117.2. Pre-Screen phone call

117.3. Decision

118. Recruiting 1st Meeting

118.1. Reflection and Feedback

118.2. Decision

119. 2nd Meeting

119.1. Decision

120. Onboarding New VSHNeers

120.1. Importance of onboarding

120.2. Who is involved with onboarding:

121. Recruiting Principles

121.1. People we enjoy working with

121.2. People with T-shaped skills

121.3. People stronger than ourselves

122. Partner Management: Definition and Scope

122.1. Overview

122.2. Objectives

122.3. Involved Activities

122.4. Types of Partners

123. Domain Products

123.1. Purpose

123.2. Key Responsibilities

123.3. Dependencies

123.4. Key Deliverables

124. Products Work Group

124.1. Meta

124.2. What we do

124.3. Members

125. Team Development Work Group

125.1. Members

126. Tech Alignment Work Group

126.1. Meta

126.2. What we do

126.3. Members

127. Domain Technology Alignment

127.1. Purpose

127.2. Key Responsibilities

127.3. Key Deliverables

128. Domain Team Development

128.1. Purpose

128.2. Key Responsibilities

128.3. Delegator Responsibilities

129. Information Security Management

129.1. Core Tasks

129.2. Constraint

129.3. Evaluation Criteria

129.4. Links

130. ISMS Policies

131. ISMS Acceptable Use Policy

131.1. Purpose, Scope, and User

131.2. Definitions

131.3. General

131.4. Confidentiality and Privacy

131.5. Equipment

131.6. Mobile Devices, Remote Working, and Bring Your Own Device (BYOD)

131.7. Data Storage

131.8. Copyright

131.9. Monitoring the Use of Information and Communication Systems

131.10. Incidents

131.11. Training and Awareness

131.12. Meta Information

132. ISMS Development Security Policy

132.1. Purpose, Scope and User

132.2. Reference Documents

132.3. Security in Development and Support Processes

132.4. Principles for the Analysis, Development and Maintenance of Secure Systems

132.5. Handling test data

133. ISMS Security Incident Management Process

133.1. Purpose, Scope and User

133.2. Definition of a Security Incident

133.3. Triggers of a Security Incident

133.4. Report Security Incident

133.5. Treatment

133.6. Learning from Incidents

133.7. Threat Intelligence

133.8. Disciplinary Measures

133.9. Collection of Evidence

133.10. Reference Documents

133.11. Appendix

134. ISMS Physical Security Policy

134.1. Purpose, Scope and User

134.2. Physical Security Perimeters

134.3. Access Rights

134.4. Visitor Logs

134.5. Physical Security Monitoring

134.6. VSHNeers' Duties

134.7. Events

134.8. Reference Documents

135. ISMS Supplier Security Policy

135.1. Purpose, Scope and User

135.2. Relationships with Suppliers and Partners

135.3. Cloud Services

135.4. Reference Documents

135.5. Appendix

136. Product Roadmap

136.1. Insights and Portal

136.2. Features

136.3. Roadmaps

136.4. Working with Productboard

136.5. Power Users and Admins

137. Product Maturity

137.1. Basics

137.2. Business and Growth

137.3. Marketing

138. Understand and Assign Drivers

138.1. Noticing Tension

138.2. Understanding Drivers

138.3. Is it an Organizational Driver?

138.4. Is it in our Domain?

138.5. Respond

138.6. Links

139. Respond to Organizational Drivers

139.1. Formats to do this

139.2. Links

140. Create Proposals

140.1. Co-Create Proposals

140.2. In more detail

140.3. Links

141. Governance meeting

141.1. Preparation

141.2. Tips for the Meeting

141.3. Links

142. Decision-Making at VSHN

142.1. Introduction

142.2. Operations vs. Governance

142.3. Consent Decision-Making

142.4. Leadership

143. Resolve Objections

143.1. Qualify Objections

143.2. Objections to proposed Agreements

143.3. Objections to existing Agreements or Activities

143.4. Formats to resolve Objections

143.5. Links

144. Evaluate and evolve everything

144.1. Examples

144.2. Links

145. Definition of Cloud Native

146. Definition of Cloud Infrastructure

147. Definition of Managed Service

148. VSHN Improvement Proposals

148.1. Overview

148.2. Implementation

148.3. Out of Scope

149. How to create VSHN Improvement Proposals

150. Decision-Making at VSHN

150.1. Introduction

150.2. Operations vs. Governance

150.3. Consent Decision-Making

150.4. Leadership

151. Teams at VSHN

151.1. Management

151.2. Board

152. Work Groups at VSHN

153. Management Work Group

153.1. Members

153.2. Official Signatures

153.3. C-Level roles

154. VSHN Product Portfolio

154.1. VSHN

154.2. APPUiO

154.3. Support Plans

154.4. Cloud Native Consulting

154.5. Reselling

154.6. An Analogy

155. VSHNeer Roles

155.1. Job (Main Role)

155.2. Additional Roles

155.3. Balance Main Role vs Additional Roles

155.4. Links

156. Business Development Manager

156.1. Key Responsibilities

156.2. Key Deliverables

156.3. Dependencies

156.4. Evaluation Criteria

156.5. Out of scope

156.6. Assignment of this role

157. Chief Marketing Officer (CMO)

157.1. Key Responsibilities

157.2. Competences, qualities and skills

157.3. Assignment of this role

158. Chief Information Security Officer (CISO)

159. Corporate IT Lead

159.1. Purpose

159.2. Key Responsibilities

159.3. Dependencies

160. Corporate IT Project Manager

160.1. Purpose

160.2. Key Responsibilities

160.3. Dependencies

161. Customer Account Manager

162. Developer Relations

162.1. Key Responsibilities

162.2. Competencies, Qualities and Skills

162.3. Evaluation Criteria

163. Inside Sales

163.1. Duties

163.2. Evaluation Criteria

163.3. Out of scope

163.4. Assignment of this role

164. Mentor

165. VSHN Tech Radar

165.1. Languages and Frameworks

165.2. Automation

165.3. System Services

165.4. Tools

165.5. How it works

166. People Operations Admin

166.1. Duties

166.2. Out of Scope

166.3. Requirements

167. Product Manager

167.1. Purpose

167.2. Key Responsibilities

168. Role Product Owner

168.1. Purpose

168.2. Stakeholders

168.3. Key Responsibilities

168.4. Key Deliverables

168.5. Key Resources

168.6. Constraints

168.7. Role Assignment

169. Role Team Facilitator

169.1. Purpose

169.2. Stakeholders

169.3. Key Responsibilities

169.4. Key Deliverables

169.5. Skills and Mindsets

169.6. Constraints

169.7. Key Challenges

169.8. Role Assignment

169.9. Delegator Responsibilities

169.10. Evaluation Criteria

170. Role Scrum Master

170.1. Purpose

170.2. Stakeholders

170.3. Key Responsibilities

170.4. Skills and Mindsets

170.5. Constraints

170.6. Key Challenges

170.7. Role Assignment

170.8. Delegator Responsibilities

170.9. Evaluation Criteria

171. Role Technology Alignment

171.1. Purpose

171.2. Key Responsibilities

171.3. Constraints

171.4. Role Assignment

172. Solution Architect

172.1. Purpose

172.2. Key Responsibilities

172.3. Key Deliverables

172.4. Delegator Responsibilities

172.5. Dependencies

172.6. Key Resources

172.7. Mindset, Skills and Capabilities

172.8. Monitoring and Evaluation

173. Role Apprentice Owner

173.1. Purpose

173.2. Stakeholders

173.3. Key Deliverables

173.4. Key Responsibilities

173.5. Key Resources

173.6. Dependencies

173.7. Delegator Responsibilities

173.8. Mindset, Skills and Capabilities

173.9. External Constraints

173.10. Monitoring & Evaluation

174. Role Apprentice Professional Education

174.1. Purpose

174.2. Key Deliverables

174.3. Key Responsibilities

174.4. Key Resources

174.5. Mindset, Skills and Capabilities

174.6. Monitoring & Evaluation

174.7. Assignment of this Role

175. Role Apprentice Technical Mentor

175.1. Purpose

175.2. Stakeholders

175.3. Key Deliverables

175.4. Key Responsibilities

175.5. Mindset, Skills and Capabilities

175.6. Monitoring & Evaluation

176. C-Level Titles

176.1. Signature Rights

176.2. If you need to name a C-level person

177. Terminology

177.1. Practices at VSHN

177.2. Corporate Management

177.3. Offering and Business Development

177.4. Organization Structure at VSHN

177.5. Various terms invented by VSHN

177.6. Good to know as a VSHNeer (inofficial)

177.7. Tool naming

177.8. German/English difficulties

178. VSHN Tooling

179. Documentation :description: Where to find documentation.

179.1. Documentation Index

179.2. Audience

179.3. Tools We Use

179.4. Documentation as Code

179.5. Handbook

179.6. Confluence Wiki

179.7. GitHub & GitLab

179.8. Jira

180. Jira

181. Project Management and Planning

182. Issue Types for Project Management

183. Project states

184. Project and Operations Reporting

184.1. Operations and Chores

184.2. Projects

185. Service Desk Workflow

185.1. Purpose

185.2. General Principles

185.3. Service Desk Workflow Diagram

185.4. Service Desk Issue Types

185.5. Issue States and How to Move Tickets.

185.6. Customer Portal Rules

186. E-mail

186.1. Webmail

186.2. Using an e-mail client

186.3. E-mail signature

186.4. Default e-mail address

186.5. Out of office replies

186.6. E-mail filters

186.7. Address book sync for local email clients (like Thunderbird)

187. Calendar

187.1. Share your Personal Calendar

187.2. Shared Calendars in SOGo

187.3. Create Recurring Meetings for Work/Interest Groups

187.4. Clients for Calendar

188. Git guidelines

188.1. Commit messages

188.2. Git Usage Basics

188.3. Tools

189. GitLab

189.1. Merge Requests

189.2. CI/CD

189.3. Pet Projects

190. Working with GnuPG

190.1. Create Key

190.2. Send to Server

190.3. Import Keys from Other Users

190.4. Exporting Keys for Backup

190.5. Using your Key

190.6. More Information

191. GnuPG and Evolution

191.1. Setup GnuPG in Evolution

191.2. Importing and Trusting Keys from Other Users

191.3. More Information

192. GnuPG and GitLab

193. Nextcloud

194. Merge Request Template

195. Chat Channels

195.1. Specification

196. Zoom Phone

196.1. Installation

196.2. How to use

196.3. Process

196.4. Call Queue Handling

196.5. TipTel

196.6. Virtual Backgrounds

196.7. Tips and Tricks

197. Password Tools

198. Passbolt

198.1. Installation

198.2. How to use

198.3. Process

198.4. Finding file attachments

198.5. FAQ

199. Passbolt User Documentation

199.1. How can I connect to Passbolt?

199.2. What is Passbolt?

199.3. How do VSHNeers get access to Passbolt?

199.4. How do I use Passbolt?

199.5. How to Add a Password

199.6. How to Use on a Second Browser/Computer

199.7. Things Missing from Passbolt

200. Recommended Password Managers

201. Generate a Password

201.1. pwgen

201.2. Generate a Memorable Password

201.3. Password Generator of Your PW Manager

201.4. Check Your Password

202. Videoconferencing Guidelines

202.1. Etiquette

202.2. Security

202.3. Sources

203. VSHN Corporate Services Strategy

203.1. Important points

203.2. Prefered services

204. Quick Links

204.1. General

204.2. Technical

204.3. Communication

Appendix A: Contributing to the Handbook

A.1. Language and Vocabulary

A.2. Documents

A.3. Branching Model

A.4. Workflow

A.5. Git Commit Messages

A.6. Tickets & Time Tracking

A.7. Useful Tools

A.8. Merge Request Approval Process

A.9. Release Process

A.10. Tips for Visual Studio Code Users

A.11. Other Recommended Tools

A.12. Recommended Reading

Appendix B: CHANGELOG

B.1. 2024-04-12

B.2. 2024-04-09

B.3. 2024-03-27

B.4. 2024-03-25

B.5. 2024-03-22

B.6. 2024-03-21

B.7. 2024-03-18

B.8. 2024-03-13

B.9. 2024-03-12

B.10. 2024-03-05

B.11. 2024-02-22

B.12. 2024-02-14

B.13. 2024-01-31

B.14. 2024-01-04

B.15. 2024-01-03

B.16. 2023-12-21

B.17. 2023-12-05

B.18. 2023-12-04

B.19. 2023-12-01

B.20. 2023-11-24

B.21. 2023-11-13

B.22. 2023-11-09

B.23. 2023-11-08

B.24. 2023-11-07

B.25. 2023-10-31

B.26. 2023-10-25

B.27. 2023-10-16

B.28. 2023-10-04

B.29. 2023-10-02

B.30. 2023-09-28

B.31. 2023-09-26

B.32. 2023-09-25

B.33. 2023-09-19

B.34. 2023-09-18

B.35. 2023-09-13

B.36. 2023-09-08

B.37. 2023-09-01

B.38. 2023-08-29

B.39. 2023-08-23

B.40. 2023-08-14

B.41. 2023-08-07

B.42. 2023-08-03

B.43. 2023-07-28

B.44. 2023-07-26

B.45. 2023-07-25

B.46. 2023-07-24

B.47. 2023-07-21

B.48. 2023-07-20

B.49. 2023-07-19

B.50. 2023-07-18

B.51. 2023-07-17

B.52. 2023-07-14

B.53. 2023-07-10

B.54. 2023-07-03

B.55. 2023-06-26

B.56. 2023-06-23

B.57. 2023-06-14

B.58. 2023-06-13

B.59. 2023-06-09

B.60. 2023-05-24

B.61. 2023-05-15

B.62. 2023-05-10

B.63. 2023-05-09

B.64. 2023-05-03

B.65. 2023-04-28

B.66. 2023-04-25

B.67. 2023-04-21

B.68. 2023-04-18

B.69. 2023-04-14

B.70. 2023-04-13

B.71. 2023-04-12

B.72. 2023-04-11

B.73. 2023-04-05

B.74. 2023-04-04

B.75. 2023-04-03

B.76. 2023-03-31

B.77. 2023-03-27

B.78. 2023-03-20

B.79. 2023-03-17

B.80. 2023-03-16

B.81. 2023-03-14

B.82. 2023-03-13

B.83. 2023-03-02

B.84. 2023-02-28

B.85. 2023-02-27

B.86. 2023-02-24

B.87. 2023-02-23

B.88. 2023-02-17

B.89. 2023-02-16

B.90. 2023-02-14

B.91. 2023-02-10

B.92. 2023-02-09

B.93. 2023-02-01

B.94. 2023-01-31

B.95. 2023-01-20

B.96. 2023-01-19

B.97. 2023-01-18

B.98. 2023-01-17

B.99. 2023-01-16

B.100. 2023-01-06

B.101. 2023-01-05

B.102. 2023-01-04

B.103. 2022-12-30

B.104. 2022-12-27

B.105. 2022-12-14

B.106. 2022-12-06

B.107. 2022-11-29

B.108. 2022-11-28

B.109. 2022-11-25

B.110. 2022-11-23

B.111. 2022-11-22

B.112. 2022-11-21

B.113. 2022-11-18

B.114. 2022-11-17

B.115. 2022-11-14

B.116. 2022-11-10

B.117. 2022-11-09

B.118. 2022-11-07

B.119. 2022-11-03

B.120. 2022-11-02

B.121. Old Changelogs

Appendix C: License & Copyright

Appendix D: VSHN Employee Handbook README

D.1. Contributions

D.2. Requirements

D.3. Build Instructions

D.4. Deployment

Colophon

The VSHN Handbook

Welcome to the VSHN Handbook! We’re very happy that you are reading it.

VSHN (pronounced like “vision”) is Switzerland’s leading partner for DevOps, Container & Kubernetes.

This handbook contains all you need to know to start collaborating with your teams and to understand the day-to-day intricacies of what we do.

At VSHN we do things a bit differently, but there is one core feature we expect from everyone here: to collaborate in writing. Writing things down helps us to work better, answering questions before they’re even asked.

Contributing to the handbook

Of course, not all questions have been asked yet! This is why this Handbook is open for collaboration. Just go to the project home page in GitLab and follow the instructions there. Spoiler: you only need a text editor and a Git client installed to help.

This Handbook contains a lot of information, but definitely not all of it. There is a whole Wiki available, whose contents are continuously updated–by everyone, including you!

And as the saying goes: "Question, don’t assume!" We’re here to help.

Download the Handbook

This handbook is also available in PDF and EPUB 3 formats, and even as a man page! Download the version you prefer most and read it any way you like.

Install the man Page

You can install the man page in your system using these commands:

$ sudo cp handbook.1 /usr/local/share/man/man1
$ sudo mandb

After these operations, the command man handbook will display the handbook in your terminal.

1. Information about SARS-CoV-2 / COVID-19

The COVID Work Group will remain passive for the time being and will be revived if new regulations will be announced in fall. Ask in #covid-wg (or covid19@vshn.ch) if you’ve any questions regarding the handling of the Corona virus at VSHN.

1.1. Summary

As of Apr 1st, 2022, there are no restrictions anymore at all.

We still ask you to stay home if you feel ill.

This policy is tracked and reviewed as VIP-152

2. VSHN’s Culture - How we do things around here

Since our founding in 2014, VSHN’s culture has been based on transparency, shared responsibility, and inclusivity, with a focus on leadership by every individual VSHNeer, rendering traditional leadership roles obsolete. It is widely recognized that such an ecosystem demands significantly more from each individual to function effectively. While there is a broad understanding at VSHN that a classic power hierarchy is not desirable as a leadership system, we often find that the level of individual participation and personal development required by our system is not yet being met. Even though we have achieved a lot in this system over the years, these circumstances sometimes lead to situations where VSHNeers are unclear about what to do, resulting in major business obstacles or frustrations among VSHNeers not being addressed.

Recognizing the need to enhance and maintain a common basic understanding of VSHN’s way of collaborating and working — our culture — we document our current understanding of how things are and should be based on our beliefs (see The Evolution of Culture below).

While not everyone needs to be an expert in all these topics, a shared understanding, commitment, and engagement from every VSHNeer are essential for the flourishing and further development of our culture. Of course, reading documentation is far from enough, but let’s start somewhere, here.

2.1. VSHN’s Culture in a Nutshell

At VSHN, we negate traditional power hierarchies, favoring a culture of shared leadership and decision-making that relies on reason, not rank. Our semi-autonomous teams carry the freedom and responsibility to do the work that’s needed, deciding on the 'how' themselves. We operate iteratively, delivering value and resolving issues one step at a time. Transparency is fundamental in our operations, making information available and progress visible to all who need it, while respecting confidentiality when required.

Key Aspects Where VSHN is Different

The following 5 key aspects are intended to give you an overview of how VSHN specifically differs from what you might be used to from your time before VSHN.

We think that this currently overlaps with and extends our Company Values. We will figure out if this needs to be merged at some point. Think of it as hopefully a more concrete addition and description of our values.

There Are no Bosses Who Decide

Decisions are powered by reason and involve affected people, not rank or position.

At VSHN, we embrace non-hierarchical principles for Decision Making and leadership. The power to influence decisions lies with reasoned arguments and not with people in specific roles or ranks, and we involve the people responsible and those affected by the decision. It’s crucial that decisions are made, and therefore equally crucial that someone takes the initiative to drive them; otherwise, they simply won’t occur. These principles apply at all levels within the organization, including our "Management Team".

More on this here.

Leadership in Every Chair

The act of being aware, identifying what is needed, and insisting it gets addressed. We empower everyone to do so.

Leadership at VSHN is not limited to a specific role or rank. It’s seen as the act of recognizing what is needed and ensuring it gets addressed, whether proactively or in response to current issues. This involves bringing people together, fostering a common understanding of what is needed, and persistently driving progress until the need is adequately met. It’s about mindsets, skills, methods, and how you engage and inspire people — all of which can be learned, trained, and practiced. When people drive things forward and make happen what is needed, this is leadership in action.

Each individual’s personal leadership style is defined by how they navigate these challenges. Some roles may necessitate more explicit leadership on certain topics, ensuring that crucial decisions are made.

More on this here.

Semi-Autonomous Teams

Teams have the freedom and responsibility to do what’s needed to create value and to decide how.

Each team is allocated a specific area of VSHN, providing them with a domain of influence, work, and decision-making. This freedom to decide and do things how they think works best also comes with the responsibility to do so effectively, contributing to the overall purpose and objectives of VSHN (see Alignment). Therefore, such a team is semi-autonomous. An important factor is that the potential workload usually exceeds the team’s capacity, making prioritization essential - time is made by selecting the right tasks. Balancing work from different sources and finding the equilibrium between operational work and improving team organization and working methods is crucial. It’s never just one thing or the other; it’s usually both and more, and breaking down larger efforts into manageable pieces for iterative work is a common approach. Teams often have dedicated roles such as Product Owners, Facilitators, or Scrum Masters to help in finding this balance and fostering continuous improvement.

Those who delegate a domain to the team retain overall accountability, which means if the team encounters issues they can’t address on their own, or if they fail to recognize them, the delegator may need to provide support, empower the team, or even object to current activities. The delegator must continuously maintain a high-level understanding of whether the team is functioning and delivering as expected and required.

More on this here.

Delivering Value Iteratively

Creating value and addressing issues, one iteration at a time.

At VSHN, we devote time to what brings us and our customers forward now, delivering tangible value early. We identify one thing out of this complex world, agree on a common understanding of this need, and then find and implement a solution that addresses the need by adding increments of features or solutions, in an iterative manner. We validate if it works and then proceed to the next iteration. Less but sooner is usually better than more or perfect too late — long periods of work without obtaining stakeholder feedback or verifying if it truly functions or improves the situation isn’t acceptable — not in product development or customer projects, nor in addressing or organizational challenges.

Full Transparency

Proactive communication and easy access to all information for those who need it. Confidentiality is respected when necessary.

We provide open access to all information within VSHN, unless confidentiality is required. This commitment to transparency means we make our work visible, document our progress, record our decisions, and explain how we arrived at them. Not everyone is expected or required to read everything, as this can be overwhelming. Instead, it’s about making information readily available when needed, and proactively communicating essential information to those directly affected. This principle fosters an environment where progress is evident, feedback can be acquired early, others can take over anytime and continuous improvement is achievable. We value and encourage authenticity in our work, with an emphasis on producing visible, tangible effective results rather than merely appearing busy.

The Evolution of Culture

Our unique organizational culture didn’t appear overnight, there were also never big changes like an "agile transformation" or similar, as VSHN always was more or less like this. From our start, we avoid traditional hierarchical power structures in favor of collaboration and mutual decision-making. With a small team, ad-hoc, collective decisions were feasible. As we grew, we began to articulate our values, which continue to guide our behavior, actions, and decision-making at all levels.

Company culture is the organic essence of an organization, shaped by beliefs, values, attitudes, and practices. It can be observed but not enforced and naturally emerges from our collaboration, communication, decision-making, experiences of success and also failures.

In its simplest terms, to change culture, things need to happen differently, and things happen when people take responsibility, act and get things done. As by our definition of leadership this can and should be anyone. Culture change is an organic process that emerges naturally when individuals and teams start behaving and doing things differently in alignment with new or altered beliefs, values, and practices. It’s not simply a matter of issuing a mandate or directive; it must be lived and experienced on a day-to-day basis across the organization.

Anticipated Impact

We believe business benefits of such models are significant and align with our vision at VSHN. They promote agility, innovation, and responsiveness, allowing us to adapt quickly to changing circumstances and to take advantage of emerging opportunities. By decentralizing decision-making and promoting leadership at all levels, we can tap into our collective knowledge and skills more effectively, leading to more informed decisions and innovative solutions. Though, we acknowledge that sometimes how we do things at VSHN can also be more time consuming, frustrating and even slow us down — let’s improve!

Sociocracy 3.0 at VSHN

The principles of Sociocracy 3.0 (S3) and a lot of its patterns (see them as tools) resonated with us, providing practical guidance that aligned with our values and helped us navigate our growth. However, we never strictly adhered to any singular framework nor is S3 a framework. While we utilize various approaches and tools — S3 just being one toolbox, we prioritize what is effective and aligned with our objectives, regardless of the method.

People Make the System Work

At VSHN, we recognize that our system and culture, built upon shared leadership and transparency, are a considerable departure from traditional work environments. Such a model requires increased engagement, proactive behavior, and continuous personal development from every individual, surpassing the skills needed for operational tasks. However, it also offers a sense of empowerment, autonomy, and personal growth, along with shared responsibilities that can alleviate the overall mental burden for individuals. We also don’t have better-paid roles (like bosses) that receive higher pay solely to take the blame.

We don’t expect everyone to grasp or fully implement all the practices described here immediately, but it is crucial that there is a baseline alignment with our values and principles for collective success. At VSHN, we have roles that specifically focus on organizational aspects and governance, such as our Management Team, Scrum Masters, Facilitators, and more. We believe in supporting every individual, providing opportunities for growth, and even facilitating mindset shifts on these topics.

While our culture fosters personal development and job satisfaction, we acknowledge that it may not align with everyone’s aspirations. This acknowledgment doesn’t reflect a failure on anyone’s part but rather illustrates the importance of recognizing the fit between individuals and their work environment. Our ultimate aim is to cultivate a setting where individuals can thrive, grow, and make significant contributions—whether that’s within VSHN or beyond.

The big risk in this

There’s a risk in such a system, a risk of a vacuum where no one drives decisions or activities within reasonable time — anyone leads could mean no one leads. However, the real issue often lies not in the absence of a person deciding, but in the absence of leadership driving the topic to the decision point and beyond that. This applies equally in traditional power hierarchies when your boss is overloaded and doesn’t drive certain things.

A safeguard here is understanding that when responsibility is delegated, the Delegator remains overall accountable (refer to Semi-Autonomous Teams). Simply put, if the team really wouldn’t care enough, the Delegator has to support and empower the team to be able to care and can’t look away. Such dynamics should invariably surface during Domain Reviews.

We are a Business After All

We need to generate enough revenue to be a great employer, provide attractive benefits, and ensure our financial sustainability. However, the reality is more complex than this.

At VSHN, we operate in a competitive market. Our tasks involve attracting and retaining customers, generating revenue, and thus preserving our financial stability. While one of our priorities is to value and nurture our VSHNeers, we also have the responsibility to strike a balance between their well-being and the overall financial health of our organization. Our focus lies in operating as a successful business, not driven solely by profit, but also because it allows us to realize our vision, create an enriching work environment, and cultivate opportunities for personal and professional growth.

When making decisions, we recognize that personal preferences or subjective feelings alone are not sufficient grounds to dismiss proposed tasks or actions. Instead, we heavily rely on reasoned arguments, especially when there is a potential risk to the organization or its ability to fulfill commitments. While individual preferences are important, in our decision-making, it’s about the arguments that support our ability to attract and retain customers, generate adequate revenue, and maintain our competitive position. By adhering to this approach, we can strike a balance between individual preferences and the collective success of our business. That being said, while customers are our priority and the key to our success, we will not compromise our organization’s health; they are not a priority at any cost.

More on this here.

2.2. What’s Next?

Frequently Asked Questions

You might have many questions, both about your daily work life and after reading all this. This is normal, and a great starting point to learn more. Perhaps your question is already (partly) answered in the VSHN Culture FAQs.

Further Self-Learning

This page serves as an overview of how we do things around here. The whole handbook attempts to document how we behave and do things at VSHN. There are links to other handbook pages in the text above. While what exactly you should read about heavily depends on your level of experience, your role, and the tasks you currently have to perform, it might be a good starting point.

Practice

While reading about these concepts should greatly help to give you a good overview and base understanding of things, it’s known that training, exposure (actually having to do things), and learning from others' experiences are what really accelerates your personal development.

We encourage you to:

expose yourself, try leading smaller topics in your team, start taking responsibility to make things happen that need to happen — and while doing so, remember these concepts.

share your experiences with others.

invest in learning by taking internal (live or asynchronous) and external education, etc.

get facilitation help whenever you’re unsure or find an internal mentor on these topics.

More Guided Ways of Learning

We’re currently contemplating how we can make this more guided and offer fitting training for different levels of required skills, etc.

3. Decision-Making at VSHN

A team has a lot of different work - customer support, incident handling, proactive product development tasks, and more. Given the sheer volume, they need to prioritize and organize who does what. The Product Owner prepares the backlog (Proposal), what to include in the sprint (an act of Leadership). Unless there is a reason why starting the sprint as proposed is a risk, the team commits and begins (Consent Decision in Operations). Everyone is now working on tasks (Operations).

During the sprint, a major incident occurs. In the next standup meeting, the engineer working on it asks for assistance. Another engineer volunteers to help but points out that doing so will prevent the completion of two sprint tasks (another act of Leadership). The team deems fixing the incident as a higher priority, and in the absence of reasons against it, two engineers are assigned to address the incident (again Consent Decision in Operations).

Over the next four sprints, the team consistently struggles to collaborate with another team due to differing Jira issue types. They agree that this issue is a significant hindrance (Consent to Driver). One team member suggests adopting the same issue types as the other team uses. With no objections raised, they proceed to make the change (Consent Decision in Governance).

~ A little story that summarizes everything outlined on this page.

Decisions at VSHN are made in both our operational and governance contexts. In both scenarios, we try to follow the principles of Sociocracy 3.0 to make decisions collectively involving the people that would be affected by the decision (Equivalence) and based on reasoned arguments (Consent). We understand what is needed, propose a next step or a solution and if there are no reasons why it would hurt us, why we couldn’t at least try it, we move forward with it.

3.1. Introduction

Decisions are powered by reason and involve affected people, not rank or position.

At VSHN, we embrace non-hierarchical principles for Decision Making and leadership. The power to influence decisions lies with reasoned arguments and not with people in specific roles or ranks, and we involve the people responsible and those affected by the decision. It’s crucial that decisions are made, and therefore equally crucial that someone takes the initiative to drive them; otherwise, they simply won’t occur. These principles apply at all levels within the organization, including our "Management Team".

3.2. Operations vs. Governance

At VSHN, we differentiate between Operations and Governance. This distinction, while a key concept in Sociocracy, isn’t exclusive to it. In any organization, team, or even for individuals, there’s a need to perform work (Operations) and to define the environment, our goals, rules, processes, etc. (Governance).

Example

Planning and prioritizing your work, and doing the actual tasks you planned, is Operations. But determining how you plan your work, for example whether we do Scrum or plain Kanban, or setting customer communication guidelines that we want to stick to, that would be Governance.

Operations

Operations relate to doing the work and the organization of day-to-day activities within the constraints defined by governance. This is what most of us engage in on a daily basis - the actual work you do, such as programming, calls with customers, resolving incidents, doing backoffice admin work, you name it. It also includes organizing and planning your work.

Although "Operations" is a common term in tech teams referring to unplanned tasks like incident responses and customer requests, in this context, Operations includes both planned and unplanned day-to-day activities.

Coordination

Coordinating and planning work is also within Operations and not Governance, as refining tasks and prioritizing them are one-time decisions.

Tracking Operations

In theory, you could keep all the work you have to do in your mind, remembering what to do and by when. In practice, this only scales to a certain point. Also, because you share the responsibility to get the necessary work done with your other team members, it’s important to write down, visualize, and track progress on work items. The most common way is through task lists, Jira issues, etc. Larger chunks of work are planned in Epics, Projects, etc. - Kanban is usually a great visualization to make work (Operations) visible.

Governance

Governance, on the other hand, involves the process of setting objectives and making and evolving decisions that guide how you do your work. This includes making and evolving policies and procedures about how we work together, distributing responsibilities and power, selecting people for roles and teams, accounting for dependencies between teams, distributing resources, developing strategy, setting priorities and objectives, and making all consequential decisions about products, services, tools, technology, security, and more.

Who does Governance?

Governance is not exclusive to a board or managers. It happens at all levels within the organization. Everyone who makes or contributes to governance decisions is a part of this process, often even unknowingly. We encourage everyone to participate in governance decisions, whether in dedicated governance meetings, on the fly during the working day, or in one-off meetings dealing with a specific topic. For transparency and future reference, we document our decisions.

Teams at VSHN are self-governing, meaning the whole team shares the responsibility to make and evolve agreements which govern how the people doing the work in their domain create value.

Defining the team’s domain - their purpose, responsibilities, products, etc. - is also part of Governance. This is done collaboratively by the Delegator and the Delegatees (the Team). This is also what ensures that the Delegator remains overall accountable for what is delegated to the Team - if they don’t deliver, they are stuck addressing issues or other issues, the Delegator needs to work this out together with the team, but doesn’t do it for them.

Tracking Governance

In theory, you could do this off the top of your head, understand the need to change a policy, propose something verbally, and ask people if they see any potential objections. If not, move forward and implement what you proposed. In practice, like with Operational work, this doesn’t scale, and it’s very difficult to reach a common understanding of what the problem might be and what your proposal implies.

For larger topics (drivers), we have an implementation in Jira - the VSHN Improvement Proposals. This is essentially a way to track the status of a governance item from understanding the problem, identifying who is responsible, finding a solution, making the decision, and reviewing the implementation and effectiveness of the decision.

It’s okay to make smaller decisions directly in meeting agendas, for example. Be aware, however, that we still document and proactively inform the people affected by the decision, and that we still need to follow up later to see if what we decided is effective.

VSHN Improvement Proposals, aka VIPs, are not Governance, they’re a way to track Governance. Governance needs to happen whether we use VIPs, something else, or nothing to track our Governance decisions. Compare tracking your normal work in Jira. Whether you use Jira or not, the work is still there, needs to be prioritized, worked on, and done.

3.3. Consent Decision-Making

The following provides an overview of key elements in making decisions based on the principle of Consent. This is a very big topic, while we encourage you to try based on what you learn here, we acknowledge that it requires quite some education, training, and experience to facilitate this in group meetings or semi-asynchronously. Our goal is to have enough Facilitators who can assist you and facilitate for you where useful. Still, to participate, a common understanding of the following elements is crucial.

Consent

Giving Consent to something or consenting means the absence of Objections. It’s not to be confused with Consensus, which would mean that everyone has to agree.

Implicit Contract of Consent:

In the absence of objections to an agreement, I intend to follow through on the agreement to the best of my ability.
I agree to share objections as I become aware of them.

Objection

An Objection is an argument relating to a (proposed) agreement or activity that reveals unintended consequences we’d rather avoid, or that demonstrates worthwhile ways to improve right now.

In turn, having no Objection means:

Despite my best effort I can see no reason why the proposed agreement would harm our organization.

I see no way to significantly improve the proposal on the spot.

I don’t think the proposed agreement conflicts with an existing agreement.

I think this proposal is *good enough for now and safe enough to try*.

You can’t have an objection - you might have a possible objection, when you dig into it together you find out what is behind your argument and whether it reveals risk or ways to improve the proposal. If that is the case, it’s an objection and we need to somehow change the proposal to integrate what we learned.

Proposal

At VSHN, you’ll often hear that we follow a proposal until there are reasons not to (an Objection). But where do Proposals come from?

First, you agree on the driver - the problem or opportunity you want to address - and then you research the issue to learn more about the details and understand all the important considerations and constraints before moving on to brainstorming ideas and finally using all the information you’ve gathered to draft a proposal.

Driver

Always start with the Why.

A Driver is a simple but powerful concept. It’s about understanding what is needed, collaboratively, to have a common understanding of what the problem or opportunity is, that you need to address. After that, we can start finding solutions and create a Proposal.

The tricky thing here is, that we as humans are often taught to think in solutions, but actually, the power to do the right thing lies between understanding what’s needed and then finding out what to do - Move out of autopilot. This is especially important, as other people might have a completely different understanding of what is needed.

If we skip understanding the Driver (the Why), it’s likely that we get stuck in "Moving forward with a proposal until there is a reason not to" (Consent), because people will question what we need to do and why in the first place.

3.4. Leadership

Leadership at VSHN plays a crucial role in facilitating decision-making processes and ensuring that decisions are followed up on. Leaders are not just those in traditional hierarchical roles - every individual is empowered to lead within their area of responsibility. It’s easy to say "No one takes the needed decisions" - what is likely the case is that it’s more an issue of missing leadership and not flawed Decision Making - Ensure that we see the need, insist that we come up with a proposal and that we decide together.

See The big risk in VSHN’s culture for an overview of this topic.

4. Operations vs. Governance

At VSHN, we differentiate between Operations and Governance. This distinction, while a key concept in Sociocracy, isn’t exclusive to it. In any organization, team, or even for individuals, there’s a need to perform work (Operations) and to define the environment, our goals, rules, processes, etc. (Governance).

Example

Planning and prioritizing your work, and doing the actual tasks you planned, is Operations. But determining how you plan your work, for example whether we do Scrum or plain Kanban, or setting customer communication guidelines that we want to stick to, that would be Governance.

4.1. Operations

Operations relate to doing the work and the organization of day-to-day activities within the constraints defined by governance. This is what most of us engage in on a daily basis - the actual work you do, such as programming, calls with customers, resolving incidents, doing backoffice admin work, you name it. It also includes organizing and planning your work.

Although "Operations" is a common term in tech teams referring to unplanned tasks like incident responses and customer requests, in this context, Operations includes both planned and unplanned day-to-day activities.

Coordination

Coordinating and planning work is also within Operations and not Governance, as refining tasks and prioritizing them are one-time decisions.

Tracking Operations

In theory, you could keep all the work you have to do in your mind, remembering what to do and by when. In practice, this only scales to a certain point. Also, because you share the responsibility to get the necessary work done with your other team members, it’s important to write down, visualize, and track progress on work items. The most common way is through task lists, Jira issues, etc. Larger chunks of work are planned in Epics, Projects, etc. - Kanban is usually a great visualization to make work (Operations) visible.

4.2. Governance

Governance, on the other hand, involves the process of setting objectives and making and evolving decisions that guide how you do your work. This includes making and evolving policies and procedures about how we work together, distributing responsibilities and power, selecting people for roles and teams, accounting for dependencies between teams, distributing resources, developing strategy, setting priorities and objectives, and making all consequential decisions about products, services, tools, technology, security, and more.

Who does Governance?

Governance is not exclusive to a board or managers. It happens at all levels within the organization. Everyone who makes or contributes to governance decisions is a part of this process, often even unknowingly. We encourage everyone to participate in governance decisions, whether in dedicated governance meetings, on the fly during the working day, or in one-off meetings dealing with a specific topic. For transparency and future reference, we document our decisions.

Teams at VSHN are self-governing, meaning the whole team shares the responsibility to make and evolve agreements which govern how the people doing the work in their domain create value.

Defining the team’s domain - their purpose, responsibilities, products, etc. - is also part of Governance. This is done collaboratively by the Delegator and the Delegatees (the Team). This is also what ensures that the Delegator remains overall accountable for what is delegated to the Team - if they don’t deliver, they are stuck addressing issues or other issues, the Delegator needs to work this out together with the team, but doesn’t do it for them.

Tracking Governance

In theory, you could do this off the top of your head, understand the need to change a policy, propose something verbally, and ask people if they see any potential objections. If not, move forward and implement what you proposed. In practice, like with Operational work, this doesn’t scale, and it’s very difficult to reach a common understanding of what the problem might be and what your proposal implies.

For larger topics (drivers), we have an implementation in Jira - the VSHN Improvement Proposals. This is essentially a way to track the status of a governance item from understanding the problem, identifying who is responsible, finding a solution, making the decision, and reviewing the implementation and effectiveness of the decision.

It’s okay to make smaller decisions directly in meeting agendas, for example. Be aware, however, that we still document and proactively inform the people affected by the decision, and that we still need to follow up later to see if what we decided is effective.

VSHN Improvement Proposals, aka VIPs, are not Governance, they’re a way to track Governance. Governance needs to happen whether we use VIPs, something else, or nothing to track our Governance decisions. Compare tracking your normal work in Jira. Whether you use Jira or not, the work is still there, needs to be prioritized, worked on, and done.

5. Leadership at VSHN

Our organizational culture is based on the philosophy of distributed responsibility and leadership. This decentralized model enables us to tap into our team’s collective intelligence and potential, fostering an environment of innovation, shared responsibility, and effective problem-solving. Importantly, it mitigates the mental burden that usually falls on a single team lead, promoting a balanced distribution of responsibilities. This ensures that no single person is overwhelmed with the need to know everything, solve every problem, or drive progress alone.

The act of being aware, identifying what is needed, and insisting it gets addressed. We empower everyone to do so.

Leadership at VSHN is not limited to a specific role or rank. It’s seen as the act of recognizing what is needed and ensuring it gets addressed, whether proactively or in response to current issues. This involves bringing people together, fostering a common understanding of what is needed, and persistently driving progress until the need is adequately met. It’s about mindsets, skills, methods, and how you engage and inspire people — all of which can be learned, trained, and practiced. When people drive things forward and make happen what is needed, this is leadership in action.

Each individual’s personal leadership style is defined by how they navigate these challenges. Some roles may necessitate more explicit leadership on certain topics, ensuring that crucial decisions are made.

5.1. Developing Leadership

To develop a leadership mindset, it’s essential to cultivate awareness, communication skills, empathy, and initiative. We encourage our team members to be curious, seek understanding, and anticipate the needs of our projects and colleagues. We believe that anyone can foster these skills with practice and intentionality.

Although leadership is a shared responsibility at VSHN, some roles may necessitate more explicit leadership in specific areas. These positions ensure that crucial decisions are made and key objectives are met, examples are Product Owner, members of the Management Team, Team Facilitators, People Operations. That being said, having such roles doesn’t meant that others can’t or shouldn’t lead certain things as well.

At VSHN, we invest in nurturing the leadership potential of our team members through continuous learning opportunities and supportive feedback mechanisms. We recognize that leadership styles can vary greatly among individuals and that each person’s approach is shaped by their unique experiences, strengths, and challenges.

5.2. Leadership in Action

Leadership at VSHN is not an abstract concept; it is a living thing that is seen in action every day. Leadership is what you can see and observe, when things happen, when people solve problems, achieve goals together, do what is needed. Whether it’s an engineer taking the initiative to solve a complex problem, a team member suggesting a process improvement, or an employee standing up for an important cause, leadership permeates every aspect of our work.

We acknowledge, that there is a lack of leadership in some areas of VSHN and that this often manifests especially in big opportunities or problems not being addressed, felling like in Decision Making at VSHN is the cause, while it’s likely missing leadership.

6. Company Alignment

Every business, including ours, must navigate the ever-changing market and uncertain world (VUCA: volatility, uncertainty, complexity and ambiguity) to find success and growth. It’s not enough to react; we need a shared understanding of our objectives (where we want to go as a business and organization) and the path to achieve them. Alignment is about having an internal compass in this volatile landscape. It anchors our self-managing teams to our overarching purpose and vision, preventing fragmentation and self-directed divergence. It assures every team and every VSHNeer understands their role, their part, in achieving our vision. In a small startup, daily conversations might suffice for alignment, but with 50+ people, we need a more systematic approach. We avoid rigid frameworks and classic command-and-control styles, yet we seek clarity in creating alignment, ensuring efficient and unified efforts towards our goals.

Alignment at VSHN can be seen as two tracks: our aligned Organizational Structure and the Agile Goal Setting track.

6.1. Aligned Organizational Structure

Having an Aligned Organizational Structure means, that teams and roles serve a higher purpose (company purpose). At VSHN this is done through Delegation that starts at the top (Board and Management Team) involving the teams in the needed decisions for this. This ensures that each of our teams has a long-term identity and purpose within the organization that is aligned. What exacly is needed depends heavily on Business Strategy clarified by the Strategist Role.

We organize our teams around business areas or value streams, taking into account technical considerations, product or service specific knowledge, etc. A team should be aligned as directly as possible to a value stream, meaning the are responsible and able to deliver services or products from producing assets, customer onboarding to continuous support and operations with only the minimal dependencies and interfaces. We also have supporting teams, like sales, marketing, customer account management, customer support, and internal operations (like HR and Corporate IT).

This so called "long-term identity" of each Team and also Role is defined and documented using a Domain Description Format, focusing on the delegated responsiblities, formulated in a result oriented way: what someone takes responsibility for, not the steps they need to do to achieve that.

Implicit and explicit roles within each team is a further level of delegation, and helps the team to clarify responsibilities and to fulfill their purpose.

See Domains of VSHN - Organizational Structure.

6.2. Agile Goal Setting

Objectivs and Key Results (OKRs)

The Strategist VSHNeers set the company-level OKRs in collaboration with the board, affected VSHNeers and subject-matter experts. They consider higher level strategic goals, current business and market situation. Each team then proposes their own Team Level OKRs that directly or indirectly contribute to the company level and their own long-term team purpose, for the next quarter.

Through the combination of structural alignment and agile goal setting, we ensure that our teams know what to focus on and prioritize, balancing their daily operational work with strategic development.

See Tracking OKRs.

Product Roadmap

We maintain customer-centric roadmaps for each defined product or product group. The roadmap is a list of products or features that should be produced next. The Product Roadmap is maintained by the Product Owner with inputs from various stakeholders like Product Managers, Customer Account Management, Sales and the Strategist Role.

For teams that own a product or product group with a roadmap, the roadmap is usually more specific than OKRs. The OKRs are more general, higher level than the roadmap - what future state do we want to reach, while features on the roadmap but also other work of the team contributes (at least indirectly) to reaching an OKR objective. This isn’t an either-or thing, it’s not roadmap vs OKRs, whatever works as orientention and alignment to the team, is the right way. In the end, a roadmap or OKRs are just tools to give tangible goals.

See Product Roadmap.

Objectives and Roadmap in Scrum

A good practice is that the Scrum Sprint Goals contribute to either the product roadmap or the Team OKRs, besides the day-to-day business that could also sometimes be Sprint Goals (like a customer’s project). The roadmap is aligend to Team or Company Level OKRs, but focuses on customer value. Not easy to find this balance.

If this connection is not visible to team members, it’s a sign of a lack of common alignment - we are no longer working towards common, higher objectives.

6.3. And where is Strategy in this?

There is not the one static plan, not one strategy. Strategy exists on different flight levels or levels of goal setting:

Those who have a (monetary) stake in VSHN (shareholders represented through the board), need to define:

What is the long term, hard to reach future picture of what VSHN does and why we exist - what is our motivation.

What is the mission: more concretely how we want to do it, but still quite high level. For example, do we want to produce products and managed services, do we want to rent engineers or do random engineering projects, etc.

What they want with and from VSHN in which time. Can be money, innovation, growth, etc. usually a combination.

Within VSHN, we need to translete those strategic goals into more tangible objectives (usually quarterly or yearly) - some sort of S.M.A.R.T. goals - we use OKRs (see above).

We also need to think about and come up with high level plans / initiatives how all the parts of VSHN can contribute to achieving those objectives. This is very close collaboration with the teams and subject-matter-experts.

From this, teams and roles in VSHN can have their more specific OKRs for the quarter.

In the teams or roles, they can then come up with plans / initatives / projects / epics how to reach their team / role level OKRs.

And that’s it: We see strategy is in between all this goal setting: * How do we want to come closer to our company vision * How we reach the strategic goals (business model) and changes in the business model. * How we reach the company level shorter-term goals * How we reach the team / role level goals

This is the proactive part. Strategy is also needed to address to strategic risks, respond to organisational challenges, personnel strategy, internal processes or structural changes, etc.

In it simplest form, a strategy is not more than a wiki page which points to a goal we want to reach or a opportunity / issue we want to address, and a few bullet points how we plan to do what.

7. Changing Things at VSHN

This page should give you an overview of how we change things at VSHN, because we need to react to something, or we need to proactively bring about the change to move forwards towards our objectives.

7.1. Reactive

What do you do if you feel that something should be different at VSHN?

People see things that they think should be different. There are always opportunities to do new things or improve existing ones. Simply doing everything straight away will lead us into chaos, while looking away and doing nothing is likely to harm our organization or bring it to a standstill.

We need ways to capture such opportunities and respond to them appropriately and in a timely manner. In this way, those responsible can understand, decide on, and solve the problem together with the people who experience or are directly affected by it. In this way, we can do our work more effectively and in a more structured way, and achieve our goals while holding on to our values as humans.

Conflict Resolution: Navigating via Tension

At VSHN, we view conflicts or tensions not as problems, but as opportunities to uncover deeper issues. It’s entirely understandable if you feel upset or frustrated about a situation. The key is not to feel alone with the issue, but to share accountability with others who might be affected or can contribute. While this approach is particularly beneficial for issues or opportunities of the team or the wider organization, it can also be very helpful when dealing with personal ones, such as dissatisfaction with your role or tasks.

When tension arises, our first step isn’t to rush to a solution, but to pause and delve into the root cause. We seek to identify the underlying "Why", the motivation, or as we call it in S3, the Driver. Achieving a shared understanding of the driver through open discussions and active listening becomes our primary goal.

Once we accurately identify and agree upon the driver, we are then prepared to explore ways to respond. This helps keep us focused on the main issue at hand, enhancing effectiveness. Without this shared understanding, it’s all too easy to get lost in discussions and meetings, especially when many people are involved, each perceiving the problem slightly differently.

TL;DR: The actual process of finding solutions or ways to address a problem only begins after we have collectively understood and consented to the need or problem, referred to as the S3 Driver.

7.2. Proactive

How do things happen that need to happen according to our higher level strategy, objectives, or to mitigate risks and attend to opportunities?

When we know that we need to create or change something in strategy, objectives, our organizational structure or policies we summarize the Why and then find out what we need, then and how we make it happen, and make a consent decision, meaning doing it, until there is a reason not to.

7.3. Governance Approach

There is a general approach or pattern for how to do Governance. While Sociocracy 3.0 makes this very explicit why it makes sense this way, it’s also mostly common sense.

Understand the need or problem, before you start finding solutions, then find solutions, and move forward with your proposal until there is reason not to. Review it after a while if it was effective, adapt and extend as needed, or drop it away if no longer needed.

Understand what the organization needs, describe it as a Driver - To have something to always refer back to: What is needed and Why in which context?

Drop it and do nothing if it’s not an Organizational Driver, meaning that it’s at least indirectly a need of VSHN.

Explore constraints and possibilities for possible solutions to address the Driver.

Brainstorm ideas within these constraints, based on the possibilities discovered.

Write a Proposal for a solution. This can be a full solution to the Driver, a first iteration that improves things, or just a next step to find out more.

Make a Consent Decision: In the absence of Objections we proceed as proposed. Be sure to define who is responsible to do what.

Implement and do what we agree to, try to the best of our abilities.

Review the solution for effectiveness, did it address the need described in the driver as we thought? Did the need change? Start at 1. with what you learned.

This approach applies to reacting to issues, opportunities, or problems and likewise to proactively steer needed changes. The difference is often just, who leads and where the Driver comes from.

8. VSHN’s Culture - Frequently Asked Questions

This page is a collection of questions and answers around how VSHN works, our culture. Make sure to read VSHN’s Culture first, to have some context. To add a new question, you can open a Merge Request by clicking the Edit-Button in the top right, add the question at the end, and assign it to a member of Management (better process to be defined later).

8.1. Practical, Real Questions

What if I just want to do my operational work (engineering stuff for example)?

As long as your team fulfills their purpose and responsibilities, and organizational issues are addressed in a timely manner, that can be perfectly fine. The key is to have people (for instance, defined roles like a Team Facilitator) who care about the most important things. They will involve you in finding solutions and decision-making, and you will need to participate to the best of your abilities. This requires some basic understanding of how VSHN works, which isn’t optional.
Read more on Leadership and Decision Making.

We agreed to a problem, prioritized it in our team, and nothing has happened for months. What’s going on?

This is most likely an issue of lack of Leadership. Either the person responsible for driving the topic forward is blocked or struggling to do so, or isn’t taking action, or it’s unclear who is responsible and "in the lead". Bring up the issue again in the team, find out who is currently driving the topic or define it. Remember to check in at short intervals to see if progress is being made.

I don’t like a proposal to a problem that was presented to me. What can I do now?

Work together to understand why you don’t like it. It’s about identifying potential risks for the organization that we should avoid, or finding ways to improve the proposal right now. If it’s really just your personal preference, put away your ego and think in the bigger picture, commit to trying the proposal for a while. You might change your opinion. Personal preferences or opinions alone aren’t directly relevant, and they can’t block progress. Consent isn’t about making it perfect for everyone.

Management always says that they don’t decide. What does that mean?

The Management adheres to our belief that there are no bosses who decide. This means that they lead major topics at VSHN, involve people who would be affected by decisions, and make decisions based on reasoned arguments, driving things forward until we find out it’s a bad idea. This implies you can’t go to Management to request an A/B decision or ask them to sign something off. However, they can help you come to a decision, together. Often, this situation is a symptom of missing leadership in your team, where needed decisions aren’t being made and issues escalate to Management.

What if we don’t have time in our team to fix our organization?

The short answer is: make time for it. A Semi-Autonomous Team is responsible for their operational work, planning and coordinating the work, and governance (mainly, making agreements on how you work and how you organize yourself). It can work just fine if everyone does a bit of everything, but we have found that it’s generally more effective to have defined roles in the team that focus on specific topics, such as a Product Owner, Scrum Master, Facilitator, Tech Lead, etc. Especially, it’s the Facilitator’s job to help the team prioritize work and create enough slack to take care of the meta-work as well.

I see a problem that we should take care about, but where do I start?

It starts with you: Bring up the issue within the team, strive for a common understanding, and document it. If it’s urgent and impeding your work, mention it in the daily stand-up and ask for help. If it’s more related to organizational processes, it might be better discussed in a retrospective. In any case, the Team Facilitator or Scrum Master should be able to guide you on what to do next.

If anyone can lead, what if no one leads?

In short: That’s a big risk and that’s not acceptable. At this point, it’s the role of the Delegator (see Semi-Autonomous Team) to notice this and intervene. However, this does not mean that the Delegator will start leading your team, but rather that they should listen, advise, support, and enable your team to resolve this fundamental issue - your lack of leadership. The specific approach will depend on the situation.
Read more See here.

9. Your First Day

Welcome to VSHN! You are a new VSHNeer now. This section of the Handbook will give you all the information you need to get started as easily as possible.

9.1. The Office

The VSHN offices are located at Neugasse 6 & 10, in Zurich. The main entrance can be found in Neugasse 10 on the first floor. We’re located a mere 7 minutes away by foot from Zurich Hauptbahnhof (Zurich main train station).

The postal code is 8005, and the office telephone is +41 44 545 53 00.

9.2. Working remotely

You can choose where you work from and get budget to support your home office. For more details see Personal Workplace Budget and Working remotely.

9.3. Working Hours

People have different rhythms when it comes to working. Some people enjoy working really early, while others do their best work in the evening, or even at night.

The rule here is very simple: as long as your team is aware of your whereabouts, feel free to find the rhythm that works the best for you. Just remember that most teams carry their stand-up meetings every Tuesday to Friday at 11:45 AM, and if you can’t attend (not even remotely) please notify your team mates.

Also pay attention to the fact that, according to your work agreement, you should work 40 hours a week, or the percentage thereof agreed for part-time contracts. Not more.

As we’re working in a yearly-hour model you’re free to figure out how to best distribute these hours over the year. Some of us are passionate skiers, others like swimming in the lake a lot. So some of us are working a bit more in summers, others a bit more in the winters which gives the needed time for what you’re passionate about outside working. The rule of thumb: Don’t go below 75 hours of under-working and 75 hours above overworking.

9.4. Your Mentor

A senior VSHNeer will be your Mentor. They will be your primary contact for questions and must make sure that you receive all required information throughout the start of your career at VSHN and your Trial Period (usually the first 3 months).

9.5. Your Introductory Blog Post

Once you have finished setting up your workstation, one of the first assignments you will receive is to introduce yourself on our blog. We’ve both an English and a German version of it, so you can choose the language that works better for you. You might want to check out the introductions of some of your new colleagues for inspiration, and to get to know each other better.

9.6. Hardware and Software

This section contains some information about your laptop, monitors, desk, and hardware budget.

Laptop

At VSHN we work with open, cross-platforms tools. This means that technically you can choose any laptop you like to work with. Most of us use Lenovo X1 Carbon or MacBook Pro machines.

In terms of software, nearly everyone ditches the Windows installation in the laptops, and uses some Linux distribution instead, such as Ubuntu, Fedora or Arch. Some of us use GNOME, others KDE and others just i3 in our desktops.

Ubuntu has very good support for Lenovo laptops, and many VSHNeers have installed it, which means they could help you in case of trouble. There is even a page in the wiki about that!

Hardware Budget

Please refer to the Personal Hardware Budget section for details.

Software

Whichever laptop you choose, you will most probably have to install one or many of the following software packages.

A web browser, such as Firefox (a favorite among VSHNeers), Chrome, Edge, Opera, Safari, Brave, Lynx or even just plain w3m.

A chat aggregator like Rambox or Ferdium

Office tools, such as LibreOffice for non-techies.

As a techie, you will likely also need these:

Docker Desktop for Mac or Windows, or Docker Community Edition for Linux.

An IDE or text editor, such as Codium (aka Visual Studio Code), Vim, Atom, Sublime Text, or Emacs.

VirtualBox and Vagrant

Minikube

9.7. Desktop Wallpaper and Virtual Background for Zoom

Maybe you want a fancy VSHN styled desktop wallpaper and a virtual Zoom background? You can find these in our brand guide.

9.8. VSHN Central

Make yourself comfortable with VSHN Central. It’s the central place (pun intended) for all things VSHN.

10. Trial Period

According to the employment contract, the first three months at VSHN are the trial period. An extension due to illness or accident is possible.

10.1. During the Trial Period

During the trial period, the new VSHNeer is introduced to their new tasks in a targeted manner, following a written introductory program. They’re given all the information about their area of responsibility, team colleagues, organization and objectives of the Team, etc. The new VSHNeer is then introduced to their new tasks following a written introductory program. During this time, the new VSHNeer will also gain a deeper insight into the company’s philosophy and culture, history, products and services.

Periodic Review Talks

During these three months, a short review will take place every two weeks, organized by the Mentor. It’s important to find out if the employee has received all the information about VSHN, and do short assessments of the work done so far.

Information about VSHN

What does VSHN do?

What are the different Teams doing?

How to work with Jira and how to create tasks?

How to do attendance tracking in Odoo?

How to do worklogs?

When are all the regular meetings held, and what meetings are available?

Where to find the best food in town?

Where to find things in the VSHN office?

General company processes.

PeopleOps, whom to contact.

Corporate clubs (for example DnD, "beering," concerts).

Training opportunities (point out that it must be demanded by the new employee).

Organisation chart.

Organisational information/processes.

Products and services.

Safety regulations/emergency.

All these topics are collected in onboarding knowledge building checklists, which are created from wiki templates here.

Assessment of the work

How’s everything working so far?

How’s the work progress and workload checked?

Is the introductory program implemented according to plan?

Are necessary changes implemented?

Are the working results correct?

Is the job description still correct?

Are the main tasks and goals clearly defined?

Does work meet expectations?

Is further training necessary?

Does the new VSHNeer feel comfortable?

How’s the workplace and climate?

Are there any wishes, suggestions or potential for improvement?

10.2. End of the Trial Period

Two weeks before the trial period ends the Mentor plans a final meeting with the new VSHNeer and a Team member that worked closely with them. In this meeting the trial period report is written together with the new employee. The report template is attached to the new employee ticket. In this report the general satisfaction, expertise, work performance, personal behavior and team integration is assessed. Furthermore it’s discussed whether the employee actually wants to stay with VSHN or not, and if there are any target agreements to define regarding further education, work performance improvements, or similar.

It’s important that all parties prepare seriously for this interview. Not least because it’s probably one of the last opportunities to terminate the employment relationship with a shortened notice period.

Decision

The trial period report is sent to PeopleOps. Also the Team of the new employee or anyone else at VSHN can send a written recommendation to PeopleOps whether they want to keep the new employee or not and why. Remember that we should stick to the Conflict resolution process though, mainly talk with the person and the team first.

Should the outcome be that we don’t want to keep the new employee, then PeopleOps will write a recommendation based on the collected information for the next Management meeting. The Management takes the final decision, considering all available inputs.

Positive Decision

In this case everything continues as planned. If there were target agreements or future review meetings defined, PeopleOps makes sure this is controlled and done at the defined time.

The team might have a lunch, share a few beers or an apéro together with the new employee to celebrate the end of the trial period!

Negative Decision

Should the decision be negative for the employee, a meeting is scheduled to inform them, usually with PeopleOps or Management.

Should the employee want to leave VSHN during or at the end of the probation period, the Mentor, Team members or someone from Management should clarify the reasons in an informal setting.

In any case the internal off-boarding process will be triggered.

11. Disciplinary Process

Version

2023-04-10

Approved by

Management

11.1. Meta Information

Definition

The disciplinary process is a procedure in which a possible offense is examined and, if necessary, sanctioned. The legal basis in Switzerland is the Code of Obligations and the Labor Law.

Purpose

It is important to ensure personnel understand the consequences of violations to prevent and handle individuals who violate policies and actively go against VSHN values.

Reference Documents

This is also related to the Information Security Management System (ISMS) but not only concerns violations against information security policies.

This policy relates to ISO/IEC 27002:2013 control A.7.2.3 and the new version ISO 27002:2022 to control A.6.4.

11.2. Procedure

We distinguish four stages of a disciplinary procedure:

First Announcement: Employee review

Participant: Employee / People Operations / Management

People operations or Management should conduct a designated interview to identify any wrongdoing and provide an explanation of the VSHN’s expectations.

Measures are defined with the employee to prevent future wrongdoing.

The employee is shown the consequences of further wrongdoing.

Whether the offense was intentional (malicious) or unintentional (accidental) must be documented.

It must be in writing and will be placed in the personnel file.

Warning (Second Warning): "Yellow card."

Participant: Employee / People Ops / Management

Employee objectively continues to violate employment duties.

Examples:

Refusal to work: Refusing or interrupting work without a justifiable reason.

Failure to comply with information security regulations.

Actively working to undermine VSHN’s values.

People operations clearly formulate the wrongdoing in writing and substantiate it with examples.

People operations issue a warning letter and point out the consequences of further wrongdoing (for example, final warning/termination).

People operations and the employee establish an action plan to address misconduct (Performance Improvement Plan (PIP)). This includes a timetable and specifies objectives to improve the behavior.

It must be in writing and will be placed in the personnel file.

Final Warning letter (last chance warning): "red card."

Participants: Employee / People Operations / Management

Further disregard of warning by employee → Lack of willingness to improve on the part of the employee.

Suspension of the automatic wage increase (for one year)

Analog 2: Formal request to refrain from certain behavior/action and warning of next measure in case of further wrongdoing: Termination.

It must be in writing and will be placed in the personnel file.

Cancellation

Participants: Employee / People Operations / Management

Termination process

Consult legal counsel if necessary

It must be in writing and will be placed in the personnel file.

11.3. Communication of this Disciplinary Process

This process is part of the employment contract.

The process is published in the VSHN Handbook.

This policy is tracked and approved by the Management with VIP-294

12. Performance Improvement Plans (PIP)

12.1. Definition

A personal improvement plan is a structured and individualized strategy designed to help someone identify and work towards achieving their personal goals, enhancing skills, and developing in areas one wants to improve on in order to grow and reach their full potential.

A personal improvement plan (PIP) can also be used when an employee is not fulfilling their duties or performance expectations.

A PIP is often used as a performance improvement tool to allow the employee to make the necessary changes and clearly communicate any consequences if the performance does not meet the required standards.

12.2. Purpose

Personal Improvement Plan (PIP) addresses performance or conduct issues with employees in a structured and fair manner.

PIPs usually last 30, 60, or 90 days but can also be extended and adjusted.

Swiss labor laws stipulate that employees must sign a PIP letter (Performance Improvement Plan) and acknowledge receipt.

This document aims to inform the employee of any unsatisfactory job performance or conduct issues that need improvement.

The employee’s signature on the PIP document signifies that they have received and understood the feedback and expectations.

12.3. Procedure

When following the steps: If someone is behaving in a non-VSHNary way, People Operations will advise you should a PIP be the best next action.

12.4. Examples of when a PIP is considered:

A Performance Improvement Plan (PIP) is typically implemented when an employee’s performance is not meeting expectations. Here are some factors to consider when determining if a PIP is needed:

Consistency of performance: If an employee’s performance is consistently below the expected standard, it may be time to consider a PIP. This may involve reviewing their job duties, goals, and responsibilities to determine where they fall short.

Communication: If there are issues with communication, either in terms of the quality or quantity of communication, it may be time to implement a PIP. This may involve setting clear expectations for communication, improving listening skills, and ensuring timely and effective communication.

Accountability: If an employee is not taking responsibility for their work or failing to meet deadlines, a PIP may be necessary. This may involve setting clear deadlines and expectations, providing additional training or support, and holding employees accountable for their work.

Employee development: A PIP may be needed if an employee is not meeting expectations due to a lack of skills or knowledge. This may involve identifying areas for improvement, providing training and development opportunities, and setting clear goals for improvement.

A PIP should be seen as a positive opportunity to improve their performance and succeed in their role. It is important to approach the process by setting clear expectations and consequences for failing to meet those expectations.

13. Salary System

VSHN has a unique, transparent, open salary system. This doesn’t mean that we’ve got a list of names with their respective salaries, but rather that:

We strive for fairness; everybody gets the same salary for the same work.

We aim for unambiguousness: a salary depends on objective criteria and not on the negotiation skills of individuals.

We consider the training level, the experience and the responsibility required for each job.

We take care of the further development and growth of the know-how of our team members.

13.1. Salary System

The salary system is under review.

The Salary System is based on three base concepts:

A basic annual wage, which has the current "100%" value.

A work experience level value.

A gradual increase of the wage in relation to the basic annual wage, according to work experience and seniority.

Instead of bonuses, we increase the basic annual wage according to the previous year’s results. This allows all VSHNeers to benefit from the success of the business.

The Salary System applies to all VSHNeers. The actual salary numbers are different for apprenticeships and internships, but the system stays the same.

Experience Level
Percentage of Basic Annual Wage

0

67%

1

76.66%

2

82%

3

87%

4

90%

5

93%

6

95%

7

96%

8

97%

9

98%

10

99%

11

100%

12

100%

We determine the experience level of each new VSHNeer according to their current experience, eventually assigning a work experience level bonus at their entrance in VSHN.

When new VSHNeers start their employment mid-month, the mentioned annual increases for salary and holiday allowance will be effective on the 1st day of the following month.

The salary payment is divided into 12 installments, paid around the 25th of each month.

13.2. Salary Evolution

The salary evolution in VSHN follows this mathematical formula:

where is the work experience level (as explained above), and is the yearly salary in Swiss Francs.

This methodology takes into account:

That VSHNeers take on more responsibilities over time.

Steady and continuous training and learning.

Internal education, being a Mentor and educating trainees.

More routine and productivity.

Role growth, taking on higher responsibilities.

Loyalty to VSHN.

13.3. Deductions

The basic annual wage is a gross number. This means that the legally prescribed social security deductions, employee contributions to occupational pension schemes and daily sickness benefit insurances are deducted in each case.

13.4. Benefits

See Employee Benefits for all the benefits of beeing a VSHNeer.

13.5. Employment Termination

Upon employment contract termination, wage increases still apply during the legally required notice period. On the contrary, additional paid leave days due to seniority do not apply during the same period.

14. Employee Benefits

Being a VSHNeers, you profit from many benefits. We have them listed on our Website and write some details here as well.

14.1. Holidays

For each year being a VSHNeer you get one day of paid leave in addition. You start with 25 days PTO (Paid time off) per year, or the percentage thereof agreed for part-time contracts. In the second year you get 26 days, in the third year 27 days etc., up until a maximum of 35 days per year after being a VSHNeer for more than 10 years.

14.2. Work time and flexibility

We work 40 hours per week, or the percentage thereof agreed for part-time contracts.

Times and length of daily work are flexible, but mandatory rest periods must be taken. Every hour you work is written down and can be used later as free time.

14.3. Half Fare Travelcard

You get a SBB Half Fare Travelcard ("Halbtax") paid per year.

Please note that your Half Fare Travelcard is paid automatically every January.

14.4. Recurring Budget for Workplace

You get a recurring budget for your workplace. This is detailed here:

personal_hardware_budget.epub

personal_workplace_budget.epub

14.5. Education / Training

Every year you have an entitlement of 5 days and CHF 4'000.00 for your personal education. You can read more about that under personal_education.epub.

14.6. Parental Leave

Women get the 14-week maternity leave specified by law, while men get 4-weeks of paternity leave, both at 100% pay.

14.7. Phantom Stock Program

If things go well, every VSHNeer should of course benefit. We have a phantom stock program, so everyone can participate in the success of the company.

14.8. Food and drinks in the office

The office is stuffed with fruits, snacks, chocolate, Club Mate, Coke, coffee, etc. All for free.

14.9. Office massage

Monthly massages by BODYALARM directly in the VSHN office Zurich (VSHN takes over 70% of the costs).

14.10. Company and Team events

Teams get a budget per year for having Team events, and we organize company-wide events throughout the year.

14.11. Swibeco

With Swibeco you have the possibility to buy discounted vouchers for different shops, for example Digitec, Coop, Migros, Spotify, etc. They offer permanent discounts at 150 top retailers, with something for everyone: multimedia, fashion, sports, food, gas, travel, and so much more.

How to take advantage of this discount? Log in to your BVG account at AXA (because it’s a service from them), and this will take you to the Swibeco platform.

Register at myaxa.axa.ch/myaxa

Shop at vshn.swibeco.ch/

If you log in to MyAXA first you have a link on the start page that will take you to Swibeco authenticated.

You have to chose the correct access and then you got a blinking Swibeco logo on the top. Don’t ignore this blinking thing!

You will be asked to accept Swibeco’s general conditions.

14.12. Brands for employees

Attention, advertising!

"Weekly offers at unbeatable prices, exclusively for VSHNeers. At Brands for Employees you will find new and exciting offers every week from the areas of technology, household, sports and many more at the guaranteed lowest price in Switzerland."

How does it work?

Go to www.brandsforemployees.ch

Register with your email address (@vshn.ch)

Accept the activation link in the confirmation email, and benefit from the discounts!

15. Personal Hardware Budget

15.1. General

Every VSHNeer has an allowance of up to 2400 CHF when starting at VSHN with which to purchase a laptop. This is replenished by 800 CHF per year up to 4 years (3200 CHF). When you replace your laptop, the old one becomes your property (Rules: Taking over old equipment), so you can use it yourself, or give it to a spouse/child/parent/etc.

An allowance that is not fully used expires and cannot be used for other things.

If the equipment requested by the VSHNeer exceeds the available allowance, the difference will be charged to the VSHNeer.

The allowance isn’t considered part of the salary and won’t be paid out if the employment contract is terminated.

15.2. Requirements

General

Ordering and any warranty processing are carried out by VSHN, Antares.

If you would like to have a new unit and are eligible to apply, please send an email with your specific requirements (link to the configured unit or screenshot of configuration) to einkauf@vshn.ch.

Every VSHNeer needs a laptop so that on-call assignments / sales presentations / etc. can also be made with the company device.

Technical

VSHN recommends a device with the following minimum requirements:

4 Core CPU

16 GB RAM

512 GB SSD

Intel Core i5-i7 processor

Thunderbolt 3 docking capable

3 years on-site warranty

Personal Equipment

Every VSHNeer gets some personal equipment in addition to their personal laptop:

Free choice of whatever equipment you feel will help you work more effectively. This usually includes a mouse (up to CHF 100.-), keyboard (up to CHF 150.-) and headset (up to CHF 300.-).

The equipment is the property of the VSHNeer and has to be taken care of. Defective equipment will be replaced by VSHN, provisioning, and maintenance organized by Antares.

Equipment can be taken by the VSHNeer for free when leaving VSHN, regardless of how long the VSHNeer has been employed.

VSHNeers must email einkauf@vshn.ch to request the purchases. Any equipment purchased without prior approval may not be allowed to be expensed.

15.3. Recommendations

Headset

Jabra Evolve 65 MS (USB connection and Bluethoot with dongle available), approx. CHF 170.-

(Epos) Sennheiser Game Zero - Closed-Back-Headset (with passive damping of ambient noise), approx. CHF 200.-

(Epos) Sennheiser Game One - Open-Back-Headset (without attenuation of ambient noise), approx. CHF 200.-

Aftershokz OpenComm - Bone Conduction Stereo Bluetooth (Good Audio Quality, tested on Mac), approx. CHF 180.-

Reasons:

Bluetooth headsets can only use the microphone in the HSP/HFP profile, which allows only very poor audio quality. The A2DP profile with good audio quality doesn’t allow the use of the microphone.

Bluetooth headsets always have some audio latency, which affects the quality of the video conference.

Some special headsets, for example those from Jabra, use their own Bluetooth profile for better audio quality. However, these only work with special USB dongles and not with the Bluetooth chip integrated into the laptop. In addition, these usually offer sufficient audio quality for video conferences, but not for music.

The use of the microphone integrated into the laptop leads to problems with echoes (when using the speakers at the same time) and a lot of disturbing ambient noise.

15.4. Private use

The devices may be used privately within the framework of the guidelines "Richtlinie zum zulässigen Gebrauch."

15.5. Insurances

Theft: Burglary, theft from vehicles and trailers, and robbery are insured by VSHN. Loss or misplacement or simple theft aren’t insured.

Damage: Fire/elementary and water hazards are insured by VSHN.

Other: Any other risks are the responsibility of the employee.

15.6. Taking over old equipment

The employee may take over old/replaced equipment. The following rules apply:

The device is at least 36 months old.

Younger equipment may be purchased by the employee when changing equipment or at the end of the employment relationship. The purchase price must be determined according to the inventory residual value.

All company data must be deleted before the acquisition or the device must be registered as BYOD under the Acceptable Use Policy (AUP).

16. Personal Workplace Budget

16.1. Joy of choice

When a new VSHNeer starts, they decide after the trial period whether they want to have a fixed Office Workplace or a Remote Workplace. If you prefer to work primarily in the office, you get a fixed workplace with the VSHN standard equipment. If you choose to primarily work remotely, you get financial support to improve your workplace at home. It is possible to switch between the two models, but there is a waiting period of at least one year (budget and accounting reasons). People operations decides about exceptions.

Office Workplace

If you choose to have a fixed desk in the office:

You get a fixed workplace (desk and chair), 1 big or 2 smaller screens and a docking station (Lenovo USB-C/Thunderbolt Dock).

The furniture and equipment is property of VSHN, remains in the office and has to be taken care of. Defective equipment will be replaced by VSHN, provisioning, and maintenance organized by Antares.

Remote Workplace

You don’t have a fixed desk in the office.

VSHN ensures that there are enough floating desks you can choose to work from when you’re in the office. See desk sharing.

After the trial period (and for all current VSHNeers), you can claim up to CHF 400.- per year in the form of expenses for furniture or equipment that will help you to work better remotely.

If you don’t make use of this, the budget adds up to a maximum of CHF 1200.-, in the years you have no fixed desk.

You can use the accumulated budget to expense one or more bills.

You can’t expense bills using future budget, as this is extra effort in accounting and the money would have to be paid back, if a VSHNeers should leave us earlier.

Antares takes the final decision about budget per item (is it within the range of usual costs?) and communicates it to the interested parties.

Stuff bought with the financial support of VSHN remains the property of the VSHNeer, which also means that maintenance, repairs, replacements, etc. are the responsibility of the VSHNeer.

The budget isn’t considered a salary component and isn’t paid out in the event of termination of the employment contract.

The VSHNeer is responsible for purchasing remote workplace equipment and then expenses it.

16.2. How to get the budget

Write an E-Mail to PeopleOps (If you are employed by VSHN Canada, please CC VSHN Canada) with the following information:

What you want to purchase.

Required budget (money).

PeopleOps will confirm the approval and will consider the budget and applicability.

PeopleOps takes a final decision (go / no go) and communicates it to the interested parties.

If the decision is positive, you can expense the costs and enjoy the new Workplace item!

17. Semi-Autonomous Teams

Teams have the freedom and responsibility to do what’s needed to create value and to decide how.

Each team is allocated a specific area of VSHN, providing them with a domain of influence, work, and decision-making. This freedom to decide and do things how they think works best also comes with the responsibility to do so effectively, contributing to the overall purpose and objectives of VSHN (see Alignment). Therefore, such a team is semi-autonomous. An important factor is that the potential workload usually exceeds the team’s capacity, making prioritization essential - time is made by selecting the right tasks. Balancing work from different sources and finding the equilibrium between operational work and improving team organization and working methods is crucial. It’s never just one thing or the other; it’s usually both and more, and breaking down larger efforts into manageable pieces for iterative work is a common approach. Teams often have dedicated roles such as Product Owners, Facilitators, or Scrum Masters to help in finding this balance and fostering continuous improvement.

Those who delegate a domain to the team retain overall accountability, which means if the team encounters issues they can’t address on their own, or if they fail to recognize them, the delegator may need to provide support, empower the team, or even object to current activities. The delegator must continuously maintain a high-level understanding of whether the team is functioning and delivering as expected and required.

17.1. What is a Team?

A team is a group of individuals united by a shared purpose and common goals, actively collaborating to achieve these objectives. Unlike a mere grouping of individuals each working independently, a team leverages collaboration and synergy, enhancing overall productivity and effectiveness.

In our organization, a Team exists when the Delegator defines - usually in a close collaborative effort with the people who form the team - the Domain and then delegates it to a group of people. Through this act of Delegation, they become a Team. This isn’t a one-time action; as the Delegator remains overall accountable for the outcomes of the Team, they need to periodically review how things are going, make changes, and enable the Team. This process continues as long as the Team exists.

17.2. VSHN Teams

Most VSHN members belong to a fixed Team, typically based on their Main Role. These teams are named after navigation stars (list 1, list 2), as decided in our internal forum discussion.

See Teams at VSHN for an overview of all Teams and VSHNeers.

Other Forms of Teams

Apart from fixed teams, VSHN consists of other circles with different objectives and structures:

Work Groups - Comprising fixed members, governance representatives, and flexible members assisting with operational work.

The Management - A group of representatives accountable for Business Operations.

The Board of VSHN - A group of representatives responsible for the overall Domain of VSHN.

17.3. Fundamental Responsibilities

Each Semi-Autonomous team at VSHN shares a set of fundamental responsibilities in addition to their unique key responsibilities that come with their specific team purpose. Agreeing on how you ensure these responsibilities in the team is Governance while doing the ongoing administrative, coordination and other actual work to ensure them is Operations. Addressing these responsibilities good enough ensures a functional team.

Prioritization and Planning: Plan your work according to the different inputs for prioritization and a have way to handle unplannable work. See also Balancing and Prioritization.

Capacity Management: Teams manage scheduling of FTE, shifts and vacations to ensure optimal capacity to be able to deliver their planned and unplanned work.

Transparency: Ensure documentation and flow of information. We make our work, progress and results visible and inform affected people proactively.

Review results: We work to achieve outcomes, that are effective to deliver value to our stakeholders. The Team has a way to get stakeholder (customer) feedback on what provides how much value and what needs to change or come next (for example sprint reviews with customer representation).

Coordination and Communication: Manage working interfaces on the dependencies to the rest of the organization and customers, and ensure effective communication so that cross-team and customer collaboration works.

Objective Setting and Alignment: Teams define their own OKRs and get consent by Delegator, monitor their progress, and adjust as needed to align with VSHN’s overall goals. Some teams further maintain a roadmap of their product, that aligns with actual customer need and the product vision. See Company Alignment.

Clarify Responsibilities: Ensure that team internal responsibilities are clear, meaning that what needs to be taken care of (for example these Fundamental Responsibilities) are taken care of continuously, often by defining roles within the team.

Delegator Dialog: Teams maintain an ongoing dialogue with their Delegator, reviewing their domain periodically to align expectations, constraints and results based on team purpose and objectives.

People Topics: Teams address personal issues internally or in collaboration with central People Operations.

Talent and Skill Management: Teams identify skill gaps, ensure needed training and education, and promote continuous learning to maintain proficiency.

Continuous Improvement: Teams conduct retros on how they account for their domain and these fundamental responsibilities, and implement improvements in their processes and ways of working, to become more efficient and effective in delivering on their purpose.

This is a list of the most important responsibilities, there might be more. We see this as the minium that needs to happen in all teams, how and to what extend depends on the purpose, size and other factors of the team. The Delegator must not accept that one of these responsibilities isn’t addressed good enough, see The big risk with Leadership in every chair.

Balancing and Prioritization

Fortunately, we always have more work than we can do in the time we have. This gives us the opportunity to decide what we should do first, what is most effective - Making time for what is needed now and most effective.

At VSHN, and more importantly in every team, we have to prioritize what we spend our time on. We see it as an anti-pattern if individuals simply decide for themselves what to work on, or simply do what they like. As a team, all members share the overall accountability to contribute to VSHN as by the responsibilities delegated to them. This means, you as a team have to figure out, what is most important and most urgent, and do that first. That being said, we try to create some slack in the system to have room to play with cool things and learn. This not only applies to actual tasks, every team has to balance between Governance and Operations, for to deliver on their purpose, but also to ensure the Fundamental Responsibilities are covered.

The Team decides on priorities, based on reasoned arguments. There might be roles that lead and guide this, like a Product Owner, Scrum Master, or a Team Facilitator.

Inputs to Prioritization

See Alignment, these are the main inputs for you to decide on priorities.

Your team’s domain defines the long-term purpose, you’ve to deliver on that. That basically frames your overall work, what you do, your customers, and gives you general enabling or limiting constraints.

In Product-based teams, the roadmap gives you priority on what’s the next feature, etc.

Your Team Level OKRs create focus, motivation, help to track progress, and help you to prioritize. Doing OKRs itself isn’t the work though, it’s about how what you do, or should do, helps you to reach your objective.

There is no either we do OKRs, Roadmap or our other work. It’s about finding the balance! While it’s an option to shift focus over time, it’s never 100% this or that.

17.4. Creating or Changing a Team

It’s important to note that a team doesn’t simply exist because people group together. There needs to be a common purpose. If they have this shared purpose, they are already a team, even without a documented domain description. See What is a Team. However, documenting the delegation agreement makes it explicit, creates clarity and shared understanding, and enables us to evaluate and evolve a domain by reviewing its effectiveness.

So, creating a Team means Creating and Delegating a Domain. Changing a Team means Reviewing the Domain of a Team. Both are collaborative efforts, a dialogue between the Delegator and the Delegatees (the existing or to-be-created group of people).

A team is considered functional by the organization if they deliver on their purpose and have all Fundamental Responsibilities addressed well enough.

People Changing Teams

It’s always possible for people to move from one team to another, fully (100% of the workload) or part-time, long-term or temporarily. This is a change for both teams; it’s essentially a Tension based review of both teams, an agreement by both teams and consent from the Delegator. It’s usually driven by the person who wants to switch teams, often guided or supported by the Delegator of both Teams.

18. Fundamental Business Principles

We have our Vision, and our Key Drivers, the reason why we exist, what we do and why. Still, for every business there are higher level drivers, which also apply to VSHN.

Most VSHNeers are engineers and do not have a business background. We show some business fundamentals here (inspired by The Personal MBA book) to create an understanding of topics that need to be taken care of in any business, not only in VSHN, and without which a business cannot function.

We create value.

We attract customers.

We complete sales.

We deliver value.

We bring in enough money.

19. Interest Groups

An Interest Group deals with topics that are mostly cross-team and may overlap with other Domains, such as documentation standards, specific technologies, etc.

Interest Groups are usually made up of volunteer members and can, but don’t have to have a fixed leadership. Anyone can start an Interest Group and start finding members.

When Interest Groups need governance decisions that affect people who aren’t represented in the group, they involve everyone affected in Proposal Forming and Consent Decision Making.

The list of the current Interest Groups is in the wiki, where they have their own space each. They have their own task lists and meeting schedule and notes, etc. Feel free to join one or more of them if you feel like you could contribute to the discussions.

Interest groups are less formal than work groups, involvement in an interest group is voluntary.

19.1. Structure

An Interest Group

consists of a bunch of VSHNeers from different teams who are interested in a topic and want to take care of it.

meets regularly or on demand to talk about the topics in question.

is long-living (that means Interest Groups aren’t suitable for short-lived topics).

is self-organized.

19.2. Constraints

An Interest Group

includes any affected VSHNeer in decisions.

has the authority and accounts for a domain of VSHN only when delegated by the containing domain. See below.

has and maintains a transparent Operations backlog, usually Jira tasks, task lists in wiki or similar.

has and maintains a transparent Governance backlog, usually the VSHN Improvement Proposals or lists and notes in wiki.

refines tasks or organizational drivers that fall within their scope of responsibility.

19.3. How to create an Interest Group

Strictly speaking, as soon as two or more people agree to tackle a long-term internal issue in VSHN, an Interest Group is born. The checklist below provides some guidelines on how to bring it to reality.

Create a wiki space and name it appropriately, see the documentation guidelines.

Create a channel in rocketchat with #<interest group name>

Link the wiki space in the List of Interest Groups.

Announce the existence of the new Interest Group in the #general channel and in the next company meeting.

With the VSHNeers interested:

Clearly define the mission and write it down on the wiki page.

Optional: Get more autonomy for your Interest Group

If useful you can request delegation of accountability by the domain that contains your topic. Be aware that this has implications, for example that only you will be accountable for the domain from now on.

19.4. How to Abandon an Interest Group

When there is no more interest in a Interest Group, or its purpose has been fulfilled, we can abandon it following these steps.

Make sure you’re no longer accountable for a domain (your topic) otherwise request to give accountability back to the domain that contains your topic (see above).

Announce the situation to the people that could be affect in the chat. If there are no objections:

Archive the corresponding wiki space.

Document the reason for the abandonment on the List of Interest Groups.

Remove the Interest Group from the Jira, for example tasks, VIPs, etc.

20. Working remotely

VSHNeers are free to choose to work remotely or at the office.

Working remotely is part of the work culture at VSHN. This page collects all you need to know about working remotely as a VSHNeer. Especially during COVID-19 we found out that even with everyone being remote everything works out very well.

20.1. Rules

Some rules for working remotely:

Keep your SOGo calendar up to date.

Let others know in the #virtual-presence chat channel when you start and end your work day.

Also let them know if you are taking a longer break (for example 30 minutes) outside of the common lunch time (most people do it usually between 12 PM and 13 PM). If you are on interrupt handling duty, follow their specific availability rules.

Have Zoom and Chat open regularly.

20.2. Socializing

In times when we don’t meet each other regularly, here are some ideas to stay in social contact:

Tell others where you’re currently located if you change your work location from time to time.

Meet regularly in Zoom for a "coffee break."

Post funny stuff in the #off-topic channel.

20.3. Tips and Tricks

Get yourself a comfortable working space

It should be comfortable and follow your preferences; you’ll spend the most of your time there.

Work out your routine and stick to it

Figure out your daily routine for getting work done, and bring yourself up into work-mood.
Develop your "starting day" routine. Some people like to do the same things they do when going to office, like shaving, applying make-up, or wearing normal office clothes.
Schedule small breaks to drink coffee/tea or to look outside your window. That will be good for your mental and physical health.
Don’t forget to exercise. This could be as minimal as go for a walk outside.
Also develop an "ending day" routine. Create a set of actions that signals the end of the workday and stay out of the computer, at least for some time.

Stay productive when working remote

Avoid distractions like TV or other devices that can remove your focus.
Don’t do normal domestic work, like laundry, cleaning, etc.
Set rules with the people that live with you during work-hours (family, kids, friends), like not entering the room and not doing any distracting noises.
During meetings, close room door and reduce the possible noise from pet animals. Also, use mute when not talking.

Working abroad (out of Switzerland)

Set your computer to the same timezone as Switzerland (VSHN Main Office.)

In VSHN, we allow employees to extend their hybrid working environment to occasionally work abroad while remaining a resident in Switzerland. However, the following guidelines must be considered when doing so:

If the employee works from another country for an extended period (more than one month, with a maximum of 3 months per year), their residency status and tax and social security obligations may be affected. Employees must personally comply with the relevant regulations or may be subject to fines, penalties, or other legal consequences.

Confidentiality and data protection: Ensuring the employee has appropriate safeguards to protect the information and comply with applicable regulations is essential.

These employees must check with their team regarding what customers they work with who have terms not allowing their data to leave Switzerland in the SLA agreements.

Please note:

The above regulations make no difference whether you spend one - three months in one country at one time or of this time spread over the whole calendar year.

Working in our Canada office does not apply to the above and is dealt with separately by People Operations.

Request for help

Feel comfortable to request for help. Don’t spend too much time trying to figure out something that can be done with the help of others.

Know when to stop working

Usually time flies working remotely, and when you look to the clock you have done more that expected. Set a time when to "stop working." Count all hours and be strict with them.

20.4. Links

Many others have written about best practices about remote working; here are some links to interesting articles:

Top Tips for Working From Home (dev.to)

New to Working from Home? Here Are Some Tips to Help You Meet Like a Pro (blog.zoom.us)

(German) Homeoffice in Zeiten des Coronavirus: Tipps und Tools (eine laufend ergänzte Liste) (konradweber.ch)

20 Tips for Working From Home (pcmag.com)

21. Working at the office

VSHNeers are free to choose to work remotely or in the office.

21.1. Office / Floor Plan

You can find an up-to-date office plan in our Wiki. This plan also shows you which desks are assigned to which VSHNeer and which desks are available as shared desks.

21.2. Security Information

Our main doors are self-closing. You can only enter them by using your key, so don’t forget to carry the key with you.

If you use the goods lift in Neugasse 6 you need to grab the special key to go to the second floor.

Visitors have to fill in a visitor form (also for a quick visit and also if you knew them) due to ISO 27001 certification. These forms can be found at the main entrance in Neugasse 10.

21.3. Different offices

We’ve three different offices in Neugasse 6 & 10.

"VSHN Office" (Neugasse 10, 1st floor): The main entrance is located here, also one meeting room, the kitchen and the coffee room.

"VSHNtower" (Neugasse 6, 8th floor): See Meeting Rooms - VSHNtower

21.4. Dedicated desks

Everyone who commits to be in the office at least two days per week can claim a fixed desk at the VSHN offices in Zurich. You’re free to change temporarily to any other free desk if it helps you to focus, work together or just for a change of scenery. When doing so, please adhere to the Desk sharing rules.

21.5. Desk sharing

In addition to desks dedicated to VSHNeers we’ve spare workplaces in most offices, they usually also consists of one big or 2 smaller screens, a docking station with charging power, electrical outlets, adjustable chair and desk, etc.

Besides the dedicated desks, we don’t schedule who sits at which desk, it’s a first-come, first-served approach. Still we’ve some rules when using spare or foreign desks:

Shared desks are labeled. Please only use a shared desk and not anyone else’s fixed desk.

Keep the desk clean, especially when you don’t plan to sit there the next day

Don’t change the infrastructure. If you do change the infrastructure, please return it to how it should be: both monitors plugged, power and network cable plugged into the dock and the dock Thunderbolt cable ready for the next user.

Every VSHNeer has one or more boxes to store personal belongings, take the box(es) with you or store them in a shelf.

21.6. Including remote VSHNeers

With everything we do in our daily work we should follow a documentation-first and remote-first approach. This means that we don’t discuss and decide about work related things face-to-face during conversations in the office. Especially when only part of the team, stakeholders or interested people are around. Instead we:

Move discussions about work-related topics into our discussion forum.

Prepare suggestions in the wiki, as a merge request or as tickets comments and request feedback in the chat, team meetings, stand-ups, etc.

When talking and deciding about next steps, solutions, etc. in a ticket, document the decision and next steps in the ticket

Prefer written chat conversations over conversations in the office

You should still talk with each other in the office, socialize and have fun. We’ve spontaneous verbal conversations about work, this is only natural, just keep in mind to document decisions and request feedback before you just do something after a conversions.

21.7. Meetings

We plan and schedule meetings, workshops, retros, etc. - basically everything that involves discussions - as video calls so everyone can join from anywhere. We always try to prefer digital collaboration tooling over things like flipchart, whiteboard, etc. so that everyone has the same experience and context.

Exceptions

All invited people agreed in advance to be at the office, then a meeting can be held in a physical meeting room, using any tools available there.

Customer and partner meetings, where we focus on what works best for the other party.

22. The Office Life

Unlike most offices, we help each other in a collaborative way performing many tasks.

22.1. Common Tasks

We don’t have a specific person for small cleaning tasks, so here is a list of thing which need to be done when necessary:

You are welcome to fill, start and empty the dishwasher. Thanks to everyone who does!

Please help emptying the trash bins. There are containers next to the main entrance (door on the left side next to the entrance).

Clean the tables after lunch.

We recycle cardboard in the printer room on the first floor; please fold it to make it smaller!

Use the vacuum cleaner whenever needed.

22.2. Cleaning

Every Friday evening our Zurich office is professionally cleaned. The cleaning team doesn’t move anything and only cleans free areas.

To make it easier please clean up your (own) space:

Your desk.

Floor around your work station (no shoes, no bags, no skateboard, no skis, not "whatever-comes to-you-mind").

Windowsill.

Tables in the common room.

Coffee machine & surroundings.

Table in the meeting room.

Your trash bin must be accessible.

Store your stuff in your box, your corpus, or better: if not needed any more, the trash bin will be happy to help!

22.3. Snack Engineering

We do regularly orders at LeShop.ch for drinks and snacks. If you would like something special we’re glad to order it for you if possible.

Unfortunately the fridge doesn’t fill up by itself, so please be aware that if you take the last drink out of it and fill it up. Snacks and drinks are stored in the printer room.

22.4. Microwave

Feel free to use the microwave oven, but don’t forget to clean after you do.

22.5. Hot beverages

Same thing for the coffee machine and the water heater: feel free to use it, but don’t forget to clean after you do.

22.6. Coffee machine - the real one

We’ve an exceptionally great barista coffee machine in the entrance room. To keep the experience great, please follow these simple rules:

Always check water and refill if needed (it’s not connected to a tube)

Clean everything everytime you’ve used the coffemachine with the washcloth (make it wet when it’s dry)

When using the machine to create milk froth, thoroughly clean the steam tube after finishing

Scour the milk-pot everytime after using with water, don’t let it lay around with milk rests and don’t put it in the dishwasher

Don’t fiddle around with the grinder if you don’t know what you’re doing!

22.7. Expenses

The expense regulations should have been handed over to you with the employment contract. If not, they’re also available in the wiki. Expenses will be paid out against presentation of the receipt with the next monthly wage (for example, your expenses last month will be paid, together with your salary, this month).

How to record them is explained, as usual, in the wiki.

22.8. Technical Orders

If you need to order devices or materials at Alltron, Digitec, or other providers, use the "Purchase" form (VSHN Cloud / VSHN / 09 Templates / Purchase) and send it to the Antares team. Private goodies can be purchased at Alltron at cost.

22.9. Medical supplies

There is a first-aid kit in the printer room, bundled with the necessary implements against pain, allergies, and other ailments.

22.10. Printer Room

This is an important room, as it houses our printers, the shredder, the pharmacy, the drinks and snack store, the office supplies, tools, cleaning materials, etc…​

To make a long story short: we store everything there.

22.11. Lunch

Our office is very well located for choosing different kinds of lunch. You will find Chinese, Indian, Thai, Döner, Italian…​ food just around the corner. During summertime we often have barbecue on the rooftop! Feel free to join. If you want to bring your own food from home, cutlery is available in the kitchen and in the common room.

Bring any empty bottles to the printer room.

22.12. The Light

In the gangway at Neugasse 10.

Current situation

The light is off by default. There are a few lights which are on all the time, this is due security reason. If you use the light button in the gangway it gives you 2 minutes of light.

Change light situation

If the interval of the light needs to be changes you can adjust this in the "electro room", located right outside Neugasse 10 (next to the elevator). The key in the key locker. There is a timer and the related manual can be found in the document storage next to it.

Replacement of broken lights

This is normally done by the cleaning company. If this isn’t the case, inform Antares, so that they can contact the landlord. Check if they can do a replacement with LED instead of Halogen lights to save energy.

22.13. The Plants

There are a few plants in our office.

Here you can find a small how to fulfill the "watering the plants" when it becomes your duty.

Watering

Plants obviously need water, which means we have to water our plants, regularly.

But no worries, most plants die because of over-watering, so better watering once less instead once too often.

Standalone plants in VSHNtower

Watering can is located in the wall cabinet on the left side.

once a week

use tap water

use approx 2 cans of water for the plants standing around (in total, not for every plant)

Wall plants in VSHNtower

Watering once a week

Normal tap water

It’s a hydro system, means there is a watering display in every pot

Fill in water on the side (there is an extra watering hole on the top edge of every pot) until the red water display is up to max

Standalone plants in Neugasse 10

there are a few plants

those are not the biggest light lovers, so don’t move them into direct sunlight (when they look bad, it’s the water, not the sun).

watering once a week

use tap water

you can ignore the big tree as this one is obviously dead

Sunlight

Water is one thing, but more than this plant need sunlight.

Therefore:

Don’t close the shutters to very dark, make sure that some light is coming through

If possible leave don’t close the door next to the elevator (on the right side)

don’t move the plants around randomly

most of the plants (except the dead tree) are placed at their location by purpose

Cuttings

If everything works well, plants will grow, so we are able to make baby plants out of the office plants. If you’re interested in having one, let me know, I’m happy to help.

SOS plants

Yes you can bring your nearly dying plant to the office and let me check if I can help. But if you do so, place it in the former common room in Neugasse 10. This to avoid the spread of potential pests to the resident plants.

Plants are no food

It might be obvious but just to say. Do not eat the plants and also avoid your kids/pets to do so. Most of the plants are toxic for small pets and toddlers. In some cases even the pouring water can have a bad impact.

23. Anti-Harassment Policy

Our company recognizes that bullying and sexual harassment in the workplace will not be tolerated. We are aware that such behavior can negatively impact the work environment and stress our employees. Therefore, we have committed to creating a safe and respectful work environment. Our rules are in compliance with Swiss law, and we are legally obligated as an employer to protect our employees. We believe it is important for all employees to be informed about these rules and to comply with them in order to create a safe and respectful work environment.

Bullying (Mobbing)

Bullying is any behavior that is intended or actually causes an employee to be harassed, threatened, or humiliated. This includes the use of violence or threats, as well as teasing, insulting or discriminating.

Sexual Harassment

Sexual Harassment is any unwanted behavior of a sexual nature. This includes, among other things, unwanted touching, flirting, harassment, sexual remarks or innuendos, and unwanted sexual advances. Especially when it is unwanted and/or the person feels uncomfortable, and it occurs repeatedly.

If an employee is affected or has witnessed an incident, they are required to report it immediately to our People Operations. All reports of harassment will be kept confidential within People Operations. No details will be shared, not even with management, unless necessary for the investigation of the incident and consent by the affected employee. The incident will be investigated with the consent of the affected person. Confirmed incidents can lead to the perpetrator’s work contract termination and possibly other legal measures.

These rules are tracked and reviewed as VIP-285

24. Work Hours

24.1. Weekly Work Hours

We work 40 hours per week, or the percentage thereof agreed for part-time contracts.

24.2. Regular working schedule

VSHN offers flexible work arrangements that don’t lock employees into set workdays when working on a percentage. They agree on their schedules with their teams. To ensure transparency, open communication and collaboration, we have a wiki page where regular Work Schedules are noted. The entries are not rigid and should be updated for long-term changes. We trust and respect all VSHNeers (our employees), fostering a supportive work culture. Keeping calendars updated for short-term changes is also essential.

24.3. Office Hours

The following work hours apply for specific duties, Monday to Friday:

09:00 - 18:00 Responsible Ops

08:00 - 18:00 Main phone duty, conducted by our partner Tip Tel

If you are not assigned to one of these roles you don’t have to work during a specific time.

Usually, we have lunch between 12:00 to 13:00, but it’s up to you when you want to take your lunch break.

See Support Availability for what office hours are communicated to our customers.

24.4. Outside Office Hours

Work outside office hours is compensated with a 1.5x time credit. This applies only for work upon request by VSHN or a customer.

We define outside office hours as follows:

Between 20:00 and 08:00 local time

All weekends

All full-day public holidays (see below)

24.5. Public Holidays

Our calculation of public holidays follows the local rules and customs. In countries with a lower number of holidays compared to Switzerland, we grant additional ones as perks.

Holiday
Date
Switzerland
Canada

New Year’s Day

January 1st

statutory

statutory

Berchtoldstag

January 2nd

perk

n/a

Family Day

n/a

statutory

Good Friday / Karfreitag

statutory

statutory

Easter Monday

statutory

n/a

Sechseläuten

perk, half day (does not count as outside office work)

n/a

International Workers' Day

statutory

n/a

Ascension of Jesus / Auffahrt

statutory

n/a

Victoria Day

n/a

statutory

Penecost Monday / Pfingsten

statutory

n/a

Canada Day

July 1st

n/a

statutory

Swiss National Day

August 1st

statutory

n/a

B.C. Day

n/a

statutory

Labour Day

n/a

statutory

Knabenschiessen

perk, half day (does not count as outside office work)

n/a

National Day for Truth and Reconciliation

n/a

statutory

Thanksgiving

n/a

statutory

Remembrance Day

November 1st

n/a

statutory

Christmas

December 25th

statutory

statutory

Saint Stephen’s Day / Boxing Day / Stephanstag

December 26th

statutory

n/a

These holidays affect the office opening times in their respective country.

Employees have the holidays deducted from their annual work time depending on the entity they signed the work contract with. For example, Swiss VSHNeers working temporarily in Canada have their yearly work hours not adjusted for Canadian holidays.

24.6. Contractors abroad & EOR

The goal is for all VSHNeers, directly employed, contractors and EOR employees to have the same total annual working hours. In countries with a lower amount of holidays compared to Switzerland, we add the difference as perks. In countries with more statutory holidays, we ensure that the employee has these days off and the days will be subtracted from their annual working hours.

25. Internal Communication Principles

Check out our Customer Communication Guidelines.

The following principles are at the core of how we work and communicate with one another.

I am responsible

I take responsibility for the task at hand.

I am okay. You are okay

I know my counterpart.

I make sure there are no misunderstandings

I understand the request and formulate my concerns clearly.

I think inside and outside of the box

I challenge the request and point out alternative solutions.

I treat my counterpart the way I want to be treated

I keep people updated and answer promptly to their concerns.

I work transparently, comprehensibly and team-oriented

I document all steps that have been taken and are necessary for further work.

I choose an adequate communication channel

I look for personal communication if it becomes technical or emotionally difficult, or when the task at hand is unclear.

Talking is silver, listening is gold

Sometimes it’s better not to communicate.

On Your Desk

Each VSHNeer has these principles on their desk:

26. Communication Channels

VSHN has well-defined communication channels. This page explains the rules and the expected reaction times for each one of them. Some channels are good for short- and some for long-lived discussions; some are mandatory for all VSHNeers to participate in.

Regarding confidentiality, please refer to the ISMS - Richtlinie zur Klassifizierung von Informationen wiki page, which is the source of truth on what information we’re allowed to distribute over which channel.

In case of an emergency, have a look at Emergency Communication Channels.

Please don’t introduce new communication channels without a decision in the accountable Team or Work Group.

26.1. TL;DR

Type
Channels

Written Channels

VSHN Chat

VSHN Announcements Channel

VSHN Discussion Forum

Ticket

VSHN E-Mail

Threema

Wiki Page Comments / Git Merge Request Comments

APPUiO Community Chat

VSHN Status Page

APPUiO Status Page

Customer specific chat (for example Slack)

In-Person Channels

Talk

Phone calls

Internal Education

Meetings

Audio / Video Conference

26.2. Written Channels

VSHN Chat

Please check the "Chat Channels" page for more information about the names of important communication channels we use every day.

Functionality

Direct messages to VSHNeers and partners (when invited)

Channel messages for VSHN internal and with partners.

Information Lifetime

Less than 8 hours

Bad search experience.

No guaranteed history availability.

Used for

Daily written internal communication.

Efficient communication with partners when ticket is too inefficient.

Information Classification Level

Internal

Expected response time of VSHNeers

Direct messages or mentions: ~4h during logged attendance time.

Channel messages: best effort.

Customer contacting VSHN: best-effort, no guaranteed answer (if urgent customer uses phone or ticket)

Mandatory for VSHNeers

Yes, during logged attendance time.

Be online.

Or offline but check every few hours.

Please make yourself familiar with the No Hello rule: "Please Don’t Say Just Hello In Chat."

VSHN Announcements Channel

Functionality

VSHN wide announcements important to know for every VSHNeer in the #announcements channel.

Moderated - Not everyone can post messages. No discussions allowed.

Channel in VSHN Chat #announcements.

Information Lifetime

Up to a year

Searchable.

Used for

Announcements which are mandatory to be read by every VSHNeer.

Catch-up after Holidays or longer absences.

Information Classification Level

Internal

Expected response time of VSHNeers

No response expected, it’s a one-way communication.

Mandatory for VSHNeers

Yes, during logged attendance time.

VSHN Discussion Forum

Functionality

Long-lasting discussions

Information Lifetime

Up to a year

Searchable.

Used for

Discussions lasting longer than just a few hours.

Decision making process.

Information Classification Level

Internal

Expected response time of VSHNeers

Only response expected from people participating in a discussion.

Mandatory for VSHNeers

No.

Ticket

Functionality

Mention VSHNeers in comments.

Comments can be sent to customers.

Customer E-Mail replies added as comments.

Information Lifetime

The scope of the ticket

Searchable.

History with timeline.

Used for

Discussion about a specific task.

Customer orders and changes.

Incidents.

Information Classification Level

Internal

Expected response time of VSHNeers

VSHN internal: ~4h.

Triage: 15m.

Assigned tickets depending on priority: 1-4h.

Mandatory for VSHNeers

Yes, during logged attendance time.

React on notifications, check every few hours.

Keep your tickets updated.

VSHN E-Mail

Functionality

Encrypted or unencrypted.

Internal or External communication.

Information Lifetime

A few days to a week

For personal use only.

Searchable.

Used for

Customer and Partner communication which doesn’t fit into tickets.

Sales, High Level Project Management.

VSHN wide announcements.

Information Classification Level (Unencrypted)

Public, Entitled

Information Classification Level (PGP encrypted)

Confidential

Expected response time of VSHNeers

Next business- or working day, use vacation responder when away.

Can depend on role (for example Sales or Project Managers have other rules here)

Mandatory for VSHNeers

Yes, during logged attendance time.

Watch for new mails every few hours.

Threema

Functionality

Direct messages to VSHNeers.

Private use.

VSHN channels.

Information Lifetime

Less than 8 hours

Bad search experience.

No guaranteed history availability.

Used for

Getting help (best-effort) out of office hours.

Dedicated emergency channel should our VSHN Chat be unavailable.

Private communication between VSHNeers.

Information Classification Level

Internal

Expected response time of VSHNeers

Best-effort.

Mandatory for VSHNeers

Yes, during logged attendance time or when on-call (VSHN Tech channel only).

Available Groups

VSHN: Chit-chat channel for all VSHNeers (can be muted). Admin: Aarno Aukia

VSHN Tech: Emergency tech channel. Admin: Tobias Brunner

Threema IDs should be scanned by every VSHNeer from every VSHNeer.

Wiki Page Comments / Git Merge Request Comments

Functionality

Collaboration on documentation or code, also with partners.

Discussions in comments.

Information Lifetime

Less than a year

Can be deleted over time.

Used for

Long-living discussions on a specific topic (for example RFC on a process or design draft, or on code)

Information Classification Level

Internal

Expected response time of VSHNeers

Best-effort.

Mandatory for VSHNeers

Yes, be able to search, view and edit documentation / code.

APPUiO Community Chat

Functionality

APPUiO customer support best-effort.

Direct or channel chats with Puzzle.

Information Lifetime

Less than 8 hours

Not really searchable.

No guaranteed history availability.

Used for

Free best-effort APPUiO customer support (better use tickets)

Written efficient communication with Puzzle.

Information Classification Level

Public

Expected response time of VSHNeers

Best-effort.

Mandatory for VSHNeers

No.

VSHN Status Page

Functionality

Inform all subscribers.

Show status for components.

Information Lifetime

Up to a month

No guaranteed history availability.

Used for

Announcing planned work, maintenance window and planned or unplanned service interrupts.

Information Classification Level

Public

Expected response time of VSHNeers

-

Mandatory for VSHNeers

No.

APPUiO Status Page

Functionality

Inform all subscribers.

Show status for components.

Information Lifetime

Up to a month

No guaranteed history availability.

Used for

Announcing planned work, maintenance window and planned or unplanned service interrupts.

Information Classification Level

Public

Expected response time of VSHNeers

-

Mandatory for VSHNeers

No.

Customer specific chat (for example Slack)

Functionality

Allows efficient communication with the partner (customer)

Customer can have a lot of users there where we might only need few users to join.

Besides that, similar to our chat.

Information Lifetime

Less than 8 hours

Not really searchable.

No guaranteed history availability.

Used for

Efficient communication with partners when ticket is too inefficient.

Information Classification Level

Public

Expected response time of VSHNeers

Best-effort.

Mandatory for VSHNeers

No

Partners know that this is best-effort.

In urgent cases ticket or phone are the correct channels.

For communicating with a customer in his Slack channel f.e. during an incident, there is usually a generic account available in the VSHN password manager.

26.3. In-Person Channels

Make sure to document the outcome of any in-person meeting!

Talk

Functionality

Efficient and personal.

Information Lifetime

Up to an hour

Except what’s written down.

Used for

Getting help, discussing things.

Getting to know a person.

Information Classification Level

Internal

Depends on involved parties.

Expected response time of VSHNeers

Synchronous, instant.

Mandatory for VSHNeers

Be open to talk and friendly when someone approaches you.

Phone calls

Functionality

Efficient and personal.

Information Lifetime

Up to an hour

Except what’s written down.

Used for

See "Talk."

Information Classification Level

Internal

Expected response time of VSHNeers

-

Mandatory for VSHNeers

-

Forward calls

For external calls: Telefon extern verbinden

For internal calls: Telefon intern verbinden

More information about phone calls can be found in the Zoom Phone and How to Answer Phone Calls pages.

Internal Education

Functionality

Spread knowledge and create awareness

Information Lifetime

Up to a month

Except if it’s based on a Wiki or Handbook Topic.

Used For

Creating awareness for new processes and technologies

Refresh awareness on existing processes and technologies

Spread knowledge about technologies, processes workflows and tools.

Introdion in to topics.

Mandatory for VSHNeers

Some are.

Meetings

Functionality

Efficient when moderated or limited number of attendees.

Please refer to the Meetings section of this handbook.

Information Lifetime

Up to two hours

See "Talk."

Please take notes.

Used for

Brainstorming.

Retros.

Getting everyone on the same page.

Meeting partners.

Information Classification Level

Internal

See "Talk."

When not using unsafe remote conferencing tools.

Expected response time of VSHNeers

Synchronous, instant

Mandatory for VSHNeers

Yes

When meeting invites are accepted.

Meetings marked as mandatory.

Audio / Video Conference

Functionality

Official tool in VSHN is Zoom.

Remote audio and video calls.

Screen sharing for collaboration and presentations.

More details are documented in the Videoconferencing Guidelines page in this handbook, and in the wiki.

Challenges

Usually only usable with 3–4 participants.

Without (good) video: Missing out on non-verbal communication: facial expressions like smiling/frowning.

A (working) headset is required to participate. Plain old voice calls (no Internet): Usually bad experience due to low bandwidth combined with cheap headphones beeing used by participants.

Information Lifetime

Up to two hours

Except when recorded

Not searchable

Not guaranteed

See "Meetings"

Used for

Same as Meetings, same rules apply

Only when In-Person meetings aren’t possible.

Dial into broken video conferencing tools (Skype for Business, etc)

Information Classification Level

Internal

Expected response time of VSHNeers

Synchronous, instant

Mandatory for VSHNeers

Yes

When invited to a Zoom meeting, prepare yourself, test the tool beforehand, and be ready to use it.

When no other option is available.

27. Emergency Communication Channels

The emergency communication was merged into our standard Incident Process.

28. Everyday life

Working at VSHN is a special experience, based in collaboration and communication. This section provides some information about those little things that helps us to work better every day.

28.1. Weekly Company Meeting

Every Monday at 11:15 AM (Zurich time), the whole company meets for a weekly all-hands meeting to discuss everything that’s going on across teams. This meeting is called the Weekly Company Meeting. New Interest Groups are announced there and everybody can share news and information, so that we all know what’s going on as soon as possible. We meet in the cafeteria and will start on time, so please arrive a bit early. You can attend physically or through video conference.

There is a separate section in this handbook about the Weekly Company Meeting with more information.

28.2. On-Call

The technical teams of VSHN provide an optional 24x7 on-call support service, organized in a rotation. For more details check the Wiki, or consult with your Mentor.

28.3. Office Life

To learn about how it is to work in our Zurich office, head over to office_life.epub.

29. How to Answer Phone Calls

Answering phone calls is a skill and an art. Here are some tips and tricks for those not used to answering calls in a corporate environment.

29.1. Greeting

There is no second chance for a good first impression. Focus all your attention on the conversation and be friendly.

Please smile

Smile before you pick up the phone. If you have a smile on your lips, your voice will sound friendlier.

Let it ring twice, but maximum five times

Let the phone ring twice before picking up the receiver. The caller doesn’t expect you to answer immediately.

Company, your first name and surname, greeting

First state the name of our company, then your first name and surname. The caller often doesn’t understand the first words correctly. Since he is calling your company specifically, he expects the company name to be mentioned. Using your first name has a personal and friendly effect. You can open the conversation with a "Hello!" a "Good Morning!" or a "Grüezi!"

No empty phrases

At the end of the greeting, don’t use phrases like "What can I do for you?" It’s meaningless and sounds like a switchboard.

29.2. Tips for the conversation

If you have introduced yourself, let the caller have his say. The caller will introduce themselves and state the reason for the call. Listen carefully, request clarification if you haven’t understood something, and repeat important information back to the caller for confirmation.

Making notes

Take notes during the conversation. Your notes are properly written when you can answer the following questions:

Who called? (Name, Company, Phonenumber where he is reachable)

What was the conversation about? (Ticketnumber?)

What was agreed? (will he call again or is he expecting a call back from VSHN?)

Remember the name of the caller

Remember both the first name and the last name of the caller. This will look good in later correspondence. If you don’t understand the name, use the present tense when asking: "What’s your name?" Request the caller with an unusual name to spell it.

Academic Degree

If the caller holds an academic degree, please address them as "Herr Doktor Hinz" or "Frau Professor Kunz."

Address the caller by name

Address the caller by name. However, don’t use the name too often, as this will be obtrusive. Two times are sufficient: at the beginning and when saying goodbye. Put the name at the end of the sentence: "I will send you the information material tomorrow, Mr. Schuster!"

Transfering calls

When you forward to a colleague, tell the caller the first name and last name of the colleague to whom you are forwarding. "I’m now connecting you to John Smith, our Python Specialist."

if the colleague you are looking for isn’t available because he or she is already on the phone or not at their desk, it’s best to leave the colleague a message via chat, with the name of the company, the name of the caller, their phone number and the reason for the call (as already mentioned above.)

Formulate positively

Avoid negative formulations and say things positively. Instead of "I’m afraid I don’t know," it’s better to say "I’ll inform myself and call you back." Instead of saying "Not this week anymore," "Probably next week" sounds much better.

29.3. End of conversation

After the call has been completed, you can politely end the call. You have several options for doing this:

Summarize

Summarize the contents of the conversation again: "May I summarize again? …“

Thank you

Thank the person you’re talking to for calling: "Thanks for the call, I’ve made a note of everything."

Questions

State a closed question that the caller can only answer yes or no: "Can we stay like this?"

Assure

Promise the caller that you’ll take care of his request: "Fine, I’ll take care of it right away!"

30. Customer Communication Guidelines

Check out our Internal Communication Principles.

30.1. Response Time

Aim to respond in a timely manner, ideally within half a work day at most. For tickets and incidents, abide by the relevant SLAs.

30.2. Say Thank You and Sorry

Express gratitude for reaching out, regardless of the reason for contact.

Offer a sincere apology for any inconvenience or problems experienced by the customer.

30.3. Professionalism and Tone

Maintain a concise, clear, and informative communication style.

Use a professionally pleasant tone and keep the formality appropriate.

Use company language (English) and ensure spelling and grammar are correct and on a professional level.

30.4. Show Empathy and Attentiveness

Demonstrate understanding and kindness when addressing customer questions and concerns.

Listen attentively, summarize before you dive into the resolution / Answer to customer inquiries, concerns, and feedback.

30.5. Personalize Communication

Address customers by their preferred name or title.

Tailor communication to meet the specific needs and preferences of each customer, including language formality and inclusivity.

30.6. Clear and Accessible Language

Use jargon-free language for easy understanding.

Check with customer if you understood their request completely and no misunderstandings arise from technical unclarities, or missing understanding on either side.

Break down complex information into digestible chunks, utilizing bullet points or numbered lists when necessary.

30.7. Empowerment and Self-Help

Provide resources, such as self-help materials, FAQs, or knowledge bases, to assist customers in finding immediate answers to non-technical questions.

30.8. Follow-up and Closure

Set clear expectations for follow-up actions and timelines.

Close the communication loop by checking back with customers after resolving their issues to ensure satisfaction.

30.9. Structure of Emails and Tickets

Begin with a personalized salutation, addressing the customer by name if possible.

Express gratitude for their contact and interest in your services.

Apologize sincerely if any issues or interruptions were mentioned.

Provide a clear and concise response to their inquiry or concern.

Summarize the main points discussed and offer necessary next steps or further information.

Conclude with a courteous closing remark, followed by your name and contact information or necessary company signatures.

30.10. Proactive Communication and Readiness

Anticipate potential customer questions or concerns and address them proactively.

Provide relevant information or updates before customers need to inquire about them.

30.11. Invite Feedback

How can we improve? Encourage customers to share their experience and provide suggestions for improvement.

Regularly review and update the customer communication guidelines based on customer feedback and evolving needs.

31. Incident Handling

31.1. Sources of Incident Alerts

Monitoring Alerts ⇒ Acknowledge the OpsGenie or Icinga alert!

Customer Ticket via VSHN Portal control.vshn.net

Customer Ticket via Email

Customer Calls our Technical Hotline +41 44 545 53 53

31.2. Jira Ticket

Check if an Incident Ticket already exists for the issue at hand, otherwise create one.

Minor incidents which can be very quickly fixed don’t need a dedicated ticket.

If more than one customer could be affected, create a ticket in VSHNOPS and link the tickets for any affected customer, as to keep data security intact.

Assess Severity Level of incident. Set ticket priority accordingly.

Note how you got alerted (Who called, what monitoring alert)

Link the OpsGenie alert if you have one.

Write down how to reproduce the error / Check the status (link alert, etc.)

If it’s about a security vulnerability, then check out Vulnerability Process for VSHNeers

31.3. Communication

Internal Communication:

Ensure a communication channel is established

vshn.chat reachable:

For high severity incidents create a new public channel for this incident, called #incident-YYYY-MM-DD, for example incident-2020-09-01 and announce it in the Threema group "VSHN Tech" and #general vshn.chat channel.

Lower severity incidents can be handled in #operations channel

vshn.chat unreachable: Announce the incident in the Threema group "VSHN Tech" and include the information that vshn.chat is unreachable.

Join the VSHN Company Zoom room, the same as used for company meetings. With that we can keep the paths of communication short and have a first organization.

Announce the Incident to the vshn.chat #operations channel.

External Communication:

Check the "00-OnCall" wiki page in the customer wiki space for any customer-specific contact instructions, procedures, etc.

Establish communication with customer

Define contact channels with customer (Ticket + Chat, Zoom or phone)

Define next contact time, prioritize problems with the customer

If needed, regularly update status.vshn.net or status.appuio.cloud during solution finding (get help from someone who is not involved in problem fixing).

if more than one customer is affected

or the incident has a major impact and downtime is more than 10-15

or for other reasons that might call for it

31.4. Get Help and Coordinate

Ensure to get help, if…​

…​ it is useful or needed.

…​ it is clear that one person alone can not handle it quickly.

…​ it’s not solved (system running again) within 30-60 min.

…​ more than one customer is affected and coordination and communication need to be handled with more focus, than one person can spare.

31.5. Distribute Responsibilities

One person can take cover all responsibilities or, they can get split up, as the engineers involved see fit.

Technical lead - Owns the technical problem-solving

Technical help - Contributes towards the technical problem-solving

Organizational lead (aka Incident Commander) - Handles documentation, information and feedback

Documents the incident timeline

Procures needed information

Requests feedback along the way where useful or needed

Mandatory: request confirmation once technical lead is confident the service(s) are back online. ⇒ Confirmation can come from customer if he was involved, or internal, if customer was not involved.

Communication Manager - Who ensures communication with the customer(s) must be kept updated at regular intervals about:

Results of the problem analysis

Progress in problem-solving

Foreseeable duration of the interruption

The solution or parts of it, as soon as it is available, even if the solution is only a temporary one.

31.6. Close Ticket

As soon as the incident is resolved, inform the customer of the resolution and close the incident ticket.

Document the cause, the timeline and the solution(s)

Document if there is anything left to do:

What is left to do?

Link follow-up ticket.

31.7. Next Steps and Follow up

These are very situational, depending on the severity, the nature of what caused the incident, whether the solution is just a temporary one, if there is more left to do, etc.

Inform Key Account Management and check if a post-mortem is needed or requested by customer.

Check if one or more follow-up problem tickets are needed to work on the underlying root cause. Problem tickets may evolve into change tickets, once an actionable solution for the underlying cause has been found.

32. What to do if someone is behaving in a non-VSHNary way?

As described by our Company Values:

Values are the definition of VSHNaryness: how we behave and interact with each other as VSHNeers and as VSHN.

What does this mean in practice? How do we notice if someone is behaving in a non-VSHNary way? And what should be done if this non-VSHNary behaviour persists?

It’s important to understand that we’re not talking about single mistakes/problems that happened (after all, we are humans), but a consistent, non-VSHNary behaviour over a longer time period affecting other VSHNeers, externals or the company as a whole.

The table below offers some examples of each VSHN’s Company Values.

32.1. Positive and negative examples of VSHNaryness

The number of an example on the right side refers to the example on the left side.

Value
Positive example
Negative example

Accountability

VSHNeer tells you that they take care of something. This something is taken care of (deliver what’s promised).

VSHNeer tells you that they take care of something. VSHNeer figures out there’s no time to do it and informs you or finds a different solution.

VSHNeers offer help, if they are able to help.

VSHNeer understands their responsibilities and takes care of them, as a stakeholder you don’t have to control or ask for it.

VSHNeer tells you that they take care of something and then doesn’t do it.

VSHNeer doesn’t do the tasks they are responsible for or committed to and don’t inform you (as the stakeholder).

VSHNeer never offers help even when asked by another VSHNeer.

VSHNeer is involved everywhere but leaves their actual job behind, which leads to more issues & stress for the teammates.

Curiosity

VSHNeer experiments and learns new stuff to address the challenges at hand. Fail quick, fail often - do it better next time.

VSHNeer is open to new things and constantly educates themselves.

VSHNeer does not want to learn/touch new things (without any proper reason).

VSHNeer does not develop know-how wise. VSHNeer rejects further education and/or new ways of thinking/solution/work, etc. ("we have always done it this way" attitude).

Effectivity

VSHNeer questions the tasks at hand and prioritizes doing the right things needed to get the job done and to fulfil the responsibilities of their role or team.

VSHNeer stays focused on what is needed to get the job done.

VSHNeer is always seeking ways to understand needs and improve work based on them, whether through automation or rethinking for the good of the company and therefore all VSHNeers.

VSHNeer works randomly on incoming tasks without knowing why (higher purpose) nor asking why.

VSHNeer gets lost in details of a task or problem, not knowing why they are doing what they are doing and not getting help.

VSHNeer invests time into changing, improving or automating things, without being clear (decision) if it will address an actual organizational need ("the problem is not the absence of your solution").

Integrity

VSHNeer is honest and virtuous.

VSHNeer takes constructive criticism seriously and doesn’t take it personally, but improves on it (you can always learn).

VSHNeer is able to offer criticism respectfully and constructively, remains calm & objective and focuses on how to improve.

VSHNeer follows through on agreements even if they don’t agree or like them (as long as no objection is brought up).

VSHNeer does not behave respectfully toward others, talks behind their backs, or pursues a hidden agenda.

VSHNeer is more destructive than constructive.

VSHNeer is blaming others (blame game) or criticizes on a personal level.

VSHNeer does not adhere to agreements, talks badly about it behind the backs of those in charge instead of addressing the problem directly with those in charge.

Positivity

VSHNeer is fun to work with and optimistic ("glass is half full").

VSHNeer notices problems and opportunities tries to understand them and brings them to the attention of whoever is responsible. If no one is, they take ownership to drive it forward - if there seems to be an organizational need for it.

VSHNeer is very negative and spreads this around the team/company, drags others down.

VSHNeer recognizes a risk, problem or opportunity and keeps it for themselves or only complains about it.

Transparency

VSHNeer shares results and know-how with other VSHNeers through an appropriate channel (unless there is a specific reason for confidentiality).

VSHNeer communicates openly with the customer and ensures they are always up-to-date about the progress of a ticket.

VSHNeer communicates opportunities, tensions and problems openly.

VSHNeer documents their work and status of their progress standardizes and automates things to be replaceable.

VSHNeer improves existing documentation or contributes to those who are responsible.

VSHNeer keeps everything for themselves, doesn’t share it with other VSHNeers.

VSHNeer doesn’t communicate openly with customer or doesn’t inform about progress and/or next steps.

VSHNeer doesn’t communicate problems/tensions.

Other VSHNeers don’t find the needed information about status and progress of the work. For example, if the VSHNeer is sick and someone else has to step in, things are not documented or in a way you can’t find them).

VSHNeer just complains about things not being documented, but doesn’t help with documenting or creates a follow-up to ensure additional documentation.

32.2. Next steps if someone is behaving in a non-VSHNary way

So what should you do if you and/or your team thinks that a person behaves constantly in a non-VSHNary way?

First of all, you should talk directly with the person, that should always be the first step. But if (for whatever reason) you can’t and/or don’t want to do this or don’t feel comfortable with it, search help in your team and talk about it in a group (or at one of your standups).

If the tension persists and you can’t solve the problem on your own and also not within your team, the further process should be as follows:

Talk to PeopleOps about the tension and tell them why you think the person behaves constantly in a non-VSHNary way.

PeopleOps will talk to the person directly and listen to their view and a personal development plan might be established on how to improve the situation and a timeframe is set to re-evaluate/check again.

If the problems persist, talk again to PeopleOps.

PeopleOps will talk to the person directly and might include a 3rd person and listen to their view again and the personal development plan should be further detailed on how to improve the situation and set a timeframe to re-evaluate/check again.

If the problems persist, talk again to PeopleOps.

PeopleOps will inform management about the problem and a meeting between the person, PeopleOps and management will take place. A final plan will be established to resolve the situation, including a time frame and a fixed date when to evaluate again.

If the problems persist, measures have to be taken which can include switching teams or as a last resort, the dismissal of the employee.

So to summarize the process, the communication and "escalation steps" to resolve such a situation should always be those specified in the Conflict Resolution Process:

→ Talk one on one → Talk with the team (including the affected VSHNeer) → Talk to PeopleOps → PeopleOps might include management in the discussion.

33. Conflict Resolution Process

One of the most important objectives of VSHN is to create a great work environment. We’re aware, however, that conflicts may arise from time to time. This page provides some guidance as to how to solve those issues in the most productive way.

The conflict resolution process is very simple and straightforward:

Talk directly to the VSHNeer you have a tension/problem with or is responsible for the topic.

Discuss tension within team.

Talk to People Care

Talk to management

33.1. 1. Talk to the other person

The first, simplest step for any conflict resolution starts with an open, respectful, frank, and private dialog between the involved parties. Take a moment to discuss the issue at hand, preferably in private, and if preferred, sharing some tea or coffee. Most problems usually stem from misunderstandings, and the VSHNeer spirit will always appreciate a honest conversation.

33.2. 2. Discuss with the team

Some issues, however, might spread outside of the private circle of VSHNeers and affect a whole team. In that case, gather the involved parties and expose the issue at hand, respectfully and thoroughly. Request your Team Facilitator or Scrum Master to moderate the discussion if needed.

33.3. 3. Talk to People Care

If all else fails, our People Care will mediate to solve the situation, as a neutral position in the interest of the company.

33.4. 4. Talk to Management

If the issue persists, it makes sense to involve company management to solve the issue. As a last resort, our Management might intervene and eventually take a final decision in the situation.

34. Holidays

If you are looking for Public Holidays, please see Work Hours

If you are looking for how to request Holidays, please see leave_requests.epub

So you have earned your days off! Well done. Before you go to sip those mojitos on that well-deserved holiday, however, please make sure to tick all boxes in these checklists.

We love receiving postcards from all over the world! Will you send us one?

34.1. In General

Make sure your legal leave request is approved by PeopleOps in Odoo before the timesheet is submitted for that month.

Setup this out of office autoreply for your e-mail account.

Add your absence to your calendar, so your co-workers know when you’re away.

Consider adding a blocker in your calendar on the day of your return, to prevent excessive meetings right upon your return.

Make sure you’re not having any duty during your holiday; if so, find someone who covers you and document it (for example overrides in Opsgenie).

In the last team planning meeting, remind the team that you’ll be away, and for how long.

Request your Legal Leaves by PeopleOps - See under How to Record Leave Request

34.2. On the last day

In General

Smaller tasks should be finished; don’t start any big ones.

Make sure all your issues in Jira are up-to-date: status, work logs, comments, due-date, priority, relations to other tickets, etc.

Hand over issues, if they can’t wait until after your holiday.

Submit your timesheets before you go on holiday!

Turn off your computer completely.

Current projects

Make sure someone is looking after your tasks in progress. Talk to the SM to discuss the exact approach!

Write down everything you discussed with customers which isn’t yet in tickets or the wiki (including deadlines, priorities of tasks, etc.)

The last comment in the ticket should always show what the next steps are and what’s left to do to complete the task.

Set a downtime on the monitoring-check for your local backup (if you have one).

Inform the customers that are prone to contact you directly about your absence, and tell them who to contact during that time.

Push all your local changes to git.

(Technical) Service Managers

Make sure:

you have a stand-in for each customer, and make sure this person is aware of that.

to talk to the stand-in about any running projects and important operations duty task you know of: Next steps, deadlines, priorities, expectations of the customer.

34.3. After a holiday

If you are returning from a holiday:

Reserve some time for yourself to be able to catch-up with emails, chat and other updates.

Read everything in the #announcements channel.

Read relevant meeting notes of meetings you missed (for example company meetings).

Request an update from one of your team what happened the last week(s), especially concerning changes within bigger projects, their plannings and decisions.

Go through the team board.

34.4. Checking your Holidays

There are multiple ways to check your balance. Navigate to Time Off to find this screen:

① Shows your available Paid Time Off days for the current year. Clicking on the (?) shows more information.

② When opening the "New Time Off" popup, the "Time Off Type" dropdown shows this information as well, depending on the selected Dates below.

Alternatively you can click on your name on the top-right corner and select My Profile. In the appearing screen you see a smart button which also shows you this information.

35. Pay Slip and Overtime

VSHN does not send your monthly payslips actively. On your pay slip your salary, the legally prescribed social security deductions, and your overtime is summarized. This page describes how you can get the pay slip if you are interested in.

35.1. How to Get the Payslip

Payslips are available under My Profile › Documents in the "HR / Payroll" folder.

35.2. Overtime

Accrued overtime must be taken within 12 months, as is required by Swiss law.

36. Sick Leave

If you are sick, you don’t have to work. If you have a doctor’s certificate ("Arztzeugnis") you are only allowed to work as much as stated there. To ensure all your duties are covered during your sick leave, you can follow the checklist in the next section.

36.1. Checklist on Sick Day

Inform your team and domain_peopleops.epub.

If you know that you are going to be sick for a longer period of time, inform the team about the next time you will update them regarding your health.

Create auto reply in SOGo if you know you will be absent for longer period of time.

If you are on-call, notify the Operations work group (via RocketChat). They’ll find a replacement for your shifts.

Ensure that any appointments with customers and colleagues will be cancelled properly.

If you are sick for more than 3 consecutive days, you need a doctor’s certificate ("Arztzeugnis"). Provide it to People Operations.

36.2. After Back to Work

see also Leave Requests.

Log Absence in Odoo

See How to Record Leave Requests and use the Time Off type "Sick / Medical Consultation".

If you have a doctor’s certificate ("Arztzeugnis"), attach it as "Supporting Document".

36.3. General considerations

Doctor’s appointments are to be scheduled for off-peak hours or, in the case of part-time employees, for days off.

If this is not possible, the absence must be recorded in Odoo as Sick / Medical Consultation.

Further information:

Sick leaves in Time Off

Log Absence in Odoo

37. Company Language

VSHN was started by Swiss nationals in the German speaking part of Switzerland back in 2014. For most of us it was only natural to speak in our native Swiss German language, and thus we wrote most of our early documentation in German.

Since then we hired more people from all over the world. Now a growing number of VSHNeers don’t speak or understand German. Fortunately it’s very common to find very good English speakers in the IT industry; therefore in 2019 we changed the official company language to English.

The official company language for written text is English. In meetings it’s just polite to speak the language that everyone understands–this is usually English as well.

37.1. Does this mean you shouldn’t speak your native language?

Of course not. You’re free to use whatever language works best for all participants in a conversation. For most official meetings, be it internal or with external partners, this means that we speak English.

Remember that we document in English even when speaking another language in a meeting. You never know who will read the notes later and will need to understand its contents.

During breaks, company events and when we’ve lunch together you usually see some groups speaking a native language like Swiss German–this is great as it’s our free time, and usually a very welcome change from the official daily routine. Don’t be afraid to join such a group though, as we will simply switch languages then.

37.2. Improving language skills

Keep in mind that not everyone is equally proficient or feels comfortable to speak a non-native language. Be sympathetic towards small grammar mistakes, wrong words and bad pronunciation. Apply the robustness principle: "Be conservative in what you send, be liberal in what you accept."

Most VSHNeers are eager to be corrected, or to get vocabulary suggestions when such mistakes happen. On the other hand, please don’t create awkward situations during presentations or bigger meetings by interrupting the presentation flow.

Depending on your language proficiency it can be tricky to write good text in a non-native language. To ensure quality, particularly when communicating with third parties, apply the "four-eye-principle" (or pair programming) and let a colleague review your text before saving or sending.

Last but not least, remember to use an online translation service or a dictionary, request help from colleagues, use your education budget to improve your skills, and take your time when writing.

37.3. Links

Worth a read:

Say What You Mean (SWYM) by GitLab

Gender-neutral Technical Writing

38. Time Off

This section contains information about how to request holidays, or any other type of leave request.

Every employee has to take two consecutive weeks off once per year! The Swiss labour law demands this; People Operations check that this is done!

The respective holiday quotas are recorded by People Operations in the ERP.

The holiday credits from the previous year are converted into overtime, and credited individually at the beginning of each year (To be mentioned separately on the payslip) Let PeopleOps know, by e-mail, if you don’t want them to convert your vacation days into hours.

Leave requests must be entered for the current month before the wage payment, otherwise the payroll will be broken.

Leave requests can’t be granted subsequently. If you forgot to enter your holiday and had the day off, it will simply be deducted from your overtime.

38.1. How to Record Leave Requests

It doesn’t matter whether you first reduce your holiday credit or your overtime. What’s important is that you allow yourself regular rest and plan some holidays.

In vshn_central.epub, navigate to Time Off and either click on [New Time Off] or directly in the calendar on the respective date. It’s also possible to select multiple days in the calendar by clicking on the first day, drag the mouse to the last day and release the mouse click again.

In the popup which appears, choose the appropriate Time Off type and fill-in the rest of the fields.

Approval of the leave request happens via the Team Facilitator.

38.2. Time Off types

Paid Time Off

These are your assigned Holidays per year, including the seniority days. See also Holiday Checklist.

Unpaid

Unpaid leaves do not necessarily have to be recorded, but to help with planning, they should be recorded in the Time-Off app as well. Use the Time Off type "Unpaid".

Sick / Medical Consultation

Use the Time Off type "Sick / Medical Consultation". See also Sick Leave Checklist.

Sick leaves

are the first 2 days sick at home.

are when you are on sick leave prescribed by the doctor.

Medical Consultation

In principle, visits to the doctor, dentist are not working time (that is, you may record no attendance), as we have annual working hours, and you can choose when you work.

Therefore, all appointments (including doctor’s appointments) can be scheduled at any time but are not work time (you must sign out) and must be coordinated with your team to limit any negative impact as much as possible.

In urgent situations, such as medical issues where you need to see a doctor as soon as possible, you cannot schedule. That’s why VSHN grants you this time as working time up to 2 hours per incident.

Authorities

In principle, visits to the authorities do not count as working time (that is, you are not allowed to record attendance), as we have annual working hours and you can choose when you work.

Therefore, visits to the authorities can be scheduled at any time, but are not working time (you must sign out) and must be coordinated with your team to limit negative effects as much as possible. In urgent cases where going to the authorities could not be planned in advance or postponed, VSHN may grant you this time as working time up to 2 hours per incident.

Requested Public Service

For example, this is for Militia Fire Service.

counts as work time during normal office hours for ordered assignments ("Einsätze" or "Angeordnete Übungen"), because:

according to Swiss law (Art. 324a OR) the fulfillment of legal obligations during normal office hours is work time.

There is a militia fire service obligation in most cantons and municipalities of Switzerland which counts as fulfillment of legal obligations.

VSHN decided in VIP-70 to give this right to any VSHNeer in active fire service duty, regardless of the canton or city of residence.

salary impact should be checked annually by PeopleOps only if a VSHNeer has an annual double payment exceeding CHF 500. We don’t actively enforce this and trust VSHNeers to report if they estimate this to be higher.

Military Service

Swiss Military service, Civil Service and Civil Protection Service.

Military service requests don’t have to be approved by People Operations.

Special Occasions

Additional paid days off include the following:

Event
Duration

Own wedding

3 days

Wedding of a close relative

1 day (1st degree)

Birth of child with partner

20 days (paternity leave)

Change of residence

1 day per calendar year

Death of a family member

3 days (1st degree)
1 day (2nd degree)

Must be requested in Odoo (under Time Off / Allocation Request) with the Time Off type "Special Occasions." Once the allocation request has been granted, enter it into the calendar like any other absence.

39. Meeting Rooms

The following rooms are available and bookable via SOGo.

Check out the Calendar for an how to add the calendars to SOGo, Evolution, and Thunderbird.

Use these meeting rooms for meetings with customers or formal internal meetings:

39.1. VSHNtower (8th Floor in Neugasse 6)

This is our break room / common room and cafeteria.

Can be booked for customer meetings, private events of VSHNeers, including external guests.

The VSHNeer booking it is responsible (damage to things, access, cleaning, restocking food and drinks, etc.)

Such Events, even if outside VSHN office hours or on weekends need to be booked in the calendar.

For lunch, bigger meetings, exceptionally meetups & bigger meetings with customers (must be announced/asked in advance).

Please ensure to not have meetings during lunch time there. Access for lunch must be granted.

Please be aware that it is outside our ISMS scope which means it is not secured and you should not store company data there.

Resource name in SOGO: VSHN Tower

Resource address to reserve the room: resource-vshn-tower@vshn.ch

39.2. VSHNtower Small Room (Small Room South Side of 8th Floor in Neugasse 6)

Can be booked for internal and external meetings.

There is a bar table with some bar chairs, works for three to four people.

Resource name in SOGO: VSHN Tower Small Room

Resource address to reserve the room: resource-vshn-tower-small-room@vshn.ch

39.3. VSHN Meeting Room (Big Room in Neugasse 10)

Meeting room without windows. Smaller meetings should take place here to leave the VSHN Tower free.

Resource name in SOGO: VSHN Meeting Room

Resource address to reserve the room: resource-vshn-meeting-room@vshn.ch

39.4. VSHN Entrance (Entrance Neugasse 10 Coffee Room)

As a general rule, the entrance shouldn’t be used for meetings. Here the main entrance is located and we pick up visitors, which doesn’t guarantee a meeting free of disturbances.

For informal meetings, waiting room: 4 chairs, coffee table

Resource name in SOGO: VSHN Entrance

Resource address to reserve the room: resource-vshn-entrance@vshn.ch

40. How to do Meetings

An action item of the VSHNday 2019 was to improve the efficiency of meetings through some easy to follow rules.

To put it in perspective:

American companies hold an estimated 11 million (subjective) meetings per day. It’s predicted that the unproductive portion of these cost the country a whopping $37 billion yearly.

40.1. What’s a meeting?

A meeting at VSHN is a scheduled, prepared and time-boxed gathering of people for the purpose of achieving a common goal through verbal interaction, such as sharing information, solving conflicts or reaching agreement.

One-way information sharing is better done in a written way, especially when you don’t expect direct feedback or questions. Meetings to just share information are mostly ineffective and unnecessary.

A meeting has

A written agenda (before the meeting)

Written meeting minutes that document the findings from the discussions and the next steps or action points

A way to join the meeting, independent of where the participants are

A note-taker

A facilitator that guides the meeting

Usually more than two participants in total

Scheduled start and end time

The following aren’t examples of meetings

Working collaboratively on a task or problem, usually at a computer

Pair-programming or shadowing a colleague

Workshops with the goal to produce something new (code, documentation, a proof-of-concept system installation and similar)

Just the fact that you’re in a video call doesn’t make it a meeting.

40.2. General

Be on time. We start meetings on time. Making others wait for you is impolite and sends the message that you don’t value their time.

try to be ready at the meeting location 5 minutes early

join the video call before the scheduled start time

This works better if a previous meeting in the same room (physical or remote meeting-id) finishes 5 minutes earlier than the time it was booked…​!

Regularly assess if recurring meetings in your calendar are needed at all, and if so, if the format, length, and attendees are contributing to their effectiveness. Are they not? Change!

Even as an attendee, make yourself familiar with what it means to be a facilitator. Observe how they drive the meeting and help (not judge) in a friendly way if they forget something.

Pay close attention that a meeting is never ended without action points and owners defined.

If the participants leave the meeting, and no one is accountable for taking action on the decisions that were made, then the meeting will have been a waste of everyone’s time. This is crucial.

40.3. Attend a meeting

Prepare

Accept the calendar invite as early as possible.

Read the agenda. If things are unclear, clarify before the meeting.

Remind the inviting person of these meeting rules, should you feel that they weren’t prepared well enough.

Make sure that you know how to join the meeting remotely or how to get to the meeting location on time.

Don’t attend meetings remotely from a bad location (for example a train) or with bad equipment (others will have a bad experience too, not only you).

If no option to attend remotely was announced in the calendar invite, make sure the organizer fixes this.

Rules when attending

Make sure all participants have your contact information and correct name (usually done by the video call tool or calendar invite). Consider bringing your business cards when you’re meeting customers or partners for the first time.

Don’t bring stuff you don’t need during a meeting (lunch or smelling food, paperwork, laptop, etc.), leave your smartphone in your pocket, and turn it into silent mode.

Don’t use any electronic devices, when you’re not attending remotely, except if you’re presenting, are the note-taker, or you’ve to look up stuff that really contributes to the meeting goals.

Staring at your notebook screen in a face-to-face meeting is impolite. Whereas it’s natural to look at the screen when participating remotely.

Don’t check e-mails, your smartphone or even work on other things in a meeting. Pay attention and contribute.

In video calls one can easily tell whether a person is actively participating or working on others things.

Listen carefully and with an open mind, let others speak out and think before speaking.

Stay on the topic - gently push others back if they go off-track.

If someone is speaking too much, cut them off nicely.

If you figure out you can’t contribute anything during the meeting, kindly request permission to leave.

Attack the problem, not the person.

40.4. Schedule and facilitate a meeting

Before you schedule a meeting, try to avoid meetings when there is a better way.

First, get different opinions via a written channel or do some short one-on-one calls. Then prepare a written proposal that will make it much easier to come to a decisions.

Scheduling a meeting doesn’t necessarily mean that you also are the facilitator, but at least for internal meetings it usually makes sense.

Initiate

Who do I need for the meeting? Think well about who really needs to attend the meeting (contributors & decision makers, no spectators).

Keep in mind declining an invitation doesn’t feel nice (to both parties). Asking first (at best with the agenda) helps the organizer to find the right people.

How long should the meeting be?

Remember, we have a Harmonized Meeting Schedule. Meetings start at :00 and are either 30min or 45min long.

Should the meeting be moderated so everyone has the chance to speak and contribute?

Schedule

Create a "Meeting Notes" document in the wiki, including:

Name of the facilitator.

The agenda and discussion items

The list of attendees (defining the facilitator).

Fix the video call meeting-id (for example scheduled zoom meeting or your fixed personal meeting-id)

Send a calendar invite to all attendees.

Add the video call join link in the description and if the meeting is remote-only in the location

Book a meeting room (by inviting the meeting room resource calendar) if you expect people to join in the office.

Prepare

Learn how to be a good facilitator and moderator.

At the end of this document there are some links with information that can help you become a better moderator.

A day or at least an hour before:

Update the agenda, if necessary.

Check the needed tools like video conferencing, a retro-tool, wiki pages, etc. Try to avoid analog tools that don’t work well for remote attendees or increase the manual effort after the meeting.

Make sure the room you reserved is available, check that the location is still correct in the invite and that all attendees are informed.

When you’re sure that everyone will attend remotely, remove the booking of the room

Meet

You as the facilitator start the meeting on time,

Assign a note-taker; if no volunteers are willing to help, do it yourself.

Be a good facilitator (this includes all the rules of being a good attendee, as described above).

10 minutes before the scheduled end, try to stop running discussions in a friendly way, so you have time to:

Define action points including the owner of each action point (this must go into the meeting notes directly).

Decide whether open discussion items should go into a next meeting.

Summarize what needs to be done and who is going to do it (defined action points).

End on time, even if there are still unaddressed topics, opinions or questions.

Because you are using time of each attendee you would mess with their time planning.

Wrap up

In the last minutes of the meeting, or right after the meeting:

Check that the meeting notes are saved, check and fix typos, etc.

Add personal notes or brain dumps to the comments or notes (but don’t change action points or documented decisions after the meeting!).

If useful, send the link to meeting notes (or for external customers a PDF) to all attendees.

Does the outcome have value for the whole company, consider adding it to the next company meeting notes.

40.5. Links

Worth a read:

5 tips for facilitators of agile meetings

How do we make remote meetings not suck?

patterns.sociocracy30.org/rounds.html

41. Harmonized Meeting Schedule

Since remote and zoom times, it’s easy to schedule meetings back-to-back without a break in between. To enforce breaks, VSHNeers have started to set different rules for meeting durations, start and end times or similar. This made it almost impossible to schedule a meeting with different people, and some start times are hard to see on the calendar and don’t seem natural.

We need a standard for when VSHN meetings should start and end so that there is time for useful breaks by default. This will help people find slots for internal and external meetings, arrive at the next meeting on time and well prepared, and reduce stress factors.

41.1. Meeting Times

When VSHNeers organize a meeting, we stick to the following rules:

Meetings start at :00.

A Meeting is either:

30min long and ends at :30.

or 45min long and ends at :45.

This gives VSHNeers a minimum 15min break between every meeting.

41.2. Exceptions

Longer meeting formats

Workshops, retros, education sessions or similar have to be planned carefully and can take longer, but still have the same start and end times. Planning carefully means for example:

Include at least one break in the middle.

A prepared agenda sent in advance, so that participants can decide whether it really makes sense to join and can prepare themselves.

Read more on attending and planning meetings here. We’ll also come up with internal educations on how to plan an prepare meetings.

If you need more meetings

We really think you should avoid this, but if you really need two meetings within an hour, you can still start a meeting at :30 as long as it does not impact other VSHNeers:

Don’t schedule meetings with VSHNeers at :30 if they have another meeting until :30.

Try to end your meeting at :50 or :55, because participant’s other meeting might start at :00.

Tell in the previous meeting that you need to leave a bit early, so you actually have a break yourself.

Dailies

In the sense of "safe enough to try" we think that 15-30min daily stand-up meetings can still happen right before lunch time, even if they start at :45 or :30.

Weekly Company Meeting

The Weekly Company Meeting starts at 11:15. As it ends before lunchtime and is kind of a historical thing to have it at 11:15, we think it’s safe enough to keep it like this.

These rules are tracked and reviewed as VIP-176

42. Time Tracking

By law, we have to keep track of the work time (attendance) of VSHNeers. To allow the Antares team to send invoices to customers for hourly billed work, we have to record the time we work for customers (work logs).

Both are tracked in VSHN Central: Attendances and Timesheets.

Don’t wait until the last day of the month to fill in your attendance and timesheets! Your contract states it should be done by the end of every work day, and experience shows it’s even better to do it immediately during the day, as you go from project to project.

42.1. Attendances

To record your attendance, login to VSHN Central and choose the application Attendances.

There are two different ways to record your attendance:

Check In / Check Out

When you start working, click on the big green button "Check IN" and when you stop working on the big orange button "Check OUT".

Manual Entry

Navigate to "Attendances" in the Attendances application and either click on [NEW] or chose the calendar view on the top right above the table and enter your attendance by click-and-drag in the respective time.

Should you forget to record your attendance, for each such day an entry will automatically be created with 0 worked hours, which should be adjusted by you.

Rules

Lunch

Lunchtime must be recorded separately, as it’s not automatically deducted. Simply check out & check back in according to your lunchtime.

Remember to take lunch breaks!

Labour law requires everyone in Switzerland to take lunch breaks. Please take them, and also remember to record your lunch break times accordingly every day.

Over 18 years old

If you work more than 5 hours daily, you must take at least a 15-minute break.

If you work more than 7 hours, a 30-minute break is mandatory.

If you work more than 9 hours daily, you must take a 1-hour break.

Under 18 years old

If you work more than 4.5 hours daily, a 30-minute break is mandatory.

If you work more than 6 hours, you must take a 1-hour break.

The break must be at least one hour after the start and one hour before the end of working hours.

Absences

Absence days must be communicated reliably, and above all they must be planned, as much as possible! Absences must be communicated in the team; exceptions such as illness and unforeseen events (train cancellations, etc.) as early as possible.

See leave_requests.epub how to record absences in VSHN Central.

Outside Office Hours (OOH)

Only upon request for work from 20:00 to 08:00 on regular work days and all day on weekends or public holidays. Typical types of work that fall into this category are planned maintenance and on-call alerts. Outside Office Hours aren’t to be confused with 24x7 worklogs for customers (which is about billing).

Reporting outside office hours is done by choosing the Attendance Reason "Outside Office Hours" while recording attendance. Please remember to choose the correct task to log your work to, so that it gets correctly invoiced should the work be for a customer.

42.2. Overtime / Undertime

To see your overtime or undertime, you have to go to My Profile and then Extra Hours.

A second option is the Time Off App there is a dashboard. Clicking on New Time Off and choosing "Extra Hours" as Time Off Type should give you an overview about your available overtime hours.

42.3. Timesheets

For us to be able to bill hours we work for our customers, or to be able to do reports on where our time is spent, we track our work time in Timesheets in VSHN Central.

Each Day

Each day, record your work in Timesheet entries. There are various ways to do that:

Via Tasks

Navigate to the "Projects" application, choose the Project and the Task you have to record time. In the "Timesheets" tab, record your time.

Via Timesheets

Navigate to the "Timesheets" application and click on "My Timesheets". Choose your favorite view and record your time.

There is an official Video from Odoo.com which explains it very well.

When recording a Timesheet entry, adhere to these important rules:

Choose the correct Project and Task to record time to

Write a short and concise Description, so that the customer and the Project / Account Manager understands what was done

The description must include the Jira issue number when the recorded entry is related to one.

Always round time to 15 min, the minimal duration is 15 minutes

For every customer, there is one main project available, named Customer: <Customer Name> and in this project there are a few default "catch-all" tasks to record time:

Support

Project Management

Account Management

When it’s unclear where to log time, ask the Account Manager of the particular customer you’re working for.

A rule of thumb is the following list of priorities to find a good task to record time:

Customer project

Customer support

Product engineering

Product operations

Everything else is not logged on any ticket

Each Month

Each month, a Task for every VSHNeer is available, in the stage "Timesheet Open".

To submit your Timesheet, navigate to Project › My Tasks. There you’ll find a Task named "Timesheet for <Month> <Year> (<Name>)", click on it and move it to the "Timesheet Submitted" stage.

43. People Pulse and Feedback

At VSHN, we have historically used various tools such as OfficeVibe and Lattice to foster a feedback culture and gather insights into VSHNeers' job satisfaction and their perceptions of the organization and employer.

However, these tools have presented several challenges:

The available tools were not customizable enough to match our VSHN Culture of Semi-Autonomous Teams.

They often presupposed traditional hierarchical management structures.

They required assigning a direct report for each employee.

They demanded the designation of team leads, contrary to our cultural practices.

Their permission models were dependent on the existence of direct reports or team leads.

They did not offer the flexibility for employees to assume multiple roles or to be part of several teams or workgroups.

The questions in pulse surveys did not resonate with our distinct culture.

They featured the eNPS question but did not permit custom instructions or explanations of its use.

When a tool consistently asks, "Please let us know what you think," it can lead to the belief that simply giving feedback will spark change, fostering an 'Employee versus Employer' mindset. This belief contradicts our "Leadership in every chair" culture, where problem-solving starts with the individual. We intentionally have no process or designated place where one can leave feedback about the organization and expect others to address it. This concept might be difficult to grasp initially, so we encourage you to familiarize yourself with the VSHN Culture. Nevertheless, for personal challenges, we have established places and responsibilities, as outlined in People Care.

43.1. VSHNeer Surveys

Currently, we use findmind.ch/ to create surveys, but only when we have a clear purpose for collecting data and a clear plan for managing the data afterward. It’s essential to fully understand our expectations and the responsibilities tied to free-text feedback or comments before we request them.

For access to findmind.ch, we maintain a paid account with personal user privileges. If you need access, please make a request in the #corporate-it channel.

Designing Effective Survey Questions

Our survey designs aim to reinforce our culture of proactive problem-solving and personal responsibility. The questions not only seek to identify areas perceived as challenging or in need of improvement but also prompt reflection on any actions already undertaken to address these issues. This aligns with our culture of "Leadership in every chair," where individuals are empowered to initiate change.

The types of questions we include are:

What challenges or opportunities have you identified?

What steps have you already taken to driving forward or addressing this issue?

What kind of support or resources would help you in resolving or taking advantage of this?

Before deploying a survey, we ensure:

The objectives for data collection are clear and the strategy for data management is explicitly outlined.

Responsibilities for responding to and managing feedback are understood and agreed upon - Who does what and how?

44. Tracking OKRs

At VSHN, we track our objectives and key results (OKRs) in our wiki - we used to have a dedicated tool that didn’t work well for us. That’s how it is for now.

The wiki allows for flexibility how you do things: We include content from wiki pages in different places to generate overview tables, etc. Therefore, it’s crucial to adhere to the format, especially not modifying the objective table and its fields in the first column.

44.1. Have a Space in the Wiki

In your team wiki space, create a page titled <Teamname> OKRs, for example, Polaris OKRs.

Each team should have an overview table and a button to create new OKR pages using the template.

Each Objective is an separate wiki page, a sub-page of the <Teamname> OKRs page.

You can replicate all this from here, avoid copying the sub-pages, instead create them using the template.

The global template is named Team Level OKR (you need to be confluence admin to change the global template).

44.2. Creating and Tracking OKRs

On your "Teamname OKRs" page, click the "Create OKR" button.

The page title format should be <year> <quarter> - <Teamname> OKR <number>, for example, 2023 Q4 - Polaris OKR 2.

Do not include the description in the page title as it complicates the creation of overview tables later on.

Use the first table to create and track the objective.

Use the second table to create and track the key results.

Use the expand sections, one per month, to enter update comments.

Update the numbers directly in the table.

Feel free to add new KRs as you learn more how to measure progress towards your objetive.

To document progress on the objective level, use the comment function of confluence at the buttom of the page.

The wiki template includes instructional text to simplify the process.

44.3. VSHN Specific Guidelines

Refrain from making significant changes to Objectives during an OKR cycle (a quarter at the team level).

Consult with your Delegator when implementing major changes to Key Results.

Unresolved directive in handbook.adoc - include::modules/ROOT/pages/lattice_enps.adoc[]

45. How to Troubleshoot Docking Stations

If you don’t use our standard docking station configuration and have problems with it use the steps below to troubleshoot.

45.1. Problem: Screen Flickering

If the display is connected via DisplayPort then change the DisplayPort version.

Check cable.

Check screen refresh rate.

Update all drivers for the laptop.

Update dockingstation driver.

45.2. Problem: Screen Is Detected but Remains Black

Unplug the monitor and plug it back in.

Disconnect the docking station from the power and wait until the monitor goes into sleep mode and then reconnect the dock.

45.3. Problem: Ethernet Is Not Working

Use a different cable.

Disconnect the docking station from the laptop and connect it again.

Make sure the cable is connected to the dock and the router.

45.4. Problem: USB ports are not recognized by the docking station

Disconnect the docking station from the system and connect it again.

Try another USB port.

Unplug the power supply and plug it in again.

45.5. Problem: Mac Does Not Support DisplayPort Version 1.2

Widescreens with USB-C Hub.

Widescreen and USB-C Hub suggestions on the Wiki page.

46. Weekly Company Meeting

At VSHN there’s a mandatory all-hands weekly company meeting. The goal is to keep all employees on the same page on what’s going on at VSHN. Those unable to attend must read the meeting notes and relevant linked information or view the recording as soon as possible.

When

Mondays, 11:15 AM to 11:45 AM (Zurich time)
Although the total time allocated for this meeting is 30 minutes, we strive to keep it under 15 minutes, reserving the remaining time for exceptional announcements.

Where

Remotely in the Zoom room whose URL is shown in the #general chat channel

Accountable

Manuel Hutter

Delegator

Management

46.1. Rules

To respect the time of every attendee follow the meeting rules.

The meeting protocol is updated with the eventual discussions held during the meetings, without personal statements. A VSHNeer is assigned at the beginning of the meeting to write notes down.

The meeting is recorded with Zoom. The URL to the recording is appended to the meeting protocol and is kept for a maximum of two months. This recording helps VSHNeers absent in the meeting, either because in a different time zone or not able to attend for whatever reason.

46.2. Meeting Notes

Every weekly company meeting produces meeting notes stored in our wiki:

The meeting notes have to be pre-filled with the agenda (see template here).

We usually don’t talk about topics that weren’t on the agenda before the meeting.

The meeting chair writes down the results of the discussions and most important comments in the second column.

The meeting notes are easily found on the wiki for later reference.

The accountable VSHNeer creates a new meeting note from the template (if not yet done by someone else) and checks all items before, during and after the meeting.

This meeting is tracked and reviewed as VIP-108

47. Learning and Reflection

To improve and learn we have to reflect to figure out what went well, what didn’t, and what to try to change. Then, we have to reflect again if the change did lead to actual improvement.

We do this on different layers:

Peer-to-peer one-on-one coaching for recurring personal reflection.

Personal coaching for larger personal issues.

Recurring team reflection in Team Retrospectives.

Personal Education: Personal Education.

Reflection on organizational issues: Evaluate and Evolve everything in the organization.

Person/role to bootstrap personal reflection during new VSHNeer onboarding: Mentor.

48. One-on-one Meetings

One-on-one meetings at VSHN are a tool for recurring personal reflection, akin to what team retros are for recurring group reflection. Reflection in this context can mean both "what does/doesn’t work well" and "what’s mentally blocking me." They’re recommended but not mandatory; just another formal communication channel, open to anyone interested.

In other companies, one-on-one meetings are used as "weekly standups with your line manager"; since we’ve daily standups and we don’t have line managers, this isn’t what we do.

A follow up for an issue might be driven through the Conflict Resolution Process, or to formulate an organizational driver. For larger issues identified in a one-on-one, a followup personal coaching session might make sense.

48.1. Finding a VSHNeer to do one-on-one meetings with

Your Mentor is the first person to have regular one-on-one meetings with (although you might want to talk to them more often than weekly.)

Invite someone from another team you think might give you good feedback. The People Interest Group has a list of volunteers.

We suggest doing at least one recurring one-on-one meeting with a peer; two or three might make sense to get more diverse feedback from VSHNeers in other jobs and teams. Doing more than three doesn’t realyl make sense, because they don’t provide additional value, and could be an effective waste of time.

If you feel you would like to change the person you do one-on-one meetings with, please give the other VSHNeer a notice period to find another peer to have meetings with.

48.2. Preparation

Prepare for a one-on-one by taking time to reflect what has been the best and worst events in the past few weeks; what has been a source of joy and of frustration? What has been mentally blocking you? And what are you grateful for?

For each item: why is the item so important to you? What feelings does the item spark in you? Is there an underlying issue that the item might be related to?

Write down your findings in a private document (for example in your personal wiki space), and collect other complementary topics to discuss as well.

48.3. Format

One on ones are weekly 25-minute meetings, giving each VSHNeer 10 minutes of reflection time after 5 minutes of check-in and socializing

Each VSHNeer shares their reflections with the other.

The other VSHNeer actively listens, helping the reflecting VSHNeer to find a root cause, the why.

The process could also be described as "postmortems for unhappiness."

48.4. Tips for the listening VSHNeer

Help the other VSHNeer dig deeper into the why by asking, for example:

"Why is this so important to you?"

"Why do you feel this way?"

"What could be causing this issue for you?"

"What do you think you can do about it?"

"What’s holding you back to just do it?"

Don’t judge, comment, or try to solve the problem, but instead help the reflecting VSHNeer to find (and eventually solve) the underlying issue themselves!

Take brief, confidential notes (for example in your personal wiki space), fill in details through clarification questions, and repeat back what you understood in your own words, for the reflecting VSHNeer to confirm if that was indeed what they meant: "What I heard you say is that you can’t do x because of y. Did I get that right?"

Don’t provide suggestions, tips, or advice about what the other person should do, so as to try to solve the other person’s problems. Giving advice implies that you know more about the other person’s issue than they do, which is rarely true, and implies inequality. Trying to solve the other VSHNeers problem also prohibits them from learning how to solve problems by themselves.

You may instead share your own similar experiences (good and bad) as inputs for the reflecting VSHNeer to figure out a solution themselves.

Questions serve the dual purpose of repeating what you understood from the other person, and for you to select a better fitting experience to share, not for personal curiosity, to steer a person towards a solution, or to wrap advice as a question.

Everything discussed in a one-on-one meeting is confidential by default. If you want to talk about issues with third parties you have to get explicit permission first. The Chatham House Rule is applied to root causes unless specified otherwise.

Be present and listen actively. Don’t multitask. For physical meetings electronic devices might be distracting.

Use open body language. Don’t lean back with your arms crossed.

Don’t let them cancel more than one one-on-one in a row, insist on rescheduling then. There are always more urgent things happening and canceling once is OK. You need to create accountability for the self-reflection process.

When you feel the reflecting VSHNeer is telling you what they’re currently doing (like in a standup) interrupt politely and bring the discussion back to "what’s mentally blocking you?" or "what has been a source of happiness/unhappiness for you?"

48.5. Goals

Peer to peer coaching: getting help to solve my issues myself.

Reciprocal: both VSHNeer peers coach each other equally.

Recurring: work on blocking issues before they get too big.

Relationship: build up a relationship based on trust to share emotions and allow to go deeper into the why.

Accountability for doing reflection and for following up with findings: formulate and write down tensions, drivers, or go through the Conflict Resolution Process.

48.6. Non-goals

For the listening VSHNeer to solve the problems of the reflecting VSHNeer.

Establishing a hierarchy between VSHNeers.

Unreflected ranting.

Talking about other people behind their backs.

48.7. Additional reading

Many one-on-one question templates found online are geared towards manager-employee conversations, but can provide some great ideas nevertheless:

hbr.org/2017/03/why-you-should-make-time-for-self-reflection-even-if-you-hate-doing-it

www.simplypsychology.org/learning-kolb.html

www.cultureamp.com/blog/great-one-on-one-meeting-questions

www.small-improvements.com/resources/1-on-1-meetings/#templates

49. Personal Coaching

If you discover during a one-on-one meeting an issue you want to discuss with somebody that doesn’t fit into the 10 minutes allocated to one-on-ones, you can request another VSHNeer or an external coach (PeopleOps can book one for you free of charge) for a personal coaching session.

49.1. Structure

The default duration is one hour.

Following meetings best practices, set an agenda of topics to talk about. These could range from professional growth, requests of mentorship, to more personal topics, and everything in between, usually related to our day-to-day life in VSHN.

Talking is cathartic; even if the session seems fruitless, that’s OK. Talking about problems is the first step towards the solution.

It’s not the role of the coach to solve the problems for the coachee, but rather, if possible, to guide them in the right direction.

Coaching sessions aren’t status updates about projects or customers. They’re about specific personal situations, which might or might not be work-related, but have a direct impact in our happiness or productivity.

49.2. Typical Subjects

The following is a typical list of subjects (by no means exhaustive) to talk about during coaching sessions:

Personal issues that have a direct effect in work.

Professional goals: growth, change, etc.

Requesting for advice about certifications, trainings, etc.

Voicing out unspoken issues that for any reason would not be shared in a team setting (for example, during a team retrospective.)

Conflicts between team and personal goals.

Impediments or conflicts blocking people to achieve their goals or do their work.

49.3. Tips for Coachees

It’s very important to have clear expectations.

Contact your coach for availability, and send a meeting request with a concrete time and agenda for the meeting.

It’s usually recommended to talk to a coach who isn’t working in the same team or job as you, so that you can get a different perspective about the issue at hand.

Furthermore it could absolutely make sense to consider a member of the management or one of the founders of VSHN for a coaching session. This can be very helpful to understand why some things are how they’re (history, business, etc.) and to give management a deeper insight into what’s bothering you.

Think about the discussion beforehand, and write down the main points of the conversation. Use those notes during the coaching session.

During the meeting, be open and share as much as possible of the problem at hand. It’s OK to be emotional about some subjects. You should feel safe at all times.

Drive the meeting towards your goals, whatever they might be. Make specific questions, and repeat them if the answer wasn’t clear or satisfactory.

Remember that the coach won’t solve the issue at hand; they can, at most, provide some of their own previous experiences or guidelines for you to solve it.

If you feel like it, request a follow-up session a few months later.

It’s OK to stop a coaching session before the scheduled end of the meeting if it’s not going in the direction you expected or if all your topics have been addressed.

Above all, be kind to the coach. We’re human after all.

49.4. Tips for Coaches

Above all, be kind to the coachee. We’re human after all.

Show empathy. Mean it. Expect to learn.

You’ve been approached for a reason. Your attitude can make or break the meeting. Make it worthy.

If possible, meet in confidential space somewhere outside the office, like a park or a café. A change of scenery can be of great help. But make sure for the environment to be confidential for the coachee to be able to open up.

Remember the 80–20 rule: only speak 20%, and listen 80% of the time.

Listen carefully; leave your smartphone and your laptop in your desk, and pay attention to what you’re being told. Take notes if that can help.

Focus on the issue at hand; particularly if you work closely with the other person, don’t let the day-to-day routine into the meeting. Concentrate your efforts in the person and the problem at hand.

Treat any information shared by the coachee with confidentiality and respect.

Have a bit of thick skin. Some of the feedback from the coachee you’ll get might be negative, but understand the context and request for more information if needed.

Open the door to a follow-up session a few months later.

If required, and if the coachee agrees, get in touch with PeopleOps after the coaching session.

50. Team retrospectives

Team retrospectives, or "retros" for short, are a tool for recurring group reflection to learn and improve as much as possible. Most teams have monthly retrospectives planned. Topics in scope can be anything from work contents, tooling, collaboration, education, etc.

50.1. Requirements

Effective retrospectives require that:

VSHNeers feel in a safe environment for feedback and discussion to open up.

There’s a plan for advancing the discussion from facts to conclusions

50.2. Safe environment

We recommend retrospectives to have an impartial moderator. If participants feel that the moderator has a stake in the conversation, they may feel as though it’s not safe to voice dissent or share concerns.

Not only are emotions allowed in retrospectives, but they should also be encouraged.

When possible, all parties should be present.

Prepare asynchronously for the retro, write down items for the next retro as you notice them, for example in your private wiki space.

When necessary, meet people face to face.

50.3. Plan

Introduction: reminder about scope and purpose of this retrospective.

Gather data: collect facts from attendees. There are different formats like "what went well/what can we do better," "start/stop/continue," "start/stop/continue/more/less," "mad/sad/glad," "liked/learnt/lacked," etc. We use tools like Miro or RetroTool as support.

Generate insights: group, deduplicate and discuss the facts. Identify patterns or causal relationships.

Decide what to do: Vote on the most important issues that should be addressed now. Discuss action items to address these issues.

Closing: Make sure all of the action items are appropriately assigned to one or more team members with clear expectations for when they should be completed. Thank all participants, and review insights and outcomes.

50.4. Followup

Follow up with the action items in the team weekly to create accountability for their progress.

51. Personal Education

We offer a budget to every VSHNeer for personal education because we believe that well-educated VSHNeers can provide the best services for VSHN and VSHN’s customers. Learning is life-long work, as new technology, processes and methodologies appear all the time and must be learned.

There are two different types of personal education, each of which has its own set of rules.

51.1. Individual Education

If a VSHNeer wants to learn a new subject for personal growth and interest, the following applies:

Budget: 5 days and CHF 4000.00 per calendar year per VSHNeer.

The amount isn’t cumulative (doesn’t sum-up if not used).

If an education spans across more than one year, the budget can be used over multiple years for the same education.

There is no deduction in this budget for VSHNeers working part-time.

If a VSHNeer quits during the calendar year, a pro-rata payback is asked by VSHN depending on the already used budget.

There is a pro-rata deduction of the available budget, depending on the start date of the working contract with VSHN (applies to the first year).

The education must have a tangible and visible benefit for VSHN to be considered, see below.

VSHN sees the personal education budget as an investment in the personal development of our VSHNeers. Therefore, you can use your education budget already during your probation period, while you are no longer entitled to it during the notice period, should you decide to leave VSHN one day. If a VSHNeer has already made a request for Individual Budget, PeopleOps will evaluate whether it will still be paid. This decision will be based on how the education can still benefit VSHN.

What qualifies as Individual Education?

Category
Description
Format & Constraints
Decision

Professional, role-specific further training

Technical or otherwise role-specific education, that helps the VSHNeer or their Team to better fulfil their responsibilities.

Technology, product or other specific trainings and courses, online or in-person.

Benefit for the role or for the team needs to be understood in the team.

VSHNeer gets consent in the team (often based on a skill matrix or similar), then People Ops checks via the Team’s Team Facilitator / Scrum Master.

Personal Coaching

Coaching the helps the VSHNeer do develop personally, as a VSHNeer and in their role.

Coach has to be a professional and certified (SCA or equivalent) coach, work psychologist.

Usually 1-on-1 sessions with a professional coach, booked by People Operations or the VSHNeer.

The Coach is usually selected by the VSHNeer, People Operations can help to find one.

Limited 2 session of 1.5h per month and up to CHF 300/h.

People Operations makes a confidential assessment of whether external support is necessary or if other solutions are accessible.

Role relevant soft skills & personal development

VSHN’s work culture demands significantly more from each individual in terms of self-responsibility, leadership skills, emotional intelligence, communication, conflict handling, etc. These skills and qualities can be learned and trained and will greatly help VSHNeers and the VSHN system and practices to work.

Usually courses and trainings in these topics, intervision, workshops, group coaching

Specific meetups on these topics.

PeopleOps checks based on feedback from peers of the VSHNeers, whether they would see it as helpful.

Conferences and Meetups

Just going to conferences or meetups (including those organized by VSHN) alone is not education (nor work time) - same as above, we have to understand if there is a “good chance” to learn something relevant or build up the network of “experts”. Benefit in the role or for the team needed - topic should directly be role or team relevant (technical, methods / practices or soft skills).

Out of Scope

Attending conferences or meetups as speaker (as VSHN). That is normal work with a clear goal, normal expenses rules apply.

Networking to create (customer) leads as decided in marketing, sales or as community measures. That is normal work with a clear goal, normal expenses rules apply.

51.2. How to request individual education

Talk to your Team about the subject, time frame, and cost of the education. The team gives a preliminary approval, required for PeopleOps to take a final decision.

Write an E-Mail to PeopleOps with the following information:

Description of the education

Required budget (money and time)

Purpose

Brief description of the benefits for VSHN based on the categories on this handbook page

Dates and time

PeopleOps will confirm the approval and will consider the budget and applicability.

PeopleOps takes a final decision (go / no go) and communicates it to the interested parties.

There might be a waiting list, based on budget usage across all VSHNeers - usually not an issue.

If the decision is positive, enjoy the training and learn a lot!

51.3. VSHN Requested Education

When there is a business need to get VSHNeers trained for some new technology or skill, the following applies:

VSHN pays the course fee and grants the time needed for the course (excl. for example individual learning).

VSHN may require a contractual employment commitment for two years, (to be decided on a case-by-case basis, depending on the type of education) starting at the end of the education.

If the VSHNeer leaves earlier, a pro-rata pay-back (on the money, not in time) will be requested.

Possible reasons which can lead to the business to request certain education paths:

Education and certification for partnership levels.

Education out of VSHN’s (strategic) need, missing needed skills.

Training required within the teams/job description (for example: CKA, AWS, and S3 courses)

This is tracked and reviewed as VIP-141

52. VSHN HackDay

The VSHN HackDay is a two-day event for all VSHNeers to hack on cool stuff. It will be organized irregularly and usually takes place on a Thursday and Friday. The event is open to all VSHNeers who are interested to break out of the daily business and work on cool and fun stuff.

This doesn’t only apply to technical work, that could also be to work on processes / things which someone wanted to do for a long time. Or even make part of the VSHN office a little bit better or different.

52.1. Before the event

Before the event takes place, ideas are collect in our Forum. Every VSHNeer can post ideas there which could attract other VSHNeers to take part and discuss the idea. Ideas should have to do something with VSHN, in any form.

Please only one idea per topic. Just open a new topic for new ideas.

A registration for the event is needed so that we know who takes part and we can organize accordingly. Please check with your team for work planning in scheduling in advance.

Daily business has to be kept up, for the most important services (operations, on-call). Teams have to plan for that in advance. Unfortunately that could mean that not every VSHNeer is able to participate in the HackDay (no worries, there will be a next event).

52.2. The event itself

The event takes place offline in one of the VSHN offices. It will last for two days (usually Thursday and Friday).

Odoo attendance for these days can be logged with at most 8 hours.

We’ll have Lunch together, organized by the HackDay orga team.

52.3. Course of the event

A few days before the event

Pick an idea you’re interested in from the Forum. If there is no idea yet in which you’re interested to work on, you’re free to propose a new idea or ask around. Add the idea (if it isn’t there yet) and your name to the table in the wiki (link to be sent in the attendee info email). This way groups can be formed already before the event.

At the beginning of the event

We’ll meet at 10:00 in person to kick-off the event with an introduction and a run-through of the event.

During the event

Groups organize themselves to work on the ideas. Socializing with other groups can happen all the time, however they fit.

Conclusion of the event

On the second day of the event at 16:00 local time, all groups come together in their respective offices, and each group presents the outcome (max. 5 minutes) of the work done during the HackDay. Votes are done with Mentimeter once all presentations are done. Each participant has one vote. The idea / group with the most votes wins a prize (CHF 500.00 per group to spend in Swibeco in Switzerland, CAD 100.00 in Canada) and glory and honor 🎉.

This page is part of VIP-85

53. Licensing Guidelines

By default we use the "BSD 3-Clause License" for all software we produce. Alternatively, should it better fit the ecosystem, the "Apache License 2.0" can be used instead.

53.1. BSD 3-Clause License

How to apply the license?

Add a file to the root of the project called LICENSE with the following content (replace <YEAR> with current year):

BSD 3-Clause License

Copyright (c) <YEAR>, VSHN AG, info@vshn.ch
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived from
   this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

What’s all this about?

You can do whatever you want with BSD-licensed code as long as you give the original author credit. Specifically:

Don’t remove their name from the code, and don’t claim that you wrote it.

Let others know you’re using code you didn’t write.

Don’t use the author’s name when advertising your own product.

Other than that, you can do whatever you like as long as you don’t sue the original authors. In particular, in sharp contrast with the General Public License, you most notably don’t have to:

Provide other people’s code together with yours.

License your own code as open source.

Provide your own changes to their code.

Breakdown

License text taken from Wikipedia.

Copyright (c) <YEAR>, VSHN AG, info@vshn.ch

Standard copyright line.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met

You can do basically whatever you want with the code, as long as you do the following.

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer

Don’t remove the license text from the original source code.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution

Include the license text when distributing a compiled version. This can be in an installer, manual, settings screen, or anything the user has access to. You don’t have to provide the source code.

Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission

Don’t use the name of the authors or organization when advertising products made using it.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

You can’t sue the original authors if their code causes problems.

Conclusion

The 3-clause BSD license is one of the most liberal licenses. All it asks is that you leave the license alone. This means you can’t claim that you wrote the original code, and you can’t change its license.

The key part is the line after the copyright line and before the list of conditions. The BSD license only requires that you give credit where credit is due. It doesn’t ask for anything else.

53.2. Apache License 2.0

How to apply the license?

Add a file to the root of the project called LICENSE with the following content (replace <YEAR> with the current year):

                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright <YEAR>, VSHN AG, info@vshn.ch

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

53.3. Server Side Public License (SSPL)

The Server Side Public License (SSPL) is a very strong copyleft source-available software license introduced by MongoDB Inc. in 2018.

~ Wikipedia

We use certain software which is licensed under the Server Side Public License (SSPL). We think that’s OK for us, and we don’t violate the terms of the license, mainly because everything we do is Open Source and also because we’re using the software as part of a solution, not directly offering it as an individual service.

Internally, this is discussed and documented in VINT-2303 and the Products Workgroup meeting notes.

53.4. About the <YEAR>

The year indicates the date of creation of the software under protection. From this date, the copyright protection stays valid for 70 years.

Ideally, one should always specify the year in which the software to protect was created or last updated. But if you are mistaken by a few years, it’s not a big deal, because the 70 year protection period is valid for an eternity anyway.

54. Working with Contractors

If there is a need to involve contractors, we define the following simple rules:

54.1. Contractors working for VSHN

Contractors which are working directly for VSHN, where the work isn’t directly billed to customers, needs budget approval from management.

Examples:

A contractor which develops something for VSHN

A contractor which supports VSHN when there is a personnel shortage

54.2. Contractors working for VSHN customers

When a contractor works for a VSHN customer in VSHN’s name (subcontractor) and the work is directly paid by the customer, then it’s up to the team (domain accountable) to decide.

In general, we try to avoid this and want to do as much ourselves to preserve knowledge and keep the money at VSHN.

This domain is tracked and reviewed as VIP-161

55. Swiss VSHNeers working and living in Canada

To train the VSHNeers employed in Canada in the VSHN way and what it means to be VSHNary, we want to have VSHNeers from Switzerland working in Vancouver, Canada. This temporary work opportunity can last between 2 and 5 months. Furthermore, by having experienced engineers on-site allows us to efficiently handle maintenance tasks, incident management and customer support during Canadian office hours. The ultimate goal is to allow your co-workers to have a more relaxed life by taking over nighttime work.

55.1. Job and responsibilities

for Swiss VSHNeers in Canada:

Train local VSHNeers for operations and other tasks required by the teams

Handle maintenance, operations and support during VSHN Canada Office hours

Represent VSHN at meetups and other recruiting events

Participate in recruiting, especially 1st & 2nd meetings with potential new hires for VSHN Canada

Assist to improve processes and tools to work across multiple time zones

Actively collaborate with VSHNeers in Switzerland - Meetings can start as early as 7 AM.

55.2. Requirements

Experienced engineers (at least 1 year with VSHN) who can take over maintenance and troubleshooting without support from Switzerland

On-Call onboarding successfully completed

Commitment to mentor and teach VSHNeers

Team agreement

Willingness to take on additional tasks relevant to VSHN Canada

55.3. Transition to Working in Canada

To ensure a successful transition to working in Canada, several steps must be taken.

Apply to work in Canada

Follow this process to apply for work in Canada:

Put your name down in the wiki and inform PeopleOps and VSHN Canada

Approximately 3-6 months before the next available slot, VSHN Canada will organize an online meeting with all applicants and PeopleOps to discuss the timeline and applicants.

Obtain approval from your team to be abroad during the planned timeframe.

Approximately 3 months prior to relocating to Canada:

Reorganize your on-call shifts.

Ensure your travel documents are valid and will not expire for at least 6 months beyond your planned stay.

Ensure you have medical and accident coverage in Canada.

Check with PeopleOps to get your intra company transfer work permit.

If your stay is longer than 90 days, fill out and hand in the tax withholding exemption form. PeopleOps and VSHN Canada can help you here.

Ensure you read your Worker Rights in Canada.

Before your departure to Canada:

Make sure all the relevant meetings within your teams are scheduled so you are able to attend.

Complete all the steps from Working from Abroad.

55.4. Expenses and travel

Working from Canada is an experience offered by VSHN. We pay for your travels within the limits of our rules for expenses.

TL;DR: You can book a flight and expense the following if not instructed otherwise by PeopleOps:

A return flight to Zurich Airport, direct or on a reasonably priced route to Vancouver Airport in economy class including seat reservations in exit rows. Upgrades to Premium Economy, business or higher have to be paid by the VSHNeers themself.

Travel from and to the Airport can be expensed under the following rules:

Use public transportation (except if the flight lands unplanned after the last or before the first train, then a taxi is ok)

From the airport to the office or an equal fare to another place

For each trip to or from Vancouver paid for by VSHN, the VSHNeer can record 8 hours of working time per way in his time sheet.

In addition, VSHN covers the cost of your accommodation while you are assigned to the Vancouver office. As a result of your temporary work location change, you will not be entitled to any additional compensation, such as lunch or overnight pay.

For VSHNeers not employed in Canada and providing OnCall as part of their daily job or while being still part of one of the Swiss rotations, costs for mobile internet can be expenses. We reimburse per 30 days up to 30 CHF (~44 CAD) for mobile internet in Canada. Before traveling to Canada, the VSHNeer has to inform PeopleOps in Switzerland and also get the agreement from VSHN Canada. As with all expenses, a receipt (for example phone bill) has to be handed in to be reimbursed.

56. VSHNeers Flat in Vancouver, BC

VSHN offers a shared apartment for the two VSHN Switzerland engineers working in Canada. The apartment is located in downtown Vancouver and accommodates two VSHN team members. The apartment complex provides amenities such as a gym, whirlpool, outdoor swimming pool, bike storage, and a concierge service.

712 - 777 Richards Street
Vancouver, BC, V6B 0M6

VSHN provides the furniture, kitchenware and other items necessary for living. Food and other consumables have to be provided by the VSHNeers themselves.

56.1. House Rules

VSHNeers communicate with each other. If there is a problem or uncertainty, talk to the others.

VSHNeers treat each other and their belongings with respect and consideration.

If one or more occupants want to have quiet times, that is to be respected.

VSHNeers are considerate of the living spaces. One takes care of the common areas and cleans them after use.

Split chores equally (Recycling, garbage disposal, shopping etc.)

Respect the rules of the building (No pets allowed, no bikes in the apartment, no smoking in the apartment or on the balcony, opening hours of building amenities)

Respect your neighbors. No noise late at night or early in the morning.

Guests are only allowed after the consent of the other occupants. For guests staying longer than 3 days, the consent of VSHN Canada is also needed.

56.2. Processes

Change of occupants

When new VSHNeers move into the Vancouver flat the following things have to happen:

The outgoing VSHN engineer should clean their room and wash their bed sheets and towels, as well as fold and prepare them on the bed for the next engineer.

Inform the landlord about the change in occupancy

Add new occupant to WhatsApp group chat with the landlord

Fill out form K with the concierge and pay the fee

Reporting Issues

If any issues with the apartment arise (for example leaking faucets, malfunctioning heating, damages, etc.), inform both VSHN Canada and the landlord immediately. In case of emergencies, such as burst pipes, also notify the concierge.

57. Working at the Vancouver office

As we are establishing a new team in Vancouver, we expect VSHNeers to work partially in the Vancouver office and are free to choose to work remotely the rest of the time.

57.1. Office

The Vancouver office is co-located in the Network Hub, with our own private office space on the 3rd floor. There are 4 floating work desks with room for a fifth.

VSHN Canada - The DevOps Company Inc.
422 Richards Street, Suite 170
Vancouver, BC, V6B 2Z4

Meeting rooms

We have 10 hours per month of access to the meeting rooms at the Network Hub.

57.2. Security Information

The Network Hub 3rd floor is only accessible with keys. The front door on the 3rd floor locks automatically and the office door has to be locked every time no one is in the office.

The office is secured with an alarm system. Make sure to disarm it when entering and arm it before you leave outside of office hours. Ensure that no other tenant is in the office before arming the alarm system.

The front desk is staffed on workdays from 09:00 AM till 05:00 PM. The main entrance door has to be locked after 08:00 PM. VSHNeers with keys can access the office at any time.

57.3. Desk sharing

All desks in the VSHN Vancouver office are free to use for everyone. There are currently more desks than VSHNeers in Vancouver, it is ok to have your customary desk but you are not entitled to it and others are free to use your space if needed.

All desks are equipped with a widescreen monitor and USB-C cable. Mice, keyboards, and headsets are considered personal items.

For desk usage, we adhere to the same rules as the VSHN Zurich:

Maintain a clean desk, especially if you don’t plan to use it the following day.

Avoid altering the infrastructure. If any changes are made, please restore the original setup: both monitors connected, power and network cables plugged into the dock, and the dock’s Thunderbolt cable ready for the next user.

Every VSHNeer has one or more boxes to store personal belongings, take the box(es) with you or store them in a shelf.

57.4. Meetings

We plan and schedule meetings, workshops, retros, etc. - basically everything that involves discussions - as video calls so everyone can join from anywhere. We always try to prefer digital collaboration tooling over things like flipchart, whiteboard, etc. so that everyone has the same experience and context.

Exceptions

All invited people agreed in advance to be at the office, then a meeting can be held in a physical meeting room, using any tools available there.

Customer and partner meetings, where we focus on what works best for the other party.

58. Visiting Headquaters from abroad

With VSHN allowing people to work from all over the world, we see each other mostly on our screens via Zoom. However, we believe that in-person meetings can enhance communication and collaboration. VSHN hosts events like the VSHN Connect, where we encourage all team members to meet face-to-face.

58.1. Foreigner work in CH without work permit

For non-Swiss citizens employed abroad, there is a limit of 8 days per calendar year working in Switzerland without a work permit[1].

Up to 8 days per calendar year

Up to 90 days per calendar year

More than 90 days per calendar year

Secondment

No permit required

Notification

Work Permit

Local Contract

No permit required

Work Permit

Work Permit

If a work permit or notification is needed, please contact PeopleOps for the next steps.

58.2. Travel and expenses

If VSHN requests your attendance at an event in a country different from your place of work, the normal expense rules for travel apply.

TL;DR:

Reasonable transportation with public transport to Zurich. Please let the travel plans be approved by PeopleOps or Management before booking.

Mid-level accommodation in hotels or preferably in short-term rentals booked by PeopleOps. An alternative is accommodation at private places of friends, family, and similar. This can be expensed up to 60.00 CHF. The duration the accommodation is paid is defined by the company’s needs and whomever invited you.

Per day maximum food allowance, if not included or otherwise paid by the company of

Breakfast 15.00 CHF

Lunch 20.00 CHF

Dinner 30.00 CHF

Travel

Before traveling to Switzerland - please ensure the following points:

For non-Swiss citizens

Ensure that your travel documents do not expire for at least 6 months beyond your planned stay.

Ensure that you do not work for more than 8 days in the current calendar year in Switzerland.

Ensure your health insurance covers the trip to Switzerland.

¹ Source Page 85 files.vshn.net/index.php/f/630929

59. Collaboration with VSHN Canada

With VIP-24 VSHN has decided to implement a follow-the-sun concept to cover 24/7 operations for our customer business, to reduce the burden of working outside regular office hours. Now that VSHN Canada is up and running, we want to make the most out of it. We are already doing night maintenance for all non CH-only customers and taking over 1st level OnCall during Vancouver office hours. This approach has significantly reduced the amount of nighttime work required in Switzerland.

To further increase the benefits of VSHN Canada, VSHNeers in Switzerland can hand over work to Canada. This can be work that has to be done during nighttime, like the rollout of changes or just regular work that is handed over because there is no capacity within the teams in Switzerland. A few examples of work that could be suitable for handing over to Canada:

Increasing PV size of xyz on cluster xyz (Ops)

Improve the Rocket deployment to get it HA (AppOps)

Refactor Terraform to meet requirements xyz (Engineering)

Find solution to automate xyz for customer xyz (Solution Design)

Plan and do upgrades to version x for all xyz instances (Projects)

For maintenance tasks, follow the Maintenance Procedure. To hand over any other work, follow these steps:

Assign ticket to team "Vega"

Remove assignee from ticket

Your ticket will be triaged by Vega and planned into future sprints

For this to work a couple of rules must be followed:

Make sure the ticket is properly refined

Task deliverables must be clear

Due date must be set

All teams can hand over tickets to Canada

If your task is urgent and needs to be handled on short notice, directly contact a member of Team Vega.

60. Apprenticeships at VSHN

An apprentice is more than just an employee because, in addition to attending vocational school ("Berufsschule" in Switzerland), we are responsible for providing practical vocational training. To prepare for their future work life, an apprentice should become a full member of a suitable technical team at VSHN and work within the team’s normal workflow as soon as possible. However, we cannot expect them to learn everything on their own like experienced IT employees. An apprentice requires guidance, daily support, education, and exposure to appropriate work based on their personal development level and the official educational plan of the apprenticeship. As an apprenticing company, we also have legal and administrative requirements to fulfill. Moreover, the apprentice needs clear go-to persons and often requires daily support in various matters, as well as escalation options if one person is unable to provide the necessary assistance.

It is essential to organize this process properly and regularly review and adapt it to ensure a successful completion of the apprenticeship.

60.1. Organization of current apprenticeships

Apprentice
Official Job description
Current Team
Responsible Roles

Finn Schunk

Betriebsinformatiker:in mit eidgenössischem Fähigkeitszeugnis (EFZ)

Canopus

Apprentice Owner (Sabrina Lang)
Administration and overall responsibility for the apprenticeship, coordinating and reviewing other involved roles

Apprentice Professional Education
Planning, review and support of work according to official education plan

Apprentice Technical Mentor (Daniel Hauswirth)
Daily go-to person

Internal Documentation

All the internal documentation, work assignments, etc. happens in the wiki here and with actual tasks in our Jira.

60.2. Planned apprenticeships

Currently, we’re not looking to have additional apprentices.

This is tracked and reviewed as part of VIP-218

61. VSHN

This page describes the overall Domain of VSHN, what we are, why we exist, what we offer and much more. It also gives you an overview of all other Domains within VSHN, our organizational structure.

61.1. Organization Canvas

Source: The S3 Organization Canvas.

This domain is tracked and reviewed as VIP-30

62. Vision of VSHN

We standardize and automate Cloud Native software operations, so that we can focus on helping you to operate your application.

~ VSHN Vision

We strongly believe that standardization and automation helps our customers to gain more time to focus on developing software, rather than doing the same work over and over again. By investing in our tooling to be able to provide standardized and automated Cloud Native software operations, we can focus more on helping our customers to operate their application. Engineering of standardized and automated Cloud Native software operations is something we have to invest into.

Standardization

We have a well-defined and maintained amount of building blocks to build the perfect Cloud Native environment for our customers' software.

Automation

By automating recurring tasks we can gain more time to work on tasks which aren’t easy to automate. Automation also helps in improving quality, less manual steps makes it harder for human error.

Software Operations

The Cloud Native environment needed so that a software is able to function continuosly.

Focus

Putting focus on the operations part is the main part of our vision. We want to emphasize that the customers' software is in the center of what we do.

Helping you to operate your application

Operating the customers' application isn’t something we can do alone. We have to do it together. Therefore, we emphasize "helping you" which means that we want to help, but can not take over the full responsibility.

63. Key Drivers of VSHN

Our top three drivers which we respond to. Each driver contains the actor, their needs and the context.

63.1. Companies that need to run software

Companies need to run their software. Their business is directly impacted if the software doesn’t work properly or can’t be easily updated. If running software is not a company’s core business, it can seem like a necessary evil to run it. The number of possible solutions can feel overwhelming. In our ever-changing and complex world, companies need to constantly adapt to stay alive. Often companies prefer not to change anything with their system once it is running because there is no time or expertise, or it seems like too much could go wrong.

These companies continuously need help to run their software and to choose the most appropriate technologies, tools, and processes to run software. And they want help from people who know what they are doing from experience, so that they can focus on their core business.

63.2. Software developers and system engineers

Software developers and system engineers need to do recurring tasks to get something done (for example to deliver products) or provide new services. Typically, they use manual processes that cause delays, are error-prone, don’t scale, create useless effort, and are typically boring work.

They want to have best-practice, standardized services, well-designed processes and automate as much as possible, so that mistakes are avoided, their work can scale, and they can focus on what really matters for their core tasks.

63.3. VSHNeers are VSHN

We spend much of our lives at work, and we believe our jobs should be lovable. What this means in practice might be different for everyone, but usually seeing what we do and why, working in a supportive environment, and being valued for what we do is key. Without this, the best people become unmotivated, unproductive or unhappy quickly.

We believe VSHNeers are what makes VSHN a lovable place to work.

VSHN needs to be a working environment which we all directly influence and evolve, so that we can adapt to the ever-changing needs of our business, make VSHN a great place to work, and attract and retain the best people for our ongoing journey.

64. VSHN Key Drivers FAQs

64.1. Why infrastructure and platform isn’t part of our key drivers?

Exclusively providing infrastructure services without a focus on the customers' application isn’t seen as the core business for us anymore, it doesn’t provide the unique value it has once been. Kubernetes is becoming a commodity and is available nearly everywhere, we don’t want to compete in this area.

We believe we can provide a better unique value to customers by helping them to achieve their business objectives. We believe the majority of our customers' business objectives are not "having Kubernetes" but "using Kubernetes to run their application". Therefore, we want to focus on what our customers are doing with Kubernetes, not on the fact that they need Kubernetes or that we want to standardize on doing it on Kubernetes.

We want to help to find a matching hosting environment, be that Kubernetes, cloud services or both, and take responsibility running it in the best possible and integrated way, with all other components needed to run their software. Running our customers' software is our "entry point". We want to work with our customers because they need to run their software, not because they require a Kubernetes cluster or cloud services.

For over two years, we have had practically no requests for managed servers. Our customers require databases, caches or a search engine and want to run their software. If a customer wants to do this directly on managed servers, then it is our job to explain why this is no longer technologically and economically appropriate in most cases.

65. Key Deliverables

What we provide to meet our key drivers. We describe the top three deliverables here.

65.1. Transition to Cloud Native Software Operations

We help organizations to transition to a modern way of continuous cloud native software operations in the form of hands-on engineering and consulting, using best practice processes and tools, and standardized building blocks.

In practice, that means:

Cloud architecture engineering and optimization, tailored to VSHNs expertise and matching cloud services to run the software the best way possible

Software hosting environment modernization for Cloud Native readiness (for example migrating from VSHN Managed Services to Cloud Native software operations or help to transition to the Cloud)

Architecture engineering, onboarding, customization and training for VSHN products

Helping with software packaging (Containerizing)

CI/CD pipeline engineering for automating tasks (build, test, deploy)

Data protection and business continuity concepts

Security architecture engineering

Developer tooling for fast development cycles (for example DevSpace or Tilt)

65.2. Continuous Cloud Native Software Operations

We work together with companies to take ownership of proactive operations for their cloud native software 24x7, using automated processes and standardized services and tools, while constantly looking for better and more reasonable ways to improve.

In practice, that means:

Standardized building blocks for Cloud Native software operations and development

Custom software monitoring, alerting and incident handling with shared operations run-books

Continuous CI/CD pipeline improvements with evolving best-practices and blueprints

Being reachable for hands-on support 24x7 (Support Plans)

Ensuring 24x7 operations with Service Level Agreement

Managed development environment (Cloud hosted or local tooling)

Managed DevOps Tooling (private code hosting or CI/CD pipeline tooling, for example GitLab)

65.3. Investment in our Organization

We invest in holistically shaping and evolving our organization together, in an enabling working environment and in personal development of our VSHNeers.

In practice, that means:

Defining, delegating and reviewing Domains to make purpose, responsibilities and boundaries clear, enabling people to create value in the way that works most effectively for them

Practicing the principle of Consent to shift power to influence from any specific individual or group, to reasoned arguments

Transparent communication and public documentation until there is a reason for confidentiality (for example no secret meetings, public handbook)

Support to work whenever and wherever VSHNeers can be most effective and happy

Internal and external facilitation support, coaching and mentoring for teams, roles and individuals

Education for modern leadership skills

Modern compensation model for VSHNeers, not limited to salary

66. Customer Segments

Our ideal customers, related to the actors mentioned in our key drivers.

66.1. Revenue through Online Application

A company which makes their revenue through their own online application, either self-developed or developed for them.

It can be any online application where revenue is generated by the service offered through it. For example, an e-commerce application, where the main revenue is generated by selling items online, an online service with paid premium add-ons, or an online software which is key for the main business. We specifically want customers with custom software, which is either developed by their own developers, or by a software development agency, so that we can directly work with developers to improve their experience and influence application development to support our best-practices of software operations.

66.2. Instances at Scale and SaaS

A company which needs multiple instances of a software for their business at scale.

It’s about companies which not only need one, but many instances automatically deployed, where it’s feasible to invest heavily in automation and self-service, using our expertise and building-blocks for doing application operations at scale. This can either be a software developed by or for them, or a software from a third-party vendor.

67. Unique Value Proposition

We’re not the only company providing 24x7 Cloud Native operations support for online businesses software developers. What do we think makes us unique?

We think we are the only company providing the above in combination with all of the following below:

Modern societies and especially online businesses run 24x7, so we’re available to support our customers 24x7 giving them peace of mind about their business-critical applications.

We support our customers on any Cloud Infrastructure, no matter on which vendor, private cloud or public cloud.

We believe all software needs to become Cloud Native and actively help our customers to become it.

We believe in openness, by using open standards and Open Source Software to do our work, by being transparent in collaboration, and honest in enforcing our values.

Collaborating actively and with personal contact, taking the time to understand our customers' technical and business needs to propose the best solution for them, and then taking the 24x7 operations responsibility for our solution.

68. Key Challenges

Important constraints or risks our organization is facing related to our Key Drivers, Customer Segments and Unique Value Proposition. In other words, this is about strategic risk: Internal or external events, changes and trends that threaten the survival of the organization.

68.1. Technology choice & keeping up

VSHN’s core technology

Open Source projects might be discontinued, dysfunctional, no longer a good fit for VSHN or becoming legacy technology.

New and extended standard Cloud Service Provider offerings

Cloud providers might start to offer similar service, quality and expertise, which could make our offerings questionable or obsolete for our customers.

68.2. Partner Choice

Software vendors providing core technology to VSHN or Cloud Service Providers might discontinue the product, make huge licensing or pricing adjustments, or change features and limitations that directly affect if and how we can keep using it.

68.3. Quality and stability of our service

Major outages of our services

If not handled properly it can make customers question the value we provide to them and the relationship as a whole. Especially when using Cloud Service Providers and Open Source technology, we are at the front with our customers, and even if we didn’t cause the incident, we are the ones responsible for resolving it.

Stability vs Bleeding edge technology

Keeping up with technology and stability doesn’t always go hand-in-hand, finding the right balance is tricky. If not done right, we’re the ones to blame.

Technical debt

Keeping up with technology often leads to an endless backlog of work, we might not be able to keep up. Wrong prioritization might lead to a stand-still or cause operational implications we can’t handle.

68.4. VSHNeers, and how we are organized

Downsides of our organization form

According to our Key Driver VSHNeers as VSHN, we want to be this special working environment, which also means that we need to always find people who want to play an active part in such an environment, and can cope with the added accountability for the course of the organization.

Missing Leadership

Things do not magically happen, missing leadership in a learning agile organization of mostly self-managing teams can mean that we don’t do what’s needed and waste time on everything else, becoming unaligned with our strategy, purpose and values.

Needed technology knowledge and experience

Covering all the needed technical knowledge 24x7 for a big set of technology and Cloud Service Providers can be overwhelming.

VSHNeers as our highest good

VSHNeers are our main and most important good, we don’t hold any patents or strategic business intelligence, licenses, or similar. Loosing good VSHNeers can, at least temporarily, seriously affect our ability to provide our services.

69. Company Alignment

Every business, including ours, must navigate the ever-changing market and uncertain world (VUCA: volatility, uncertainty, complexity and ambiguity) to find success and growth. It’s not enough to react; we need a shared understanding of our objectives (where we want to go as a business and organization) and the path to achieve them. Alignment is about having an internal compass in this volatile landscape. It anchors our self-managing teams to our overarching purpose and vision, preventing fragmentation and self-directed divergence. It assures every team and every VSHNeer understands their role, their part, in achieving our vision. In a small startup, daily conversations might suffice for alignment, but with 50+ people, we need a more systematic approach. We avoid rigid frameworks and classic command-and-control styles, yet we seek clarity in creating alignment, ensuring efficient and unified efforts towards our goals.

Alignment at VSHN can be seen as two tracks: our aligned Organizational Structure and the Agile Goal Setting track.

69.1. Aligned Organizational Structure

Having an Aligned Organizational Structure means, that teams and roles serve a higher purpose (company purpose). At VSHN this is done through Delegation that starts at the top (Board and Management Team) involving the teams in the needed decisions for this. This ensures that each of our teams has a long-term identity and purpose within the organization that is aligned. What exacly is needed depends heavily on Business Strategy clarified by the Strategist Role.

We organize our teams around business areas or value streams, taking into account technical considerations, product or service specific knowledge, etc. A team should be aligned as directly as possible to a value stream, meaning the are responsible and able to deliver services or products from producing assets, customer onboarding to continuous support and operations with only the minimal dependencies and interfaces. We also have supporting teams, like sales, marketing, customer account management, customer support, and internal operations (like HR and Corporate IT).

This so called "long-term identity" of each Team and also Role is defined and documented using a Domain Description Format, focusing on the delegated responsiblities, formulated in a result oriented way: what someone takes responsibility for, not the steps they need to do to achieve that.

Implicit and explicit roles within each team is a further level of delegation, and helps the team to clarify responsibilities and to fulfill their purpose.

See Domains of VSHN - Organizational Structure.

69.2. Agile Goal Setting

Objectivs and Key Results (OKRs)

The Strategist VSHNeers set the company-level OKRs in collaboration with the board, affected VSHNeers and subject-matter experts. They consider higher level strategic goals, current business and market situation. Each team then proposes their own Team Level OKRs that directly or indirectly contribute to the company level and their own long-term team purpose, for the next quarter.

Through the combination of structural alignment and agile goal setting, we ensure that our teams know what to focus on and prioritize, balancing their daily operational work with strategic development.

See Tracking OKRs.

Product Roadmap

We maintain customer-centric roadmaps for each defined product or product group. The roadmap is a list of products or features that should be produced next. The Product Roadmap is maintained by the Product Owner with inputs from various stakeholders like Product Managers, Customer Account Management, Sales and the Strategist Role.

For teams that own a product or product group with a roadmap, the roadmap is usually more specific than OKRs. The OKRs are more general, higher level than the roadmap - what future state do we want to reach, while features on the roadmap but also other work of the team contributes (at least indirectly) to reaching an OKR objective. This isn’t an either-or thing, it’s not roadmap vs OKRs, whatever works as orientention and alignment to the team, is the right way. In the end, a roadmap or OKRs are just tools to give tangible goals.

See Product Roadmap.

Objectives and Roadmap in Scrum

A good practice is that the Scrum Sprint Goals contribute to either the product roadmap or the Team OKRs, besides the day-to-day business that could also sometimes be Sprint Goals (like a customer’s project). The roadmap is aligend to Team or Company Level OKRs, but focuses on customer value. Not easy to find this balance.

If this connection is not visible to team members, it’s a sign of a lack of common alignment - we are no longer working towards common, higher objectives.

69.3. And where is Strategy in this?

There is not the one static plan, not one strategy. Strategy exists on different flight levels or levels of goal setting:

Those who have a (monetary) stake in VSHN (shareholders represented through the board), need to define:

What is the long term, hard to reach future picture of what VSHN does and why we exist - what is our motivation.

What is the mission: more concretely how we want to do it, but still quite high level. For example, do we want to produce products and managed services, do we want to rent engineers or do random engineering projects, etc.

What they want with and from VSHN in which time. Can be money, innovation, growth, etc. usually a combination.

Within VSHN, we need to translete those strategic goals into more tangible objectives (usually quarterly or yearly) - some sort of S.M.A.R.T. goals - we use OKRs (see above).

We also need to think about and come up with high level plans / initiatives how all the parts of VSHN can contribute to achieving those objectives. This is very close collaboration with the teams and subject-matter-experts.

From this, teams and roles in VSHN can have their more specific OKRs for the quarter.

In the teams or roles, they can then come up with plans / initatives / projects / epics how to reach their team / role level OKRs.

And that’s it: We see strategy is in between all this goal setting: * How do we want to come closer to our company vision * How we reach the strategic goals (business model) and changes in the business model. * How we reach the company level shorter-term goals * How we reach the team / role level goals

This is the proactive part. Strategy is also needed to address to strategic risks, respond to organisational challenges, personnel strategy, internal processes or structural changes, etc.

In it simplest form, a strategy is not more than a wiki page which points to a goal we want to reach or a opportunity / issue we want to address, and a few bullet points how we plan to do what.

70. VSHN Connect

70.1. Purpose

The purpose of VSHN Connect is to get everyone on board with the current direction of the company, share business information & updates, present & celebrate OKR cycle updates and discuss topics in open spaces as well as concluding with a social event.

We believe it’s crucial for everyone in an organization, especially in a business, to understand the big picture - what we do, why we do it, how we’re organized, and how we work, collaborate, decide, and behave. We strive to foster transparency on our Values, Vision, Business Model, Roadmaps, and OKRs, and by documenting and training on how VSHN operates. Despite these measures, achieving a common understanding can still be challenging, it’s still easy to miss decisions or reasons for what’s happening. This may be due to time constraints, the need to shift focus on high-level topics, or difficulties in applying these principles to their own contexts. It can also be tough to grasp the work and perspectives of other teams when focusing on your own work.

We have regular events that involve all VSHNeers, in person, at one location. These occasions focus on fostering a shared understanding of who we are, what we do, why we do it, and how we do things. By taking a break from our routine, coming together as a whole organization, independent of current team structures, we can generate a better common understanding. These events offer a platform to discuss topics that might otherwise be overlooked, brainstorm collectively, and socialize in person - a valuable opportunity, also to meet those who primarily work remotely in real life. This approach can strengthen our sense of unity and reinforce our identity as one company.

70.2. General

Our half day VSHN Connect event takes place quarterly, focusing on alignment and shared understanding.

It’s an opportunity for all VSHNeers to meet in person. We’re looking for a great location for this event and we expect every VSHNeer to attend. Customers will be informed 1–2 weeks in advance, that we will only handle incidents during this event. Teams must ensure a minimum workforce to handle incidents. As such, it may be necessary for some VSHNeers to intermittently work during the event.

If you can’t attend for private reasons (holidays etc.), that’s okay.

To ensure a great experience, the event is non-hybrid. People who usually work remotely attend in person according to VIP-42.

VSHN Canada will hold a similar event if possible and presentations etc. will be shared beforehand with VSHN CA. We aim to fly in VSHNeers from Canada at least once a year that they can also attend in person.

We’ll take notes and photos, and slides will be published internally. However, there won’t be recordings of talks or discussions.

VSHN Connect is considered work time (half day, 4 working hours, not more).

Lunchtime and social events, according to the agenda, are not work time.

The official social event is paid by VSHN. Travel expenses for people who are employed in VSHN Zurich are not covered (as with the normal work commute).

In alignment with our idea of Leadership and shared accountability, there is no default instance (like the Management Team) that drives the topics discovered during VSHN Connect open spaces forward. It’s up to whoever feels responsible or motivated to drive things forward. A summary is usually documented, though.

70.3. Planning

VSHN Connect typically falls on a Thursday to avoid impact from Maintenance Tuesday, and because Monday and Friday are perceived as not ideal by many VSHNeers.

People Operations plan logistics, with Management leading content planning.

Necessary announcements are made timely to allow Teams to plan their responsibilities around VSHN Connect.

Planning details can be found in our wiki for each VSHN Connect.

70.4. Format

VSHN Connect involves company and OKR updates, interactive work, presentations on focused topics, spontaneous discussions, and socializing. Team building activities and VSHNeer-proposed topics are encouraged, provided they align with the VSHN Connect’s scope.

70.5. Travel expenses

For VSHN Connect we want to bring all VSHNeers from all over the world together. Therefore the travel and accommodation for VSHNeers employed abroad are paid for by VSHN. In general inviting VSHNeers from abroad to Switzerland is handled like a business trip. Expenses are therefore paid according to our expense regulations.

As it would be very wasteful to bring people in just for a single day at VSHN Connect, we want people to use the time at our headquarters to our advantage by Improving the social team and company coherence with in-person meetings and activities. VSHNeers should use this time to work together in person with their teams and get to know the rest of VSHN. To ensure this happens, meetings and workdays must be planned by the incoming VSHNeers beforehand. VSHN pays 6 nights in total. Longer stays are paid by the VSHNeers - we suggest staying for the weekend before and after.

Other than that the normal travel expenses rules apply.

Notes: Accommodation is booked by PeopleOps VSHN Switzerland according to our Expenses rules favoring either a group accommodation via AirBnB or similar for all visiting VSHNeers that need accommodation.

VSHN Connect is tracked and reviewed as ticket.vshn.net/browse/VIP-316

71. Company values

This page gives an overview about what drives our work and is the content that forms the foundation of our Alignment Framework. Everything we do and think as a company is powered by these ideals.

71.1. Values

Values are the definition of VSHNaryness: how we behave and interact with each other as VSHNeers and as VSHN. The core of these values is that we don’t work for VSHN, but we all together are VSHN and make up what VSHN stands for. We trust each other to live our values and help each other be vigilant and grow personally.

We believe a company culture that everybody shares makes working together more fun and more successful. These values are the documented VSHN culture.

Many of these values are tools to foster trust, between both VSHN and VSHNeers, to create a high-trust environment and psychological safety for every VSHNeer. This trust is key for respect, recognition and freedom - all forms of esteem necessary to be able to reach the next levels of cognitive needs and self-actualization as per Maslow’s hierarchy of needs.

Positivity

We are optimists and think in solutions rather than problems.

Positive people are much more fun to work with than pessimists. Being optimistic also helps to think in solutions rather than in problems. Another aspect of positiveness is to be proud and celebrate achievements together.

Effectivity

We favor work that brings us closer to our goals.

We devote time only to what brings us closer to achieving our objectives. For this, it’s important to know our goals and objectives. This includes continuously reducing all forms of waste (time, resources, quality). It also means to think holistically, put the ego away and focusing on the benefit for the whole company and thus all VSHNeers. Effectively getting things done means for us to iteratively deliver value and using the feedback to improve in the next iteration.

Integrity

We are objective, communicate in a direct open fashion, give and accept constructive criticism.

Integrity means for us not only honesty and righteousness but also being respectful and constructive. This implies being open to criticism oneself and to openly, directly and constructively contribute to topics and correct behavior of others. Discussing organizational problems constructively means to reflect and voice Tensions or Drivers. Follow through on Agreements even if you don’t agree or like them as long as you don’t have a possible objection you can bring up. Try to remain calm, objective and matter of fact when discussing issues, don’t get emotionally involved, don’t blame others. Approach people you have issues with directly instead of talking behind their backs.

Curiosity

We are open to learn about new and innovative ways to achieve our goals.

We’re always open to new information and ways of addressing the challenges at hand. Experiment and continuously learn to develop yourself and our company. Actively help others to do so as well. We actively experiment to apply new knowledge accepting the risk of occasional failure as an opportunity to learn and do better next time.

Transparency

We document our work and share our knowledge.

We actively share our knowledge both internally and externally, be it in documentation (Open Source) or communication. We believe that collaborating with other experts over company borders produces win-win results.

We record all information that’s valuable for others and the organization, and make it accessible to everyone, unless there is a specific reason for confidentiality. Together with automation and standardization this helps us to be replaceable, which we strive for.

Accountability

We take ownership for what we say and produce.

We respond when something is needed and do what we agreed to do. We take ownership for the course of the organization. We’re dependable by taking ownership and reaching out actively if you need help to get the task done. Being accountable also means to take care of your primary job before contributing to other topics.

72. Tech Strategy

72.1. Main Technology Beliefs

Applications belong in containers by default.

All manual recurring effort is reduced as much as possible through automation.

72.2. Make or Buy

Whenever possible, we prefer to use services offered by the cloud service provider. This applies to Kubernetes, as well as any other services needed to provide the required infrastructure, like databases, caches, search index, queues, but also infrastructure building blocks like storage, shared file systems or load balancers.

Should the chosen infrastructure not provide the required services, we provide them on top of Kubernetes. If there is no way to run a service on Kubernetes, we can make an exception and run it directly on virtual machines.

If we also have to bring our own Kubernetes, we do that with Red Hat OpenShift.

72.3. Kubernetes First

We use Kubernetes to deploy workload, but it is also used as a common control plane for service provisioning and for container orchestration.

72.4. Service Providers

We don’t have our own Hardware but are deploying our services on top of already existing infrastructure.

Our primary area of expertise lies in automating service and infrastructure provisioning. In instances where more in-depth knowledge of a specific infrastructure is necessary, we collaborate with specialized partners to ensure comprehensive expertise in the required field.

These are the main service providers we work with:

Public Cloud

cloudscale.ch

Exoscale

Amazon AWS

Google Cloud

Microsoft Azure

Private Cloud

Swisscom (VMware based)

aspectra (VMware based)

72.5. Further Documents

In addition to this document, have a look at:

VSHN Corporate Technology > Production Operations

VSHN Corporate Technology > Engineering Manifesto

VSHN Corporate Technology > Product Architecture

73. Organizational Structure

73.1. The Domains of VSHN

VSHN’s organization is divided into Domains that are a specific area of influence, activity, and decision-making — in more traditional organizations, this would probably simply be called departments and teams.

More about this is described in Company Alignment.

Domains are delegated to groups of people (a Team) or to individuals as role keeper.

74. Brand Guide

This is the official brand guide for VSHN.

74.1. Logos

Our logo looks like an eye because VSHN is pronounced like "vision". The black parts on both sides are a reference to the angle brackets of HTML code, and the circle in the middle represents the earth.

Color

SVG
PNG (White background)
PNG (Transparent background)

Main

Square

No Text

Square, no text

White (Transparent Background)

SVG
PNG

Main

Square

No Text

Square no text

Download all logos in a single zip file: vshn_logos.zip.

74.2. Mascot

Our mascot is called VSHNbot and it likes to automate things.

Color

File

Normal

Animated (GIF)

Animated Wide (GIF)

White

File

Normal

Animated (GIF)

Animated Wide (GIF)

74.3. Color Codes

Onyx (logo)

rgb(68, 68, 68) or #444444. Example

Steel Blue (logo)

rgb(64, 129, 203) or #4081CB Example

Rich Black (titles, main text, background)

rgb(0, 13, 26) or #000D1A Example

Amber (buttons, illustrations)

rgb(255, 191, 0) or #FFBF00 Example

Capri (links, illustrations, indicators)

rgb(76, 195, 255) or #4CC3FF Example

74.4. Font

The official VSHN font is Montserrat, designed by Julieta Ulanovsky, Sol Matas, Juan Pablo del Peral, and Jacques Le Bailly.

Headers use Montserrat Bold with font weight 900.

Body text uses Montserrat Regular with font weight 400.

CSS

Include the Montserrat font in your projects using this command:

$ npm install typeface-montserrat

Make it available to your stylesheets as follows:

@font-face {
  font-family: "Montserrat";
  font-style: normal;
  font-weight: 400;
  src:
    local("Montserrat Regular"),
    local("Montserrat-Regular"),
    url(~typeface-montserrat/files/montserrat-latin-400.woff2) format("woff2"),
    url(~typeface-montserrat/files/montserrat-latin-400.woff) format("woff");
}

@font-face {
  font-family: "Montserrat";
  font-style: italic;
  font-weight: 400;
  src:
    local("Montserrat Italic"),
    local("Montserrat-Italic"),
    url(~typeface-montserrat/files/montserrat-latin-400italic.woff2) format("woff2"),
    url(~typeface-montserrat/files/montserrat-latin-400italic.woff) format("woff");
}

@font-face {
  font-family: "Montserrat";
  font-style: normal;
  font-weight: 900;
  src:
    local("Montserrat Bold"),
    local("Montserrat-Bold"),
    url(~typeface-montserrat/files/montserrat-latin-900.woff2) format("woff2"),
    url(~typeface-montserrat/files/montserrat-latin-900.woff) format("woff");
}

@font-face {
  font-family: "Montserrat";
  font-style: italic;
  font-weight: 900;
  src:
    local("Montserrat Bold Italic"),
    local("Montserrat-BoldItalic"),
    url(~typeface-montserrat/files/montserrat-latin-900italic.woff2) format("woff2"),
    url(~typeface-montserrat/files/montserrat-latin-900italic.woff) format("woff");
}

74.5. Desktop Wallpapers

You can find an assortment of wallpapers for your desktop in our Nextcloud under this direct link.

74.6. Virtual Backgrounds for Zoom

You can find and assortment of virtual Zoom backgrounds in our Nextcloud under this direct link.

74.7. Company Description

VSHN - The DevOps Company

VSHN automates the operation of applications in the cloud or on-premise, so that you as a software developer can have peace of mind and build your awesome application. VSHN is the Ops in DevOps.

Also see: www.vshn.ch/en/about/ and handbook.vshn.ch/values.html

75. VSHN Central

Welcome to VSHN Central - our ERP system based on Odoo (the Enterprise variant).

It is reachable under central.vshn.ch.

How a VSHNeer uses VSHN Central day-to-day is documented here - in our Handbook. Some related pages:

Time Off

Time Tracking

Pay Slips and Overtime

The recorded internal education introduces VSHN Central and provides basics about Odoo.

The technical documentation is available under docs.central.vshn.ch.

75.1. First Login

Step 1: Login with VSHN Account

Navigate to central.vshn.ch

Click on "(1)"

Click on "(2)"

Login with your VSHN Account

Step 2: Personalize your Profile

On the top right menu, click on your username and choose My Profile
first login 1

Edit the Email Signature and upload your profile picture
first login 2

To save, click on the save icon (1)
To dismiss the changes, click on the reset button (2)
first login 3

Step 3: Start using Odoo

To help you to get started, it’s recommended to watch this video:

Your Reading System does not support (this) video.

And if you’re keen to get to know a lot, take a look at the online courses in Odoo Learn.

75.2. Odoo API Access

Should a VSHNeer want access to the Odoo API, a local password has to be created (limitation of Odoo). Please inform CISO to get access. You’re required to enable 2FA and only use the local login to generate the API key. Normal login has to be made via VSHN Account.

76. Odoo 16 Tips and Tricks

This page contains tips and tricks to work with Odoo 16 aka the VSHN Central.

76.1. Open Search Menu

Chromium

Press slash (/)

Firefox

CTRL+K then slash (/)

76.2. Timesheet View

If you are interested to view your daily work logs including the description directly, as in the picture below, following steps should be done.

Go to Timesheet main menu.

Change to list view.

Choose 'Date' and then 'Day' at 'Group By'.

Choose 'Filters' and 'Add Custom Filter'.

Choose 'Task', 'is not equal to', and '[t3] Time Off'

With that you make sure your future time off do not appear in the time sheet view.

Add it as Favorite and use as default if you like the view.

76.3. Formatting

Use / for formatting in text boxes. /h1 will give you a heading 1.

76.4. Tasks / Tickets

You can relate your tickets to other tickets, see picture:

77. Domains

Domain: A distinct area of influence, activity, and decision-making within an organization.

77.1. What is a Domain

A team within an organization is formed because the organization requires specific tasks to be accomplished, decisions made, or products developed and delivered. This specific area of influence is defined by the organization through a domain description, which is then delegated to a group of people to form a team.

When this team identifies specific responsibilities that need to be explicitly addressed, they define a sub-domain and delegate it to a team member, creating a role.

In its most basic form, a domain description needs to articulate the team’s or role’s purpose. This purpose usually aligns with an organizational need that is essential for the organization’s functioning and business success.

It’s important to note that a team doesn’t simply exist because people group together. There needs to be a common purpose. If they have this shared purpose, they are already a team, even without a documented domain description. See What is a Team. However, documenting the delegation agreement makes it explicit, creates clarity and shared understanding, and enables us to evaluate and evolve a domain by reviewing its effectiveness.

Domains are not solely an invention of S3 or VSHN. They represent naming conventions and definitions. Essentially, it’s one of many ways to specify 'an area of influence'. What makes it special is that we make it explicit through the act of delegation and use it as the base to create, evaluate, and develop our teams and roles - making explicit what exists or should exist anyway.

This defines the concept of domains at VSHN, it doesn’t replace (self) education on the topic of domains. For that, please read Clarify and Develop Domains from the S3 Guide.

77.2. Creating and Delegating Domains

Understand why you want to define a domain - understand the Driver for it.

To brainstorm a domain, you can use a delegation canvas on a miro board. For example: this.

We create a VIP for every domain in Jira. In Jira, there is only the purpose - the reason we need to define and delegate a domain. The VIP links to miro boards, wiki pages, etc., where you prepare everything, and finally to the domain description.

Once an initial agreement is reached on the domain and to whom we delegate it, we create a page in our handbook as a sub-page of Organizational Structure. See the Template you should use, but be aware that what exactly you need to document varies.

Do not expect a role or team to simply function after the scope is defined. A team needs to be built, technically, but more importantly in terms of "Storming - Forming - Norming - Performing": working methods, working arrangements, standards, social aspects, group dynamics, planning and review rhythm, governance, continuous improvement, etc. Depending on the characters in the team, much of this can happen automatically over time, but it usually requires conscious effort.

The Delegator and Delegatee(s)

The Delegator is is the team or role that delegates ("assigns") a domain to an individual or a group of people, the Delegatees. Both are not a role on their own, both roles are implicitly there as long as the domain is delegated. There is no role or team without a Delegator.

Examples of Delegators:

The overall Domain of VSHN is delegated by the Board to VSHN, represented by the Management.

A Team’s Domain is delegated by the Management.

The Team Facilitator role in a Team is delegated to that person by the Team.

A Work Group or cross-team relevant role can also be created by people from different teams, because they need something, then they together could also be the Delegator (buttom-up delegation).

77.3. Reviewing Domains

A Domain is an area within the overall organization. What is done and produced in that domain, and the value delivered, needs to serve the purpose of the overall organization. People’s understanding of the organization is limited, and the environment is always changing. Therefore, it’s essential for the delegator of a domain and other relevant stakeholders to regularly check in with the delegatee(s). They should take the time to evaluate and evolve both the design of the domain and how people account for it as their understanding of the domain deepens. People might do a great job of accounting for a domain the way it’s designed, but the design of the domain might be primitive or flawed. Conversely, even if the design of a domain is poor in the first iteration, it will improve over time through this process.

Over time, we discovered that simply talking together isn’t enough. Aside from how clear and relevant the purpose of the domain still is, we need to closely examine certain aspects of a domain and team or role:

Assess the Key Deliverables: Are they being delivered as agreed? If not, why? What’s preventing them?

Examine the Key Responsibilities: Are they being adequately addressed? If not, why? What’s preventing them?

Evaluate the Team Level OKRs and their progress: Is progress in line with their OKRs? What is hindering progress?

Review the Fundamental Responsibilities: Are they being addressed good enough for now? If not, what changes are needed? What support does the team need from the organization? This includes the personnel situation of the team - do they have the people with the required mindsets and skills?

In the above, they refers to either the Team or the Rolekeeper, the Delegatee(s).

More on How we do Domain Reviews, here.

77.4. Domain Descriptions

The details we need to document are dependent on our agreements. The level of detail depends on what is needed to have a common understanding and to be able to review it. However, there is essential information that we see as needed to make a domain description useful.

Content Requirements

Delegator and the Delegatees: Who delegated it to whom.

Purpose: What purpose does this domain serve, why does it exist? Please use the 4 parts, 2 paragraph S3 Driver Summary format.

Key responsibilities: brief but clear enough. They have to be written in a way, the wording, that can be inspected during reviews. Don’t write what you do; write what you produce, what you deliver to your stakeholders, so that we can ask the stakeholders if that is the case, how well you do that, and what we should improve. This is not optional. If it proves ineffective during reviews, we will need to reword it.

Other points are optional, like: decision-making domains, roles, teams, processes, standards, documents, etc. What and how much to document depends on what the delegatees and delegators agree on.

Format Requirements

Be as brief as possible, as comprehensive as needed: The level of detail depends on who it needs to be clear for. This document is not an educational resource; it’s a definition. Education might be necessary in addition, and common understanding is typically fostered during the decision-making process when we delegate the domain or review it.

Link to VIP: Include a link at the bottom of the page to the VIP where we track the governance of this domain delegation.

Prefer bullet point lists over long-form text.

Favor searchable text over diagrams and pictures.

Template

While the following serves as a template we acknowledge that most domains are unique, what we need to document depends on what we need to agree on (see above). The format of domains is defined to give a unique reader experience in our handbook, but it might differ from domain to domain and over time, as we learn more how to better define domains. That’s fine, we don’t rework domains just to keep up with the format, until it is needed for clarity.

== Name of the Domain (for example: Domain Customer Support)
:description: brief description of the domain, why it does what.
:keywords: keyword1, keyword2

[cols="h,1"]
|===
|<<Accountable Team,Accountable>>|_TEAMNAME_ xref:vshn_teams.adoc[Team]
|Delegator|xref:domain_business_operations.adoc[Business Operations] (Management)
|Lead|Name of Person (xref:link_to_domain_of_role.adoc[Role Name])
|===

== Purpose

// tag::driver[]
Driver summary - this can be directly the driver from the VIP. But often it makes sense to write it in a more general, opportunity based way vs. writing it from a problem standpoint.
// end::driver[]

== Stakeholders

// tag::stakeholders[]
* *Stakeholder 1:* What they need.
* *Customer Segment 1:*  What they need.
* *The Delegator* of the Team: What they need.
// end::stakeholders[]

== Key Responsibilities

List 1::

* Do X to produce outcome Y
* ...

List 2::

* Do X to produce outcome Y
* ...

== Key Deliverables

* Product 1, definition or link to definition
* Service 1, description what we deliver
* Special kind of or what documentation
* ...

== Dependencies

* List of dependencies, add what they need from whom.
* ...

== Monitoring and Evaluation

* In which interval do we proactively review the domain.
* How do we review the domain periodically.
** Evaluation criteria.

== Other Section

Any other section that is helpful to create clarity, from the https://patterns.sociocracy30.org/clarify-and-develop-domains.html[Clarify and Develop Domains] or anything else.

== Accountable Team

NOTE: Optionally, a note on special agreements for who accounts for this domain.

Avior::

78. Domain Reviews

78.1. Summary

A Domain is an area within the overall organization. What is done and produced in that domain, and the value delivered, needs to serve the purpose of the overall organization. People’s understanding of the organization is limited, and the environment is always changing. Therefore, it’s essential for the delegator of a domain and other relevant stakeholders to regularly check in with the delegatee(s). They should take the time to evaluate and evolve both the design of the domain and how people account for it as their understanding of the domain deepens. People might do a great job of accounting for a domain the way it’s designed, but the design of the domain might be primitive or flawed. Conversely, even if the design of a domain is poor in the first iteration, it will improve over time through this process.

Over time, we discovered that simply talking together isn’t enough. Aside from how clear and relevant the purpose of the domain still is, we need to closely examine certain aspects of a domain and team or role:

Assess the Key Deliverables: Are they being delivered as agreed? If not, why? What’s preventing them?

Examine the Key Responsibilities: Are they being adequately addressed? If not, why? What’s preventing them?

Evaluate the Team Level OKRs and their progress: Is progress in line with their OKRs? What is hindering progress?

Review the Fundamental Responsibilities: Are they being addressed good enough for now? If not, what changes are needed? What support does the team need from the organization? This includes the personnel situation of the team - do they have the people with the required mindsets and skills?

In the above, they refers to either the Team or the Rolekeeper, the Delegatee(s).

78.2. Review the Team and their Domain

We’re still exploring the best ways to conduct Domain reviews. This is our current approach, which we aim to refine over time. Join us in this endeavor and help us improve with each iteration.

Who does what and how?

In our company culture, teams don’t report to management nor does management dictate their tasks. Consequently, the review of a team’s output, their processes, their challenges, and their needs can be initiated from any side—even by another team. It’s always a collaborative effort.

The Team understands where they are

The team has, through various means, an understanding of their work, their progress, their ways of working, their current impediments, and from this, how effectively they meet their team’s responsibilities and advance their team-level OKRs.

This should typically occur during internal team retrospectives and reviews of their work (for example in sprint reviews), and arise tension-based when something seems off, or when new opportunities emerge.

The concept is that the team, often with the support of a Scrum Master or Team Facilitator, continually understands their performance. This knowledge stems from working in iterations, reviewing work, conducting retrospectives on processes, and more. It also encompasses social elements, team dynamics, and the satisfaction levels of VSHNeers.

There should be someone who can grasp the broader perspective and represent the team to the Delegator or other teams. Typically, this is either the Product Owner focusing on the What the team does (reviewing work), or the Scrum Master or Team Facilitator focusing on How efficiently the team operates and what obstacles they face.

The Delegator Dialogue

As the Delegator remains overall accountable for a team, they need to understand how effectively the team delivers on their purpose and identify areas for improvement. The Delegator might also perceive required changes within their domain, have inputs for prioritization, and need clarity on whether there are aspects the teams think should be modified or clarified. The goal is to stay in the loop, both to empower the team to create value and to ensure the team’s delivery on their purpose and deliverables. It’s essential for the business not to overlook issues when things don’t function as they should.

Periodically, the Delegator should check in with representatives of the Team (as mentioned above) to assess how things are progressing. This interaction can follow a simple format and should be documented for future reference. Essentially, it involves going over a list of topics and collaboratively deciding if everything is being managed well and identifying areas for improvement.

The Domain’s Key Responsibilities

The Domain’s Key Deliverables

Team Level OKRs or Product Roadmap

A specific problem or opportunity (Driver)

The Team comes up with a plan how to improve on the things that are not good enough yet. The Delegator plays a role in creating these plans, gives consent to them, and holds the team accountable over time to achieve the necessary improvements. This accountability is bidirectional; the Delegator also has responsibilities towards the Team, mainly in enabling them.

Anyone might have tensions anytime

Anyone in any team or role might stumble across things that seem to not be how they should be (problem) or how they could be (opportunity). We don’t live in a culture where you simply report problems to management and hope for a resolution. We share the responsibility. The subject matter specialist, for example you in your team, who identifies the problem usually has deeper insight into it than the Delegator. Paired with the Delegator’s high-level context, a first iteration solution might be closer and simpler than you’d expect.

As a Delegator, approach the Team; or if you’re a Team member, consult with your peers and then approach the Delegator. Share what you’ve observed or experienced and describe the potential problem or opportunity.

Align on the topic, evaluate its relevance, urgency, and importance (we call this Consent to Driver), and then think about the next steps. This might entail a one-time action or a significant governance decision.

It’s always a collaborative effort - you spot an issue, we collectively delve into it, and then we act. It begins with you.

What to review

We review based on specific matters: a case, a problem, an opportunity, or a responsibility that hasn’t been addressed. We avoid vague feedback like "everything is bad; do something about it." While such statements might arise from frustration, the only constructive way forward is to dive deeper. We need to address each issue individually, get specific, and collaborate on potential solutions. Implement the changes, assess the outcomes, refine, and review again. In our intricate world, there isn’t a single solution to the sentiment "everything is bad."

The Domain’s Purpose

Is the purpose of the domain still clear and relevant to the organization? Does it summarize what the team or rolekeeper actually do and why, can they identify with this purpose?

Key Responsibilities

Are the expectations clear? Are they adequately fulfilled? If not, why? What obstacles are present?

Key Deliverables

Are they still relevant and clear? Does the team deliver as agreed upon? If not, why? What is preventing successful delivery?

Team Level OKRs

Is there sufficient progress as outlined in the Objectives and Key Results (Os and KRs)? If not, what’s holding them back? How can we remove obstacles or enhance progress?

Product Roadmap

Is there sufficient progress to deliver the required features on the roadmap within the stipulated time? If not, what’s the barrier? How can we alleviate the constraints or boost progress?

Fundamental Responsibilities

Do they effectively address all of Fundamental Responsibilities good enough? If not, what needs improvement? What support do they need from the organization?

There isn’t a one-size-fits-all approach here. For a team of two, a simple work tracking mechanism might be enough, whereas a nine-member value stream team might adopt full-fledged Scrum to handle the Prioritization and Planning responsibility.

A specific problem or opportunity (Driver)

Refer to Anyone might have tensions anytime. It could be a task within your team where you were obstructed by another team, resulting in a delay in getting what you needed. It might be an instance where there’s a lack of clarity hindering progress, your team lacking specific skills, or perhaps someone departing from your team necessitating a hiring decision. Address any situation that either doesn’t arise or can’t wait for another scheduled review session.

When to review what

This might be specified in your domain description, or the following defaults can serve as guidance. There’s no absolute right or wrong. As long as both the Delegator and Delegatees are informed and operations are satisfactory, all is well. If there’s no shared understanding of operational efficiency, it’s crucial to address it.

Self-Retro

The team internally conducts a retro on the topics defined in What to review. The frequency and timing depend on the team’s cadence and iterations (such as sprints). Sprint reviews on your work and retrospectives on your processes usually occur at the right intervals. Often, this frequency suffices.

There might be more significant concerns or "elephants in the room" that demand dedicated retrospectives or other formats. Address these as often as necessary. Avoid conducting them without a genuine need.

If the two points above aren’t addressed, hosting a dedicated team internal retrospective before a review meeting with the Delegator might become essential. Otherwise, providing a comprehensive overview and effectively representing your team can be challenging.

Tension based on a specific issue

Address tensions as they arise. Do not delay. Refer to Anyone might have tensions anytime.

Periodically

Initiated by either the Delegator or Team, come together and discuss What to review.

During Sprint-Reviews (Review of Deliverables)

During these reviews, the team can identify changes needed to enhance their effectiveness.

78.3. Review a Role and their Domain

While we don’t have a set guide for this yet, given that a role is a domain assigned to an individual, most of the guidelines in Review the Team and their Domain can be directly applied to role reviews.

One distinction is that, for instance, in a team internal role, your team acts as the Delegator for your role. Delegating and reviewing roles within your team align with your team’s Fundamental Responsibilities.

79. Role: Strategist

Delegator

Business Operations (Management)

Links

VSHN Strategy

VSHN OKRs Overview

VSHN Business / Value Streams

79.1. Purpose

At VSHN, the Vision, Mission, and strategic objectives at the company level are driven and clarified by the board members, usually involving subject-matter experts or relevant roles within VSHN. Teams and roles within VSHN need to follow more concrete, more specific, and time-bound objectives, as well as company-wide strategies, to understand how to make this happen and be one aligned organization.

Therefore, we want a role that continuously understands the Vision and Mission of VSHN and those strategic, long-term objectives and provides clarity to our teams and other roles in VSHN through close collaboration and continuous review, creating the needed accountability to pull in the same direction.

Role Summary

This role is crucial in aligning the company’s strategic direction with actionable business objectives. This role is responsible for comprehending and conveying the company’s Vision and Mission, as established by the board, and translating these into specific, time-bound objectives for teams and roles within VSHN. By fostering close collaboration and providing continuous review, those who hold this role ensure that all parts of the organization are moving cohesively towards the strategic goals, enhancing overall business success and getting closer to our vision.

79.2. Key Responsibilities

What I take responsibility for, whether I do it myself and how I do it is up to me. Not a task list.

VSHN is internally aligned to common goals and a common direction as by our Mission and Vision, concretely:

Continuous understanding of the business models within VSHN and how they contribute.

Teams and Roles in VSHN understand and follow specific, time-bound, measurable goals,

and get their strategic questions and uncertainties addressed, getting the needed clarity continuously.

VSHN Shareholders / Board understand what happens in VSHN and how that aligns with their goals and our Mission.

79.3. Stakeholders

Who needs something or benefits directly from me in this role?

Shareholders of VSHN: Need to understand how VSHN tries to reach the strategic objectives and the progress towards that.

Teams and Roles at VSHN: Need concrete objectives and higher-level context, to understand how they contribute to the bigger picture.

79.4. Key Deliverables

The concrete things that stakeholders get from me.

Up-to-date documented business areas ("Geschäftsfelder") within VSHN.

Company OKRs

Team and Role level OKRs strategic input and review collaboration

Company-wide strategies and strategic initiatives

79.5. Skills and Mindsets

What Skills and Mindsets are needed, to fit this role?

Mindset

Do what is needed, get and produce missing insight and information - self-responsibility, we’re in the lead.

This is the place where this level of strategy happens, if it doesn’t happen here, it doesn’t happen at all - which we don’t accept.

Curious to learn how we do all of this, together with other role keepers.

Leadership and communication skills to drive issues forward while being an example of our cultural principles.

Skills

Flight level and strategic thinking, able to distance from operational work and keep things apart - Focus

Business fundamentals understanding

Basic knowledge of operational accounting

Strategic Risks and Opportunities Management

Business Model thinking and tooling (Business Model Canvas, Value Proposition Canvans and similar)

Structured working and documenting

Solid understanding of Objective and Key Results (OKRs)

79.6. Dependencies

Vision and Mission need to be clear enough and serve as a "north star" where we want to go and can provide motivation for VSHNeers.

Strategic longer-term goals clear (3-10 years), qualitative and quantitative.

Collaboration and insights from various teams and subject matter experts at VSHN (POs, Marketing, Sales, etc.)

79.7. Role Assignment

We see this as a role for 3-5 VSHNeers, with the mindset mentioned above. Skills can be learned and shared among role keepers. Varying capacities of members is fine.

The minimum term is 1 year - to have continuity and consistency in what we do and produce.

We want a broad representation of VSHN: Board, (former) Management, Product Owners, Facilitators, Culture, Sales, Customers, and Finance - knowing that it’s about doing the work, not just representing.

79.8. Evaluation Criteria

Peer review every 3 months (role and role keeper, not the group), involving stakeholders and others who hold this role.

This role is tracked and reviewed as VIP-X (No VIP yet)

80. Role Customer Support Lead

Delegator

Business Operations (Management)

Role Keeper

Arngard Brülisauer

80.1. Purpose

Creating a Customer Support Domain and later a dedicated team to account for it is an experiment that starts in March 2023. Just defining a new domain alone doesn’t do much, especially as there is no team in the beginning.

We need someone to lead governance (to evolve the existing and needed processes), organize and coordinate operations, also to take some of the operational work of this domain, to get started, and later lead in the team.

80.2. Key Responsibilities

Governance

Evolve the processes of Customer Support.

Actively participate in evolving interfaces between Customer Support and other Domains and Teams of VSHN.

Participate in Team Development Work Group as relevant.

Coordination and Operations

Oversee, coordinate and actively participate in the operational work of Customer Support.

Documentation and Training

80.3. Key Deliverables

Leadership and facilitation for Governance, evolving involved processes and structures

Documentation, Presentations and Training of needed processes and agreements

Organization-wide go-to person regarding the involved processes and responsibilities

80.4. Dependencies

Product clarity by Product Management, especially Product SLA and Support Plans

Need and constraints from Customer Support stakeholders

Customer contacts, basic information and contacts by and in co-operation with Customer Experience Team

80.5. Delegator Responsibilities

Business Model, Strategy and Objectives

80.6. Mindset, Skills and Capabilities

Focus on the balance between customer satisfaction, quality and the needs of our teams.

Excellent in customer communication, English and German.

Strong in collaboratively understanding impediments and organizational need, evolving solutions, decision-making and reviewing effectiveness, valuing Sociocracy 3.0 principles.

Focus on pragmatic and iterative / continuous process optimization.

Understanding of Agile and Scrum (how our value stream teams work.)

Ability to differ between Operations and Governance (Doing vs Steering.)

80.7. Monitoring and Evaluation

Review with Delegator representative every 4 weeks

Weekly check-ins with Mentor during role keeper onboarding

This role is tracked and reviewed as VIP-290

Unresolved directive in handbook.adoc - include::modules/ROOT/pages/role_culture_catalyst.epub

Unresolved directive in handbook.adoc - include::modules/ROOT/pages/role_management_member.epub

81. VSHN Canada

Accountable

General Manager of VSHN Canada

Delegator (Purpose)

VSHN Switzerland Management

Delegator (Legal)

VSHN Canada Board (Board of Directors)

81.1. Purpose

With VIP-24 VSHN has decided to implement a follow-the-sun concept to cover 24/7 operations for our customer business, to reduce the burden of working outside normal working hours.

To do this, we need staff at additional locations around the world, ideally about 8 time zones apart from Switzerland. The Swiss evening hours and the time until midnight are most important for us because of scheduled changes and periodic maintenance work, and are therefore our priority.

With VSHN Canada - The DevOps Company Inc., located in Vancouver, British Columbia, we have our first follow-the-sun location, and employ people locally there.

81.2. Key Responsibilities

People in Vancouver are effectively working to cover the follow-the-sun needs of VSHN.

VSHN is a legally compliant employer in Vancouver.

81.3. Key Deliverables

VSHN Canada Opeartons - Primarily maintenance amd other night work, and plannable work capacity for other VSHN Teams.

Invoices of the services to VSHN Switzerland.

81.4. Organization

This shows the high level organization of VSHN Canada in relation to VSHN Switzerland.

Identity and Culture

We’re one company, we share the same Identity and Culture.

Legal Structure

VSHN Canada - The DevOps Company Inc. is owned by and part of VSHN AG Switzerland

VSHN Switzerland appoints the General Manager of VSHN Canada.

Purpose and Operations

VSHN Canada hires people, employs them in Vancouver.

VSHN Canada employees are part of VSHN Teams to cover European evening and night work.

VSHN Switzerland pays costs of VSHN Canada.

Governance

The VSHN Switzerland Management defines the purpose, constraints and business requirements for VSHN Canada.

The General Manager of VSHN Canada is part of the VSHN Switzerland Management.

81.5. Constraints

While there are naturally cultural differences, we strive for equivalence for all employees and adhere to our common Values.

If exceptions are necessary (for example local employment conditions), we decide together with Peoople Operations and VSHN Switzerland Management

We try to find simple, generally and if possible globally applicable solutions that do not require further exceptions.

Whenever possible, we try to unify organizational, process and tooling globally and don’t reinvent the wheel.

This domain is tracked and reviewed as VIP-46

82. General Manager VSHN Canada

This role is the Business Management of VSHN Canada - The DevOps Company Inc., Vancouver.

Accountable

Matthias Indermühle

Delegator

VSHN Canada Board (Board of Directors)

82.1. Purpose

Why does this role exist?

A company must make sure that it fulfills its purpose and makes all the necessary organizational, economical and personnel decisions as well as plans, implements and controls measures and the operational business. The board of directors can do this themselves or delegate this to others in the company (as defined by British Columbia, Canada law).

We want to define this as the Business Management domain and delegate it to a person in Vancouver working for VSHN Canada. So that we have someone locally to ensure the health of the company and the effectiveness of the follow-the-sun concept for VSHN.

82.2. Key Responsibilities

General

The same responsibilities as the VSHN Switzerland Business Management but for VSHN Canada.

Additional

Vision and culture of VSHN Switzerland represented and lead within VSHN Canada.

Legal compliance with and between British Columbia, Canada and Swiss law.

Working People Operations (Human Resources) for the staff employed in Canada.

Recruiting to hire people for VSHN Canada.

Physical office for VSHN Vancouver.

VSHNeers traveling between Canada and Switzerland supported and coordinated.

Represent VSHN Canada in the Switzerland Management.

82.3. Key Deliverables

VSHN Canada budget for the next 18 months, aligned with overall VSHN strategy.

Invoicing to VSHN Switzerland.

Reviews of the Canada domains and people.

Meetings with Canada VSHNeers (for escalation, and as useful and needed).

Company-wide presentations and announcements for VSHN Canada staff.

Representation at external meetings and events (official representation of VSHN).

82.4. Monitoring and Evaluation

Review (usually Peer Review) every 6 months with the Management Switzerland and reviews as the Delegator as part of the reviews of all delegated Domains.

Evaluation Criteria:

VSHN Canada has the means (financial, infrastructure, and people) to fulfill its purpose.

Financial Health of VSHN Canada.

Key Deliverables produced and usable / working as intended.

82.5. Constraints

Administrative work is turned over to VSHN Switzerland only when there is a good reason, consent to by VSHN Switzerland to do so, for example substitute during vacation, more experience and more efficient staff and similar.

This domain is tracked and reviewed as VIP-166

83. Central Services

In order to enable VSHN’s core business, provide things and tooling for VSHNeers, fulfill employer obligations and comply with legal and financial regulations, VSHN must provide certain internal services to support the teams.

We need a team that has overall accountability for all of these things and then can divide into sub-teams to better serve that overall purpose and organize themselves.

We also need a team that can be a "home" for people who are not otherwise in any other Team because they only work in Workgroups, Management, etc.

Accountable

Antares Team

Delegator

Business Operations (Management)

83.1. Key Responsibilities

Most of the responsibilities are specified and delegates in these sub-domains:

Office Management

Finance

Procurement

People Operations

Corporate IT

Legal & Compliance

Some exceptions and stand-ins are documented in Wiki.

Various

Zurich Office Concept

Periodically check requirements

Rent new and get rid of rooms we no longer need

Assignment of rooms (see Office Management)

Develop long term strategy, including constructional measures to improve our offices, etc.

According to VIP-151

Company Events

Budget

Gather ideas for upcoming events.

Organize events.

Make sure that it happens according to what we promise to VSHNeers (for example 4 times a year).

VSHN Connect

Organize a VSHN Connect once a year with the goals set by the Board and Management as defined in VIP-149.

83.2. Constraints

People Operations

People Operations is what others might call human resources, it has special constraints and is partly regulated by law, this is why we delegate this into its own sub-domain People Operations.

As caring about people is our most important core value we want to invite everyone to contribute and participate in decision making on topics that affect us all.

83.3. Evaluation Criteria

Salaries are payed on time.

We bring in the money that we can bill.

We operate according to the law.

83.4. Accountable Team

Antares

Dawn Nitsche (People Operations Lead, People Care and Recruiting)

Manuela Banz (Finance lead and Team Facilitator for Antares)

Patrick Mathers (Finance and Chairman of the Board)

Sabrina Lang (People Operations, People Care, and Finance)

This domain is tracked and reviewed as VIP-35

84. Corporate IT

Taking care of tools and services which VSHNeers use on a daily basis, helping them to do their job as efficiently as possible.

Accountable

Canopus Teams

Lead

Role keeper of Corporate IT Lead

Delegator

Corporate IT Workgroup

84.1. Purpose

We have many tools and services throughout the company that are used by many or all VSHNeers or serve processes and workflows that are required by our business. Our engineers on the value stream teams could care about these systems, but they should focus on the work that generates our primary value and business. Non-technical people at VSHN often don’t know how to help themselves when it goes beyond the normal use of our tools.

We need a way to take care of all the IT systems, tools, and processes at VSHN, continually evolve them according to actual (future) need and support the users, so that the VSHN business runs smoothly, grows and people can work efficiently.

84.2. Key Responsibilities

Maintenance and Upgrade of Corp IT systems to have up-to-date functionality and availability.

Security of Corp IT systems and data.

Requirements Engineering, Evaluation, Planning and Implementation of new IT Tooling.

Users (primarily VSHNeers) get help when unclear how to use our tooling.

Implementation and Changes of business processes and workflows in our IT Tooling (fore example Ticketsystem, ERP), if not maintained by the users themselves.

84.3. Key Deliverables

Usable IT systems, tools and services which VSHNeers use on a daily basis, helping them to do their job as efficiently as possible.

Usable business workflows and processes in our tooling.

User usage Support.

A go-to-person for Corp IT for all VSHNeers and the Delegator on the non-technical level.

84.4. Key Resources

The IT Systems and tooling in question.

Up-to-date overview of all IT Systems, Tooling and Services

Corp IT Budget (one-time and running costs)

84.5. Constraints

Corporate Services Strategy: What services and software we use or prefer.

Budget as given by Management.

84.6. Evaluation Criteria

VSHNeers have working tooling they need to do their daily work.

This domain is tracked and reviewed as VIP-96

85. DevOps Engineer

This is the default / dummy role of an engineer at VSHN working in a customer or product team at the moment. It includes:

Site Reliability Engineers

Software Developers

Kubernetes Engineers

Linux Engineers

…​

This needs to be reworked with the new teams during or after the 2022 Reteaming.

86. Office Management

Take care about various things of our physical office in Zurich.

Sub-domain of

Central Services

Accountable Circle

Antares

Delegator

Business Operations (Management)

Lead by

Patrick Mathers

86.1. Key Responsibilities

Care about our physical office in Zurich.

Handle physical mail and shippings.

Manage office equipment and furniture.

Moderate how rooms are used.

Organize facility management, including cleaning, repairs, etc.

Organize recycling and physical waste.

Organize visitor reception.

Organize phone duty for the company main number (TipTel).

86.2. Dependencies

Buying and maintaining things for the office is mostly with Procurement.

VSHNeers should report broken things immediately by creating a ticket (blocking VINT-31 Office Management)

86.3. Evaluation Criteria

Physical Office in working and usable condition, not blocking VSHNeers.

VSHNeers have the things they need to work in the office.

Office is in a presentable condition for visitors and partners.

This domain is tracked and reviewed as part of VIP-35

87. Finance

Handling, controlling and managing our finances.

Sub-domain of

Central Services

Accountable Circle

Antares Team

Delegator

Business Operations (Management)

Lead by

Manuela Banz

87.1. Key Responsibilities

Invoicing to customers, including customer support

Monthly consulting hours and subscriptions billing

Payment reminders

Budgeting

Reporting to Business Operations, Management.

Support Management with budget decisions.

Accounting

Cash register

Accounts payable

Accruals

Bank accounts

Chart of accounts

Pay out salaries

(Annual) financial statements

Tax declaration

Provide the reports needed by Business Operations.

Banking

Budget (see above)

KPIs

Revenue and spending of teams and products

Financial controlling

Support Board with financing decisions:

Credit management

Loan management

Financial audits

87.2. Evaluation Criteria

Management and others at VSHN get the numbers they need to make decisions.

VSHN operates in compliance with tax laws.

This domain is tracked and reviewed as part of VIP-35

88. Legal & Compliance

Managing contracts and coordinating various legal topics with lawyers and our teams.

Sub-domain of

Central Services

Accountable Circle

Antares

Delegator

Business Operations (Management)

Lead by

Patrick Mathers

88.1. Key Responsibilities

Contracts Management

Support contract negotiation and reviews.

Coordination with Lawyers.

Insurance Management and yearly tenders

Corporate law, changes to the commercial register

This role is tracked and reviewed as part of VIP-35

89. Procurement

Buying new things and keeping track of them.

Sub-domain of

Central Services

Accountable Circle

Antares

Delegator

Business Operations (Management)

Lead by

Manuela Banz

89.1. Key Responsibilities

Overview of what we buy (one time and recurring) for VSHN, together with Finance.

For our office

Buy, keep record of and maintain:

Office equipment and furniture

Office supplies

Technical equipment (like projectors, meeting equipment, etc.)

Maintain stock of free snacks and drinks for VSHNeers.

For our VSHNeers

Personal equipment according to our Personal Workplace Budget

89.2. Evaluation Criteria

VSHNeers have the things they need to work in the office.

VSHNeers have the equipment they need to work.

This domain is tracked and reviewed as part of VIP-35

90. Business Management

Accountable

Management Work Group

Delegator

Board ("Verwaltungsrat")

90.1. Purpose

Why does this domain exist?

A company must make sure that it fulfills its purpose and makes all the necessary organizational, economical and personnel decisions as well as plans, implements and controls measures and the operational business. The board (“Verwaltungsrat”) can do this themselves or delegate this to others in the company (as defined by Swiss law.)

We want to define this as the Business Management Domain and delegate it to a group of people at VSHN. So that we can ensure the health and growth of VSHN, and Board and Management can control this through reviews together.

90.2. Key Responsibilities

Finance

Create and maintain Rolling Budget, control effective numbers.

Get budget approval from Board.

Handle budget requests, including hiring decisions.

Control and ensure liquidity.

Define, watch and react on "red flags" in finance.

Control finances for VSHN Canada as budgeted.

Organizational Structure

Understand, document and help others to understand how we are organized, how VSHN’s overall purpose is delegated, and what our high-level business processes are.

Initiate and host reviews of the Domains (Teams and Roles) we delegated.

Represent us as the Delegator in Reviews.

Actively provide feedback to Delegatees to help evolve existing Domains.

Periodically check defined metrics and evaluation criteria of delegated domains, talk with Delegatees.

People

React to VSHNeers escalating to Management (or via PeopleOps), find out what is needed, point them in the right direction and offer support.

Support People Operations and Recruiting with our high level prespective of VSHN.

Periodically check defined employee metrics (eNPS, etc.) and react on "red flags".

External Representation

React to Customers escalating to Management, offer support and attend meetings.

Officially represent VSHN to the outside, at events, towards authorities, and similar, where a "C-title" is required.

Internal Representation

Represent the business in company wide, internal events.

Represent the business and our high level prespectie in governance on all levels, where it’s needed or requested.

Link to Board

Attend board meetings (or otherwise interact) to be on the same page.

Report Information Security Risk Management (ISMS) issues.

Report financial figures, company health, audit results and measures.

Report strategy progress (Company Level OKRs).

Strategy

Ensure that within VSHN, we undertand where VSHN is going (vision and mission), and how to reach strategic goals set by the Board. This is delegated to the Strategist Role.

90.3. Key Deliverables

Last escalation point to all Teams and VSHNeerys

Support to understand VSHN and our business.

A working lead for high level Governance of VSHN.

Company Alignment Measures and Events.

Reviews and feedback to delegated Teams and Roles.

Lead and execution of short-term needed measures if everything else fails or is too slow to mitigate risks.

90.4. Delegator Responsibilities

Decision on overall Identity and Purpose of VSHN (even if Management and other VSHNeers are involved, and contribute)

Quarterly decision on Budget for the next 18 months

Organize and ensure proper accounting (even if operationally delegated)

"Organisationsreglement" that delegates us the "Geschäftsführung".

90.5. Dependencies

VSHN and the Teams for collaborative proposal forming and decision-making on high level strategy and Company Level OKRs.

Marketing & Sales Team (Sol) for Product and go-to-market strategy, as well as profitability of our products and offerings, as well as sales pipeline and customer retention metrics (to be able to notice and react if they don’t).

90.6. Monitoring and Evaluation

Review (usually Peer Review) every 6 months with the Board and reviews as the Delegator as part of the reviews of all delegated Domains.

Evaluation Criteria:

The organization (all VSHNeers) has everything to sustain itself, be successful and grow.

Financial health of VSHN.

Key Deliverables produced and usable / working as intended.

This domain is tracked and reviewed as VIP-61

91. Compensation Domain

Accountable

Compensation Work Group

Delegator

Business Management (Management)

91.1. Purpose

Why does this domain exist?

Every organization needs a working compensation model in order to attract and retain employees. In most companies, this is done top down by management, with little influence by single employees (except their negotiation skills). This does not correspond to the VSHN values.

We want to have a group that creates and develops our compensation model (including salary system) as objectively as possible, leaving personal interest and personal political views out, so that it’s supported by all VSHNeers.

91.2. Stakeholders

Our Business (represented by Management)

A salary system is for the company - the ability to actually hire and retain employees, so that we can fulfil our company purpose. In that are the aspects of fairness, transparency, equivalence, etc. This is why the compensation topic is delegated by Management directly.

VSHNeers

All VSHNeers who get a salary are directly or indirectly affected.

91.3. Key Responsibilities

Get clarity about the requirements of compensation at VSHN.

Define and evolve:

the basis on which our compensation model is built like fairness, transparency, market orientation, etc.,

the Salary System, incl. how to set salaries outside of Switzerland,

other ways of compensation / benefits.

91.4. Key Deliverables

Documented and usable compensation model

Support to understand and use the salary system, to implement other aspects of compensation, etc.

91.5. External Constraints

Members of this group are selected through role selection, or other reasoned decision-making.

The Management needs to be represented by at least one member.

People Operations needs to be represented by at least one member.

Decisions are made using consent, involving the people affected.

VSHN Values.

91.6. Key Resources

Team members of the group accountable for this domain need time to actively work for this domain. Expectations to be defined as we learn about actual effort through reviews.

91.7. Delegator Responsibilities

Provide and support with economical / financial overview and constraints.

Budget for Education, Consulting, etc.

91.8. Dependency

Besides the fact, that this domain directly affects every VSHNeer and the finances of VSHN, we see no clear dependencies at the moment.

91.9. Mindset, Skills and Capabilities

Willingness to learn about modern ways of compensation, what others do, etc.

Ability to leave personal interest and political views out.

Facilitation skills and experience (or ability to know when to get help).

91.10. Monitoring and Evaluation

Review (usually Peer Review) every 2 months with the Management as the Delegator.

Evaluation Criteria:

Every VSHNeer understands how compensation at VSHN works.

We’re able to set salaries to hire people in Switzerland, Follow-the-sun-locations and remote.

We’re able to translate other aspects of compensation to other countries.

Salary is not a blocker for what VSHN needs to do (hiring the best people).

This domain is tracked and reviewed as VIP-219

92. Domain Application Catalog

Accountable

Schedar Team

Delegator

Business Operations (Management)

Scrum Master

Nicolas Bigler

Product Owner

Liene Luksika

Tech Alignment

Gabriel Saratura

92.1. Purpose

Our customers need databases, search, cache and similar services, as well as "Developer Tooling as a Service", consumable via self-service, to do DevOps and run their applications reliably in production, or offer such services at scale. On VM only clouds or for on-premises installations, there are no cloud provider services available for this.

We therefore need to broker cloud services, and also build, run and support self-made services, so that we can offer both in a unified way, as VSHN products.

92.2. Stakeholders

Company that needs software for their business

Software Developers

Provider with instances at Scale

92.3. Key Deliverables

VSHN Application Catalog, consisting of:

Brokered Cloud Services

Services made by VSHN

Framework

92.4. Key Responsibilities

Requirements for Services from stakeholders are understood, fed and decided in product management.

Products defined in needed detail, including SLIs and SLOs.

Automation Framework built and maintained.

Defined Services are engineered.

Code and documentation for all Services maintained.

Customer Services operated towards defined SLOs.

Customers receive support according to (Support Plans).

92.5. Definition of Done

All used services are visible and automatically billed, no manual interventions needed.

Unified way (API) for customers and VSHNeers to self-service provision and configure services.

Definition of Run

Service used by customers up and running according to SLI / SLO definition.

92.6. External Constraints

Product Roadmap

Defines which service, and major features, to build next

Defines which clouds to focus on

Tech Radar (Technology Alignment)

92.7. Delegator Responsibilities

Ensure product management gives clear roadmap.

92.8. Dependencies

VSHN Products

APPUiO Cloud

APPUiO Managed OpenShift

APPUiO Managed Kubernetes Services

External

Cloud Provider Services

OSS Projects and Software Vendor contracts

VSHN Internal Services

Finance

People Operations

VSHN Canada timezone coverage support

92.9. Key Resources

Application Catalog Framework

Project Syn

Inventory of all running services

SLO Monitoring System

92.10. Mindset, Skills and Capabilities

Skills

System Engineering

Cloud Architecting (expert knowledge)

API / Kubernetes Operator Software Development

Kubernetes

Cloud Provider specific knowledge

Major Database Systems (as Server Admin)

Mindsets

Product and SLO oriented

Eager to learn and develop skills for the technology

92.11. Monitoring and Evaluation

Review (usually Peer Review) every 2 months with the Management.

92.12. Accountable Team

Schedar

Gabriel Saratura (DevOps Engineer)

Liene Luksika (Product Owner)

Łukasz Widera (DevOps Engineer)

Nicolas Bigler (DevOps Engineer, Scrum Master)

Simon Beck (DevOps Engineer)

This domain is tracked and reviewed as VIP-277

93. Domain APPUiO Managed OpenShift 4 & APPUiO Cloud

Accountable

Aldebaran Team

Delegator

Business Operations (Management)

Scrum Master

Elia Ponzio

Product Owner

Christian Häusler

Tech Alignment

Simon Gerber

93.1. Purpose

To run their workloads, our customers, and we to do AppOps, need Kubernetes. Strategically, VSHN uses and is known for Red Hat OpenShift. On Clouds where we can’t get OpenShift (or Kubernetes) from the provider, for on-prem installations or where we want to offer OpenShift namespaces as a service, we have to build and run dedicated clusters in VMs.

We therefore need to develop and maintain how to most effectively do OpenShift in VMs and with that design, build, and configure clusters and their environment according to customer needs and reliably run them as a managed service. With that, VSHN AppOps and our customers don’t need to care about getting and running Kubernetes clusters.

93.2. Stakeholders

Company that needs software for their business

Software Developers

Provider with instances at Scale

93.3. Key Deliverables

APPUiO Managed OpenShift

APPUiO Cloud

APPUiO Managed RKE (discontinued)

93.4. Key Responsibilities

Customer Requirements for dedicated clusters continuously understood.

Setups of dedicated clusters architected and continuously reviewed according to changing requirements.

Recurring maintenance and operations tasks standardized and automated to a useful level.

Existing instances of standardized building blocks maintained and migrated when needed.

Customer Services operated towards defined SLOs.

Customers receive support according to (Support Plans).

93.5. Definition of Done

All used services are visible and automatically billed, no manual interventions needed.

Unified way (API) for customers and VSHNeers to self-service provision and configure services where applicable (for example APPUiO Cloud).

Definition of Run

Service used by customers up and running according to SLI / SLO definition.

93.6. External Constraints

Product Roadmap

Defines which service, and major features, to build next

Tech Radar (Technology Alignment)

93.7. Delegator Responsibilities

Ensure product management gives clear roadmap.

93.8. Dependencies

VSHN Internal Services

Finance

People Operations

VSHN Canada timezone coverage support

93.9. Key Resources

Project Syn

Inventory of all running services

SLO Monitoring System

93.10. Mindset, Skills and Capabilities

Skills

System Engineering

OpenShift (as Sysadmin)

Kubernetes

Linux Admin

Terraform

Software Development (Go, Python)

Mindsets

Product and SLO oriented

Customer Project thinking

93.11. Monitoring and Evaluation

Review (usually Peer Review) every 2 months with the Management.

93.12. Accountable Team

Aldebaran

Adrian Haas (DevOps Engineer)

Aline Abler (DevOps Engineer)

Christian Häusler (Product Owner)

Elia Ponzio (DevOps Engineer, Scrum Master)

Sebastian Widmer (DevOps Engineer)

Simon Gerber (DevOps Engineer)

Stephan Feurer (DevOps Engineer)

This domain is tracked and reviewed as VIP-279

94. Domain Canada Operations

Accountable

Vega Team

Delegator

Business Operations (Management)

Team Facilitator

Matthias Indermuehle

Product Owner

Sandro Kaspar (for APPUiO Managed Kubernetes Services)

Tech Alignment

Sandro Kaspar

94.1. Purpose

VSHN Canada in Vancouver was founded primarily to offload plannable Swiss night work to our first follow-the-sun location. This doesn’t utilize the capacity of the personnel we have in Vancouver. This brings the opportunity for them to also do other work for VSHN.

We therefore have a team that offers their capacity and skills to all other VSHN teams and also takes on maintenance and proactive operations ownership of certain services.

94.2. Stakeholders

Customers with APPUiO Managed Kubernetes Services

Other VSHN (Value Stream) Teams

Customer Support for 24/7 Support & Incident handling

94.3. Key Deliverables

Technical

Maintenance of running APPUiO Managed Kubernetes Services instances.

Framework maintenance and limited improvements around APPUiO Managed Kubernetes Services

Planned night-maintenance work for the instances of Value Stream Teams’s products.

Other plannable tasks for other VSHN Teams

Non-technical

Sales and Account Management support for Sol

94.4. Key Responsibilities

Technical

Plan and execute proactive instance and framework maintenance to keep APPUiO Managed Kubernetes Services instances running.

Execute planned and handed over task from other VSHN Teams.

Participate in Customer Support or On-Call rotations to cover part of 24/7 Incident handling and support.

Non-technical

Define the requirements and keep the dialog with other VSHN Teams how work is handed over to VSHN Canada.

Sales and Account Management support for Sol

Support Sol in entering the market to sell VSHN services in North America.

94.5. External Constraints

Proactive development / investments into APPUiO Managed Kubernetes Services to be decided collaboratively in Tech Alignment.

94.6. Dependencies

Work defined and properly handed over and reviewed after execution.

Clarity on product strategy around APPUiO Managed Kubernetes Services

94.7. Key Resources

Project Syn

Inventory of all running services

SLO Monitoring System

Rancher Management Server (for now)

94.8. Mindset, Skills and Capabilities

Technical Skills

System Engineering

Cloud Kubernetes Experts

Kubernetes

Rancher (for now)

Terraform

Mindsets

Product and SLO oriented

Non-Technical Skills

Sales Offering

Account Management and Project Management

Customer Communication

Asynchronous planning and work review

94.9. Monitoring and Evaluation

Peer Review every 2 months with representative from VSHN teams who work with VSHN Canada. Hosted by the Team Facilitator.

Domain Review with Delegator every 2 months after Peer Review.

94.10. Key Challenges

Planning, working and staying connected across a major timezone gap.

Stay culturally connected with VSHN Switzerland, be involved in cross-company decisions that affect VSHN CA or where contributions are needed.

Stay up-to-date on the technical skills and innovaton with all VSHN Value Stream Teams.

94.11. Accountable Team

Vega

Jay Sim (DevOps Engineer)

Sandro Kaspar (DevOps Engineer)

Matthias Indermuehle (Team Facilitator)

This domain is tracked and reviewed as VIP-280

95. Domain Managed Server based Services

Accountable

Polaris Team

Delegator

Business Operations (Management)

Scrum Master

Jessica Wyrsch

Product Owner

André Keller

Tech Alignment

Michel Rios

95.1. Purpose

Historically, VSHN built application hosting platforms and services using Managed Linux Servers. Even the business behind this is basically the same as our AppOps and Managed Services, the processes and technology isn’t what VSHN plans to use for this in the future and where the IT world is moving towards. Existing customer setups needs to be run reliably until customers (with our help) can transform to our new products and services.

We therefore need to maintain how to most effectively run Linux Servers and applications on it, and with that reliably run the systems for existing setups until no longer needed, to make that happen. We also need to help other VSHN teams migrate customers by leveraging our experience with existing setups.

95.2. Stakeholders

Company that needs software for their business

Software Developers

95.3. Key Deliverables

Managed Server based Services.

Managed Server based Custom Solutions.

95.4. Key Responsibilities

Additional Managed Services provisioned.

Setups of existing customers up and running.

Existing Solutions are documented.

Automation framework and product building blocks maintained.

Customers receive support according to (Support Plans).

Customer Services operated towards defined SLOs (or legacy agreements).

95.5. Definition of Done

Definition of Run

Service used by customers up and running according to SLI / SLO definition, or legacy customer agreements.

95.6. External Constraints

VSHN Strategy, especially VIP-240

New setups only for services we have in our future product portfolio, and only until we have a successor product.

We do not invest in extending/improving existing products and frameworks if we have a defined successor product.

Changes to existing setups (incl. major software upgrades) only when needed or when paid by customer.

Tech Radar (Technology Alignment)

95.7. Delegator Responsibilities

Ensure product management gives clear roadmap.

95.8. Dependencies

VSHN Internal Services

Finance

People Operations

VSHN Canada timezone coverage support

95.9. Key Resources

Puppet Managed Server Framework

Icinga based Monitoring Stack

Burp backup system

PuppetDB based billing

95.10. Mindset, Skills and Capabilities

Skills

System Engineering

Puppet

Ansible

Major Database Systems (as Server Admin)

Mindsets

Product and SLO oriented

Customer Project thinking

95.11. Monitoring and Evaluation

Review (usually Peer Review) every 2 months with the Management.

95.12. Accountable Team

Polaris

Alexander Dehmel (DevOps Engineer)

André Keller (DevOps Engineer)

Ivan Grcic (DevOps Engineer)

Jessica Wyrsch (Scrum Master)

Michel Rios (DevOps Engineer)

Peter Ruegg (DevOps Engineer)

Pierre Rouveyrol (DevOps Engineer)

This domain is tracked and reviewed as VIP-281

96. Domain AppOps & AppFlow

Accountable

Nunki Team

Delegator

Business Operations (Management)

Scrum Master

Jessica Wyrsch

Product Owner

vacant, hiring

Tech Alignment

Manuel Hutter

96.1. Purpose

Companies that need software for their business, need help choosing the most appropriate platform, technologies, tools, and processes to run their software and often struggle with 24/7 proactive operations. The Developers, who produce such software, want to have best-practice, standardized services, well-designed processes and automate as much as possible, so that mistakes are avoided, their work can scale, and they can focus on what really matters for their core task of creating great software.

We therefore need to help engineer application hosting platforms, support developers with their processes and tooling and take ownership for application operations around the clock.

96.2. Stakeholders

Company that needs software for their business

Software Developers

96.3. Key Deliverables

Guided by our current understanding of VSHN AppOps and VSHN AppFlow:

Cloud Hosting Architecture

VSHN AppFlow one-time engineering

General engineering to build a full solution to the customer’s requirements

Automated or manual Operations of this Application and other components (in combination with what’s operated by other VSHN internal or external services)

Cloud Native Consulting

Insights for existing and potential new products

96.4. Key Responsibilities

Starting in sales, find out what problem we need to solve for our customers.

Engineer solutions based on our products, potential future products and, if needed, together with partners.

Deliver first iterations of services that address the customers requirements now, and evolve it over time.

Over time, figure out what we should and can standardize into well-define products and features of VSHN AppOps and VSHN AppFlow.

96.5. External Constraints

What we offer is decided together with other POs in the sales process, see VIP-302. While this domain is where we build the missing puzzle pieces to give a full solution to the customer’s requirements we can’t do everything. It’s crucial to define the boundaries, before we sell a solution.

Tech Radar (Technology Alignment) - Tech decisions with impact beyond the team Tech Alignment Work Group

96.6. Definition of Done

We’ll learn as we define what we provide to customers and with the products of AppFlow & AppOps.

Documented and customer agreed definitions of the solutions we provide, either based on:

VSHN Product definitions

Specific agreements with customer - to ensure that expectations of what we provide and how customer contributes are clear.

Definition of Run

Service used by customers up and running according to SLI / SLO definition or customer specific agreement.

96.7. Delegator Responsibilities

Ensure guidance for the team based on OKRs, Roadmap and through the Pre-Sales decision making.

Ensure coordination between teams regarding the work that Nunki depends on (for example AppCatalog services).

96.8. Dependencies

VSHN Products

Application Catalog

APPUiO Cloud

APPUiO Managed OpenShift

APPUiO Managed Kubernetes Services

External

OSS Projects and Software

VSHN Internal Services

Finance

People Operations

VSHN Canada timezone coverage support

96.9. Key Resources

Concepts, Templates, Frameworks

Inventory of in-use setups and applications we run.

SLO Monitoring System

96.10. Mindset, Skills and Capabilities

Skills

CI/CD Pipeline Engineering (GitLab and GitHub Actions)

Containerizing applications

Run applications on Kubernetes and OpenShift

Helm, Kustomize

Hosting Architecture Engineering

"Cloud" Know How

Developer Background to understand the customer

Mindsets

Open for new and unknown challenges, open minded to make something new.

Customer oriented

Eager to learn and develop skills for the technology

Trainer and Sparringspartner

96.11. Monitoring and Evaluation

Review (usually Peer Review) every 2 months with the Management.

96.12. Accountable Team

Nunki

David Gubler (DevOps Engineer)

Gabriel Mainberger (Solution Architect)

Jessica Wyrsch (Scrum Master)

Manuel Hutter (Solution Architect)

Nick Marti (DevOps Engineer)

This domain is tracked and reviewed as VIP-278

97. Domain Marketing

Sub-domain of

Marketing & Sales

Accountable

Sol Team

Coordinator

Annie Talvasto

97.1. Purpose

Understand the market, customer segments, and buyer personas enough to define the offerings of VSHN. We aim to develop dynamic and responsive marketing strategies for VSHN as a brand and for our offerings. By closely collaborating with Product Management and the teams that produce the actual value, we continuously adapt to market changes, ensuring that we address customer pain points and create significant value for them. Our goal is to generate leads for Sales, thereby attracting the right customers, and also supporting business growth with existing customers in Account Management.

97.2. Key Responsibilities

Define go-to-market strategy, execute, and evaluate the effectiveness of initiatives to generate high-quality sales leads.

Define and run marketing campaigns to boost brand and product/offering visibility.

Enable Sales and Partners to promote and sell our offerings.

Maintain a robust brand identity and develop effective brand positioning strategies.

Generate diverse and engaging content, such as blog articles, white papers, and social media posts.

Manage and optimize the company’s website and overall online presence.

Conduct in-depth market research and analysis to inform marketing and product decisions.

Evaluate the success of marketing activities and adjust strategies accordingly.

Develop and implement strategies to enhance existing customer engagement and improve retention rates with Sales & Account Management.

Manage strategic marketing partners.

97.3. Key Deliverables

Go-to-market strategy.

Documented offerings of VSHN.

Documented buyer/customer segments.

Enabling sales material/content for Sales & Account Management.

Company website.

Social media presence.

Leads for the sales team.

Reporting (metrics) of product and offering profitability.

97.4. Key Metrics

Number of incoming/generated leads.

97.5. Dependencies

Working together with the Value Stream Teams to define our offerings.

Product Management: For aligning offerings and marketing strategies with product roadmaps.

Sales & Account Management: For a feedback loop on lead quality and sales conversion rates.

98. Domain Marketing & Sales

Accountable

Sol Team

Delegator

Business Operations (Management)

Team Facilitator

Patrick Mathers

98.1. Purpose

There are Companies that need to run software, Software developers and system engineers that have not yet heard of VSHN and don’t know how we could help them.

We need to understand the customers' challenges through market analysis and customer insights, define how we can solve those challenges through product management, attract the right customers through marketing, convert them to paying customers through sales, plan and successfully onboard them through customer project management, retain them long-term through account management and find partners that help us with any of these tasks.

Successfully acquiring and retaining customers enables the sustainability of the business.

98.2. Stakeholders

Product Owners: Need clarity on the high level product strategy, profitability, etc.

(Potential) Customers: Expect a great buyer and customer journey.

Delegator (Management): Need continuous clarity on brand and product marketing strategy, profitability and sales pipleine.

Value Stream Teams: Need product insights, enough incoming new business to deliver their services, and customer feedback on their services and products to optimize value contiuously.

98.3. Key Responsiblities

High-Level

Understand the market and our (potential) customer segments.

Develop, own and reevaluate our value proposition and Go-to-market strategy.

Generate leads and turn them into customers.

Nurture customer relationships.

Own and continously improve the whole sales process.

Manage strategic marketing, sales channel and product / supplier partnerships.

See the following sub-domains

Marketing

Product Management

Sales & Account Management

98.4. Key Deliverables

High-level

Increased brand recognition and market visibility.

Enhanced brand reputation and differentiation from competitors.

Growth in customer base and improved customer retention rates.

Revenue growth and increased sales figures.

Positive market feedback and customer satisfaction.

Up-to-date data about our customers (offers, orders, contracts, contacts, etc.)

Pipeline, product / offering and customer metrics to enable strategic decision-making.

Documented strateigc partnerships and related agreements.

See the following sub-domains

Marketing

Product Management

Sales & Account Management

98.5. Key Metrics

Sales Pipline (leads, offered, sold), recurring per month and one-time revenue, with probability and timeline.

Customer NPS

Profitability per product or offering

Profitability per customer

98.6. Dependencies

Solution Architects from Value Stream Teams.

Value Stream Teams doing the technical onboarding and provide the service as sold.

Accounting / Finance: Correct invoicing of created services and having up to date numbers of our existing business.

98.7. Key Resources

Odoo ERP

Hubspot

98.8. Delegator Responsibilities

Contribution to product and marketing strategy, bringing the Delegator’s perspective of all VSHN teams.

Budgeting and other high level constraints.

Enabling collaboration with other teams when it doesn’t work directly between the teams.

98.9. Monitoring and Evaluation

Monthly overall Domain Review on how well the team functions with the Team Facilitator.

Sales figures weekly for now, with representative of Sales & Account Management

Marketing Strategy bi-weekly for now, with a representative of Marketing

The rest is on-demand / tension based.

98.10. Accountable Team

Sol

Aarno Aukia (Head of Growth)

Annie Talvasto (Marketing and Public Relations Lead)

Daniel Briner ((Key) Account Manager)

Josh Meyer (Cloud Gotomarket Specialist)

Mia Egger ((Key) Account Manager)

Patrick Mathers (Team Facilitator)

Tobias Brunner (Product Manager)

Virag Josephsen (Inside Sales)

Gabriel Mainberger (Solution Architect)

Manuel Hutter (Solution Architect)

This domain is tracked and reviewed as VIP-X

99. Domain Product Management

Sub-domain of

Marketing & Sales

Accountable

Sol Team

Lead

Tobias Brunner

99.1. Purpose

Translate customer needs and market insights in the scope of VSHN vision into a strategic product vision. This involves defining, designing, and managing products that solve customers' challenges, add value, and align with VSHN’s business goals. Product Management serves as a bridge between market demand and the technical solutions we provide, ensuring that the offerings we develop and enhance resonate with current and potential customers, and stand out in the competitive landscape.

99.2. Key Responsibilities

Know the market

Customer needs (jobs to be done, pains, and gains)

Partners who complement the VSHN offering

Competitors

Possible future demand

Technology trends

Product vision

Ideas for potential new products

Knows the technical landscape VSHN is in

Define the overall vision of our offerings (primarily for our products)

Portfolio management

Maintain the VSHN Product Portfolio

See dependencies between products and find ways to cross-/up-sell products. For example:

Users of product x might also be interested in this product

Users of this product might also want to buy x

Propose and drive decisions to define the concrete offerings of VSHN

Business model and pricing

Manage the business model and financial aspects per offering:

(Instance) Pricing, including variants, discounts

Professional services and consulting rates and billing schemas

Product costs (external and internal)

Revenue and margin

Product Roadmap

Maintained the Product Roadmap

Coordinate major upgrades and migrations to other products

Offering Partner Management

Coordinate the strategic partnerships in the scope of Partner Managers

99.3. Key Deliverables

Maintained Product Roadmap

Defined, documented offerings, including:

Pricing and billing definitions

Dependencies

Cost

Product vision clear to Product Owner of the offerings/product

Profitability per product

99.4. Key Challenges

Give the Product Owner and the Value Stream Team enough clarity on the vision, help with the meta-level aspects of a product, but don’t intervene with how the product is realized and operated

Focus on the high level, portfolio and profitability (economic overview) of all VSHN products vs. focusing on specific products in-depth

Enable the Product Owners vs. doing their job

99.5. Constraints

Product/Offering decisions happen collaboratively involving the Value Stream Team(s) and especially the Product Owner that are affected - directly or via Products Work Group Governance

100. Domain Sales & Account Management

Sub-domain of

Marketing & Sales

Accountable

Sol Team

Coordinator Sales

Virag Josephsen

Coordinator Account Management

Mia Egger

100.1. Purpose

Converting potential leads into customers, nurturing existing customer relationships, and ensuring successful onboarding of new customers to contribute to business growth and customer satisfaction.

100.2. Key Responsibilities

Sales

Develope, run and continously evaluate sales initiatives to turn marketing leads into customers.

Identify upselling and cross-selling opportunities with existing customers.

Own and handle sales deals / RFPs until won (or lost).

Coordinate and support Solution Architects to ensure Requirements Engineering and Solution Design.

Customer receive support for self-signup and self-service.

Active VSHN brand and offer presentation to increase probability to close deals.

Price and Contract negotiation.

Gatherng and evaluation of relevant sales data for strategic decision-making.

Manage strategic sales (channel) partners together with Marketing.

Account Management

Own and maintain customer data (CRM), including customer profitability.

Develop, execute and maintain customer segmentation and account management strategies to continuously understand customer needs and improve customer satisfaction and retention.

Personal contact with customers accordingto segmentation and strategy.

Preiodical (non-personal) data gathering of all customers.

Single-point-of-contact for the customer on the non-technical and strategic level.

Represent customer in value stream team work planning and reviews where useful.

Invoicing exception and customer escalation handling.

Ensure a smooth onboarding process for new customers.

Manage Customer Projects on the non-technical level to onboard customers and deliver our services.

100.3. Key Deliverables

Sales

Smooth buyer journey.

Continuous growth in customer base and revenue

Managed pipeline overview of potential deals at different stages of the sales process, including the needed metrics

Identified customer needs turned into product insights

Dashboard or other reporting of sales performance and revenue growth

Training on the Sales process and involved tooling

Account Management

Up-to-date data on our customers (orders, contracts, contacts)

Up-to-date metrics of all customers (primarily NPS, profitability)

Reports of bigger key customer development (for example change of buyer strategy, budget, new needs)

Support for VSHNeers for clarity about and communication with customers on the non-technical level

Collected customer feedback for Product Management

Documented and maintained processes of how we communicate, coordinate and work with our customers

Project delivery timeline and budget coordination and control

100.4. Key Metrics

Sales

Sales Pipline figures (leads, deals offered, sold, lost): recurring per month and one-time revenue, with probability and timeline

Account Management

Profibatiliy per Customer (revenue, effort, contribution margin)

Customer NPS (or similar)

100.5. Dependencies

Product Management & Marketing: Go-to-market strategy, Portfolio, pricing, Sales Material.

Pre-Sales Process: Deciding what to offer. The only place where decisions on unclear offerings happen.

Solution Architects to do the Requirements Engineering and Solution Design.

100.6. Definition of Done

To be defined as we learn more.

Onboarding

Customer knows all non-technical things about VSHN (how to work together), where to find documentation, etc.

Customer knows who to to contact how for non-technical inquiries.

Customer set up for self-service (for example APPUiO) and relevant supporting systems (Portal, Jira, Chat, etc.)

Correct recurring and one-time invoicing ensured.

Buyer to onboarding journey feedback collected, where useful.

101. Deciding to Deliver: Sales Offering

Accountable

Sales & Account Management, Team Sol

Lead

Mia Egger

101.1. Driver for this Agreement

As we transitioned from building custom Managed Solutions to a more standardized product portfolio, the need to address specific customer needs that don’t yet fit into our offerings has become apparent. As long as it aligns with VSHN’s vision, we are committed to finding ways to deliver, even if it requires customer-specific solutions. We see this as an opportunity to meet customers where they are, truly understand their needs, and use these insights to guide our product development towards actual customer value. This proactive approach can enable us to make informed decisions quickly, enhancing our sales process, driving business growth, and increasing customer satisfaction.

This is the opportunity we see in this, for the driver describing the problems that led to this, see VIP-302.

101.2. Summary

Those in contact with the customer to understand their business and technical requirements (see Requirements Engineering), typically the Solution Architect working with the Account Manager or Sales, create an initial draft of what to offer, usually a documented "Solution Design". This might need to include products, services, software, and tooling that we don’t officially offer now in order to fully address the customer’s needs. In a weekly meeting with all necessary Product Owners (not everyone) and the Product Manager, we decide together what we offer, how we offer it, who would build and run it, and what it needs to cost to ensure profitable business. This is the only place and time where we make such decisions, together. Only things that are perfectly clear from product definitions can be sold directly without going into this meeting.

101.3. 1. Preparation before the Meeting

We prepare topics in an Agenda for the meeting, to a point where we can come up with concrete proposals and decide in the meeting. In respect of our precious time and the effectiveness of the process we don’t discuss unprepared topics - A link to HubSpot, or an initial customer request is not a prepared agenda item.

SAs & Sales prepare the meeting agenda by Friday 17:00, including all relevant information:

Requirements documentation (coming from Requirements Engineering)

What do we already know? Link to:

Solution design (draft, coming from Requirements Engineering)

Which products or teams could contribute?

What do we need to decide?

Check if participation is needed

The Meeting Host reorganizes the meeting slots in a way that the least number of participants need to join by Monday 14:00, informing all attendees via the group chat.

All potential participants (Product Owners, Product Manager, Solution Architects, Account Managers and Sales) are required to check which slots (agenda items) they need to attend:

If there is no reason to join they don’t join, but keep the meeting blocker to be ready to be called in (zoom invite) anytime - they must be reachable. This is a key aspect of this concept, it isn’t optional.

If they can’t attend or are not reachable, they must proactively inform the Meeting Host to decide who can step in. They should also ensure the stand-in is briefed well on the topic before the meeting.

101.4. 2. The Weekly Meeting

Meeting Slot: Every Tuesday 10:00 to 10:45 remote-only via Zoom.

Meeting Agendas: in our wiki here.

We go item by item:

What can we offer to fulfill the requirements, and how? See How to decide what we offer and how.

When could we deliver what? (And by when an offer needs to be signed to be able to keep this date)

Who (which team) does what?

Estimate one-time effort to offer (and what to do on our side).

Define (or at least estimate) recurring costs for unclear products, custom solutions or MVPs.

Possible alternatives in case we can’t provide something to still offer a full solution.

We are here with an expectation of not accepting a "we don’t know". If a solution can’t be found right away within the meeting (for example someone else from a team needs to be consulted) we agree on the next concrete action and who will do it and until when when Sales (or who ever represents the Agenda Item) gets the needed answer or input to move forward.

101.5. 3. Follow-up after Meeting

Solution Architect finalizes design, gives input for offer.

Inside Sales creates the offer.

Sales sends out the offer and follows-up with customer.

Depending on the probability of the deal, the Product Owners might inform their team to not get surprised when we get the order soon.

When the offer gets accepted

A (Key) Account Manager is in the lead for the project and organizes the kick-off between all involved stakeholders.

We stick to what we decided and documented in the meeting. Small changes can directly be coordinated with the affected Product Owners.

If major scope changes occur, we may drag the issue back to the next meeting to revise our decisions and offer whatever the scope change brought up to the customer.

101.6. Responsibilities

Function / Role
Who

Meeting Host

Mia Egger for Customer Experience Team

Representing Agenda Item

SA, Account Manager or Sales

Representing VSHN Portfolio and Product Pricing

Product Manager

Evaluation of this Process and Meeting

Mia Egger for Customer Experience Team

Representing the Team and Product

Product Owners

101.7. Constraints

Management must be involved in the decision-making process and qualified objections need to be addressed before offering, if:

we are offering something that would require VSHN to change core processes, organize ourselves differently, or that would have a major impact on our work culture,

or we see a bigger financial or legal liability risk, for example guaranteeing delivery or levels of services with high potential penalty payments that exceed one month service fees.

All time definitions are Zurich time. This agreement is tracked and reviewed as Governance Item VIP-302.

102. Customer Project Management

Accountable

Account Managers of Sales & Account Management, Team Sol

102.1. Driver for this Agreement

Project Management is essential during the customer onboarding of complex IT solutions as it streamlines processes and ensures efficient delivery. It facilitates clear communication between customers and technical teams, supports the Product Owner in planning the required work, fosters effective coordination, and with that provides a seamless onboarding experience for our customers.

During our Sales Offering Decisions, we pre-define which teams would contribute, how we would manage the project at a high level, and who would own the onboarding. To simplify these decisions, we need to define how we conduct project management in general and who is responsible by default for ensuring onboarding project management.

This is the opportunity we see. For the driver describing the problems that led to this, see VIP-303.

102.2. Process and Responsibilities

When we have an order for something that requires an Onboarding Project (meaning we have to coordinate deliverables, expectations, timeline, and budget between our value stream teams and the customer), Account Management owns the non-technical onboarding, more specifically, one (Key) Account Manager takes the lead.

They Account Manager has to coordinate everything, but can’t do the technical part of defining work packages and tickets or do the more technical communication with the customer side. For this they depend on engineers from the team, and usually especially the Solution Architect who designed what the customer ordered. Still, the Account Manager stays in the lead (not the Solution Architect), but others have to contribute.

Sales & Account Management, usually the Inside Sales, performs the general non-technical customer onboarding.

Account Management defines who the (Key) Account Manager is.

The Account Manager:

organizes and hosts a kick-off meeting with the customer and needed engineers from VSHN.

begins to work with the Solution Architect who was involved in the case and the required Product Owners to define the needed work in the Value Stream Teams.

keeps the customer and the involved teams updated.

directly or indirectly via the Product Owner, joins the involved team’s planning and sprint reviews to check whether the work done effectively moves the project forward, brings in the needed feedback, and updates the customer.

ensures budget control according to the Sales Order and recurring services, while also ensuring that recurring Managed Service billing is working correctly.

for larger onboarding, initiates the project retrospective with the involved parties to continuously improve this process.

For AppOps and AppFlow projects: The Technical Project Manager of Nunki takes the technical lead and coordinates with the Account Manager.

Technical Project Manager in Nunki is currently in the role of their Product Owner.

This agreement is tracked and reviewed as Governance Item VIP-303.

103. Domain Customer Support

Accountable

Avior Team

Delegator

Business Operations (Management)

Lead

Arngard Brülisauer (Customer Support Lead)

103.1. Purpose

VSHN offers numerous products and services, produced, set up, and managed by various value stream teams. After customer onboarding or the setup of new services, customers often have needs such as support requests, service changes, or the need to address service disruptions. These needs arise regardless of the specific team involved, and customers expect professional handling of such requests, often around the clock.

We require a mechanism to centrally own and professionally handle customer requests to ensure expectation management and to refine the request until it’s clear enough for the value stream team to work on. Additionally, it’s crucial to maintain professional coordination and communication until the request is closed, including for tasks initiated from our side, such as changes to services and incidents we’ve identified.

Currently 2nd Level Triage and Support is still mainly covered through Responsible Ops by the Value Stream Teams directly. Transforming this into a centralized Customer Support and mid to long-term into a separate Team is an experiment that started 2023-03-01 and was reviewed to continue on 2023-07-21. With our new Customer Support Lead we have someone who is evolving and leading this endeavor.

103.2. Stakeholders

Customers: Expect professional coordination and communication and that we address their needs in time.

Value Stream Teams: Need assistance with less technical customer communications and expect refined tasks, including customer expectations, understanding urgency and importance, and other frameworks.

The Delegator: Needs a central place where we can see what is happening at the Customer Support front and what is working well and what needs to improve in the process, to be able to support the company wide improvement.

Sales and Account Managers: As they deal with customers at the overall customer relationship level, rather than at the individual ticket level, they need to have an easy overview of what is happening with their customers, and they need to be informed when things are not going well.

103.3. Key Responsibilities

All the following relates to individual customer requests, not work that was sold in the scope of consulting or onboarding projects.

Customer Requests Triage and Refinement

Communication with customer to understand what they need and how they expect us to work together.

Coordinate with Value Stream Team(s) until clear who can do what until when.

Ensure the task and constraints are clearly documented.

Get approval from customer on scope, timeline and costs.

Assign refined tasks to the value stream team.

Identify requests for new business (up selling) and either:

redirect to Account Manager and represent the customer’s need,

or assist customer to self-service to get the new service.

Oversee Coordination and Communication

Track all task that were handed over to the team to ensure: proper coordination, professional communication and execution within agreed boundaries (time, scope and budget)

Keep customers informed when work is pending else where, for example in one or multiple Value Stream Teams.

Take over non-technical communication with customer during incident resolution.

Represent Customers

For the relevant outcomes in (Sprint) Reviews of the Value Stream Teams.

For work refinement with the PO of Value Stream Teams.

Process

Own and evolve our Support core processes (including OnCall and follow-the-sun locations):

24/7 Incident Management

24/7 Triage and Support

103.4. Key Deliverables

Refined tasks for the Value Stream Teams

Professional customer communication on the task level

An (automated) overview of all open and done tasks per customer

Documented concepts and processes how-to address the Key Responsibilities, including internal awareness and trainings

Go-to person and escalation point for issues within the Key Responsibilities

103.5. Dependencies

Contribution of the Value Stream Teams (24/7)

Every value stream team needs to provide a defined way to:

immediately start working on incidents reported by customer,

support request refinement, and do the work that this involves, in reasonable time,

work on urgent customer requests within reasonable time.

(Virtual) team members to cover shifts in Customer Support.

Follow-the-sun locations and / or people ready to cover on-call shifts.

103.6. Key Challenges

The majority of our business is quite customer specific and deeply technical, refinement of tasks usually needs engineers with the right expertise but also account managers to contribute constraints and expectations in a reasonable time or make that information easily available. It’s not expected that Customer Support can do the refinement on their own (maybe at a later stage with dedicated engineers). Owning refinement therefore means to make sure the ticket gets refined, usually by engineers, while Customer Support would ensure that it happens, including professional communication with the customer.

103.7. Monitoring and Evaluation

Review with the Delegator representative every 2 months

Feedback from Value Stream Teams (usually Peer Review) - Effectiveness of Triage and Refinement

Customer Feedback on support effectivity and response times: Ticket level and customer level surveys.

103.8. Accountable Team

Starting a new Team for this Domain is an experiment. In the initial phase, the plan is that people from Value Stream Teams provide the needed workforce, similar to the Triage part of to the old Responsible Ops.

Avior

Arngard Brülisauer (Customer Support Lead)

Rotating members from Value Stream Teams

This domain is tracked and reviewed as VIP-253

104. Requirements Engineering and Solution Design

104.1. Summary

When a standard VSHN product (often a self-service product) is not sufficient to meet a customer’s needs, we need to find out what problems and benefits (technical and business) the customer is looking for and develop a solution to meet their needs based on VSHN services and products and possibly things we don’t already have. During this, we might need take decisions on what whether we offer something, how and when and who would do it, to be confident enough to offer and sell it.

This process describes high-level requirements engineering and defining solutions to offer, while Deciding to Deliver - Sales Offering describes how we make the needed decisions before each round of offering. The two processes work together to ensure that we have enough information to make sales decisions, but also to influence the solution design so that we can actually deliver it and run it profitably later.

104.2. Process Description

This is a simplified view, details have to be worked out by the Solution Architects and Sales.

If there is a concrete request for a new. or an existing customer, Sales owns this request and creates an issue in Jira.

A Solution Architect pulls this request from the Backlog and starts working on it together with Inside Sales to address the request. This can include anything (and more) of:

Meetings to understand the customer’s challenges and requirements, and documenting them.

Doing (paid) pre-sales Consulting or Workshop.

Coordinating with Product Management and Product Owners on what we can and should offer.

Working together with other Solution Architects to get other perspectives and more in-depth knowledge.

Designing and documenting a Solution, before it is offered, including:

Estimate effort of iterations we’ve to deliver.

Define which products / services need to be in the offer.

Find out pricing for undefined things.

Determine Security & Availability requirements such as encryption, backup, fail-over.

Sales keeps the commercial lead, one Solution Architect keeps the technical lead for the request.

Works with Sales or Account Manager.

If the solution is ordered, the Solution Architect support the involved Value Stream Teams and Account Manager with Project Management, until everything is clear and set up for the onboarding to start.

During onboarding, the Solution Architect is available on short notice to support Project Management, Product Owner or involved Engineers.

104.3. Monitoring and Evaluation

Review this process after 2 months, then every 4 months: Retros with all involved parties.

Evaluation Criteria

Does this process address our need (driver) effectively?

This process is tracked and reviewed as part of as VIP-189

105. 24x7 Operations

This domain is about all organizational topics (VIPs) regarding how we handle incidents around the clock, so that the accountability is clear and current and future needs can be addressed and coordinated.

Accountable Circle

Operations Work Group

Delegator

Management

Lead by

To be defined

105.1. Key responsibilities

Organize handling of incidents during office hours for:

VSHN Switzerland

VSHN Vancouver (and other follow-the-sun locations)

Organize handling of incidents outside office hours (on-call).

Know the requirements of 24x7 incident handling, for example from our product’s SLAs and existing customer contracts.

Select tooling needed for the above: mainly how we do alerting.

Facilitate decisions regarding on-call compensation.

105.2. Key Deliverables

Documented guidelines for teams how incident handling has to work (to meet the requirements):

Shifts to cover

Alerting

Expected response times

Scope of incident handling

Requirements of incident handling in ticket system, for example all Jira issue types and workflows.

Documentation on on-call compensation.

Yearly Reporting and pay out of on-call compensation.

105.3. Dependencies

Work together with the Monitoring and Alerting Interest Group.

105.4. Constraints

The periodic maintenance carried out by Solution Teams isn’t the scope of this domain.

How systems and services are monitored isn’t the scope of this domain - only alerting is.

105.5. Risks

This group is a Work Group and therefore accountable. This accountability requires that members reserve and invest time to work through and drive forward the topics in this domain.

105.6. Evaluation Criteria

Relevant Drivers (VIPs) which fall into this domain are effectively addressed.

24x7 Operations meeting the requirements of our business.

On-call duty within the scope of the legal regulations for employees.

This is a sub-domain of Customer Solutions and is tracked and reviewed as VIP-145.

106. On-Call

Every active engineer in our tech teams has the duty to participate in the on-call organization after their trial period.

Exemptions from this duty have to be requested from People Operations (for example medical reasons). People Operations review active exemptions every 6 months if reasonable.

106.1. Important wiki pages

On-Call Agreements

On-Call Guide

Prepare for On-Call

VIP-144 - On-Call Organization (compensation documented here)

107. Rulebook for Planned Work Ticket Workflow

107.1. Purpose

For Scrum and Kanban Teams: this article shows what issue types and states you can use to visualize your planed-work items.

This is not a one way workflow with just one "step by step manual", this is a rulebook that explains in which way tickets can be moved between the different states of the planned work workflow.

107.2. General Principles

To eat an elephant, one needs to cut it into bite sized pieces. This means that if we want to build something big, we need to cut down the bigger task into work items that we can incrementally work on.

We are also pledged to deliver value in smaller iterations. So our main focus when cutting down work should lie on doing it in a way that delivers a smaller but usable result each time.

To be effective in this, we thoroughly plan and prepare our work, before implementing it. Here are the Ticket types and Workflow States we us to do this. Tickets can freely flowinside the preparatory phase states. And once they have been selected, then again can freely flow between the implementation-phase states.

107.3. Issue Types

Listed in order of relevance to most readers (engineers)

Project/Change

Type
Purpose

Task

A work package of a project

Change

An atomic change on an existing system
More considerable changes requiring numerous tickets might be handled as a project.

All the above issue types use the "Planned Work" workflow.

Product

Type
Purpose

Story

Atomic work package

Bug

Something out of the order has been observed and needs to be investigated/fixed.

All the above issue types use the "Planned Work" workflow.

Maintenance

Type
Purpose
Jira Template

Maintenance Task

Task

Maintenance Procedure
Mandatory use!

To ensure effectiveness and work quality in maintenance, please adhere to the Maintenance Procedure & Template.

The Maintenance Task uses the Simple Task workflow.

Starts at OPEN and moves to CLOSED, that’s it.

Meta Issue Types used in Customer Projects

Type
Purpose

Epic

A collection of tickets to work towards a common goal. Epics can be used to track bigger features or projects.
In Comparison to the issue type Project, Epics provides some filtering and planning features, while projects still need to be used for billing purposes.

Operations

Link to Odoo for billing purposes.

Project

Link to Odoo for billing purposes for projects.

Project Milestone

Link to Odoo for billing purposes for parts of a project.

107.4. Workflow Diagram

107.5. Preparatory Phase: New to Ready (Backlog)

NEW

Status definition

When created, the issue gets assigned this state. This state is about understanding the subject, linking them to relevant tickets (projects, epics).

Transition to NEW

When a ticket was in one team and needs to get reassigned to another team, then the ticket will automatically go back to the status NEW, to make sure it does not get lost or disrupt the workflow in the new team.

Next possible transitions:

REFINEMENT clarify

ON HOLD not now

BACKLOG ready

CLOSED deemed not relevant.

REFINEMENT

Status definition

The issue should be worked on in the foreseeable future, but the expected outcome needs to be clarified. Action required.

Clarify the following aspects:

The scope "what" of the ticket is defined and clear?

It has to be estimated how much work it is. (for example, story points)

Priority and budget: when do we need to do it? And does customer consent to costs?

Rule for Transition to REFINEMENT

VSHN-Team must be set.

Ticket must have a description.

Link related tickets, if applicable.

Next possible transitions

ON HOLD not now

BACKLOG ready

CLOSED deemed not relevant.

ON HOLD

Status definition

We are confident that this is something we have to do, or we would like to do, but it is unclear when that is supposed to happen.

*Passive State –*with automated handling, to avoid permanently forgetting about it.

Rule for Transition to ON HOLD

Set delay time (in months)

Comment as to why it’s put on hold.

Inform customer, if related to a customer project or ticket.

Automation:

Ticket gets unassigned automatically.

After the set number of months, this ticket will be automaticallytransitioned to Refinement. This way, we know it requires our attention again.

Next possible transitions

REFINEMENT clarify

BACKLOG ready

CLOSED deemed not relevant

BACKLOG

Status definition

The ticket is ready and can be selected.

Rule for Transition to BACKLOG

The scope of the ticket must be clear enough to make an estimation (story points or hours)

Rule for assigning it to a sprint

Customer must have consented to costs. When in doubt, ask the Project-Manager, CAM or Avior to help sort this out with the customer.

Next possible transitions

REFINEMENT clarify

ON HOLD not now

SELECTED start work

IN PROGRESS is being worked on

107.6. Implementation Phase: Ready (Backlog) to Done

BACKLOG

Status definition

Backlog For Scrum Teams only: Backlog items that have been assigned to sprint.

Next possible transitions

REFINEMENT more to clarify

IN PROGRESS is being worked on

SELECTED

Status definition

SELECTED is for Kanban Teams only: backlog items that have been selected to get worked on this week.

Rule for transition to SELECTED

Customer must have consented to costs. When in doubt, ask the Project-Manager, CAM or Avior to help sort this out with the customer.

Next possible transitions

REFINEMENT more to clarify

IN PROGRESS is being worked on

IN PROGRESS

Status definition

The assigned team is actively working on the implementation of it.

Rule for Transition to IN PROGRESS

Only put tickets in this state if you are actively working on it and not waiting for anything else to happen first.

Next possible transitions

PENDING internal wait

WAITING FOR MAINTENANCE Maintenance

REVIEW get it checked

CLOSED all done

PENDING

Status definition

Work is in progress somewhere else inside VSHN. Used for tickets while waiting for a maintenance task to get done. Used for tickets, that have a related ticket, where work must get done shortly by a different team or person.

Passive State – with automated handling, when a ticket is untouched

Rule for Transition to PENDING

Define numbers of days before ticket needs attention again. (1-7)

If the ticket is depending on a different ticket, interlink them correctly (causes,waits for,relates to, or by mentioning it in the comment)

Add comment to state, what it is waiting for.

Automation

Ticket gets unassigned automatically.

After the set number of days, this ticket will be automatically transitioned to "in progress". This way, we know to carry on with our work on it.

Next possible transitions

IN PROGRESS work on it now

REVIEW get it checked

CLOSED all done

WAITING FOR MAINTENANCE

Status definition

This status is only used when a ticket needs to get worked on in maintenance and if there is a reason not to open a dedicated maintenance ticket.

Template maintenance task must be used and correctly applied.

Rule for transition to WAITING FOR MAINTENANCE:

Due date must be set.

Make sure no important and relevant information is missing for the Engineer carrying out this task.

Next possible transitions

REVIEW get it checked

IN PROGRESS work on it now

CLOSED all done

REVIEW

Status definition

REVIEW Implementation has to be reviewed by another VSHNeer. Polaris and Vega will also use this for external review.

Next possible transitions

IN PROGRESS still something to fix right now

CLOSED all done

CLOSED

Status definition

Nothing left to be done. Good job!

Or ticket has become obsolete.

Next possible transitions

CLOSED is a terminal state: no transitions allowed.

If a ticket was closed less than 48h ago, it can be reopened to the state it had before closing it.

107.7. Customer Portal Rules

Customer sees all tickets in their project.

Customers can read and add comments. In this workflow, where we are working on bigger and more complex tasks for the customer, customer can only close a ticket, if it’s in state REVIEW and not in any other.

108. Sales On–Boarding Process

108.1. Introduction

We would like our future and existing customers to know how our sales and onboarding process works. Therefore we’ve specified what happens in each step. This process involves not only Business Development and Customer Success Managers, but also Solution Architects, Service-, and Project Managers. This is because we would like to offer our future and existing customers only the best possible solution. We want our customer to understand the reason behind this.

In order to offer a good solution and ensure the happiness of new and existing customers we need to ensure that different stakeholders are working together efficiently.

108.2. Explanation of the Steps

Step
Actions
Who is involved at VSHN

Contact and qualify

First contact with customer - identify the right point of contact within the customer’s organization

What are the problems the customer is facing? 

Identify scale of possible proposal/project

Is there an opportunity for us and the customer?

If so, set up Solution Architecture meeting

Business Development Manager

Solution Architecture meeting

What are the customer’s technical needs?

How can VSHN solve them?

Meet with the customer to find the right solution

Define timelines on both ends 

Business Development Manager

Solution Architect

Design solution / Feasibility

Document solution architecture and offer contents

Solution Architect

Create and send offer

Create offer based on the solution identified 

Review the offer with the Solution Architect

Confirm the VSHN timeline with a Project Manager

Send the offer to the customer (offer, SLA, Framework agreement …​)

Business Development Manager

Customer Review

Offer has been sent to the customer

Negotiation between customer and VSHN

For special deals or contracts, the BDM escalates to product management or legal as necessary

Business Development Manager

Customer Decision: Won’t or can’t

Mark deal as closed lost and document the reasons

Business Development Manager

Customer Decision: Will do / Setup Customer

Inform the Customer Success Manager and Service Manager that the customer has signed

Internal handover with all stakeholders

Inform and introduce customer to new roles and responsibilities (CSM, SM, TSM, PM) 

Business Development Manager

Setup Customer

Change prospect to customer in ERP

Create Customer In Jira, Control Panel, Wiki page

Customer Success Manager

Initialization: Consulting

Create the necessary ticket

Allocate internal resources (find VSHNeer)

Schedule Workshop

Customer Success Managers

Project Manager/Service Manager

Initialization: Standard Service

Define requirements with Tech VSHNeer

Create Ticket and hand over to tech team

Inform about status of ticket

Service Manager

Initialization: Project

Create Project in Jira

Create detailed concept, planning

Project Manager to lead project and review rounds with the customer

Create Tickets together with engineers

Project Manager 

Implementation

The solution/service gets implemented

The Project Manager works closely with the technical point of contact from the customer´s side and keeps that person informed

CSM acts as escalation and feedback point 

Customer Success Managers

Project Manager

Technical Service Manager

Project / Service review

Evaluate delivery and support

Feedback meeting to evaluate the implementation with all stakeholders

Customer Success Managers

Project Manager

Technical Service Manager

Follow up

Ensure Ongoing Success for existing customer

Customer Success Review meetings

Upsells

Customer Success Managers

109. How to do Avior Triage and Support

Disclaimer

The old "Responsible Ops" becomes obsolete through this new Role and way of working. But, we still have to define in which way, every team can make sure to always have someone reachable to react to incidents and support requests. This will be defined on a different page.

109.1. Jira

Triage

Servicedesk Board with all Teams and Tickets

Avior Service Desk

https://ticket.vshn.net/secure/RapidBoard.jspa?rapidView=185

Service Desk all Teams

ticket.vshn.net/secure/RapidBoard.jspa?rapidView=186

109.2. Important Links

Service Desk Workflow

Customer Communication Guidelines

Incident Process

Service Levels (2023)

Support Plans (2023)

Legacy Service Level Agreement 2020-2022

Older than December 2020

109.3. Your Duties

1. Be ready and punctual to begin your shift on time

Rotationplan in OpsGenie: vshnag.app.opsgenie.com/schedule/whoIsOnCall ⇒ Avior Triage and Support

Finn and Arngard have their fixed shifts every week.

For Aldebaran and Polaris, there is an Ops Genie alert to the assigned person at the start of their shifts.

Rotation Q4 2023 from Oct. 1. to Dez. 31.

Monday
Tuesday
Wednesday
Thursday
Friday

09:00-13:00

Arngard

Finn

Finn

Arngard

Finn

Polaris

13:00-18:00

Arngard

Arngard

Aldebaran

Aldebaran

Polaris

2. Set your Zoom to receive hotline calls

Go to your zoom profile.

Click on "receive Team calls"

Activate the "Technical Support" hotline.

3. Check the triage board every ~10 min

Here ist the link to the Customer Service All Teams Board

4. Triage incoming tickets promptly

Choose Issue Type: Service Request, Information Request, Problem or Incident

Assign VSHN-Team: Avior, Sol, Aldebaran, Polaris, Schedar, Vega or Nunki.

Set priorityhttps://products.vshn.ch/support_plans.html#_severity_levels[(see Product definition)]

Submit

Delete incoming SPAM:_⇒ click on "more" in the ticket menu and select "delete", then confirm._

You can drag and drop tickets, in the kanban view, for easier handling.

Triage Screen

Service Desk Issue Types

Type
Purpose

Service Request

Customer requests support or a service.
(for bigger requests, an additional change ticket will be created by the VSHN-Team working on it.)

Information Request

Customer requires information on our services and products.

Problem

The customer stumbled upon a problem in his systems or our services to them.

Incident

Customer reported a malfunction or interruption of services. And it needs urgent fixing …​

If you are unsure…​

Check for previous tickets of the same customer and of a similar topic to figure out to which team something belongs.

Ask in #operations or in #avior if someone else might know it.

5. If urgent, alert the responsible team

It is urgent if a customer reports an Incident.

…​ if they are facing a problem, that has a bigger impact on their work or production sites.

…​ if a customer says so, believe them in a first instance.

As a curtesy to our colleagues, please alert Schedar, Vega, Nunki and TempAppOps for any incomming tickets, as they only rarely receive new customer-tickets.

⇒ Alert the Team via their team channel in Rocket Chat.

6. Take care of any tickets open in Avior Service Desk

Go to this Board:https://ticket.vshn.net/secure/RapidBoard.jspa?rapidView=185&useStoredSettings=true[Avior Servicedesk]

Check for open tickets and tend to them accordingly…​

Be polite and professional in tone when answering customers requests. See also the Customer Communication Guidelines in this Handbook.

Additional Duties of Customer Service Lead or their Deputy

Double-check the VSHN Service Desk Board for unattended tickets

Board: Customer Service all teams

Use Filter: Over 2 days no update

You can filter per team additionally.

Use "no Comment" filter to check for any tickets where Customer has recieved no ansver from us yet. this must be EMPTY before lunch and before end of the day.

Check for failed Josy tickets

Check for the oldest of these Tickets, if any seem to have been missed by the assigned team. Gently remind them where needed.

Enable and support the other teams in CS-Communication

Help sort out unclear Tickets.

Help clarify billing questions, before work begins.

Provide oversight and "failsafe - controlling" of tickets in Servicedesk workflow.

110. People Operations

Others might call this human resources, as our most important core value is to care about people we call this People Operations instead. It has special constraints and is partly regulated by law. PeopleOps is the personnel administration of VSHN. This includes routine tasks of the personnel management, doing all the adminstration work from hiring VSHNeers over helping them with various administrative matters, paying their salaries, handling contract changes and making sure, even if unfortunate, an off-boarding happens as smooth as possible for both parties.

Sub-domain of

Central Services

Accountable

Dawn Nitsche (People Operations)

Delegator

Business Operations (Management)

110.1. Key Responsibilities

Payroll Accounting

Social insurances

Salary increases

Monthly and yearly payslips

Employee Contracts

New contracts, contract changes and contract termination.

VSHNeer Onboarding

New VSHNeer administrative bootstrapping

Moderate workplace requirements and ordering.

Contact with new VSHNeer until on-boarded in the Team with a Mentor.

VSHNeer Offboarding

Ensure Information Security and correct removal of access rights.

Create and hand out certificate of employment.

Expenses

Check and pay expenses on a monthly basis.

Employee Administration

Yearly vacation budget per VSHNeer, special vacations

Public holidays

Address changes

Check VSHNeer attendance, including attendance to work-log ration cross-check.

Yearly on-call compensation payment

Manage personal education budget per VSHNeer.

Check and manage

Hardware budget.

Personal Education budgets.

Request and file debt collection register and criminal records.

110.2. Recruiting

Make job offerings to a candidates based on the decisions by Management.

To avoid mistakes and simplify contract negotiation, job offers are communicated to candidates exclusively through People Operations. In the absence of People Operations, management can send out carefully reviewed job offers if absolutely necessary.

VSHNeer care recurring duties

Send wishes and presents for birthdays, marriage, new born, on- and off-boarding, etc.

Coordinate with Marketing to organize swag for VSHNeers (T-shirts, etc.).

Help with authorities (new hires moving to Switzerland, military service and similar).

110.3. Constraints

Planning and approving vacations is done in the teams.

Final decision to hire or fire a VSHNeer is made by the Management.

110.4. Evaluation Criteria

Defined open positions are filled with suitable candidates.

VSHNeers are correctly employed and able to work.

Salaries are payed.

Legal obligations as an employer are met.

This domain is tracked and reviewed as VIP-36

111. People Care

VSHN is developing more and more in the direction of self-organized teams. However, we’re finding that VSHN employees sometimes want someone to talk to who is independent of the team, especially when it comes to very personal issues. VSHN also needs to know how our employees are doing (for example, to measure our eNPS 2-year goal). Electronic surveys alone don’t cover all aspects and we risk overlooking some VSHNeers.

People Care is this escalation point and further responsible for obtaining the required metrics and feedback, in addition to providing the ability to track development plans for VSHNeers in a confidential manner.

Sub-domain of

People Operations

Accountable

Dawn Nitsche (People Operations)

Delegator

People Operations

111.1. Key Responsibilities

VSHNeers have a point of escalation according to the Conflict Resolution Process:

for personal issues or when they feel that they’re not heard, when an issue can’t be solved within the Team or other Accountable Circle.

if they’re disappointed with the (quality of) work or behavior of another VSHNeer, after a direct discussion with the person and their team hasn’t led to an improvement in the situation or isn’t possible for personal reasons.

People Care knows how individual VSHNeers are doing, directly or indirectly (for example through the Team Admin):

Are they happy with VSHN and their job?

What are their plans to develop and grow personally within VSHN?

What impediments do they face, which they can’t solve themselves.

Behavior with other VSHNeers, personally and professionally (customers and partners).

Understanding of and fitting our company values.

While People Care focuses on personal support for individual VSHNeers, Agile Coaching and Team Facilitator focuses on systemic coaching within and between teams.

111.2. Key Deliverables

eNPS metrics for the company.

Confidential development plans for VSHNeers who need help.

Final decision on firing VSHNeers are brought up with the Management without delay.

Employee Feedback

Gather feedback from VSHNeers on how they’re doing personally. This should be done in 2 ways:

A tool that asks for (anonymous) feedback from VSHNeers on a regular basis, calculating reports automatically (data driven).

At least yearly

feedback talk with every employee.

(attend) retro or a similar meeting to gather feedback from every team.

Personal Development

Together with the affected VSHNeer PeopleCare develops a personal development plan, if there is the need for it. Goals of such a development plan could be:

Personal Coaching as requested by the VSHNeer.

Setting goals of personal development as requested by the VSHNeer.

Setting expectations for the VSHNeer on what needs to change when in order for them to stay with VSHN.

Necessary change in personal behavior, quality of work, or building of missing skills to meet the requirements of the job for which the person was hired.

Defining deadlines and decision points including defined consequences:

What happens if the planned personal development isn’t on track or a defined goal hasn’t been reached? For example: Ordered education, suspension of salary increase or ultimately contract termination.

111.3. Dependencies

Support for People Care

Others actively help with development plans, feedback talks, etc. as invited by People Care.

A group of mediators support People Care (mediate between fronts).

People Care

helps people to find their solutions. Ultimately solving the personal challenges is done by the affected VSHNeers, for exampling when changing a team.

doesn’t give psychological support, but can externally organize it depending on the situation.

works with Corp IT regarding tooling and to gather feedback automatically.

111.4. Constraints

The Management is informed about planned consequences in Personal Development and has to consent to them.

Anonymous data about VSHNeer happiness (for example eNPS) is periodically presented and accessible by everyone.

Feedback and other personal information collected in the scope of People Care is kept confidential by default. Shared with management on a case-by-case basis only if needed (business relevant).

People Care mediates between fronts with a neutral position "as the company" (according to our Beliefs, Values and our VIP-157 - VSHNary Manifesto Proposal Forming ).

Peer 1-on-1 reflection / review meetings are complementary to the above, not a replacement.

111.5. Key Challenges

Avoid People Care becoming a "complaint box," a way to drop problems, hoping that someone fixes it - which isn’t VSHNary.

111.6. Evaluation Criteria

People Care is used by VSHNeers.

VSHN has the data we need to check where we’re in terms of VSHNeer happiness.

This domain is tracked and reviewed as VIP-113

112. Debt Collection Register and Criminal Records

112.1. Overview

People operations is responsible to collect excerpts of debt collection (Betreibungsregister) and criminal records (Strafregister).

Why

We do this to fulfill the ISO 27001 control A.7.1.1:

Background verification checks on all candidates for employment shall be carried out in accordance with relevant laws, regulations and ethics and shall be proportional to the business requirements, the classification of the information to be accessed and the perceived risks.

~ ISO/IEC 27002:2013 7.1.1 Screening

VSHN decided to repeat this for the employees every year to comply with audits.

112.2. Responsibility People Operations

Ensure all employees has handed in their excerpts (handled with ISMS-1011).

Ensure new hires file their excerpts during onboarding process (ensured with TEMPLATE-25).

Ensure the excerpt is stored in the HR folder of the employee and is deleted once not needed any more.

Check every excerpt for entries. If there are entries approach Management to decide how to mitigate the risk with that person.

Management has to decide about the steps if someone has entries in their excerpts which could be a risk for VSHN, its customers, or violates our Values.

Problematic Entries

Lot of unpaid bills in the debt collection could be problematic to work for our customers in the financial industry. The common understanding of such entries is, that people with such entries are more likely to be susceptible for fraud.

If there are entries in the criminal records about financial fraud this people cannot work for the financial industries and therefore VSHN will not hire such people.

112.3. Employee’s Duties

Every employee must hand in their excerpts with signing the yearly salary increase contract amendment.

Of course VSHN is paying for that so you have to add it to your Expenses.

How to Get the Excerpts

Switzerland

Criminal Record

You need a copy of your identity card or your passport.

You need a printer to print out the request.

You need a stamp and an envelope.

Go to www.e-service.admin.ch/crex/cms/content/strafregister/uebersicht_de and follow the steps.

Pay it with credit card or Twint (you could also pay it via other ways, but that’s the easiest thing).

Send it via good old postal mail.

Please send an electronic copy of the certificate to Peopleops by email.

Debt Collection Register

Go to the homepage of your Gemeinde and search for Betreibungsregisterauszug. You can usually order one there.

Please send an electronic copy of the certificate to Peopleops by email.

Canada

Criminal Record

You can get a criminal background check from Triton on www.tritoncanada.ca.

Expense the costs of the record.

Dept collection register and credit score

You can get your credit report that includes a dept collection report from Equifax> www.consumer.equifax.ca/personal/products/credit-score-report/.

Ensure you use the free report.

112.4. Based on

Based on "Erläuterungen zur Personensicherheitsprüfung von Mitarbeitenden" from the EDÖB.

We ensure that we do a background check in our ISMS.

We ensure that we do background checks in our ISAE 3402 report, see ISAE 3402 control 5.10.7.

There are customers asking for such background checks.

This process is tracked and reviewed as VIP-216

113. Annex to the Declaration of Confidentiality

113.1. Preamble

The following excerpts from Swiss law must be read by employees. It is particularly important to take note of them regarding clients in the financial services sector.

Wording of legal texts as of January 1, 2019.

113.2. Swiss Criminal Code

Art. 143 - Unauthorised obtaining of data

Any person who for his own or for another’s unlawful gain obtains for himself or another data that is stored or transmitted electronically or in some similar manner and which is not intended for him and has been specially secured to prevent his access shall be liable to a custodial sentence not exceeding five years or to a monetary penalty.

The unauthorised obtaining of data to the detriment of a relative or family member is prosecuted only on complaint.

Art. 143bis Unauthorised access to a data processing system

Any person who obtains unauthorised access by means of data transmission equipment to a data processing system that has been specially secured to prevent his access shall be liable on complaint to a custodial sentence not exceeding three years or to a monetary penalty.

Any person who markets or makes accessible passwords, programs or other data that he knows or must assume are intended to be used to commit an offence under paragraph 1 shall be liable to a custodial sentence not exceeding three years or to a monetary penalty.

Art. 144bis - Damage of data

Any person who without authority alters, deletes or renders unusable data that is stored or transmitted electronically or in some other similar way shall be liable on complaint to a custodial sentence not exceeding three years or to a monetary penalty. If the offender has caused major damage, a custodial sentence of from one to five years may be imposed. The offence is prosecuted ex officio.

Any person who manufactures, imports, markets, advertises, offers or otherwise makes accessible programs that he knows or must assume will be used for the purposes described in paragraph 1 above, or provides instructions on the manufacture of such programs shall be liable to a custodial sentence not exceeding three years or to a monetary penalty. If the offender acts for commercial gain, a custodial sentence of from one to five years may be imposed.

Art. 147 - Computer fraud

Any person who with a view to his own or another’s unlawful gain, by the incorrect, incomplete or unauthorised use of data, or in a similar way, influences the electronic or similar processing or transmission of data and as a result causes the transfer of financial assets, thus occasioning loss to another, or immediately thereafter conceals such a transfer shall be liable to a custodial sentence not exceeding five years or to a monetary penalty.

If the offender acts for commercial gain, he shall be liable to a custodial sentence not exceeding ten years or to a monetary penalty of not less than 90 daily penalty units.

Computer fraud to the detriment of a relative or family member is prosecuted only on complaint.

Art. 162 -  Breach of manufacturing or trade secrecy

Any person who betrays a manufacturing or trade secret that he is under a statutory or contractual duty contract not to reveal, any person who exploits for himself or another such a betrayal, shall be liable on complaint to a custodial sentence not exceeding three years or to a monetary penalty.

Art. 273 - Industrial espionage

Any person who seeks to obtain a manufacturing or trade secret in order to make it available to an external official agency, a foreign organisation, a private enterprise, or the agents of any of these, or, any person who makes a manufacturing or trade secret available to an foreign official agency, a foreign organisation, a private enterprise, or the agents of any of these, shall be liable to a custodial sentence not exceeding three years or to a monetary penalty, or in serious cases to a custodial sentence of not less than one year. Any custodial sentence may be combined with a monetary penalty.

Art. 305bis - Money laundering

1 Any person who carries out an act that is aimed at frustrating the identification of the origin, the tracing or the forfeiture of assets which he knows or must assume originate from a felony or aggravated tax misdemeanour shall be liable to a custodial sentence not exceeding three years or to a monetary penalty.

1bis. An aggravated tax misdemeanour is any of the offences set out in Article 186 of the Federal Act of December 14, 1990, on Direct Federal Taxation and Article 59 paragraph 1 clause one of the Federal Act of December 14, 1990, on the Harmonisation of Direct Federal Taxation at Cantonal and Communal Levels, if the tax evaded in any tax period exceeds 300 000 francs.

2 In serious cases, the penalty is a custodial sentence not exceeding five years or a monetary penalty. A custodial sentence is combined with a monetary penalty not exceeding 500 daily penalty units.

A serious case is constituted, in particular, where the offender:

acts as a member of a criminal or terrorist organisation;

acts as a member of a group that has been formed for the purpose of the continued conduct of money laundering activities; or

achieves a large turnover or substantial profit through commercial money laundering.

3  The offender is also liable to the foregoing penalties where the main offence was committed abroad, provided such an offence is also liable to prosecution at the place of commission.

Art. 320 - Breach official secrecy

Any person who discloses secret information that has been confided to him in his capacity as a member of an authority or as a public official or which has come to his knowledge in the execution of his official duties shall be liable to a custodial sentence not exceeding three years or to a monetary penalty.
A breach official secrecy remains an offence following termination of employment as a member of an authority or as a public official.

The offender is not liable to any penalty if he has disclosed the secret information with the written consent of his superior authority.

Art. 321ter - Breach of postal or telecommunications secrecy 

Any person who in his capacity as a public official, employee or auxiliary of an organisation providing postal or telecommunications services reveals to a third party details of customers' post, payments or telecommunications, opens sealed mail or tries to find out its content, or allows a third party the opportunity to carry out such an act shall be liable to a custodial sentence not exceeding three years or to a monetary penalty.

The foregoing penalties also apply to any person who by deception causes a person bound by a duty of confidentiality in terms of paragraph 1 to breach his obligation of secrecy.

A breach of postal or telecommunications secrecy remains an offence even after termination of employment as a public official, employee or auxiliary of an organisation providing postal or telecommunication services.

A breach of postal or telecommunications secrecy does not carry a penalty if it is carried out in order to determine the identity of the entitled person or to prevent loss or damage being occasioned.

Article 179octies is reserved, together with the federal and cantonal provisions on the obligations to give evidence or provide information to a public authority.

113.3. Federal Act on Data Protection (FADP)

Art. 4 - Principles 

Personal data may only be processed lawfully.

Its processing must be carried out in good faith and must be proportionate.

Personal data may only be processed for the purpose indicated at the time of collection, that is evident from the circumstances, or that is provided for by law.

The collection of personal data and in particular the purpose of its processing must be evident to the data subject.

If the consent of the data subject is required for the processing of personal data, such consent is valid only if given voluntarily on the provision of adequate information. Additionally, consent must be given expressly in the case of processing of sensitive personal data or personality profiles.

Art. 35 - Breach of professional confidentiality 

Anyone who without authorisation wilfully discloses confidential, sensitive personal data or personality profiles that have come to their knowledge in the course of their professional activities where such activities require the knowledge of such data is, on complaint, liable to a fine.

The same penalties apply to anyone who without authorisation wilfully discloses confidential, sensitive personal data or personality profiles that have come to their knowledge in the course of their activities for a person bound by professional confidentiality or in the course of training with such a person.

The unauthorised disclosure of confidential, sensitive personal data or personality profiles remains an offence after termination of such professional activities or training.

113.4. Swiss Federal Act on Banks and Savings Banks (BA)

Art. 47 - Breach of banking secrecy

1 Whoever intentionally does the following shall be imprisoned up to three years or fined accordingly:
      a) disclose confidential information entrusted to them in their capacity as a member of an executive or supervisory body, employee, representative, or liquidator of a bank or a person in accordance with Article 1b, as member of a body or employee of an audit firm or that they have observed in this capacity;
      b) attempt to induce an infraction of the professional secrecy;
      c) disclose confidential information to third parties or use this information for own benefits or the benefit of others.
1bis Whoever enriches themselves or others with an action in accordance with (1)(a) or (c) shall be punished with imprisonment for up to five years or fined accordingly.
2 Whoever acts in negligence shall be penalized with a fine of up to CHF 250,000.
3 …​
4 The violation of the professional confidentiality shall remain punishable even after a bank license has been revoked or a person has ceased his/her official responsibilities.
5 The federal and cantonal provisions on the duty to provide evidence or on the duty to provide information to an authority shall be exempted from this provision.
6 Prosecution and judgment of offenses pursuant to these provisions shall be incumbent upon the cantons. The general provisions of the Swiss Penal Code shall be applicable.

113.5. Federal Act on Financial Institutions (FinIA)

Art. 69 - Violation of professional confidentiality

A custodial sentence not exceeding three years or a monetary penalty shall be imposed on any person who wilfully:

discloses a secret entrusted to them in their capacity as a director or officer, employee, agent or liquidator of a financial institution or of which they have become aware in said capacity;

attempts to induce a violation of professional secrecy;

discloses to other persons a secret disclosed to them in violation of letter a or exploits such a secret for their own benefit or for the benefit of others.

A custodial sentence not exceeding five years or a monetary penalty shall be imposed on any person who obtains a pecuniary advantage for themselves or another person through an action as detailed in paragraph 1 letter a or c.

A fine not exceeding CHF 250,000 shall be imposed on persons who commit the foregoing acts through negligence.

Any person who violates professional confidentiality remains liable to prosecution after termination of the official or employment relationship or exercise of the profession.

The federal and cantonal provisions relating to the duty to testify and the duty to provide information to the authorities are reserved.

The cantons are responsible for the prosecution and adjudication of acts under this provision.

113.6. Federal Act on Financial Market Infrastructures and Market Conduct in Securities and Derivatives Trading (FinMIA)

Art. 142 - Exploitation of insider information 

Any person who has insider information and who knows or should know that it is insider information or who has a recommendation that he or she knows or should know is based on insider information shall behave inadmissibly when he or she:

exploits it to acquire or dispose of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland or to use derivatives of such securities;

discloses it to another;

exploits it to recommend to another to acquire or dispose of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland or to use derivatives of such securities.

The Federal Council shall issue provisions regarding the admissible use of insider information, in particular in connection with:
..securities transactions in preparation of a public takeover offer;

a special legal status on the part of the recipient of the information.

Art. 143 - Market manipulation 

A person behaves inadmissibly when he or she:

publicly disseminates information which he or she knows or should know gives false or misleading signals regarding the supply, demand or price of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland;

carries out transactions or acquisition or disposal orders which he or she knows or should know give false or misleading signals regarding the supply, demand or price of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland.

The Federal Council shall issue provisions regarding admissible conduct, in particular in connection with:

securities transactions for price stabilisation purposes;b. buyback programmes for a company’s own securities.

Art. 154 - Exploitation of insider information

A custodial sentence not exceeding three years or a monetary penalty shall be imposed on any person who as a body or a member of a managing or supervisory body of an issuer or of a company controlling or controlled by them, or as a person who due to their holding or activity has legitimate access to insider information, if they gain a pecuniary advantage for themselves or for another with insider information by:

exploiting it to acquire or dispose of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland or to use derivatives of such securities;

disclosing it to another;

exploiting it to recommend that another acquire or dispose of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland or to use derivatives of such securities.

Any person who through an act set out in paragraph 1 gains a pecuniary advantage exceeding one million francs shall be liable to a custodial sentence not exceeding five years or a monetary penalty.

Any person who gains a pecuniary advantage for themselves or for another by exploiting insider information or a recommendation based on insider information disclosed or given to them by a person referred to in paragraph 1 or acquired through a felony or misdemeanour in order to acquire or dispose of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland or in order to use derivatives of such securities shall be liable to a custodial sentence not exceeding one year or to a monetary penalty.

Any person who is not a person referred to in paragraphs 1 to 3 and yet who gains a pecuniary advantage for themselves or for another by exploiting insider information or a recommendation based on insider information in order to acquire or dispose of securities admitted to trading on a trading venue or DLT trading facility which has its registered office in Switzerland or to use derivatives of such securities shall be liable to a fine.

List of further regulations to be observed:

Swiss Criminal Code 137, 138, 139 Unlawful appropriation, Misappropriation, Theft

FADP 6, 7, 11a, 12 ff, 34 Data protection

TCA 43 Obligation of confidentiality

UWG 6 Manufacturing and trade secrets

ATSG 33 Duty of confidentiality under social insurance law

Agreement on the Swiss banks’ code of conduct with regard to the exercise of due diligence (CDB 20)

114. Recruiting

People are the most important asset of the company, thus finding and selecting the right people for the company is key to overall success of our organization exactly because great people in the right spot will produce great results. And working with great people producing great results makes working more fun for oneself as well.

Accountable Circle

Recruiting Work Group

Delegator

Business Operations (Management)

114.1. Importance and principles of Recruiting

Since we’re working in self-organized Teams, individuals can influence our success far more than at other companies - either in a positive or negative direction. Adding a great person can create value across teams and in the whole company becaus this is how we evolve our company.

Read more about our Recruiting Principles here.

Bring your friends. Assuming you think VSHN is a great place to work, who would be a great person so we can bring them here as well? If you’re not sure yet, wait six months and ask yourself the question again.

114.2. Forms of Recruiting

We don’t hire just because we’ve budget for it or feel there is enough work - Hiring a new person is more effective when we know what we need them for and have the full commitment of the team during onboarding as they have selected the person themselves.

We differentiate two forms of recruiting: Filing an actual need and constantly being on the look-out for great people, where the first always has priority to help our Teams and VSHNeers and to keep our business running.

Recruiting for an actual need

Recruiting helps to fill a job opening for an actual need, defined by the stakeholders. The Stakeholders (usually the team with the need) decide who, the Management gives budget OK. Recruiting pre-filters as much as possible, inviting stakeholders to help.

For more details check the Recruiting Process.

Unsolicited applications

We never stop looking for great people. Generic Job ads might be used to attract people, but making it clear that it’s an unsolicited application (also called cold or spontaneous application). Recruiting (periodically) checks against updated job openings and might discuss or inform potentially interested parties if an application has the "wow-effect" we’re looking for. Such applications have no priority and must not impact Recruiting for a job opening in a negative way.

Unsolicited applications might become applications for an actual need, as soon as there is one.

Recruiting together with Management might define a job opening ad-hoc to hire a "wow-candidate" we don’t want to miss.

114.3. Key responsibilities

Help team and other stakeholders to define and write down their recruiting need.

Handle applications.

Do 1st meeting interviews with candidates.

Talk with candidates and navigate them through our processes.

(Help to) organize interviews.

Own the recruiting process and constantly improve it involving the affected people.

Select appropriate tooling to simplify the process.

Moderate decisions needed from Management or the Teams.

114.4. Dependencies

Teams or other stakeholders knowing what they’re missing and actively approaching Recruiting for help to define their recruiting needs.

Teams participating in meeting candidates and choosing their favorites.

Marketing support to be able to publish job ads, etc.

Management having a budget to actually recruit new VSHNeers.

Management talking the final hiring decisions.

114.5. Risks

Teams not participating enough.

Too slow handling of unsolicited applications, we might still miss good opportunities.

114.6. Evaluation Criteria

Seen as a Team

Their need is addressed through recruiting, they actually get open positions filled.

Seen as the Organization

We strategically hire people who help us to get close to our Goals and Beliefs.

The hiring budget is used to address actual needs of the organization.

This domain is tracked and reviewed as VIP-112.

115. Recruiting Process

In the scope of the Recruiting Domain the Recruiting Interest Group manages and handles applications as described here.

Define the need for new jobs and roles.

Consent to Open Positions.

Publish Job Ads.

Handle Applications.

Sort out, decide and invite.

Complete pre-screening.

Do 1st Meetings with candidates.

Team or stakeholders select candidates.

Do 2nd Meetings with candidates.

Make a final decision.

Do all the Contract and Paperwork.

Onboarding starts.

115.1. Workflow in Recruitee

Applications are handled in Recruitee.

115.2. Open Positions

Stakeholders (usually teams) get clarity on what they’re missing currently or in the future (workforce, skills, etc.). Recruiting may help with this.

Recruiting helps to define and write down this need as a job description and open position in our Wiki.

The Management, as the Delegator, consents to the job description and gives the budget OK for all job openings.

Publish the job ad and start Handling Applications.

115.3. Job Ads

For the two forms of recruiting we manage two types of job ads on our website:

Open Positions.

Ads to do "recruiting, marketing." There are multiple different job ads for the same job to lower the barrier of entry for candidates to contact us because they can find a "more specific" job ad than elsewhere.

New roles are created through a VIP and a role description in our handbook.

115.4. Handling Applications

We don’t consider applications from recruiters or agencies! Should we still get such applications, we reject them manually.

The application process starts when a candidate fills out the application form on vshn.ch/jobs or sends an email to jobs@vshn.ch.

An application and candidate is automatically created in Recruitee which automatically confirms the receipt to the candidate via E-Mail.

The application is automatically mapped to the job opening in Recruitee.

Applications for an Open Position

We check incoming applications vs. the job opening and either

Ask clarifying questions.

Reject the application.

Refer the applicant to a more fitting job opening.

Ask the candidate to be on the waiting list for unsolicited applications.

Ensure the candidate handed in all relevant diplomas and references ("Arbeitszeugnisse")

Ultimately we invite the candidate if we see a potential match.

We do a pre-screening.

We reflect and sort out candidates that don’t match.

We provide a list of fitting candidates to the stakeholders or team.

Stakeholders select candidates they want to talk to in 2nd Meeting, other VSHNeers might also join.

Stakeholders select the final candidate so that Recruiting can send the job offer to the candidate

Spontaneous Applications

We manually move these spontaneous applications to the Talent Pool in Recruitee if we don’t have a matching job right now.

We also ask the candidate (if not done automatically via the application form) if it’s okay to store the application for later.

At least once a month and when we add new open positions, we go through the list and check if we already have someone in the pipeline that could match an open position.

When checking new or existing applications and see a candidate, that would perfectly fit VSHN but we don’t have an open job, we might start discussing options and reach out to VSHNeers and Management.

115.5. Interviews

Following the pre-screening, we usually do a 1st Meeting and if we would like to continue a 2nd Meeting with all candidates.

Preparation

The Recruiting lead will seek volunteers for the interview in #general chat or by direct approach. If not enough volunteers are found, Recruiting may directly invite people from the affected teams based to their availability in the calendar.

It is important that all stakeholders meet with the candidate.

For privacy reasons, we usually can’t share the application and CV with the entire company at this point.

The interview is scheduled in Recruitee with exact times and adding the VSHNeers who participate.

This automatically allows the VSHNeer to view the candidate (including cover letters, CVs, etc.) in Recruitee.

VSHNeers get an automated e-mail for the interview and a link where they can provide feedback after the interview.

Reflection and Feedback

All VSHNeers will provide feedback in Recruitee, including a recommendation for the Experience level at which the candidate should be hired.

Recruiting reviews this feedback.

The Recruiting lead checks the certificates and the references in the CV to ensure that the applicant’s information is correct.

115.6. Contract and Paperwork

People Operations then prepares all necessary paperwork (contract, addendums, etc) and sends them to the candidate for review and signature. Two Members of the Management sign the contract also afterwards.

Depending on the candidate’s answer, the status is set to Offer Accepted or Offer Declined. If everything is done the status is set to Hired (Onboarding starts).

115.7. Onboarding

People Operations is responsible for the administrative onboarding, ordering hardware and connecting the new VSHNeer with their new Team and Mentor.

The onboarding process works towards constant improvements and being successful in making new VSHNeers feel equipped with everything needed to be successful in their role.

This process is tracked and reviewed as part of VIP-112.

116. Reverse Interview

This page, inspired by the Reverse interview project, provides some answers to the most common questions candidates make during interviews.

116.1. Tech

What are the usual stacks used at the company?

Each team uses different technology stacks. For example, the Polaris team uses Puppet for configuration management and Ansible for change management like updates, while Sirius specializes in Ansible and Kubernetes in the OpenShift and Rancher distributions. Many team members wrote and maintain tools written in several programming languages: Python, Go, Bash shell script, and TypeScript are some examples.

How do you use source control?

Very extensively: we use our own GitLab for our internal projects, where we even store the source Asciidoc files of this handbook. We also have a GitHub account where we share code and tools with the world. We encourage our engineers to open source projects!

How do you test code?

We use unit testing as thoroughly as possible, wherever and whenever we can. But we can always do better.

How do you track bugs?

We use Atlassian Jira, and we use it to track everything, including recruiting, accounting, and of course customer support. There is a special page about Jira in this handbook with more information.

How do you integrate and deploy changes? Is it CI/CD?

Yes. We build, test, and integrate continuously everything we do, exactly the same way we help our customers to do it! We’ve CI/CD pipelines for this handbook, and even for our presentation slides.

Is your infrastructure setup under version control / available as code?

Yes.

What’s the workflow from the planning to the finished task?

We use Scrum and Kanban internally. Each Team plans their work separately and following their own processes, but always in an agile and collaborative way. We use Jira extensively to document and keep a trace of everything we do, so that we can work as asynchronously as possible.

Is there a standardised development environment? Is it enforced?

No. Every VSHNeer is free to use the tools that work best for them, although some tools become natural "standards" because everyone uses them.

How quickly can you setup a new local test environment? (minutes / hours / days)

Each of our tools and projects should come with a README and an appropriate setup configuration (for example, Makefile, build.sbt, setup.py, docker-compose.yml) to help you set them up. Usually, there is also additional documentation in the wiki. So, something like git clone && make typically gets you started within minutes.

How quickly can you respond to security issues in the code or dependencies?

We’ve a 24x7 on-call team, ready to respond day and night within 30 minutes, and we’re very proactive.

116.2. The Team

What does VSHNary means?

If you get in touch with VSHN you will hear the Word «VSHNary» sooner or later. But what does this mashup of our company name and "visionary" mean? VSHNary is our term to describe a person that fits in our team. It doesn’t mean that you have to be identical to us. It means: To share the same cultural qualities and values, the same fascination for what we’re doing, the same thinking about what’s a team is what makes you VSHNary. To be VSHNary isn’t described in a job description, so you have to come over to feel what it means.

How much independent action vs working off a provided list is expected?

If you want things to change, you are expected to independently act! Which doesn’t mean that you can "just do stuff" without talking to your peers. We’re looking for people which are team players, so a little bit of both attitudes are necessary. We’re looking for people which are open minded and ready to improve things. But also to have the team spirit to work on routine things which just need to be done.

What are the expected core work hours?

We use a 40 hours work week, including maintenance shifts. We’re also looking for engineers for our on-call rotation, which counts as additional time and is payed in addition to the salary.

What does the onboarding look like?

We’ve documented this in Your first day at VSHN.

How’s the work organized?

We’re organized using concepts from Sociocracy 3.0 like Domains, Teams and Delegate Circles. Teams use Agile methods like Kanban to plan their work.

How does the intra/inter-team communication typically work?

We use chat extensively, whereas e-mail is mostly a tool to talk to the "outer world." We also use Zoom to communicate with remote team members, and to record our internal training sessions. You can read more about those tools in the following pages of this handbook: Calendar, Documentation, Jira, and Mail.

How are differences of opinions resolved?

It’s okay to have different opinions, and it’s also okay to have differences about them. At the the end there are three ways of solving them:

It’s important to use common sense, and it’s okay to just let differences of opinions be.

Include a bigger amount of team members into the discussion, maybe a third, fourth or even eleventh opinion will show up, but in the end the crowd will decide.

Money is a hard fact. There are things we’re just not able to pay, so sometimes we’ve to find another solution or a different compromise.

Who sets the priorities / schedule?

The teams in consultation with the Project Manager and the Sales teams.

What kind of meetings happen every week?

We talk about that in the "Your First Day" and "Weekly Company Meeting" pages of this handbook. Teams organize themselves.

What happens after production incidents? Is there a culture of blameless analysis?

We win as a team and we f*ck up as a team. To handle incidents is a very important topic at our company, and we work hard on avoiding them. If there is an incident we work as a team in fixing it, and don’t let anyone by themselves. After fixing we will discuss in the team what happened, and how to avoid such situations in the future by writing a blame-less postmortem.

What are some ongoing challenges the team is experiencing that you are yet to resolve?

We’re humans, and hence we sometimes struggle in our communication. But we’ve strong communication principes we stick to, and we’re constantly trying and evaluating new ways to collaborate and communicate with one another. Some work better than others, but we’re always trying to get better at this.

116.3. The Company

What’s the status of / view on diverse hiring?

We’ve a lot of work to do to reach gender parity, and we’re doing it. We give equal opportunities to all candidates, wherever they come from, whatever their background is, and however they see themselves. As long as you adhere to the VSHNeer communication principles, you will be welcome!

Is there a budget for education?

Of course! There is an annual budget of 4000 CHF per employee, which can be used for personal education in nearly any way. Certification, language school, conferences, it’s up to you to decide. You can find more information in the "Salary System" and the "Personal Education Process" pages of this handbook.

Can I contribute to FOSS projects? Are there any approvals needed?

Yes you should contribute to FOSS projects, No you don’t need special approval for that.

What do you think are the gaps in the company culture?

We’re all human and that means we all make mistakes. The best we can do is to learn from these gaps, and most importantly, to never blame somebody else for our own mistakes.

Do you collaborate with social or community projects?

At the moment we’re cooperating with Women++ and the ETHZ, but we’re always looking for new opportunities to improve the state of our community and our industry.

116.4. The Business

Are you profitable?

Yes.

What’s the maturity stage?

Growing.

Where does the funding come from, and who influences the high level plan/direction?

We don’t have investors; we’re solely owner-based. We grow organically.

How do you don’t make money?

We don’t provide bodyleasing and no «traditional» consulting.

What have you identified as your competitive advantage?

Our team.

116.5. Remote Work

What’s the ratio of remote to office workers?

At the moment there are two part time remote workers that work a few weeks at the time from remote. Homeoffice or remote work isn’t a problem, if you show up here at the VSHN office regurarly, for example 33% of your working hours.

Does the company provide hardware and what’s the refresh schedule?

This is explained in detail in the "Your First Day" page in this handbook.

116.6. Office Work

What’s the office layout?

We currently have one large room (12 people) and 5 smaller rooms (with 3–5 people each). Come visit us for a cup of coffee and to have a look.

116.7. Compensation

If you have a bonus scheme, how are bonuses determined?

We believe that you should be payed equally for equal work. We also believe that every VSHNeer works the best they can, so there are no bonus schemes. Salary increases apply to the whole team, and not to a single person. The Salary System page contains more information about this.

116.8. Time Off

How much Paid Time Off (PTO) is offered?

We talk about that in detail in the Salary System page of this handbook.

What’s the parental leave policy?

Women get the 14-week maternity leave specified by law, while men get 4-weeks of paternity leave. There are more benefits explained in the Salary System page.

117. Recruitment Pre Screening

The pre-screening interview serves as an initial evaluation step that takes place before candidates are invited for face-to-face interviews.

This stage helps streamline the hiring process and for us to get an understanding of the candidates' alignment with VSHN’s values and culture.

Pre-screening can be done in the following ways:

A One-Way Video Interview

A Pre-Screen phone call with recruitment

It is important that the candidate is also aware of the culture at VSHN. This helps candidates avoid investing time and effort in pursuing opportunities that may not be the right fit.

117.1. One-Way Video Interview

One-way video (also known as asynchronous video interviews) is tech-savvy and forward-thinking, potentially appealing to tech-oriented candidates.

This allows candidates to complete the interview at a time that suits them within seven days following receiving the invitation.

Candidates can take their time to formulate responses and present themselves in the best possible way. Candidates also have the option to review their responses before submission, giving them the opportunity to edit or retake parts they are not satisfied with.

At the beginning of this interview, the candidate is able to gain valuable context about the company’s history, mission, and values by watching an introduction Video recorded by our Co-Founder.

Following this, there are a few questions where we find out a little more about the candidate’s history, motivation, and enthusiasm for the role.

With relevant questions, the candidate will receive links to the job description and links to find details on VSHN’s compensation benefits and structures.

Only recruitment and direct hiring managers/stakeholders can access these videos, stored in Spark Hire.

117.2. Pre-Screen phone call

Pre-screen phone calls are usually completed on request should a candidate not feel comfortable completing the One-Way Video Interview.

The candidate will receive a calendar link where candidates can schedule a 20-30-minute phone call with recruitment.

Within the call, we will discuss the candidate’s history, expectations, and VSHN’s compensation benefits and structures.

117.3. Decision

Recruitment reviews this stage and then either

Ask any clarifying questions to the candidates

Rejects the candidate if either side doesn’t see value in continuing with the process

Discusses the candidates with the hiring manager or direct teams to arrange first interviews

118. Recruiting 1st Meeting

The first meeting is a mostly informal talk with someone who represents the Stakeholder of the Open Position to get to know the candidate better and determine if they’re VSHNary and fit the position.

The first meeting can be through Zoom or face-to-face in the main working office (Zurich/Vancouver) and usually lasts around 40 minutes.

This allows the candidate to gain a more comprehensive understanding of the role’s day-to-day responsibilities and expectations. They can ask specific questions and gather insights that may not have been covered in the pre-screen interview.

The candidate can also gain a clearer picture of what working within the team would be like helping them form realistic expectations about the work environment, collaboration, and team dynamics.

The team members/stakeholders can assess the candidate’s fit with the team, their ability to collaborate effectively, and their alignment with the team’s goals and values.

118.1. Reflection and Feedback

See Recruiting Interviews.

Candidate

We suggest that the candidate takes the rest of the day and sleeps on all of the information he has learned about VSHN and the Open position. The candidate is then asked to provide feedback in writing (e-mail) in the following days.

Do they want to continue the application process with VSHN?

Are there questions or clarification needed before we go ahead?

VSHN

Is there a match with VSHN’s values, beliefs, and culture?

Is there a match with the role and the open position?

What experience relevant to the role(s) do they bring?

Other open positions the candidate could fit?

When the candidate provides Feedback via e-mail (or after a timeout), the recruiter shares the VSHN feedback with the candidate.

118.2. Decision

If we’ve positive feedback from the candidate and the team, we invite the candidate for a 2nd Meeting, depending on the findings from our Reflection:

For this step, the open position’s stakeholder or sponsor must be involved.

The candidates we want for a 2nd meeting, we advance the status in Recruitee to 2nd Meeting.

This usually means that we’ve to wait until a few 1st meetings for one position are done to compare candidates and provide a list of favorites to the stakeholders.

Other candidates are rejected in Recruitee.

This process is tracked and reviewed as part of VIP-112.

119. 2nd Meeting

In the 2nd meeting, the candidate meets other VSHNeers, usually focusing on people from the team for which this open position is. The goal is to further find out if the candidate is a good fit for VSHN and the position, but also to show the candidate who we’re and how we work at VSHN.

It’s important that we let the candidate tell us a lot about themselves so that the team can get a feel for whether the person might be a good fit for them and for the job. Of course, there should always be timeto answer the candidate’s questions.

The second meeting consists of

15min welcome and agenda introduction with the recruiter

3x 30min meeting with 2 VSHNeers each, preferably from the teams the candidate could join

15min break

60min co-working with a VSHNeer or a special discussion round for non-tech positions.

30min reserved for feedback, questions, next steps with the recruiter

See Recruiting Interviews.

119.1. Decision

If all feedback is positive, Recruiting proposes the candidate to the stakeholders (usually the team). The stakeholder (team) makes the decision whether it wants the candidate (or which one, if more than one is considered).

If it’s a go, the candidate is advanced to Offer Draft in Recruitee and then the management takes the final decision (usually in the next weekly Management meeting).

When approved Recruiting hands over to People Operations to send a work contract as an official job offer. The status is then set to Offered. See Contract and Paperwork.

When a position is filled, we usually close the job opening, which automatically removes the job ad from our vshn.ch/jobs.

In case of a negative decision, Recruiting informs the candidate and rejects the candidate in Recruitee.

This process is tracked and reviewed as part of VIP-112.

120. Onboarding New VSHNeers

We recognize that an onboarding experience sets the tone for a new VSHNeer’s journey with us and the importance of the new VSHNeer to feel equipped with everything needed to succeed.

Accountable Circle

Recruiting Work Group

Delegator

Business Operations (Management)

People Operations is responsible for the administrative onboarding, ordering hardware, and connecting the new VSHNeer with their new Team and Mentor.

120.1. Importance of onboarding

So that new VSHNeers can be prepared from their first day through to the end of their three-month trial period, we aim to introduce the new VSHNeer to everything needed to be successful in their new role.

Also, to ensure all feedback is communicated when the new VSHNeer is doing well or if the new VSHNeer is not a perfect fit.

120.2. Who is involved with onboarding:

Mentor

This is usually the hiring manager who helped create the role description and oversaw all candidates within the recruiting process or another direct stakeholder to the position.

A mentor will sync regularly with the new VSHNeer throughout the trial period and be available for any questions.

The Mentor will also introduce an onboarding plan in Wiki, which is detailed with all the information needed within week 1, week 2, and weeks 3-5, 6-9, 10-11, and 12.

Shadow Buddy

This is someone within the team who can guide you through the team’s day-to-day work. This may be one more than one VSHNeer.

A Shadow Buddy will sit with the new VSHNeers in the first week and then have dedicated daily, weekly, or bi-weekly blockers in their diary to be available and open for any needed questions.

The purpose of this role is so that the new VSHNeer doesn’t feel like they are disturbing anyone in their daily work.

New Team

The new team will be available on the first day and introduce themselves individually to the new VSHNeer.

People Operations

People Operations will be there on the first day to meet with the new VSHNeer, and they will schedule syncs in the diary for weeks 3, 7, 9, 11, and the end of the trial meeting.

The purpose of this role within onboarding is so that the new VSHNeers feel like there is a safe environment outside of the team where two-way feedback can be communicated.

Management and Board

As part of the onboarding, we suggest the new VSHNeer schedules a sync with a management or board member for a Q and A session.

Office management

Whether the new VSHNeer decides to work remotely or from the office with their dedicated personal workplace budget, Office Management will be available to discuss these options with the new VSHNeer.

New VSHNeer

Last but not least, as the most important person in this process, the new VSHNeer will also be responsible for reaching out to the relevant VSHNeers for any help, guidance, and support.

We are all happy to help in any way we can, so just ping anyone on chat when needed.

This process is tracked and reviewed as part of VIP-148.

121. Recruiting Principles

Usually, it’s immediately obvious whether or not we’ve done a great job hiring someone. However, we don’t have the usual checks and balances that come with having managers, so occasionally it can take a while to understand whether a new person is fitting in. This is one downside of the organic design of the company—a poor hiring decision can cause lots of damage, and can sometimes go unchecked for too long. Ultimately, people who cause damage always get weeded out, but the harm they do can still be significant.

During the recruiting process we want to check if people are VSHNary, but what does that mean?

121.1. People we enjoy working with

Before assessing any professional/technical skills we need to find out if we can effectively collaborate as a team. We value people who can deconstruct problems on the fly, and talk to others as they do so, simultaneously being inventive, iterative, creative, talkative, and reactive.

There are many questions to help reflect on a person:

Would I want to talk to this person daily?

Would I want this person to be my boss (if we had bosses)?

Would I learn a significant amount from them?

Do you feel a constructive, positive, reflected attitude?

What if this person went to work for our competition?

In essence, we need to filter out all "genius assholes" first that would be able to do the job but that we would not want to collaborate with daily.

121.2. People with T-shaped skills

"People with T-shaped skills" are people that are both generalists (skilled at a broad set of valuable things - the horzontal bar of the "T") and also experts (among the best of their field in a specific discipline - the vertical bar of the "T"). Many experts with too narrow of a field have difficulty collaborating. A generalist who doesn’t go deep enough in any area has difficulty contributing as an individual.

Many technical skills, like experience in a specific programming language, people can learn quickly if they already know a few other languages. We’ve more difficulty teaching non-technical skills like collaboration, motivation, learning, etc. These we need to see present.

121.3. People stronger than ourselves

It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so that they can tell us what to do.

~ Steve Jobs Co-founder

I surround myself with people who have knowledge and talents in areas where I might not be so well versed.

~ Richard Branson Founder of Virgin Group

I will only hire someone to work directly for me if I would work for that person.

~ Mark Zuckerberg Founder and CEO of Facebook

We need to hire people we can trust to get on with the day-to-day, those who we don’t feel the need to constantly micromanage, because we feel confident in the fact that they’re the best people for the job. It’s always been important to hire people who are somehow ‘better’ than ourselves (particularly in terms of specific skill sets and areas of expertise). Then collaboration is much more fun and we can entrust them easier with our tasks, on-call duties or work while we’re on vacation.

There are many forms of bias that might cloud our judgement though, as Madan Pillutla, PhD, professor of organizational behavior at London Business School, states: “Even if people are well-meaning and well-intentioned, it’s very difficult to act against your own self-interest by hiring someone who could outperform you.” Hiring someone we perceive to be "better" than us almost goes against our primal sense of self-preservation and taps into the unspoken fear that we’re somehow replaceable. It also feeds into the nagging feelings of insecurity we all experience from time to time. Hiring useful but lower-powered people is a natural response to having so much work to get done but it’s a huge mistake for the long-term company culture and collaboration environment.

Being aware of possible unconscious bias and reflecting on your "first impression" of a person is the first step of overcoming them. For example, was your negative first impression of a person caused by the person’s difficult to understand accent, creating a language barrier? Might be a sign of Similarity attraction bias. Or, did you change your negative into a more "might be OK" review because there were already a few positive feedbacks and you didn’t want to be the only negative person? Might be a sign of Conformity bias.

122. Partner Management: Definition and Scope

Partner management is no longer regarded as a separate domain, but as an integral activity of Marketing, Product Management, and Sales & Account Management.

122.1. Overview

Partner management encompasses the strategies and activities aimed at nurturing relationships with partner companies to enhance mutual growth. It involves understanding partners' businesses, strategies, markets, and key stakeholders, while also defining the synergy and objectives of the partnership. This collaboration can take the form of reselling products, creating combined offers, or engaging in joint marketing initiatives.

122.2. Objectives

Understand the dynamics and strategies of partner companies.

Grow and nurture relationships, ensuring mutual benefits.

Drive initiatives such as joint marketing campaigns.

Maintain awareness of contractual obligations, certification statuses, and reporting requirements.

Foster clear communication and collaboration between VSHN and partner companies.

122.3. Involved Activities

Strategic Oversight: Understand the partner’s strategy, maintain contact, plan joint business initiatives, and monitor certification requirements and risks.

Sales Coordination: Engage in joint deals, maintain contact lists, identify sales opportunities, and participate in roadshows and other initiatives.

Marketing Collaboration: Plan and execute joint events, campaigns, and webinars, ensuring that branding guidelines are upheld.

Operational Tasks: Organize regular sync meetings, ensure certifications are in place, plan joint marketing initiatives, and manage financial aspects such as invoicing and funding.

122.4. Types of Partners

Consultant & Reseller: Collaborative entities that can either bring business to VSHN or work alongside VSHN on projects.

CSP (Cloud Service Provider): Entities that either sell VSHN services to their clients or provide infrastructure for VSHN offerings.

Software Vendor: Companies whose software is sold by VSHN to its customers. Partnerships here might necessitate specific certifications.

Distributor: Intermediaries between software vendors and VSHN, often handling licensing and supporting marketing & lead generation.

Customer: While customers are crucial stakeholders for VSHN, in the context of this definition, they are not classified under "Partner Management."

123. Domain Products

Accountable

Products Work Group

Delegator

Business Management

Lead by

Tobias Brunner (Product Manager)

123.1. Purpose

Product Management as part of Marketing & Sales understand the market need, trends and the overall strategy of VSHN. They develop and propose concrete offerings.

As we collaborativle make strategic decisions, involving those affected (in this case the teams that work to deliver our offerings), we need a way to officially meet understand and decide together.

123.2. Key Responsibilities

Governance on the Product Roadmap

Sharing knowledge between Product Owner

Decisions on VSHN offerings including commercials (pricing), especially when multiple offerings or teams are affected - otherwise can be done directly with PO of offering.

123.3. Dependencies

The operational work for market research, strategic planning, and writing the high level product descriptions, as well as creating marketing and sales material happens in Marketing & Sales.

Writing technical Product definitions and documentation is with the Product Owner of an offering.

123.4. Key Deliverables

Ownership of Product Roadmap

Agreement on Product Roadmap

Decisions on offerings, pricing, priorities and product level strategy and tactics

This domain is tracked and reviewed as VIP-40

124. Products Work Group

The Work Group accountable for the Products Domain:

Product Management as part of Marketing & Sales understand the market need, trends and the overall strategy of VSHN. They develop and propose concrete offerings.

As we collaborativle make strategic decisions, involving those affected (in this case the teams that work to deliver our offerings), we need a way to officially meet understand and decide together.

124.1. Meta

Scheduled Meetings

We regularly meet:

once a month for operational exchange and checking our VIPs.

once every quarter for agreeing on product goals.

Meeting Notes

Our meeting notes can be found in our wiki.

Chat

Talk to us in #products-wg.

Zoom

The Zoom link can be found in our chat channel.

124.2. What we do

Collaboratively Learn

We exchange how we work (Methods, Processes, Tools) as Product Owner so that we can learn from each other and improve our skills. We’ll do that in a retro style, but can also amend the format if requested.

Agreeing on Product Goals

We agree on the strategic product goals for each product, which is prepared by the respective Product Owner together with Product Management. This way we also shape the longer term product roadmap, up to "where do we want to be in a year?". For that, Customer Care is also involved.

Governance / Decisions

We’re governing VIPs assigned to our workgroup.

124.3. Members

Product Owners of the Value Stream Teams and the Product Manager:

Tobias Brunner
Product Manager

Christian Häusler
Product Owner of Aldebaran - APPUiO Managed OpenShift and APPUiO Cloud

Liene Luksika
Product Owner of Schedar - VSHN Application Catalog

André Keller
Product Owner of Polaris - Managed Server based Services

This team is tracked and reviewed as part of VIP-40

125. Team Development Work Group

The Work Group accountable for the Team Development Domain:

The Team Facilitator of a team leads to ensure the team continuously develops how to most effectively and efficiently account for their domain. The involved activities need knowledge and experience, ways to find out if they are on the right track, and stay on track. Other teams do similar things and face similar challenges, it would be a waste, when every team would have to self-learn and -invent everything. Also there are and will always be things that make sense to do the same way across teams to best serve the overall organization. The Delegator of the Teams should also notice when there is something the teams need help with, so they can support and enable the team with what is needed.

We need a way for the teams and their delegator(s) to come together and share, learn and decide together about how they best account for their domain and how to address cross-team challenges. How they facilitate and lead their team to work effectively.

125.1. Members

Team Facilitator of the Value Stream Teams, the Delegator representative of Management, and others who contribute or participate in governance.

Elia Ponzio
Team Facilitator of APPUiO Managed OpenShift & APPUiO Cloud

Alexander Dehmel
Team Facilitator of Managed Server based Services

Marco Fretz
Delegator Representative Business Management

Nicolas Bigler
Team Facilitator of AppCatalog

This team is tracked and reviewed as part of VIP-264

126. Tech Alignment Work Group

The Work Group accountable for the Technology Alignment Domain:

Even though our Value Stream teams develop, deliver, and run different products for our customers, there are many technical things they have in common, such as similar requirements that need to be addressed, similar processes, similar infrastructure and software, etc. If each team solves these things on their own, we risk reinventing the wheel in each team and thus not only doing redundant work, but also missing the opportunity to leverage team-independent collective intelligence. Also, there are from time to time strategic technology decisions to be made that have a crucial business impact, such as technology partnerships, or the change of necessary skills when introducing a new technology.

We therefore need a way to align ourselves on the technical level, to identify problems and opportunities, and make decisions together. This allows us to find solutions for similar challenges across teams where it makes sense, learn from mistakes and developments so that they are not repeated in other teams, and prevents that we duplicate or triplicate work in different teams.

126.1. Meta

Scheduled Meetings

We meet regularly to progress our agenda. The Zoom link can be found in our chat channel.

Meeting Notes

Our meeting notes can be found in our wiki.

Chat

Talk to us in #tech-alignment-wg.

Work Tracking

We use Jira to track our work in the VTAW project. We also maintain a Kanban Board.

126.2. What we do

Work Planning

We plan work which is related to our Key Responsibilities. As the workgroup itself doesn’t do any operational work, this work is assigned to a Team which is able to work on it.

Information Sharing

We share information over team boundaries to learn from each other, in the form of brief reports.

Governance / Decisions

We’re governing VIPs assigned to our workgroup.

126.3. Members

Tech Alignment role keepers of the Value Stream Teams and others who contribute or participate in governance.

Sandro Kaspar
Tech Alignment of APPUiO Managed Kubernetes Services

Simon Gerber
Tech Alignment of APPUiO Managed OpenShift & APPUiO Cloud

Michel Rios
Tech Alignment of Managed Server based Services

Gabriel Saratura
Tech Alignment of AppCatalog

Manuel Hutter
Tech Alignment of AppOps & AppFlow

Daniel Hauswirth
CISO representing Information Securty Domain

Tobias Brunner
Product Management (tech focus)

This team is tracked and reviewed as part of VIP-265

127. Domain Technology Alignment

Accountable

Technology Alignment Work Group

Delegator

Business Management

Lead

Tobias Brunner

127.1. Purpose

Even though our Value Stream teams develop, deliver, and run different products for our customers, there are many technical things they have in common, such as similar requirements that need to be addressed, similar processes, similar infrastructure and software, etc. If each team solves these things on their own, we risk reinventing the wheel in each team and thus not only doing redundant work, but also missing the opportunity to leverage team-independent collective intelligence. Also, there are from time to time strategic technology decisions to be made that have a crucial business impact, such as technology partnerships, or the change of necessary skills when introducing a new technology.

We therefore need a way to align ourselves on the technical level, to identify problems and opportunities, and make decisions together. This allows us to find solutions for similar challenges across teams where it makes sense, learn from mistakes and developments so that they are not repeated in other teams, and prevents that we duplicate or triplicate work in different teams.

127.2. Key Responsibilities

Learn together about current and past problems, how they were solved, across all our teams.

Decide on technologies, concepts, frameworks, etc. the teams should use, where useful.

Current Topics

We take care of tools and processes needed to provide our products which are not part of Corporate IT:

VSHN Portal

Project Syn (Commodore, Lieutenant and Steward)

The infrastructure at VSHN (Lieutenant and Vault)

Project Roadmap and Prioritization

Common Commodore Components

Commodore Compile Pipeline

Top-level configuration hierarchy

Technical Documentation system

Authoritative DNS

Automated Billing System for our products

ACME DNS instance

Docker Hub proxy

Cilium

Self-Hosted Renovate

We also strive to have a common way of engineering:

Maintain Technology Radar

Provide best practices and guidance on how to do things

Curate an engineering manifesto

Ensure Information Security is addressed in the tech teams together with Information Securty Domain

127.3. Key Deliverables

Documentation of major technology decisions

Technology Radar

This domain is tracked and reviewed as VIP-265

128. Domain Team Development

Accountable

Team Development Work Group

Delegator

Business Management, Represented by Marco Fretz

128.1. Purpose

The Team Facilitator of a team leads to ensure the team continuously develops how to most effectively and efficiently account for their domain. The involved activities need knowledge and experience, ways to find out if they are on the right track, and stay on track. Other teams do similar things and face similar challenges, it would be a waste, when every team would have to self-learn and -invent everything. Also there are and will always be things that make sense to do the same way across teams to best serve the overall organization. The Delegator of the Teams should also notice when there is something the teams need help with, so they can support and enable the team with what is needed.

We need a way for the teams and their delegator(s) to come together and share, learn and decide together about how they best account for their domain and how to address cross-team challenges. How they facilitate and lead their team to work effectively.

128.2. Key Responsibilities

The scope are opportunities, issues and impediments regarding the capability and the flow of the teams to deliver on their purpose and responsibilities. Overarching business processes are the responsibility on the company level and therefore of the management, which addresses these problems with the affected teams.

For the Teams

Facilitating the resolution of team and cross-team impediments, with the people involved.

Sharing information about dependencies.

Coordinating efforts.

Exposing risks.

Provide a heads up for changes in the team(s) - in How or What a team works on - that would impede other team’s success.

Finding ways to improve, to increase the value produced by the teams.

Responsibilities toward the Delegator

Addressing the needs coming from the Delegator Business Management.

Interfacing with Delegator in regular reviews, at Team Development WG Review and Office Hours.

128.3. Delegator Responsibilities

The Delegator might offer help, but is committed to not interfere with the Work Group’s learning. They own their issues and take responsibility for the impact of their actions. The Delegator representative joins work efforts and meetings on-demand only, and usually stays in contact with the group lead only.

Gives context on the high level business needs, constraints and objectives, either:

directly to the Team Development Work Group, if relevant,

or directly to the Team in question, if relevant,

Enables the Work Group through resources needed, so that they can do their work. This includes:

organizing personnel (internal, hiring, external)

organizing and financing of training

giving guidance via information on business needs and objectives

protecting the domain from intrusion by leading actions which preserve their purpose.

Initiates reviews of domain and the Work Group’s effectiveness, or participates as requested by the Work Group.

Leads that issues on the company level are addressed.

This domain is tracked and reviewed as VIP-264

129. Information Security Management

To ensure the information security of our company and to be ISO 27001 certified, we operate an Information Security Management System, in short ISMS. This system must be maintained by a group of people with defined leadership.

The ISMS is a set of procedures and guidelines within a company, which serves to define, control, monitor, maintain and continuously improve information security.

ISO 27001 is an international standard that describes how information security in a company can be ensured with an Information Security Management System ISMS.

Accountable

Work Group Information Security Management

Lead

Role keeper of CISO

Delegator

Management

129.1. Core Tasks

Maintain our Information Security Management System.

Define policies regarding information security.

Define processes to identify and mitigate information security threats.

Ensure the ISO 27001 certification.

Ensure the yearly ISAE 3402 report.

Ensure the risk management process.

Handle Security Incidents that fall into the scope of the ISMS.

Prepare yearly Management Review.

Prepare, organize and hold employee educations on ISMS relevant policies and topics.

Prepare, organize and support recurring internal and external audits.

Support VSHN teams in compliance questions.

Define processes to identify and mitigate information security threats.

Conduct a comprehensive risk analysis and risk mitigation.

Moderate acceptable risk approval.

129.2. Constraint

The Management has to approve new policies and policy changes to ISMS policies which are marked as to be approved by management.

The CISO can directly approve all other ISMS policy changes.

There is a yearly Management Review of the ISMS approved by the Board.

Defined, acceptable risks need approval by Board.

129.3. Evaluation Criteria

Security Incidents are coordinated and handled according to ISMS policies.

VSHN has a yearly ISAE 3402 Type 2 report.

VSHN is ISO 27001 certified.

129.4. Links

Policies documented in our Wiki.

Policies documented in our Handbook.

This domain is tracked and reviewed as VIP-43

130. ISMS Policies

To ensure the information security of our company and to be ISO 27001 certified, we operate an Information Security Management System, in short ISMS. The ISM Domain is accountable for that ISMS.

The ISMS defines couple of policies which must be available for employees. Currently most of our ISM policies are documented in German in the ISMS Space in our Wiki. All translated policies will be available in this section of the handbook and the German version in the Wiki will be removed after that.

131. ISMS Acceptable Use Policy

131.1. Purpose, Scope, and User

This document sets out clear rules for the use of VSHN’s information systems and other information assets. It aims to prevent unauthorized access to mobile devices, both inside and outside VSHN premises. It also explains how VSHN maintains control over the organization’s information when it’s accessed through devices that do not belong to the organization.

These rules apply to the entire scope of the Information Security Management System (ISMS), covering all people, data, and assets within the ISMS scope. That includes any devices that can store, send, or process sensitive data. The policy also covers the use of personal devices, known as BYOD (Bring Your Own Device).

This policy is legally binding for all employees of VSHN AG. It must be acknowledged upon signing the employment contract.

131.2. Definitions

Bring Your Own Device (BYOD)

BYOD refers to personal devices like laptops or mobile phones, that synchronize business data locally (for example, data from file servers, email, calendar, etc.). A computer that serves exclusively as a host for a virtual machine for business purposes is also considered BYOD. Additionally, personal devices that store private SSH/GPG keys for a VSHN account or have a VPN connection to the VSHN infrastructure are considered BYOD.
Not considered BYOD are devices used for two-factor authentication (2FA) such as YubiKeys, or other FIDO2 security keys. Storing your GPG or SSH key on such a security key is not covered by the BYOD policy either.

Information Assets

For the purposes of this policy, the term information assets is applied to information systems and other information/resources, including paper documents, mobile phones, portable computers, storage devices, etc.

Information System

Includes all servers and workstations, network infrastructure, system programs and applications, data, and other computer subsystems and components owned by, used by, or under the organization’s responsibility. The use of any information system also includes usage of all internal or external services such as Internet access, email, etc.

Mobile Device

VSHN treats all provided computers and storage as mobile devices. This includes, in particular, all types of computers, mobile phones, smartphones, memory cards and other portable devices used for the storage, processing and transmission of data. This does not include fixed devices such as monitors, docking stations, etc. No approval is required for the removal of a mobile device from the organization’s site.

Remote Working

According to ISO/IEC 27002:2022 "remote working occurs whenever personnel of the organization work from a location outside of the organization’s premises, accessing information whether in hard-copy or electronically via ICT equipment."

131.3. General

Acceptable Use

Information assets provided by the company are to be used primarily for business purposes to perform tasks for the organization. Personal use outside working hours is permitted with restrictions according to the point Forbidden Activities below.

Forbidden Activities

Use of the infrastructure in a manner that unnecessarily uses capacity, degrades the performance of the information system, or poses security risks is not permitted.

It is also forbidden to…​

use the business email address for personal correspondence.

use external devices for storing and reading business data (for example USB Flash Drives) without the explicit approval of the CISO; use in compliance with the Information Classification Policy is permitted.

Responsibility for Assets

Each information asset held by VSHN is assigned an owner in the inventory of assets. The asset owner is responsible for the confidentiality, integrity, and availability of the information in that asset.

131.4. Confidentiality and Privacy

Confidentiality Levels

According to the Information Classification Policy, information is categorized into the following confidentiality levels:

Level "Public" / "Öffentlich": not marked

Level "Authorized" / "Berechtigt": marked "INTERNAL" / "INTERN"

Level "Confidential" / "Vertraulich": marked "CONFIDENTIAL" / "VERTRAULICH"

Use of AI and Translation Services

The usage of generative AI like ChatGPT or translation services like DeepL is allowed. However, users must take utmost care to not share any sensitive data through such tools. [2].

Security Concerns

Users are responsible for using generative AI and translation tools only in a secure manner. They must make absolutely sure that no passwords, secrets, or other confidential or sensitive information is ever being submitted.

Privacy

Users are responsible for protecting the privacy of personal and company data when using such tools. That means ensuring to not submit information that can be used to identify yourself or others.

Intellectual property

Every VSHN employee is responsible for respecting the intellectual property rights of others when using generative AI and translation tools. They must not infringe any copyright of another party using such tools.

Accuracy

VSHN employees are responsible for how the information generated by AI and translation tools is used. The result must not be blindly accepted as correct without verification.

Integrated Cloud Translation Tools

Tools like LanguageTool (and any others) for integrated translation must run with a local server or a server approved by Corporate IT. [3]

Integrated AI Tools

AI Tools directly integrated in your working environment (that is your IDE) must not be used. The CISO can define exceptions. [4]

Clear Desk and Clear Screen

Any information classified as "Authorized" and "Confidential" under the Information Classification Policy is considered sensitive information in this section.

Clear Desk Policy

If a VSHN employee is not at their desk, all paper documents and data carriers marked as sensitive must be removed from the desk and other locations (printer, copier, etc.) to prevent unauthorized access.

Such documents and media must be stored securely in accordance with the Information Classification Policy.

Clear Screen Policy

If the user is not at their workstation, sensitive information must not be displayed on the screen.

To ensure this, all users must lock their screen immediately when leaving their work desk.

Physical Security

All employees must adhere to the ISMS Physical Security Policy. Particularly:

Regularly check your peripheral devices such as keyboards to ensure they are not manipulated and no keyloggers are attached. [5]

Make sure guests are accompanied and aren’t left alone in the office.

Protection of Physical Documents

Documents containing sensitive information must be removed from printers and copiers immediately.

Postal Mail

Incoming

Incoming mail is to be received solely by authorized personnel from Office Management.

Identification of personal mail:

Mail marked as "Personal" or "Confidential" or with the employee’s name above the company name is considered private.

Personal mail items are not opened; the intended recipient is notified.

The recipient is informed about the arrival of their personal mail and the consignment is put into their inbox in the office.

Outgoing

Employees are responsible for outgoing mail themselves.

Office Management carries a supply of stamps.

Work from Outside Switzerland

Because of the Swiss Data Protection Law by default employees are only allowed to work from Switzerland, Canada, or European Economic Area. Exception from that rule must be discussed with ISMS work group before working abroad as customers must be informed if their data is processed outside that defined countries. [6]

Some customers must not be served from outside Switzerland. Employees working outside Switzerland must ensure that they do not connect to such services and servers. See the wiki page Definition of "Leistungserbringung" for further information.

Employees who work remotely outside Switzerland (except VSHN Canada) must follow the policy Working abroad (out of Switzerland) which includes legal obligations.

Authorizations for the Use of Information Systems

Users may only use the information system for the purposes for which they are authorized.

Users must not perform any activities that could be used to circumvent the security measures of the information system.

Certain employees (including members of the board, management, and some engineers) have admin access rights for operational reasons. Examples of this include tasks such as maintenance or granting access rights. In theory, these employees could use such rights to grant themselves additional permissions or to log in with a shared admin user account, thereby potentially viewing, modifying, or copying data they are not authorized for. Such confidential information includes for example information from the People Ops/HR area on VSHN systems, as well as any sensitive customer data such as "customer identifying data (CID)" of banking customers.

Intentional access to data for which one does not have authorization is strictly prohibited and will be internally investigated in every instance. Such cases typically lead to immediate termination of the employment contract and the filing of a criminal complaint.

User Account Responsibilities

The user may not, either directly or indirectly, allow other persons to use their credentials (user name/password, ssh keys, etc.), nor may they use any of the credentials of another person.

The use of shared user names is to be avoided whenever possible.

The user of a user account is its owner, responsible for both the use of the user account and all actions conducted with it.

Passwords

Users must follow these best practices concerning security when selecting and using passwords:

Passwords may not be disclosed to other persons.

Passwords must not be written down in plain text.

Each user may only use the credentials assigned to them individually.

Personal passwords must be stored using a password manager. See Password Managers for a list of recommended password manager.

Personal passwords created by the user may not be passed on in any way (verbally, in writing or electronic form, etc.).

Passwords must be changed if there is any indication that the passwords or system may have been compromised - in which case a security incident must be reported.

Secure passwords can either be chosen by the user or generated:

Requirement for a self-selected password:

Length of at least 12 characters. If the User has elevated rights at least 18 characters.

At least three out of the following four groups of characters must be represented: digits, upper case letters, lower case letters, special characters.

Passwords must not contain any personal data (for example date of birth, address, names of family members, etc.).

Generated passwords:

Passwords can be generated using the methods provided in Generate a Password.

Personal passwords that protect publicly available services should be changed every 12 months. The last three passwords must not be reused.

The CISO may order passwords to be changed at any time.

Passwords not set by the user must be changed the first time the user logs on to a system.

Passwords used for private purposes must not be used for business purposes and vice versa.

Email and Other Methods for Exchanging Messages

According to the Information Classification Policy, management determines the communication channels that may be used for each type of data. Means of communication are documented in the handbook page Communication Channels.

When sending a confidential message, the user must protect it according to the Information Classification Policy. For acceptable methods of transferring confidential messages, see "How to transfer data securely".

Decisions and important information from chat must be documented in an appropriate system because information in the chat system is meant to be short-lived. Chat accounts from former employees are deleted after 6 months and therefore chat history won’t be a reliable source of truth.

Paper and ePaper Notebooks

Paper notebooks with work notes must be secured similarly to your laptop.

ePaper notebooks must have a PIN set.

Loss or theft of a notebook must be reported to the ISMS work group.

131.5. Equipment

Personal Device

Each employee gets a VSHN-issued personal work device according to Personal Hardware Budget.

Warranty and Repairs

Warranty and repairs are handled through purchases according to Personal Hardware Budget.

Confidential information (for example unencrypted disks) must be removed before repair.

After maintenance, the equipment must be checked for signs of tampering before putting it back into service.

If the equipment cannot be repaired, follow the disposal and destruction policy.

Taking Assets Off-Site

If an employee takes information assets or mobile devices outside the VSHN AG premises, the employee is fully responsible for their secure storage and monitoring.

Assets Return Policy Upon Contract Termination

Upon termination of employment or any other contract, all assets, including equipment, software, or information, must be returned to VSHN.

The off-boarding process is led by people operations.

Departing employees who want to keep their device as per the Personal Hardware Budget must provide evidence that all data owned by VSHN has been removed.

Internet Usage

Internet in the VSHN office is provided primarily for work-related purposes. It isn’t specially secured and all employees have to use it responsibly. All VSHN services are in the cloud and all connections to these services are encrypted.

The office WiFi is for use by VSHN employees only. For mobile phones the guest network should be used.

The user is responsible for all possible consequences that may result from unauthorized or inappropriate use of Internet services or content.

Web Filter

Users must use content blocking for their browser, for example installing content blockers according to advice of Corporate IT to reduce the risk of being compromised by malware. [7]

131.6. Mobile Devices, Remote Working, and Bring Your Own Device (BYOD)

Basic Rules

Anyone who uses computers outside the organization’s location or who is working remotely must observe the following rules:

Computers must be supervised, locked up or secured with special locks. Storage in the employee’s own home is considered locked in. The employee must ensure that information on the device cannot be accessed by family and friends.

When using computers in public places, the user must ensure that unauthorized persons cannot read or see data. For employees who regularly work in public areas (for example on trains) the use of a screen protection film / privacy filter is recommended.

Users must keep their devices regularly updated with the latest security updates from the supplier/manufacturer.

Systems which are no longer supplied with security updates by the provider/manufacturer may no longer be used.

To ensure a secure environment, users may be required to run scripts provided by Corporate IT in order to verify security settings.

The person using the computer is responsible for regularly backing up the data.

Connections must always be encrypted. WiFi networks at users’s home offices must comply with current security requirements. When using devices in public, a hot spot provided by the user’s mobile phone or an integrated mobile broadband is to be used whenever possible. Public WiFi should only be used with caution and a VPN (see How to Create a VSHN Full VPN Tunnel in our wiki) must be used through which all traffic is routed.

Information on computers must be encrypted. For this purpose, the entire hard disk must be encrypted except for the boot partition (see also Anhang: Anleitung zur Nutzung der kryptographischen Massnahmen)

The protection of sensitive data must be implemented in accordance with the Information Classification Policy.

Protection software such as anti-virus and firewall should be used according to best practices for the operating system in use.

Installation of software should be performed according to best practices for the operating system in use. Software that is incorrectly licensed or unlicensed must not be installed.

The ISMS work group is responsible for training and awareness of individuals using mobile devices outside of the organization’s location.

Additional Regulations Regarding Private Computers (BYOD)

VSHN is automatically assigned copyright on business-related work created on personal computers. The employee waives ownership of business data on the personal computer.

The employee grants VSHN the right to obtain accompanied access to the personal computer for the purpose of security checks or for audits, etc. Such access is carried out in accordance with our DPA in section "Subcontracting, teleworking and place of processing", paragraph 6.f.

The employee is responsible for ensuring that the used software is properly licensed.

A new personal computer to be used for BYOD must be reported to and approved by the CISO before it may be used. The personal device must be uniquely identifiable with the following information:

Manufacturer

Model/Description

Serial Number or IMEI for mobile phones

Address for non-mobile devices

Changes of status (no longer used, stolen, sold, lost, etc.) of the private computer must be reported to the CISO immediately.

In the case of dual-boot systems, which can be clearly separated into personal and business, the regulation concerning encrypted hard disks only applies to the operating system used for business.

Unauthorized Use

The following is not allowed with a computer:

Giving an unauthorized person access to company data stored on it.

Storing illegal data on the device.

Installation of unlicensed or incorrectly licensed software.

Transfer of company data to other unauthorized devices.

Security Breaches

All security breaches related to mobile devices, remote working, and BYOD must be reported immediately according to the Incident Management Process.

131.7. Data Storage

USB Flash Drives

USB flash drives may only be used if they come from VSHN’s stock in the storage room or if they were bought from a reputable shop and are still in the original, unopened package.

USB flash drives may only be used for:

creating bootable sticks to install or run operating systems.

personal data.

business data where there is no alternative, for example quotations.

It is explicitly forbidden to use USB flash drives that came from an unverifiable origin or were given as promotional gifts.

Backup Procedure

As a matter of principle, all data must be stored in VSHN owned services (Nextcloud, Wiki, ERP, Gitlab, etc.), thereby ensuring daily backups at all times. The user is responsible for ensuring there is a backup of data that is stored locally.

Backups can be done with:

The VSHN backup system according to the instructions in the appendix in our wiki.

Other backup systems that are encrypted client-side.

Local working copies (Git repositories, Nextcloud Sync, Vagrant caches, etc.) do not require being backed up periodically.

Cloud Storage

Employees must not store data on cloud storage such as Google Drive, OneDrive, and any others. Only cloud storage approved by Corporate IT may be used.

131.8. Copyright

Users must not make unauthorized copies of software.

Users must not copy software or other original material from other sources without authorization and are responsible for any consequences that may arise under intellectual property laws.

131.9. Monitoring the Use of Information and Communication Systems

All data created, stored, sent, or received via the information system or other communication systems, as well as via various applications, email, Internet, etc. of the organization, whether of a personal nature or not, are considered the property of VSHN AG.

The user agrees that persons authorized by management may access this data and that this access is not considered a violation of their privacy. In other words, VSHN is entitled to access the personal VSHN mailbox if operationally necessary.
Even though personal mail usage is prohibited according to Forbidden Activities, authorized personnel must refrain from viewing private emails that are clearly marked as such (for instance, by including 'PRIVATE' in the subject or folder).

131.10. Incidents

Every employee, supplier, or other third party who deals with data and/or systems of VSHN AG must promptly report any system vulnerability, incident, or occurrence that indicates a potential incident, in accordance with the Incident Management Process.

131.11. Training and Awareness

The ISMS work group is responsible for employee training and awareness within the scope of this policy. This includes, in particular:

the usage of mobile computing off-site at VSHN.

the appropriate use of BYOD.

promoting awareness of the most prevalent threats or hazards.

131.12. Meta Information

Policy Tracking

This policy is tracked and approved by the ISM Domain with ticket ISMS-166 and changes must be approved by Management.

Effective From

This policy is effective from September 25, 2023, and was completely revised, reviewed, and released in MR 892 with ticket ISMS-1210.

Reference Documents

ISO 27001:2013
ISO 27001:2022
Control Name ISO 27001:2022

A.8.1.2

A.5.9

Inventory of information and other associated assets

A.8.1.3

A.5.10

Acceptable use of information and other associated assets

A.8.1.4

A.5.11

Return of assets

A.13.2.1

A.5.14

Information transfer

A.13.2.3

A.5.14

Information transfer

A.9.3.1

A.5.17

Authentication information

A.18.1.2

A.5.32

Intellectual property rights

A.6.2.2

A.6.7

Remote working

A.11.2.9

A.7.7

Clear desk and clear screen

A.11.2.6

A.7.9

Security of assets off-premises

A.11.2.5

A.7.10

Storage media

A.11.2.4

A.7.13

Equipment maintenance

A.6.2.1

A.8.1

User endpoint devices

A.11.2.8

A.8.1

User endpoint devices

A.12.2.1

A.8.7

Protection against malware

A.12.3.1

A.8.13

Information backup

A.12.5.1

A.8.19

Installation of software on operational systems

A.12.6.2

A.8.19

Installation of software on operational systems

Record Management

Record
Responsible person
Measure for the protection of the record
Storage duration

List of permitted BYOD devices

CISO

Only the CISO may edit the list and release a new version of it.

3 years

² This section was inspired by Amazee’s Handbook regarding generative AI tools

³ A language tool integrated e.g. in a browser sends all written text to a server. That means all information we write in our ticket system is shared with an uncontrolled third party. Therefore it is forbidden until approved officially.

⁴ A chatbot / AI tool integrated your IDE sends all written code to a server and so is shared with an uncontrolled third party. Therefore it is forbidden until approved officially.

⁵ See also our internal ticket ISMS-1323.

⁶ See also our internal ticket ISMS-1383 and our AVV Art. 6e resp. DPA Art. 6e.

⁷ for example use uBlock Origin.

132. ISMS Development Security Policy

132.1. Purpose, Scope and User

This policy documents VSHN’s fundamental rules for secure development.

This document applies to the development and maintenance of all services, architecture, software, and systems developed by VSHN AG.

Users of this document are all technical employees of VSHN AG.

132.2. Reference Documents

ISO/IEC 27001:2013 standard, sections

A.9.4.5

A.14.2.1

A.14.2.2

A.14.2.5

A.14.2.6

A.14.2.7

A.14.2.8

A.14.2.9

A.14.3.1.

132.3. Security in Development and Support Processes

Security of the Development Environment

The development environment must be protected from unauthorized access to prevent unsolicited program code from being introduced. Engineers at VSHN are responsible for securing their development environments.

Storage Location

Program code and all other files related to development are managed with distributed version control system (as of now mainly git).

Our Engineering Manifesto defines where to store which kind of source code.

Version Control

Code and all other files related to development are managed with distributed version control system (git) and are thus cleanly versioned and checked for integrity.

Software releases should be versioned according to our Engineering Manifesto.

Required Security Training

VSHN defines the requirements and the necessary knowledge required as part of the development process and proposes the training required for this purpose. Training programs are documented in our wiki (internal) in the "Plan für Training und Awareness" and VSHNeer Certifications & Accreditations

Management of System Changes

The transition from development to operation is performed according to the change procedure documented in Betriebsverfahren für Informations- und Kommunikationstechnik (internal).

Further the guidelines in the Engineering Manifesto have to be followed.

132.4. Principles for the Analysis, Development and Maintenance of Secure Systems

The following basic principles apply to all internal and external developments of VSHN:

Input/data validation

User input must always be validated

Input validation must be done in the back end / server

Client-side validation only supplementary (for example to improve usability)

Authentication

Authentication only via secure channels (for example TLS)

No clear text storage of authentication tokens or passwords

User accounts can be disabled

Prefer authentication based on PKI procedures over plain password authentication

Consider to use multi-factor authentication

Consider to connect to the SSO infrastructure

Authorization

Principle of least privilege

Role-based authorization

Privilege separation

Access to external resources via API token or service account

Sensitive data

If possible, refrain from storing sensitive data

If sensitive data is stored, it’s stored in encrypted form

Sensitive data only transmitted via secure channels (for example TLS)

Cryptography

Use proven existing implementations, no proprietary developments

When using PKI, secure rotation of key material must be ensured

Storage of private keys in designated systems

Error handling

Don’t log sensitive data such as passwords or private keys

Structured exception handling

Integration into central monitoring systems

Audit trail

Operations with access to sensitive data must be logged

Operations that modify data should be logged

Log files should follow a clearly structured format to facilitate automated analysis

Log files should be backed up and analyzed on a regular base

In addition, specific guidelines apply to the individual programming languages used. These are documented in the technical guidelines in our Wiki.

132.5. Handling test data

To test a system, usually test data is required. This test data should be as close as possible to the production data. The following principles apply to the use of test data:

Test data should be anonymized if possible

The same access control procedures apply to test and production systems

Any transfer of production data to a test system must be logged (for example documented in the ticket)

This policy is tracked and approved by the CISO with ticket ISMS-176

133. ISMS Security Incident Management Process

133.1. Purpose, Scope and User

This document defines the process how VSHN handles security events and vulnerabilities.

Further it defines the objectives and processes to for threat intelligence.

133.2. Definition of a Security Incident

An information security incident is "a single or a series of unwanted or unexpected information security events that have a significant probability of compromising business processes and threatening information security" (ISO/IEC 27000:2016, translated from German).

133.3. Triggers of a Security Incident

The following events can trigger a security incident and should be handled according to this document.

Loss or theft of equipment

Loss or theft of information

Data loss on VSHN systems

Unauthorized access to customer data and other sensitive data (for example customer names passed on to other customers, access by customers to data of other customers, etc.)

Protected data (for example passwords, confidential documents, etc.) that were viewed or sent via insecure channels

Violation of the Acceptable Use Policy (AUP)

Openly accessible papers requiring protection (confidentiality level "Authorized"/"Berechtigt" or higher)

Indications that passwords, sensitive data or the system may have been compromised

Targeted attempts by third parties to gain unauthorized access to VSHN systems

Large-scale and noticeable attacks on VSHN systems (DDoS, viruses, etc.)

Long unresolved security vulnerabilities in software, packages, etc. used by VSHN (for example no updates on important servers)

Phishing mails whose links have been clicked on by employees or subsequently user entries have been made.

Targeted Phishing mail attack with APT tactics. In other words, if a targeted phishing e-mail is sent to a person in VSHN using publicly accessible data from VSHN or internal information obtained through social engineering in order to damage VSHN

Attempted or successful social engineering

Longer backup failures of VSHN systems

Longer failures of system-relevant VSHN systems

Physical access of unauthorized persons to the offices of VSHN

Possible violations of regulations or laws by VSHN or its employees

Other triggers where there is a suspicion that confidentiality, integrity or availability is at risk. The principle is to report one incident too many rather than too few.

133.4. Report Security Incident

Each employee or third party who is in contact with information or systems of VSHN AG must report any system vulnerabilities, incidents or events that could lead to a possible security incident as follows:

All incidents must be reported to the CISO or the Information Security Management Interest Group.

The observer creates a security incident ticket according to How to Create Security Incident Tickets.

The observer ensures that the CISO or the Information Security Management Interest Group is aware of the ticket and that immediate measures are applied if needed.

133.5. Treatment

First an initial assessment must be done, then work through bullet points according to classification.

Initial Assessment

The CISO ensures:

Assessment of the incident and whether immediate measures are needed:

Organize immediate measures in coordination with the Responsible Ops.

Define a ticket owner.

Classification of the incident in four categories:

Security vulnerability or event - no incident has occurred, but the event related to a system, process or organization could result in an incident in future.

Minor Incident - an incident that doesn’t have a significant impact on the confidentiality or integrity of information and can’t cause a longer-term loss of availability.

Major Incident - an incident that could cause significant damage through the loss of confidentiality or integrity of information, or that could cause an interruption in the availability of information or processes for an unacceptable period of time.

Incident endangering the business continuity - a serious incident that could endanger the existence of VSHN.

Security Vulnerabilities or Events

The CISO analyzes the information, determines the cause and, if necessary, proposes preventive and corrective measures.

All actions must be recorded in the ticket system.

Minor and Major Incidents

If a minor incident is reported, following steps must be done:

Take measures to isolate the incident.

Analysis of the causes of the incident.

Take corrective action to eliminate the cause of the incident.

Informing those affected by the incident and the Management about the procedure for handling the incident.

If customers are involved then Management must assess whether they should inform the customer also from C-level to C-level.

The assignee of the ticket must document taken actions in the ticket system.

Incidents that Endanger the Progress of Business

In the event of incidents that endanger the progress of business, an emergency management plan comes into effect.

The assignee of the ticket must document taken actions in the ticket system.

133.6. Learning from Incidents

The CISO must analyze each incident and document following points in the ticket:

identification of the type

origin of an incident

and cost of an incident

The CISO must review all incidents on a quarterly basis and propose appropriate preventive or corrective measures for those that recur (or those that could become significant incidents the next time they recur). The verification is ensured by the recurring ticket ISMS-181 and documented in the VSHN’s wiki.

133.7. Threat Intelligence

The objective of VSHN’s threat intelligence is to ensure that the ISMS Work Group remains updated on potential threats and can effectively communicate this information to employees working on the front line.

The CISO is responsible for analyzing new potential threats during the quarterly review, as defined in the Learning from Incidents section. The following three layers of threats should be analyzed:

Strategic threat intelligence (high-level information about the changing threat landscape)

Tactical threat intelligence (information about attacker methodologies, tools and technologies)

Operational threat intelligence

For strategic and tactical intelligence analysis, the CISO utilizes sources documented in Security and Vulnerability Handling Process; this list may be expanded or modified during the analysis process. Operational intelligence is gained from the incidents documented by VSHN and other relevant sources. A summary is quarterly documented in Annex - Quarterly Review of Security Incidents with the ticket ISMS-181. The CISO is responsible for deciding whom to communicate the findings to and to define follow-up tickets to be looked at by VSHN’s teams.

133.8. Disciplinary Measures

The Management may initiate disciplinary processes for any violation of security rules.

133.9. Collection of Evidence

If there is a suspicion that an incident occurred due to criminal activities, evidence must be secured immediately. For this purpose, external partners such as Swiss FTS are called in who have the necessary expertise in handling evidence. The CISO is responsible for the coordination.

133.10. Reference Documents

ISO 27001:2022
ISO 27001:2013
Control

A.5.7

N/A

Threat intelligence

A.5.24

A.16.1.1

Information security incident management planning and preparation

A.5.25

A.16.1.4

Assessment and decision on information security events

A.5.26

A.16.1.5

Response to information security incidents

A.5.27

A.16.1.6

Learning from information security incidents

A.5.28

A.16.1.7

Collection of evidence

A.6.4

A.7.2.3

Disciplinary Process

A.6.8

A.16.1.2, A.16.1.3

Information security event reporting

133.11. Appendix

Annex - Quarterly Review of Security Incidents

Incidents blocking ticket ISMS-243

Related process Security and Vulnerability Handling Process

This policy is tracked and approved by the CISO with ticket ISMS-180

134. ISMS Physical Security Policy

134.1. Purpose, Scope and User

This policy defines VSHN’s rules regarding physical access to VSHN’s premises.

All employees of VSHN AG must adhere to this policy.

134.2. Physical Security Perimeters

The office in Neugasse 10 in Zürich is considered a security perimeter.

Data centers of third party providers where VSHN’s hardware is running, are considered a security perimeter.

Not considered as security perimeter are the VSHNtower in Neugasse 6, Zürich, and the shared offices in VSHN Canada, 422 Richards St, Suite 170 Vancouver.

134.3. Access Rights

VSHN Office

All VSHNeers have access and have their own key.

VSHNeers can grant accompanied access to guests if a visitor log was filled.

People Operations controls who has an office key with the corresponding ticket ISMS-198.

Access to Hardware Servers

Access can be ordered via the management or the ISMS Work Group. A ticket must exist in VSHN’s ticket system with the work to be done.

Access to VSHN servers at third party providers is only possible for VSHN employees after prior coordination. Access control is handled by the data center provider.

134.4. Visitor Logs

Each visitor must fill out one of the visitor log forms provided in the coffee room.

If visitors are working for a longer period with us, an NDA must be signed and the visitor log isn’t needed after that.

VSHNeers' Responsibility

VSHNeers inviting guests are responsible that:

Visitor log form is filled out.

Visitor does not walk around in the office unsupervised.

Visitor log is placed in the visitors log "mail box".

Back-Office Responsibility

PeopleOps checks visitor log forms regularly and files them in a physical ad-hoc folder.

Visitor logs older than a year are destroyed.

The CISO conducts regular spot checks.

Exceptions

Exceptions to this rule can be found in Annex - Exceptions Physical Security in our wiki.

134.5. Physical Security Monitoring

VSHN can monitor access to secure spaces using video surveillance and other technical appliances.

Exceptions of this rule can be found in Annex - Exceptions Physical Security in our wiki.

134.6. VSHNeers' Duties

Ensure the two entry doors on the first (European floor numbering system) floor leading to the coffee room and the one leading to the hallway are always closed.

Ensure visitors are never left alone.

Ensure all windows are closed when the work day is finished.

Ensure no confidential paper is lying around.

Regularly check the physical connections of your keyboard and mouse, ensuring they are directly connected to the docking station to prevent threats like keyloggers.

Keep VSHNtower clean; this means you are not allowed to leave sensitive data there or leave your devices unsupervised.

134.7. Events

Events can take place in VSHNtower as it is considered a public space.

Events should not take place in the VSHN office. If this is not possible, check with CISO and checklist.

134.8. Reference Documents

ISO 27001:2013
ISO 27001:2022
Control

A.11.1.1

A.7.1

Physical security perimeters

A.11.1.2

A.7.2

Physical entry

A.11.1.3

A.7.3

Securing offices, rooms and facilities

N/A

A.7.4

Physical security monitoring

A.11.1.4

A.7.5

Protecting against physical and environmental threats

A.11.1.5

A.7.6

Working in secure areas

This policy is tracked and approved by the CISO with ticket ISMS-557

135. ISMS Supplier Security Policy

135.1. Purpose, Scope and User

The purpose of this document is to define rules for relationships with suppliers and partners.

This document applies to all suppliers and partners who have the possibility to influence the confidentiality, integrity and availability of sensitive information of VSHN AG.

135.2. Relationships with Suppliers and Partners

Identification of Risks

Fundamental security risks related to suppliers and partners are identified in accordance with the risk assessment and treatment methodology during the risk assessment process.

The Partner Management domain decides whether it is necessary to assess additional risks related to individual suppliers or partners.

Screening

The domain Partner Management decides whether it is necessary to check the background of certain suppliers and partners and, if so, which methods are to be used. Such a screening follows the same objectives as the Debt Collection Register and Criminal Records for employees.

Contracts

The domain Partner Management is responsible for deciding which security clauses to include in the contract with the respective supplier or partner. This decision must be based on the results of the risk assessment and treatment. The clauses on confidentiality and return of assets are mandatory in every contract with suppliers and partners who require access to confidential data. In addition, the reliable delivery of products and services should be anchored in every contract.

A list of recommended clauses can be found in the appendix "Security clauses for suppliers and partners".

Employees of the supplier/partner who work directly for VSHN must sign a confidentiality agreement / NDA, unless this has been agreed in the framework agreement with the supplier/partner.

The domain Partner Management decides who is the contract owner of each individual contract, that is who is responsible for the respective supplier or partner.

Training and Awareness

External employees who have access to data of VSHN and its customers may be requested by VSHN to participate in security and awareness training courses in accordance with the training and awareness plan.

The CISO is responsible for providing all security training and awareness measures for these employees.

Monitoring and Auditing

The Contract Owner shall regularly review and monitor the quality level of the services and the fulfillment of the security clauses by the suppliers or partners as well as their reports and records. If the risk classification has shown an increased risk, an audit must be carried out at the supplier/partner at least once a year.

All security incidents in connection with the supplier’s/partner’s tasks must be reported immediately in accordance with the ISMS Security Incident Management Process.

Changes to or Termination of Supplier Services

The contract owner proposes changes or termination of the contract and the final decision lies with the management.

Withdrawal of Access Rights / Return of Assets

If the contract is amended or canceled, the access rights of the supplier/partner’s employees must also be withdrawn at the same time and in accordance with the access control policy.

If the contract is amended or canceled, the contract owner must also ensure that any equipment, software or information is returned in electronic or paper form.

135.3. Cloud Services

VSHN does not own or manage physical hardware. Internal IT services and services provided to customers are hosted on cloud-based platforms.

Definition of Cloud Service

ISO/IEC 22123:2023 defines cloud service as follows:

3.1.1 cloud computing

paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand
Note 1 to entry: Examples of resources include servers, operating systems, networks, software, applications, and storage equipment.

3.1.2 cloud service

one or more capabilities offered via cloud computing (3.1.1) invoked using a defined interface

~ ISO/IEC 22123:2023

Conclusion: everything VSHN has in terms of IT is are cloud services and therefore covered by all policies. Goal of this section is to add additional cloud specific guidelines.

Cloud Services for Internal IT

Corporate IT maintains a list of cloud services used for internal IT.

New services must use the Annex 2 - Checklist for SaaS/Cloud Services to get approved for corporate IT.

Cloud Services for Managed Services

Cloud providers for VSHN Managed Services must be ISO/IEC 27001:2022 or certified or having a similar certification / assurance report. The certificates are reviewed with Annex 2 - Checklist for SaaS/Cloud Services.

135.4. Reference Documents

ISO 27001:2022
ISO 27001:2013
Control

A.5.11

A.8.1.4

Return of assets

A.5.19

A.15.1.1

Information security in supplier relationships

A.5.20

A.15.1.2

Addressing information security within supplier agreements

A.5.21

A.15.1.3

Managing information security in the information and communication technology (ICT) supply chain

A.5.22

A.15.2.1, A.15.2.2

Monitoring, review and change management of supplier services

A.5.23

N/A

Information security for use of cloud services

A.6.1

A.7.1.1

Screening

A.6.2

A.7.1.2

Terms and conditions of employment

A.6.3

A.7.2.2

Information security awareness, education and training

A.8.30

A.14.2.7

Outsourced development

135.5. Appendix

Sicherheitsklauseln für Lieferanten und Partner

Überwachung und Prüfung von Lieferantendienstleistungen

Annex 1 - Supplier’s Certificates

Annex 2 - Checklist for SaaS/Cloud Services

ISMS-596 - Annually Verification of Cloud Suppliers Certificates

This policy is tracked and approved by the CISO with ticket ISMS-178

136. Product Roadmap

We use Productboard to:

Collect insights from VSHNeers and customers

Track, prioritize and plan product features

Communicate internal and external Roadmaps

136.1. Insights and Portal

We collect insights on various places:

Source
Audience

APPUiO Cloud Portal Integration

APPUiO Cloud Users

HubSpot: Field on Contact "VSHN Productboard Insights"

Sales & Account Management

Public Productboard Portal

VSHNeer and all Customers

VSHN Portal

VSHN Customers

Direct Input

VSHNeer power users (Contributor Role).
See also How to add Insights

E-Mail to feedback@vshn.ch (Alias for redirection)

Everyone?

Insights are regularly analyzed and processed by the Product Management and Product Owners. Processing of insights generally is a Team effort, but can also be refined after that by the Product Owner.

The "User Impact Score" [8] is communicated via insights. Either it comes directly via the Productboard Portal or it is set during processing of insights. It’s important to only set the User Impact Score according to what has been learned from the insight. When in doubt, the author of the insight must be asked or discussed in the team.

How to add Insights

Browse to Insights, login with your personal account

Click on the big blue "+" sign located lower-left

Fill in the fields

Give the insight a meaningful title

Connect the insight to a customer and/or user. Create it if it doesn’t exist yet.

Fill in all information you have, the more, the better. If you have any sources, please link them.

That’s all, Product Management will take care of processing these insights regularly (see Working with Productboard).

Productboard Portal

The official URL is portal.productboard.com/vshn/. We have various redirects in place:

roadmap.vshn.ch

feedback.vshn.ch

roadmap.appuio.cloud

The Productboard Portal is used to communicate our plans to the public. Cards on this Portal are manually crafted and can also be used to communicate with interested parties about the state.

Each VSHN product gets its own section on the various tabs.

Tab: Under Consideration

Features we’re pretty sure are coming and are actively being researched. State of the related feature must be at least "Discovery".

Tab: Planned

Features planned to be worked on (Jira Stories are already in a Sprint) or are actively being worked on. State of the related feature must be at least "Planned".

Tab: Launched

Features rolled out and ready to be used. State of the related feature must be at least "Announcement".

136.2. Features

Shared Views

We have the following shared views defined:

All Products Scoring and Prio

Shows all products and features in one view. Direct Link.

Per Value Stream for Prioritization

A view per value stream (can contain multiple products), used for prioritization. The following fields are displayed:

Factors: Impact, Confidence, Ease

Formulas: ICE Score and ICExUIS Score

User Impact Score

Jira Link

Hierarchy

Level 1: VSHN Main Product (Type: Product)

  Level 2: Product Flavor (Type: Component)
           Flavor of the main product (sub-product), sharing the same Drivers and Priority rules

    Level 3: User Need (Type: Component)

      Level 4+: Product Feature or Subcomponent (Type: Component or Feature)
                Clarifying the structure further or specifying a feature addressing the User Need

Levels can be skipped if they don’t apply to a product or just don’t fit.

Prioritization

We have two inputs for prioritization: external and internal. The external input is the User Impact Score (see further down below), whereas the internal score is based on the ICE Scoring Model (Impact, Confidence, Ease).

Prioritization is used per state and helps to define which Feature transitions into the next state.

Table 1. Factors

Factor
Description

Impact

How impactful do we expect this feature to be? Impact can be on user, goal, market traction or others.

1: Very low impact

2 - 5: Minimal impact

6 - 8: Measurable impact

8 - 10: Significant impact

Confidence

How confident are we that this feature will prove our hypothesis and deliver the desired results?

From 0% (absolutely not confident) to 100% (fully confident) in 10% steps.

Ease

How much effort will it take to implement that feature?

1 - 2: 1+ Epics, 10+ Stories

3 - 5: 1 Epic, 8+ Stories

6 - 7: 1 Epic, 3+ Stories

8 - 10: 1-2 Stories (no Epic)

The scale of factors is always 1 - 10.

Table 2. Scores

Name
Formula

ICE Score

ICE scores are not exact science. They’re just a hint - knowing what we know now, these are the ideas that look most promising. ICE does not guarantee that these are the best ideas, or that they will even work.

~ Itamar Gilad ICE Scores - All You Need to Know

Some resources to learn about this model:

itamargilad.com/ice-scores/

productfolio.com/ice-scoring/

www.growthmentor.com/glossary/ice-scoring-model/

User Impact Score

Sum of points from insights.

For every piece of user feedback that is linked to a feature, its user impact score increases according to the following scale:

+0 points: Not important

+1 point: Nice-to-have

+2 points: Important

+3 points: Critical

ICExUIS Score

Assigning Factors

Assigning the factors is in the hands of the Product Management and respective Product Owner. This is to lower the friction and have meaningful data available with minimal effort. As a feature progresses through the states and we learn more about them, we have to update the factors to the current knowledge.

Factors are assigned to all features, independent in which state they are. The further a feature progresses towards the Planned state, the better the factors can be assessed.

Choosing features to work on next

Usually the feature with the highest rank gets chosen to work on next (transition into the next state). That could mean the feature with the highest:

ICExUIS Score

ICE Score

User Impact Score

But that might not always be the best judge and usually a debate with arguments can lead into a choice to work on a feature with a lower score.

States

Active

Status
Meaning
Notes

New Idea

The feature idea inbox - untriaged

These are new ideas which can be in a very raw format, they are "free" because no further work is being done with them at this time.

Discovery

Prioritized new ideas to figure out all the details - research.
This is a critical stage as it needs a lot of time to be done properly - it’s the refinement phase.
Can move into Candidate or Won’t Do.
The feature needs to be properly written with the "Feature Template" (directly available in Productboard) so that it can be prioritized.

These features are not free as they will cost a lot of time to properly work out.

Candidate

Feature is selected to be a candidate for implementation.
Discovery had to be made to be able to go into that state. From now on it will be part of the prioritization efforts.

Features in this state will be part of the prioritization effort and therefore will cost some time.

Planned

Planned to be handed over to the team to start working on it.
This is where it flows from Productboard to Jira Epics / Stories.

This will cost a lot of time as Jira issue have to be properly prepared. It will be externally communicated, via Productboard Portal.

In Progress

Feature is being worked on in the Team.
This could also mean that the Team still has to run through their own workflow of planning / doing (refinement and estimation).

This will cost a lot of time as this is the implementation phase. It will be externally communicated, via Productboard Portal.

Announcement

The feature is done but still needs to be properly announced (Marketing).

This will cost some time for writing and communication.

Inactive

Status
Meaning
Notes

Parking Lot

Ideas and features which we currently won’t implement but find interesting enough to keep and not just close it.

This list has to be cleaned up from time to time.

Released

Feature is completed (Implemented, Rolled Out, Announced)

-

Won’t Do

Assessed but deemed to not be appropriate to implement.

-

These statuses have nothing in common with Jira!

Mapping to Jira

Features can either be an Epic or a Story in our Jira, depending on what makes more sense. As soon as a corresponding Jira issue to a Feature exists, the full URL to the Jira issue must be stored in the "Jira Issue" custom field.

Naming

As short and concise as possible, over 55 characters makes it hard to read, depending on the view

We have no defined format, use what works best at the time when writing the feature. Examples:

Finish the sentence "I need to …​" from a user’s perspective

"verb object clarifier" (For example "Install an OpenShift 4 cluster on cloudscale.ch")

Choose the name that best represents your current understanding of the need and that will make it easy to find the feature when you search for it later.

Feature names can change over time as the underlying needs are understood better.

136.3. Roadmaps

Name
Content

All Products Timeline

All VSHN products in a high-level timeline, giving an idea when a feature is being worked on.

APPUiO Managed Timeline

Specific view for the APPUiO Managed and APPUiO Cloud products with a more detailed timeline to see when features are being worked on.

AppCat Timeline

Specific view for the Application Catalog product with a more detailed timeline to see when features are being worked on.

136.4. Working with Productboard

Insights Processing

Product Management regularly assesses the open "Unassigned" Insights and assigns them to the Product Owners. If an Insight is already clear enough, it could also directly be processed. Otherwise the Product Owner then processses these Insights:

If no priority given, default to 1

Do a refinement if needed

Mark as processed if everything is done (for example assigned to a feature)

Insights which won’t be transferred into a feature get a comment on why and are marked as processed. Such insights will stay in the "All notes" folder and can still be found via the search feature.

Insights which aren’t clear can be discussed in the recurring Products WG meeting.

Update Productboard Portal

Update the Productboard Portal:

Check all tabs for cards to be updated and update them accordingly

Compose an update to listed cards if needed

136.5. Power Users and Admins

Product Management and Product owner have the "Maker" role.

VSHNeers having one of the following roles at VSHN will get a "Contributor" role account:

Business Development

Service Manager

Customer Success Manager

Solution Architect

⁸ The user impact score is an auto-calculated score that can help you surface your top-requested feature ideas. It represents the number of people who’ve requested a feature (or expressed a need that would be solved by it), weighted by how important it is to them.

137. Product Maturity

To help us to understand how mature a product of ours is, we define several aspects of documentation a successful product needs to have. Each product is assessed against these definitions like a checklist.

We keep the assessment internal, it’s available in our Wiki under Product Maturity Assessment.

137.1. Basics

Product Vision

We have a well-defined vision for the product in our company handbook. It must describe the idea and where we want to go with this product.

Implementation

The product is actually implemented and can be used by customers and VSHNeers:

A well-defined value stream team takes care of it

A product owner is assigned

Technical documentation is available

137.2. Business and Growth

Existing Customers

The product has existing customers actively using it any are paying for the usage.

Pricing Model and Automated Billing

A price model is described in our product documentation. Internal documentation is available, describing for example how discounting works or how the cost structure looks like. Billing is fully automated for the product, according to its pricing model.

Investment Budget

We have an investment budget defined for the further progress of the product.

Business Plan

A business plan is available for the product, discussing the following points:

Market demand

Goals

ROI

Cost/Revenue Transparency

We have full transparency over the costs for running and developing the product, and we know about the exact revenue of it. Reporting is fully automated, no manual process is involved to get the transparency.

Sales Material

Sales materials are available, which help a salesperson qualify potential customers for the product.

137.3. Marketing

Customer Journey

The customer journey is worked out, properly documented and kept up-to-date.

Personas

The personas for the product are properly defined and documented, including a "Pains and Gains" analysis which is kept up-to-date.

Sales Website

A sales website is available which describes the product matching the target personas.

Detailed Product Description

The detailed product description is available in our product documentation website.

Advertisement

Advertisement is being made for the product, for example Ads on various places or by attending conferences and talking about it.

Analytics

Analytics for the product website and customer journey materials to continuously analyze where visitors are finding our product, what steps/materials in the customer journey they consume, and to iterate our marketing based on this information.

138. Understand and Assign Drivers

People in an organization are the sensors (and actors) of the organization. When people feel or see something that isn’t how they expect or prefer it to be, we call this Tension.

Tensions show challenges (a.k.a. problems) and opportunities for an organization when people reveal the reason why they experience it.

In Sociocracy 3.0 we call this pattern Navigate via Tension.

Viktor Frankl, an Austrian neurologist and psychologist said, “Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.”

We humans usually tend to think about solutions and act directly when we see something we think should be changed. By doing so, we often try to solve the wrong problem and miss opportunities to look at other possible solutions first.

This is based on Sociocracy 3.0 Patterns we adapted. Use them where ever they might help you. VSHN Improvement Proposals (VIPs) can help you through this.

138.1. Noticing Tension

We try to consciously identify Tensions so that we can better understand them later, rather than reacting to them directly. So should you feel that something isn’t how it should be or how you prefer it to be, start talking about it with someone.

Questions to ask yourself

In which situation do I experience it?

Who else is involved?

What could cause it?

How do I think it should be?

Formats to show Tensions

Write down and then talk about it:

with a colleague.

in the team.

in an Interest Group where the topic could fit.

Start a discussion forum topic.

All of the above helps you reflect and understand what you are experiencing and what you could do about it. It doesn’t mean others solve it for you.

Formats to track Tensions

There are ways to capture tension so that it doesn’t get lost:

Add it to the Agenda of your Team’s next (governance) meeting.

Create a VIP even if you don’t have a driver yet - start by formulating your Tension.

Avoid chat messages for this. Chat messages fade away after a short time risking your valuable input getting lost.

138.2. Understanding Drivers

To better understand where Tension comes from, we try to formulate it as a Driver - also known as the Why. The power of the Driver is to understand What we need and Why without thinking about the How, leaving it open for later to find possible solutions by having everyone on the same page. You could also say Always start with the Why.

Drivers are written as a brief summary as explained in the poster above.

Drivers precede the How, don’t write about the How in a Driver summary.

Formats to understand Drivers

Find people that might feel or see the same or similar Tension or you know might have an opinion on the topic to do one of the following:

Organize a workshop with interested people or those who have strong opinions or knowledge. Gather as much information as possible.

Start a discussion forum thread to gather more information around the topic and see how others feel or see it and to find out who could help you in this step.

Either way, you should dig into the following questions together:

what’s the current situation that surrounds this topic in our organization?

What are the (negative) effects of this situation on the organization?

What do we need to change or improve the situation?

What would be the (positive) impact when we attend to that need?

With all this information you can start to isolate one or more concrete Drivers.

It’s not uncommon that when trying to understand or find the Driver behind a Tension to find out that it’s actually multiple Drivers. This is a good thing.

138.3. Is it an Organizational Driver?

Tensions can reveal valid drivers that nevertheless don’t help the organization if we respond to them, nor lead to unintended consequences if we don’t. Such drivers should usually be dropped.

Formats to qualify Drivers

Write in the Chat "Any potential objection against this being an organizational driver?" in the circle you think is accountable.

Present the driver and decide in the next Governance Meeting of the accountable circle.

138.4. Is it in our Domain?

It’s important that we assign a Driver to the Circle that’s responsible for the Domain that this Driver falls into. If we aren’t the Circle accountable for that Domain, we assign (step 5 in the "Navigate via Tension" image above) it to the Circle we think is responsible.

The other Circle will check this again and may reassign the Driver to another Circle. This can delay things but is still better than one Circle proceeding and then not being able to make any decisions because they aren’t responsible.

This step usually happens in the same formats as Is it an Organizational Driver?

138.5. Respond

The accountable Circle consents to respond in a certain way, by either coordinating an Operations action or agreeing that this needs a Governance decision.

More on this in Respond to Organizational Drivers.

138.6. Links

Describe Organizational Drivers

139. Respond to Organizational Drivers

For every organizational Driver we’ve to decide how we respond to it. It doesn’t always mean that we need to start creating proposals for governance decision making.

Governance

Is the act of setting goals, and making and evolving decisions on policies, processes and definitions that influence how we act and behave in the future.

Operations

Is where the actual work happens and how teams or individual VSHNeers organize their day to day activity. This usually means that there is already a previous decision like a domain description or an agreement that allows us to just act - we don’t need another decision.

This is based on Sociocracy 3.0 Patterns we adapted. Use them where ever they might help you. VSHN Improvement Proposals (VIPs) can help you through this.

139.1. Formats to do this

In a Governance Meeting present the Driver and go though the steps from the poster above.

Ask in the chat channel of the accountable circle "Do you see a potential objection if we just do this and this here?" if you feel that this can simply be done (Operations).

This often becomes quite clear by the time we understood and assigned the Driver. However, it doesn’t hurt to check if there are any objections to the way of responding you have chosen.

139.2. Links

Sociocracy 3.0 - Governance and Operations

140. Create Proposals

When we decide to respond to an Organizational Driver by doing Governance , it’s time to start forming a proposal.

Creating Proposals involves more than just starting to write about a potential solution. The goal is to tap into collective intelligence, build a sense of ownership, and increase engagement and accountability by involving stakeholders and people who have experience with or strong opinions about the topic. Or in other words, if your opinion and ideas were considered when the proposal was created, it’s much easier to give your consent during Decision Making on the proposal afterwards.

140.1. Co-Create Proposals

Bring people together to collaboratively create proposals. There are many ways to do this, they typically follow a similar pattern though:

Agree on the driver

It’s important that we understand the Driver, as we tend to think about solutions before we actually understand the problem we want to solve. Make sure that the driver is clear to everyone in the group and consent that we’re accountable to handle it. This usually happened already in Understand and assign Drivers.

Who: In the circle accountable for the driver, usually in a Governance Meeting or the Chat channel of the circle.

Explore the topic and understand constraints

Prepare information gathering questions like Do we’ve a budget? Who is affected? and What do we already have? to learn about constraints.

Prepare generative questions to see what possibilities we’ve to address the driver, like What’s the simplest thing we could do?

Answer these questions, for example in:

Online surveys sent to all affected and interested people

Brainstorming sessions

a discussion forum thread (or multiple when it’s a bigger topic)

Who: A smaller group might prepare the questions, surveys, etc. The accountable circle should consent to this, before proceeding. Usually coordinated in a Governance Meeting or the Chat channel of the circle.

Generate ideas

Come up with ideas that offer a full solution to the driver.

Prioritize and merge ideas. It’s not either or, it’s both an more.

Who: Same as above

Design a proposal

Taking the ideas we had so far and combining them into one proposal.

Who: Often done by a smaller group, which is selected by the accountable circle. We call this group Tuners

140.2. In more detail

One way to co-create proposals is to use S3’s Proposal Forming pattern.

140.3. Links

The Role of Tuners in Proposal Forming

Missing opportunities through shortcuts in Proposal Forming

141. Governance meeting

Work Groups, Teams or Interest Groups, usually meet at regular intervals. The purpose of the meeting is to decide on the next steps required to achieve objectives. It’s also used to talk about drivers and coordinate the work required to address them. And finally, it can also serve to set constraints on how and when things should be done.

A Governance meeting is about making Governance, which includes:

consenting to Drivers

choosing how we respond to an organizational Driver

doing Consent Decision Making on a prepared Proposal

choosing the the Tuners that design a Proposal

The main part of the meeting should be organized around prepared Drivers on the Agenda. A governance meeting is usually facilitated, prepared in advance, timeboxed and scheduled every 1—4 weeks.

VIPs can help, to automatically include the Drivers in the Meeting Agenda and show their progress of each VIP, making it easy to know, what we’ve to do next.

141.1. Preparation

Making decisions in a meeting is often more effective and easier, as people can talk in real time. However, it proved to be good practice to:

ensure that all Drivers, that will be discussed in the meeting are already understood and assigned to the responsible circle before the meeting.

allow the participants to read all drivers and proposals before the meeting in order to prepare.

141.2. Tips for the Meeting

Focus on

who could invest time to understand a Driver
and postpone discussing and making decisions on unclear drivers.

deciding on the next step or S3 pattern that we can apply to bring a driver forward.

Avoid

questions like "Do you agree?" and replace them with "Do you see any possible objection?"

open discussions on Concerns and instead make sure we evaluate it during reviews.

141.3. Links

Governance Meeting

142. Decision-Making at VSHN

A team has a lot of different work - customer support, incident handling, proactive product development tasks, and more. Given the sheer volume, they need to prioritize and organize who does what. The Product Owner prepares the backlog (Proposal), what to include in the sprint (an act of Leadership). Unless there is a reason why starting the sprint as proposed is a risk, the team commits and begins (Consent Decision in Operations). Everyone is now working on tasks (Operations).

During the sprint, a major incident occurs. In the next standup meeting, the engineer working on it asks for assistance. Another engineer volunteers to help but points out that doing so will prevent the completion of two sprint tasks (another act of Leadership). The team deems fixing the incident as a higher priority, and in the absence of reasons against it, two engineers are assigned to address the incident (again Consent Decision in Operations).

Over the next four sprints, the team consistently struggles to collaborate with another team due to differing Jira issue types. They agree that this issue is a significant hindrance (Consent to Driver). One team member suggests adopting the same issue types as the other team uses. With no objections raised, they proceed to make the change (Consent Decision in Governance).

~ A little story that summarizes everything outlined on this page.

Decisions at VSHN are made in both our operational and governance contexts. In both scenarios, we try to follow the principles of Sociocracy 3.0 to make decisions collectively involving the people that would be affected by the decision (Equivalence) and based on reasoned arguments (Consent). We understand what is needed, propose a next step or a solution and if there are no reasons why it would hurt us, why we couldn’t at least try it, we move forward with it.

142.1. Introduction

Decisions are powered by reason and involve affected people, not rank or position.

At VSHN, we embrace non-hierarchical principles for Decision Making and leadership. The power to influence decisions lies with reasoned arguments and not with people in specific roles or ranks, and we involve the people responsible and those affected by the decision. It’s crucial that decisions are made, and therefore equally crucial that someone takes the initiative to drive them; otherwise, they simply won’t occur. These principles apply at all levels within the organization, including our "Management Team".

142.2. Operations vs. Governance

At VSHN, we differentiate between Operations and Governance. This distinction, while a key concept in Sociocracy, isn’t exclusive to it. In any organization, team, or even for individuals, there’s a need to perform work (Operations) and to define the environment, our goals, rules, processes, etc. (Governance).

Example

Planning and prioritizing your work, and doing the actual tasks you planned, is Operations. But determining how you plan your work, for example whether we do Scrum or plain Kanban, or setting customer communication guidelines that we want to stick to, that would be Governance.

Operations

Operations relate to doing the work and the organization of day-to-day activities within the constraints defined by governance. This is what most of us engage in on a daily basis - the actual work you do, such as programming, calls with customers, resolving incidents, doing backoffice admin work, you name it. It also includes organizing and planning your work.

Although "Operations" is a common term in tech teams referring to unplanned tasks like incident responses and customer requests, in this context, Operations includes both planned and unplanned day-to-day activities.

Coordination

Coordinating and planning work is also within Operations and not Governance, as refining tasks and prioritizing them are one-time decisions.

Tracking Operations

In theory, you could keep all the work you have to do in your mind, remembering what to do and by when. In practice, this only scales to a certain point. Also, because you share the responsibility to get the necessary work done with your other team members, it’s important to write down, visualize, and track progress on work items. The most common way is through task lists, Jira issues, etc. Larger chunks of work are planned in Epics, Projects, etc. - Kanban is usually a great visualization to make work (Operations) visible.

Governance

Governance, on the other hand, involves the process of setting objectives and making and evolving decisions that guide how you do your work. This includes making and evolving policies and procedures about how we work together, distributing responsibilities and power, selecting people for roles and teams, accounting for dependencies between teams, distributing resources, developing strategy, setting priorities and objectives, and making all consequential decisions about products, services, tools, technology, security, and more.

Who does Governance?

Governance is not exclusive to a board or managers. It happens at all levels within the organization. Everyone who makes or contributes to governance decisions is a part of this process, often even unknowingly. We encourage everyone to participate in governance decisions, whether in dedicated governance meetings, on the fly during the working day, or in one-off meetings dealing with a specific topic. For transparency and future reference, we document our decisions.

Teams at VSHN are self-governing, meaning the whole team shares the responsibility to make and evolve agreements which govern how the people doing the work in their domain create value.

Defining the team’s domain - their purpose, responsibilities, products, etc. - is also part of Governance. This is done collaboratively by the Delegator and the Delegatees (the Team). This is also what ensures that the Delegator remains overall accountable for what is delegated to the Team - if they don’t deliver, they are stuck addressing issues or other issues, the Delegator needs to work this out together with the team, but doesn’t do it for them.

Tracking Governance

In theory, you could do this off the top of your head, understand the need to change a policy, propose something verbally, and ask people if they see any potential objections. If not, move forward and implement what you proposed. In practice, like with Operational work, this doesn’t scale, and it’s very difficult to reach a common understanding of what the problem might be and what your proposal implies.

For larger topics (drivers), we have an implementation in Jira - the VSHN Improvement Proposals. This is essentially a way to track the status of a governance item from understanding the problem, identifying who is responsible, finding a solution, making the decision, and reviewing the implementation and effectiveness of the decision.

It’s okay to make smaller decisions directly in meeting agendas, for example. Be aware, however, that we still document and proactively inform the people affected by the decision, and that we still need to follow up later to see if what we decided is effective.

VSHN Improvement Proposals, aka VIPs, are not Governance, they’re a way to track Governance. Governance needs to happen whether we use VIPs, something else, or nothing to track our Governance decisions. Compare tracking your normal work in Jira. Whether you use Jira or not, the work is still there, needs to be prioritized, worked on, and done.

142.3. Consent Decision-Making

The following provides an overview of key elements in making decisions based on the principle of Consent. This is a very big topic, while we encourage you to try based on what you learn here, we acknowledge that it requires quite some education, training, and experience to facilitate this in group meetings or semi-asynchronously. Our goal is to have enough Facilitators who can assist you and facilitate for you where useful. Still, to participate, a common understanding of the following elements is crucial.

Consent

Giving Consent to something or consenting means the absence of Objections. It’s not to be confused with Consensus, which would mean that everyone has to agree.

Implicit Contract of Consent:

In the absence of objections to an agreement, I intend to follow through on the agreement to the best of my ability.
I agree to share objections as I become aware of them.

Objection

An Objection is an argument relating to a (proposed) agreement or activity that reveals unintended consequences we’d rather avoid, or that demonstrates worthwhile ways to improve right now.

In turn, having no Objection means:

Despite my best effort I can see no reason why the proposed agreement would harm our organization.

I see no way to significantly improve the proposal on the spot.

I don’t think the proposed agreement conflicts with an existing agreement.

I think this proposal is *good enough for now and safe enough to try*.

You can’t have an objection - you might have a possible objection, when you dig into it together you find out what is behind your argument and whether it reveals risk or ways to improve the proposal. If that is the case, it’s an objection and we need to somehow change the proposal to integrate what we learned.

Proposal

At VSHN, you’ll often hear that we follow a proposal until there are reasons not to (an Objection). But where do Proposals come from?

First, you agree on the driver - the problem or opportunity you want to address - and then you research the issue to learn more about the details and understand all the important considerations and constraints before moving on to brainstorming ideas and finally using all the information you’ve gathered to draft a proposal.

Driver

Always start with the Why.

A Driver is a simple but powerful concept. It’s about understanding what is needed, collaboratively, to have a common understanding of what the problem or opportunity is, that you need to address. After that, we can start finding solutions and create a Proposal.

The tricky thing here is, that we as humans are often taught to think in solutions, but actually, the power to do the right thing lies between understanding what’s needed and then finding out what to do - Move out of autopilot. This is especially important, as other people might have a completely different understanding of what is needed.

If we skip understanding the Driver (the Why), it’s likely that we get stuck in "Moving forward with a proposal until there is a reason not to" (Consent), because people will question what we need to do and why in the first place.

142.4. Leadership

Leadership at VSHN plays a crucial role in facilitating decision-making processes and ensuring that decisions are followed up on. Leaders are not just those in traditional hierarchical roles - every individual is empowered to lead within their area of responsibility. It’s easy to say "No one takes the needed decisions" - what is likely the case is that it’s more an issue of missing leadership and not flawed Decision Making - Ensure that we see the need, insist that we come up with a proposal and that we decide together.

See The big risk in VSHN’s culture for an overview of this topic.

143. Resolve Objections

We encourage everyone to raise Objections against existing agreements and activity any time. Handling such objections isn’t always an easy tasks though.

143.1. Qualify Objections

Not all arguments raised are Objections. It usually helps to ask again "why do you think isn’t good enough for now or safe enough to try, until the next review"? When doing so, this usually reveals a valuable Concern we can document for a future review of the agreement.

143.2. Objections to proposed Agreements

During Consent Decision Making Objections prevent a Proposal from becoming an Agreement. Objections should be seen as a gift to make proposals better and not as way to block or prevent something - we amend the proposal to make it better and resolve the Objection. In rare cases it can also mean to go back and try to understand or assign the driver differently.

143.3. Objections to existing Agreements or Activities

If it’s clear which agreement or what Domain this activity falls into you can do one of the following:

Talk in the next Governance Meeting of the accountable circle about this or add it to their agenda

Create a VIP to record your Tension and assign it to the accountable circle.

Talk to someone who knows the agreement or the domain on what to do.

In most cases, this should be a trigger to do a Review of the agreement or domain in question.

If it’s not clear it’s most likely not an Objection but a new Tension see Understand and Assign Drivers.

143.4. Formats to resolve Objections

There is actually only one Format we found effective in most cases: Meet and discuss with the Objector, Tuners and other people who where involved in creating the Proposal:

You can come up directly with an amendment to the proposal that everyone in this group can consent to.

Chances are then very high that the accountable circle will also consent to this amendment later.

This usually can happen directly in the Governance Meeting where you’re making the decision.

Avoid written, asynchronous discussions when trying to resolve Objections. This proved to be very ineffective and often leads to even more misunderstandings. Collecting Objections asynchronously in a written way can make sense, discussing them like that doesn’t.

143.5. Links

Resolve objections

Test Arguments Qualify as Objections

144. Evaluate and evolve everything

In a learning and dynamic organization, it’s important to simply start doing things, once we have a good enough for now, safe enough to try solution to a Driver. We do this until the next review. Regular reviews of agreements, domains and behavior is an essential practice to evolve our organization.

This helps us to

Adapt agreements to suit changing context.

Stop doing things which are a waste (don’t help us).

Integrate learnings to make agreements more effective.

We therefore ensure all agreements have an appropriate review date.

This is the main reason we should track as many agreements and domains as possible as VIPs - VIPs have a due-date for agreements and agreements will pop-up in the accountable circle on that day, so that we don’t forget to start the review.

Evaluating agreements can be as simple as checking that an agreement is still relevant, and there is no objection to keeping it as it’s. Usually done in Governance Meetings or dedicated meetings to review a specific agreement or domain.

144.1. Examples

Meetings

Most organizations have a lot of (recurring) meetings. We should always be clear about the Driver (the Why) of a meeting, even when the Driver isn’t written down. Do short Meeting Evaluations at the end of meetings, from time to time.

If the Driver is no longer relevant consider dropping the meeting.

If the meeting doesn’t have the intended effect, change the meeting (agenda, participants, length, moderation, etc.)

Domains

Are we really doing what’s written in our Domain description? Check actual progress, behavior and success by looking at the Evaluation criteria in the Domain description. Add new evaluation criteria through every review, to make it easier to review it again and again.

Agreements

Are we actually doing what we agreed to and does this have the intended effect in regards to the Driver behind the Agreement? Did we actually solve or address the problem or opportunity described in the driver?

144.2. Links

Evaluate Meetings

Evaluation Criteria

145. Definition of Cloud Native

The Cloud Native Computing Foundation defines Cloud Native as follows:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

~ Cloud Native Computing Foundation (CNCF) CNCF Cloud Native Definition v1.0

Source

146. Definition of Cloud Infrastructure

On-demand self-service

A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Broad network access

Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

Resource pooling

The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.

Rapid elasticity

Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.

Measured service

Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

~ National Institute of Standards and Technology (NIST) SP 800-145 - The NIST Definition of Cloud Computing

Source

147. Definition of Managed Service

Under "Managed Service" we understand:

Together with the customer, we collaborate on the application hosting architecture

We automate the infrastructure and software delivery lifecycle

We are aware that the application is running fine

Should something go wrong, we fix it ourselves or escalate it to an appropriate supporting organization (cloud service provider, customer, developer, etc.)

We provide "standard" services: Monitoring, Backup, Metrics, Logs, Maintenance, 24/7 Incident Response and Support (Helpdesk), Consulting of customers when they need additional know-how

We work together with partners to provide deep expertise for things we don’t know

148. VSHN Improvement Proposals

We need a way to capture and track organizational drivers. This way, we can ensure that everyone can see how we’ve responded to organizational drivers, what agreements we’ve made, and when and how we’ve reviewed the agreements. We also need an easy way to make drivers visible at any stage to the current accountable circle.

Don’t know what Organizational Drivers are? Start by reading How we evolve our organization.

148.1. Overview

The VSHN Improvement Proposals - in short VIPs - are a way to capture and record Organizational Drivers. It can be seen as our main Governance Backlog.

See Respond to Organizational Drivers to learn more about the difference between Governance and Operations.

VIPs are implemented as VSHN Improvement Proposal in Jira.

Statuses of VIPs

Understand and Assign

Someone noticed Tension and wrote a (provisionally formulated) Driver. The Circle has to:

Consent to the Driver (formulation).

Consent that it’s as an organizational Driver, otherwise Drop it.

Consent that it’s within their Domain (are responsible), otherwise assign it to another Circle.

See Understanding and assigning Drivers.

Respond

We’ve an Organizational Driver which is within our domain (we’re responsible). It’s yet unclear how we respond to it. Possible options are:

Decide that this is Operations and doesn’t need a Governance decision.

Decide that it’s Governance.

See Respond to Organizational Drivers.

Proposal Forming

We’ve an Organizational Driver that we want to address with a Proposal. Usually the following might happen in this phase:

Through discussions, surveys, etc. we find constraints, considerations and ideas for a Proposal.

We choose 2—3 Tuners that will use the gathered information to Design a Proposal

See Create Proposals.

Decision Making

We’ve a Proposal that offers a solution to the Organizational Driver. The accountable circle:

consents to the Driver (if not already done perviously).

asks clarifying questions.

raises potential Objection.

resolves Objections with the help of the Tuners to amend the Proposal as needed to improve it.

If there are no unresolved Objections in the sense of good enough for now, safe enough to try, we made the decision.

See Consent Decision Making.

Agreement

The Proposal is now an agreement, let’s celebrate that! The accountable circle:

sets a due-date for the next review of the agreement.

can plan follow-up actions to implement this proposal.

makes sure that the agreement is documented (for example in the handbook).

Review

On the due-date of the VIP or when we see the need (tension based), the accountable circle:

Reviews the Driver - Is it still relevant?

Review the effect of the Agreement - does it still address the driver and does it have the intended effect?

Consents to either:

Keep the Agreement

Evolve it

Drop it

See Evaluate and Evolve.

148.2. Implementation

Jira is how we track VIPs - The Driver and the Proposal is on a Wiki page or in a Merge Request. The VIP itself is created in Jira - the resulting unique VIP number is used everywhere else.

You find the VIPs here in Jira:

Project: VSHN Improvement Proposals (VIP)

Issuetype: VSHN Improvement Proposal

VIPs can be anywhere in the Wiki as long as the wiki page and Jira issue are linked in both directions. There are some common places for the VIPs though, for example:

Management Work Group

Products Work Group

Wiki Pages, with the page name following the schema VIP-X - <name of driver = Jira summary> contain:

The Driver summary formulation

The Wiki page might contain information to help understanding the driver

Questions, Concern and Objections documentation

Proposal is (one of) linked:

On the same Wiki page

GitLab Merge Requests (usually the VSHN handbook), include VIP-X in the title of the MR

The driver formulation can be in Jira, until we go into Proposal Forming.

Merge Requests

If you don’t need a wiki page, you can simply use a merge request in GitLab as long as you link the MR and Jira issues in both directions.

Documenting Concerns

When we resolve objections during decision making we should document concern on the Wiki pages or in the merge requests. Concern can be considered when we review VIPs to Evaluate and Evolve.

Objection handling

The Wiki page templates has a section Objection handling with a table where we document each potential objection and the steps taken to resolve it. In Merge Requests this happens as threads with comments.

We should handle Objections in Governance or other meetings and not start discussions on a wiki page. Documenting the findings here is very welcome though.

Inter-Linking of VIPs

VIPs can:

relate to each other (relates to in Jira) - use sparingly where it helps to understand the context.

address a parent driver (address driver in Jira) or have sub-drivers (has sub driver in Jira) - mandatory

Making Proposals and Change visible

We want to make everything we’re working on visible to everyone so that everyone knows what’s around to read, comment, object or help with. As VIPs are normal issues in Jira, we can easily filter, sort and show the VIPs on boards in Jira and Confluence.

This allows us to have an automated overview to:

Show in Weekly Company Meetings

Base a "Weekly OrgDev newsletter" on it or similar.

Sync with external Coaching about what’s currently going on

148.3. Out of Scope

VIPs are for organizational topics (the Governance Backlog) and aren’t:

about tracking operational issues which clearly fall within an existing Domain's core tasks.

"Tickets" on which you actually work to implement something. Implementation is always done in follow-up tasks.

This process is tracked and reviewed as VIP-1

149. How to create VSHN Improvement Proposals

A VSHN Improvement Proposal (VIP) is created by creating a Jira issue in the project VSHN Improvement Proposals.

You might want to read Understand and Assign Drivers before you start creating VIPs.

Create a new VIP in Jira

Write a Summary - the title of the VIP.

Set the Accountable Circle. They will further handle this VIP or assign it to another circle, should they not be accountable.

This is an LDAP Group search, Teams and Work Groups are named VSHN <circlename> here, for example VSHN Sol

Write a Driver in the description field. The format is explained here.

Later you might use the VIP number from Jira to create either a Wiki page or a Handbook Merge Request with the title: VIP-XX - Summary

This How-to is tracked and reviewed as part of VIP-1

150. Decision-Making at VSHN

A team has a lot of different work - customer support, incident handling, proactive product development tasks, and more. Given the sheer volume, they need to prioritize and organize who does what. The Product Owner prepares the backlog (Proposal), what to include in the sprint (an act of Leadership). Unless there is a reason why starting the sprint as proposed is a risk, the team commits and begins (Consent Decision in Operations). Everyone is now working on tasks (Operations).

During the sprint, a major incident occurs. In the next standup meeting, the engineer working on it asks for assistance. Another engineer volunteers to help but points out that doing so will prevent the completion of two sprint tasks (another act of Leadership). The team deems fixing the incident as a higher priority, and in the absence of reasons against it, two engineers are assigned to address the incident (again Consent Decision in Operations).

Over the next four sprints, the team consistently struggles to collaborate with another team due to differing Jira issue types. They agree that this issue is a significant hindrance (Consent to Driver). One team member suggests adopting the same issue types as the other team uses. With no objections raised, they proceed to make the change (Consent Decision in Governance).

~ A little story that summarizes everything outlined on this page.

Decisions at VSHN are made in both our operational and governance contexts. In both scenarios, we try to follow the principles of Sociocracy 3.0 to make decisions collectively involving the people that would be affected by the decision (Equivalence) and based on reasoned arguments (Consent). We understand what is needed, propose a next step or a solution and if there are no reasons why it would hurt us, why we couldn’t at least try it, we move forward with it.

150.1. Introduction

Decisions are powered by reason and involve affected people, not rank or position.

At VSHN, we embrace non-hierarchical principles for Decision Making and leadership. The power to influence decisions lies with reasoned arguments and not with people in specific roles or ranks, and we involve the people responsible and those affected by the decision. It’s crucial that decisions are made, and therefore equally crucial that someone takes the initiative to drive them; otherwise, they simply won’t occur. These principles apply at all levels within the organization, including our "Management Team".

150.2. Operations vs. Governance

At VSHN, we differentiate between Operations and Governance. This distinction, while a key concept in Sociocracy, isn’t exclusive to it. In any organization, team, or even for individuals, there’s a need to perform work (Operations) and to define the environment, our goals, rules, processes, etc. (Governance).

Example

Planning and prioritizing your work, and doing the actual tasks you planned, is Operations. But determining how you plan your work, for example whether we do Scrum or plain Kanban, or setting customer communication guidelines that we want to stick to, that would be Governance.

Operations

Operations relate to doing the work and the organization of day-to-day activities within the constraints defined by governance. This is what most of us engage in on a daily basis - the actual work you do, such as programming, calls with customers, resolving incidents, doing backoffice admin work, you name it. It also includes organizing and planning your work.

Although "Operations" is a common term in tech teams referring to unplanned tasks like incident responses and customer requests, in this context, Operations includes both planned and unplanned day-to-day activities.

Coordination

Coordinating and planning work is also within Operations and not Governance, as refining tasks and prioritizing them are one-time decisions.

Tracking Operations

In theory, you could keep all the work you have to do in your mind, remembering what to do and by when. In practice, this only scales to a certain point. Also, because you share the responsibility to get the necessary work done with your other team members, it’s important to write down, visualize, and track progress on work items. The most common way is through task lists, Jira issues, etc. Larger chunks of work are planned in Epics, Projects, etc. - Kanban is usually a great visualization to make work (Operations) visible.

Governance

Governance, on the other hand, involves the process of setting objectives and making and evolving decisions that guide how you do your work. This includes making and evolving policies and procedures about how we work together, distributing responsibilities and power, selecting people for roles and teams, accounting for dependencies between teams, distributing resources, developing strategy, setting priorities and objectives, and making all consequential decisions about products, services, tools, technology, security, and more.

Who does Governance?

Governance is not exclusive to a board or managers. It happens at all levels within the organization. Everyone who makes or contributes to governance decisions is a part of this process, often even unknowingly. We encourage everyone to participate in governance decisions, whether in dedicated governance meetings, on the fly during the working day, or in one-off meetings dealing with a specific topic. For transparency and future reference, we document our decisions.

Teams at VSHN are self-governing, meaning the whole team shares the responsibility to make and evolve agreements which govern how the people doing the work in their domain create value.

Defining the team’s domain - their purpose, responsibilities, products, etc. - is also part of Governance. This is done collaboratively by the Delegator and the Delegatees (the Team). This is also what ensures that the Delegator remains overall accountable for what is delegated to the Team - if they don’t deliver, they are stuck addressing issues or other issues, the Delegator needs to work this out together with the team, but doesn’t do it for them.

Tracking Governance

In theory, you could do this off the top of your head, understand the need to change a policy, propose something verbally, and ask people if they see any potential objections. If not, move forward and implement what you proposed. In practice, like with Operational work, this doesn’t scale, and it’s very difficult to reach a common understanding of what the problem might be and what your proposal implies.

For larger topics (drivers), we have an implementation in Jira - the VSHN Improvement Proposals. This is essentially a way to track the status of a governance item from understanding the problem, identifying who is responsible, finding a solution, making the decision, and reviewing the implementation and effectiveness of the decision.

It’s okay to make smaller decisions directly in meeting agendas, for example. Be aware, however, that we still document and proactively inform the people affected by the decision, and that we still need to follow up later to see if what we decided is effective.

VSHN Improvement Proposals, aka VIPs, are not Governance, they’re a way to track Governance. Governance needs to happen whether we use VIPs, something else, or nothing to track our Governance decisions. Compare tracking your normal work in Jira. Whether you use Jira or not, the work is still there, needs to be prioritized, worked on, and done.

150.3. Consent Decision-Making

The following provides an overview of key elements in making decisions based on the principle of Consent. This is a very big topic, while we encourage you to try based on what you learn here, we acknowledge that it requires quite some education, training, and experience to facilitate this in group meetings or semi-asynchronously. Our goal is to have enough Facilitators who can assist you and facilitate for you where useful. Still, to participate, a common understanding of the following elements is crucial.

Consent

Giving Consent to something or consenting means the absence of Objections. It’s not to be confused with Consensus, which would mean that everyone has to agree.

Implicit Contract of Consent:

In the absence of objections to an agreement, I intend to follow through on the agreement to the best of my ability.
I agree to share objections as I become aware of them.

Objection

An Objection is an argument relating to a (proposed) agreement or activity that reveals unintended consequences we’d rather avoid, or that demonstrates worthwhile ways to improve right now.

In turn, having no Objection means:

Despite my best effort I can see no reason why the proposed agreement would harm our organization.

I see no way to significantly improve the proposal on the spot.

I don’t think the proposed agreement conflicts with an existing agreement.

I think this proposal is *good enough for now and safe enough to try*.

You can’t have an objection - you might have a possible objection, when you dig into it together you find out what is behind your argument and whether it reveals risk or ways to improve the proposal. If that is the case, it’s an objection and we need to somehow change the proposal to integrate what we learned.

Proposal

At VSHN, you’ll often hear that we follow a proposal until there are reasons not to (an Objection). But where do Proposals come from?

First, you agree on the driver - the problem or opportunity you want to address - and then you research the issue to learn more about the details and understand all the important considerations and constraints before moving on to brainstorming ideas and finally using all the information you’ve gathered to draft a proposal.

Driver

Always start with the Why.

A Driver is a simple but powerful concept. It’s about understanding what is needed, collaboratively, to have a common understanding of what the problem or opportunity is, that you need to address. After that, we can start finding solutions and create a Proposal.

The tricky thing here is, that we as humans are often taught to think in solutions, but actually, the power to do the right thing lies between understanding what’s needed and then finding out what to do - Move out of autopilot. This is especially important, as other people might have a completely different understanding of what is needed.

If we skip understanding the Driver (the Why), it’s likely that we get stuck in "Moving forward with a proposal until there is a reason not to" (Consent), because people will question what we need to do and why in the first place.

150.4. Leadership

Leadership at VSHN plays a crucial role in facilitating decision-making processes and ensuring that decisions are followed up on. Leaders are not just those in traditional hierarchical roles - every individual is empowered to lead within their area of responsibility. It’s easy to say "No one takes the needed decisions" - what is likely the case is that it’s more an issue of missing leadership and not flawed Decision Making - Ensure that we see the need, insist that we come up with a proposal and that we decide together.

See The big risk in VSHN’s culture for an overview of this topic.

151. Teams at VSHN

This is an overview of all Teams and VSHNeers in VSHN. Besides these Teams, there are also Work Groups for example. You can read more about the different types of teams here.

Name
Members
Accountable for

Nunki

David Gubler (DevOps Engineer)

Gabriel Mainberger (Solution Architect)

Jessica Wyrsch (Scrum Master)

Manuel Hutter (Solution Architect)

Nick Marti (DevOps Engineer)

AppOps and AppFlow (Value Stream)

Schedar

Gabriel Saratura (DevOps Engineer)

Liene Luksika (Product Owner)

Łukasz Widera (DevOps Engineer)

Nicolas Bigler (DevOps Engineer, Scrum Master)

Simon Beck (DevOps Engineer)

Application Catalog (Value Stream)

Vega

Jay Sim (DevOps Engineer)

Sandro Kaspar (DevOps Engineer)

Matthias Indermuehle (Team Facilitator)

Canada Operations (Value Stream)

Aldebaran

Adrian Haas (DevOps Engineer)

Aline Abler (DevOps Engineer)

Christian Häusler (Product Owner)

Elia Ponzio (DevOps Engineer, Scrum Master)

Sebastian Widmer (DevOps Engineer)

Simon Gerber (DevOps Engineer)

Stephan Feurer (DevOps Engineer)

APPUiO Managed OpenShift and APPUiO Cloud

Polaris

Alexander Dehmel (DevOps Engineer)

André Keller (DevOps Engineer)

Ivan Grcic (DevOps Engineer)

Jessica Wyrsch (Scrum Master)

Michel Rios (DevOps Engineer)

Peter Ruegg (DevOps Engineer)

Pierre Rouveyrol (DevOps Engineer)

Managed Server based Services (Value Stream)

Sol

Aarno Aukia (Head of Growth)

Annie Talvasto (Marketing and Public Relations Lead)

Daniel Briner ((Key) Account Manager)

Josh Meyer (Cloud Gotomarket Specialist)

Mia Egger ((Key) Account Manager)

Patrick Mathers (Team Facilitator)

Tobias Brunner (Product Manager)

Virag Josephsen (Inside Sales)

Gabriel Mainberger (Solution Architect)

Manuel Hutter (Solution Architect)

Marketing & Sales

Antares

Dawn Nitsche (People Operations Lead, People Care and Recruiting)

Manuela Banz (Finance lead and Team Facilitator for Antares)

Patrick Mathers (Finance and Chairman of the Board)

Sabrina Lang (People Operations, People Care, and Finance)

Central Services

Avior

Arngard Brülisauer (Customer Support Lead)

Rotating members from Value Stream Teams

Customer Support

Canopus

Daniel Hauswirth (CISO)

Finn Schunk (Corp IT Engineer, Apprentice)

Corporate IT

151.1. Management

Special Case, see Management Work Group

VSHN AG, Switzerland

Markus Speth

Marco Fretz

VSHN Canada - The Devops Company Inc.

Matthias Indermuehle - VSHN Canada

151.2. Board

Patrick Mathers (Chairman of the Board)

Aarno Aukia (Member of the Board)

Till Bay (Member of the Board)

Tobias Brunner (Member of the Board)

152. Work Groups at VSHN

This is an overview of all Work Groups and VSHNeers in VSHN.

Name
Members
Accountable for

Products

Tobias Brunner
Product Manager

Christian Häusler
Product Owner of Aldebaran - APPUiO Managed OpenShift and APPUiO Cloud

Liene Luksika
Product Owner of Schedar - VSHN Application Catalog

André Keller
Product Owner of Polaris - Managed Server based Services

Products

Team Development

Elia Ponzio
Team Facilitator of APPUiO Managed OpenShift & APPUiO Cloud

Alexander Dehmel
Team Facilitator of Managed Server based Services

Marco Fretz
Delegator Representative Business Management

Nicolas Bigler
Team Facilitator of AppCatalog

Team Development

Technology Alignment

Sandro Kaspar
Tech Alignment of APPUiO Managed Kubernetes Services

Simon Gerber
Tech Alignment of APPUiO Managed OpenShift & APPUiO Cloud

Michel Rios
Tech Alignment of Managed Server based Services

Gabriel Saratura
Tech Alignment of AppCatalog

Manuel Hutter
Tech Alignment of AppOps & AppFlow

Daniel Hauswirth
CISO representing Information Securty Domain

Tobias Brunner
Product Management (tech focus)

Technology Alignment

Corporate IT

Daniel Hauswirth

David Gubler

Marco Fretz

Tobias Brunner

Finn Schunk (Apprentice "Betriebsinformatik")

Corporate IT

Operations

Simon Gerber

Michel Rios

Elia Ponzio

24x7 Operations

Information Security Management

Daniel Hauswirth

Patrick Mathers

André Keller

Information Security Management

Recruiting

Dawn Nitsche

Marco Fretz

Markus Speth

Recruiting

COVID

Marco Fretz

Daniel Hauswirth

Information on COVID-19

Compensation

Dawn Nitsche

Peter Ruegg

Manuela Banz

Markus Speth

Compensation

Management

General Managers

Marco Fretz

Markus Speth

Executive Managers

Matthias Indermuehle

Management

153. Management Work Group

The Work Group accountable for the Business Management Domain:

A company must make sure that it fulfills its purpose and makes all the necessary organizational, economical and personnel decisions as well as plans, implements and controls measures and the operational business. The board (“Verwaltungsrat”) can do this themselves or delegate this to others in the company (as defined by Swiss law.)

We want to define this as the Business Management Domain and delegate it to a group of people at VSHN. So that we can ensure the health and growth of VSHN, and Board and Management can control this through reviews together.

The Board of Directors (“Verwaltungsrat”) appoints one or more General Managers ("Geschäftsführer"). The General Managers may appoint other Executive Managers. Together they form a team VSHN simply calls Management, which is the Executive Management ("Geschäftsleitung") of VSHN.

153.1. Members

General Managers

Marco Fretz

Markus Speth

Executive Managers

Matthias Indermuehle

Legal source of truth: VSHN AG (CHE-275.566.226), Commercial register.

153.2. Official Signatures

For a list of VSHNeers who are allowed to sign official documents in the name of VSHN, consult the commercial register.

Always two VSHNeers have to sign ("joint signature at two"), just one signature is invalid.

153.3. C-Level roles

Regarding C-Level roles, see C-Level Roles (External Use).

This team is tracked and reviewed as part of VIP-61

154. VSHN Product Portfolio

This page describes our product portfolio, the rationale behind it, and what benefits each of these products brings to our customers. These products are a consequence of our Key Drivers and Key Deliverables.

Figure 1. The VSHN Product Portfolio Overview

A detailed product description is available under VSHN Products documentation.

154.1. VSHN

Under the VSHN brand, we offer services operated inside already existing Kubernetes clusters; these clusters are usually provided through the APPUiO brand.

VSHN AppFlow

Because applications need to be packaged, tested, and deployed.

Product Vision

To assist software developers bringing code from development to production.

Software developers should be able to focus fully on developing code for their businesses. When deploying code in production is not part of their skillset, our expertise helps developers fulfill this task.

Continuously building and testing applications, properly packaging them into containers, and making them ready for deployment, isn’t easy, and not the domain of our customers' expertise. VSHN helps developers in engineering solid CI/CD pipelines, packaging their applications into properly designed container images, and writing Helm charts to make applications ready for deployment. We believe that fully automated processes are beneficial to our customers.

We can help customers get the best value out of our product offering, increasing customer satisfaction and sales.

More information on products.vshn.ch - VSHN AppFlow.

VSHN AppOps

Because applications need to be taken care of.

Product Vision - Draft

To design and react to actionable alerts so that applications can run smoothly.

AppOps takes care of applications, fulfilling a core task in the DevOps process. Applications deployed with AppOps receive actionable alerts about their behavior and state. It doesn’t matter where they are deployed, and they won’t receive alerts about "false positives." Platform and infrastructure alerts are taken care of by platform products like APPUiO. AppOps ensures that low-level, day-2 operations happen automatically, such as backing up persistent storage, vulnerability scanning, scraping metrics, and more.

Through AppOps, we make sure there is always somebody to take care of applications, making sure they are running in the best conditions, all the time, 24/7.

With AppOps we offer our expertise to design and engineer the best matching cloud hosting environments, and are continuously and proactively making sure applications run smoothly. We react to pre-defined alerts with properly designed runbooks, so that our customers can spend their time developing applications and directly creating value for their customers.

More information on products.vshn.ch - VSHN AppOps.

VSHN AppCat

Because applications need supporting services.

Product Vision

To enable software developers to provision and consume services immediately and reliably.

Developers must be able to provision and consume services directly where and when they need them most. Their flow shouldn’t be blocked by slow and cumbersome manual provisioning procedures. Service provisioning must happen immediately and should be fully automated. With AppCat, VSHN makes it possible by automating every aspect of the service lifecycle: provisioning, providing connection details, billing, backing up, monitoring, maintaining, decommissioning, and more. AppCat complements and extends the value of APPUiO Cloud and APPUiO Managed.

Applications depend on databases, caches, queues, indexes, and other services to work correctly. With AppCat, we offer a variety of such services, available to be ordered in a self-service fashion. In the future, AppCat will offer services from our partners, as well as SaaS software packages, like managed GitLab instances, to support the full software development lifecycle.

By making these services and applications available in self-service, we enable AppCat users to be free from manual intervention.

Services in the application catalog can either be offered by a cloud service provider, or directly by VSHN:

Cloud Services brokering

VSHN resells services from Cloud Service providers in our application catalog. VSHN provides the added value of self-service ordering, billing, and pre-configuration of those services, following our best practices.

Self-Made Managed Services

Services provided by VSHN directly, as Kubernetes operators, instantiated Helm chart, or any other workload running on Kubernetes.

Furthermore, AppCat can be easily extended to offer new services in the future.

More information on products.vshn.ch - VSHN AppCat.

154.2. APPUiO

Because applications need a platform to run on.

Under the APPUiO brand, we offer platform products based on Kubernetes. Those platforms are the foundation of the VSHN-branded products described in the previous section.

APPUiO Cloud

Product Vision

To provide software developers immediate 24/7 access to a hosting environment to run their applications.

Developers should always and immediately have access to a hosting environment to run their applications. APPUiO Cloud provides such an environment with a number of always available shared Red Hat OpenShift clusters. The clusters are fully self-service with self-sign-up. APPUiO Cloud unlocks Red Hat OpenShift and all of its advantages, without having to cope with any of its complexities. No need to care about servers or infrastructure; just interact with the Kubernetes API and deploy your applications.

APPUiO Cloud is based on OpenShift, providing instant and private access to OpenShift Projects, and leveraging its hardened multi-tenancy features.

More information on products.vshn.ch - APPUiO Cloud.

APPUiO Managed OpenShift

Product Vision

To provide dedicated managed OpenShift clusters on any infrastructure.

Red Hat OpenShift is a powerful, off-the-shelf Kubernetes-based PaaS (Platform as a Service) product, available to anyone to install and operate, but featuring a very complex and time-consuming operation needing lots of expertise. We believe that managing OpenShift clusters shouldn’t be the concern of our customers, and should be taken care of by dedicated experts, available round the clock with an SLA.

We choose Red Hat OpenShift to provide managed Kubernetes clusters. By stating that we provide it on any infrastructure, we strive to bring Kubernetes to places where it isn’t available yet.

VSHN runs many OpenShift clusters on different cloud infrastructures on behalf of our customers. Thanks to the quantity and quality of projects we manage, we have a deep knowledge of OpenShift. A knowledge one does not get by just operating one or just a few clusters on one single infrastructure. Armed with that knowledge, we are able to overall provide a better service than our competitors.

More information on products.vshn.ch - APPUiO Managed OpenShift.

APPUiO Managed Kubernetes Services

Product Vision

To take care of all the processes required to have production-ready Cloud Kubernetes environments available, on every available Cloud Kubernetes service provider.

Managed Kubernetes clusters from cloud service providers usually require lots of additional work to be ready for production and to unlock their full potential. We take care of all processes involved to have a production-ready Cloud Kubernetes environment, available within every cloud service provider.

There are many Cloud Kubernetes services available as a managed service control plane, like Amazon’s EKS, Azure AKS, Google GKE, or Exoscale SKS. But choosing between so many market players isn’t easy, given the many different feature sets, and the sometimes missing features needed for proper application hosting.

We enable our customers to use those platforms, without having to care about day-2 operations tasks like provisioning, configuration, Kubernetes lifecycle, monitoring, backup, and others. We augment these offerings with tooling to make the life of developers easier.

More information on products.vshn.ch - APPUiO Managed Kubernetes Services.

154.3. Support Plans

Our customers need support for our services, the support plans make that possible.

We help them to get the most out of our products and services. And when they struggle, they know who to ask, how, and where. Support plans define the details: how and when to reach us, what to expect, how much it costs, etc. Support plans are available to customers consuming recurring VSHN services.

More information on products.vshn.ch - Support Plans.

154.4. Cloud Native Consulting

The landscape of business and technology is continually changing, and as a VSHNeer, you are at the forefront of these shifts. Our primary business, managed services, forms the core of our offerings. Still, our consulting services have an equally critical role to play, both for our customers and for our business’s growth and sustainability.

For our customers, consulting services offer a personalized, expert perspective that enables them to navigate and leverage complex cloud-native technologies more effectively. This guidance is crucial for businesses that might not have the in-house expertise or resources to fully exploit these technologies. By offering consulting services, we’re not just providing a solution; we’re also educating our clients, empowering them to make informed decisions about their operations and strategies.

From a VSHNeer’s perspective, providing consulting services brings several benefits. Here’s how you can profit from this line of work:

Skill Development

Consulting provides an opportunity to broaden your skillset. You’ll encounter diverse client needs, challenges, and infrastructures, which will require you to stay updated with the latest trends and technologies.

Problem-Solving

Each client presents a unique set of problems, providing an exciting challenge and chance to sharpen your problem-solving skills.

Networking

As a consultant, you’ll interact with different clients and industry professionals, broadening your professional network and opening up potential career opportunities.

Job Satisfaction

There’s immense satisfaction in guiding businesses towards their goals, helping them grow, and witnessing the impact of your work.

As for how VSHN profits from these services:

Revenue Diversification

Consulting services provide an additional revenue stream, reducing reliance on our core managed services and making our business more resilient to market fluctuations.

Brand Enhancement

Successful consulting engagements help bolster our reputation as a comprehensive solutions provider, enhancing our brand and making us more attractive to potential clients.

Long-Term Customer Relationships

Consulting gives us a chance to work closely with our clients, understand their needs better, and build deeper relationships. These relationships often translate into long-term contracts and referrals.

Cross-selling Opportunities

Through our consulting engagements, we can identify clients' needs that could be met by our managed services, creating opportunities for cross-selling and upselling.

So, while consulting services may be a 'side business' for us, they play a pivotal role in our growth, sustainability, and reputation. It is a rewarding field that offers personal growth for our engineers and contributes significantly to our company’s bottom line.

While our aim at VSHN is to always accommodate our client’s needs, there are certain situations where we may need to decline a consulting request:

Lack of Expertise

Our primary objective is to deliver high-quality, value-adding services. If a consulting request involves a domain where we do not possess sufficient expertise or confidence to deliver the desired results, it is in the best interest of the client and our reputation that we respectfully decline. We value transparency and strive to provide services only in areas where we are certain we can make a positive impact.

Body Leasing

As a professional consulting firm, we do not engage in body leasing arrangements. We are committed to providing expert, tailored solutions for specific business needs, rather than merely supplying personnel. Our focus is on quality consulting work, which goes beyond just staffing client projects.

On-Site Work Requests

Our operation model is primarily remote, as detailed in our remote working policy. We believe this offers us the flexibility to work with a wide range of clients while maintaining our work-life balance. Therefore, requests for continuous on-site engagements may not align with our operational strategy and may be politely declined.

Availability of VSHNeers

The value we deliver through our consulting work heavily relies on the right match between client needs and our engineers' expertise. If we cannot find an available VSHNeer who is adequately qualified and can meet the client’s needs within the requested timeline, we may have to say no to the consulting request.

In all these situations, it’s crucial that we handle these conversations with utmost respect and transparency, leaving the door open for potential future collaborations. If possible, we could also consider referring the client to a trusted partner who could cater to their requirements better.

More information on products.vshn.ch - Consulting.

154.5. Reselling

We resell the products of several partner vendors. These software vendors operate in the same markets as VSHN.

GitLab licenses

GitLab

NGINX Application Platform licenses

F5

SUSE Rancher subscriptions

SUSE Rancher

Cloud resources

Amazon AWS, Google Cloud, Microsoft Azure, cloudscale.ch, Exoscale, Swisscom

154.6. An Analogy

Imagine a pizzeria. To make a good pizza, the pizzaiolo needs dough and toppings, consisting of different ingredients.

Imagine that the dough is the foundation; in our case, that would be an APPUIO-branded Kubernetes cluster. You can choose different kind of dough (white flour, multigrain flour, gluten-free flour, etc.) but every kind of dough serves the same purpose, just like you can choose different kind of APPUiO-branded products, where every kind offers you a foundation in the form of a Kubernetes cluster.

The pizzaiolo adds toppings on top of the dough, following the wishes of the customer. We do the same with our products: on top of every APPUiO-branded product we can add the VSHN-branded products our customers require.

Just like you can’t have a pizza without dough and toppings, VSHN-branded products work best when supported by an APPUiO-branded product.

155. VSHNeer Roles

A role is an area of responsibility (a Domain) that is delegated to an individual (the Role Keeper), who has autonomy to decide and act within the constraints of the role’s Domain.

There are two types of Roles at VSHN: Your Job (Main Role) and additional Roles.

155.1. Job (Main Role)

Every VSHNeer is hired for a specific role. This is your main role, your job.

Examples

Product Owner

DevOps Engineer

Agile Coach

155.2. Additional Roles

As VSHN consists of self-governing and self-organizing Teams and when deciding how to account for the Domain as a Team it might be needed for some VSHNeers to take on additional Roles. Such Roles are usually within one Domain and therefore also defined by the Team who’s accountable for the Domain. Additionally there might be a need for VSHN-wide roles, representatives, etc.

Additional Roles bring you more responsibility, which can mean that you’ve to do less in your other Roles, balancing this is crucial.

Examples of additional Roles at VSHN

Team Facilitator

Technology Alignment

Representative in a Delegate Circle

Delegator Representative

Becoming a member of other groups

At some point, you might want to or have to join other Work Groups or Interest Groups. With this you implicitly get an additional Role of Member of Group XYZ. Especially in this case, balancing the time investment between your Roles becomes crucial.

Voluntariness of Additional Roles

VSHN expects that people take on additional Roles when it’s useful, possible and needed. This is also part of our Salary System. In one way or the other selecting people for Roles happens with Consent Decision Making, for example by doing a Role Selection.

Possible implies that you can make time for it (Balancing) and have or can acquire the needed skills.

155.3. Balance Main Role vs Additional Roles

Time is limited, we all have to make the most of our time. Usually no one has time for additional tasks and responsibilities, you have to actively make time for them.

Taking on additional Roles must always be done in accordance with your main role and other additional Roles. That means you can’t just take on additional Roles and leave the work for your other Roles. Overall, the Main Role always comes first - that’s what we all were hired for.

On the other hand, taking on additional Roles and actually investing time can be crucial to VSHN’s success. For this, there are a few things to keep in mind:

With the Delegator of your main Role (usually your Team), decide and document how much time you can spare for your other Roles.

Together with the Delegator of your additional Roles (Team, Work Group, etc.), determine what the expectations are for your time commitment and document them (usually directly in the domain description of each role.)

There are Roles that need more time during bigger projects, organizational changes and similar undertakings. This makes time planning with your other Roles even more important.

Review your Roles regularly with the Delegator. If you are not keeping up with your tasks, talk to the Delegators of your Roles instead of leaving work or governance undone. When you can’t make time to account properly for your additional Role, you can’t keep the role (see Voluntariness.)

Roles can grow (responsibility and/or effort) or can be "big" right from the start, often it’s the better way to make a Main Role (a Job) out of them, instead of trying to find someone who can do it in addition to their main Role.

155.4. Links

Role in Sociocracy 3.0

156. Business Development Manager

This role is one of the first people incoming inquiries get to know. The role filters all inquiries aiming to onboard prospects who fit VSHN’s customer target groups according to the services and products VSHN can provide. Solution teams' capabilities and wishes are part of the Sales On-Boarding Process. In addition, the BDM role keeps an eye on the marketplace. As an outcome of the qualification meeting they propose possible new fields and possibilities VSHN can improve or extend its service portfolio. So far, the BDM is in charge not only of taking over the generated leads but also to take care that the sales process is followed.

156.1. Key Responsibilities

Ensure company revenue growth by

Outbound sales and lead-generation as part of the Sol Team.

Contacting and qualifying incoming prospects

Selling VSHN’s products and services according to VSHN’s product portfolio.

Successfully acquiring new customers that fit VSHN’s customer profile.

Having a state-of-the-art sales process.

Proactively represent VSHN’s values and beliefs to the outside world.

Other Duties

As BDM you are VSHN’s face for our target market.

You are leading price and contract negotiations.

You are the first contact for prospects, commercial inquiries, leads from partners, and potential new partners.

You help Developer Relations as well as our Marketing to generate leads and to contact leads to qualify as soon as possible.

You organize qualification meetings and solution architecture meetings with Solution Architects.

You take part and actively contribute to the Technical Pre-Sales weekly meeting.

156.2. Key Deliverables

Qualified leads

Sales closures

156.3. Dependencies

Collaboration within the Teams

The Inside Sales and BDM are closely working together to make sure that all data is up-to-date and that the Onboarding as well as the Sales Process is followed.

The Customer Success Manager and the BDM are in regular exchange to make sure, that possible new opportunities out of CSM-Work are followed up.

The Solution Architect works togehter in Pre-Sales topics like meetings and requirements engineering as well as expectation managment towards the customer in order to find the best fitting solution on a technical and business level.

Alignement with Marketing to execute and follow up campaigns.

Product Management

Products defines products and services that we can sell.

Customer Solution Teams

Solution teams have the capacity to setup and implement what’s sold.

Coordination of what we sell within Technical Pre-Sales.

156.4. Evaluation Criteria

Seen as the sales team

Takes part in tender meetings and sales-related events.

All involved parties are coordinated and up-to-date.

Continuous improvement of the sales process.

Seen as the company

VSHN is able to scale its business through selling products and services to new customers.

The sales funnel is constantly filled.

Seen as the customer

Postive experience and guidance through the sales process.

Customer communication is done within a timely and positive manner.

156.5. Out of scope

A BDM isn’t:

The direct contact for existing customers

A project related first contact

156.6. Assignment of this role

By the affected Domain: Sales

This role is tracked and reviewed as VIP-131

157. Chief Marketing Officer (CMO)

The CMO is responsible for overseeing the Marketing domain including marketing & business strategy, branding, digital & traditional marketing, events as well as communication & public relations with the goal to increase brand awareness, gain leads and ultimately increase revenue of VSHN.

157.1. Key Responsibilities

All marketing operations of VSHN aligned with the company’s strategy and vision.

Make sure that marketing efforts meet the goal to increase brand awareness, gain leads and increase revenue

Digital marketing: oversee digital marketing, content, social media, website, SEO/SEM efforts

Brand management: ensure VSHN is a well known and respected brand and increase brand awareness

Market research: listen to trends and collect important information about the target market, demand and competition

Communications & PR: manage the way VSHN communicates to the market and ensure that the intended message is clear and consistent

Campaigns & advertisement: able to design and coordinate marketing campaigns across channels

Content marketing: create and oversee content and make sure that it’s valuable for the intended parties

157.2. Competences, qualities and skills

The CMO should have:

A degree or apprenticeship in business and/or marketing or alternatively, equivalent professional experience.

Knowledge in marketing & business strategy and its execution

Experience in branding, digital & traditional marketing, events as well as communication & public relations

Experience in tools such as CRM, marketing automation, market research, data analytics, website development, branding, design & visual software

A flair for communication to communicate precisely, both verbally and written

Team-spirit and negotiation skills in order to collaborate with other departments and external partners and stakeholders

157.3. Assignment of this role

The role is appointed by Management.

This role is tracked and reviewed as VIP-155

158. Chief Information Security Officer (CISO)

The Chief Information Security Officer (CISO) is the main responsible role for the information security at VSHN.

Duties

Own (be responsible for)

Develop and enhance VSHN’s Information Security Management System (ISMS).

Lead the Information Security Management Work Group.

Be

Strategically and tactically responsible for the information security in VSHN.

Responsible for maintaining and monitoring the ISMS.

The go-to person for customer’s questions about information security.

Define

Policies regarding information security.

Processes to identify and mitigate information security threats.

Plan

Awareness training, and general ISMS education sessions.

Audits regarding the ISO 27001 certification.

Audits regarding the ISAE 3402 report.

Regular meetings for Information Security Management Work Group.

Coordinate

Reporting of the state of information security to the Board.

Tickets regarding information security with all teams.

Handling of information security incidents and threats.

Control

All processes in the ISMS (for example, information security process).

The company’s risk management system.

Out of Scope

A CISO isn’t:

The role necessarily working on the technical implementations of security measures.

The legal and compliance department of the company.

Part of the Management Work Group.

Requirements

The role is appointed by Management and reporting to the Board. The CISO should have:

A degree or apprenticeship in computer science.

Alternatively, equivalent professional experience.

Knowledge in ISO 27001/27002 standards.

Experience in the development and operation of the IT systems to be certified.

Experience in risk assessment and risk management.

Missing competences or experience can be provided by an external consultant.

159. Corporate IT Lead

Delegator

Corporate IT Workgroup

Role Keeper

in review

159.1. Purpose

Because Corporate IT is a Workgroup that primarily consists of people who work in other teams and roles at VSHN, we run the risk of lacking capacity or continuity of necessary duties and responsibilities.

We need a person that leads, that the needed things in Corporate IT are decided, followed-up on and done in reasonable time, and that someone has the overview of the state of all systems, the costs and serves as a go-to-person for everyone else at VSHN on the non-technical level.

159.2. Key Responsibilities

Governance lead of Corporate IT.

Ownership and prioritization of operational backlog of Corporate IT (Jira), excluding defined project work (see Corporate IT Project Manager).

Host and facilitation of meetings of of Corporate IT.

Organization of duties of Corporate IT (for example User support).

Ownership of the budget of Corporate IT in dialogue with Business Management.

Operational tasks and user support as far as possible and useful (expertise and capacity).

159.3. Dependencies

Commitment of capacity from Corporate IT Work Group members for governance and operational tasks.

This role is tracked and reviewed as VIP-250

160. Corporate IT Project Manager

Delegator

Corporate IT Workgroup

Role Keeper

in review

160.1. Purpose

The people in Corporate IT Workgroup work primarily in other teams and roles at VSHN, they don’t have the capacity to focus on bigger and complext projects over a longer period of time. Still there are such projects in Corporate IT VSHN needs to get done.

We need a person that leads and stays on top of such projects.

160.2. Key Responsibilities

Lead and oversee initiation, evaluation, design, implementation, and closure of Corporate IT projects. Especially:

Requirements engineering including understanding of and adaption to business processes and workflows.

Software and tooling evaluation.

Solution Design lead.

Implementation or migration planning and oversight of execution.

Project budget.

Evaluation of needed external consulting, support and workforce.

Assignment and management of internal and external workforce, tracking of progress toward project completion.

Host and facilitation of meetings and calls to make decisions and move forward in the project.

Tasks within the project, as far as possible and useful (expertise and capacity).

160.3. Dependencies

Commitment of capacity from Corporate IT Work Group members for governance and operational tasks.

Collaboration from stakeholders and people needed for or affected by the projects.

This role is tracked and reviewed as VIP-251

161. Customer Account Manager

This describes is the former "Customer Success Manager". The role description needs a review to become what we already live as (Key) Account Managers in Sales & Account Management.

The Customer Success Manager (CSM) is responsible for a successful business relationship. They’re the ongoing partner contact for all commercial matters like offers, contracts, invoices and feedback and promote retention and loyalty.

In German: Der Customer Success Manager ist verantwortlich für eine erfolgreiche Geschäftsbeziehung. Er/Sie ist die Hauptansprechsperson für alle geschäftlichen Angelegenheiten wie Angebote, Verträge, Rechnungen und Feedback und fördert eine gute Partnerschaft und Loyalität.

Duties

Own (be responsible for)

Ongoing communication with the business decision makers on the customer side.

Planning and execution of regular meetings to ensure that the customer is happy with the service(s) provided.

Customer contracts and legal requirements.

Be informed in case of negative or positive feedback. For negative feedback and complaints, the first person contacted must take care of mitigation measures.

Keep Service Managers informed, in the form of short briefings, synchronization, etc.

5–10 minute tasks can be done by either Customer Success Managers or Service Managers. The other role must be informed if it affects the other role’s other processing area, for example, when creating a user, or specifying prices for products.

Coordinate

With Sales and Presales Engineering for new customers

With Service Managers and Project Managers for ongoing projects/tasks.

With Support for technical questions from customers

With Accounting for financial/invoicing questions from customers

Overview

Overview of all projects running and planned (or in sales pipeline) for this specific customer.

Support

Service Manager and Project Managers with business requirements such as contracts, billing, etc.

Out of Scope

A Customer Success Manager isn’t:

A project manager for the customer. See Project Manager

The one having technical knowledge of the platform or services of the customer. See Service Manager

Working on engineering tasks for the customer.

Answering technical questions.

162. Developer Relations

Developer Relations (or DevRel for short) is responsible to increase the awareness of technical activities and products within VSHN to current and prospective customers, through various activities: conference speaking, blogging, video production, podcasting, documentation writing and editing, social media presence, and more.

162.1. Key Responsibilities

These are the main responsibilities of a DevRel in VSHN.

Technical spokesperson:

DevRels represents the voice of the technical VSHN team in public settings, both online or in person.

They act professionally in all circumstances.

They act as a low-noise, high-signal communication channel between customers, external teams, and the VSHN technical team, eventually putting engineers in contact with each other for the resolution of specific issues.

They might also appear as guests in podcasts, or be interviewed for press articles, written or online.

Conference speaking:

DevRels participate in technical conferences showcasing VSHN’s expertise, products, and know-how.

DevRels can also be called to moderate panels about various technical subjects.

They prepare and deliver live demos of various technologies.

They show presentation slides based on the official VSHN templates, featuring the required fonts, colors, and other branding elements.

Meetups:

DevRels schedule, organize, and host technical meetups.

Keep the events calendar up-to-date with upcoming events.

They find speakers, coordinate schedules, and engage with the community.

As hosts, they ensure the proper timing of events and make sure that any questions from the audience are properly handled.

After the event, upload recording to YouTube if the event was recorded.

Webinars:

DevRels organize, record, deliver, and publish webinars online about technical subjects, both live or pre-recorded, with or without demos.

After publication, DevRels are also responsible to find answers to any questions that the audience might ask in forums or comment sections.

Blog posts:

DevRels are responsible for all technical content published in the VSHN blog.

They coach other VSHNeers wishing to write and publish their own content on the blog, a coaching activity which might involve ghostwriting.

Social media:

DevRels keep alive social media channels (Twitter, Facebook, LinkedIn, YouTube) with new content every week, generating traffic to our website, and advertising our products, events, initiatives, and culture.

Documentation:

DevRels actively write and eventually also edit documentation written by all team members and thus take an active role in the documentation interest group.

They create tutorials and detailed instructions to help others learn about VSHN products or technologies.

They organize documentation artifacts following the Divio Documentation System: Tutorials, How-To Guides, Explanations, and References.

They ensure a common voice across all documentation bundles.

They gather feedback from end users about the quality of the documentation, and continuously strive to the betterment of said artifacts.

They maintain the various tools used in documentation production: Docker images, command line tooling, CI/CD pipelines, presentation slides, etc.

They teach other VSHNeers about how to use those tools more effectively.

Reports:

DevRels participate in the creation and edition of VSHN’s yearly reports about the state of the DevOps industry.

Consultation role in product management tasks:

DevRels might be asked for feedback during the development of new products.

They have an active role in the creation of documentation artifacts directly related to those products.

162.2. Competencies, Qualities and Skills

A DevRel should possess a certain set of skills:

A technical background; usually as a software developer, a DevOps engineer, a system administrator, a tester, or other related roles.

Proven writing skills; as a blogger, podcaster, book author, or similar.

Basic video editing skills; no need to be a YouTuber, although it helps.

Speaking experience in events, both in person and online, small and large.

Extrovert personality, eager to approach customers and users both in person and online, in order to discover trends, identify needs, and propose solutions to the community.

Curiosity to try new technologies, programming languages, or ideas.

Eagerness to teach others through workshops or online training sessions.

162.3. Evaluation Criteria

These are some of the possible ways in which the work of DevRels is evaluated internally by other VSHNeers:

Positive and visible higher awareness of VSHN as a leading provider of innovative, state-of-the-art, or bleeding edge solutions in the markets where VSHN has positioned itself as a leader.

Visible increase in social media followership numbers, but also in engagement volume and quality.

Documentation products are always up-to-date, reflecting the latest changes in our products.

Customer and end user feedback through social media or other channels.

163. Inside Sales

The Inside Sales is responsible for a successful sales process. They’re the central pivot to ensure good communication between all parties involved.

163.1. Duties

As an Inside Sales you help our customers and partners to become successful with VSHN.

After the initial contact through the Business Development Manager, you take responsibility for opportunities and accompany potential customers through the sales process until closing.

You create customer offers based on Solution Architect’s analysis of customer requirements, Engineering ("what") and Project Management ("when").

You manage the administrative sales process and ensure that future customers receive the best service during the sales process.

You make sure all quotations and contracts are filed properly, support both VSHNeers and customers in these matters and take care of the follow-up and coordination of inquiries and tenders.

You coordinate meetings and workshops with our customers and engineers.

Your goal is to create successful and satisfied customers who stay with VSHN for a long time, grow with us and recommend us to others.

Dependencies

Collaboration with other roles: Service Manager, Engineers, Sales, Sales Architect, Customer Success Manager.

163.2. Evaluation Criteria

For the sales process

Customer receives feedback in a timely manner.

Up-to-date sales pipeline.

All parties involved are coordinated and up-to-date.

Responsible for tracking, maintaining and keeping Contract Management up to date.

163.3. Out of scope

An Inside Sales isn’t:

A project manager for the customer.

The one having technical knowledge of the client’s platform or services. See Service Manager.

The one who handles technical tasks for the client. See Engineering.

Answering technical questions. See Engineering.

Looking after existing customers. See Customer Success Manager.

163.4. Assignment of this role

By the affected Domain: Sales & Marketing

This role is tracked and reviewed as VIP-99

164. Mentor

A Mentor is a senior VSHNeer helping a new VSHNeer to get into VSHN, and learn everything about VSHN.

Duties

Be

Responsible for the new VSHNeer during the Trial period.

The primary contact person for the new VSHNeer.

Define

Onboarding program for the new VSHNeer.

The onboarding program is created in the Wiki here.

Plan

Execution of onboarding program.

Regular catch-up with new VSHNeer (daily get together or as it fits).

Trial period meetings with the new VSHNeer and a member of the team.

Coordinate

Education, to teach all about VSHN to the new VSHNeer:

What does VSHN do?

What are the different Teams doing?

How to work with Jira and how to create tasks?

How to do attendance tracking in Odoo?

How to do worklogs?

When do all the regular meetings happen, and what meetings are available?

Where to find the best food in town?

When and where to get beers with other VSHNeers?

Where are all the things located in the VSHN office?

All these topics are collected in onboarding knowledge building checklists, which are created from wiki templates here.

Control

Execution of onboarding program.

Progress of new VSHNeer.

Out of Scope

Technical help

Getting help on the day-to-day work is the responsibility of the Team.

Requirements

Teaching the "VSHN way" needs some good practical experience working at VSHN. Being a mentor is only possible after being a VSHNeer for more than a year.

Being a mentor carries some duties (see above). This shouldn’t be taken lightly, and it must be carried out carefully. It helps new VSHNeers a lot to get help from a real VSHNeer.

It makes sense for the Mentor to be from the same Team, but it’s not a strict requirement. It’s more important for the mentor to be able to really teach about the "VSHN way."

165. VSHN Tech Radar

There are sometimes many ways how things can be done to achieve the same outcome. To have a common technical alignment at VSHN and to not waste resources, this page lists what tools and technologies we use day-by-day.

If there is a good reason to choose another tool which isn’t listed here, that’s perfectly OK. But please be aware that it might fall out of the picture and doesn’t get the support like the official tools do.

165.1. Languages and Frameworks

Name
Jobs-to-be-done
Ring

Go

Kubernetes Automation (Operators and Controllers)
CLI tools

Adopt

Rust

Tooling which needs to be very fast

Assess

Python

Day-to-day automation
CLI tools

Adopt

Shell Scripts

Day-to-day automation

Adopt

Java

Maintaining the VSHN Portal

Hold

Helm

Packaging of applications for Kubernetes

Adopt

Jsonnet

JSON templating for Kubernetes manifests

Adopt

165.2. Automation

Name
Jobs-to-be-done
Ring

Project Syn Commodore

Bringing configuration to our Kubernetes clusters

Adopt

Terraform

Infrastructure as Code

Assess

Crossplane

Infrastructure as Code with continuous reconciliation

Adopt

Argo CD

GitOps

Adopt

Ansible

Automation of Tasks on VMs and in OpenShift

Assess

Puppet

Configuration management in Linux virtual machines

Hold

165.3. System Services

Name
Jobs-to-be-done
Ring

Kubernetes

Running containerized applications

Adopt

Rook/Ceph

Storage Cluster in Kubernetes

Adopt

Prometheus

Metrics in Kubernetes
Alert roules based on metrics
Alertmanager for alert routing to on-call

Adopt

Opsgenie

On-Call Paging

Adopt

Icinga

Monitoring and Alerting for Puppet Managed Services

Hold

165.4. Tools

Name
Jobs-to-be-done
Ring

AsciiDoc and Antora

Documentation as code

Adopt

Docker

Containerizing applications

Adopt

K8up

Backup on Kubernetes

Adopt

kind

Local Kubernetes environment for development and testing

Adopt

165.5. How it works

We currently don’t have a fancy graphical representation, although this page resembles the structure of a graphical way.

This page is inspired by:

Zalando Tech Radar

Thoughtworks Technology Radar

CNCF Radars

AOE Technology Radar

Quadrants (Categories)

They are represented by the headings on this page:

Languages and Frameworks

Automation

System Services

Tools

Rings

Adopt

Recommended being widely used

Used in production

Perfect for new projects

High confidence in to serve our purpose

Usage culture in our production environment

Low risk

Trial

Might be the next big thing

We have seen work with success in project work to solve a real problem

First serious usage experience that confirm benefits and can uncover limitations

Slightly more risky

Some engineers walked this path and can share knowledge and experiences

Assess

Two-fold: Either brand new or unclear future

Promising and have clear potential value-add for us

Worth to invest some research and prototyping efforts in to see if it has impact

Higher risks, they are often brand new and highly unproven for us

Some engineers have knowledge in the technology

In a phase to be re-evaluated if it should stay

Hold

Don’t use of new projects

Not recommended being used for new projects

We think are not (yet) worth to (further) invest in

Not be used for new projects, but usually can be continued for existing projects

What’s here?

This page documents our view on the tech landscape and helps to answer which tool or service to use when there is more than one choice. We don’t document obvious things like "use kubectl to talk to Kubernetes". We also don’t document all the dependencies to be used for software development, that would blow up this radar too much.

166. People Operations Admin

VSHNeers having the role People Operations Admin (HR) are accountable for the domain of People Operations.

166.1. Duties

In addition to the core tasks of People Operations:

Be approachable by VSHNeers

Lead by example

166.2. Out of Scope

People Operations isn’t:

about getting involved directly in team internal personnel issues, only as a passive escalation point.

solving conflicts for VSHNeers, but moderating and supporting in such matters.

166.3. Requirements

This role is a job at VSHN and can not be held as an additional role.

VSHNeers in this job:

have a diploma in human resources or proven similar work experience.

are resilient.

have outstanding social skills.

This role is part of the domain description which is tracked and reviewed as VIP-36

167. Product Manager

167.1. Purpose

Our Product Manager is the lead of our Product Management and the Products Governance.

Role keeper

Tobias Brunner

167.2. Key Responsibilities

Ensure that the responsibilities of Product Management are fulfilled.

Ensure that governance in Products Work Group effectively happens bring the needed decisions.

Bring the affected / needed people together.

Prepare proposals for offerings, strategy, tactics for Governance.

Documentation work of offerings.

Ensure internal and external communication on vision, strategy and offering changes.

This role is tracked and reviewed as VIP-123

168. Role Product Owner

New Role, work in progress.

168.1. Purpose

Our value stream teams build, operate and support specific VSHN products for our customers, end-to-end. We receive work from product management / road map, troubleshooting, and other team internal sources, but most importantly from our customers. If requirements are not checked, the work is not refined and prioritized, the team would end up doing random things that don’t necessarily help us advance our product strategy or solve the most important or urgent customer needs or problems, or one type and source of work could overrule the others.

We need a way for stakeholder requirements to be brought into the team’s backlog and prioritized, so that the product is delivered with most value, is protected, and ensure alignment with our product strategy.

168.2. Stakeholders

Delegator (often the Management) and Product Management - Needs a person to speak to the team about WHAT the team produces and the progress of that.

The own Team and all Team members.

The customers of the product as defined by the team’s domain.

168.3. Key Responsibilities

This role is the ONLY one that owns a product, defines and prioritizes what the team needs to produce to advance in our product strategy and create the value for our customers. For the team and organization to be successful, we move forward with the decisions evolved by the Product Owner, until there is a reason not to.

For the Organization

Know the product, its customers and how the product is implemented and used.

Market positioning and competition is known and taken into account.

Support the customers and the rest of your Domain’s stakeholders with this product knowledge.

Involved partners and vendor products are known and appropriately considered.

Write viable product feature definitions.

Represent your Domain’s Product(s) in VSHN Product Management and contribute to system level product management decisions.

For the Team

Prioritizing requirements from all stakeholders into the team’s backlog, so that it brings maximum value to the Product(s).

Translating features into bite-sized tasks for development.

Ensuring that the Product Backlog is transparent, visible and understood by the team.

Providing the team an effective balance of work and use of capacity: new product features, changes, maintenance, problem solving, etc.

Evaluating the progress and effectiveness of the work, together with stakeholders.

Leading and contributing to product documentation.

168.4. Key Deliverables

Representation of the product and its development progress in Product Management.

Clarity about what we need to build in detail.

Go-to-person for questions about the Product.

168.5. Key Resources

The Product Backlog

The Product Roadmap

168.6. Constraints

Understanding of Leadership

The responsibility for the team’s domain stays with the team, not with this role.

This role isn’t about deciding for the team how they do things, it’s about making the work - the what - clear.

168.7. Role Assignment

By default, every team that owns one or multiple VSHN products needs to cover this role.

This role description defines the minimum responsibilities to cover, and general constraints.

How the team implements this role, is up to the team, under the constraints defined here.

This role is tracked and reviewed as VIP-124

169. Role Team Facilitator

We have two variations of this role: The Scrum Master serves our Value Stream Teams, the Team Facilitator (this role) serves all other teams.

Delegator

The Team that needs to role
If need is still unclear, the Delegator of the Team

169.1. Purpose

At VSHN, our teams operate semi-autonomously, which involves not only carrying out operational tasks—such as building, delivering, and maintaining products for our customers—but also self-managing to function effectively as a team and continually improve. This means ensuring that the Fundamental Team Responsibilities are adequately addressed by the team, for example organizing and prioritizing work, and reviewing results to deliver effectively on their purpose. If we provide the necessary support for teams to successfully navigate the complexities of being self-managed, self-organizing, and continuously improving, we can foster strong, effective teams. This would enable individuals to focus on actual work while collectively sharing the team’s responsibilities.

We believe there is a need to assign a dedicated role in each team, focused on the team’s effectiveness and the team’s fundamental responsibilities. This will allow other team members to concentrate on the actual value-creating work, while the role owner can direct their attention to these specific topics.

169.2. Stakeholders

The Team: Needs the to function as a semi-autonomous, self-managed team and improve to fulfil their delegated purpose.

The Team Members: Need help to navigate complexity, focus, commit, overcome personal challenges.

The Delegator of the Team: Needs a go-to person on how the team works and what clarity or support they need, also to get insights on how our defined system and principles work in practice at VSHN in a Team.

169.3. Key Responsibilities

In general, ensuring (not necessarily doing it yourself) the team has addressed all Fundamental Team Responsibilities good enough. More specifically:

To the Team

Coaching the team members to develop self-management, cross-functionality, and effective working methods;

Understanding the team’s purpose, constraints, and dependencies to point out issues in being effective and acting within those boundaries.

Helping the team focus on creating high-value increments that meet the stakeholders needs and team’s Definition of Done.

Leading the removal of impediments to the team’s progress.

Ensuring that meetings are hosted and moderated to be effective and efficient (do it or help to do it).

Facilitating Governance synchronously (for example, governance meetings) and asynchronously - for team level governance items.

Facilitate goal setting (OKRs), tracking progress, reviewing and process retros.

Helping find techniques for effective work item definition and Backlog management.

Helping establish an empirical planning process.

To the Organization

Ensure the interface with the teams’s Delegator.

Facilitating stakeholder collaboration as requested or needed.

Removing barriers and impediments between the team’s stakeholders, dependencies and the team.

Be the leader, an agent of change within the teams for our organization’s development.

169.4. Key Deliverables

A Trainer, Coach, supporter and facilitator for the Team on the above Key Responsibilities

A Go-to person for the organization on the topics of how the team functions and works

A Go-to person for the team members on the above Key Responsibilities

A Representative in cross-team governance on topics for the team

An Owner of team level governance topics to remove impediments and improve how the team functions

Documentation on how the team functions

169.5. Skills and Mindsets

This roles require specific skills and mindsets to be effective. If the a role keeper doesn’t meet the requirements, training is required. What is needed at which level depends on the context the Facilitator acts (which team, used methodologies / frameworks, etc.), the following is the needed minimum.

The following skills on the "Ha" (Shu-Ha-Ri) Level

Solid understanding of how VSHN works. Facilitating the semi-autonomous, self-managed culture of the team via S3 patterns, primarily: role selection, consent decision-making, describing organizational drivers, peer review, governance backlog on the Team level.

Teaching and Facilitation of Objective and Key Results on the Team Level

Strong social skills, ability to connect with people, empathy, mindfulness and self-awareness.

Mindsets

Sociocracy 3.0 principles, primarily Equivalence and Consent

Agile, primarily iterative and incremental value delivery and review cycle, in Operations and for Governance on the Team level.

169.6. Constraints

What leadership means in this context

The responsibility for the team’s domain and their Fundamental Team Responsibilities stays with the whole team, not with this role.

169.7. Key Challenges

Don’t become the boss of the team - stay the servant leader and facilitator. See what this means at VSHN.

Care about and lead the topics defined in your role, do the operational work defined in the role - Don’t become the person doing all the meta work for others, just because they don’t care - help team to share the responsibility and workload instead!

169.8. Role Assignment

By default, every team at VSHN needs to cover what is defined in this role - assigning this role to someone in the team is the suggested way.

How the team implements this role, is up to the team, under the constraints defined here. This role description defines the minimum responsibilities to cover, and general constraints. Value Stream Teams have a more specific role defined, the Scrum Master.

169.9. Delegator Responsibilities

The Team

Ensure that what is outline in this role, and especially the Fundamental Team Responsibilities are addressed good enough.

Support the role keeper by sticking to the role definition and not overloading them with additional duties. Especially if the role keeper as another primary role.

The Delegator of the Team

Ensure that the team has a way to address the Fundamental Team Responsibilities.

Break up situations where the Team doesn’t understand their responsibilities yet because of the lack of a role like this.

169.10. Evaluation Criteria

Binary evaluations as tools of measure to show how a role keeper is succeeding:

As a Team Facilitator

As a Leader

What does it mean for a Team Facilitator to be a Leader?

What does it mean for a Team Facilitator to be failing or succeeding?

This role is tracked and reviewed as VIP-255

170. Role Scrum Master

We have two variations of this role: The Scrum Master (this role) serves our Value Stream Teams, the Team Facilitator serves all other teams.

Delegator

The Team that needs to role
If need is still unclear, the Delegator of the Team

170.1. Purpose

This role has the same purpose as the Team Facilitator with an added, strong focus on Agile, Scrum or related methodologies in our Value Stream Teams, to continuously improve the team’s practices, using the Scrum framework, the KanBan system and more, to establish a way of working that delivers the value assigned to the team’s domain and meet customer needs incrementally and iteratively.

At VSHN, our teams operate semi-autonomously, which involves not only carrying out operational tasks—such as building, delivering, and maintaining products for our customers—but also self-managing to function effectively as a team and continually improve. This means ensuring that the Fundamental Team Responsibilities are adequately addressed by the team, for example organizing and prioritizing work, and reviewing results to deliver effectively on their purpose. If we provide the necessary support for teams to successfully navigate the complexities of being self-managed, self-organizing, and continuously improving, we can foster strong, effective teams. This would enable individuals to focus on actual work while collectively sharing the team’s responsibilities.

We believe there is a need to assign a dedicated role in each team, focused on the team’s effectiveness and the team’s fundamental responsibilities. This will allow other team members to concentrate on the actual value-creating work, while the role owner can direct their attention to these specific topics.

170.2. Stakeholders

Same as Team Facilitator.

170.3. Key Responsibilities

In addition to Team Facilitator

Establishing Scrum within the team.

Leading, training, and coaching the team and the organization in its Scrum adoption;

Helping the Scrum Team understand the need for clear and concise Product Backlog items.

Helping establish empirical product planning for in complex environment.

Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

170.4. Skills and Mindsets

In addition to Team Facilitator

Solid understanding and experience in guiding a Team through Scrum and KanBan in a Software or IT Engineering Team.

Professional Scrum Master I level.

170.5. Constraints

Same as Team Facilitator.

170.6. Key Challenges

Same as Team Facilitator.

170.7. Role Assignment

Same as Team Facilitator.

170.8. Delegator Responsibilities

Same as Team Facilitator.

170.9. Evaluation Criteria

Binary evaluations as tools of measure to show how a role keeper is succeeding:

As a Scrum Master

As a Leader

Same as Team Facilitator but more specifically:

What does it mean for a Scrum Master to be a Leader?

What does it mean for a Scrum Master to be failing or succeeding?

This role is tracked and reviewed as VIP-255

171. Role Technology Alignment

New Role, work in progress. Better name for this role needed.

Delegator

The team that needs to role

171.1. Purpose

In a team many technical things have to be decided, one has to choose the one way out of many, how a task or a problem is solved technically. Many decisions have a long-term impact and can often only be changed again with a lot of effort. If everyone in the team would solve things the way they think is right, collaboration would hardly be possible, and in the end no one would understand how what is solved. Usually it works out naturally that the team makes such major technical decisions together, but often situations are complex or one does not even notice when a conscious decision would make sense.

We need leadership in the team that can point out technical challenges to the team or cross-team and then insist that we understand them together, find solutions, decide, implement and continuously develop it further and share it for other teams where it makes sense.

171.2. Key Responsibilities

This is the role in the team that cares about how they address technical challenges and that needed decisions are done together.

Give clarity to the teams what technical decisions and issues are relevant to dig into and might need alignment.

Facilitate, evaluate and lead development of technology and technoical doncepts decisions in the team.

Represent the Team in the Tech Alignment Workgroup.

Lead implementation of cross-team decisions from the Tech Alignment Workgroup in the Team.

171.3. Constraints

Understanding of Leadership

The responsibility for the team’s domain stays with the team, not with this role.

This role isn’t about deciding for the team, it’s about insisting that the necessary decisions are made.

171.4. Role Assignment

By default, every team at VSHN needs to have a person in this role.

This role description defines the minimum responsibilities to cover, and general constraints.

How the team implements this role, is up to the team, under the constraints defined here.

This domain is tracked and reviewed as VIP-X

172. Solution Architect

Role Keepers

Gabriel Mainberger, Manuel Hutter

Delegator

Marketing & Sales (Account Management), Team Sol

172.1. Purpose

Why does this role exist?

VSHNs is known for the ability to speak directly with an engineer who knows what they' re talking about, who can understand a customer’s challenges and figure out how we can solve them. Non-technical sales people can’t do that. Sales asking random engineers for help doesn’t create the needed sense of ownership.

We need people who can take the time to work directly with sales and the customer to figure out what the customer needs and provide them with a solution that meets their needs and aligns with VSHN’s strategy.

172.2. Key Responsibilities

Coordinate with other Solution Architects, Inside Sales and Key Accounting (SM, CSM) on who is handling which "Requirement Engineering" tickets. Pull tickets from the backlog, own the request from start to finish, and perform the following tasks as needed.

See Requirements Engineering and Solution Design Process.

Requirements Engineering

Meet with (potential) customer, understand and document their business, challenges, requirements and constraints - technical and business.

Clarify budget and timeline of iterations to deliver possible solutions.

Solution Design

Coordinate with Products (PM, PO) and other Solution Architects and Engineers.

Create and document Solution Design, including effort estimation and service pricing.

Support offering and present Solution to customer, answer technical questions.

Consulting

In all the above, do consulting as useful to help the customer understand their challenges and what they need, while focusing on creating Managed Services later. This might include:

Workshops

Setting up demo instances of VSHN Products (for example APPUiO Cloud instances, CI/CD pipeline, etc.).

Getting their development environment set up and support it.

172.3. Key Deliverables

What are the specific things we offer to fulfil our key responsibilities and purpose?

Documented requirements per request

Documented solution design to be used in the offer

Consulting

Technical support for the (potential) customer during the whole sales process

Internal support during onboarding of the customer

172.4. Delegator Responsibilities

Make sure that VSHN Strategy is made clear enough.

Governance within Customer Solution to support this role.

172.5. Dependencies

Solution Team of the Engineer

Time for this Role, fulfilling this role has priority over other work in the team.

Availability to react and answer to new / updated requests within 1 work day.

Sales

Bring in and create tickets in the backlog for actual customer requests.

VSHN Strategy

Clarity on what we actually want to offer and what not.

VSHN Products

Definition of the Solution Framework

Product Catalog including feature maturity

172.6. Key Resources

Issue-type, workflow and backlog in Jira for "Sales Requests"

Access to Hubspot and ERP

172.7. Mindset, Skills and Capabilities

Solid understanding of all current VSHN Products (what do we offer)

Hands-on Setup and Operations experience (could be distributed over all Solution Architects) of the VSHN Product and the used technology

Ability to understand and talk about business / economic aspects with the customer and sales

Basic understanding of the technologies used in customer Application (for AppOps)

Confident in advocating VSHN values, strategies, and solutions, including ability to engage in technology debates

172.8. Monitoring and Evaluation

Review (usually Peer Review) after 2 months when someone starts in this role, then every 4 months.

Evaluation Criteria

Own at least 2 active requests in average.

Customer are happy with consulting provided.

Engineers can directly work with the documented Solution Design and understand the "why" (Requirements).

(Potential) customers get answers and offers within a useful time.

This role is tracked and reviewed as part of as VIP-189

173. Role Apprentice Owner

Role Keeper

Sabrina Lang (starting 2023-03-01)

Delegator

Business Management (Management)

173.1. Purpose

VSHN has one apprentice in the 3rd of 4 years and would like to have more apprentices in IT in the future. An apprentice is more than an employee, as we are responsible for the vocational practical training in addition to the vocational school.

We have to make sure that we fulfill this responsibility, that the administrative work that goes along with it is done conscientiously and that the organization of the training and mentoring within the company is ensured so that the trainees complete their apprenticeship successfully and are well-prepared for their working life.

173.2. Stakeholders

As a Swiss company we want to be part of the Swiss "Duales Bildungssystem" counteracting the impending shortage of skilled workers. Offering apprenticeships and having apprentices is a big part of this, and is also a way to "create future VSHNeers".

Management (strategic decision to offer apprenticeships)

Parents of the apprentice

The apprentice

Education institutions (for example TBZ / MBA in Switzerland)

173.3. Key Deliverables

Documented, up-to-date educational concept in the wiki.

Official administrative work with education institutions.

3rd level go-to person for all academic, professional and personal matters.

Go-to person for all administrative matters.

173.4. Key Responsibilities

Ensure education according to official educational plan:

Apprenticeship Organization: Who is responsible for what,

Organize Education Concept with the Apprentice Professional Education role keeper,

Organize and ensure availability of needed Technical Mentors.

All apprentice related administrative work not covered by other roles.

Ensure review of apprentice progress. Regular sync with the role keepers involved in the apprenticeship.

173.5. Key Resources

Educational Plan (Bildungsplan) "Betriebsinformatiker:in mit eidgenössischem Fähigkeitszeugnis (EFZ)"

Apprentice documentation, handbook, and work assignments in Wiki.

173.6. Dependencies

Recruiting (for additional apprentices if planned)

Availability of mentors in different fields and needed topics

Level of personal development, expertise, and motivation of individual apprentice

173.7. Delegator Responsibilities

Define if and when to get additional apprentices and organize recruiting.

Enabling external support as needed.

Support to define and delegate relevant roles and responsibilities (if needed).

173.8. Mindset, Skills and Capabilities

HR Administration

Understanding of Swiss Apprentice System

173.9. External Constraints

Swiss law and regulations, specifically:

Education permission from MBA required.

One Person with "Berufsbilder" certificate required within the company.

173.10. Monitoring & Evaluation

Every 3 months, retro or peer review with the involved roles, apprentices and the Delegator.

This domain is tracked and reviewed as part of VIP-218

174. Role Apprentice Professional Education

Better name for this role needed.

Role Keeper

Alexander Dehmel

Delegator

Apprentice Owner

174.1. Purpose

The Apprentice Owner role ensures the apprenticeships at VSHN on the high level, does the administrative work and serves as a 3rd level go-to-person and escalation point. Planning the work according to what is required officially (educational plan) requires understanding of technical concepts and requires expertise.

We need someone who has the overview of the needed work according to the official educational plan, who plans, coordinates and reviews it and is the go-to-person on this level.

174.2. Key Deliverables

Go-to person for all technical and personal matters (2nd level).

Concrete work from the official educational plan as refined projects or tasks.

174.3. Key Responsibilities

Define additional or refine work in apprentice’s team to fulfil requirements according to the educational plan.

Regular sync with apprentice.

Review of apprentice progress according to educational plan.

Coordinate or delegate needed knowledge transfer or education from VSHNeers.

Psychological, vocational training and pedagogical issues, supervision and opportunities to share experiences.

174.4. Key Resources

Educational Plan (Bildungsplan) "Betriebsinformatiker:in mit eidgenössischem Fähigkeitszeugnis (EFZ)"

Planning in Jira and Wiki.

174.5. Mindset, Skills and Capabilities

Needed technical expertise and experience.

Didactic and social skills - likes and used to work with young people.

Communicating & Motivating

174.6. Monitoring & Evaluation

Every 3 months, retro or peer review with the involved roles, apprentices and the Delegator.

174.7. Assignment of this Role

This role can be assigned to any engineer at VSHN who meets the role requirements, independent of the Team.

This role should not interfere negatively with the main role of the role keeper, see Roles.

The time investment into this role needs to be tracked by the role keeper and is estimated to not be more than 2-4 hours per week.

This domain is tracked and reviewed as part of VIP-218

175. Role Apprentice Technical Mentor

Role Keeper

Daniel Hauswirth (starting 2023-03-01)

Delegator

Apprentice Owner

175.1. Purpose

The role Apprentice Professional Education cares about defining work in addition to the work of the apprentice’s home team. That work might be mentored by anyone at VSHN or external who commits to doing that. The normal work, is the work of the team (for example Corp IT).

There needs to be someone around by default who supports the apprentice on a daily basis, works together, explain how things work and where to find information.

175.2. Stakeholders

The apprentice

175.3. Key Deliverables

Daily Go-to person for all technical and task related matters (1st level).

175.4. Key Responsibilities

Support apprentice with a defined topic or task.

Sync with the Apprentice Owner as helpful.

Be there for all technical questions of the apprentice, in general and in context of specified tasks.

Be in the same team, same planning context with the apprentice.

Find and help to plan actual work from the team that matches the education plan, in cooperation with the Professional Education role keeper.

175.5. Mindset, Skills and Capabilities

Didactic and social skills.

Likes and used to work with young people.

Be in the office.

175.6. Monitoring & Evaluation

Every 3 months, retro or peer review with the involved roles, apprentices and the Delegator.

This domain is tracked and reviewed as part of VIP-218

176. C-Level Titles

Our management is defined in Management Work Group and is very different from classic, more hierarchical organizations. At VSHN, the Management acts as a Delegator for semi-autonomous, self-organizing teams. The Management has no direct influence on what happens in VSHN and mainly serves as an oversight and escalation function only, which can then bring up issues with the teams or other roles, but management can’t simply decide on their own. Read more in here about how VSHN works.

Please don’t use C-level titles at VSHN internally or proactively communicate them externally. We do not identify with these titles; they are not defined roles at VSHN, nor do they serve any function within our organization.

176.1. Signature Rights

Many VSHNeers, independent of their role (and especially C-level titles) might officially sign for VSHN, usually a "joint signature-at-two" is required. See commercial register.

176.2. If you need to name a C-level person

From experience, we know that for customers, partners, and the business world, it’s unfortunately sometimes tricky to avoid naming some C-level titles. Therefore, if after explaining how VSHN operates, an external party insists on knowing a C-title or when you have to sign as "C-level" on a contract, you might use one of the following VSHNeers.

Title
Possible VSHNeer
What it could mean
How it actually is

CEO
(Chief Executive Officer)

Markus Speth, Marco Fretz

Represent VSHN to authorities, customers, at events, and the like.

While anyone might drive decisions, members from Management, People Ops, Culture or Strategist roles often do. Depending on what it is, anyone might represent VSHN externally.

COO
(Chief Operations Officer)

Marco Fretz, Markus Speth

Represent the Operational Business and how we are organized.

Operations is self-organized in teams, with standardized constructs like most teams having a Scrum Master and Product Owner. The Culture role drives clarity around organizational structure, practices, and proactively helps to cultivate work culture.

CTO
(Chief Technology Officer)

Tobias Brunner, Marco Fretz

Represent our products, tech-strategy, and tech-related decisions.

Technology decisions can be made by any team and are aligned via the Tech Alignment Work Group. More strategic decisions are driven by the Strategist role, and product level decisions and documentation are handled by product roles (like Product Manager or Product Owner).

Exception
(for completeness):
CISO
(Chief Information Security Officer)

Daniel Hauswirth

-

Exception: this role actually exists in VSHN and is used internally and externally. We might rename this role at some point for consistency.

177. Terminology

177.1. Practices at VSHN

Agile

Since its start VSHN tried to be as Agile as possible. Agile refers to the Agile Manifesto, Scrum, DevOps and Sociocracy 3.0 build heavily on Agile and go way beyond Software Development, applying Agile principles to the whole organization practices, structures and collaboration.

Driver

A term from Sociocracy 3.0 - A driver is a person’s or a group’s motive for responding to a specific situation, especially used in our Decision Making Process.

Governance

A fundamental term from Sociocracy 3.0 - The act of setting objectives (goals), and making and evolving decisions that guide people towards achieving them. Read more here.

Meeting

A meeting is an event where 2 or more VSHNeers meet to achieve a pre-defined results. This can be problem solving, coordinating Operations work, making Governance or understanding an issue. We try to only have meetings if the intended outcome or at least the Driver is clear to all participants. See Meetings.

Sync Meeting

It historically evolved that we have many Syncs at VSHN, that can be 2 or more VSHNeers. The idea is to quickly get on the same page on one or multiple topics, unblocking the other person to get back at work and make progress. Syncs are often a less efficient way and needed, when other work coordination processes are not working effectively. Syncs should be used sparingly and usually need an agenda (list of topics) to be effective. Evaluate your Syncs periodically and check if there is a better way to coordinate with the needed people.

Workshop

A more defined format of a Meeting, with facilitation through a defined process to produce a specific result. Simply discussing and taking notes is not a Workshop. We have internal workshops and workshops with and for customers.

Operations

a) A fundamental term from Sociocracy 3.0 - Doing the work and organizing day to day activities within the constraints defined through Governance. Read more here.
b) Running, maintaining and handling operational issues with an IT Service (Product) that VSHN uses or provides to Customers.

Scrum

While Agile but also Sociocracy 3.0 are more principles and patterns that you might value or use, Scrum is more a framework that gives a team the minimal structure to organize their workflow in an Agile way. We don’t do Scrum exactly by the official Scrum Guide, but we use most aspects of it in our tech teams.

Sociocracy 3.0

Sociocracy 3.0 (S3) is social technology for evolving agile and resilient organizations at any size, from small start-ups to large international organizations. See it as a toolbox, it’s not a framework, not an organization model. We use patterns from this toolbox and value the 7 principles, which also align quite directly with our Values and Agile.

Effectiveness

Devote time only to what brings you closer toward achieving our objectives, so that we can make the best use of our limited time, energy and resources.

Consent

Raise, seek out and resolve objections to decisions and actions, so that you can reduce the potential for undesirable consequences and discover worthwhile ways to improve. Continue with something until there is a such a good reason not to.

Empiricism

Test all assumptions you rely on through experiments and continuous revision, so that you learn fast, make sense of things and navigate complexity as effectively as you can.

Continuous Improvement

Regularly review the outcome of what you are doing, and then make incremental improvements to what you do and how you do it based on what you learn, so that you can adapt to changes when necessary, and maintain or improve effectiveness over time.

Equivalence

Involve people in making and evolving decisions that affect them, so that you increase engagement and accountability, and make use of the distributed intelligence toward achieving and evolving your objectives.

Transparency

Record all information that is valuable for the organization and make it accessible to everyone in the organization, unless there is a reason for confidentiality, so that everyone has the information they need to understand how to do their work in a way that contributes most effectively to the whole.

Accountability

Respond when something is needed, do what you agreed to do, and accept your share of responsibility for the course of the organization, so that what needs doing gets done, nothing is overlooked and everyone does what they can to contribute toward the effectiveness and integrity of the organization.

177.2. Corporate Management

Corporate management comprises functions that need to function in order for a company to be successful in the long term. Governance is not necessarily a role or a team, these functions can be distributed and shared. Below are just a few that often cause confusion and which we would like to explain.

(Information) Security Risk

(Information) Security Risk involves threats to information assets, such as cyber attacks, data breaches, or insider threats, potentially disrupting business operations and strategic goals. Implementing robust security measures and policies is essential for protecting data integrity, ensuring compliance, and maintaining operational and strategic stability. See our Information Security Management.

Escalation Handling

Escalation Handling, especially in an organization of self-organized teams is about addressing unresolved issues through structured support, without viewing escalations negatively. It’s a reactive approach ensuring team, customer or employee needs are met and promoting continuous improvement within the team’s autonomy and decision-making framework.

Operational Risk

Operational Risk pertains to potential failures in internal processes, systems, or human actions that can disrupt a company’s operations. These include system outages, inefficiencies, or security breaches, particularly impacting service delivery and compliance. Managing these risks is vital for maintaining operational efficiency and achieving strategic objectives.

177.3. Offering and Business Development

Lead

A Lead is any individual or entity potentially interested in our Offerings, marking the first stage of engagement. It encompasses anyone showing curiosity or interest in our products or services without committing to a purchase yet.

Sales Request

A Sales Request is made by a Lead seeking a proposal, quotation, or more information to aid in their purchasing decision. This marks a critical shift from interest to active pursuit of how our offerings can fulfill their needs. Such a request is usually followed-up by more interaction with the customer and a Sales Offer.

Sales Offer

A Sales Offer is a tailored proposal comprising a list of Products and Services, complete with descriptions, validity dates, pricing, and any applicable discounts. It addresses a specific Sales Request for a potential customer. Also known as a "Quote" or "Quotation."

Sales Order

When a Customer or potential customers buys the Sales Offer we have an order, a purchase. We then have to deliver what the customer ordered.

Asset

An Asset is a Resource we produce or define, such as software, infrastructure, tooling, blueprints, concepts, checklists, or workshop formats. Assets are integral components of Products or Services but are not directly marketable. They serve as foundational building blocks within our solutions. Example: The VSHN Puppet Framework, a key element in our Server based Managed MariaDB Product.

Value

In both marketing and Agile terminology, Value is a crucial concept. Value is determined by the receiver, typically the Customer, and the most effective way to measure whether something offers Value is if a) the Customer’s needs are met and b) they (repeatedly) compensate us for it.

Product

A Product is a tangible or digital good designed to fulfill Customer needs, thereby providing Value to them. In our context, products encompass reproducible IT solutions or XaaS (Anything as a Service). They are distinguished by their 'off-the-shelf' availability, meaning we can deliver them readily or have a precise plan for their execution. While there are more specific forms of Value — for example, see 12 Standard Forms of Value — we summarize our offerings as Products, even when they might strictly fall into categories like Subscription, Shared Resource, or Resale.

Service

A Service is an intangible offering, such as Consulting, Engineering, or training, designed to meet customer needs. Unlike Products, services are bespoke, often customized, and typically invoiced based on the actual time and effort involved.

Offering

Our Offerings represent the diverse solutions we provide, analogous to a restaurant’s menu. While a specific type of pasta is an Asset, pasta bolognese would be a Product. When listed on a menu, it becomes an Offering – a selection that customers can order. Offerings can be a single Product or Service, or a bundle of multiple Products and Services, targeting different customer segments.

Customer

A Customer is a private person or, in the case of VSHN, primarily another company that we provide value to through our Offerings. They purchase from us and, in return, pay us. Customers are known to us, tracked in our ERP/CRM, and we maintain records of our engagements and their financial contributions.

Customer Segment

Also known as "Customer Profile", a term best described in the Value Proposition Canvas. The circle represents the Customer Profile. It’s not one customer, but our understanding of a group of customers with similar needs, pains, and potential gains. We group customers into segments and then figure out which Value Proposition (the rectangle) would be a match.

Value Proposition

Although it could be used interchangeably with Offering, "Value Proposition" is more internal in designing the specific value intended for the Customer Segment to receive. It represents a bundle of Products and Services designed to meet the needs of a customer (grouped into a Customer Segment), alleviate their pains, and provide them with benefits.

Account

A Customer is also an Account in the scope of Customer Account Management. Defined by various criteria, we have Key Accounts and other Accounts.

Partner

While a Customer might be referred to as a Partner in marketing and sales contexts, for internal clarity, a Partner is defined distinctly. In alignment with the Business Model Canvas definitions, a Partner is another company that provides critical Resources or performs essential activities that are integral to our value creation for our Customers. This can include partners who act as sales or delivery channels, enabling us to reach broader markets by selling or delivering our Products and Services through their offerings to their customers.

Resource

Resources are Assets and capabilities crucial to the operation and value delivery of our business. This can include physical assets like hardware, intellectual properties such as software and patents, human skills and expertise, financial capital, or technological tools. Each Resource plays a specific role in supporting our Products, Services, and overall business strategy, enabling us to meet our objectives and satisfy customer needs.

Support

While there are no official definitions, for us Support is a Service either included in the fixed billing of a Product or billed by-the-hour to help a Customer us the things we provide to them. For example how to use a function of APPUiO Cloud. A Support cases is done, when the customer has understood the answer or instructions. Follow-up work for us, is not in the scope of support.

Engineering

Engineering is a frm of Service, and is about understanding an issue, problem or (Customer) need, designing and implementing a solution to address that need. We deliver a tangible result, not simply work for a customer.

Consulting

Consulting is a form of Service and means working for a Customer by questioning their status quo, thoughts and ideas or understanding their problems and giving advice. It might involve writing concepts or delivering other artifacts, but as part of Consulting, we don’t implement a technical solution or take responsibility for what the customer does with our advice. That would fall into the area of Engineering.

177.4. Organization Structure at VSHN

Interest Group

See Interest Groups: A group of people coming from various teams solving a particular problem in the company. Interest Groups are orthogonal to teams.

Domain

A term from Sociocracy 3.0 - A distinct area of influence, activity and decision making within an organization. Domains for example describe what a team is accountable for within VSHN.

ISMS

Information Security Management System of the Domain Information Security Management.

Role

A person taking responsibility for something at VSHN. Usually the responsibilities are defined in a Domain description which is delegated to an individual person, then it’s a role and the person becomes the role keeper.

Role Keeper

See Role.

Team

A group of people taking responsibility for part of VSHN. Usually the responsibilities are defined in a Domain description which is delegated to a group of people, through they become a Team and share the responsibility together.

Delegator

The Role or Team that delegates a Domain to an individual or group of people. The delegator stays overall accountable, the individual or the group become the Delegatee(s)

Delegatee

The individual or the group of people who take responsibility for a Domain, delegated by the Delegator - either Team or a Role Keeper.

VSHN

The name of the company, pronounced like the english word "vision:" ˈvɪʒn. It’s not an abbreviation, it’s just some characters put after each other, sounding like "vision."

VSHNeer

An employee of VSHN.

Value Stream

A Value Stream is a value creation chain. It encompasses the entire process from developing products and services to the sales process, onboarding, project execution, daily operation, and support, and circles back to reviewing and modifying the solution periodically to fit the Customer's changing needs. This includes reselling adapted or new solutions. In our case, our focus is to continuously deliver value, not on-off tasks - that’s why Value Streams at VSHN can be seen as a cycle that only stops, when the customer leaves VSHN. A Value Stream is not necessarily a Team at VSHN, but we try to organize or at least align Teams and Roles as much as possible to one or similar Value Streams. More on this, see Align Flow Pattern.

177.5. Various terms invented by VSHN

VSHNary

Anyone aligned with the VSHN culture, mainly referring to our Values.

VSHNtower

Our cool meeting room in Neugasse 6, 8th floor.

177.6. Good to know as a VSHNeer (inofficial)

Amboss Rampe

The brewery bar next door to the VSHN Zürich office, famous for its traditional beer.

Satay chicken day

There’s an excellent Thai food take-away next to the VSHN Zürich office, that serves excellent satay chicken once a week. That day is called "Satay chicken day."

Znoomi

Casual group coffee drinking over video conference, mix of words "Zoom" (video conference) and "Znüni" (Swiss-german word for mid-morning snack). Twitter post from one of our Znoomis.

Yak shaving

Going down the rabbit hole of task dependencies. Blogpost explanation, video example.

177.7. Tool naming

Some of our tools have really weird names. If you ever feel lost, just refer to this table.

Name
Description
Translation
Wiki
Source

Concierge

Align your repository configuration files. Plain simple, with CI.

Concierge

GitHub¹

GitHub²

Espejo

Kubernetes object syncer

Mirror (Spanish)

GitHub

Floaty

Cloud provider API integration for Keepalived

GitHub

Garacho

VSHN Package Cache

Package cache

GitLab

K8up

Kubernetes / OpenShift Backup Operator

Kubernetes (K8s) backup

APPUiO Backup as a Service - K8up

GitHub

k8up.io

Larawan

Automated virtual machine image builds using Packer

GitLab

Locutor

Ansible callback plugin sending important messages to chat channels

Spanish for "Speaker" or "Broadcaster"

GitLab

Pacco

Local Puppet Vagrant environment

GitLab

Paecklichef

Downloads pending updates to local caches prior to weekly maintenance

GitLab

Signalilo

Alertmanager to Icinga Bridge

Railway signal (Esperanto)

Alertmanager to Icinga2 Bridge Specification - Signalilo

GitLab

Seiso

Cleanup tool for Kubernetes

Japanese for "cleaning" (think “shine” in English)

GitHub

177.8. German/English difficulties

Sometimes the German to English translation (or vice-versa) leads to confusion.

German
English

Generalversammlung / GV

General Assembly

Verwaltungsrat

Board

Verwaltungsratspräsident

Chairman of the Board

Verwaltungsratsmitglied

Member of the Board

Geschäftsleitung

Management

Geschäftsführer

General Manager

Geschäftsleitungsmitglied

Member of the Management

178. VSHN Tooling

Corporate IT provides various tools to enable VSHNeers to do their jobs. Here is a list of all the tools and their uses:

Service Description
Current Tool

Central Authentication

LDAP, Keycloak

Chat

Rocket Chat

Coding

Github

Contract Generation

DocGen

CRM

Hubspot

Discussion Forum

Discourse

E-Mail

Mail Server

ERP, Accounting, HR

Odoo

Filehosting

Nextcloud

Git Repo and Pipelines

GitLab

Groupware

SOGo

IP Addressing

RIPE

Office Network

UniFi Network

Online Signatures

SignRequest

Password Manager

Passbolt

Phone and Video Conferencing

Zoom

Recruiting

Recruitee

Surveys

Findmind

Ticket and Project Management

Jira

More information about our tooling is available on the Wiki: Corporate IT.

179. Documentation :description: Where to find documentation.

Comprehensive, precise, and up-to-date documentation is at the very core of our activity. It helps us to collaborate with each other, and it helps our customers as well. At VSHN we’ve an extensive documentation strategy, and this section of the handbook explains it in detail.

179.1. Documentation Index

Documentation
Content
Audience

Company Handbook

The VSHN Company Handbook

VSHNeer

Product Documentation

VSHN Product Documentation

VSHNeer, Prospect, End-User

Confluence Wiki

Company Wiki

VSHNeer, (End-User)

Knowledgebase

Technical Knowledgebase

Technical VSHNeer

APPUiO Cloud docs

APPUiO Cloud End-User

Technical VSHNeer, End-User

APPUiO Portal docs

APPUiO Cloud Portal End-User

VSHNeer, End-User

AppCat docs

VSHN Application Catalog End-User

Technical VSHNeer, End-User

VSHN Portal docs

VSHN Portal End-User

VSHNeer, End-User

Project Syn

Project Syn

VSHNeer, End-User, Prospect

K8up

K8up (Kubernetes Backup Operator)

VSHNeer, End-User, Prospect

Company Website

Mostly marketing and blog articles

Prospect

179.2. Audience

Documentation is only as good if the content matches the audience reading it. We see the following audiences:

VSHNeer

All VSHNeers.

Technical VSHNeer

VSHNeer doing system administration, solution architecture and other technically focused jobs.

End-User

A person actively using VSHN products day-to-day.

Prospect

A potential customers.

179.3. Tools We Use

There are various tools we use to document our work:

Antora with AsciiDoc, Documentation as Code.

README files in code repositories (either Markdown or AsciiDoc).

Our VSHN wiki, based on Atlassian Confluence.

179.4. Documentation as Code

We extensively make use of Antora and AsciiDoc. This allows us to store documentation in Git, leveraging all the possibilities it gives us (history, pull/merge requests, automated deployments). All (most) Antora based sites are linked in the knowledge base.

To find the source of a documentation simply click on [Edit this Page] top-right, and it will bring you to the source. The README of the documentation sources have more information about how to work with them.

179.5. Handbook

The VSHN Handbook is the document you are currently reading. It documents how VSHN works and how we at VSHN work. It’s geared towards new employees, it serves the purpose of telling potential new hires about us. But it’s also a reference for active VSHNeers to read about VSHN whenever needed, to help have a self-informed live at any VSHN-day and to document any changes or improvements.

The handbook doesn’t contain any confidential or customer specific information, and is therefore meant to be public.

Handbook vs Wiki

The following table describes the major differences between the Handbook and our Wiki.

Handbook
Wiki

Stability

Stable, carefully reviewed changes

Dynamic, a lot of changes and collaboration

Who is it for

For new and prospective hires, for active VSHNeers: eventually for the public

For active VSHNeers, VSHN customers and VSHN partners

History

yes, via git

yes, via page history

internal content

no

yes

confidential content

no

yes

customer specific content

no

yes

Examples

Your first day at VSHN

How you setup your vshn.ch e-mail address

How Team and Interest Groups work

Team shift scheduling table

What the VSHN Connect is

Meeting notes from the VSHN day

179.6. Confluence Wiki

Internal or confidential information is documented in the Atlassian Confluence VSHN wiki.

If you use Firefox you can add the Confluence and Jira search engine to your "One-Click Search Engines" list by clicking the […] button on the location bar. Then, in about:preferences#search you can assign a keyword to it, for faster searches.

You should take a look at our wiki, and if you find a mistake, an error, or a typo, select the "Edit" button (or just hit the E key) and correct it. We use Confluence as wiki software. Don’t worry of making mistakes, Confluence stores the history of every change, and you can always roll back a previous version of any page if needed.

Customer Spaces

Each VSHN customer gets its own Space in our wiki. Access can be granted for the customer users to access their space.

Space Name: Customer: <customername>

00-OnCall: Contains relevant information for 24x7 on-call engineers. Exists only, if the customer has a 24x7 support SLA

01 Services: Overview over all services we’re operating for the customer with a tight focus on anything the is customized/different from our standard setups and products

<Service A>: Managed GitLab

<Platform B>

DB Servers

Load balancers

Monitoring checks

02 Meeting notes:

<2019–05–10 Meeting bla blah blah> (use meeting notes template!)

03 HowTo articles: No further structure, just single pages per how-to article, use tags!

12 Projects: Running projects (done or closed projects are archived and relevant information moved to How-to articles and Services

13 Incident reports:

<2019–05–10 xyz incident postmortem>

Work Groups

Each VSHN Work Group gets its own wiki space. There is no given structure, do whatever works for you.

Space Name: VSHN <Work Group name> Work Group

Teams

Each VSHN team gets its own wiki space. There is no given structure, do whatever works for you.

Space Name: VSHN <Teamname> Team

Rules

As soon something has value for not only the Team, it must be documented in a "global" Wiki space (or maybe the handbook).

Some examples on what’s a good and a bad idea to keep inside the team space:

Good

How this particular Team works, how to work together

Team shift planning tables and stuff like that

Team internal organization (projects)

Meeting notes (name them <year>-<month>-<day> …​)

Retro notes (name them <year>-<month>-<day> …​)

Bad

How-tos that also have value for other teams (for example, a technical guide on how to setup something)

Workflows that also affect other teams (for example, how we hand over tickets to another team, etc.)

Business

Contains short-lived or frequently updated organizational stuff that doesn’t fit into the Handbook, for example, Meeting notes, current projects, how-to articles

Space Name: VSHN Business

02 Meetings (Meeting notes)

03 How-to articles (should mostly go into Handbook)

12 Projects (non-tech projects, for example, "New Documentation structure")

13 Research

Space Key: VINT

Technical

Contains short-lived or frequently updated organizational stuff that doesn’t fit into the Handbook, for example, Meeting notes, current projects, how-to articles, maintenance logs, Research, etc.

Space Name: VSHN Technical

03 How-to articles

12 Projects (non customer specific tech projects)

13 Research

Maintenance Logs

Space Key: VT

179.7. GitHub & GitLab

Code (Apps, Tools, Ansible playbooks and roles, Puppet profiles and modules, etc.) are documented within the same git project, usually in a README written in Markdown or AsciiDoc.

These projects can also contain an Antora-based documentation under docs/ which is published under a specific domain. For example Commodore components do have their documentation in the docs/ folder and the documentation is available in the Component Hub.

179.8. Jira

Our ticket system is based on Atlassian Jira. There is a whole page in this handbook on How we use Jira.

Regarding documentation, it’s important to say that we document everything related to a specific task, problem or incident directly in the ticket but link related tickets, wiki pages, etc. to the ticket.

For incidents, usually an incident report is written in the wiki based on the information in the ticket gathered during debugging an analysis.

180. Jira

Jira is a very important tool at VSHN. We track everything in Jira, including internal events, trainings, meetings and many other things. Getting used to how Jira works is a very important part of your daily life as a VSHNeer.

Our Jira is available from ticket.vshn.net.

181. Project Management and Planning

We use issue linking to link task and project management together ("blocks" and "blocked by"):

Each customer gets a Jira project called "Customer: NAME," with an ID that’s composed of three or four characters, easily associated to the name.

Project Lead: Customer Account Manager (CAM)

In a Customer Jira Project, there is at least one issue of type "Operations."

This is used for ongoing operations and customer requests, which aren’t tied to a specific project.

A Customer Project is planned in the issue type "Project." There is a "Customer Project" template available, which adds a boilerplate with all information and questions needed.

Real work gets done in one of the shared issue types [Link to Shared Issue Types Page].

If you use Firefox you can add the Jira search engine to your "One-Click Search Engines" list by clicking the […] button on the location bar. Then, in about:preferences#search you can assign a keyword to it, for faster searches.

182. Issue Types for Project Management

A Jira Project (aka Customer) can have one or more "Project"

A Project can have zero or more "Project Milestone" (it really only makes sense to use milestones if there is more than one milestone) and zero or more "Task" and "Chore"

A Project Milestone can have one ore more "Task"

A Operations can have one or more "Task" and "Chore"

Issue Type
Usage
Roles

The container holding different issue types together. Also contains the overall definition of the scope, stakeholders, etc.

When a project has no milestones, this is the flight level on which we plan "VSHN wide" projects and timeline planning

Reporter: The main stakeholder
Assignee: Project Manager

A milestone is a specific point in time within a project lifecycle, used as signal posts for: a project’s start or end date, a need for external review or input, a need for budget checks, submission of a major deliverable, etc. Milestones have a fixed (due) date.

Reporter: The main stakeholder
Assignee: Project Manager

Used to group different categories of work or services on the customer side; not used in project management.

Reporter: Service Manager
Assignee: Service Manager or Technical Service Manager

If you encounter an error in one of VSHN’s own services (Mail, GitLab, etc.) please don’t open a ticket in the VT space, but rather in the VSHNOPS space, and don’t forget to use the corresponding template. This helps the corresponding team (usually Polaris) to solve the issue faster and better.

183. Project states

In use by the following Issue types: Project, Project Milestone

State
Meaning

New

Sales process is completed (Project Initialization) or conditions are set to define a new internal project. The project is being defined.

Backlog

The project is defined but there is no need to plan the project yet, for example: no immediate need, no due-date, focus lies on other projects

In Planning

Project is currently being planned - not work should be done now

On Hold

Project was in progress but is now paused.

Running

Project is running

Review

All task and deliverables are done or handled, and the project is in review (internally or with the customer).

Closed

Project is done. There are no further actions taking place.

184. Project and Operations Reporting

There are some custom fields available which help with Project and Operations reporting.

184.1. Operations and Chores

Field
Usage

Total logged time (h)

Sums all logged work of issue links of type "is blocked by." Or in case of a Chore, all logged time in this Chore

Monthly Budget (h)

Hours which can be spent on this Chore / Operations per month (editable field)

Mt Budget Used (%)

Percentage of "Mt Budget Used (h)" vs. "Monthly Budget (h)" of the current issue

Mt Budget Used (h)

Sums all logged work of issue links of type "is blocked by" from the current month. Or in case of a Chore, all logged time in this Chore from the current month.

Listing 1. JQL Example - Budget more than 90% used

(issuetype = Operations OR issuetype = Chore) AND status = Running AND "Mt Budget Used (%)" >= 90

184.2. Projects

Field
Usage

Work remaining (h)

Sums all remaining estimates of issue links of type "is blocked by" and state not Done

Total logged time (h)

Sums all logged work of issue links of type "is blocked by"

Estimation vs. Actual (%)

Percentage of "Total logged time (h)" vs. Original Estimate of the current issue

Listing 2. JQL Example - Project Estimation at 90% used or more

(issuetype = Project AND status = Running) and "Estimation vs. Actual (%)" >= 90

185. Service Desk Workflow

185.1. Purpose

This article shows how to move work items between issue states on the Service Desk work board, and visualize the work items in the Service Desk workflow.

185.2. General Principles

Abide by the Customer Communication Guidelines when working on customers tickets. Always aim to keep conversations concise and effective. Inform customers proactively of the expected next steps and when those are planned to happen. Close ticket once it’s done. Customer Support tickets are not meant to handle project management work. For bigger requests, projects or big changes, set up project management tasks and attach planned work items to it.

185.3. Service Desk Workflow Diagram

185.4. Service Desk Issue Types

Type
Purpose

Service Request

Customer requests support or a service.
(for bigger requests, an additional change ticket will be created by the VSHN-Team working on it.)

Information Request

Customer requires information on our services and products.

Problem

The customer stumbled upon a problem in his systems or our services to them.

Incident

Customer reported a malfunction or interruption of services. And it needs urgent fixing …​

185.5. Issue States and How to Move Tickets.

In context of the Service Desk.

New

Status definition

NEW is an incoming ticket that has not been triaged.

Open

Status definition

OPEN is a service desk ticket that needs taking care of. Action required.

Move: New to Open

Drag and drop (on board)

Choose transition triage to BlueOPEN on ticket view

Keyboard shortcut . (with ticket selected on board or on ticket view) → write "triage".

Transition Screen: Triage

Choose Issue Type: Service Request, Information Request, Problem or Incident

Assign VSHN-Team: Avior, Sol, Aldebaran, Polaris, Schedar, Vega or Nunki.

Set priority

Submit

Visualization: Triage screen in Servicedesk Kanbanboard

Waiting

Status definition

WAITING is only used when we need an information or reaction from the customer, where we cannot do anything more in this ticket, until the customer has answered. Passive State.

Move: Open to Waiting

Drag and drop

Transition Screen: Waiting

Ticket gets unassigned automatically

Add comment to customer. Be courteous when stating what is needed or when requesting them to do something. Proactively inform them of the next steps. See customer communication guidelines.

Submit.

Automation in Waiting

3 Days Reminder: If the customer does not reply within 3 working days, a comment will be automatically added to remind the customer of our question.

7 Days Closure: If a customer does not react to our comment, question, or request within 7 days, the ticket will be automatically closed with an additional comment to the customer.

Open on comment: If a customer adds a comment, the ticket is automatically transitioned open. This way we know that action is needed from us.

Visualization: Move Open to Waiting in Servicedesk Kanbanboard

Pending

Status definition

PENDING is only used for internal dependencies, as in "ticket suspended for a short time".Expl. Waiting for a specific time slot to activate a piece of code or small update and such things. Also used for a ticket depending on the progress in a different ticket to happen.

Pending is a Passive State – with automated handling, when a ticket is untouched

Move: Open to Pending

Drag and drop

Transition Screen: Pending

Define numbers of days before ticket needs attention again. (1-7)

If a Task needs to wait significantly longer than a week, consider making a new Planned work ticket for that and close the conversation with the customer for now, letting them know the expected timeline for the next steps.

If the ticket is depending on a different ticket, interlink them correctly (causes, waits for, relates to, or by mentioning it in the comment)

Add comment to customer to keep them posted. (not mandatory in this case) See customer communication guidelines

Submit.

Automation in Pending

Delay Timer: after the set number of days, this ticket will be automatically transitioned to open. This way, we know it requires our attention again.

Open on comment: If anyone adds a comment, the ticket is automatically transitioned open. This way, we know it needs our attention again.

Visualization: Move Open to Pending in Servicedesk Kanbanboard

Closed

Status definition

CLOSED is done, won’t do, expired or Duplicate.

For any of these reasons, there is nothing more to do in this ticket. We never close a ticket without a comment on why and what has been done.

Done

We did it.

Won’t do

there is a reason not to do this, and this reason has been communicated.

Expired

Ticket where a customer did not reply within a week. (can be reopened within 7 more days)

Duplicate

this might happen if we open a ticket for an incident and the customer does so too.

Move: Open to Closed

Drag and drop

Transition Screen: Pending

Set resolution

If the ticket is relating to a different ticket, interlink them correctly. Not mandatory.

Add comment to inform customer what was done and how it was resolved. Or why we are closing a ticket, even if it’s not done.

Submit.

Automation in Closed

Ticket gets reopened, if customer replies to it within 7 days.

A follow-up ticket will be created, if the customer replies to a closed ticket after more than 7 days.

Visualization: Move Open to Closed in Servicedesk Kanbanboard

185.6. Customer Portal Rules

In this workflow, where we concentrate on short-lived customer request, customer can close any of their tickets in any state, when they see a ticket as done or obsolete. When customer closes a ticket in control.vshn.net they have the possibility to leave a satisfactionrating (1-5 Stars).

Tickets that have received a Satisfaction rating will be displayed under this filter query:

_updated > -60d AND "Customer Satisfaction" is not EMPTY ORDER BY updated DESC_

186. E-mail

E-mail is an important tool of communication, even though in VSHN it’s primarily geared towards "the outside world;" internally we prefer using our chat system. We do however use our calendars extensively, and usually every team has its own calendar exposed, so you can be notified of meetings and special events.

186.1. Webmail

We use SOGo Groupware as our mail and calendar provider. You can use the web interface to read your mail and browse calendars. * Your username is firstname.lastname

186.2. Using an e-mail client

You can use your preferred mail client as well.

Recommended e-mail clients

Linux:

Thunderbird with Lightning

www.betterbird.eu/ (fine tuned version of Thunderbird that fixes multiple annoying bugs)

Evolution

Mac:

Apple Mail

Airmail

Windows:

MS Outlook via ActiveSync

Android:

K-9 Mail and DAVx⁵ (CalDAV and CardDAV sync)

Outlook via ActiveSync.

iOS:

Default Mail & Calendar apps

Outlook via ActiveSync

Setup

These are the settings you need for that:

Your email address is firstname.lastname@vshn.ch

Your username is firstname.lastname@vshn.net

IMAP (receiving): imap.vshn.net, SSL/TLS on port 993

SMTP (sending): smtp.vshn.net, STARTTLS on port 587 (requires authentication)

In Evolution, in the Account Editor, select "Server requires authentication" and then select "Login" as the type of the authentication. You will be prompted for your password on first connection.

Create a GPG key and publish it to a key server.

You can perform these steps with GPG Suite on the Mac. And of course you can use your keys with Evolution instead of Thunderbird.

Note: In the past Enigmail was recommended for Thunderbird/Betterbird but OpenPGP is now supported out of the box so Enigmail is end of life and no longer needed. Simply use the inbuilt tool to generate a new key or to import an existing one.

186.3. E-mail signature

The official email signature of VSHN looks like this:

--
Firstname Lastname
Title according to homepage or business card

VSHN AG | Neugasse 10 | CH-8005 Zürich
T: +41 44 545 53 00 | M: +41 XX XXX XX XX | https://vshn.ch

At the beginning: two hyphens and a space.

Only give your cell phone number if you want.

Signature in SOGo

Please define the signature also in the SOGo webmail (without the 2 hyphens "--"). It’s a plain-text signature.

After you have logged in, select the "Settings" wheel to the right of your name.

Click on "E-Mail" in the "Settings" menu on the left.

Select the menu item "IMAP Accounts" on the right.

Select the mail for which you want to create the signature.

Use the pen on the right to edit the settings.

In the lower area you can enter the signature.

Confirm with [OK].

After confirming with OK click on the save icon in the upper right corner of the menu. Only then the process is finished.

186.4. Default e-mail address

Your email address has many aliases available. To choose your default email address, follow these steps.

Click on the preferences icon (top-right, next to the name).

Click on Mail.

Click on IMAP Accounts.

Click on the edit icon.

Type in your default E-Mail address (firstname.lastname@vshn.ch) in the field "Email."

Click on [OK].

Click on the save icon on the top right.

186.5. Out of office replies

Before going on holiday (or any other prolonged absence) please set up your e-mail with the proper out of office message in the web interface:

Click on the preferences icon (top-left, right next to the name)

Select menu::Mail[Vacation]

Click on "Enable vacation auto reply"

Fill in the fields with the following text:

Hi,
Thank you for your message.
I'm on holiday and will be back on DAY, DATE. If your request is urgent, please send it to support@vshn.ch
Best regards,
[YOUR NAME]
--
[YOUR SIGNATURE]

Finally, remember to click on the save icon on the top right.

There is a whole section in this handbook about absences and holidays handover, make sure to read it too!

186.6. E-mail filters

The mail filters defined in the web interface won’t be migrated automatically to your client, and they need to be created from scratch.

In Thunderbird, follow these instructions:

Click on the preferences icon (top-left, right next to the name)

Click on Mail

Click on Filters

Create your filters as you like

Hint: They’re disabled by default

Enable the filters with a tick

Click on the save icon on the top right

186.7. Address book sync for local email clients (like Thunderbird)

If you also want to have your personal and the global VSHN address books synced from Sogo to your local email client then this can be done via CardDAV.

Technical documentation for how to do this can be found on the VSHN Wiki.

187. Calendar

SOGo calendars are an important tool for collaboration with your team members.

Some info remains in our wiki: SOGo - Share Calendar

187.1. Share your Personal Calendar

Your personal calendar must be visible for your peers to see; this way they can tell where you are at any given moment. These are the steps to do share your personal calendar.

Click on the "⋮ < Sharing…" menu next to your calendar. Mind that you have to scroll in the context menu.

Choose "Any Authenticated User"–all SOGo users will have access to this calendar.

Public: "View All"

Confidential: "View the Date & Time"

Private: None

Choose "Public Access" and set all to none if there isn’t a really good reason somebody unauthenticated should access your calendar.

Public: None

Confidential: None

Private: None

187.2. Shared Calendars in SOGo

In SOGo’s calendar view, you’ll find a "Subscriptions" section in your sidebar. Click on the round "+" sign to search for a shared calendar.

Popular shared calendars:

VSHN Company

VSHN Events

Internal Education

Interest Groups

Meeting rooms

VSHN Tower

VSHN Meeting Room

VSHN Entrance

Personal calendars of your colleagues

Rename the calendar with the 3 dots, not via properties, so it will be ordered alphabetically after renaming.

187.3. Create Recurring Meetings for Work/Interest Groups

Use Interest Groups to send invites for recurring meetings for interest groups. For that, we can do changes to recurring meetings even though the original organizer is unavailable.

Add the calendar in SOGo like in the pic below:

After that create the appointment with that calendar via sogo.vshn.net(SOGo in the web browser).

187.4. Clients for Calendar

You are free to use your local calendar client. People are using Evolution and Thunderbird, and we are using most probably a ton of other clients.

Below you’ll find some tips for different clients.

Access your Calendars from Evolution

If you use GNOME Evolution you can access your SOGo calendars following these steps.

In SOGo, click on the "⋮ < Links to this Calendar" menu next to your calendar. Copy the first field, labeled "CalDAV URL" to your clipboard.

Open the Edit < Accounts dialog box.

Click the [Add] button and select the "Calendar" option.

Select the "CalDAV" type.

Enter the URL copied in the previous step.

Enter your username in the "User" field.

Click the [Find Calendars] button.

You will be asked for your password. Enter it and a list of possible calendars will appear. Select the one you want, choose a color and a name for it, and click [OK] to close the dialogs.

The same procedure applies to contacts (using CardDAV) and task lists (using CalDAV).

Access your Calendars from Thunderbird

Go to Thunderbird Calendar and click on +

Choose "on the network"

In SOGo, click on the "⋮ < Links to this Calendar" menu next to your calendar. Copy the second field, labeled "WebDAV ICS URL" to your clipboard.

Paste the personal.ics link from above in and your username.

Click on the calendars you want to join and click subscribe.

Access your Calendars from Outlook

Download the CalDavSynchronizer

After downloading the synchronizer you need to unzip the folder

Run the Setup.exe

Restart Outlook

After starting Outlook you should see a menu called "CalDav Synchronizer"

Click on the menu and click "Synchronization Profiles"

It will open a window called "Options"

Click on the green "+" symbol

Choose SOGo as your profile type

Click on "Advanced Setting" and fill in your personal information

You can get the DAV URL from SOGo if you click on the three points next to your calendar and after that click "Links to this Calendar"

Copy the second link

After finishing the Profile click Synchronize now

Access your Calendars from macOS Calendar

You have to unsubscribe from all your calendars in SOGo first, otherwise you probably cannot connect with MacOS.

Start macOS Calendar and open the Settings (Command + ,)

Choose "Accounts" in the top bar

Hit the + button and choose "other CalDAV Account…​"

Enter your E-Mail Address ending with the .net and your password

If this does not work, you can choose the account type Advanced and enter the following settings.

Access your Calendars from iOS

Unsubscribe from all except your own calendar in sogo.vshn.net web client or else the phone gets overwhelmed and will not sync.

Go to the iOS Settings App

Go to Calendar → Accounts → Add Account → Other → Add CalDAV Account

Add the following settings

Server: sogo.vshn.net

Username: firstname.surname

Password: you know this part

Description: whatever you choose

Bonus: Holiday Calendar

If you want to add a calendar with the official holidays in Zurich, add a new calendar of type "On The Web" with the following URL: fcal.ch/privat/fcal_holidays.ics.php?hl=de&klasse=3&geo=3055.

188. Git guidelines

How we use Git, the distributed version control system (DVCS).

188.1. Commit messages

The seven rules of a great Git commit message

Separate subject from body with a blank line

Limit the subject line to 50 characters

Capitalize the subject line

Do not end the subject line with a period

Use the imperative mood in the subject line

Wrap the body at 72 characters

Use the body to explain what and why vs. how

Source: chris.beams.io/posts/git-commit/ (with more details)

Commit message subject

A properly formed Git commit subject line should always be able to complete the sentence "If applied, this commit will <subject>", doesn’t end with punctuation and the first letter is capitalized.

Commit message body

Reference tickets, issues, commits, tags, versions and pull requests where applicable. Our commit messages should look like this:

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to at most 72
characters. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit's solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: CUST-123
See also: commit 00abc123, CUST-789

188.2. Git Usage Basics

git config

git clone

git remote

git branch

git rebase

git add

git commit

git tag

git status

git push

git reset

git log

git reflog

Example configuration

git config --global diff.color auto
git config --global color.interactive auto
git config --global color.status auto
git config --global color.ui auto
git config --global --bool merge.log 1
git config --global branch.autosetuprebase always
git config --global push.default tracking
git config --global format.thread shallow
git config --global --bool grep.lineNumber 1
git config --global --bool rebase.stat 1
git config --global --bool commit.verbose 1

git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.st status
git config --global alias.cp cherry-pick
git config --global alias.wdiff 'diff --color-words'
git config --global alias.wshow 'show --color-words'

Example workflow

git clone git@git.vshn.net:vshn/handbook.git
git remote rename origin vshn

# add additional remote (optional) and pull in changes
git remote add github https://github.com/vshn/handbook.git
git pull github master
git push

# create a new branch for some changes
git checkout -b feature/add-git-guide-chapter
# (change or add some files)
git add -v .
git status
git commit -m 'Add new section'

# ooops, we made a mistake! Now update our last commit:
git commit -m 'Add new subsection' --amend
git push -u vshn feature/add-git-guide-chapter
# we added a new branch, let's double-check
git branch --remote

# after creating and merging a PR or MR, delete the branch
git checkout master
git pull
git branch -d feature/add-git-guide-chapter
git branch

git tag
git tag 1.0.0
git push --tags

188.3. Tools

CLI enhancements

git-extras

TUI tools

tig

Graphical tools

gitk --all

git citool

189. GitLab

GitLab is our central source code management tool. It’s the place where we keep all our tools, puppet modules, or hiera configs.

INFO: To learn more about how we use Git, consult the Git Guidelines in the Wiki.

Given the complexity of code and its required levels of quality, we’ve implemented several measures to manage it.

189.1. Merge Requests

If not explicitly stated otherwise, a project will use GitHub flow. In GitHub flow, every new feature or bug gets its own branch.

We merge according to the four eyes principle, meaning that another person has to review and merge your merge request.

189.2. CI/CD

CI/CD is an integral part of the DevOps philosophy. Projects we create should have a CI/CD pipeline to ensure short release cycles with fast, frequent and safe deployment of changes.

189.3. Pet Projects

We encourage pet projects at VSHN if you think they bring value to all of us.

As an engineer you might write scripts to simplify your work, to help you be more productive, or you just have a silly idea that could be fun or otherwise useful. If you think it will save you (us!) time in the long run, it’s probably a good idea.

We encourage you to put them under version control, public or on our GitLab. Also tell others about it and mention your project on this wiki page.

Sharing your experience through code allows everybody to learn and use it.

As always, please try to keep the time investment in balance with your work achievements. If it’s something like a toilet sensor, it’s okay to invest one to two hours initially (if your workload permits), but your work shouldn’t be impacted.

190. Working with GnuPG

GnuPG, the GNU Privacy Guard is a complete implementation of the OpenPGP standard. It allows you to generate and manage your own GnuPG key, and is tightly integrated to many e-mail clients, libraries, and many other applications.

Ubuntu 18.04 includes both gpg and gpg2. However, Evolution and the "Password and Keys" app (also known as "seahorse") only work with gpg2.

190.1. Create Key

The following command will guide you though the process of creating a new key:

gpg2 --full-generate-key

If gpg2 command does not work, try with gpg

gpg --full-generate-key

Follow the instructions and set a limited duration for the new key, for example one or two years. And remember the password!

Check Key Fingerprint

Use the following command:

gpg2 --fingerprint firstname.lastname@vshn.ch

For most practical purposes, the fingerprint can be thought of as the last four hexadecimal characters of the output.

190.2. Send to Server

Submit your public key so that others can find you:

gpg2 --send-keys ABCDEF10

190.3. Import Keys from Other Users

You can find the keys corresponding to your colleagues with this command:

gpg2 --search email@address

Once found, use the gpg2 --recv-keys ABCDEF01 command to add it to your keychain.

190.4. Exporting Keys for Backup

You should export your key and store it safely, for example in your password manager.

List your keys:

gpg2 --list-keys

Export your keys as follows:

gpg2 --output mygpgkey_pub.gpg --armor --export ABCDFE01
gpg2 --output mygpgkey_sec.gpg --armor --export-secret-key ABCDFE01

This also works:

gpg2 --armor --export you@example.com > mykey.asc

or

gpg --export-secret-key [last 8 digits of your fingerprint] > ~/my-key.asc

The resulting file can be safely imported into other applications, for example ProtonMail or GitLab.

190.5. Using your Key

Check these related pages for more information about how to use your newly created key:

Evolution Mail

GitLab

190.6. More Information

How-To: Import/Export GPG key pair

191. GnuPG and Evolution

Using your GnuPG key on Evolution requires the following steps.

191.1. Setup GnuPG in Evolution

Go to Preferences/Accounts and select your e-mail account. Then click on the "Security" section. The Key ID is the 8 last characters (or more) of the fingerprint seen above.

Clicking the "always trust keys in my keyring" option will allow Evolution to use the keys in your keyring even if they’re not trusted. If you would rather trust keys one by one, follow the instructions in the following section.

191.2. Importing and Trusting Keys from Other Users

You can find the keys corresponding to your colleagues with this command:

gpg2 --search email@address`

Once found, use the gpg2 --recv-keys ABCDEF01 command to add it to your keychain.

If desired, raise its trust level to "Ultimate":

gpg2 --edit-key ABCDEF01 and then type the trust command, selecting option 5 to trust it "ultimately."

If a key isn’t "ultimately" trusted and the "always trust keys in my keyring" isn’t selected, Evolution won’t use the key and you won’t be able to encrypt your messages.

191.3. More Information

How to Enable PGP Encryption in Evolution

Using GPG with Evolution - Fedora Project Wiki

192. GnuPG and GitLab

You can use your newly created key in GitLab very easily.

Export your GnuPG key as explained in the main document:

gpg2 --armor --export [KEY_ID] | xclip -selection clipboard

In your GitLab GPG Keys settings paste the contents of the public key and hit the [Add key] button.

Configure your local git installation:

git config --global user.signingkey [KEY_ID]

git config --global gpg.program gpg2

Use the -S switch to sign your commit:

git commit -S -m "Some changes"

Run the git config --global commit.gpgsign true command to sign all commits by default.

You should see your commits appearing as "Verified" on GitLab.

Make sure your GitLab profile page shows the "commit email" to be the same as the one you used for your key! Otherwise your commits will stay unverified.

193. Nextcloud

We use Nextcloud to share files across the company. You can access it with any web browser by following this link.

The main Nextcloud folder can also be opened on GNOME (as a server on "other location") and as a share on Mac and Windows using the following URL:

davs://files.vshn.net/remote.php/webdav/

You can also sync folders to your laptop for offline access using the official clients.

194. Merge Request Template

This document contains a template document which can be used for providing the required context to your Merge Requests (MRs).

You can find this file in this very same repository, in this location: .gitlab/merge_request_templates/merge_requests.md

What does this MR do?

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Types of changes

Bug fix (non-breaking change which fixes an issue)

New feature (non-breaking change which adds functionality)

Refactoring (non-breaking change which adds no functionality)

Infrastructure (change which affects containers or pipeline, linters, tests)

Breaking change (fix or feature that would cause existing functionality to change)

Screenshots (if relevant)

Make sure that you’ve checked the boxes below before you submit MR

My code follows the style guidelines of this project

I have performed a self-review of my own code

I have commented my code, particularly in hard-to-understand areas

I have made corresponding changes to the documentation. (Readme, Wiki, SAD, Domain Model)

My changes generate no new warnings

This is a Bugfix, new Feature or a Refactoring

I have added tests that prove my fix is effective or that my feature works. If not, I created a comment explaining why no tests are needed.

New and existing unit tests pass locally with my changes

Status

Ready for Review

Does this MR meet the acceptance criteria? (Checklist for reviewer)

Conforms to the style guides (black, flake8, pydocstyle)

README updated, if necessary

Tests added for this feature/bug. If no Tests were added, the MR creater given a good reason as a comment.

Pipeline Passes

If you have multiple commits, please combine them into a few logically organized commits by squashing them

What are the relevant issue numbers?

Please include any relevants issue numbers with your request here.

195. Chat Channels

This page provides some information about the various chat channels we use every day.

Some of these channels are mandatory for all VSHNeers!

Questions
Answers

Which channels to be in?

There are a few channels which are mandatory for every VSHNeer (#general & #announcements). The other channels are semi mandatory (every VSHNeer has to be a member of his own Teamchannel) and some which are on a voluntary basis.

How and when to create a channel? Mandatory things for a channel to exists (for example: good description, topic, etc.)

Fill in a precise Room topic: What’s this channel used for, who should be part of it’s discussion allowed or not.

How to have discussions in channels? (use threads)

Threads
Will exist on the same channel. They add the parent message property to the messages, so they can be displayed on the sidebar. They’re used to just answer a short question or input. For longer conversations it might be better to use the discussion button.

Discussions
Are basically new sub channels that inherit permission from the parent channel and have its creation announced on the parent channel. Usually, a discussion is being created to discuss something with a goal. Once this goal has been achieved, the discussion is going to be deserted. Semantically, it’s "done."

How to approach people in chat?

Typing is much slower than talking, so don’t just say hi and wait to state your question, instead write the full question upfront.

→ It doesn’t mean that you don’t have to follow basic courtesy rules, but jumping into the question directly and give your chatpartner the possibility to answer your question even when you aren’t there anymore. This asynchronus conversations saves you a lot of time.

Complicated issues, for which you have to write a longer text, have no place in chat. Especially if there are several attachments. The messages in the chat can’t be sorted away like an e-mail and it’s pointless to find the files again later. Better write a mail with a proper subject.

Customers in our chat, how they get access, why not to invite them into VSHN channels, etc

Please check this page in the wiki.

195.1. Specification

Channel
Mandatory for VSHNeers
Long story short

VSHN Chat

yes, during logged attendance time

Means:

be online

or offline but check every few hours

#announcements

yes, during logged attendance time

VSHN wide read only announcements. Mandatory for every VSHNeer

#general

yes, during logged attendance time

transitory announcements like visitors, doodles, recruiting interviews, etc

#virtual-presence

no

Daily announcements about attendences

#off-topic

no

Topics / Links with no direct relation to work but interesting for VSHNeers

#technical

yes, for tech people

#link-dump

no

link things you want to share with other vshneers

#goodnews

no

announcements of good news, articles, blogposts from inside and outside the Vshn universe

#documentation-ig

yes, for Interest Group members

discussions about documentation in wiki, handbook etc are held here

#meetups

no

information about all kind of meetups

#OfficeMgmt

yes, for Interest Group members

Topics around our physical office

#orgdev-wg

yes, for Interest Group members

Discussions about organisation developement

#recruiting-wg

yes, for Interest Group members

Notice the recrutingpipeline and find Interest Group people for talks

Teamchannels

yes, for team members

Channel for team specific topics

Customerchannels

yes, for team members

Channel for topics attached to Customer X

196. Zoom Phone

At VSHN we use Zoom Phone as our official phone system. This page contains all the information you need to get it up and running.

196.1. Installation

Download the zoom client (for Windows, macOS, and various Linux flavors), the same client also used for videoconferencing.

For Windows and macOS there are automatic updates configurable; enable them.

Log in with your VSHN email address and password.

Notify the Sol team if you need a phone license.

The most common need for a zoom license is when you need to schedule meetings longer than 40 minutes, which is the default length for Zoom calls.

For mobile phones, you can download the clients for iOS and Android.

196.2. How to use

Make sure your Zoom client is always open. The easiest way is to make it start automatically when your computer starts.

Open the client

Click on the [Phone] tab button (or on [Telefon] if your application is running in German)

On the left side you can see your call history and the voicemail inbox.

On the right side you can enter a phone number. You can also enter a name–it pops up when you have it in your address book.

On the right side at the bottom you can see your Caller ID. This is your internal phone number, and it’s visible to customers. Usually it’s the office number.

You can also change your ID opening the dropdown next to the Caller ID.

On the right side you can see your own number (804 for example). This number VSHN can use to transfer calls to you directly.

In a call

You have different options in a call:

You can mute yourself;

You can add someone to a call;

You can hold the call;

You can transfer the call to another VSHNeer;

You can choose to speak with this other VSHNeer before you transfer the call: please do it! Then transfer the call just by clicking the [End Transmission] button.

Please be aware that if you are transferred a call from a colleague, the name of that colleague will be visible during the call. This is normal, even if you aren’t speaking to that person anymore.

Finally, you can upgrade the call to a Zoom Video meeting.

After a call

You can see the list of all previous calls.

When you hover over any call, 3 dots appear: if you click on them you will see another menu with even more options.

You can block callers, but don’t do this for customers!

Incoming calls

When someone calls you, a pop-up appears. You can accept the call by clicking on [Accept].

If a VSHNeer forwards you a call and you pick up, he can tell you who is on the line. As soon as the call from the other side (VSHN) is ended you have the customer on the line. 10. Attention: There is no sound when the VSHNeer has handed over, the customer is directly connected to you. Say "hello customer here is .."

Using Zoom Phone from mobile devices

The app works very similarly to the one for your computer, but it looks slightly different. You can use the mobile application to make calls with the office number, wherever you are.

196.3. Process

196.4. Call Queue Handling

To change the people in a call queue, please follow these steps.

Go to vshn.zoom.us

Sign In

Go to Phone System Management

Go to Call Queues

Choose the "Main" Queue

Under the Section "Member(s)" click "View or Edit"

With "Add Members" You can add new members to the queue

Make sure the member(s) you want to remove isn’t Manager of the Queue

If he is, click "Set as Manager" behind someone else

Mark the member(s) you want to remove

Click "Remove"

196.5. TipTel

TipTel is responsible for the telephone service of the main number. They take calls and forward them to the person you are looking for. If the person you’re looking for is not available, they will receive a notification via e-mail. So please don’t be surprised, if an external person wants to transfer a call to you.

Calls are forwarded from +41 44 200 90 86.

Technical requests are forwarded to the technical support number. The support call queue should still be filled with engineers doing first ops; this has not changed.

If you have questions ask Office Management for help.

196.6. Virtual Backgrounds

You can find some virtual backgrounds in our brand guide.

196.7. Tips and Tricks

Please contact the following people for all matters regarding the Zoom Phone system:

Matthias Indermühle

Aarno Aukia

Corporate IT Work Group

For internal calls, between VSHNeers, use standard Zoom meetings instead of Zoom phone calls. The only exception to this rule is when transferring calls to another VSHNeer.

Check the How to Answer Phone Calls page for more tips and tricks.

197. Password Tools

At VSHN we use Passbolt as password manager for company used passwords.

For your personal passwords you use for your daily work, Corporate IT recommend Bitwarden or any other password manager on the list.

198. Passbolt

At VSHN we use Passbolt as our official password manager. This page contains all the information you need to get it up and running.

198.1. Installation

To be able to install Passbolt, you will need an invitation, please ask in #Corporate-IT.

Once you receive an invitation to join, follow the link and install the browser addon. Note: Unfortunately, there isn’t a browser addon for Safari yet, so please use Chrome or Firefox.

Make sure to keep the private key that Passbolt gives to you during the set up, you will need this if you ever change browser or computer.

You can only have one browser configured for Passbolt at any one time. If you change browser or computer, it will make you go through the account recovery process, for which you need your private key and your password. There is no way to reset your password or to get your private key back. If you have lost either of these, your account will need to be deleted and re-created.

198.2. How to use

Passbolt is similar to other password managers in that it uses a browser plugin to allow you to input credentials into forms without ever even seeing the password. You can also search for passwords directly from the addon, or you an use the web interface by logging in here: cloud.passbolt.com/vshn/. There is also a redirect from passbolt.vshn.net to this.

198.3. Process

Passbolt does not allow administrators to add users to groups before they have activated their account. This means that your account will need to be added to the relevant groups in the admin interface after you have activated your account.

198.4. Finding file attachments

Unfortunately, Passbolt does not support file attachments to passwords yet, it is in their roadmap for 2022. Text files have been stored in the encrypted description field of passwords and picture files have been stored in NextCloud, with links put in the password description field.

198.5. FAQ

Can I use Passbolt in two separate browsers?

No, it is only possible to use Passbolt in one browser, on one machine. If you try to use it on a second one, it will take you through the account recovery and you will not be able to use it in the first one.

Can I use Passbolt with my Mac?

Yes, but not on Safari.

Can I use Passbolt to save my personal passwords?

Yes, but be aware that if you do not share them with anyone else (in a group for example), then if you lose access to your Passbolt account, those passwords are lost forever.

199. Passbolt User Documentation

199.1. How can I connect to Passbolt?

You can log in to Passbolt at the following address: https://cloud.passbolt.com/vshn/

For easier redirects, you can also use:

https://passbolt.vshn.net

https://vs.hn/passbolt

199.2. What is Passbolt?

Passbolt is a password manager based on VSHN and has been in use since December 2021.

It’s the way VSHN employees securely share passwords and secrets with each other.

Passbolt is hosted by Passbolt on their cloud services in Luxembourg. The URL to access it is: https://cloud.passbolt.com/vshn/

199.3. How do VSHNeers get access to Passbolt?

The Passbolt Administrator adds VSHNeers with their @vshn.net email address. VSHNeer receives an email invitation. If you haven’t received an invitation, please inquire in the #Corporate-IT chat channel.

Steps:

Click on the invitation link you received from the Administrator (use Firefox or a Chromium-based browser; other browsers work, but Safari does not).

You’ll be prompted to download the extension and add it to your browser.

After installing the extension, you’ll be redirected to the "Welcome page." Click "Next."

Set your passphrase (Use a new password you’ve never used before; you can generate one, for example, with "Generate a Rememberable Password").

Download the recovery kit named "passbolt-recovery-kit.txt" and save it to your home folder on your laptop (with an encrypted hard disk).

Click "Download" again if you haven’t already.

Save it securely on your laptop.

Choose a color and three characters. These will be displayed when your passphrase is requested, helping you verify that the form is from Passbolt and protect against phishing attacks.

Add your password and recovery kit to your personal password manager

This is important if you need to set up Passbolt on a new browser. Without the recovery kit, your Passbolt account will have to be deleted and recreated.

The recovery kit looks something like:

-----BEGIN PGP PRIVATE KEY BLOCK-----

xcTGBGMYTTMBDACljeYGScSf33dL66+s8OcQdG+2qH0zJtQZl8UXTfS0ZiMe
PO/G5s55SOW8/rPY1UJPn49TF4E+SJDFOVjh68P8Dezx23c5l/BaaE/m/zHc
WCbTsJvW7+Zp4FE6zSbxlTD1j9BYWoBbb/ysJBoxA38SkeJby/lgqCzSPyvm
Kfbgeoe3n57zoD+SswC3Tdl8OP08/DKsJTMndHST2mji61LnO1RHlfXT33oT

-----END PGP PRIVATE KEY BLOCK-----

Ask an Administrator in #Corporate-IT to add you to the correct groups.

199.4. How do I use Passbolt?

Click on the Passbolt Extension in your browser:

Check if the 3-character token (for example, "DRZ") and the color match the ones you initially chose. If they do, enter your password.

Check "Remember until I log out."

You can now search for passwords.

If you click in the top left corner, "cloud.passbolt.com/vshn" will open with the password. There are descriptions within it.

If you have any trouble using it, please ask an Administrator in the #Corporate-IT channel.

199.5. How to Add a Password

Go to https://cloud.passbolt.com/vshn/app/passwords

Select the folder where you want to store the password.

See Passbolt Admin page in our wiki to see how our groups and folder are structured.

Click on "+Create."

Add all the information for the password and click "Create."

199.6. How to Use on a Second Browser/Computer

Follow the instructions at https://help.passbolt.com/faq/start/account-recover

Prerequisites:

You have an active account → Check if you can log in to https://cloud.passbolt.com/vshn/.

You have your recovery kit, which contains a copy of the private key associated with your account → You should have stored it in your personal password manager during your first login if you followed "How do VSHNeers get access to Passbolt?" in step 7 above. Alternatively, you can restore it as documented in "How to Get the Private Key to Restore the Account" below.

You remember your passphrase → Check if you can log in to https://cloud.passbolt.com/vshn/.

Steps:

Go to https://cloud.passbolt.com/vshn/recover

Log in with your @vshn.net address.

Follow the link in your mailbox.

Follow the recovery steps, which are much like the initial setup. You will need to import your private key.

Enter your passphrase to log in!

199.7. Things Missing from Passbolt

Currently, Passbolt does not support file attachments to passwords. These are currently still stored in Rattic but will be migrated as follows:

Picture attachments will be stored in NextCloud. This is also considered secure storage.

Text file attachments will be copied to the description field in Passbolt. This is also stored encrypted.

200. Recommended Password Managers

The following password managers are recommended:

Bitwarden (recommended by Corporate IT)

Enpass

Keepass (and its forks)

Lastpass

Mac Keychain

pass (also gopass)

1Password

Suggestions for additional password managers may be directed to the CISO.

201. Generate a Password

It is recommended to generate a password instead of trying to think yourself about a good password. Use the ways below to generate a password.

201.1. pwgen

Generate a password with pwgen. According to NIST recommendations 800-63-3 at least 8 characters are recommended; the longer the better. In our Acceptable Use Policy we define a minimum of 12 characters.

Example to generate a 12-character password:

# 12 chars with special character (relatively easy to remember) and `-y` for at least one special character
pwgen 12 -1 -y

# 12 chars with special character, 'completely random' (`-s`) and `-y` for at least one special character
# most secure way (according to https://www.starlab.io/blog/why-enforced-password-complexity-is-worse-for-security-and-what-to-do-about-it ) but copy paste from terminal not that easy
pwgen -y -s 12 1

# Example to generate a password for disk encryption:
pwgen 32 -1 -s

If you want to exclude ambiguous characters, you can use -B. This is also known as Base58, without Il0O, see de.wikipedia.org/wiki/Base58

pwgen 12 -1 -s -B

201.2. Generate a Memorable Password

If you want to generate a password that is memorable, then you could use the XKCD password generator. The relevant XKCD comic is number 936.

How to generate such a password:

Install XKCD-Password-Generator (github.com/redacted/XKCD-password-generator)

pip3 install --user xkcdpass
# or for homebrew/linuxbrew
pip3 install xkcdpass

Optional: Download the German word list: wordlist-german.txt. This word list is based on a German diceware wordlist from world.std.com/~reinhold/diceware_german.txt without numbers and symbols. It consists of 7536 words.

An alternative word list with only nouns wordlist-German-Nouns.txt consisting of 66225 words.

Generate a password with:

$ xkcdpass
struggle stencil doily unmindful pureness swiftly

# with the german wordlist
$ xkcdpass -w wordlist-german.txt
muendig suchte irrweg erstes duengt schule

# create password with first letter upper case and dashes instead of space for direct copy paste
$ xkcdpass -n5 --case first -w wordlist-german.txt --delimiter="-"
Ungarn-Stutzer-Hammeln-Herdes-Polaris

Now you have to remember these 6 words. Bonus for adding your preferred special character to separate the words.

Entropy Calculations

If an attacker has your hash and knows about how your password was generated, then you could calculate the entropy like that:

There are 7536 possible words

Entropy per word is log2(7536) ≃ 12.88 bits

Entropy for a 6 word password: 6 * log2(7536) ≃ 77.3 bits

According to www.pleacher.com/mp/mlessons/algebra/entropy.html, a password above 60bits of entropy is strong:

Password strength is determined with this chart:

< 28 bits = Very Weak; might keep out family members

28 - 35 bits = Weak; should keep out most people, often good for desktop login passwords

36 - 59 bits = Reasonable; fairly secure passwords for network and company passwords

60 - 127 bits = Strong; can be good for guarding financial information

128+ bits = Very Strong; often overkill

~ David Pleacher

If the attacker does not know your way to generate a password, but correctly assumes you have a lower case password (26 possibilities), then the entropy would be:

26 possible characters (all lower letters)

37 characters used in password:

Entropy: log2(26)*37 ≃ 174

201.3. Password Generator of Your PW Manager

Password managers usually have a password generator, you could use that.

201.4. Check Your Password

NIST recommends to prove whether the password ever was part of a security breach and is already known. There is an API to check already known password hashes at haveibeenpwned.com/API/v2 and the full hash list is downloadable from haveibeenpwned.com/Passwords. A small bash script to check if your password ever was used and in a password leak can be found in github.com/chloesoe/pwcheck/blob/master/password-check.sh.

202. Videoconferencing Guidelines

We use Zoom as our default videoconferencing system. The rules below apply for other similar tools too, even though they mostly focus on Zoom.

This page defines general etiquette guidelines for joining meetings, and important security configurations and rules.

202.1. Etiquette

Consider if video chats are really the most efficient option. Sometimes sharing a Confluence wiki page, starting a Discourse thread, or having a conversation over chat are enough. Limit video calls to those that are really necessary.

In the Zoom settings, select the following options:

Video: "Turn off my video when joining meeting"

Audio: "Mute my microphone when joining a meeting"

Test your webcam and microphone before joining meetings. Sometimes plugging and unplugging them, or just rebooting your laptop, might change the selected device.

Beware of microphone feedback loops if you aren’t using headphones.

Turning on the camera is optional. Cameras don’t always have to be on throughout each meeting.

In particular, if your network connection is poor, try turning the camera off first.

Turn off your microphone if you aren’t actively participating in a conversation. This will avoid ambient noises slipping into the meeting.

Having your screen off to the side, instead of straight ahead, could also help your concentration, particularly in group meetings.

Take time at the beginning of meetings to catch up before diving into business.

Have a break in between video meetings: try stretching, having a drink or doing a bit of exercise.

Plan a few five minute breaks for calls longer than one hour.

202.2. Security

When using Zoom follow these rules:

Regularly update your Zoom client (check for updates in menu "About")

Stay cautious when sharing Zoom URLs, especially if the password is embedded or access control isn’t in use.

Use your vshn.ch address for your Zoom account.

Avoid Zoom for confidential ("VERTRAULICH") content.

Don’t share recordings of non-public meetings without access control.

General security rules for creating meetings:

Don’t use your personal meeting id for external meetings, create new meetings ad-hoc as needed.

For VSHN internal meetings:

use access control settings to restrict the meeting to VSHNeers.

For external meetings:

Protect the meeting with a password.

Consider using the waiting room.

Consider locking the meeting after all participants have joined.

Consider using "Only authenticated users can join" access control.

For your personal meeting room:

Activate the waiting room so you have the admit participants individually.

202.3. Sources

The following resources provide more information about the subject:

Kubernetes community Zoom guidelines

TidBITS article about all Zoom flaws so far.

Zoom docu in our Wiki

203. VSHN Corporate Services Strategy

This page defines high-level requirements to a tool or service to align the decision when evaluating a (new) tool or service for VSHN corporate. This will help to focus on defining the detailed requirements to a tool or service, not having to define the high-level requirements again and again.

203.1. Important points

We see the following points important when doing an evaluation for a new VSHN corporate tool or service:

When VSHN provides it as a service, we use the service managed by ourselves ("Eat our own dogfood")

We don’t run it ourselves if it isn’t related to our core business (Get it as SaaS)

End user support must be provided by the company providing the service

203.2. Prefered services

We prefer services which:

are provided by a Swiss or EU company, preferably by companies we know

are provided by a company that shares our values

are built upon and support Open Source software

allow for data portability preventing vendor lock-in

can be integrated with our user management

These aren’t hard requirements. If the evaluation of a service finds that a service is the best for VSHN but doesn’t fully comply to the above points, it must have a documented reasoning.

This strategy is tracked and reviewed as part of VIP-96

204. Quick Links

In VSHN we use a variety of tools to help us do our jobs. This section provides quick links to many of them. If you can’t find what you’re looking for here, there’s a "Tools" section in the Control Panel (see below) which lists all services you have access to!

204.1. General

Control panel

Manage Servers and Customers

Webmail and calendar

Our Mail and Calendar

Wiki

Our Confluence Wiki to record everything from processes to howtos.

Rocket Chat

Our Chat program where we discuss everything VSHN related.

Discussion Forum

Our discussion forum to have longer lasting discussions.

Jira

Tickets and Project Management

VSHN Central (Odoo ERP)

To log presence, and for leave requests

Zoom Meetings

Tool to make Video Calls

Nextcloud file storage

File Storage, mainly for business and marketing related files.

Passbolt

Our password manager.

204.2. Technical

GitLab

Our internal source code management

GitHub

Our open source software projects

204.3. Communication

Status page

Our Status Page will inform customers about planned maintenance and incidents.

Appendix A: Contributing to the Handbook

This document highlights how to make changes in this project.

For the technical requirements of this project, please check the README of the project.

There was an internal documentation session about contributing to the VSHN Handbook on August 9th, 2019. All the information about it (including link to the video, slides, etc.) is available in the VINT-1429 ticket. Check it out!

A.1. Language and Vocabulary

Please follow the following guidelines for your writing:

The language of the Handbook is American English.

Please use gender-neutral English whenever possible. Refer to people as "they" and "them" instead of "he," "she," "him" or "her."

Write short sentences.

Introduce enumerated lists (like this one) with a little bit of context (as in the previous paragraph).

Beware of common grammar mistakes in written English.

Use a spell checker before committing your changes.

The text of the handbook is automatically verified by the vale tool before deployment. You can use the tool locally in your laptop, just using the make check command. As a rule of thumb, your text must not trigger any errors in the output of vale.

When writing content for the Handbook in your own laptop, use the make check command to trigger a verification of your text using the vale tool.

A.2. Documents

Documents are written in AsciiDoc. Please check the AsciiDoctor user manual for a complete reference of the AsciiDoc language.

There is a quick reference document as well.

The pages of the manual are stored in the src/modules/ROOT/pages folder. This is a requirement of the Antora tool used to build the website.

Don’t use subfolders inside the pages folder. Store all pages inside the same level. You can regroup them into sets later on–for example, on the nav.adoc file for the website, or in the handbook.adoc file for dividing the PDF into parts.

Navigation on the left side of the screen in browser has to be configured in src/modules/ROOT/nav.adoc.

Files must be in src/handbook.adoc for PDF creation.

Filenames should use the underscore character "_" and not the dash "–" to distinguish different parts.

Images must be stored in the src/modules/ROOT/assets/images folder, and referenced using the following block macro:

image::file_name.ext[optional alt text]

You can use :keywords: to generate a <meta name="keywords" content="…​"> tag which search engines might pick up, they aren’t relevant for our handbook search.

A.3. Branching Model

The default branch of the project on GitLab is master. This branch is deployed to production.

Changes happen in (short-living) branches, starting from the master branch. Create such a branch, push changes to it, and open a merge request for review (four-eyes principle) before it gets merged into master. This can create a preview deployment under $branchname.preview.handbook.vshn.ch, once you hit the "Deploy" button. After the branch has been merged, the preview deployment gets removed again.

Check the "Delete source branch when merge request is accepted" checkbox when creating new MRs. This will clean up merged branches automatically.

A.4. Workflow

In a nutshell, this is how we use Git in this project:

To add a new page to the handbook, or to modify or delete an existing one, start a new branch.

When done, always create an MR on GitLab, and request a colleague to review and merge the changes.

Every time you add a new page or delete an existing one, remember to modify the src/modules/ROOT/nav.adoc and the src/handbook.adoc files; the former is the navigation bar shown on the left side of the handbook, the latter is the master file of the PDF & e-book formats.

A.5. Git Commit Messages

The Git commit messages are used in the Changelog. Please write the messages accordingly. If you don’t want your change to be in the changelog (for example typo fixing) you can add [nochangelog] to your commit message. Maybe you want to rebase your branch before it gets merged into master to have a clean commit history and properly written commit messages.

Only the first line (summary) is included in the Changelog. If you want to tell a bit more about the change, add a blank line and then write as much as you want / need.

A.6. Tickets & Time Tracking

If your modifications include substantial changes to the contents of the handbook, please create a new task blocking the VINT-1317 project milestone. This new task should summarize in a nutshell the changes that you intend to make. You can then log your time on that specific task.

If you can’t make the changes yourself, assign someone from the Documentation Interest Group to do them on your behalf.

For smaller changes, simply open a merge request.

A.7. Useful Tools

Some recommendations to work with Git:

GitLab Web IDE (integrated, web-based IDE)

Sourcetree (Git GUI for Windows, macOS, Linux)

GitKraken (Git GUI for Windows, macOS, Linux)

Codium (Windows, macOS, Linux) has built-in support

A.8. Merge Request Approval Process

MRs are approved by the project editor, or one of their deputies, with prior agreement from the Documentation Interest Group. When approved, the changesets of the MR are merged into master (see Branching Model).

Make sure your MR has the MR Template in its merge request description.

Never push commits directly to master. Always create a feature branch and open an MR to merge changes into master.

A.9. Release Process

After merging an MR to the master branch:

A changelog gets generated from the Git commit messages (by Poopayee).

Add [nochangelog] to your commit message if you don’t want it to be in the changelog.

Changes are automatically published to the production deployment on APPUiO Cloud.

There is no need for a Git tag.

A.10. Tips for Visual Studio Code Users

Install the Official AsciiDoctor Visual Code extension and then add the following entry to your settings, to allow images to appear in the preview pane and for a better writing experienceg:

"[asciidoc]": {
    "editor.quickSuggestions": {
        "comments": false,
        "other": false,
        "strings": false
    },
    "editor.wordWrap": "wordWrapColumn",
    "editor.wordWrapColumn": 70
},
"asciidoc.preview.attributes": {
    "imagesdir": "../assets/images",
    "experimental": "experimental",
    "toc": "preamble",
    "icons": "font",
    "hide-uri-scheme": "",
    "kroki-server-url": "[KROKI URL HERE]",
    "nofooter": ""
},
"asciidoc.preview.fontFamily": "'Ubuntu',-apple-system, BlinkMacSystemFont, 'Segoe WPC', 'Segoe UI', 'HelveticaNeue-Light', 'Droid Sans', sans-serif",
"asciidoc.use_kroki": true,
"asciidoc.preview.useEditorStyle": false,

A.11. Other Recommended Tools

git extras

A.12. Recommended Reading

The Three Core Antora Concepts You Need To Know To Use It Fully

Appendix B: CHANGELOG

B.1. 2024-04-12

Remove Colin from the teams and workgroups (!1013)

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.2. 2024-04-09

Removed Adrian Kosmaczewski from Handbook (!1011)

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

Updated: weekly_company_meeting.epub

B.3. 2024-03-27

New Timesheet submission process (!999)

Updated: timetracking.epub

B.4. 2024-03-25

Update Supplier Security Policy with contents for new ISO Control 5.23 (Cloud Services) (!1008)

Updated: ism_supplierpolicy.epub

B.5. 2024-03-22

Add ISMS Supplier Security Policy to the handbook (!1007)

Added: ism_supplierpolicy.epub

B.6. 2024-03-21

Add Threat Intelligence (ISO/IEC 27001:2022 A.5.7) to incident process (!1003)

Updated: ism_incidentmanagement.epub

B.7. 2024-03-18

Update Individual Education Process, Review VIP-141 (!1001)

Updated: personal_education.epub

B.8. 2024-03-13

Improve C-level title handling (!995)

Updated: domain_tech_alignment.epub

Updated: role_clevel.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

Updated: wg_tech_alignment.epub

B.9. 2024-03-12

Delete 2023 Company Focus Page (!996)

Deleted: company_focus.adoc

Updated: vshn_key_deliverables.epub

B.10. 2024-03-05

Update all links to new wiki on Atlassian Cloud (!979)

Added: definition_managed_service.epub

Added: odoo16_tips.epub

Added: role_culture_catalyst.epub

Added: role_management_member.epub

Added: role_strategist.epub

Deleted: role_agilecoach.adoc

Deleted: role_responsibleops.adoc

Deleted: role_responsibleops_how_we_work_with_tickets.adoc

Deleted: role_responsibleops_organizing_help_for_other_teams.adoc

Deleted: role_responsibleops_phone_duty.adoc

Deleted: role_responsibleops_ticket_triage.adoc

Deleted: vshn_management_office_hours.adoc

Updated: alignment.epub

Updated: apprenticeships.epub

Updated: avior_triage_and_support.epub

Updated: calendar.epub

Updated: can_ch_working_in_canada.epub

Updated: can_visit_ch.epub

Updated: can_vshneer_canada_flat.epub

Updated: changelog_legacy.epub

Updated: communication_channels.epub

Updated: coronavirus.epub

Updated: corporate_it_tools.epub

Updated: debtandcriminalrecords.epub

Updated: documentation.epub

Updated: domain_247_operations.epub

Updated: domain_business_management.epub

Updated: domain_centralservices.epub

Updated: domain_corporate_it.epub

Updated: domain_ism.epub

Updated: domain_marketing.epub

Updated: domain_peoplecare.epub

Updated: domain_product_appops_appflow.epub

Updated: domain_product_server_based_services.epub

Updated: domain_recruiting.epub

Updated: domain_team_development.epub

Updated: everyday_life.epub

Updated: gitlab.epub

Updated: interest_groups.epub

Updated: ism_incidentmanagement.epub

Updated: ism_policies.epub

Updated: learning_reflection.epub

Updated: leave_requests.epub

Updated: licensing_guide.epub

Updated: mail.epub

Updated: meetings.epub

Updated: office.epub

Updated: office_life.epub

Updated: okrs_tracking.epub

Updated: one_on_ones.epub

Updated: recruiting_onboarding.epub

Updated: recruiting_process.epub

Updated: role_apprentice_owner.epub

Updated: role_apprentice_professional_education.epub

Updated: role_mentor.epub

Updated: service_desk_workflow.epub

Updated: tech_strategy.epub

Updated: terminology.epub

Updated: timetracking.epub

Updated: trial_period.epub

Updated: troubleshoot_dockingstations.epub

Updated: videoconferencing_guidelines.epub

Updated: vshn_culture_overview.epub

Updated: vshn_improvement_proposals.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

Updated: vshnconnect.epub

Updated: weekly_company_meeting.epub

Updated: wg_management.epub

Updated: wg_products.epub

Updated: wg_team_development.epub

Updated: wg_tech_alignment.epub

Updated: your_first_day.epub

Remove obsolete Agile Coach role (!952)

Deleted: role_agilecoach.adoc

Updated: changelog_legacy.epub

Updated: domain_centralservices.epub

Updated: domain_peoplecare.epub

Updated: domain_team_development.epub

Updated: learning_reflection.epub

Updated: wg_team_development.epub

Slightly refine tech strategy document (!954)

Added: definition_managed_service.epub

Updated: tech_strategy.epub

Add description where to find extra hours in Odoo (!972)

Updated: timetracking.epub

Add tips and tricks page for new Odoo 16 (!967)

Added: odoo16_tips.epub

B.11. 2024-02-22

Update debtandcriminalrecords.adoc to remind people to add certificates via email (!992)

Updated: debtandcriminalrecords.epub

Updated: your_first_day.epub

B.12. 2024-02-14

Document 2024 Strategy Approach (!978)

Added: role_strategist.epub

Updated: alignment.epub

Updated: domain_business_management.epub

Updated: role_culture_catalyst.epub

Updated: terminology.epub

B.13. 2024-01-31

Split Management Roles (!981)

Added: role_culture_catalyst.epub

Added: role_management_member.epub

Updated: domain_business_management.epub

Updated: wg_management.epub

Avior related and other cleanup (!980)

Deleted: role_responsibleops.adoc

Deleted: role_responsibleops_how_we_work_with_tickets.adoc

Deleted: role_responsibleops_organizing_help_for_other_teams.adoc

Deleted: role_responsibleops_phone_duty.adoc

Deleted: role_responsibleops_ticket_triage.adoc

Deleted: vshn_management_office_hours.adoc

Updated: avior_triage_and_support.epub

Updated: meetings.epub

Updated: service_desk_workflow.epub

B.14. 2024-01-04

Remove former employee from handbook (!966)

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.15. 2024-01-03

Update Canadian Holidays 2024 (!964)

Updated: work_hours.epub

B.16. 2023-12-21

First round of updates for VSHN Central (!962)

Added: vshn_central.epub

Deleted: jira_worklogs.adoc

Updated: corporate_it_tools.epub

Updated: holidays.epub

Updated: leave_requests.epub

Updated: links.epub

Updated: payslips.epub

Updated: role_apprentice_owner.epub

Updated: role_apprentice_professional_education.epub

Updated: role_mentor.epub

Updated: sickleave.epub

Updated: terminology.epub

Updated: timetracking.epub

Updated: trial_period.epub

Updated: your_first_day.epub

B.17. 2023-12-05

Update procedure on how to handover work to Canada (!955)

Updated: can_collab.epub

B.18. 2023-12-04

Remove Colin and add Sandro to TA for Vega (!957)

Updated: vshn_workgroups.epub

B.19. 2023-12-01

Update Vega Domain to be VSHN CA Operations Team, Updates Nunki (!951)

Added: domain_canada_operations.epub

Deleted: domain_product_appuio_kubernetes_services.adoc

Updated: domain_vshn_canada.epub

Updated: vshn_teams.epub

Update the driver for TF and SM role (!956)

Updated: role_team_facilitator.epub

B.20. 2023-11-24

Merge Marketing and Sales Teams (!872)

Added: domain_marketing.epub

Added: domain_marketing_sales.epub

Added: domain_product_management.epub

Added: domain_sales_account_management.epub

Added: partner_management.epub

Deleted: domain_customer_experience.adoc

Deleted: domain_marketing_business_development.adoc

Deleted: domain_partner_management.adoc

Deleted: role_partnermanager.adoc

Updated: avior_triage_and_support.epub

Updated: changelog_legacy.epub

Updated: domain_products.epub

Updated: howto_create_vips.epub

Updated: process_presales.epub

Updated: process_project_management.epub

Updated: product_roadmap.epub

Updated: role_bdm.epub

Updated: role_customer_account_manager.epub

Updated: role_productmanager.epub

Updated: role_solution_architect.epub

Updated: service_desk_workflow.epub

Updated: vshn_improvement_proposals.epub

Updated: vshn_teams.epub

B.21. 2023-11-13

Update from VSHNday to VSHN Connect. (!948)

Deleted: vshnday_expenses.adoc

Renamed: vshnconnect.epub

Updated: can_visit_ch.epub

Updated: documentation.epub

Updated: domain_centralservices.epub

B.22. 2023-11-09

Remove Lattice (!947)

Added: people_pulse.epub

Deleted: lattice.adoc

Renamed: enps.epub

Document Wiki for OKRs instead of lattice (!945)

Added: okrs_tracking.epub

Deleted: lattice_okrs.adoc

Updated: alignment.epub

Updated: lattice.epub

Updated: teams.epub

B.23. 2023-11-08

Fix heading structure in Taking Assets Off-Site in AUP (!946)

Updated: ism_aup.epub

B.24. 2023-11-07

Change delegator of ISMS work group (!944)

Updated: domain_ism.epub

B.25. 2023-10-31

Added page describing Rulebook for Planned Work Ticket Workflow (!943)

Added: rulebook_planned_work_ticket_workflow.epub

Added page describing Service Desk Workflow (!941)

Added: service_desk_workflow.epub

Deleted: jira_change_issue_type.adoc

Deleted: jira_incident_issue_type.adoc

Deleted: jira_incident_prevention_issue_type.adoc

Deleted: jira_information_request_issue_type.adoc

Deleted: jira_issue_blocking_rules.adoc

Deleted: jira_problem_issue_type.adoc

Deleted: jira_service_request_issue_type.adoc

Deleted: jira_task_management_and_planning.adoc

Added page describing how to do Avior Triage and Support (!942)

Added: avior_triage_and_support.epub

B.26. 2023-10-25

Fix typos and trivias on several pages (!940)

Updated: alignment.epub

Updated: organization_structure.epub

Updated: vshn_culture_overview.epub

B.27. 2023-10-16

Improvements to recruiting process documentation (!924)

Added: recruiting_onboarding.epub

Added: recruiting_pre_screening.epub

Updated: recruiting_1st_meeting.epub

Updated: recruiting_2nd_meeting.epub

Updated: recruiting_process.epub

B.28. 2023-10-04

Integrate and Update Disciplinary Process in Handbook (!770)

Added: disciplinaryprocess.epub

B.29. 2023-10-02

Update team and workgroup membership (!937)

Updated: domain_product_appuio_kubernetes_services.epub

Updated: domain_team_development.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.30. 2023-09-28

Add confidentiality annex with legal text (!932)

Added: annex_declaration-of-confidentiality.epub

B.31. 2023-09-26

Add Passbolt user documentation (!927)

Added: passbolt_user_documentation.epub

B.32. 2023-09-25

Add ISMS Acceptable Use Policy (AUP) (!892)

Added: ism_aup.epub

Updated: ism_incidentmanagement.epub

Updated: password_generate.epub

Updated: personal_hardware_budget.epub

B.33. 2023-09-19

Update team membership - September 2023 (!923)

Updated: domain_customer_experience.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.34. 2023-09-18

Add performance improvement plan (people ops) (!922)

Added: pip.epub

B.35. 2023-09-13

Add password generation and manager how to (!919)

Added: password_generate.epub

Added: password_managers.epub

Added: tools_password.epub

B.36. 2023-09-08

Add Process to request personal workplace budget (!915)

Updated: personal_workplace_budget.epub

B.37. 2023-09-01

Add Alex as Apprentice Professional Education (!912)

Updated: role_apprentice_professional_education.epub

B.38. 2023-08-29

Add the Rust programming language to the Tech Radar in the "Assess" ring (!909)

Updated: tech_radar.epub

B.39. 2023-08-23

Domains and Domain Reviews (!897)

Added: review_domains.epub

Updated: domains.epub

Updated: teams.epub

Updated: vshn_culture_overview.epub

B.40. 2023-08-14

Moving Ramón to Team Nunki (!906)

Updated: vshn_teams.epub

B.41. 2023-08-07

Created new page about the customer communication guidelines (!899)

Added: customer_communication_guidelines.epub

Renamed: internal_communication_principles.epub

B.42. 2023-08-03

Remove former VSHNeer from team page (!900)

Updated: vshn_teams.epub

B.43. 2023-07-28

Review Avior (!889)

Updated: domain_customer_support.epub

B.44. 2023-07-26

Instructions for Canadian Criminal and Dept Record (!852)

Updated: debtandcriminalrecords.epub

Colab Process with VSHN Canada (!808)

Added: can_collab.epub

Document risk constraints for pre-sales decisions (!893)

Updated: process_presales.epub

B.45. 2023-07-25

Added page about incident handling (!894)

Added: incident_handling.epub

B.46. 2023-07-24

Document Project Management VIP-303 (!890)

Added: process_project_management.epub

Updated: domain_customer_experience.epub

Updated: process_presales.epub

B.47. 2023-07-21

Shorten emergency communication channels (!863)

Updated: emergency_communication_channels.epub

Ask people to add their absences to their calendar (!887)

Updated: holidays.epub

Change Corp IT to Canopus (!888)

Updated: apprenticeships.epub

B.48. 2023-07-20

Add reviewed Team Facilitator and Scrum Master Roles (!873)

Added: role_scrum_master.epub

Updated: role_team_facilitator.epub

B.49. 2023-07-19

Document Fundamental Team Responsibilities (!866)

Updated: teams.epub

B.50. 2023-07-18

Added Josh Meyer to Rigel team (!881)

Updated: vshn_teams.epub

B.51. 2023-07-17

Document VIP-302 (Sales Offering Decisions) (!875)

Added: process_presales.epub

Renamed: role_customer_account_manager.epub

Updated: process_requirements_engineering.epub

Nunki (AppOps and AppFlow) Review (!871)

Updated: domain_product_appops_appflow.epub

B.52. 2023-07-14

Updated mail and address book setup for Thunderbird/Betterbird (!876)

Updated: mail.epub

B.53. 2023-07-10

Add physical security policy for ISMS (!867)

Added: ism_physicalsecurity.epub

B.54. 2023-07-03

Added Jessica to the Polaris team (!861)

Updated: vshn_teams.epub

Added clarification about Legal Leaves (!860)

Updated: leave_requests.epub

B.55. 2023-06-26

Update Solution Architect Delegator (!855)

Updated: role_solution_architect.epub

B.56. 2023-06-23

Introduce the VSHN Cloud Native Consulting product to our product portfolio (!850)

Updated: vshn_product_portfolio.epub

B.57. 2023-06-14

Revise Dev Policy to include manifesto (!837)

Updated: ism_developmentsecuritypolicy.epub

B.58. 2023-06-13

Add Information Security domain to tech alignment (!851)

Updated: domain_tech_alignment.epub

Updated: vshn_workgroups.epub

B.59. 2023-06-09

Document VSHN, Culture, How we do things (!830)

Added: leadership.epub

Added: operations_governance.epub

Added: vshn_culture_faqs.epub

Added: vshn_culture_overview.epub

Updated: alignment.epub

Updated: decision_making.epub

Updated: evolving_our_organization.epub

Updated: teams.epub

Updated: understand_and_assign_drivers.epub

Updated: videoconferencing_guidelines.epub

Updated: vshn_improvement_proposals.epub

B.60. 2023-05-24

Update VSHNday during yearly review (!833)

Updated: vshnday.epub

Change the accountable team and the delegator (!831)

Updated: domain_corporate_it.epub

B.61. 2023-05-15

Added clarification to personal education policies (!828)

Updated: debtandcriminalrecords.epub

Updated: personal_education.epub

B.62. 2023-05-10

Document Lattice eNPS (!823)

Added: lattice_enps.epub

Updated: lattice.epub

B.63. 2023-05-09

Document OKRs in Lattice (!822)

Added: lattice_okrs.epub

Updated: lattice.epub

B.64. 2023-05-03

Add clarification for expenses and travel to and from Canada (!807)

Updated: can_ch_working_in_canada.epub

Updated: can_visit_ch.epub

Add Information for VSHNday Visit (!814)

Added: vshnday_expenses.epub

Updated: can_visit_ch.epub

Remove former VSHNeers from handbook (!819)

Updated: apprenticeships.epub

Updated: domain_product_appuio_kubernetes_services.epub

Updated: role_apprentice_professional_education.epub

Updated: vshn_workgroups.epub

B.65. 2023-04-28

Address InfoSec during Solution Process (!816)

Updated: process_requirements_engineering.epub

Add onboarding step for debt and criminal records (!815)

Updated: debtandcriminalrecords.epub

B.66. 2023-04-25

Remove Patrik from Vega Team (!813)

Updated: vshn_teams.epub

B.67. 2023-04-21

Fix pages without page title (!812)

Updated: jira_issue_types_for_project_management.epub

Updated: jira_project_and_operations_reporting.epub

Updated: jira_project_states.epub

Updated: role_responsibleops_how_we_work_with_tickets.epub

Updated: role_responsibleops_ticket_triage.epub

B.68. 2023-04-18

Various small PeopleOps updates (!811)

Updated: leave_requests.epub

Updated: payslips.epub

Updated: timetracking.epub

B.69. 2023-04-14

Rephrasing of the VSHN Product Portfolio page for a better reading pleasure (!805)

Updated: vshn_product_portfolio.epub

B.70. 2023-04-13

Introduce the VSHN mascot "VSHNbot" and describe the VSHN logo (!798)

Updated: brand_guide.epub

B.71. 2023-04-12

Document workaround to add SOGo calendar to Mac OS (!806)

Updated: calendar.epub

B.72. 2023-04-11

Adding Annie to the Rigel team (!802)

Updated: vshn_teams.epub

B.73. 2023-04-05

Add how-to for adding Outlook calendar (!801)

Updated: calendar.epub

Explained details about working outside of Switzerland (!792)

Updated: remote_working.epub

Adding team definition for Sandro Kaspar (!800)

Updated: vshn_teams.epub

B.74. 2023-04-04

Updates to Marketing and Sales Domain (!743)

Updated: domain_marketing_business_development.epub

Updated: vshn_teams.epub

B.75. 2023-04-03

Remove VSHNeers leaving the company (!796)

Updated: domain_product_server_based_services.epub

Updated: office_life.epub

Updated: role_corporate_it_lead.epub

Updated: role_corporate_it_project_manager.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

Updated: zoom_phone.epub

B.76. 2023-03-31

Update description how to get a leave summary (!794)

Updated: holidays.epub

B.77. 2023-03-27

New page about Lattice (!787)

Added: lattice.epub

Add ISMS policy section and move policies (!785)

Added: ism_policies.epub

Updated: domain_ism.epub

B.78. 2023-03-20

Cleanup outdated content (Spring clean) (!774)

Deleted: hero_ops.adoc

Deleted: team_antares.adoc

Renamed: employeebenefits.epub

Updated: can_ch_working_in_canada.epub

Updated: can_office.epub

Updated: can_vshneer_canada_flat.epub

Updated: chat_channels.epub

Updated: communication_channels.epub

Updated: domain_centralservices.epub

Updated: everyday_life.epub

Updated: office_life.epub

Updated: salary_system.epub

Updated: terminology.epub

Updated: timetracking.epub

Updated: vshn_teams.epub

Updated: weekly_company_meeting.epub

Updated: work_hours.epub

Updated: your_first_day.epub

VSHN Canada Documentation (!698)

Added: can_ch_working_in_canada.epub

Added: can_office.epub

Added: can_visit_ch.epub

Added: can_vshneer_canada_flat.epub

B.79. 2023-03-17

Replaced check_orphans.py with ad-hoc container (!775)

B.80. 2023-03-16

Completely rework navigation for former Everyday Life topics (!773)

New timesheet every month not week (!763)

Updated: timetracking.epub

Link responsible domain with TipTel and vice-versa (!765)

Updated: domain_officemanagement.epub

Updated: zoom_phone.epub

Document name for Corporate IT team (!772)

Updated: vshn_teams.epub

B.81. 2023-03-14

Add governance and admin constraints for VSHN CA (!771)

Updated: domain_vshn_canada.epub

Updated: role_ca_general_manager.epub

B.82. 2023-03-13

Updated copyright text and infrastructure versions (!769)

B.83. 2023-03-02

Document future Customer Support Domain and Lead Role (!753)

Added: role_customer_support_lead.epub

Updated: domain_customer_support.epub

Updated: vshn_teams.epub

Add Pierre Rouveyrol to Team Polaris (!759)

Updated: vshn_teams.epub

Document new Compensation Work Group members (!757)

Updated: vshn_workgroups.epub

Add Nick Marti to Team Nunki (!760)

Updated: vshn_teams.epub

B.84. 2023-02-28

Remove VSHNeers DC and other obsolete structures (!756)

Deleted: delegate_circles.adoc

Deleted: delegatecircle_vshneers.adoc

Deleted: domain_orgdev.adoc

Deleted: domain_vshneer_success.adoc

Deleted: role_delegate.adoc

Updated: calendar.epub

Updated: communication_channels.epub

Updated: decision_making.epub

Updated: domain_247_operations.epub

Updated: domain_centralservices.epub

Updated: domain_compensation.epub

Updated: domain_peoplecare.epub

Updated: domain_peopleops.epub

Updated: domain_recruiting.epub

Updated: domain_team_development.epub

Updated: evolving_our_organization.epub

Updated: governance_meeting.epub

Updated: howto_create_vips.epub

Updated: interest_groups.epub

Updated: personal_coaching.epub

Updated: recruiting_process.epub

Updated: role_team_facilitator.epub

Updated: roles.epub

Updated: teams.epub

Updated: terminology.epub

Updated: understand_and_assign_drivers.epub

Updated: vshn_improvement_proposals.epub

Updated: vshn_workgroups.epub

Updated: weekly_company_meeting.epub

Updated: wg_management.epub

B.85. 2023-02-27

New page helping troubleshooting issues with dockingstations (!654)

Added: troubleshoot_dockingstations.epub

B.86. 2023-02-24

Adapt HackDay page to account for other VSHN offices like Canada (!755)

Updated: vshn_hackday.epub

B.87. 2023-02-23

Refresh the HackDay page to account for the upcoming events (!752)

Updated: vshn_hackday.epub

Review office hours (!754)

Updated: vshn_management_office_hours.epub

Add reviewed roles for apprenticeships at VSHN (!741)

Added: apprenticeships.epub

Added: role_apprentice_owner.epub

Added: role_apprentice_professional_education.epub

Added: role_apprentice_technical_mentor.epub

Updated: vshn_workgroups.epub

B.88. 2023-02-17

Introduce audience for our documentation and cleanup documentation page a bit (!732)

Updated: documentation.epub

Updated: interest_groups.epub

Update changelog generator version which displays what has changed (!707)

Cleanup and align APPUiO Managed product naming (!750)

Renamed: domain_product_appuio_kubernetes_services.epub

Updated: company_focus.epub

Updated: domain_product_appcatalog.epub

Updated: domain_product_appops_appflow.epub

Updated: domain_product_appuio_os4.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.89. 2023-02-16

Review and adjust Team Development Work Group (!728)

Updated: domain_team_development.epub

Clarify how Tech Alignment WG Works and point to the Jira project (!742)

Updated: wg_tech_alignment.epub

B.90. 2023-02-14

Add new meeting room resource in VSHNtower (!736)

Updated: meeting_rooms.epub

Added reasons for required education for VSHNeers (!737)

Updated: personal_education.epub

B.91. 2023-02-10

Document telephone number of TipTel which is used for call forwarding (!733)

Updated: zoom_phone.epub

B.92. 2023-02-09

Change Product Owner of Team Vega (!731)

Updated: domain_product_appuio_cloud_kubernetes.epub

Refine Products WG and Domain after an internal review (!730)

Updated: domain_products.epub

Updated: vshn_workgroups.epub

Updated: wg_products.epub

B.93. 2023-02-01

Remove BAG link to COVID rules which return a 404 (!729)

Updated: coronavirus.epub

B.94. 2023-01-31

Update VSHN Teams for February 2023 (and order alphabetically) (!727)

Updated: vshn_teams.epub

Improve page about GPG with some nice commands (!717)

Updated: gpg.epub

B.95. 2023-01-20

Revise Incident Management Policy (!714)

Updated: ism_incidentmanagement.epub

Update Product Portfolio with Product Vision and clarified structure (!712)

Updated: vshn_product_portfolio.epub

Document Anti-Harassment Policy (!718)

Added: anti_harassment_policy.epub

B.96. 2023-01-19

Add Aarnos title (!715)

Updated: vshn_teams.epub

Document the Company Focus for 2023 and cleanup Beliefs into Tech Strategy (!711)

Added: company_focus.epub

Added: tech_strategy.epub

Deleted: beliefs.adoc

Updated: alignment.epub

Updated: role_ciso.epub

B.97. 2023-01-18

Clarify who is allowed to officially sign documents (!713)

Updated: wg_management.epub

Introduce our Product Maturity assessment checklist (!702)

Added: product_maturity.epub

B.98. 2023-01-17

Update Tech Radar Q1 2023 (!705)

Updated: tech_radar.epub

Update Management and Board after AGM (!706)

Added: role_clevel.epub

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

Updated: wg_management.epub

B.99. 2023-01-16

Update Team Polaris and Compensation Workgroup members (!708)

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.100. 2023-01-06

Mention where to find Desktop Wallpapers and Virtual Zoom Background in Brand Guide (!701)

Updated: brand_guide.epub

Updated: your_first_day.epub

Updated: zoom_phone.epub

B.101. 2023-01-05

Change product prioritization scheme to ICE scoring (!691)

Updated: product_roadmap.epub

B.102. 2023-01-04

Add new VSHNeers started in January 2023 and update Roles of Rigel Team Members (!700)

Updated: vshn_teams.epub

Updated: vshn_workgroups.epub

B.103. 2022-12-30

Add info box to find public holidays quicker (!694)

Updated: holidays.epub

Use new Changelog Generator - Based on merged GitLab Merge Requests (!697)

Added: changelog_from_commits.epub

Updated: changelog_legacy.epub

B.104. 2022-12-27

Document Team Facilitator of Antares (!696)

Updated: vshn_teams.epub

B.105. 2022-12-14

Link new Value Stream Domains to Governance VIPs (!693)

Updated: domain_product_appcatalog.epub

Updated: domain_product_appops_appflow.epub

Updated: domain_product_appuio_cloud_kubernetes.epub

Updated: domain_product_appuio_os4.epub

Updated: domain_product_server_based_services.epub

Document current Nunki Team (!692)

Updated: vshn_teams.epub

B.106. 2022-12-06

Amend list of Tech Alignment topics (!687)

Updated: domain_product_appops_appflow.epub

Updated: domain_tech_alignment.epub

Updated: vshn_workgroups.epub

Clarify salary system expectations (!684)

Updated: salary_system.epub

First Day: Reference where to get overtime from. (!683)

Updated: your_first_day.epub

Update team member page after leaving (!688)

Updated: vshn_teams.epub

Updated: zoom_phone.epub

B.107. 2022-11-29

Correct listing in Medical Consultation leave description (!682)

Updated: timetracking.epub

B.108. 2022-11-28

Document configuration for Apple Calendar (!681)

Updated: calendar.epub

B.109. 2022-11-25

Refine Tech Alignement (!677)

Updated: domain_tech_alignment.epub

Updated: wg_tech_alignment.epub

Refine Products WG and interim PO of Vega (!672)

Updated: domain_product_appuio_cloud_kubernetes.epub

Updated: domain_products.epub

Updated: vshn_workgroups.epub

Updated: wg_products.epub

B.110. 2022-11-23

Highlight VSHNeers who are Canada employees (!678)

Updated: vshn_teams.epub

Add roadmap as PO key resource (!675)

Updated: role_productowner.epub

Refine Rigel (!676)

Updated: domain_marketing_business_development.epub

Updated: domain_partner_management.epub

Updated: vshn_teams.epub

B.111. 2022-11-22

Add new employee to the Vega team (!674)

Updated: vshn_teams.epub

B.112. 2022-11-21

Updates to time tracking rules (!673)

Updated: timetracking.epub

B.113. 2022-11-18

Add new Marketing & Business Development Domain (!669)

Added: domain_marketing_business_development.epub

Deleted: domain_marketing_sales.adoc

Updated: domain_partner_management.epub

Updated: domain_products.epub

Updated: organization_structure.epub

Updated: vshn_teams.epub

Updated: wg_products.epub

Re-add paying information about Halbtax (!671)

Updated: salary_system.epub

Update Public Holidays (!657)

Updated: work_hours.epub

B.114. 2022-11-17

Document Office Hours with Management (!670)

Added: vshn_management_office_hours.epub

Add how-to for interest group calendar invites (!663)

Updated: calendar.epub

Add explanation about use of :keywords: (!666)

Updated: contributing.epub

Small refinement for Productboard usage (!659)

Updated: product_roadmap.epub

Link to recruiting work group wiki (!667)

Updated: domain_recruiting.epub

B.115. 2022-11-14

Clarify SOGo calendar sharing (!668)

Updated: calendar.epub

B.116. 2022-11-10

Document nochangelog label in contributing (!665)

Updated: contributing.epub

B.117. 2022-11-09

Add Tom and Patrik to their correct team (!658)

Updated: vshn_teams.epub

B.118. 2022-11-07

Recruiting process and salary system changes (!661)

Updated: recruiting_process.epub

Updated: salary_system.epub

B.119. 2022-11-03

Improve explanation how to insert calendar in Thunderbird (!656)

Updated: calendar.epub

B.120. 2022-11-02

Update contribution page to have quicker overview (!655)

Updated: contributing.epub

B.121. Old Changelogs

The changelog which was generated with Git commit messages is here.
The previous (manually maintained) changelog is available here.

Appendix C: License & Copyright

Copyright © 2014–2024 VSHN AG–All Rights Reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and other materials provided with the distribution.

Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Appendix D: VSHN Employee Handbook README

This project contains the AsciiDoc source of the VSHN Employee Handbook.

D.1. Contributions

Please check the Contributing document for information.

D.2. Requirements

The only requirement to build this project is Docker.

Web Version

This project is built with the vshn/antora Docker image.

Other Versions

The man page version of the Handbook require the Asciidoctor Docker image.

The PDF version is built with the vshn/asciidoctor-pdf Docker image.

The EPUB3 version is built with the vshn/asciidoctor-epub3 Docker image.

D.3. Build Instructions

For Authors: Antora will only build the currently checked local branch, using as source the git repo and not the local filesystem.

Clone the project:

git clone git@git.vshn.net:vshn/handbook.git

Run the make command.

Open the public/index.html file to see the generated website. A ZIP file with the generated output will be located in the _archive subdirectory. The PDF file will also be located there.

You can make epub to build the remaining item, if desired.

Cleaning the Build

You can clean the build artifacts at any time using the make clean command.

D.4. Deployment

Production

The CI Pipeline is setup to deploy to APPUiO Cloud LPG 2 projects:

vshn-handbook for production

To deploy to production, merge into the master branch.

Access to APPUiO for GitLab CI

You need to configure Kubernetes project level integration for this project in GitLab with a token of a service account, that has access to both project (see above).

You also need to create a secret which contains a registry token via "Settings → Repository → Deploy tokens".

Configure and run the snippet:

docker_user=gitlab+deploy-token-XX
docker_token=TOPSECRET

for namespace in vshn-handbook vshn-handbook-test
do
    oc -n ${namespace} create sa gitlab-ci
    oc -n ${namespace} policy add-role-to-user admin -z gitlab-ci
    # Create the Image pull secret
    oc -n ${namespace} create secret docker-registry registry-vshn-net --docker-server=registry.vshn.net --docker-username="$docker_user" --docker-password="$docker_token" --docker-email=noreply@vshn.net
    # Create the cert-manager Issuer
    oc -n ${namespace} apply -f deployment/manifests/issuer.yaml
    # Get the token:
    token=$(oc -n ${namespace} sa get-token gitlab-ci)
    export KUBECONFIG=gitlab-ci.${namespace}.kubeconfig
    # write the kubeconfig file by logging in
    oc login --server=https://api.cloudscale-lpg-2.appuio.cloud:6443 --token=$token
    unset KUBECONFIG
done

For the preview deployments to work, an ACME DNS secret and a wildcard TLS certificate needs to exist.

Create an ACME DNS client as described in the Component docs.

Then:

echo "${client_config}" | jq .
oc -n vshn-handbook-test create -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: acme-dns
stringData:
  acmedns.json: |
    {
        "preview.handbook.vshn.ch": {
            "username": "UUID",
            "password": "SECRET",
            "fulldomain": "UUID2.acme-dns.vshn.net",
            "subdomain": "UUID2",
            "allowfrom": []
        }
    }
EOF
oc -n vshn-handbook-test apply -f deployment/manifests/preview-certificate.yaml

Configure the Variables in CI/CD settings. Expand the "Variables" section and add new variables for each environment accordingly:

Key = KUBECONFIG

Value = <file content of gitlab-ci.{vshn-handbook,vshn-handbook-test}.kubeconfig>

Type = File

Environment scope = {production,"preview/*"}

Colophon

Copyright © 2014-2024 VSHN AG–All Rights Reserved.

Published in Switzerland on 2024-04-12 08:31:53 UTC.

Created with Antora and Asciidoctor.