Software Engineering is More Than Code

[00:00:00]
>> Francesca Sadikin: So yes, fast forward to a different role at a different company where I encountered a similar challenge but approached it very differently. So my team is responsible for developing reusable components and workflows meant to accelerate our other engineers' velocities. And when I joined, I found out that despite having some solutions available, no one was using any of it.

[00:00:26]
So we tried all of the traditional adoption methods, like write better documentation. We were presenting it in lots of different meetings, to lots of different engineers, but all of that failed to spark adoption. So, we decided to take a different approach. And thankfully, I knew what not to do, based off of my first experience.

[00:00:47]
We were definitely not going to keep our heads down and continue coding more tools and workflows. It was time to talk to our engineering customers and really understand the lack of adoption. So, we had presented this in groups of meetings, but when we asked, what's the hesitation? What's going on?

[00:01:09]
Silence, nothing. So we began instead, to have one-on-one conversations with individual engineers. And these sessions created a safe space for them to openly share all of their concerns and hesitations, and to be clear, we weren't trying to sell them on our existing tools. Not like, hey, why don't you use this specific thing?

[00:01:31]
It was more to really just take a step back and just understand, l what's going on for you, what's actually difficult for you, what's the most painful part of the engineering workflows, hearing their opinions. And it wasn't just simple conversations where people just told us the answers, it actually required a lot of active listening, intense curiosity to really dig deep into what people were implicitly saying or hinting at.

[00:02:00]
And creating an environment where engineers felt safe to provide that kind of feedback. Because, I think in a way they were also afraid of offending us. And we were like, no, please, just let us know, we want to know these things, right? And so what emerged from these conversations were really deeply personal insights that we were never gonna get in any other forum.

[00:02:22]
Some engineers, we learned, had been burned by previous tools because they adopted it too early when it wasn't ready. Others found that they didn't have time to learn something new, especially if they didn't know if it was actually gonna be useful. So it became clear that in general, trust was a significant barrier, they didn't trust our team, it was new, and they didn't trust these tools.

[00:02:49]
But that wasn't all, we also uncovered other deeply painful problems in their workflows that we hadn't initially considered. These were issues that were really causing the most frustration and time consumption in their workflows, and they wanted those to be solved first. So armed with these insights, our team did not just push forward with our existing tools, we iterated on them continuously, adding feedback and making adjustments based on the feedback we received.

[00:03:20]
So all of the engineers we talked to, we kept the feedback loop to make sure that we were continuously hearing what they thought about it. And we focused on solving the main pain points that were most important to these engineers. This personalized and responsive approach gradually built trust and credibility.

[00:03:41]
As more engineers saw their peers benefiting from our tools, eventually, skepticism gave way to curiosity, and now to widespread adoption. It took a while, but we were there. So in both experiences, the importance of caring about users and actively listening to them and wanting to understand them became crystal clear.

[00:04:02]
The first project failed because we didn't take the time to actually understand the needs of our users beyond the initial request. The second succeeded with widespread adoption because we put empathy and understanding first, engaging in genuine conversations to uncover and address the real concerns of our users.
>> Francesca Sadikin: That's the end of this story.

[00:04:27]
[LAUGH] Do you guys relate, agree, or disagree? Okay, maybe this was a very obvious message to engineers, that as someone who constantly did this in the beginning of my career, I thought it was important.
>> Francesca Sadikin: Just as a takeaway, a recap of this particular story. The experience has taught me that effective work in software engineering is more than just your ability to code.

[00:04:54]
Especially if you're working to build something for someone, it requires empathy, a willingness to listen, and a deep care for the person that you're serving. Without them, we risk building solutions in search of problems, pushing out work that looks great on the surface but ultimately fails to deliver any real value.

[00:05:18]
So our ability to care directly correlates with our ability to execute.