00:00:00.299
[foreign]
00:00:11.760
Hi everyone, thank you so much for coming to my talk today. The title of my talk is 'We Need Someone Technical on the Call.'
00:00:14.580
If this strikes fear in your heart, never fear because I am here to help you navigate this. Hello, Ruby community! My name is Brittany Martin, and I am the host of this talk.
00:00:23.039
Did I know I was giving this talk today? No, I was on the waitlist, and I’m super thrilled to be speaking today. I want to point out that being on the waitlist can be a fabulous experience. You never know when you’ll get to give your talk, so you don’t have to be anxious about it. I myself actually suffer from performance anxiety, so I didn’t have to work myself up at all. You’re actually getting to see me at my best impromptu self, so enjoy today!
00:00:42.840
Now, let’s talk a little bit about who I am. First of all, I identify as a Rubyist. My pronouns are she/her. I am the engineering manager at Texas, an enterprise text messaging app built on Ruby on Rails and React.
00:01:03.719
This is a rather terrible photo of my team, but we recently took an off-site trip to Chicago. This is actually our reflection being reflected back at us from the Chicago Bean. It was a really fun trip, and, of course, we're hiring, which is usually the typical thing. However, the market is kind of weird right now.
00:01:32.820
I took over the 5x5 Ruby on Rails podcast on September 26th of 2018. As many know, I took the podcast independent in 2021 and added three fabulous co-hosts in the process: Gemma, Bryan, and Nick. This podcast is my contribution to the community, and I'm thrilled to see many more Ruby podcasts emerging, including ones being launched at this very conference.
00:01:48.799
Recently, while interviewing candidates, I asked how they stay plugged into the Ruby and Rails community. They responded by saying they listened to the Ruby on Rails podcast. I was like, 'That’s so great! But it's a different Brittany Martin.' So, my question for you is, if you haven’t guessed it, why not come talk to me? Bring me a topic! I want to get more people involved who haven’t been on podcasts.
00:02:05.640
I also want to take a moment to thank Gemma, Emily, and Andy for all their hard work on this conference. What they have pulled off is an incredible feat, and it’s something we need to talk about. Their passion for creating a safe space is evident in everything they did.
00:02:25.599
Additionally, I’d like to thank everyone who participated in the RubyConf mini 5K this morning. It was super fun! I was really thrilled by the turnout. There are really good people here, and it’s great to celebrate one of my passions with them.
00:02:46.680
Now, it’s time for me to pitch why I’m qualified to give this talk. Some say I have had a varied career; those people would be correct. However, there’s a common theme that runs through all the titles I’ve had: my specialty is to be the grease between the wheels to keep the gears turning.
00:02:51.899
Along the way, I happened to learn how to code, which has made me more efficient. I am the absolute queen of setting barriers, and my goal is to reduce chaos and keep focus for my team. My driving force is to connect people together.
00:03:11.640
It was pointed out to me that I work at a text messaging company, and I recently wrote code around call forwarding, so I’m definitely qualified to talk about phone calls, right? So, what does it mean to be technical? We say it often, and as someone who has transitioned from being an individual contributor to an engineering manager, I want to hold on to the idea that I’m still technical.
00:03:41.040
But for someone who doesn’t know what that means, what does it really mean? Technical, according to dictionary.com, is defined as belonging to or pertaining to an art, science, or the like; skillful in or familiar with a particular art or trade. Now, to me, defining technical versus non-technical is quite challenging.
00:04:03.960
Non-technical skills are interpersonal skills that we all value, which might include communication skills, leadership, teamwork, decision-making, and situational awareness. Those skills can be highly technical though. Facts are facts: if you work in the tech industry, you are considered technical. I'm declaring it right now! However, for the purposes of this talk, a person with technical abilities is someone who possesses unique knowledge about how a system or process works internally. I’m focusing this talk primarily on software developers, but it applies to anyone who is technical.
00:04:56.940
Here’s another way I see it: we hold a quarterly contest at TextUs called Employee of the Quarter. Employees are encouraged to nominate co-workers based on the core values established at the company. For years, the nominees were mainly non-technical roles like customer support and sales. However, as our culture has shifted to be more product and engineering-driven, so have the nominations. For example, the top three nominations from Q1 of 2022 were all technical.
00:05:33.579
A good case in point is Zachary. Zachary is one of our senior software engineers who was recently promoted to staff. It’s clear why he would be considered technical—he writes code. Our next nominee is Josh. Josh is our associate product manager, and you might think to yourself, 'That’s not technical.' But Josh is actually the product owner over our API. When people have questions about how to integrate with us and how to make that easier, Josh is the one who facilitates that.
00:06:00.360
Lastly, Sierra is our tier three support engineer. She sits between customer support and engineering and serves as a barrier for complicated questions that arise. In essence, she is almost like a caching layer, attempting to answer questions and delve into our logs—thus, she is also highly technical.
00:06:17.280
So for the context of this talk, what is considered a call? Do we even get on the phone anymore? It’s easy to refer to various situations as calls, but truthfully, a call is any instance when someone is requesting your time in real time – whether that’s a phone call, video conference, or even a casual huddle in Slack.
00:06:29.520
Now, let’s get to the actual situation: you’ve just received a DM—the dreaded message—asking for someone technical on the call. If that statement is terrifying, do not worry! But how did we end up in a situation where this statement feels so terrifying? In the beginning, there’s a small team comprising a couple of technical and non-technical co-founders who can all meet customers together.
00:06:46.140
This is where the engineers are actually talking to customers directly, and everything goes really well. However, as the team expands and more engineers and salespeople get hired, a distance grows between the engineers and the customers, prospects, and vendors.
00:07:01.620
Customer support, sales, and executive leadership asking for a developer to join a call becomes a lofty ask. Now we're going to delve into one of my favorite memes of all time, which truthfully inspired this talk. This reflects my first reaction when I get invited to a call to which I wasn’t originally invited. We are protective of our time because all interruptions disrupt our flow.
00:07:19.440
We’ve discussed many times throughout this conference how vital flow time is to our engineers. We are paid to code, not to be in meetings. So what’s the best way to handle being the technical contact on a call? Well, I have a great answer for you: you should try to avoid it! At first, it sounds really obvious, but there is an art to dodging a call.
00:07:36.600
The first thing I want to talk about is the anatomy of a support ticket. Sending a well-written support ticket or response might give you exactly what you need. Let’s break this down: use a really clear title. Many email providers will group titled emails, so be unique and clear. Don’t send an email in all capital letters just saying 'IMPORTANT' because it might end up in spam.
00:08:06.180
Next, clearly state who you are and why you are the technical contact. Elevate your position so that the recipient takes you seriously. Then, communicate what you’ve tried already; there’s nothing worse than getting deep into a technical issue only to be sent a standard help article link.
00:08:25.320
You need to make it very clear what action you need them to take, so I typically bold that sentence in my emails to ensure it stands out. Also, be technical and provide the necessary data needed as an attachment. Don’t dilute the message with code or logs intermixed with your points; keep that at the bottom and direct the recipient to where they can locate that information.
00:08:42.840
The next thing to ensure is that you have clear API documentation. How many calls can you avoid if your API documentation is solid? Think of API documentation as a reference that has all the information needed to work with your developers, partners, and customers. It should contain everything possible with the API and how to get started. If anyone at your company can reliably link to the documentation, external stakeholders will trust it.
00:09:06.600
Now, this is a somewhat controversial point, but I’m happy to discuss it with anyone here. I have been called the queen of barriers here at TextUs. If I am being asked for the technical person on the call and they are not already a customer or partner or vendor, I tend to deny it. Needing a sales engineer is one thing, but that indicates we need to equip the sales team with better tools and roadmaps to ensure they can handle those calls themselves.
00:09:40.680
Another instance of denial comes when I receive a surprise invitation. For example, I recently got invited to a call with a customer that had no agenda or context and was scheduled on top of an existing meeting. It’s crucial to set boundaries and be consistent about them, which is why I sent an instant decline for that invite. However, I did follow up with an email to the account manager after submitting a case with details before scheduling any time.
00:09:58.920
Now, there are signs that indicate you should accept joining the call, and that's what we’ll talk about going forward. I find this to be quite funny. You should accept taking the call if you are highly invested in the situation; particularly, if asynchronous communication hasn’t worked.
00:10:21.240
This can happen when there's been back-and-forth communication and a clear misunderstanding is occurring, with growing frustration from the other party. In such cases, it is a good time to take the call. If the relationship is crucial to your organization—like if you have a big customer and their departure would be a significant loss—you should probably take the call.
00:10:46.440
Lastly, if you suspect that the issue might stem from your side—such as if they discovered a critical bug that needs urgent addressing—that could also be a reason to take the call.
00:11:05.640
Taking a call has a hidden cost; you need to calculate the cost of the call literally by factoring your salary into an hourly rate, determining if it will end up being a net positive for you. We can agree there have been some very expensive calls.
00:11:24.000
If losing the monthly recurring revenue (MRR) from a customer or partner is significant enough, and it will require more engineering resources, then it’s wise to take that call.
00:11:42.960
Like a good RSpec test, it’s all about the setup before executing. We’re going to walk through a hypothetical scenario where you are tasked with deprecating a public API at your company. The deprecation is scheduled, and you are eager to retire these services, but your partner just alerted you that they’re blocked on transitioning from the version one endpoint to version two.
00:12:08.400
This creates a problem, as they are now in your way of accomplishing what you need to do. Thus, you need to assemble a call but with a very specific agenda to stay effective. You want to avoid a committee on the call because nothing gets done that way; people will drag their own agendas into it.
00:12:28.800
Four key participants must be involved to ensure a productive discussion: your technical contact, a representative from their team who’s technical, and their advocate. Your second-in-command must also be there, as this role is crucial to keeping the flow of the call.
00:12:46.680
Now, who fits the role of this second-in-command? This person should ideally be your engineering manager, your tier-three engineer, your account manager, or your product manager. It depends on the problem at hand. In the case of a deprecation issue, it’s likely that your engineering manager is the best fit, given that it’s an engineering-driven project.
00:13:04.920
Make sure this person can handle follow-through and respect boundaries. Consider whether your second-in-command will be calling in from the car during vacation or multitasking and keeping pace with the conversation; if they aren't, choose someone else.
00:13:26.520
Did they earn a reputation for executing calls well and following up? That’s your person. Before the call, ensure the agenda is clear and concise to keep everyone on point and prevent drifting into unrelated topics.
00:13:46.680
If something isn’t on the agenda, you should respond with, 'I don’t know, but I’ll get back to you.' In this scenario, the API deadline needs to be a crucial agenda item; don’t skirt around it because that’s the point of the call.
00:14:06.780
Sync internally before the call. Schedule a quick meeting to solidify the goals and familiarize everyone with known personalities among the participants. Some may take on aggressive or passive roles, so knowing who’s on the call will help align responses.
00:14:24.960
Now, it’s the call day. Always start the call with introductions, even if everyone knows each other. This sets the stage well. Your second-in-command should drive the call, stating their name, title, and role in the project.
00:14:46.680
Ensure your camera is on throughout the call; you want to foster engagement. It might seem basic, but please bear in mind that it’s easy for technical individuals to want to start typing or driving the conversation.
00:15:09.840
Take a step back and listen to fully understand what the other participants are experiencing. The more they talk, the more likely they are to reveal the core problem.
00:15:29.040
Designate someone to take notes and record the call. Ensure you get permission for recording; this is crucial in keeping your team in sync. After the call, funnel the status of the API project to the account manager for the partner.
00:15:54.840
As most of us are still working from home, it’s important to acknowledge our circumstances. My lab, George, has figured out that during my calls is prime time for him to bark for treats! It’s crucial to be human and acknowledge these realities; we all have lives outside of work.
00:16:14.160
Feel free to engage in small talk about your interests, like your favorite shows. However, once the call starts, stay focused on the topic at hand—envision yourself steering the conversation back to the API transition.
00:16:45.360
If you find yourself opening your Rails console or logging tool during the call, stop! It’s not the best use of your time or your partners. If reproduction steps need inspection, save that for after the call and address those details offline.
00:17:06.300
While you may be the most technical person on the call, it’s your job to elevate your second-in-command. This might include reiterating that they can provide the answers needed or that they have engaged with other partners in similar situations.
00:17:28.680
Ultimately, you want to reduce their dependency on you while allowing them to recognize your second-in-command as truly competent. Once upon a time, you were not technical, so remember it’s important to provide translations for non-technical stakeholders.
00:17:47.760
For instance, if the issue is expecting an XML payload from v1 but the v2 API only offers JSON, you can help them migrate or find a library that can translate XML to JSON effectively.
00:18:05.220
Furthermore, if you can finish the agenda early, end the call ahead of schedule! Free time is valuable, and you need to make it clear that your time is well spent.
00:18:34.440
Repeat the conclusions made during the call, making sure the partner commits to moving to your v2 API by a set date. Agree on the handoff that your second-in-command will complete within 24 hours of the discussion.
00:19:05.280
Before we wrap up, let’s discuss the follow-up. Remember, if you did well on the call, be prepared for some amusing new statements to come your way—like being invited to all future calls. This might seem sweet, but don’t take it as a sign to change your behavior.
00:19:36.360
So you don’t need to schedule another call if you come across an issue during the initial call. Let’s say the API endpoints aren't as you thought—they need to work with your engineering manager to prioritize them ASAP.
00:19:55.920
Tag your second-in-command so they can see the ongoing work. This demonstrates one of my favorite skill sets: being a technical whisperer. Remember how important it is to empower your second-in-command.
00:20:20.760
Prepare them with technical information to make them sound brilliant during follow-ups. They will lead the communication rather than you. For example, Sierra reached out to me regarding her response to a customer issue, and together we worked through it without my needing to intervene directly.
00:20:48.240
The lesson here is that when done correctly, you can avoid calls while helping your teammates grow in confidence.
00:21:06.360
Once the v1 API is deprecated, you may find that it falls behind schedule. Schedule an internal retrospective on why technical intervention was needed, and what measures can be taken so partners and customers are better informed in real time.
00:21:21.720
Though this may seem demanding, there are plenty of positive outcomes to gaining skills in these situations. You can build a fantastic career as an individual contributor, a manager, or a founder. It's essential to hone in on skills in managing interpersonal dynamics.
00:21:39.840
You too can be a hero by helping others to accomplish their tasks, improving trust. It’s all part of enhancing our existing requirement management practices as we scale Ruby on Rails. It presents an opportunity to spot client issues that can be resolved through new technology.
00:21:59.880
Given that we all go through ruts, connecting with clients and partners whose lives are impacted by the software we develop can reignite passion.
00:22:29.760
Instead of viewing calls as time-wasters, appreciate them for the potential they hold to save time by facilitating immediate answers rather than being stuck in lengthy back-and-forths.
00:22:43.440
So, perhaps next time, think about picking up the phone and maybe call me, maybe? I welcome any funny or tragic technical call anecdotes, and I’m eager to hear them! We will be adjourning to lunch shortly, so thank you very much for listening today.
00:23:05.640
You can tweet me at my awkwardly chosen Twitter handle, visit my website, or listen to me on the Ruby on Rails podcast. Thank you all!
