📑Find the right organization
Map your context to reach an efficient knowledge-sharing process
Last updated
Map your context to reach an efficient knowledge-sharing process
Last updated
The first key step is to register and onboard users in the platform. But having an account is not enough, and users should be assigned to spaces that make sense.
Think a Space in Packmind as a channel where users will share coding practices.
So the question every new customer asks us is:
How should we segment our users into spaces in Packmind? What must be taken into consideration?
The are two factors to take into consideration.
From our point of view, spaces should have between 4 and 20 people ideally.
If you're less or equal than 3, running regular workshops may not sustain in the long-term since tiny teams usually work closely and already communicate on their coding practices.
There's no stop from us if you're over 20. Indeed, in some projects, we can have 30 engineers or more working on the same technology, so separation doesn't make sense. The rationale behind this limit of 20 is that running collective workshops may be more complex if there're too many people in the meeting. But if you manage to run them successfully, keep going!
Users should be confident in sharing coding practices and belong to relevant spaces. Ideally, spaces should gather people sharing a common technology and are close to each other in terms of context, for instance:
A space can gather users from the same project, all working on the same technical stack (Front, Back, Full-Stack, and more...)
A space can gather users from different projects, working on the same technical stack and sharing a common domain in the organization (meaning they at least know each other). Otherwise, if they're too far, workshops will be less relevant. Except if it's a community of practice.
As much as possible, we should avoid situations where users are isolated, meaning they belong to spaces where no other users share common technologic topics. If you can't find alternatives (because this is the only person working on Front-end for instance), ensure that more generic/transversal topics, such as architecture or performance, will be discussed during workshops. Everyone will get value from the space.
Illustrations of spaces:
A Team "Marketplace" with 6 full-stack engineers will have their own space.
3 Teams from the "Web" domain, having each 3 exclusive back-end and 3 front-end engineers, could create two spaces, such as "Web - Back" and "Web - Front".
Let's summarize with a big picture:
For this example, we used common Web technologies, but please keep in mind that Packmind welcomes any kind of programming language and domain, such as test automation, infrastructure as code, and more.
How to include these transversal entities in Packmind? There are two common cases with them:
If they come in addition to regular spaces (such as the ones above), they should welcome workshops where tech leaders from different spaces introduce some of their best practices on the community topic (e.g., Front-end). Users won't push many practices in this space. Instead, the practices review feature will be used to introduce practices created in others spaces to the community.
If they stand as primary spaces and there are no finer-grain level of spaces, thus they should be considered regular spaces where users contribute.
This documentation will guide you later on how to manage spaces in Packmind.
Our customers often wonder if they should start onboarding first teams and then onboarding others a few weeks later.
If you think you should go gradually, ask yourself why you prefer to be more cautious. Are there some settings you're unsure about? We can help with that, get in touch with us, and we'll provide tips to optimize your strategy.
When onboarding in Packmind, users are invited to indicate their skills domains on which they are willing to contribute. This is a great start to assess the expertise within a team and across teams. As mentioned in the Key Success Factors of Packmind, communicating your goals is a great strategy. For instance, if your engineering leaders want to raise teams' level on Domain-Driven Design, this should be codified in Packmind.
Users will get inspiration to create their first contributions, considering the expected topics for the coding practices. See more on this dedicated page:
A simple tip to support Packmind usage in your community is to create a dedicated channel in your communication system (Teams, Slack, ...) open to everyone, but at least including all the Tech ambassadors identified for the different Packmind spaces.
This will help share advice and tips for users, raise new ideas and provide technical support internally.
In addition, spaces can also set notifications in their own channel:
You can join our public Slack with +200 users to ask for advice and understand how others Packmind users are doing in their context. And, of course, our team will be available to provide tailored assistance:
If you run the Cloud version, a chat popup is available at any time on the right-bottom of the page. You can reach us from our website if you run the on-premise version.
Our only answer is simple: if you have a clear organization for spaces and identified team leaders for each, you're ready to go .
