In this episode, Rupesh Bhatia and I talk about his various experiences in web development. As a Specialist Master, he has worked with many developers and consultants and has a lot of career advice for us. He also shares how to have a consultant mindset.

Rupesh wasn’t always destined to be a programmer. Having grown up in a barber’s family, he eventually fell into web development. Tune in to hear all about his career journey and current expertise in the field.

Show Highlights:

  • What D2C (or developer to consultant) is.
  • What’s involved in the presale cycle and why that’s important to a developer.
  • Tips for developers interacting with tech leads and technical architects.
  • Advice for people working with clients and communicating back to offshore people.
  • How to document the information you receive from clients.
  • How to make sure the escalation process goes smoothly as an offshore developer.
  • How to navigate the challenges that come up with language and culture barriers.

Links:

Episode Transcript

Rupesh Bhatia:

Opportunities do not come your way. You have to create them in this world.

Josh Birk:

That is Rupesh Bhatia, a specialist master with Deloitte Digital. I’m Josh Birk, the Developer Evangelist for Salesforce and here on the Salesforce developer podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Rupesh about his experiences with developers, working with consultants and having a consultant mindset. And I want to highlight that a lot of this is career advice and Rupesh wasn’t always destined to be a programmer.

Rupesh Bhatia:

Okay. So I come from a barber’s family. My dad is a barber and getting into an engineering college was itself a big kind of feat from where I come from. I was kind of prepared to go into do a graduation in mathematics and part-time help my father on his barber shop. But yeah, I secured good marks and I luckily got a merit set into an engineering college and I went through the four years and yeah, the first job happened to me in a very accidental way. The first offer I took up was primarily because there was financial need and it was into web development. So that kind of excited me, but I was always looking for more technical role. I was always interested in programming.

Josh Birk:

Okay, so getting to our main topic, define D to C or developer to consultant for me.

Rupesh Bhatia:

Yeah. So DTC developer to consultant for me is any developer who is building applications, who is doing programming will adopt a consulting mindset. When I say consulting mindset, start thinking about for whom are they making that page for whom are they building that code who is going to use the end application that you’re going to build, right? Which personas are you catering to? Your module is catering to which all personas. When you are building a trigger or a visual first page or a lightning component, you have to understand how that fits into the overall module, how that module fits into the overall business process and how that business process will at the end of the day, when it gets delivered in production, who is going to use it, how it’s going to impact their day-to-day lives. Are there any cross dependencies with other modules which are there might be building by some other developer, right?

Rupesh Bhatia:

So having that mindset of relating the technical world to the business world and vice versa, when you hear a business requirement, can you relate it to a technical solution in your mind? Right? That is, to me, is a consulting mindset that you might not be facing your customers on a day-to-day basis, being a developer, but you are interacting with someone. It might be a technical lead. It might be our scrum lead. It might be our client stakeholders, or it might be our own internal onshore team. Right? Treat them as your clients when you’re interacting with them, ask more queries, try to let the business context, and that will help you evolve as a consultant. And I often get this complaint or excused by the developer saying that we don’t get enough client facing roles, treat each and everyone with whom you’re interacting on an official project as your client. And that’s how you’ll evolve and you’ll make a difference for yourself. And that’s how you’ll create more opportunities. So that’s, how I’ve always approached my career. And that’s my general advice to everyone.

Josh Birk:

What’s involved in the presale cycle? And why is that important to a developer?

Rupesh Bhatia:

Yeah. Presale cycle is the kind of an extension to the sales engine. It’s part of the sales engine for any organization. It’s a process of getting more work or getting more projects or getting more accounts for your company. And typically the teams are there for larger accounts or larger clients that are these account teams. And these account teams basically form a pre-sales team. And it could be a combination of both onshore and offshore at times, or it could be also be directly from onshore, but here are the group of people who work together in a very aggressive timeline to put together the entire RFP response document, a formal proposal document to the client based on their requirements. Now these requirements could be high level, very detailed based on the nature of the RFP, but this group basically works towards repairing that formal response document, putting all the sections of a proposal document in place and coming up with the right estimates with the sole intent of winning that deal.

Josh Birk:

And that’s a really interesting phase of a contract because if you don’t have that technical person in the room and you only have the salespeople in the room…

Rupesh Bhatia:

Right.

Josh Birk:

..then what gets signed now somebody, maybe that offshore developer in India is the guy who has to try to clean up the best of tech requirements that actually may not have the right technical solutions.

Rupesh Bhatia:

Right. And I’ve been part of conversations, right. And just our technical person talking through the requirements would give a whole lot of confidence to your stakeholders that this vendor knows the substance and they have the right SMEs on the team for us to award that project. Right. So a technical person talking to business confidently about a solution, we’ll do a whole lot of work to the overall team and the company.

Josh Birk:

Yeah. And I think it’s also kind of interesting. We’ve had on the podcast before talking about architects talking about how architects can kind of interact with developers, but you’re also talking about the reverse, like what are their tips for developers when they’re interacting with their tech leads and when they’re with their technical architects?

Rupesh Bhatia:

Yeah. On that front, there’s a very interesting observation which I’ve heard had, most of the developers tend to aim for becoming architects without really understanding that architects also have a very important skillset of interacting with business as well. Not with all the business stakeholders, but when you are discussing solutions, right. If you’re talking to a C level executive, they might be aware of Salesforce as a platform, or they might not be, right. So you need to have that skillset where you can converse technical stuff with the technical folks or the technical stakeholders, as well as, you should be equally competent enough to discuss your solutions in a very layman language to a business stakeholder as well. And I think that’s the missing piece of which I found, which I observed, at least in the developer community is everybody wants to be an architect, but they miss this very key aspect of soft skills: communication, having the right questions in place, challenging business requirements based on your know-how of the Salesforce platform. Right. These are some of the key attributes, which I think any architect should have and yeah.

Josh Birk:

Yeah. And here’s where you’re describing a distinction between developers who can talk tech, architects who can talk structure and then you’re kind of adding on another layer consultants who can talk to the clients.

Rupesh Bhatia:

Yes.

Josh Birk:

Nice. So I know you can’t talk about specific clients, but can you talk about some projects because I’m curious about the other side of the other direction. Like, I guess actually, let me ask a more generic question. Do you have, from the person who is the onshore and they’re the people working with the clients, do you have any advice for them when they’re the ones communicating back to the offshore team?

Rupesh Bhatia:

So I’ve been fortunate enough to work in both those spaces. I’ve done a lot of short term travels for my projects in the past for three weeks, two weeks, one month, right? Just for a requirement gathering session or a discovery session that are just for the train, the trainer sessions, or just for conducting UATs for very short durations. And I’ve been in those shoes as well, where you are into like 10 different things where you’re handling your business stakeholders, you’re engaging with the IT stakeholders. You are into this daily meetings workshops going through the business requirements, trying to understand the business world, trying to map a solution on Salesforce platform. Along with all of these things, right, and somebody’s doing all of these things, the client might come up and say, “Okay. We have heard about this app exchange. Do you know how it works?” Right, and on the fly, you might have to do a quick POC for them.

Josh Birk:

Right.

Rupesh Bhatia:

You might have to also run the demos with the stakeholders on the fly, right? And these are traits of a consultant, but when you interact with your offshore team or the developers who are remotely, who do not have all of these contexts, a good consultant will always ensure that they pass on as much information to the offshore team.

Josh Birk:

Gotcha.

Rupesh Bhatia:

Because if you can do that early in the game, during your requirement gathering workshops, or during the discovery sessions, you will have lesser challenges during the bill cycle, during your sprint demos.

Josh Birk:

Mm-hmm (affirmative).

Rupesh Bhatia:

If that developer understands the business context well in advance, they will ensure that they will deliver quality, it’s not just about code quality, it’s about the quality of the application as well. And they will have that overlap with you where they might also come up with a suggestion or a better technical solution, which you might not have thought through.

Rupesh Bhatia:

Right. And that is this handshake, which I’m really looking forward to. And I always make it a point, that whenever I’m into these workshops, documentation becomes the key at times, right? If you are in back-to-back meetings, you might not have the whole lot of time to document everything and pass it over. Right? And that becomes a kind of a practical challenge which every consultant face. How do I offload information to my remote teams? Right? And that’s where you need to be innovative. You need to be creative on how you take down your notes. How do you articulate that to your offshore team, so that you are all aligned when you’re talking about a requirement. Right.

Josh Birk:

Yeah.

Rupesh Bhatia:

And I understand those challenges. There’s no kind of a theoretical way to do it, but it’s more practical. And if you’re a good consultant, you’ll always find a good way of doing that handshake.

Josh Birk:

Got it. So that’s pretty interesting, so it’s kind of a warning that you don’t want that person who actually happens to be in the room to lose any of the information, because they’re hearing it verbally and maybe it’s in their head, but if it’s not documented, then it can’t be passed on to anybody. And then the offshore developer can’t get the context, to get that code done right.

Rupesh Bhatia:

Right. And oftentimes what I’ve seen is the focus is on documentation and it becomes a focused area of: is the document is in the right format?

Josh Birk:

Yeah.

Rupesh Bhatia:

Do we have the right sections in place? Is there a template right? No. Focus on the content. Have we captured all the stuff that we had discussed with the business?

Josh Birk:

Gotcha.

Rupesh Bhatia:

Have we captured all the personas? Have we captured the right stuff that the development team needs? So I think that’s where those gaps are. And that’s where project struggle. And the teams have to scramble through the build phase, trying to get more understanding during sprint demos, you can get like shockers from the clients who could say, “This is not what I had meant!” Okay, where is the gap? Okay. Someone didn’t do their job.

Josh Birk:

Right, right, right. Do you have any advice or tips when it comes to? I mean, I don’t, I agree don’t focus on the format, but either on the format or tools that can help that documentation be successful?

Rupesh Bhatia:

Notes, scribble notes, handwritten diagrams, just trying to explain myself how this entire solution would look like.

Josh Birk:

Got it.

Rupesh Bhatia:

It could be a formal word document, word template. Like to me format, yes, every company has their own format and you have to go by those predefined templates. Right? But I think if you can get all the right kind of content into that template, it’s kind of a teamwork, right. If you’re not able to do as a consultant, by your own, always find someone who can do it for you. Right. People, everyone has their own individual skillset. There will be someone who can do, who can do a good job at documenting stuff. Then if that is not your trade, do not attempt it and do not force yourself to do it. Right? Find that right person who can do that for you. And yeah. I mean it, every company has their own set of tools and own set of mechanisms to deal with it. I’m not going to comment on any one, but yeah. I feel, I think that person should get comfortable in what they’re trying to do.

Josh Birk:

So the importance, is not the tool, it’s not the format, it’s just making sure that the information is getting stored somewhere.

Rupesh Bhatia:

Yes. That’s for me, at least the handshake between onshore and offshore, that’s the key element.

Josh Birk:

Got it. So, okay. So going back to the question I was forming earlier, I know you can’t talk specific clients, but do you have like real world examples where maybe you like dodged the bullet with a client because this information was properly handed from onshore to offshore.

Speaker 3:

Instead of stating one such example. I mean, it happens with almost all the projects, right?

Josh Birk:

Yeah, okay.

Speaker 3:

Where let’s say you’re delivering a project, right. And the client comes back during a sprint and asked for, okay, we can be at a couple of fields in this object. Okay. And we’ll get these fields populated from our back-end systems. And we let the integration team know that they need to populate these fields. Now, if I were to delegate this task to my development team, right, it’s basically creating those three fields right there and setting up the light level of field level security and off they go. Right? Versus it might be a check box and if you really deep dive in with the business stakeholder than what they’re really trying to do, it might turn up that they are trying to do a kind of a sneak peek into a solution where they might have to build an actual model out of it.

Josh Birk:

Gotcha.

Rupesh Bhatia:

Right. And I can’t like code exact requirements here, but often in projects, that’s what you see. It, it starts with a very small element of a request. And when we actually dig deeper into the request with the business stakeholders, and if you ask the right questions, you will understand what’s the end to end implication of that one field on an account object or on an opportunity. Right? That means something to the business, either to ERP, either to a source, any source system, either to an MDM system, right. That has a potential impact somewhere, unless you understand that, do not agree upon any solution, unless you get the 360 view of a requirement. We talk about customer 360 for a developer. It should be requirements 360, unless you understand that, do not go for that solution.

Josh Birk:

Nice. I like that! Requirements 360. So that’s really good advice because if that feels like you are trying to get ahead of scope creep before it even really happens.

Rupesh Bhatia:

And that’s how you will save yourself, right? Otherwise you’re burning yourself on projects and I think it’s very obvious if you don’t save guard yourself by putting the right boundaries, by asking the right questions upfront, you are bound to get into scope creep discussions, and those discussions are not good with any customer.

Josh Birk:

Yeah. So let’s flip back to the other direction. If I’m that offshore worker or that offshore developer and I feel like I need to escalate something, do you have any advice for making sure that’s a process that goes smoothly?

Rupesh Bhatia:

Yeah. So every company has an hierarchy. Every project has a manager. Every project has a tech lead. I mean, not every project, it depends upon the team structure, but any person within the team will have a go-to person too, okay. And at times what happens is either we don’t understand the requirement. Either, we are having this perspective, in our mind, that if we kind of escalate this, this will not reflect good on us, on our carriers. That our developer is saying no to certain things. Right? So there’s this conscious mind of ours, which says that, should I say no to something? What will happen? If someone hears no, from my side, will they hold it against me? Right? And any team who can promote that culture of empowering the developers to speak up their mind will be successful on any of the projects, right?

Rupesh Bhatia:

So there will always be people around you with whom you can have that one-on-one talks, there will be forums within your organization where you can formally put forward your thought process. Right? And to me, email is a weapon where any professional can use it in a very lethal way, at times. Whenever they have to push back on certain things. Right? Whether it is within the team, whether it is on requirements with the customers, whether it’s on their onshore counterparts, use email as a formal mode of communication to put forward your thought process. But again, you have to be very careful in how are you representing your intent, your content in an email. And that’s where email communication is right up there in my list, right? Verbal communication is up there in my list, email or verbal. So I normally give this example in my campaign when I do these sessions is what happens when there is an escalation? Whenever there is a project, escalation, what happens?

Rupesh Bhatia:

The leadership from both the sides will have a call, will have email exchanges. What happens on email exchanges? You basically put a root cause analysis and a mitigation plan, or you justify whether there’s an issue, not an issue, right? Whatever the case is. It’s basically content, how you articulate that content on an email, how do you write that is what matters. Through one single email, you can douse the fire or through one single call among the stakeholders. You can dose the fire if you can communicate in the right way. And that’s where communication is a core aspect of any consultant and any developers who can pick up this skillset early in the game is bound to be successful.

Josh Birk:

So talking about communication broadly across this, do you see challenges that come up because of language barriers or cultural barriers? And do you have any advice with that?

Rupesh Bhatia:

Absolutely. And there’s a whole lot of myths that communication means fluent English. To me, communication is simplification of your words and articulating in a manner that my recipient understands.

Josh Birk:

Yeah.

Rupesh Bhatia:

Right. When you’re dealing with European stakeholders, their accent might be different than of with american stakeholders, right? And that’s why I say customer facing roles, if you get a chance to travel, always travel, because the more people you meet, the more cultures you know, the more empathy you will develop in your minds while working on projects. And that’s an important aspect in a consulting world as well. That even if you’re working remote, right, take that five minutes of your call, time to at least get to know each other. Right? Even if you’re having a formal discussion, not always once in a month, once in a while, take that Liberty of introducing yourself, giving your personal background, giving your cultural background.

Rupesh Bhatia:

Right. Try to understand each other, develop that relationship. When we talk about being a trusted advisor and building relationships, right? How do you build those relationships? Relationships are built with people, right, by knowing each other. On, how do we work? What is our work culture? From where we origin from? Right.

Josh Birk:

Yeah.

Rupesh Bhatia:

So I think that forms an important aspect of building human to human relationships. And that’s where we all can grow together. Right? I mean, projects gets delivered projects that are burning projects that are green projects, right. There are all kinds of projects. But I think as a developer, or as a human, if we focus on building relationships that will work for us in this professional lives.

Josh Birk:

Yeah. I totally agree with that. I love that. And I’ll throw up a quick perspective from somebody who is Midwestern or English speaking that I have found…and I’ve actually had in some of the interviews I’ve done with people where English is their second language, I’ve gotten this feedback back to do more of this. It’s like, be, be mindful of how you’re talking because you want to give a nice, easy cadence, like I occasionally talk fast when I’m really excited about something, which is not friendly to somebody who’s isn’t fluent in English. And then also be mindful of like how you’re speaking. It’s like idioms don’t always work and weird phrases, don’t always work, like be specific, be concise and just kind of get to the point. And I’ve rewritten emails because I’m like, “wait, that doesn’t make sense.” I can’t even remember what bad metaphor that was, but it’s not a good thing to put out there.

Rupesh Bhatia:

Right. And every individual is different, right? So everybody individually needs to do a self introspection of which areas they are good at. Are they good at communicating verbally certain things? Verses, are they good at putting things over an email? If they cannot…if let’s say the mother tongue slang comes in, while you’re talking, right?. Then it’s better to put everything on an email. Right. I know email is a formal communication, but then that helps you to communicate your thoughts. So every individual needs to find that spot for themselves with what is the right medium or channel for communication.

Josh Birk:

Gotcha. Okay. Well, a couple of final questions, but one just sort of broad one based, just kind of to ramp it up a little bit, from your experiences. Zachary Jeans once put it as, “From Scissors to Salesforce.” Do you have any final pieces of advice for people?

Rupesh Bhatia:

Yeah, I normally have it captioned in my blog, as well as with Zachary had in his blog, “fortune favors the bold.” So be curious and take your chances, speak up your mind wherever required and just be curious for everything and anything that you’re doing, whether it’s development, whether it’s consulting, whether it’s interacting with your customers, your peers, and the most important aspect of being in this professional world is having empathy. Empathy will help you go places, building relationships, because you can learn technology all your lives, but empathy is something which will help you build those relationships in the long run.

Josh Birk:

And that’s our show. Now, before we go, it turns out that Rupesh’s favorite non-technical hobby used to be, something I totally don’t understand…

Rupesh Bhatia:

When I was growing up, it was playing cricket…

Josh Birk:

Nice.

Rupesh Bhatia:

…but since I’ve been into the IT world I don’t get much time, but these days it’s would be, if I were to take some time off, my favorite place would be listening to some good Bollywood music.

Josh Birk:

And to be clear, I myself to enjoy a good Bollywood tale, but I might have to get Rupesh back to explain the basic mechanics of cricket to me. Thanks for listening. Thanks to Rupesh for the great conversation and information. If you want to learn more about this podcast, head on over developer.salesforce.com/podcast, where you can hear old episodes, read the show notes and have links to your favorite podcast service. Thanks again and I’ll talk to you next week.

Get notified of new episodes with the new Salesforce Developers Slack app.