I helped establish the developer relations team at Freshworks as a founding member, working to improve the visibility of developers within the Company. I will describe a practice I put together that I am particularly proud of on this page. This practice impressed me with its ability to address a broad range of Developer Experience problems.

Here's it in a glimpse:

Here is how it works

1. The company & team aspire to improve the developer experience through a few initiatives. They usually translate into Epics in the team's favorite tools like Jira. These Epics would imagine stories from the developer's shoes. For example, the developer should be able to get started with a guide on their first attempt.
2. Stories can be well defined — Add X capability to the sample app for developers for reference (or) they maybe need help to be well defined — Ensure developers can learn the new feature Y on the platform (How many tutorials? help articles? CLI updates? are unclear).
3. Clear stories will be taken up in a sprint via the project management tool that you would use. What about Unclear stories? They will be pitched to attract perspectives from the generalist team you already have.
4. The assignees of unclear stories would pitch a 1-page document with the following details:
   1. Problem — The raw idea, a use case, or something we've seen that motivates us to work on this
   2. Appetite — How much time we want to spend and how that constrains the solution
   3. Solution — The core elements we came up with are presented in a form that's easy for people to understand immediately.
   4. Collaboration — Identified any dependencies? Call them out.
   5. Rabbit holes — Details about the solution worth calling out to avoid problems
   6. No-gos — Anything expressly excluded from the concept: functionality or use cases we intentionally aren't covering to fit the appetite or make the problem tractable
5. The team would discuss asynchronously until a grooming meeting that's scheduled. The open items are closed in the grooming meeting; ideally, well-defined work items flow into Basecamp or the project management tool.
6. Finally, use Retrospection meetings to find improvements and Demos to showcase internal awareness about what the DevRel team has delivered!

Problems with usual approaches

1. The DevRel team focuses on code, content, and community but reports to the engineering team, making it easier for coding team members to follow sprints. However, for example, community-building team members may face challenges in planning and executing events within the sprint cycles to show their progress. This situation could be better. 
2. The organizations tend to break up into squads where teammates focus on code, content, or community to drive efficiency. So a DevRel can only be a programmer, author, or program manager for a while (a few months?).
3. It's also more work to translate work up the hierarchy. For example, a DevRel team reporting to marketing may need to properly empathize and be resourceful to the team segment who would code because the focus is not on shipping software to a marketing reporter.
4. Career-wise, a DevRel would get lesser opportunities to overlap their work with other segments (code, content, or community).
5. The biggest drawback of having a generalist DevRel team is that it can be challenging to use insights from one area and apply them to others. For example, a DevRel team member focused on support can write specific tutorials developers want and host relevant and helpful workshops. It means that insights from support, content, and engagement are interconnected. Currently, only leaders of DX teams have the luxury of seeing these insights because they have reporters across all areas. However, these insights are crucial in defining the quality of work each DevRel team produces.

Problems that Comet Solves (and How)

1. Comet wanted to be a team practice that can serve the breadth of the DevRel role without worrying about which organization it reports to. However, the organization should welcome the practice (as an experiment for a few months) if the team can deliver better results. They can do this because phases like "shaping" and "building" are independent, allowing them to link from the desired place. For example, they use Basecamp but link it to Jira, so Engineering org can still see Jira. The same goes for other tools for Marketing or Product org.
2. Comet is an agile practice that uses some ideas from Shape Up to help the Company meet Developer Experience goals. Shape Up lets engineers join the product-making process, while Comet adds to it to let DevRels join the Experience making process.
3. Comet thinks the work should be done by projects. Different projects need different people. Comet lets only the needed people (like documentation, marketing, or engineers) work together and talk without distraction but also lets anyone join and give their opinions. Basecamp helps with this need.
4. The concept of Pitches distributes the role of product management to all the generalists to capture opinions, while a product manager can use them to define stories well with confidence. It covers the major drawback of applying insights in one place and applying them to the interconnected.
5. In theory, a DevRel can do code, content, and community, but not many companies help them grow in these areas. Comet makes a DevRel improve in many ways, openly and deeply.

Final thoughts