How Linear approaches knowledge sharing
How Linear approaches knowledge sharing
Powered by GitBook
Powered by GitBook
Powered by GitBook
8 Nov 2023
Helping people share their information — and then using that information effectively — is key in any organization. But for Linear, just like here at GitBook, the whole business is about making that information easy to document, discover and share.
So we sat down with Jori Lallo, one of Linear’s co-founders, to discuss their approach to knowledge sharing, and find out how they use GitBook to help that process along.
A frictionless information flow
The team’s main objective is to make using Linear feel frictionless. “That leads people to capture more high quality information in Linear,” says Jori. While many teams start by simply managing individual bugs and tasks in Linear, this typically evolves into them using it for project work as well. “And that opens up another challenge for us — to help you capture the information you need for your projects, while also helping surface relevant data when you need it.”
We can relate. Here at GitBook, we’re on a similar journey — and while our two platforms handle different kinds of information within the development flow, the challenges we face are strikingly similar. And just like us, the Linear team understands that bringing different strands of knowledge together adds valuable context to help you understand the bigger picture.
“We think that how you link information can have a significant impact in how you build knowledge,” says Jori. He likens it to the world-wide web — it wasn’t the first network-connected service, but it was the first method that cross-linked data. “Binding your tools together and linking information gives you similar ways to traverse information in your company without the need to collect it into one place.”
Integrations are the answer
For Linear — like for GitBook — the solution is integrations. “There is only so much collaboration that you can fit into a single tool and people tend to do what is most convenient for them in the moment,” says Jori. “We know this is a reality with Linear as well and we want to integrate with the tools our customers use most and match the habits that already exist.”
Linear has integrations with dozens of services, allowing you to do things like automate GitHub pull requests and create issues automatically through Sentry. Bringing Linear into the tools people already use reduces friction in the information flow. “People are busy, and manually moving information is time consuming. So as much as we can we try to make it easy, no matter what app you currently have open,” says Jori.
“People are busy, and manually moving information is time consuming. So as much as we can we try to make it easy, no matter what app you currently have open.”
Moving knowledge internally
That’s great news for Linear’s customers, but the team follows similar practices internally, too. So when it comes to updating their public API and developer documentation, everyone is encouraged to collaborate — in GitBook.
“We’ve been using GitBook for our documentation for a few years now,” says Jori. “Linear is a small team […] so everyone in the engineering team is responsible for working on the public API and updating the documentation in GitBook.” And because of that smaller team, Jori explains it’s typically the developer that made the changes who takes a first pass at the documentation.
Once they’ve got a first draft, they share it with the rest of the team for changes and feedback. Because the API is stable, they don’t need to make updates every day — but when the team does make one, diff view helps them see what’s changed fast. Ultimately, keeping their workflow consistent is key — especially as the team is fully remote. “At Linear all engineers work in a monorepo, and we try to maintain the same standards and practices across the engineering organization.”
Creating great documentation
But outside of consistent, detailed updates, how do the team make sure their docs are good? According to Jori, the answer is pretty simple — keep it relevant.
“We only add information that’s useful for our users — it should be clear and to the point,” he says. But the key is developers taking a major role. “As the writers of the documentation are also consumers of the information, they know the most important information to include.”
“The best documentation is what’s findable and up to date,” Jori continues. And if you fail at either of those, documenting things is not really worth it.”
“The best documentation is what’s findable and up to date.”
Internal documentation and support
The processes the team have put in place work well for public documentation — but what about sharing internal knowledge? For Jori and the team, it’s all about content that will be useful both today and in the future.
“Some internal processes we do document into our engineering wiki, but there we try to focus on short, evergreen content,” he explains. Because the team is always busy, information has to be accessible fast. Again, it comes back to what Jori said before — if people can’t find the information they need, or it takes too long to consume, it’s not worth documenting it in the first place.
The same applies when it comes to support — but there, it’s as much about keeping the support team close to engineering as it is about documenting things well. “Bringing support teams closer to engineering and product is key to building products for your users,” says Jori. For the Linear team, creating silos for these two teams creates an unhealthy product culture.
“Bringing support teams closer to engineering and product is key to building products for your users.”
That’s why the customer experience team report bugs and requests to the engineering team constantly, who in turn take great pride in addressing them. “When we ship an update that addresses a request, Linear automatically notifies our support team so they can update the customer,” says Jori. And that tight feedback loop is just one reason why Linear has great customer satisfaction. “At Linear, we treat support as part of the product experience alongside the code we write.” It’s no wonder Linear has so many die-hard fans.
A huge thanks to Jori for taking the time to talk to us — we were thrilled to hear that the Linear team are on a similar path to us, and have such a similar ethos! Like them, our goal is to make it easier to find information throughout your development workflow, and use it to write great documentation for teammates and users.
Head to Linear’s website to find out more about the tool, and check out our beta page to discover what the future of GitBook looks like.
→ See the future of GitBook on our beta page
Helping people share their information — and then using that information effectively — is key in any organization. But for Linear, just like here at GitBook, the whole business is about making that information easy to document, discover and share.
So we sat down with Jori Lallo, one of Linear’s co-founders, to discuss their approach to knowledge sharing, and find out how they use GitBook to help that process along.
A frictionless information flow
The team’s main objective is to make using Linear feel frictionless. “That leads people to capture more high quality information in Linear,” says Jori. While many teams start by simply managing individual bugs and tasks in Linear, this typically evolves into them using it for project work as well. “And that opens up another challenge for us — to help you capture the information you need for your projects, while also helping surface relevant data when you need it.”
We can relate. Here at GitBook, we’re on a similar journey — and while our two platforms handle different kinds of information within the development flow, the challenges we face are strikingly similar. And just like us, the Linear team understands that bringing different strands of knowledge together adds valuable context to help you understand the bigger picture.
“We think that how you link information can have a significant impact in how you build knowledge,” says Jori. He likens it to the world-wide web — it wasn’t the first network-connected service, but it was the first method that cross-linked data. “Binding your tools together and linking information gives you similar ways to traverse information in your company without the need to collect it into one place.”
Integrations are the answer
For Linear — like for GitBook — the solution is integrations. “There is only so much collaboration that you can fit into a single tool and people tend to do what is most convenient for them in the moment,” says Jori. “We know this is a reality with Linear as well and we want to integrate with the tools our customers use most and match the habits that already exist.”
Linear has integrations with dozens of services, allowing you to do things like automate GitHub pull requests and create issues automatically through Sentry. Bringing Linear into the tools people already use reduces friction in the information flow. “People are busy, and manually moving information is time consuming. So as much as we can we try to make it easy, no matter what app you currently have open,” says Jori.
“People are busy, and manually moving information is time consuming. So as much as we can we try to make it easy, no matter what app you currently have open.”
Moving knowledge internally
That’s great news for Linear’s customers, but the team follows similar practices internally, too. So when it comes to updating their public API and developer documentation, everyone is encouraged to collaborate — in GitBook.
“We’ve been using GitBook for our documentation for a few years now,” says Jori. “Linear is a small team […] so everyone in the engineering team is responsible for working on the public API and updating the documentation in GitBook.” And because of that smaller team, Jori explains it’s typically the developer that made the changes who takes a first pass at the documentation.
Once they’ve got a first draft, they share it with the rest of the team for changes and feedback. Because the API is stable, they don’t need to make updates every day — but when the team does make one, diff view helps them see what’s changed fast. Ultimately, keeping their workflow consistent is key — especially as the team is fully remote. “At Linear all engineers work in a monorepo, and we try to maintain the same standards and practices across the engineering organization.”
Creating great documentation
But outside of consistent, detailed updates, how do the team make sure their docs are good? According to Jori, the answer is pretty simple — keep it relevant.
“We only add information that’s useful for our users — it should be clear and to the point,” he says. But the key is developers taking a major role. “As the writers of the documentation are also consumers of the information, they know the most important information to include.”
“The best documentation is what’s findable and up to date,” Jori continues. And if you fail at either of those, documenting things is not really worth it.”
“The best documentation is what’s findable and up to date.”
Internal documentation and support
The processes the team have put in place work well for public documentation — but what about sharing internal knowledge? For Jori and the team, it’s all about content that will be useful both today and in the future.
“Some internal processes we do document into our engineering wiki, but there we try to focus on short, evergreen content,” he explains. Because the team is always busy, information has to be accessible fast. Again, it comes back to what Jori said before — if people can’t find the information they need, or it takes too long to consume, it’s not worth documenting it in the first place.
The same applies when it comes to support — but there, it’s as much about keeping the support team close to engineering as it is about documenting things well. “Bringing support teams closer to engineering and product is key to building products for your users,” says Jori. For the Linear team, creating silos for these two teams creates an unhealthy product culture.
“Bringing support teams closer to engineering and product is key to building products for your users.”
That’s why the customer experience team report bugs and requests to the engineering team constantly, who in turn take great pride in addressing them. “When we ship an update that addresses a request, Linear automatically notifies our support team so they can update the customer,” says Jori. And that tight feedback loop is just one reason why Linear has great customer satisfaction. “At Linear, we treat support as part of the product experience alongside the code we write.” It’s no wonder Linear has so many die-hard fans.
A huge thanks to Jori for taking the time to talk to us — we were thrilled to hear that the Linear team are on a similar path to us, and have such a similar ethos! Like them, our goal is to make it easier to find information throughout your development workflow, and use it to write great documentation for teammates and users.
Head to Linear’s website to find out more about the tool, and check out our beta page to discover what the future of GitBook looks like.
→ See the future of GitBook on our beta page
Helping people share their information — and then using that information effectively — is key in any organization. But for Linear, just like here at GitBook, the whole business is about making that information easy to document, discover and share.
So we sat down with Jori Lallo, one of Linear’s co-founders, to discuss their approach to knowledge sharing, and find out how they use GitBook to help that process along.
A frictionless information flow
The team’s main objective is to make using Linear feel frictionless. “That leads people to capture more high quality information in Linear,” says Jori. While many teams start by simply managing individual bugs and tasks in Linear, this typically evolves into them using it for project work as well. “And that opens up another challenge for us — to help you capture the information you need for your projects, while also helping surface relevant data when you need it.”
We can relate. Here at GitBook, we’re on a similar journey — and while our two platforms handle different kinds of information within the development flow, the challenges we face are strikingly similar. And just like us, the Linear team understands that bringing different strands of knowledge together adds valuable context to help you understand the bigger picture.
“We think that how you link information can have a significant impact in how you build knowledge,” says Jori. He likens it to the world-wide web — it wasn’t the first network-connected service, but it was the first method that cross-linked data. “Binding your tools together and linking information gives you similar ways to traverse information in your company without the need to collect it into one place.”
Integrations are the answer
For Linear — like for GitBook — the solution is integrations. “There is only so much collaboration that you can fit into a single tool and people tend to do what is most convenient for them in the moment,” says Jori. “We know this is a reality with Linear as well and we want to integrate with the tools our customers use most and match the habits that already exist.”
Linear has integrations with dozens of services, allowing you to do things like automate GitHub pull requests and create issues automatically through Sentry. Bringing Linear into the tools people already use reduces friction in the information flow. “People are busy, and manually moving information is time consuming. So as much as we can we try to make it easy, no matter what app you currently have open,” says Jori.
“People are busy, and manually moving information is time consuming. So as much as we can we try to make it easy, no matter what app you currently have open.”
Moving knowledge internally
That’s great news for Linear’s customers, but the team follows similar practices internally, too. So when it comes to updating their public API and developer documentation, everyone is encouraged to collaborate — in GitBook.
“We’ve been using GitBook for our documentation for a few years now,” says Jori. “Linear is a small team […] so everyone in the engineering team is responsible for working on the public API and updating the documentation in GitBook.” And because of that smaller team, Jori explains it’s typically the developer that made the changes who takes a first pass at the documentation.
Once they’ve got a first draft, they share it with the rest of the team for changes and feedback. Because the API is stable, they don’t need to make updates every day — but when the team does make one, diff view helps them see what’s changed fast. Ultimately, keeping their workflow consistent is key — especially as the team is fully remote. “At Linear all engineers work in a monorepo, and we try to maintain the same standards and practices across the engineering organization.”
Creating great documentation
But outside of consistent, detailed updates, how do the team make sure their docs are good? According to Jori, the answer is pretty simple — keep it relevant.
“We only add information that’s useful for our users — it should be clear and to the point,” he says. But the key is developers taking a major role. “As the writers of the documentation are also consumers of the information, they know the most important information to include.”
“The best documentation is what’s findable and up to date,” Jori continues. And if you fail at either of those, documenting things is not really worth it.”
“The best documentation is what’s findable and up to date.”
Internal documentation and support
The processes the team have put in place work well for public documentation — but what about sharing internal knowledge? For Jori and the team, it’s all about content that will be useful both today and in the future.
“Some internal processes we do document into our engineering wiki, but there we try to focus on short, evergreen content,” he explains. Because the team is always busy, information has to be accessible fast. Again, it comes back to what Jori said before — if people can’t find the information they need, or it takes too long to consume, it’s not worth documenting it in the first place.
The same applies when it comes to support — but there, it’s as much about keeping the support team close to engineering as it is about documenting things well. “Bringing support teams closer to engineering and product is key to building products for your users,” says Jori. For the Linear team, creating silos for these two teams creates an unhealthy product culture.
“Bringing support teams closer to engineering and product is key to building products for your users.”
That’s why the customer experience team report bugs and requests to the engineering team constantly, who in turn take great pride in addressing them. “When we ship an update that addresses a request, Linear automatically notifies our support team so they can update the customer,” says Jori. And that tight feedback loop is just one reason why Linear has great customer satisfaction. “At Linear, we treat support as part of the product experience alongside the code we write.” It’s no wonder Linear has so many die-hard fans.
A huge thanks to Jori for taking the time to talk to us — we were thrilled to hear that the Linear team are on a similar path to us, and have such a similar ethos! Like them, our goal is to make it easier to find information throughout your development workflow, and use it to write great documentation for teammates and users.
Head to Linear’s website to find out more about the tool, and check out our beta page to discover what the future of GitBook looks like.
→ See the future of GitBook on our beta page
Get the GitBook newsletter
Get the latest product news, useful resources and more in your inbox. 130k+ people read it every month.
Similar posts
Get started for free
Play around with GitBook and set up your docs for free. Add your team and pay when you’re ready.
Get started for free
Play around with GitBook and set up your docs for free. Add your team and pay when you’re ready.
