The evolving developer ecosystem convinced Satwik & Rohit that Freshworks needed a developer relations team. They set up one four years ago. Although they had no formal DevRel experience, they would figure things out independently. They took a leap of faith.

One of the things that kept me excited about the fronting developer experience at Freshworks is its breadth of work opportunities.

There's always enough work to:

Advocacy: Influence product API and platform engineering teams' design and implementation practices by gathering developer feedback.
Enablement: Create educational content that helps developers improve their web development skills and advance their careers.
Experience: Define procedures and standardized engineering documents, PRDs, and code reviews to ensure a consistent and high-quality development experience.
Community: Foster community within your developer ecosystem by encouraging collaboration and problem-solving.
Engagement: Motivate developers to contribute, give feedback, and improve their skills by creating incentives and recognition programs.
Awareness: There are always new platform evolutions for the developers that keep adding value to the developer community

I present the following picture from Mary's blog to articulate the opportunity when hiring new advocates for our team.

Opportunity

From a developer's shoes, the developer experience constitutes the combination of all these segments. It does not matter how we get this experience to the developers, but does the ideal experience exist?

Satwik strongly believed in building a team that complemented each other's skills so that, as a team, we could deliver the ideal experience to the developers, if not individually. This is amazing because, unlike others in the industry where DevRel is heavily leaning towards either evangelism or advocacy, this approach is the best foundation to leverage balance in the DevRel position.

Challenge

Grabbing the opportunity means we had to build ways to consume the work routinely to help us build fully-rounded skills and experience. We tried a couple of ways —

Kanban Board

The Kanban board on Trello has effectively tracked specific work types but has yet to be more helpful for others. You've found that certain swimlanes, including "In Review," may not be pertinent or useful for particular tasks like program management or ad-hoc assignments. However, the team has discovered that this board format has successfully tracked work like writing blog content or refactoring code.

Personal Trackers and Standups

We even took the liberty of counting on the team members to have their projects and responsibilities tracked, done, and shipped in their own ways. The smallest visibility into each other was weekly standups, daily Slack updates, and monthly goal reflections.

This was helpful for the members who knew how they would achieve their goals. Still, for the team who needed help, there needed to be recurring opportunities to get help by default.
Our leaders would need help to learn the progress on the projects given to our team, embarrassingly, could have been more significant at posting clear updates daily.

Freshworks' Classic Agile (Voluntary)

I tried cleaning up our internal ticketing system (think Jira). I started setting up tool interfaces best suited to our DevRel and Tech Writing team. However, I did not use authority, nor did I have one to enforce its usage thinking it could not have been a promising approach. A few weeks later, only I and one other were using the system.

The hope is that team members will adopt it voluntarily, even after gathering feedback or customizing sprints to be monthly.
Our leaders have the same problem of having difficulty understanding progress unless they specifically ask the team members.
This approach expected us to have a product manager we did not have during this time.

On the Table

The more time passes, the more we squander our time.

The top two contenders were following.

Comet (Recommended Agile by Shape Up) — After a year of trying systems out, it was my best bet for a proposal I want to bring to our DevRel team.
Enforced Classic Agile — Leverage the existing experience of people in their past organizations and use authority to enforce work in Agile for engineering teams.

Enforced Classic Agile

To me, it appeared like this:

I foresee a few red flags with it:

To the engineering leaders from the outside, the performance of the DevRel team will be measured by other engineering teams ignoring the nuances. How fair is it?
It discourages high agency in individuals and paints the picture in black and white; there's work to do that's straightforward, or there's a dependency one wouldn't care about.
For example, if DevRel needs a review from the engineering team/would want to review marketing work/would like the product team to prioritize a task, all of them are treated as dependencies or ad-hoc items. The result is to wait until this is someone else's problem to help you unblock, whereas unblocking yourself through effective collaboration isn't rewarded.
Overall, conventional wisdom from the people in authority would start expecting DevRels as "task doers" on fully defined projects (by a product manager). In contrast, unknowns pop up 60% more frequently than usual engineering teams where Design and Scope can permanently be frozen strictly with systems. While this is different for people programs such as champions programs.
Finally, DevRels proactive focus on collaborating with marketing, engineering, support, and product teams is not rewarded against meeting sprint goals limiting the ability to become partners. Hence constraining the generalist experience Freshworks can offer.

Comet (fork of Shape Up)

It will take a separate blog for me to expand the details in actionable ways to your DevRel team. I will only share a glimpse of it in this section.

But here's how it would appear to you:

It creates separate projects with necessary talent groups (marketing, engineering) representatives' commitment upfront, allowing predictability.
There would be Epic level view for anyone gauging DX, especially to translate work to upper management.
The Housekeeping and Adhoc work will get their reservations, and PM/EM will have the opportunity to align work to an advocate based on missing areas of the generalist skillset a dev advocate wants to grow into.
A huge possibility of asynchronous collaboration and decision-making. For example, each task can seamlessly keep every project-level stakeholder, irrespective of talent group, to get inputs and move on without labeling everything a dependency.
Allows more developer advocates to participate in the product creation process alongside product managers rather than acting as "task doers" on fully defined projects since we assume it can never be fully defined without mutually.

Closing

It is deeply satisfying to be able to think in this direction and able to Rethink Existing Practices from 0 -> 1.

In this blog, I describe Comet and the problems it will solve for a generalist DevRel team. I hope you'd like it and let me know if you do.

Optimizing DevRel for Generalists: A New Team Practice [Part 1]