Nadina D. Lisbon is a Systems Capability and Salesforce Architect over at Tradeshift. Having started back in the Visualforce days, she has had the chance to work with wide range implementations and integrations.
In this episode, I’m talking with Nadina about her long experience working with developers, architects, customers and partners.. She explains what she does in her current role, how she accomplishes projects for her clients, and her business interests. Tune in to hear some great insights on architecture, automation, and coding.
Show Highlights:
- The experience that made Nadina realize she wanted to be an architect instead of a developer.
- What she does in her current job.
- The challenges of working with people from so many different regions.
- How Nadina ensures that there is functionality that’s reusable across her many client projects.
- How she decides if automation is necessary when working with clients.
- What you should always try to automate.
- Why code needs to be user-centric.
- Best practices for junior developers writing code.
- Nadina’s experience joining RAD Women.
- Leading a user/developer group during COVID.
Links:
Episode Transcript
Nadina Lisbon:
So one of my early memories actually are what I remember fondly is on Saturdays we had dial-up internet. And so on Saturdays, my mom would, because we had one phone line, take the line off the hooks and so my brothers would do their chores and not be on the internet.
Josh Birk:
That is Nadina D Lisbon, a systems capability and Salesforce architect over at Tradeshift. I’m Josh Birk, your host with the Salesforce developer podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Nadina about her long experience, working with developers, architects, as well as business interests. We start as we frequently do with our early years, this time being an internship that was working with Salesforce.
Nadina Lisbon:
Yeah. So I got to work with some pretty cool integrations. So one was essentially a building stacking plan. That was really cool using back then a lot of visual force, lightning wasn’t there as yet. So lots of visual force, lots of controllers. I did a lot more early in my career, I did a lot more backend development. So a lot of heavy Apex focus where I worked on reading [inaudible 00:01:24] to doing massive calculations, or working on a lot of it was working on, because I worked on the professional services team, it was enhancing our product as well. So working on any adjustments that needed a trigger here or they needed something visually built out. So things like that.
Josh Birk:
Got it. Was it easier to kind of learn a little bit about Salesforce architecture because you’re sort of working with people who have existing solutions, but then they also need enhancements and improvements and additions to it.
Nadina Lisbon:
Yeah, it was interesting because when I started out, I didn’t think about architecture that much. It was more so I thought about it from a development perspective. So you, as a young developer, junior developer, you’re usually given the requirements, this is what needs to be done. But as you go more into your career, you start to question, is this really what needs to be done? And so I think that curiosity for me, I played a lot of [inaudible 00:02:30] sometimes you’d be the business analyst because you have to make sure that those requirements, those technical requirements made sense to you. So you really want to understand what the client is asking for. Sometimes you were [inaudible 00:02:43] where you needed to be on the call, with your business analyst to make sure they were asking great questions. So there was no delay on the project. And I did a lot I feel of managing expectations as well as managing system expectations.
Josh Birk:
Got it.
Nadina Lisbon:
When you’re not accustomed to Salesforce and there’s so many limits and you’re hitting them all the time, clearly there was a need to learn how to refactor code and make sure it’s written well. But it was more so that the more that I practice, and the more that I did something multiple times, it would get better. And I would know next time, “Oh, definitely we shouldn’t recommend this because this is just going to be a headache overall.” Or, “Is this really what they want, which then became am I getting the right requirements? Am I building this correctly?” And so, it just started to grow and grow.
Josh Birk:
Got it. I think it’s so true. Like the number of times that’s come up, that’s like the central most important question you can ask a client is something along the lines of, is this really what you want? Or is it kind of what you think that you want?
Nadina Lisbon:
Yes. I don’t know if you’ve seen that diagram with software development where there’s a tree and a tire, and it’s like something completely different and everyone asks a different question?
Josh Birk:
Yep.
Nadina Lisbon:
That’s how I feel. Yeah. The whole cycle spin.
Josh Birk:
Yeah. Nice, nice. So was there kind of a moment, so you’re kind of learning your development and then you’re sort of seeing the Grander Architecture and you’re realizing, “Hey, if I get involved with the Grandner Architecture, it’s actually going to improve my best practices.” Was there a moment for you that you had that tipping point where you’re like, “I’m not just a developer, I’m an architect?”
Nadina Lisbon:
I try to figure out what this moment was, because I feel like from every job, there’s always a little bit of architecture, but I would say it was from a previous job back when I had to build out an entire Salesforce instance and to no fault of anyone’s own, I had to do the majority of the work. So I got to be everything on that project. And I think it was there where… It wasn’t as, the requirement was essentially replicate what we have in this system to this new system. But as you’re looking at it, it’s like, well, this system has so many flaws. Like if I had to choice to rebuild this system, I’m going to build it better and scalable. And so that’s what I did for the new org and that… It’s hard to convince people like, “Oh, well this is what we have in the old system. We should build this for the new system.”
Nadina Lisbon:
Because they wanted to make sure that this project went well, but it was more so that was my job to tell them basically like, “Our system is good, it could be better. Here is how we can improve it now because we have things that were not available back then.” We have a brand new org. No one has touched. I mean, like there wasn’t even a custom field. Nothing was that it was brand new from Salesforce to build this new architecture. So it was a really, really great experience because one, I had, there was no one to be like, “Oh well, we have to follow this or that,” none of that had to happen. It was more so, “There’s a new org, we need to gather these requirements.” The goal is to build a replica ish or replicate what we have in this other org, but really the goal was, if you had the choice to build it better with not as long as a timeline, because the timeline was not that long, how would you do it? And so that is what I did.
Josh Birk:
Wow. It just occurred to me all of my years of consulting, I never once had that opportunity. I never had a truly Greenfield Salesforce org with nothing associated to it. So congratulations-
Nadina Lisbon:
Thank you.
Josh Birk:
… you were only going to create your own technical debt. You didn’t have to incur any, you didn’t have to inherit anybody else’s.
Nadina Lisbon:
Correct. Only my technical debt, which it’s a very, it’s an interesting mind shift, right? Because most orgs in ecosystem, there’s a lot of technical debt or you start a new job and they already have Salesforce. So how do you make it better short of moving them to a new org, which is not always the right use case.
Josh Birk:
Right. Usually it’s there’s that one trigger that Sam the contractor wrote three years ago and it’s breaking everything, but everybody loves it anyway. So please don’t touch it.
Nadina Lisbon:
We can just drop the batch size down to [inaudible 00:07:26] and it’ll be okay, right? So, exactly.
Josh Birk:
Exactly. Well, I think we’re drawing around the edges of this, but how would you define your current job?
Nadina Lisbon:
So my current job, I feel like I do multiple jobs within that current job, but I would define it as three things. So the first thing is I manage a team of global developers. So we have Salesforce developers and MuleSoft developers, and it’s my job to make sure from a technical aspect that they understand what they need to build from a technical build. The second part of my job I would say is definitely the system architecture. So a lot of what we have now assessing what can be changed, what needs to be updated, and just to ensure that best practices are being followed, but also that we can get to a point where if we went to custom, we can get back to a point where we can use some standard out of the box feature that might be available now that was not available before.
Josh Birk:
Got you.
Nadina Lisbon:
And my third and the most important part of my job is I have to liaison a lot with VPs and make sure that what we’re building, what they’re getting, is what they want and manage those expectations.
Josh Birk:
Wow. So you’re the C-level level whisperer.
Nadina Lisbon:
C-level whisperer, system whisperer, overall business whisperer.
Josh Birk:
I love it. Describe global to me. Like how many countries time zones are you dealing with on a typical development cycle?
Nadina Lisbon:
So from a global development standpoint our contractors are in India. From a company perspective, we have people in Denmark, we have people in the UK, we have people in, we have people like, I would want to say almost all over the world. Yeah. It’s a lot different time zones.
Josh Birk:
So I was going to say, so out of time zones, but at least most of them. Do you have any tips there? Have you had challenges that you’ve had to overcome when you’re dealing with so many people working on something from so many different regions?
Nadina Lisbon:
Yeah. I would say there, it’s really important to one, make sure you can. You may not have a technical counterpart, but you may have, you can leverage a project manager, or someone on that time zone that can meet with the team. So you do want to have, there might be someone who might not know the project, for example, as technical as I do, but definitely we have PMs that understand high level, what is going on so that they can help with meeting with some of these times zones. And then two, when we have meetings, we try to be very respectful of everyone’s time because most times you might have a few users who might just not be able to meet in what we would consider their working time zone. And so it’s important there to make sure that, you ask, can I have this one-time meeting? Make sure that you can send followup notes or does this person really need to be included or when they have somebody essentially be a representative that can be in that meeting.
Josh Birk:
Got it.
Nadina Lisbon:
Now, the project will slow down a little bit, but from a peace and quality of life, that will definitely be improved.
Josh Birk:
Got it. Got it. So, I was considering this follow-up question as you’re talking, but now I’m thinking maybe the answer is different than I thought it might be. Has the pandemic changed that for you? Because my first guess was like, you’re already so global, you’re probably pretty used to Zoom calls and Google Hangouts and things like that. But it sounds like there was always sort of a person to person element to it.
Nadina Lisbon:
Yeah. So I think the pandemic, what that shift made was a lot of members, especially my company, they have kids and they had to do homeschooling as well as do work. So they had more of a flexible schedule. So for me, I had to be a bit more flexible on when I could meet with them because obviously they have times where they have to do home schooling for their kids and it might’ve not been necessarily times that would relate to my time. So I was definitely a bit more flexible knowing that and taking that into consideration. But I think overall as a company, we’ve always tried to be more remote friendly. And I think with the pandemic, we’re definitely looking at that more to make sure that as a remote worker, even if people were in office, you still feel connected to that meeting.
Josh Birk:
Got it. Got it. So let’s talk a little bit about your experiences dealing with your various business partners. And you’ve kind of hinted at it a little bit about when they’re coming to you with what they want, you’re responding a little bit with not just getting that done, but what’s your emphasis when it comes to things like being able to have functionality that’s reusable across projects and across units?
Nadina Lisbon:
Yeah. So usually, our issues usually come down to how long is it going to take, and then how much money do we need to invest in terms of our contractors, or who’s doing the work. Because with all the projects that we have going on, they have to be a priority. But what I always try to do depending on the project is not look at it for just, this is the project that they’re trying to do, but look at it overall as is there any part of this that we would be able to reuse? Is this something that once we get it situated that we can add automation to because sometimes the problem that we’re fixing, isn’t always a system problem. It’s usually a business problem that might need governance and we can fix that with enforcement of validation rules, or enforcement of required fields. So things like that to help fix those issues.
Nadina Lisbon:
But other times, the process itself might be so new. It’s not always flushed out. And so to put automation to such a new process that is still working would just cause pain on both sides. So sometimes the solution presented is how about you manually populate this field for now and see if this is where you want to go before we put automation to it. And usually, that can help fix about 80% of the problems because again, someone will come and tell you, this is the problem. You’re listening, and it’s that unspoken of you know this team and you know how these business units are and just some experience from being with the company now that I know that this is a problem, but it’s not the most critical problem, but it is a problem for this team right now.
Nadina Lisbon:
So how do I manage your expectations to make sure one, my global teams aren’t getting burnt out because we’re making these rapid changes too quickly. And then two, level setting to make sure this is the best way to do this so that the next time that you asked for something similar, it takes us a shot at time and you’re happy about the delivery.
Josh Birk:
So to kind of paraphrase like, so don’t throw code at the problem right away and only automate when you’re convinced of the right way to go so you don’t have to refactor it 100 times early on. Do you have it like a specific example of that evolution?
Nadina Lisbon:
Overall in my career? So I think it’s-
Josh Birk:
Yeah.
Nadina Lisbon:
… the way how I get our technical requirements. So most times when I say we’re starting off with day one, I will usually record the call or have someone else take notes when I’m doing technical requirements, because two things there, you don’t want a solution on that initial call. What you want to do is listen to the pain points, listen to what’s being done, and really listen to what they’re trying to convey because at the end of the day, the problem that they have that might be, they might have solutioned it a bit as well. Because a lot of, at least for us, a lot of our users know Salesforce, and so they might start throwing out words that they don’t necessarily want to throw, but because they understand the language and some of the jargon, they will [crosstalk 00:16:17] their own recommendation.
Nadina Lisbon:
So first is to hear what the problem is, restate the problem, to make sure that you understand it. And then once you get that initial business requirement, my job is then to look at the architecture that we have in place, and one, figure out is what we have in place right now, will it fit into what they’re trying to do? Do we need to refactor or is there some technical debt that we can no take care of with this new thing coming online? Or is it simply that what they need is so straightforward, but the way they asked it might be complicated. So I can give you an example. We had a goal life going recently there was a critical business process missing. And as part of that critical business process, of course, it’s critical, so we need to stop the goal life. So this has happened a couple of times.
Nadina Lisbon:
So I was like, “Okay, let me hear what the problem is.” So I’m listening to the problem and it’s like, we need this way to make sure that when, I’ll just rephrase it, when these users are doing a specific status on one of our custom objects, we need a way to make sure that we know what user to contact. And we already had a field for that on that customer object, but that field specifically is tied to automation where it does some updating of task and some other different records. So the team was like, “Well, we need a new field and this new field should have all this automation. And it should also create all these tasks and do all these things,” and so as I’m listening to the requirements, one of the first questions they asked is how do you track this right now? And they’re like, “Oh, we use a report.”
Nadina Lisbon:
So we use this report and from this report, when the record is in this status, we have the report and it will show us who’s working that record. So it’s like, “Oh, this is a [inaudible 00:18:14].” Well, they’re like, “No, it’s not the owner of the record, it’s literally the person who was an owner of another record that were now populating here.” So after going through all of that, it’s like, so visually you need a way where you pull this report to have that user stay static, but you don’t want to necessarily change the owner right now. And they’re like, “Yes.” “So technically we don’t need to tie automation to this?” And they’re like, “Yes.” So all you need is a look up to a user record that we could populate with automation in the future. But for now, you’re okay with manually updating it because you know who that user needs to be.
Nadina Lisbon:
And after a little bit, they’re like, “Okay, we need to talk to some other people on the team because they’re in a different time zone and we’ll get back to you.” And I was like, “Okay, let me know this first option doesn’t have to stop the go live. The second option, we would need to stop the go live and flush out the requirements.” They obviously went for the first option, we created that look up field. We named it, I can’t remember even what we named it right now, but right now they’re manually doing it, and then in the future, we will automate who should be in that field once they have that defined. Because they don’t have that defined right now.
Josh Birk:
Nice. I’m having flashbacks right now. But like those conversations are just so, they’re so, so familiar to me. Okay. So that’s really good stuff. Do you have examples of kind of going in reverse to that? Like for instance, you’ve got a video up on salesforce.com. We’ll probably try to remember to get a link to it. I’m trying to remember the page that it’s on, but it’s a series of very quick tips and tricks on things you can do in Salesforce and on the platform. And it’s a video about automating emails for like Apex errors. Do you have some automation tips which you’re like actually universally, these are good ideas for you to always try to automate?
Nadina Lisbon:
Yeah. So I think at least for me, there’s a couple things that I always try to automate. So any time the process doesn’t change, it’s something repeatable, and you know, it’s not going to change in the future because this is how it’s been done, that’s always a good use case for automation. Automation should also be something that a user can do. So it’s not like a complicated process because I think a lot of the times we automate these very complicated processes, but then users can’t really follow well. If I needed to do this manual, how would I be able to do this? But at the same time, we have integrations like MuleSoft that can handle these complex business logic. But the most important thing when you’re dealing with any type of automation is you have to have a process where you’re going back to review it to see, does this automation still makes sense? Do we need to update this automation?
Josh Birk:
Got it. So talking kind of more specifically around the developers themselves, do you have, well, first of all, I think in our previous conversations, you’ve described there’s, it’s important for code to be user centric. What do you mean by that?
Nadina Lisbon:
Yeah. So when I am giving requirements or when we’re dealing with anything when it comes to code, we have to think about how the user is using the systems. So you can build the best code in the world, the prettiest, lightning, web component, but if the users find it hard to use, or if it’s someplace where there one too many clicks, there from like a UI perspective, they’re just not going to use it. And so as were doing any coding here, as we’re getting any designs, we always want to make sure that one, it might not be a big deal for us that the fields or what we’re automating is lower on the page before our users if you have to scroll too much, that’s like a big deal for them. And I think, just overall, when you’re coding, as you’re going through, there’s always a, as you’re like looking at your use cases and there’s the way how the developer will test it because they will test it from the backend, but then here’s the way the user will interact with it.
Nadina Lisbon:
And that is as important as how a developer tests it. Because as we have people do UAT, they may come back and say, “Well, there’s an issue with this, but it wasn’t even part of the initial bill cycle.” It was more so that something they might have expected, but just never came up from a technical requirements. Which is not a bad thing, it means that your users are getting really good at your system and that they understand how they’re using the system. And so you want to make sure that the system you’re designing, it’s not for the developers, it’s for your users.
Josh Birk:
Yeah. Yeah. And an annoyed user is still going to file a ticket.
Nadina Lisbon:
Yes.
Josh Birk:
Even if it technically it still works. Yes.
Nadina Lisbon:
Correct.
Josh Birk:
Do you have any, like, talk to me like I’m a brand new junior developer. Do you have any top of mind, best practices that you know I want to do out of the gate.
Nadina Lisbon:
So from a coding perspective, I think there’s a lot in terms of making sure that your code is, it has very good, I will say documentation in it. So meaning when you write code, I know there’s a lot of people who will say you should not comment your code, but at the end of the day, you should always comment your code because you’re writing that code, not for you, you’re writing it for your future self or for someone who has to review it. And as a lead who would be reviewing your code, they don’t have time to necessarily step to every single line of code. So high level, they should understand how that block is working, things like making sure you don’t put query in for loops, I think that’s just standard practices, but I would say the unstandard ones as well as when you get a ticket and you’re reading through that take it as a junior though.
Nadina Lisbon:
There’s usually a ton of questions that they will ask, but some questions that I think are always missing out are who’s the user, because sometimes they will see like a sales director, for example, as a sales director, they need to do this. But what does that mean as a sales director? What is [inaudible 00:24:51] actually doing in the system? So understanding the persona of that user, you’re building too. Because if you’re building something where I’ll just make an example, you’re doing a lightning web component where a sales director needs to navigate to it. Well, they’re probably going to want it on the homepage, but the ticket might’ve said the record page, but you know, as a sales director, as they come into Salesforce, that’s probably the first thing they’re looking to see. So things like that, understanding your users you’re building for.
Nadina Lisbon:
I think another really important one is as you’re reviewing the code, some people get very, especially junior developers I’ve heard of this where they’re trying to write it in a less amount of lines, versus you’re always going to refactor code. So that first right might be pretty long, but a second right should be better because the more that you understand what you’re doing, and the second time you build it, you will build it faster. So I think don’t be so hung up if it takes you 200 lines versus I don’t know, 500 lanes, the lights are kind of negligible, but it is something I think a lot of junior developers spend time on, like, “How can I meet this smaller?”
Josh Birk:
Got it. Got it. All right. Okay. So changing gears slightly. Talk to me a little bit about joining RAD women.
Nadina Lisbon:
Yeah. So RAD women was interesting. I wanted a way to volunteer, but I also do not like to [inaudible 00:26:23]. So I wanted a way to virtually volunteer. And when I found out about RAD women, it was interesting because when I did my interview with Angela, who was one of the people and owners, founders, I guess of RAD women, I took that call actually, I don’t remember. I think was walking through a park. I was on vacation somewhere and it was so interesting because one, I didn’t feel like I wouldn’t be able to contribute to the program, but it was always that my schedule is always so busy and I was always worried like, will I have enough time to really give this the time that I need? And so, as I was talking to her and she was letting you know, “Well, this is kind of the amount of time that the coaches spend, and this is how much time you can spend.”
Nadina Lisbon:
I was like, okay, I’ll try it for, let me try it for one term and see how it goes. And if the next time it doesn’t go so well, then I can always step back or take a break because that’s always an option with RAD women, coaches come in and out-
Josh Birk:
Got it.
Nadina Lisbon:
… per session. So I think I’ve taught every session since then, because I really enjoyed it. Commitment wise, it’s not a lot of time, especially when you’ve been doing it so much. But one of the big things I get out of it is that one, a lot of these administrators who are becoming developers, they’re in this place where you’re providing them the safe environment to code, which I learned code trial by fire. So I was virtually a person who would say, “Yeah, I can get this done.” And then we’ll spend all night trying to figure it out, which I do not recommend to anyone now, but it was definitely a learning experience. So you’re not going to finish this course or the book courses and become this super developer. What you do with this course is one, you get a network of people. So those people that you start the course with, I feel, I always encourage the students that I teach to stay in touch with them because that’s like your network now.
Nadina Lisbon:
You can always bounce ideas off of them. But two, one of the big things I teach about the courses, there’s always these unspoken rules. And I keep talking [inaudible 00:28:37], right? Unspoken business requirements. And it’s being able to listen attentively, being able to, you don’t have to memorize everything in the DevDocs. But if you know where to go, then you’ll know that, that information updates. So just being able to have this hyperlink, this library in your mind of where do I need to go to find this answer? And that’s what makes a really good developer because you won’t remember everything. You won’t remember every [inaudible 00:29:05], I barely remember every [inaudible 00:29:07], but I can tell you where to Google to find the different limits, and to find what has changed, and being able to really utilize the release notes because of those three releases a year.
Josh Birk:
Uh-huh (affirmative). Yeah. Yeah, no, I can confirm a couple of those things. I’m living proof that being angry at your laptop does not actually make you a better coder.
Nadina Lisbon:
It does not.
Josh Birk:
So if you have got other options, you’ll take advantage of them. And I think I have spent an absurd amount of my time developing over the years trying to remember the right format of links. Like which method am I using in Apex versus JavaScript. But, I don’t know how many times I’ve had to look that up. So going on a little bit to a different topic, a pandemic is an interesting time to decide to co-lead a user group/developer group but that’s what you did. What was the motivation there?
Nadina Lisbon:
So When I started, the pandemic hadn’t started yet. So it was very interesting. Yeah. I started to be in person. I wanted to give back more to my community and I figured I had a little bit more time to give. And then the pandemic happened then it definitely was hard at first to co-lead a virtual group. But I personally am, again, I don’t like to drive. So I personally like the virtual format because we can have people from everywhere come in, but also it meant we could have speakers from Inware come in. So during a pandemic, I think we met not as frequent, we did every other month, but what we did was we had some really good speakers come in, some products speakers, speakers that were from our community and overall the quality I would say of the sessions definitely went up. And then we had more people that could join and get more information. And it wasn’t the same as being in person obviously, but definitely there was still a connection.
Josh Birk:
Got it. Same question I ask almost every leader who has had to go through that evolution. In a post pandemic world, do you think that you would still organize some format of remote content?
Nadina Lisbon:
Yes, I think so. I think that’s something we would have to figure out, but I liked that aspect of being able to meet people from all over the world and have people coming to the meeting, and so even if it is an aspect where… We haven’t tried any of these formats yet, but maybe we have a in-person meeting, but one of the leaders is actually doing the virtual or the section of it where maybe we do a Zoom meeting or we use the platform. So one of the leaders is running that section of the meeting and then there’s an in-person. Something like that to give that hybrid approach. Or maybe we just do every other meeting as in-person and every other meeting as virtual. Yeah.
Josh Birk:
That’s our show. Now, before we go, I did ask [inaudible 00:32:14] Nadina’s favorite non-technical hobby and it turns out it’s something that was very handy for the pandemic.
Nadina Lisbon:
I really liked to crochet.
Josh Birk:
Nice.
Nadina Lisbon:
And during the pandemic I’ve been crocheting a lot, so there’s a net force group that I joined during the pandemic and they do other things besides knitting. So I definitely bring the crochet aspect in there, but people do other things in that group. And yeah, that’s been pretty interesting as well to sit down and just chat and craft with other people.
Josh Birk:
And that’s our show. Now, I want to thank Nadina for the great conversation and information, and as always, I want to thank you for listening. Now if you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody. And we’ll talk to you next week.