As a society, we’re hyper focused on creating things and processes that make our lives easier and more efficient. From Ubering somewhere instead of braving through a long walk, to tackling chores through multitasking, we’re always looking for ways to be as efficient as possible.
This sentiment is directly translated to our views on software development, too.
For this issue of Developer Decoded, I had the privilege of interviewing Amara (Keller) Graham, the Head of Developer Experience at Camunda! One faithful LinkedIn connect message lead to the next and suddenly I was able to converse with Amara about her life, job, and aspirations for the DevEx space (thank you, again)!
Amara works on creating a better developer experience by lowering the barriers for developers to complete their tasks- whether it’s by providing key documentation or making important resources readily discoverable, Amara does it all to make developers more efficient. With 10+ years of development experience herself, Amara is pushing the boundaries of development and developer relations in practices all over the globe!
That being said, here is our DevEx issue of Developer Decoded! If you’re interested in participating in these yourself, please fill out this form!
Outside of work I try to get away from my desk and computer as much as possible. I love cooking new recipes, brewing beer, and shopping local at the farmer’s market. I also enjoy video games on the Nintendo Switch.
As the Head of Developer Experience, I manage a team focused on enabling developers to use Camunda Platform 8 efficiently and successfully. We are responsible for our documentation and API strategy, including our emerging SDKs.
This means I act as both an engineering manager and a product manager, setting the direction for how developers can work with Camunda Platform 8 programmatically and how all users can find what they need in the docs.
We do almost everything on GitHub, so my day starts with triaging anything that came in overnight from the EMEA colleagues to unblock them during our brief overlap in working hours. Then after some 1:1s with my team or various stakeholders across the company, I may do some IC work to keep my team focused on their larger projects. This could be checking in on docs fixed or monitoring our docs SEO. Some days I may work on internal documentation for cross-functional work that gets baked into strategy docs. No two days are the same!
What goodness does this unlock, or what problem does this solve?
New initiatives may do both, but this can separate foundational work from growth opportunities. Both are important, but with a team like mine that has a lot of empathy, we tend to always side with, "well, users feel friction here, so we must fix it ASAP!" As with many things in life we need moderation and balance.
If you asked me what 3 questions I use as guiding questions for DevEx, I have a slightly different answer:
-Are developers getting what they need?
-Are developers getting what they need efficiently?
-Could you optimize the efficiency?
The short answer is that we monitor many things, but it ultimately depends on the goal.
In docs, for example, we look at SEO aspects because we know the bulk of our users come from search engines into pages of the docs. We want to make sure new pages are discoverable, so we look at vanity metrics like views. But as pages mature, we look at time on page, what pages are in their journey as they click around in the docs, and what search terms lead them to that page - more engagement metrics. Success here is aligning our users' behaviors in and around docs with how we present the docs to them.
Our SDK area of focus is brand new, so we look at product metrics via tools like Mixpanel to see how many users are working with programming language-specific clients. We look for anecdotes to validate our approach.
In general, we want to reduce the overall burden on internal teams by monitoring topics on technical support tickets and community spaces. We have dashboards in JIRA and Common Room that help us here.
This is a fantastic question!
Developer Experience at Camunda is part of the Engineering team and acts as a product team. However, we also have plenty of support team aspects as well.
Balancing new product-oriented features like new SDKs or fresh code examples with documentation reviews and docs infra support can be challenging, particularly when everyone wants to be agile and move quickly. We have to be flexible but also set boundaries and clear expectations.
Developer Experience remains largely the same, but the branding becomes even more critical.
At its core, DevEx is still enabling developers to be efficient and successful. For some companies, that focus will be internal through teams supporting infrastructure pipelines, DevOps, or platforms, and for others, that will be an external focus.
Many more unknowns exist when your DevEx focus is external, like ours. You can have teams running different tools, tech stacks, and configurations than your happy path, emphasizing your internal collaboration and negotiation skills with product management to prioritize those differences. Then you inevitably need to think about supporting many different paths and tools. It's a forcing function for truly cross-functional work.
DevEx at Camunda is investing more in our SDK mission! We look to fully support Java Spring, Node.js, and .NET/C# with SDKs to work with Camunda Platform 8. These currently exist as community-supported clients, but to really embrace our polyglot strategy, we need to give them some more structure and priority.
This opens us up to more opportunities for feedback, dogfooding, and meeting our developer community where they are at!
99 South Almaden Blvd. Suite 600
San Jose, CA
Jl. Pluit Indah 168B-G, Pluit Penjaringan,
Jakarta Utara, DKI Jakarta