DEV Community: Colm Doyle

Developer Relations in 2022 - Where I'm focusing

Colm Doyle — Fri, 21 Jan 2022 14:00:00 +0000

Like many SaaS companies, the planning year at Slack runs from February to January, so we’re coming to the end of our planning process for the next 12 months.

One part of that process which is important in my role as Head of Developer Advocacy at Slack is recruiting and headcount planning. I need to make an ask for a specific number of hires, justify that, start working with recruiting to hire those people, etc etc.

As part of that, I’ve been thinking a lot about what it is that I want the team to achieve.

Obviously I need to consider what we’re doing through the lens of the company, but like any good leader, I try to consider what each individual on my team will get out of it. What skills will they learn to advance in their career, what will be transferable to other roles, other teams and more.

I think these skills could serve as a good blueprint for many small DevRel teams, so wanted to share them.

So with that, let me talk about what Slack’s Developer Advocates will be doing this year.

It’s all about the content

A big focus for us next year is massively upping our content game. More video, more blog posts, maybe some other mediums we haven’t considered yet.

Towards the latter half of 2021, we started to spin up what we’d consider mid-length videos, that is longer than 5 minutes, but less than 15.

Here’s a great example by Sandra, the most recent member of the team, who was speaking about using our App Home feature.

Then there’s also blog posts like this one from Jim Ray.

Whilst both of those example are very ”you already know and have bought into the idea of Slack”, we also want to start producing content which is more reflective of our amazing community of developers. At the end of the day, our platform exists to help people get things done more easily in Slack, whether that’s responding to incidents, managing their projects, or most importantly bragging about your wordle score, so we want to talk about the interesting things that our community are making, and even things that aren’t related to our APIs, but can still make your life easier, like offering a look at how we plan content, or build product, or launch features.

Here’s just a few of the things we want to tackle soon.

Once more unto the in-person events, dear friends

I still think 2022 will be very heavy on digital content, but like other organisations, we’re keeping a close eye on what a return to in-person looks like, so there’ll likely be some hybrid events too.

We already have at least one major event on the books in the form of TrailblazerDX 2022 this April, but as with everything, it will depend on COVID-19 and how safely we can run an event at the multiple thousands scale.

As I say though, I don’t know that any large event will ever be 100% in-person again. Hybrid is here to stay.

One message, many mediums

But fundamentally, COVID or otherwise, I think DevRel is a multimedia discipline now, so DevRel teams should have experience / an interest in generating content across all sorts of mediums.

There are so many ways to help your community, and make your content accessible to a wide range of folks, regardless of where they’re based, or their style of learning. We’re not there yet, but we want to be a team that generates content for our whole community.

In a practical sense, I think that knowledge of how to produce content in multiple formats is a table stakes skill for a DevRel professional today. You don’t have to be a world class video editor, but the idea of learning to slice together some video content in iMovie/Premiere Pro etc shouldn’t terrify you. The same can be said of audio. Voiceovers, podcasts, virtual workshops all require you to be confident speaking into a microphone.

Similarly, you need to be confident in your writing. Blog posts, tutorials, even tweets. The written word is still important, no matter how much video or audio you pump out.

I think what’s going to be interesting is how much we could leverage short form video for technical content. If you look at the success other industries are having with the likes of Instagram Reels, YouTube Shorts and TikTok, I can’t believe that it’s not going to be a useful way to get developer facing content to a new audience.

For some examples of folks who I think are doing this well, I always look at what GitHub and Stripe are doing. Michelle Mannering, BDougie and Chris Trag in particular from those teams are doing great stuff.

Staying close to the product

In a post last year, Getting better at Developer Relations, I spoke about the importance of being Developer Zero and working closely with Product Managers. I definitely still believe that to be true, and I’ve started to think more about how our team should balance that work with the content creation work.

When I do, I envisage it as a circular thing, because each part of a Developer Advocate’s job is wholly dependent on the other. You cannot create value for your community if you’re not pushing your product team to build things that solve their problems, and you cannot get valuable feedback to bring to your product team if you’re not sharing ideas, sharing information and ultimately building a relationship with your community.

If you’re only ever pitching your product, then congratulations, you work in Sales and Marketing, and I wish you well.

If you’re only ever having interesting technical conversations with people that don’t teach you more about how people use your platform, then congratulations, you’re a well funded distinguished engineer, and I wish you well.

Developer Relations / Advocacy sits somewhere in the messy middle. We are neither engineers who talk in the abstract and write fancy algorithms all day, nor are we marketing/sales people. You need to be comfortable living in that grey area.

At Slack, we sit inside the Product Organisation, alongside the Platform Product Managers, so it’s easy for us to build and maintain these relationships. Wherever your team sits though, you should put in the effort, as they’re one of the most important partners you have.

Always tighten the feedback loop

So what is 2022 at Slack Developer Advocacy? It’s about iterating on the loop I mention above, making it faster. Ship more content, ship better content, ship platform improvements, ship ever increasing value for our community , because ultimately, it’s them we’re here to serve, not the other way around.

If you’re as passionate about these things as I am, and want to join us, I’m always looking to talk with great people. As I write this post, I’m actively looking for people in Europe, and hope to soon be looking for people in North America. So drop me a DM on twitter, and let’s talk.

The best Incident Commanders might not be where you think

Colm Doyle — Tue, 01 Jun 2021 16:00:00 +0000

The Incident Commander is a powerful role in the world of Incident Management. Like Flight Directors in NASA missions, they have responsibility for the decisions made and actions taken during an incident. Depending on your company’s process, they may have powers like stopping deployments, commandeering staff or even shutting down the service. Whatever they deem necessary for resolving the incident.

In many software organizations, the Incident Commander is an on-call rotation, shared amongst senior members of the engineering team. And this seems logical right? Engineering managers and senior engineers will be close to the technology involved, so are best placed to solve the issues that may arise. But have you ever considered that maybe you should be casting your net a bit wider when it comes to staffing that role?

Incident Commanders are leaders, not fixers

The excellent PagerDuty training materials distill the role of the Incident Commander down to “Keep the incident moving towards resolution”. You’ll note there’s nothing their about actually resolving the incident directly. The training materials talk instead about skills like

Listening
Leadership
Clear communication
Rapid decision making

These are skills you should expect across your entire organization, and certainly ones that you would want to foster. Incident Command is an excellent way for people to exercise those skills, and limiting that opportunity to just your senior technical staff does a disservice to the whole company. In fact, at Slack we encourage members of the Developer Relations team to take part in the incident process.

If you staff up your Incident Command rotation with Product Managers, Salespeople, Customer Support Reps and others, then those people will be less drawn to directly solving the problem, letting engineers act as the subject matter experts and leaving the Incident Commander to focus on their primary role - coordinating the response.

Beyond just tapping into the leadership talents of your whole organization, there’s other benefits to sharing the responsibility of incident command, so let’s talk about those.

Solving problems can be a powerful lure

Whilst it is logical to think that good incident commanders will also be good engineers, it ignores what the role of the incident commander actually is. Put simply, incident commanders shouldn’t be solving the issue directly.

I can’t speak for everyone of course, but I know that for myself, a problem is an extremely tempting thing. I love to solve puzzles, and sometimes an incident is a ready made puzzle. But when I’m running an incident, I must constantly resist the urge to jump in. Instead, I remind myself that my role is to co-ordinate the response, because if I get too into the weeds of a proposed solution, I’m more likely to take my eye off the bigger picture of the incident.

As I mentioned earlier, as folks in Product or Sales are likely to be further removed from the technical architecture, the likelihood they’ll be tempted to offer solutions is minimized.

Empathy and Empowerment

On-call rotations in technology companies are typically only expected in the Engineering organization, but since the IC rotation involves being on-call, this expectation is shared more broadly, meaning more of your organization understands and empathizes with being on-call.

And in a similar vein, if your customer facing teams are directly involved in your incident management process, they’ll be in a much better position when it comes to discussing that process with their peers and with customers.

Many companies provide root cause analysis documents to customers after major incidents. Imagine how much more empowered your sales and support teams would be if they could speak to how the incident was run when sharing that RCA with customers.

A fresh set of eyes

The final point applies not just to incident teams, but organizations more generally. You know the expression “When all you have is a hammer, everything looks like a nail”? The same can be said about your incident process. If everyone involved in the incident process is an engineer, then your process will bias itself towards engineering solutions.

Now whilst the solution to a technical incident is likely to be technical, the same doesn’t need to be true for the process. By diversifying your rotation of incident commanders, you’re adding a fresh set of eyes to the process and will therefore create opportunities for new ways of approaching incidents to emerge.

First steps to diversifying your Incident team

Slack incident training tabletop cards

You might be wondering how to go about building a more diverse team of responders. Every organization will have a different approach, but I’d suggest the following -

Speak to the leadership of the relevant departments to get buy-in. Explain the benefits to their teams, but also the company as a whole. Incident Response will need to be considered part of the person’s role, not something that gets in the way of “actual work” that will need to be completed in addition to incidents, otherwise you’re contributing to burnout.
Invite those that are interested in helping out to observe some incidents, either live or through recordings / channel history.
If they’re still excited at the prospect, it’s time to start training them up. You can use the PagerDuty training materials as a template if you don’t already have a process for this. Although regardless of the background of your commanders, training is a good idea.
Run some mock training incidents. At Slack we do a tabletop exercise as part of the IC training process.
Let your trainees then shadow some real incidents
Add them to the rotation and see how it goes!
As the leader of your incident response program, be sure to note their contributions when it comes to performance reviews

Never stop learning

I’ve been an incident commander at Slack for over a year now and I can honestly say I’ve learned so much about leadership, communication and system architecture because of the role I play in incidents here. It’s a fantastic experience that I would recommend to anyone, so please do encourage others to try it out, they’ll thank you for it.

Improving your video conference setup

Colm Doyle — Tue, 25 May 2021 12:00:00 +0000

After a year of entirely virtual meetups and conferences, it seems unlikely at this point that we’ll ever go back to 100% in-person events. Like workplaces, most events seem to be leaning towards a hybrid model, with participants attending both in person, and virtually over a livestream. So with that in mind, what investments should you be making in your setup to ensure that when you choose to participate virtually, you’re not giving a sub-par experience to the people attending your talk?

When reading the advice below, it’s important to remember that i’m coming at this from my perspective as a Developer Advocate. My job involves far more conference speaking than most, so it’s entirely possible that my setup is complete overkill for the majority of situations, but some people just like to invest in these things, so if you’re not into public speaking, but long for your Zoom game to be on point, then have at it, I’m not here to judge!

You get out what you put in

This is probably obvious, but up to a certain point, the more you spend, the better a result you’ll get. That isn’t to say you can’t lower the costs here and there, but the reality is that all these things should be considered an investment and the costs viewed accordingly. Where possible, I’ve included both expensive and cheaper options. I’ve used many of these at some point, so can stand over them, but where I haven’t had the chance to try something yet, I’ll mention that.

Audio

If you’re just starting out, audio is 100% where you should start. People will forgive poor video, but if they can’t hear you speaking clearly, then staying engaged with your content will be a real challenge.

Higher end option - Yeti by Blue ($130)

Yeti by Blue

The Yeti by Blue is almost a defacto standard now for people running smaller podcasts and is what I use. You can adjust the gain, have different settings for one person using it versus multiple, you can mount it or have it on your desk, and easiest of all, it supports USB, so you don’t need a second piece of hardware to run it through.

For a sense of what results the Yeti gives, every episode of Klokta was recorded using one, so feel free to check that out.

Mid-range option - Snowball by Blue ($70)

At about half the price, the Snowball is Blue’s “budget” option. I’ve never used it myself, but it’s well regarded and as the name implies, is from the same manufacturer as the Yeti, so has some similar benefits.

Budget conscious option - The mic on your headphones

If you can’t afford to get a dedicated microphone, at a minimum you should use the microphone on your cellphone’s headphones. If you have AirPods or AirPods Pro, even better, use those. It’s moving the microphone a lot closer to your mouth, and the AirPods do fancy beam-forming things.

Video

Higher end option - Sony a6400 w/ Sigma Prime lens and Elgato CamLink 4K ($1300)

There’s no getting around the fact that $1300 is a lot for what you’d essentially be using as a webcam. But if you want to justify it to yourself, I’d point out that you can take it off the mount when you’re not presenting and you have a very good camera for taking photos of your kids, nature, friends etc.

Sony a6400 w/ Sigma Lens

Anyway, this is definitely going to give you a serious step up from the built-in webcam you’re probably using. The Sony a6400 has super fast auto focus, an intuitive UI and a flip up LCD so you can position yourself. Pair that with a 30mm Sigma Prime Lens to give you that nice bokeh (blurred background) and you’re gonna look great.

For an example of the kind of output you can expect, here’s a recording of an event I did that was pushed through Zoom then through Facebook, so you can imagine there’s a lot of compression going on and the result I think still looks pretty good. If you skip to around the 20 minute mark, my video is full screen and that will give you the best impression.

It’s a popular choice for Streamers, YouTubers and other video professionals, so there’s a wealth of information out there on how to configure it best, plus it’s widely supported. One last thing though. The a6400 apparently supports directly connecting over USB, but I was recommended to use an Elgato CamLink 4K and did so, but that could be a way to shave $120 off your costs.

Mid-range option - Logitech Brio ($199)

Coming in at just under $200, the Logitech Brio is still pretty pricey for a Webcam, but I’ve been told by those who own them (I do not) that the quality is top notch, as it pushes out 4K quality video.

Budget conscious option - Reincubate Camo ($39 per year)

Reincubate Camo

If you have an iPhone, then Reincubate Camo is a great investment. For about a year I paired it with my iPhone XS and got really great results. It was a vast improvement from the Logitech C920 I had.

Lighting

Once you’ve settled on video and audio, you’re likely already in a good spot, but if you want to go further, the next thing I’d consider is lighting. I have two different lights I use when recording. Even one of these is going to be pretty good.

Higher end option - Elgato Key Light ($199)

Elgato Keylight

I use a single Key Light clamped to my desk and offset to my right. The warmth of the light is adjustable from very bluish to very yellowish, and the output is adjustable from barely on to staring directly into the sun. It doesn’t get warm and has some nice touches like being controllable from my laptop (vs a physical button).

Mid range option - Generic Ring Lights (starting from $10)

Ring light

I originally started out with $50 ring light that I bought on Amazon. It’s since been discontinued, but Amazon has an almost unlimited supply of these things. What you’re looking for when considering them is

Can you adjust the brightness? (Ideally yes)
Is their a mount for your camera / phone built in? (Ideally yes)
Does it plug into the wall or into USB? (I prefer USB, but this is personal preference)
What size is it? (My one has an inner diameter of 8 inches and that feels about right)

Budget conscious option - Sunlight (free I guess?)

If you’re tapped out budget wise, but still look dark, consider if you can move your desk so that you face a window, because natural light can be pretty flattering. What you absolutely don’t want in the background is a large light source like a window or bright lamp. No amount of camera trickery will compensate well for that.

All the other things

Once you’ve gotten all of the above sorted, you’re really into over-engineering for most situations. But I love a good gadget as much as the next person, so here’s a few other bits and pieces I use regularly

Stream Deck Mobile

Stream Deck Mobile ($25 per year): I had an old iPad Mini that wasn’t doing anything else, so I purchased Stream Deck Mobile and stuck it on a stand. It’s definitely helpful as you can configure it to control just about anything from Zoom to your lights, to playing random noises in meetings. If you don’t have a spare iPad or iDevice lying around, you can also buy a physical Stream Deck for a significantly higher cost from Elgato.
Elgato Green Screen ($160): I really only pull this out for videos where I’ll do a bunch of post-production, but it’s a helpful tool, especially if you can’t really otherwise control your background due to space constraints etc. The screen shot in the “Reincubate Camo” section above involved the green screen.
Jarvis Hardwood Standing Desk (starts at $1139): You’re going to need somewhere to put all this stuff obviously, and I put mine on a Jarvis hardwood desk. It’s adjustable over a wide range and is big enough to hold everything comfortably.

The content is still the star

The choices I’ve made in terms of equipment reflect what works for me and I’m sure many others have made equally valid choices, both more expensive and cheaper. It’s important to remember though, that at the end of the day, video and audio equipment are just tools to help make your content shine. But if that content isn’t polished to start with, no amount of fancy lenses or shiny lights will make it interesting. Be sure you invest the time and effort there before you worry about how you look or sound.

Flexibility shouldn't mean always-on

Colm Doyle — Tue, 18 May 2021 12:00:00 +0000

As parts of the planet, but not all, start to see light at the end of the COVID tunnel, many companies have started to formalize their plans for post-COVID working conditions. Technology companies in particular are considering a “hybrid” or a “fully distributed” model, whereby you can choose to either come into a pre-agreed company office for 2/3 days per week and work from somewhere else for the balance, or work in a location of your choosing all of the time, usually in line with some requirements around tax laws and local corporate entities.

But there’s another consideration being discussed in addition to location, and that’s when you work. Companies are recognizing that punching a clock and working a strict 9-5 doesn’t work for many, especially people with family commitments, or people who just like to keep a different schedule for whatever reason. There are benefits to this approach, especially when it comes widening the pool of people you can recruit, hopefully leading to a more talented and diverse employee base. But as we embrace the positives of this, we must also be cognizant of the potential downsides, so we can build protections into this new normal.

In a world where you’re measured not by the hours you put in, but by your output, how do we avoid creating a situation where you end up working significantly more than before because of unreasonable output expectations, especially across cultures and timezones.

The pitfalls of unlimited flexibility

The clearest cautionary tale in this regard is “unlimited” paid time off (PTO). On the face of it, unlimited PTO could be considered an extremely employee-friendly policy. No more counting your days, no more stressing about whether you’ll have enough left over if your kids are sick or whether you’ll have to work over the end of year holidays.

But time and time again, unlimited PTO has led to people taking less time off. People move from a model of earning time off that belongs to them and they spend as they see fit, to time off being in the gift of their line manager, and suddenly every PTO request feels like an imposition you’re placing on your team. Some teams that embraced unlimited PTO in the past have even moved to “minimum vacation” policies to counter this effect.

Now imagine that atmosphere of imposition, but applied to when you close your laptop for the last time in a given day. You can easily picture people feeling pressured to crank out one more thing because their team has unreasonable expectations, whereas before, knowing that it was around 5:30pm would have drawn a natural line under the working day and given you explicit permission to step away from your keyboard. Ask yourself, what cultural norms should you and your team establish to recreate that “time to log-off” mentality?

Your time, your ideas?

As I write this post, I wouldn’t consider myself “at work”, but I also know that I didn’t punch a time card and sit down at my desk this morning at 9am, because Slack isn’t overly concerned with the hours I keep. But who owns these words? Do I? Does Slack?

Intellectual Property clauses are a common feature of many tech company contracts and the traditional way to establish ownership boundaries over this sort of output. Frequently they suggest that anything you create using company hardware or on company time is the property of the company. Simple enough you’d think. But consider this - I’m writing these words on my personally purchased iOS device, using software I funded myself, and will upload them to my personal GitHub. That certainly seems to make them mine. But , content creation is part of my job. It’s what I’m paid to do, so arguably Slack could claim ownership under my current employment contract. And since Slack doesn’t demand I work set hours, who’s to say what’s company time and what’s my time?

Realistically I don’t think Slack’s legal team will worry about the ownership of this content, but someone somewhere is writing the next Google. Assuming that person is employed right now, I’d imagine that their employer would be very interested in that IP. For all concerned, this is another example of how agreements will need to evolve.

Use your mobility to shape your company’s approach

Those of us in the technology sector, particularly Product Managers, Designers and Engineers, have never had so many choices of where to work. There are few other industries where it is truly a job seeker’s market. And that means that employers, at least the good ones, are hyper-conscious of the challenge of retaining talented staff and will do what it takes to hold on to people. That’s a privilege that you should use to your advantage when it comes to influencing how your company will approach these decisions. As I said in Building for the new normal, the time to consider this is now.

Decisions […] need to be made before the industry starts to fall back on what worked in the past, even if it’s no longer fit for purpose.

Companies everywhere are currently discussing what work will look like in the future, and many are circling the model where the hours you put in are less important. I think this approach can provide many benefits, but we should all be careful that we don’t sleepwalk into a situation where in the name of flexibility, we end up ceding some protections - like the ability to own our ideas or to turn off our work devices - because as tempting as clearing a red notification bubble can be, that Slack message can probably wait for tomorrow.

When you struggle to write

Colm Doyle — Thu, 06 May 2021 00:00:00 +0000

It’s staring at you, making you feel stupid. It’s an empty page, or a blinking cursor in a document of zero kb.

You want to write something. The will is there, but the idea just won’t come. You look back through your previous ideas, you voraciously consume content. Podcasts, other writers posts, your favorite websites. You seek out inspiration like a dry sponge, you wish for liquid. But it’s not coming and you’ve promised yourself you would write more, and you want to stick to your schedule. So what can you do to get going?

Tend to your ideas like a garden

I’ve said before that when I have an idea for a piece of content, as soon as I can, I write it down. Writing it down can mean many things. Sometimes it’s a paragraph or two, sometimes it’s some bullet points, but more often than not, it’s a single sentence.

I think of this like planting seeds in a garden. Some will grow almost instantly and be ready for publishing that week. Others may take weeks or months to bloom. It’s that garden of ideas that I visit whenever I’m stuck. If you don’t already, start tending to your own garden of ideas, and hopefully you’ll always have some content ready to harvest.

To produce, you should consume

If you’re in the business of creating content, you should also be consuming as much content as you can too. This isn’t a case of ”good writers borrow, great writers steal”, but more that reading the work of others will help you form an opinion on topics that interest you, and from those opinions you’ll be able to write content that appeals to you and hopefully others.

I often say that when you can’t get a designer to help you build a visual asset, just do it yourself, because they’ll either be ok with what you’ve made, or be so horrified that they give you a better asset. Either way, you have the asset. Consuming other people’s content is kind of the same. You either find an topic you agree with and want to expand on, or you feel so strongly that you want to counter their opinion.

Give old content a new home

Martin Beeby from the AWS DevRel team has it absolutely right when he talks about assets and activities. In most Developer Relations work, creating new content doesn’t always mean writing a blog post. You speak on podcasts, you record videos or talk at events.

Sometimes the best way to getting out of a rut writing-wise is to take something that’s already been fully formed and look at ways to repurpose it. So try taking a blog post and turn it into your next talk. Or rewrite it into a script for a podcast episode.

When all else fails, just write about it

I was once involved in a conversation about the point of internal company hackathons, and a point raised by someone there really stuck with me. He said that we all have ideas we want to pursue that aren’t on the roadmap, or funded. They’re the kind of idea that if you just get started, you’ll be able to rapidly prototype it and make your case. But it’s finding the time to get the ball rolling that always blocked you, and that was were the hackathon came in. It gave you the space to get started.

Unlike regular hackathons, I reckon that writing about your inability to write something is probably a chip you can only cash in once, but when you do, you might find that everything else clicks back into place and you’ll have your 1% written. Now to just write the other 99%.

If you like this kind of content, did you know I also produce a newsletter and a podcast. Subscribe to one or both and get these posts and more delivered automatically!

Building for the new normal

Colm Doyle — Thu, 29 Apr 2021 00:00:00 +0000

As the world starts to look toward a post COVID work environment, the commonly accepted wisdom seems to be that a Monday to Friday 9-5 routine in a central office is no longer the default expectation for knowledge workers.

Instead, particularly in the technology sector, a lot of companies are moving to either a fully distributed workforce, or a hybrid one where you spend only a small percentage of your time co-located with your team. And whilst most of the focus has been on what that means in terms of physical real estate and employee compensation, I think the interesting long term changes will be in the digital tooling that we all rely on day to day. A lot of these product and organisational trends have been bubbling under the surface for some time now, but over the last few months and in the coming years, those trends have started to accelerate, bringing about a new way of working that some believe were inevitable. In the past year, developers rushed to adapt tools to a fully distributed environment, but the challenge presented by the next twelve months and beyond is how to make those tools work in the hybrid environment many of us will inhabit.

So in a world where someone new to the organization can no longer learn how it works by sitting next to their teammates and tapping them on the shoulder, how should your existing tooling adapt and what new approaches to tooling does this new style of working enable?

Learning through discovery

The traditional model of your teammates explaining how a tool works, showing you how a tool works, and finally letting you try those tools for yourself will, I believe, fail to deliver.

Tools for this new future of work will need to focus not just on the initial onboarding experience, but will also need to work with existing collaboration tools like Slack, Teams and even email, to make usage of the tool visible in ways that allow people to learn the particular quirks of how their team uses it.

Let’s take code review for example. Imagine you’re a new engineer, and you’re in a project channel in your company’s Slack workspace or a Workplace by Facebook Group. It’s day one and you can see Pull Request notifications from the GitHub app, so you now know that your team prefers to do their code reviews there. Importantly, you didn’t have to already be subscribed to GitHub email notifications, because modern collaboration tools shouldn’t rely on outdated patterns like the information silos that are email inboxes.

When you click into the review, GitHub is already showing you what the CI/CD pipeline looks like because the list of checks are surfaced right beside the merge button. Some tools even post information like coverage reports directly into the pull request. And because Pull Requests are all about collaboration, you can get a sense for what matters to your team when code is being reviewed, because you’re doing it all together inside the GitHub UI.

You’re being guided through the whole process, from the pull request being surfaced in a group setting like a channel, all the way through to providing you with a list of CI tools that you’ll need to familiarise yourself with. It’s this kind of collaborative behaviour that needs to exist in all tooling.

Collaborative by design

I don’t know about you, but I’ve lost count of the number of times over the last twelve months that I wished I could just round up my team, jump into a meeting room with an actual whiteboard and some post-it notes to just figure something out.

Whilst Google Docs in particular has been held up as an example of best-in-class collaborative document editing, I’ve yet to see the experience of being “in the room” replicated well in a digital tool. It’s entirely possible this is just a function of my own personal working style, but I’ve had enough folks express similar thoughts to me that I know I’m definitely not alone or even in a small minority.

The tools that are needed for the next 5 years and beyond will have to weave online and asynchronous (or indeed synchronous) collaboration into the very fabric of their product, not as a mere feature or add-on.

The Room Where It Happens

Early in the second act of Hamilton, Aaron Burr laments the fact that he wasn’t in ”the room where it happened”. As someone who has spent the bulk of his career working from Ireland, but with the majority of my teammates in a California HQ, I can definitely sympathize with how Burr felt.

How many times have you been the only person dialling into a meeting room full of people, and felt like you’re observing the meeting instead of participating in it? In one way, forcing everyone to work from home has been a great leveller in this regard because when everyone is on zoom, no one group dominates conversation. In the whiteboard scenario I mentioned, when you involve video conferencing, I think you have two equally awful choices - Either point the (inevitably poor resolution) camera at the whiteboard and hope the folks on the zoom can make it out, but then have no way to contribute, or you use some kind of online mind mapping software where everyone in the physical room has sit in front of their laptops and the folks on zoom have to choose between looking at the screen or seeing their colleagues. Google Jamboard feels like a step in the right direction, but not every company can afford to kit out a room with a full video conferencing setup and spend $5,000 on a fancy whiteboard.

Some changes that need to happen, for meetings in particular, will be larger, like the whiteboard collaboration use case, but others will be smaller affordances that make life easier for the people running the meeting. Today for example, when you get a meeting invite, your options are Yes, No, or maybe. Perhaps in the future, when you answer yes, Google Calendar would ask you if you’ll be attending in person or over Zoom/Hangouts. Then the system can ensure you’re assigned a meeting room that (a) is the correct size and (b) has the facilities you’ll need in terms of cameras / whiteboards and more.

Whatever the solution, the experience of dialling into a meeting will need to be re-imagined or the people who choose to work outside one of the company’s hubs will once again be relegated to the role of observers. And in this hybrid world, regardless of where we choose to work from, we all deserve to be in the room where it happens.

Seamless security

If you can’t rely on traditional security approaches like a strictly controlled office network, how do you secure tools? People will inevitably follow the path of least resistance, so the key as always with security is balancing the most secure route with the most convenient route, especially when you talk about data leaving an organization.

As an example of following the path of least resistance, you would be astonished at the number of people who conduct business over consumer messaging apps like WhatsApp or Signal. It honestly boggles my mind until you consider that the alternative for most people is email, which despite being the defacto standard for decades, is, well, not very good.

It lacks all sorts of features that people have come to expect from messaging, like the ability to leave or join a conversation, or inline attachments that actually work well, and just the societal expectation of a formal style of communicating when emailing.

So given that alternative, people chose what they were comfortable with. The path of least resistance. But the likes of WhatsApp or iMessage are, by their very design, consumer messaging tools. They lack features that are table stakes for corporate messaging, like e-discovery features to comply with legal requests, data loss prevention systems, audit trails and more. It was this gap that Slack leveraged when they launched Slack Connect.

Connect took the consumer level features that the every day user enjoys, with the enterprise protections that a company needs to protect themselves. And because sending a DM or creating a multi-company channel in Slack Connect only requires the other party’s email addresses, it’s pretty easy to create the connection, so there’s no real need to lean on your consumer messaging app of choice. Which is a good thing, because whatever about the company’s legal obligations, if you’re going to maintain a good work/life balance, it’s probably better not to mix how you talk to your friends and how you talk to your customers.

Flexible schedules, not 24/7 ones

When I talk about an entire class of products weaving something into their fabric, the most recent product shifts that come to mind are closely connected to each other - the adoption of “social” features such as algorithmic ranking, and the shift to a “mobile first” mindset. Both of these were transformative in the software industry, came within a few years of each other, and many would argue, haven’t been 100% positive.

The tendency in both these shifts was to chase engagement metrics at all costs, which led people to craft addictive experiences where success was based on how long you kept people in your product without considering if that cumulative time was a net positive for your user’s physical or mental health.

In the current shift, especially for the work based tooling I’m talking about, we have an opportunity to learn from these mistakes and create experiences that add value, but are respectful of the work/life balance of our users.

This isn’t about your product dictating work schedules to people, but instead creating new incentives that don’t encourage constantly checking in with colleagues. What you’re looking for is ways to give users control about how they guard their time, and from a cultural perspective, encouraging the use of those guardrails. You want to offer this flexibility, because in all likelihood, the schedules of your team can vary wildly, and employees will start to expect their work schedule to be flexible. As examples of tools that are already started to weave this into their design, you could look at Slack and Google Calendar.

Slack encourages users to tell it when they want to be available and when to leave them alone through custom “Do not disturb” schedules. Similarly, Google Calendar recently rolled out the ability to more granularly control your availability for meetings, as well as setting repeatable periods of “out of office” time, where they would automatically decline meeting invites without you having to be notified.

The digital water cooler

Perhaps one of the most controversial side effects of moving to primarily digital communication is the extent to which some companies want to, and can, decide what employees can discuss at work.

Obviously the notion of company policies around acceptable behaviour at work have been around for some time, but it’s the extent to which a primarily digital environment allows employers to actually monitor and enforce these policies that’s different now. It’s a lot harder to see what goes on “around the water cooler” vs in your company tools.

With all of our workplace communication flowing through those tools, the line between casual conversations with colleagues and what you’d expect to appear in a court document is blurring further and further.

Features that enhance user safety, or legally important things like e-discovery are usually less controversial, but the extent to which your tooling is perceived as enabling the suppression of speech in the workplace is a harder line to toe.

The time to consider these problems is already here

We’re now over a year into this forced global work-from-home experiment. What was previously a fluid pandemic mandated experience will soon become like poured concrete, setting quickly and hard to change after the fact. Decisions about the kind of tooling we want to create need to be made before the industry starts to fall back on what worked in the past, even if it’s no longer fit for purpose.

As the people who are ultimately building these tools for the future of work, it’s our collective responsibility to be sure that the products we design help to create the best possible environments for everyone. We owe it to ourselves not to dodge that responsibility.

If you have something to add, I’d love to hear it, so let’s continue the conversation over on Twitter!

If you’re not iterating, you’re already falling behind

Colm Doyle — Fri, 09 Apr 2021 21:00:00 +0000

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.

If you have something to add, I’d love to hear it, so let’s continue the conversation over on Twitter!

Getting better at Developer Relations

Colm Doyle — Sat, 03 Apr 2021 21:00:00 +0000

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 parter. 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.

If you have something to add, I’d love to hear it, so let’s continue the conversation over on Twitter!