All engineering teams rely on some kind of documentation tool to communicate important product information with their colleagues. For small teams just getting started, this could be as simple as a Google Doc, and for larger teams with complex products, this could be a hierarchical wiki. Depending on how their company is structured, other teams (like HR or marketing) may use this wiki too, or have other areas where they store their team’s information.
When joining a new engineering team (either internally or externally), the onboarding process is critical to determining how quickly a new teammate feels ready to contribute. From setting up their coding environment to perusing feature documentation, there’s a lot needed to get up-to-speed and ready to take on new work.
For many engineering teams, the onboarding process ends up being laborious for another teammate, who is designated as the new employee’s “buddy” and would walk them through this information in real-time. But by providing their team with expert-verified, up-to-date Cards in Guru, RS21’s engineering leaders give new hires the flexibility to onboard at their own pace. This lets them save time with their onboarding “buddy” for more interpersonal relationship building or outstanding questions.
When a new engineer joins RS21’s team, they log in to Guru to start working through their onboarding materials. They’ll look through a “Team Info” Board where they can get to know a little about their teammates, use infrastructure Cards to get their environments set up correctly, and read through their team’s coding standards to get an idea of how to best collaborate with their new colleagues.
Similarly, at Guru, when an engineer joins or moves to a new team, their onboarding is done in Guru. They’ll use life story Cards to get to know their teammates, see guides on how they should expect to work together, and browse their new team’s Collection in Guru to get familiar with the product features and areas they are now responsible for.
Best Practices and Team Standards
Once the whole team is onboarded, ongoing resources, like coding standards and documentation best practices, also have a home in Guru. When documented in a way that’s accessible in their workflows, these make it easier for engineers to collaborate productively with the rest of their team and the rest of the company. It also prevents them from needing to memorize any policies or procedures or worse, bookmark and rely on outdated documents.
RS21’s Engineering Collection in Guru includes a Board dedicated to process guidelines, including Cards with instructions for merging code, creating a bash script, requesting a code review, and more. They also have Boards dedicated to their team’s agreed upon coding syntax style, AWS setup instructions, System Admin information, and more. They even have frequently used code snippets available for easy copy-and-pasting in Guru Cards.
Aside from these engineering-specific Cards, Guru is also a great place for engineers to access cross-functional best practices and guidelines for inter team processes. For example, RS21’s team conducts asynchronous discussions using Guru to give team members more time to respond thoughtfully, and to give everyone an even and fair platform to contribute. Instructions for how to set up and monitor these discussions are kept in a Guru template, so that anyone can spin one up with ease when needed.
At Guru, we enlist teams outside of our product development organization to assist with our quality assurance (QA) process. With more diverse views, we are better able to identify bugs, explore potential customer challenges, and protect against them before release. But a process as technical as QA necessitates documented instructions and procedures when involving cross-functional teams. Before beginning QA for a new feature, an engineering team lead will use our QA Process template to create a one-stop-shop for everything our team and stakeholders will need for end-to-end QA. When we’re ready to begin QA, they’ll send this out as an announcement to the team and stakeholders, and include the active QA dates in the message.
Project Planning and Development Documentation
Anytime a new development project kicks off, there’s a lot of documentation that follows to ensure everyone has the full context they need to play their part. After a kickoff meeting, engineers rely on requirements documents from product teams, the most up-to-date functional designs from their UX team, copy from their marketing or copywriting team, and more.
And, of course, they’ll frequently need to reference any technical documentation that impacts the feature they are working on, or that they’ll need to update later on in development.
At Guru, we keep track of the various resources needed for product development in an Active Projects Resources Card, championed by each project’s engineering lead. These Cards are the engineering team’s go-to-resource throughout the early stages of the product development lifecycle, and are kept up-to-date to reflect any changes throughout.
As the development process progresses, the collaboration between engineering and design must be kept in lock-step. But due to often the asynchronous and remote nature of work, designers and engineers can’t always jump on a Zoom call to talk through any issues or feedback. To ensure they’re following our agreed upon internal protocol for soliciting design feedback, our engineering team uses our Design Feedback for UI Changes workflow documented in Guru.
Future-proofed documentation
Documentation has always been and will always be a necessary part of an engineer’s work. But what once solicited painful groans and distressed sighs can become a simple, natural part of their day-to-day when it’s brought directly into their workflow. Guru’s browser extension brings documentation right to the places engineers need it, rather than forcing them to context-switch to access it, and short-form, expert-verified Cards take the pressure away from the long-form articles of yesteryear that were a headache to write and even harder to maintain. So why compound technical debt with outdated documentation when you can easily future-proof it right now? Start today for free.
All engineering teams rely on some kind of documentation tool to communicate important product information with their colleagues. For small teams just getting started, this could be as simple as a Google Doc, and for larger teams with complex products, this could be a hierarchical wiki. Depending on how their company is structured, other teams (like HR or marketing) may use this wiki too, or have other areas where they store their team’s information.
When joining a new engineering team (either internally or externally), the onboarding process is critical to determining how quickly a new teammate feels ready to contribute. From setting up their coding environment to perusing feature documentation, there’s a lot needed to get up-to-speed and ready to take on new work.
For many engineering teams, the onboarding process ends up being laborious for another teammate, who is designated as the new employee’s “buddy” and would walk them through this information in real-time. But by providing their team with expert-verified, up-to-date Cards in Guru, RS21’s engineering leaders give new hires the flexibility to onboard at their own pace. This lets them save time with their onboarding “buddy” for more interpersonal relationship building or outstanding questions.
When a new engineer joins RS21’s team, they log in to Guru to start working through their onboarding materials. They’ll look through a “Team Info” Board where they can get to know a little about their teammates, use infrastructure Cards to get their environments set up correctly, and read through their team’s coding standards to get an idea of how to best collaborate with their new colleagues.
Similarly, at Guru, when an engineer joins or moves to a new team, their onboarding is done in Guru. They’ll use life story Cards to get to know their teammates, see guides on how they should expect to work together, and browse their new team’s Collection in Guru to get familiar with the product features and areas they are now responsible for.
Best Practices and Team Standards
Once the whole team is onboarded, ongoing resources, like coding standards and documentation best practices, also have a home in Guru. When documented in a way that’s accessible in their workflows, these make it easier for engineers to collaborate productively with the rest of their team and the rest of the company. It also prevents them from needing to memorize any policies or procedures or worse, bookmark and rely on outdated documents.
RS21’s Engineering Collection in Guru includes a Board dedicated to process guidelines, including Cards with instructions for merging code, creating a bash script, requesting a code review, and more. They also have Boards dedicated to their team’s agreed upon coding syntax style, AWS setup instructions, System Admin information, and more. They even have frequently used code snippets available for easy copy-and-pasting in Guru Cards.
Aside from these engineering-specific Cards, Guru is also a great place for engineers to access cross-functional best practices and guidelines for inter team processes. For example, RS21’s team conducts asynchronous discussions using Guru to give team members more time to respond thoughtfully, and to give everyone an even and fair platform to contribute. Instructions for how to set up and monitor these discussions are kept in a Guru template, so that anyone can spin one up with ease when needed.
At Guru, we enlist teams outside of our product development organization to assist with our quality assurance (QA) process. With more diverse views, we are better able to identify bugs, explore potential customer challenges, and protect against them before release. But a process as technical as QA necessitates documented instructions and procedures when involving cross-functional teams. Before beginning QA for a new feature, an engineering team lead will use our QA Process template to create a one-stop-shop for everything our team and stakeholders will need for end-to-end QA. When we’re ready to begin QA, they’ll send this out as an announcement to the team and stakeholders, and include the active QA dates in the message.
Project Planning and Development Documentation
Anytime a new development project kicks off, there’s a lot of documentation that follows to ensure everyone has the full context they need to play their part. After a kickoff meeting, engineers rely on requirements documents from product teams, the most up-to-date functional designs from their UX team, copy from their marketing or copywriting team, and more.
And, of course, they’ll frequently need to reference any technical documentation that impacts the feature they are working on, or that they’ll need to update later on in development.
At Guru, we keep track of the various resources needed for product development in an Active Projects Resources Card, championed by each project’s engineering lead. These Cards are the engineering team’s go-to-resource throughout the early stages of the product development lifecycle, and are kept up-to-date to reflect any changes throughout.
As the development process progresses, the collaboration between engineering and design must be kept in lock-step. But due to often the asynchronous and remote nature of work, designers and engineers can’t always jump on a Zoom call to talk through any issues or feedback. To ensure they’re following our agreed upon internal protocol for soliciting design feedback, our engineering team uses our Design Feedback for UI Changes workflow documented in Guru.
Future-proofed documentation
Documentation has always been and will always be a necessary part of an engineer’s work. But what once solicited painful groans and distressed sighs can become a simple, natural part of their day-to-day when it’s brought directly into their workflow. Guru’s browser extension brings documentation right to the places engineers need it, rather than forcing them to context-switch to access it, and short-form, expert-verified Cards take the pressure away from the long-form articles of yesteryear that were a headache to write and even harder to maintain. So why compound technical debt with outdated documentation when you can easily future-proof it right now? Start today for free.
Experience the power of the Guru platform firsthand – take our interactive product tour
.webp)
