Making DevTools more human with Carla Sofia Teixeira from Miro
Carla Sofia Teixeira's rule for community: give something first, without asking for anything back. Not because it's clever growth tactics, but because flipping the usual ask-then-give order is what actually makes a developer feel like the relationship isn't purely transactional.
Carla Sofia Teixeira is developer relations program manager at Miro, where she's helping build awareness for Miro's developer platform — a REST API, a web SDK for building apps inside Miro boards, and live embeds — launched as V2 in May, still relatively unknown despite Miro's huge existing user base.
We get into her four pillars of DevRel — outreach, product, education and support, and community — and how 'humanness' shows up concretely in each one, from writing developer testimonials instead of feature lists, to closing the feedback loop after every request, to treating community contributors like respected stakeholders rather than assuming they already have context.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does 'humanness' actually mean in the context of developer tools?
There's a Simon Sinek quote I love: we don't do business with companies, we do business with people — business is always human. If you think back to genuinely good experiences you've had with a vendor or a company, there's usually a person on the other side you connected with, and that connection directly translates into higher retention — people who feel that connection keep subscribing, keep buying. The inverse is just as real: a great product with a terrible support experience will still lose you as a customer. As humans we want to connect, feel understood, and find things we relate to, and developer relations is fundamentally about relationships and connections with developers — leaning into that authentically, not as a tactic to extract more value, is where the real impact comes from.
You've described four pillars of DevRel. What are they, and how does 'humanness' show up in outreach specifically?
The four pillars are outreach, product, community, and education and support. In outreach, it's about how you communicate what the product does — sharing a genuinely human message and showing real value instead of just claiming to be the best. With so many competing tools out there, a developer searching for a solution will see too many options to meaningfully evaluate all of them, so standing out with something that feels human rather than purely promotional is a real advantage. Concretely, that might mean writing a blog post from another developer's actual experience using the tool, rather than one from the company — developers trust another developer's opinion more than a company's claims about itself.
Is that trust in other developers' opinions really about emotion, or is it more practical than that?
I'd frame it less as developers being emotional and more as pure pragmatism — they have a limited amount of time to get something done, so they're asking which tool they've actually heard of, which one seems more credible, and which one puts the information in front of them fastest. With five options in front of you, most people won't go hunting for a sixth. That's why it matters to actually meet developers where they already are — I like the exercise of putting yourself in a developer's shoes, thinking through their actual daily routine, when they take breaks, when they have spare attention, and building your communication plan around those real rhythms rather than your own convenient schedule. A lot of that is available through existing market research, and the rest you can get just by asking simple questions directly, like what newsletters someone reads or when they'd want to hear a story from you.
How does 'humanness' apply to the product pillar of DevRel?
Two things mainly: genuinely looking at developer feedback, whether through usage analytics or direct conversations, to understand if what you've built is actually helping; and taking feature requests seriously enough to feed them into the roadmap. When you actually build something a developer asked for, they feel like they were part of the journey, which makes them far less likely to churn and far more likely to talk about it to others — everyone remembers the feeling of being heard and then seeing it happen. It also directly improves product-market fit, since you're building what the market is actually asking for rather than guessing in a closed room. Early access programs work the same way — they validate a feature before full launch, and they create genuine advocates, because being invited into something exclusive early makes people feel connected and more likely to spread the word themselves.
You've emphasized closing the feedback loop. Why does that matter so much, and how do you actually keep up with it?
Whenever you ask someone for feedback or help, you have to circle back — even just a quick thank you and a status update. It's easy to let this slip because so much is happening at once, we're only human. I think it helps to deliberately build a small system for it — a standard reminder or message template — rather than relying on remembering every single person you owe an update to. It sounds small, but it genuinely makes a difference to the person on the other end.
How should education content differ from support, and what should teams keep in mind when building it?
Education is proactive, support is reactive — but for education specifically, people don't all learn the same way, so having content across multiple formats — visual, written, video — matters, since someone who prefers video will simply go to a competitor if you don't have any. That said, you can't do everything perfectly from day one — start with something and build from there, and think from the outset about creating content in ways that are reusable across formats rather than one-off. It's also worth understanding what actually motivates someone to keep learning with your tool — if someone wants to become genuinely excellent in a specific area and your tool can help them get there, that's an additional reason for them to stick around, and recognizing progress with things like badges or certificates can make that process more engaging, even a little competitive, which a lot of developers respond well to.
Does it matter that different people are engaging with a tool for very different reasons — a hobbyist versus someone building their career on it?
It matters a lot, and it's genuinely hard to account for in metrics. Someone learning casually on Sunday afternoons and someone deliberately building career expertise will engage completely differently, and technically, if both are putting in equivalent relative effort, their outcomes are equally 'successful,' even if the timelines look wildly different on paper. It's hard to formalize that into clean metrics without going too deep into the weeds, but just having the awareness that these different profiles exist within your community changes how you think about things like response-time expectations in support — someone building their career genuinely needs a fast answer, while someone doing a side project will still appreciate a quick reply but won't be devastated by a two-day wait.
What does a genuinely human approach to support actually look like when someone's already frustrated?
Approach every interaction with real empathy — you don't know what's happening on the other side of that support ticket. They might have just been told by their manager to fix this or be out, or they might not have slept because they were caring for a sick family member. You can't know, but you can choose to respond with real compassion rather than a curt, purely functional answer, and that difference genuinely comes through in how a message lands, especially for someone already having a bad day. Being honest and transparent matters just as much — don't promise a specific date for something you don't control. If you don't know exactly when a feature ships, say you're working on it and will share an update once you have one, rather than committing to a date that might change for reasons entirely outside your control.
Does community fit into support in a specific way?
There's a real bridge between the two — beyond official ticket-based support, spaces like forums let other community members help each other directly, so you're not the sole source of every answer. That capability doesn't exist from day one, though — it requires building a community that genuinely wants to help others, creating a space where that kind of contribution is recognized and incentivized, sometimes formally through something like a Champions program.
You mentioned flipping the usual give-and-take order in community building. What does that mean?
We often ask developers for things — feedback, contributions, participation — and then offer something in return. Flipping that, giving something first with no expectation attached, just to say 'you're doing great work,' makes a real impression precisely because there's no hidden ask behind it. A developer spotlight in a newsletter is a simple, concrete example — it gives someone genuine visibility and a platform for their own work, and that kind of unprompted recognition sticks with people in a way that a scripted ask-then-thank-you sequence never quite does.
How should DevRel think about the people who become active community contributors or helpers?
Treat them like interns you deeply respect as real stakeholders — meaning, assume they don't have the context you take for granted, and give them everything they need rather than assuming it's obvious. At the same time, respect that their opinions matter and keep them genuinely informed and involved, even if they don't need every internal detail of a program's business goals. Community, done well, becomes something like an extended team — people who help with support, help with outreach, help spread the word — but that only works if you're reaching out to individuals directly and personally, the way you'd check in on a friend, rather than only ever posting generic messages into a shared channel.
What are the key takeaways you'd want people to remember from all of this?
Be empathetic — you never know what's actually going on for the person on the other side. Build and maintain trust through transparency, and never over-promise things outside your control. Use inclusive language and formats, since people consume information differently. And be respectful of the time people are investing in exploring or contributing to your product or community — help them the way you'd want to be helped yourself. At the end of the day, developer relations is the human side of a company, for better or worse, and keeping that front of mind is what makes someone's experience with a tool feel human rather than transactional.