1. What Is a Workshop
A Workshop is a learning format centered on an experienced speaker in the field, guiding members to discuss a topic together through activities, discussion, talks, and other means.
Compared with traditional formats, a Workshop has the following characteristics:
- More targeted
A bit like a seminar, it can concentrate and fully discuss one class of problem.
- More flexible organization
There are more choices for venue and format β it can be outdoors, or in a meeting room, break room, and so on.
- Lower cost
It usually uses a split-the-bill arrangement, where participants only need to pay for meals and venue, with no extra expenses.
The above is organized from mbalib. Workshops for internet products differ from this, mainly in the following ways:
- The content is more concrete, targeting a specific product
The main purpose of the Workshop is to promote the product, letting users experience, think about, and master it.
- It is free
An organizer in its growth phase does not charge Workshop attendees any fee. Many internet conferences offer free refreshments, gifts, and so on to attract users, and a Workshop is no exception.
2. My Workshop Experience
I was fortunate to work at a big company, and the company had a lot of internal training. For courses covering project management, time management, corporate strategy, and the like, the instructor would usually split the trainees into groups, teaching in the form of small-team discussion and collective output. This was probably the earliest Workshop I encountered after starting work.
The Workshops I helped organize were two.
One was a SaaS development course. The trainees came mainly from inside the company; the instructor taught one task, the trainees performed one task, and teaching assistants at the back coached the trainees. But the result was unsatisfactory. The main reason was that, with no foundation, developing a SaaS on site was quite hard β it demanded full-stack skills, and an ordinary person could not finish it. The Workshop got somewhat out of control in the later stage: few people were doing the tasks, and many were chatting with the teaching assistants about the product.
The good thing was that this was one of a series of open classes, and other segments could make up for the Workshop.
The other one is the DevOps Workshop I am about to review below.
3. DevOps Workshop Retrospective
3.1 The Expectation Gap
First, the goals:
- 20 people attend the Workshop
- Use the DevOps product to deploy a complete pipeline
Now the results:
- 8 people attended the Workshop, and they were mainly on-site participants, not registered trainees
- Not one person completed the task
Judging by the results, I think it was very bad β the Workshop got out of control. The number of attendees, the quality of completion, and the degree of completion all fell short of expectations.
3.2 Where the Problems Were
- The trainees were never profiled
When discussing the task list, ambiguity arose: some thought we should not assume the trainees’ level, while others thought the trainees would not have a deep understanding of the product and it should be simpler.
- The goal was not focused
When choosing the development environment, the consideration was drawing users to other products rather than focusing on the Workshop itself.
- The task list and on-site flow were confirmed very late
Only in the week before the Workshop did we start discussing the task list and the on-site flow; there was not enough time reserved for preparation, nor did we find other colleagues to rehearse the Workshop flow.
- The promotion was too late
Posters and promotion only started two days before the Workshop, so not enough trainees could be recruited. Although registrations exceeded 20, almost none showed up on site.
- Trainees could not be actively filtered
Because registrations were few, we could not filter trainees or pick more suitable ones to attend the Workshop.
- Most trainees came from the on-site audience
The trainees who joined the Workshop on site had uneven levels, making the Workshop’s goal hard to reach.
- The development environment was chaotic
At first we planned to have trainees register their own accounts and gave out coupons. The day before the Workshop it was changed on the fly to a shared sub-account.
When initializing the development environment on site, an oversight meant we forgot to bind an EIP, so there was no access to the external network. Then we had trainees use the R&D environment; then a single node of the R&D environment got broken, so we switched to another shared R&D environment, and finally switched back to the sub-account development environment.
I am dizzy just saying it β several development environments switched back and forth.
- The on-site run did not follow the flow
We wrote a PPT, but did not carry out each item according to the PPT’s chapters.
- There were also some force majeure factors
This mainly refers to the venue being in a sensitive area, which affected attendance; and the event time clashing badly with events at other big companies.
4. What a Good Workshop Should Be Like
I have said a lot about the problems above, so what should a good Workshop be like? Is avoiding the problems above enough? Basically yes, but what I want to emphasize is not how to do it, but how to think about it.
A Workshop has many details that can be optimized and done better. But from what angle should we think about it?
A good Workshop should have a smooth flow. This smoothness comes from rehearsal under certainty. There should not be too many uncertain factors; the instructor needs to practice repeatedly and simulate possible situations.
A good Workshop should have full content. That brimming, overflowing feeling leaves trainees refreshed and well rewarded. While raising their awareness, it also achieves the Workshop’s goal.
A good Workshop should have trainees who know each other. Gathering together is a kind of fate; being able to know one another, learn from each other, and gain friendship is a gift beyond the Workshop itself.
A good Workshop should be run continuously. A Workshop is a starting point, not an endpoint. With a good start, it still needs continuous care and management.
