When I worked at Facebook in the early days, we used to talk a lot about what would be “the new Facebook”, because if we didn’t become the “new Facebook”, there was a hundred YC startups that surely would. There was a definite sense of urgency around shipping new code.
This sense of urgency is, in my opinion, the true meaning of “Move Fast and Break Things”. It wasn’t about carelessness and disregard for users, although sometimes it did unfortunately manifest that way. Instead it was about accepting a certain amount of risk you’d break something in return for the perceived upside of forward momentum, because with so many companies wanting to be the next Facebook, if we weren’t moving forwards, we were moving backwards.
Obviously that hasn’t yet come to pass in the truest sense of the Facebook being toppled as a company, but the sentiment still rings true, regardless of what your product is. It’s kind of like what Reid Hoffman says.
If you’re not embarrassed by the first version of your product, you’ve launched too late
When I hear that phrase, what comes to me is this - What you build will never be perfect. You can spend an eternity on polish. In fact, it can drag down your whole organization. It’s infinitely better to ship what you have and iterate. Obviously there’s a quality bar to meet depending on your product. A pacemaker has a higher bar, than say, an app to connect people for dating. But as much as possible, all your processes should bias to releasing what you have at that moment.
The cost of iteration
For software, the cost of iteration has never been lower. Infra as a service, feature flags, CI/CD as a service, and much more have created an environment that enables increasing faster development cycles.
As an example, these days when bad code is committed to a code base, it’s sometimes quicker and easier to fail forward than it is to revert. When you’re dealing with a primarily server based piece of software, you can keep rolling deploys and get a fix out much easier than the days of floppy disks and gold master CDs, so you have an inherently lower risk profile, and as an industry, we should be leaning into that, not getting ever more cautious.
Feedback fuels the best products in the world
The reason you should be doing this is because feedback is the lifeblood of a good product. Ship the smallest possible unit, get feedback, iterate. Repeat.
As you iterate, you’re refining, you’re improving, you’re getting closer to something that solves a need for your users.
Move a pixel, nudge a button, publish a blog post, knock a few ms off a load time by sorting a collection differently. Whatever releasing means to you, be doing it.
Iteration as a super power
If, like me, you work as a Developer Advocate, then encouraging Product Managers to incorporate feedback from the community and getting other engineers to push that code into the hands of that same community in order to get more feedback should be a critical effort of your team. You and your community are direct benefactors of the historically low cost of iteration in modern software, so use it as a super power to deliver an ever improving platform for the developers you serve.
Much to my own surprise, a number of people have been asking me lately how they should approach working in Developer Relations. After listening to the excellent Twitter Spaces Panel the other day, I was inspired to write down some of my thoughts on how people can refine the craft of working with their Developer Community. I hope this advice is as valuable for someone considering moving into DevRel as it is for a seasoned practitioner.
It’s important to say though, this is less me prescribing the perfect formula of being a Developer Advocate / Community Manager / pick your DevRel title, and more about what works for me, because I am far from perfect at this and have actively been trying to improve what I do. In fact, the mere writing of this is part of my process, which leads me to my first suggestion.
Create more content
What this looks like for you depends on the medium you feel most comfortable with. Some people like to write blog posts or books, others want to stream on twitch or pre-record a presentation. And some people want to churn out sample code. Whatever works. What’s important is building a better creative muscle.
Think of it like getting healthy through running. It doesn’t matter how long you run, it’s about lacing up, getting out there and forming a habit. In this case, the habit is content creation.
For me, the easiest thing tends to be written pieces. Every time I have an idea for some content, I immediately take out my phone and write it down. I’ll revisit and refine it until I have the bones of something to work with, then I’ll publish.
So write a bit, don’t worry about word count or over refining it. Just write something and share it. Next time you can write a bit more. And the time after that, and the time after that, and so on.
Soon you’ll find yourself writing/recording so much that you’re needing to edit it down, and isn’t that a great position to be in?
Be curious
I believe that in order to succeed in Developer Relations, you might not need a formal software education, but you do need to have a thirst for learning. You should be trying out new technologies regularly, even if they’re not 100% related to the platform you work with.
It can sometimes be difficult to find the time to do this. The things on your to-do list are like a gas, they’ll expand to fill the amount of time you give them. So don’t give them all of your time. Consciously make time for learning.
This doesn’t always mean doing it in your spare time. Work life balance is vital, especially once we get back to a world of traveling for events. This is professional development, and if your organization doesn’t give you time to learn, then honestly, if you can, you should start looking for one that will.
Be generous
As much as you can afford to, be generous with your time and your knowledge. People are genuinely curious and a big part of DevRel is sharing what you know.
Sometimes it’ll be about what it is that you do, sometimes it’ll be someone asking for advice about how to succeed on your platform. Sometimes people will just want to pitch you an idea for feedback. Whatever it is, make the time. Grab that coffee, give that talk, hop on that zoom.
If you make time for the various communities that you work with, then they’re more likely return that generosity when you come calling.
Be developer zero
You should constantly be putting yourself in the shoes of your community by building against the platform you work on. Before a new feature sees the light of day on your platform, your team should have built against it.
This isn’t a formal QA process. QA is an incredibly specific field with many excellent practitioners, and DevRel shouldn’t be one of them. This is about getting a feel for the feature and the APIs it exposes. Do the patterns feel right? Does the contract make sense? Is it all intuitive? These are the questions you’re trying to answer.
Perhaps most importantly for your community, you’ll be better placed to help them see the benefits of a feature if you’ve used it yourself and understand its quirks. Plus you can open source the code when you’re done and you’ve seeded the library of sample code for that feature.
Work closely with Product Managers
When I talk about being Developer Zero and the kinds of questions you should be asking when trying a new feature, what I’m really trying to give you is a list of things you should be talking to the relevant Product Manager about. Your relationship with Product Managers will be key to how effectively you can advocate for the views of the developers you serve, so cultivate them.
Ultimately, the relationship you have with your PMs will depend on your organization, but I think ideally you want to get to a place whereby PMs are actively seeking out your feedback as early as possible in the design stage of a feature. Be their trusted partner. Don’t ring their bell for every single piece of feedback. Watch for patterns in the community and surface them.
Practice Empathy
My final piece of advice is this - Be empathic with those in your community. Assume their best intent. They want to learn - after all, they raise bugs and suggest features because they share your passion for the platform you have the privilege of working on.
What seems incredibly obvious to you may well have been blocking them for hours/days/weeks.
Besides - some of the best insights I’ve learned about the products I work on have always come from the community. They offer a perspective that an insider won’t always have.
Just remember, while you may have answered the same question a million times, this is their first time asking you, and if they’re asking you, then it’s important to them. Respect that and respect them, it’s the least they deserve.
I’ll be upfront and say that I’m probably not the best at living up to these traits. And I’m not sure that anyone is 100% at all of them. Ultimately the best we can ever do is strive to improve, and that’s what I’m trying to do. I hope you feel like you’re improving too.
Tech companies do a fantastic job on their career sites of talking about all the amazing perks they offer. Free food as far as the eye can see, the latest hardware and eye-popping salaries. But at the best companies, the real perk is something else.
The older I get, the more I realise the real perk I derived from working at Facebook wasn’t the money, the benefits, the amazing facilities or even the fantastic product I had the privilege of working on.
The thing that was truly incredible was the caliber of people who I could call my co-workers. I got to regularly hear from the likes of Mark Zuckerberg, Mike Schroepfer, Chris Cox and Sheryl Sandberg.
Mark Zuckerberg answering questions at a Town Hall.
And those are just the people who are widely known. There were countless others at all levels who are some of the most intelligent people I have ever known.
Sheryl’s commencement address to UC Berkeley is impressive viewed by itself, but is ordinary in the sense that she brought the same level of passion and insight every time I heard her speak, whether to a small group or a large crowd. I’m lucky to have heard her speak on so many occasions.
I guess the point I’m trying to make here is that, when you’re evaluating opportunities at a company, especially early on in your career, be sure to look beyond what’s in your contract.
Salary, benefits, perks etc are important and should of course be a part of your decision, but focus more on the product or service, and the people who have already chosen to be involved with the company. The lessons you will learn from being surrounded by smart people and leaders in their field will stay with you long after you have finished your last free meal or spent your final paycheque from that company.
I’ve just finished reading Disrupted by Dan Lyons. Apart from finding it hilarious, which I did, it offers a somewhat scathing critique of how a modern technology company operates.
I’ve spent the majority of my career working for the kinds of companies that fall into this bucket, and it was interesting to see a different perspective on what’s generally referred to as “startup culture”.
I joined Facebook about two months after my 27th birthday and loved it. I completely bought into the culture of Hackathons, Happy Hours and the various perks (free foods, high end equipment etc).
As I’ve gotten older (and I’m only 33 as of writing), I’ve started to become far more conscious of how geared this culture is to a particular life stage. At any number of companies, the “culture” is defined by all-night, weekend and evening events.
Take meetups for instance. In Dublin, these take place almost exclusively on a weekday evening, around 7pm-ish. Now I love hearing about new technologies and discussing the various challenges of framework X over a slice of pizza as much as the next techie, but when it comes to a choice between that and having dinner with my kids before putting them to bed, I know which one I’m picking.
I’ve never worked as an accountant, but I can’t imagine they learn about the intricacies of Capital Gains Tax over a slice of pepperoni and a beer some evening
In other industries, Continuing Professional Development (CPD) is seen as part and parcel of the job. Medical professionals practice new techniques, accountants learn about this year’s tax code. Now I’ve never worked as an accountant, but I can’t imagine they learn about the intricacies of Capital Gains Tax over a slice of pepperoni and a beer some evening. They do it during working hours at organised professional events.
Dinner for 50 please
Going to a meetup has a social element, sure. But what’s so wrong with that? A company’s best source of referrals are existing employees and this is where employees make the connections to people who could be your next Engineering Manager / iOS Developer / SRE.
Put simply, we have to create a culture where people can, and should be encouraged to, attend daytime meetups. Even going as kind of an extended lunch break would be more inclusive than the current situation. Having employees who are familiar with the latest trends in their field can only be good for your company and expecting people to learn it all in their personal time is not much different from expecting them to work for free.
But of course, before people can attend daytime meetups, those events need to exist! If you organise a meetup in your area, I implore you to at least experiment with hosting one during the day. It might be challenging to find a venue at first (since most meetups are in offices after hours), but once you do, I think you’re going to get a much more diverse audience, which will lead to some really interesting conversations.
I’m willing to bet that almost every app update installed on your device in the last 12 months has had that exact set of release notes, or something extremely similar.
Release notes have become something of a differentiator in the App Store, ranging from generic, to witty, to extremely detailed like release notes in the days of physical media.
Whilst some believe it’s incumbent on us as developers to provide release notes to the people who use our products, the reality is that for consumer facing software (as opposed to APIs/SDKs) they are no longer relevant to modern application development.
No two users are alike
Modern mobile applications, like most online services, are primarily controlled via an API. New features are hidden behind feature flags, some features aren’t exposed on mobile if you haven’t paid for it and every customer uses your product slightly differently, so there’s no way to accurately describe what they’ll see when they open the app.
Release notes are bad place to introduce features
Traditionally, release notes were a place for you to explain to people about changes you’d introduced in this build of your application. But realistically, a wall of largely unformatted text is a pretty terrible way to introduce a feature you’ve spent time building.
Many applications now choose to introduce features with some kind of in-app user tutorial or notification, where you can measure things like conversion rates, get customer feedback etc. These are the modern iteration of “release notes”.
The two main mobile platforms auto-update
One of the big reasons not to do release notes these days is that both of the major mobile platforms ship with auto updating enabled, so depending on the make-up of your userbase, most people may never even see the app store release notes.
So the next time you’re getting ready to release a new feature, consider this – should you spend those last few hours polishing and testing, or should you write a pile of release notes that almost no-one is going to read? I know where I’m going to spend my time.
