In this episode, we were joined by Jonathan Mergy, who at the time of this recording was the Director of IT for Tides, to talk about the systems needed in complex organizations.
We discussed:
- The decision to apply a product or platform approach, the build vs buy dilemma, and how organizations should approach this decisions.
- What it means to really manage a tech platform in an organization, as essentially, you’re managing a product internally.
- The digital maturity needed to pursue this path and how teams and roles needed in a more digital organization.
Please note: this conversation was recorded in December of 2020. Jonathan has since moved on from his role at Tides, and this podcast discussion is presented with permission from Tides.
Learn more at tides.org
Come see us at PEAK2021! We’re thrilled to be leading a session on May 6th at 3pm, Where Intention Meets Action: Operationalizing Trust Based Philanthropy. Or swing by the exhibitor hall to chat with one of our friendly team members.
Episode Four Transcript:
Jonathan Mergy:
Dealing with this decision making around the build or buy kind of a thing. There's different ways to address it, but ideally you want to be able to buy a solution. Ideally, you would love to be able to step into something and say, "Great, this is awesome. We can just configure it here, a little bit here and there and be fine." There's that mantra that I have heard and I even said, the 80/20 rule where, "Let's buy something that can cover 80% of what we need and the other 20%, we'll kind of figure this out." I think the challenge that a lot of folks have is that 20%, unfortunately, might be absolutely vital and critically important to be able to tweak or to adjust or whatever, because it's connected to brand or it's connected to the process that you want to have in your organization.
James Law:
In philanthropy, the path from setting strategy to seeing success can be a little difficult. Here we dig into the experiences of grant makers figuring out this journey for themselves to help us all better understand how to operationalize our mission and our vision. I'm James Law, Director of Innovation here at Grantbook, and this is The More Good Podcast.
In this episode, we were joined by Jonathan Mergy, who at the time of this recording, was the Director of IT for Tides. And we essentially wanted to talk about the types of systems needed in complex organizations to achieve mission. We really focused on the quintessential question or dilemma, should you buy a product or a platform—the build vs. buy approach—and how an organization should approach this decision. We then also reviewed what it means to really manage a tech platform in an organization, as essentially, your team is now managing a product internally. You need to do the design, you need to do the solutions analysis, sometimes even do the build itself, and you definitely have to do the support. Lastly, we touched on the digital maturity needed to pursue such a path, and how teams, roles, and even governance need to change in a more digital organization.
Please note, the conversation was recorded in December of 2020. Jonathan has since moved on from his role at Tides, and this podcast discussion is presented with permission from Tides. To learn more about Tides, visit Tides.org.
James:
Hi Jonathan.
Jonathan:
Hey James. How are you doing?
James:
It's going well. How are you holding up? How's the end of the year coming through?
Jonathan:
I think we're ready. We're ready for the end of the year. I think we're ready, but it's going well.
James:
Yeah, I think everyone's feeling that. It's been such an intense time, obviously with COVID. We're Canadians, but with the Americans, of course, you had your election. So, I just imagine there's quite a lot that everyone's ready to chill out from a little bit.
Jonathan:
Absolutely. Yeah, the election with everything else going on and just learning how to work and execute and be successful with everything that we're trying to do, absolutely, it's been a tough year.
James:
Even towards the end of this year where we're all trying to wrap things up, I want to thank you for taking some time to speak with us today, because I think your organization, and we're going to get here in a second, just has a really important perspective on a question that a lot of folks we've worked with and seen have been sort of I think really struggling with and trying to figure out. Which is this movement towards more flexible systems, but then really trying to understand and think about what that means for an organization, how to support it, how to build in it, how to keep it from going haywire, going sideways. So, I think your insight will be really critical. Thanks so much, really, for doing this even though we're really getting towards the end here.
Maybe to get us started ... I actually think Tides is quite famous. Most people know Tides. But maybe for those who may not know Tides or maybe not know Tides really well, can you tell us a little bit about the organization and then maybe your role there as well?
Jonathan:
Sure. Yeah. We refer to it as Tides just because there's so many different legal entities that make up Tides in the United States, but the primary areas are ... at our core, we're a community foundation. We also have a fiscal sponsorship entity that is kind of like a nonprofit incubator for small nonprofits in the United States. Then we also have a real estate angle as well in San Francisco and New York where we're a master, a leaseholder on a building in New York, a master tenant in a wonderful location in San Francisco called the Presidio where we also have tenants and nonprofit, like an ecosystem in San Francisco and New York that we also manage.
So, those are the big chunks that Tides does, but obviously we're connecting with so many different organizations in the sector and also in the corporate sector as well just around social change and around a lot of the things that we really want to be able to do for the world. We have a core organization of staffing of about 150 or so employees that manages and supports these different entities. Then in that nonprofit incubator at Tides Center, which is a fiscal sponsor, we're one of the first organizations that really started fiscal sponsorship, they're about 700, 800 employees from time to time. That could constitute anywhere from 150 to 200 projects that are mission focused projects for different areas that are working in the social change world and environmental and other different focus areas.
A lot going on and a lot going on between different constituencies and different audiences. So, really being able to make that connection and make that partnership being intermediary but also be kind of an agent for those partnerships. I'm the Director of IT for Tides. I came in in 2015 and really led this larger rollout and system needs assessment around our core platforms and around financial systems, grant management system and other related systems and then also worked with other folks on business process and other stuff and continuous improvement.
James:
It sounds like both you and Tides have quite an extensive repertoire of work and responsibilities and skills. It's a complex organization or series of organizations that requires I think a fairly complex role that you do hold. Maybe we can just get right to it then, because this is the question that everyone asks us. I think reflecting on the complexity that both your organization has and that your role has and maybe the interrelationships that the individual entities and people have, I want to sort of hold that context and then kind of get into it to think about for your technology systems because it does come down to that day-to-day. How did you approach choosing what ultimately was a platform approach in Tides? How did you sort of come to that? How did you make your decisions around that? What do you see happening right now as you sort of roll it out a little bit?
Jonathan:
You see it in the various groups or organizations that I'm a part of that are with other organizations in the sector and just dealing with this decision making around the build or buy kind of a thing. There's different ways to address it, but ideally you want to be able to buy a solution. Ideally, you'd love to be able to step into something and say, "Great, this is awesome. We can just configure it here, a little bit here and there and be fine." There's that mantra that I have heard and I even said it, the 80/20 rule where, "Let's buy something that can cover 80% of what we need and the other 20%, we'll kind of figure this out." I think the challenge that a lot of folks have is that 20%, unfortunately, might be absolutely vital and critically important to be able to tweak or to adjust or whatever, because it's connected to brand or it's connected to the process that you want to have in your organization.
That's where I think some of these decisions or discussions start to have challenges where you do want maybe to step into a platform environment where there's not as many walls up necessarily, but you do have the ability to focus on specific areas that might be just super important to your internal staff, your partners, your clients, who you're working with, your connections. So, to not have that is a real challenge. I think that's definitely the case for Tides to be able to have an environment that we can rely on and then be able to have the wherewithal if we want. It doesn't mean you always go there where you're going to do all this development and make all these changes and build all this stuff. But to be able to have that option if something is super critically important to you, to be able to do that in a way that's a very thoughtful way with the capabilities and connect into this evolving platform that other sectors, other verticals, other organizations, other people and organizations that don't even have anything to do with you but they're innovating in as well so you can leverage that ecosystem.
I think that's a discussion and that's a decision you have to make as an organization when you're looking at what you're trying to do from a technology perspective and what systems are going to play in the systems/process/people aspect of everything that you do, how much you want in there. I think that's really, really helpful. Then also, what's out in the vendor landscape I think is really important as well.
James:
Maybe we can lean into that 20% a little bit, because I want to hold onto that note. It's so critical when folks go out and think, "Am I buying a product? Am I buying a platform?", honestly, even then searching amongst the variety in that landscape, those verticals, I guess we can call them, or those areas. We often run into people saying, "Well, it does most of it. So, if it does most of it, isn't it good enough?" I'm wondering if you can expand on your experience of that 20% that ends up making or breaking it. Maybe how you worked through that as a team. What are some of those things that were in that 20% for your team?
Jonathan:
I think your point on, "Yeah, we can just work around this stuff. It's minor compared to the core functionality that we get," that's absolutely true, except if something is in that 20% or that small area that maybe something can't be configured or tweaked or whatever. It's so involved or it's such an impediment into what people are hitting on a day-to-day basis. Like the way you do, in the grants management world, maybe the way that we do award letters is a certain thing, but that's actually something that's super critically important and maybe super impactful for the people that are involved with that.
It kind of doesn't work to say, "Hey, it does all the core stuff," but these pieces that are kind of ... I wouldn't even call them icing because it's really something that's critical to the overall process, "We can't change that or we can't move that button over there or we can't do this," those type of things maybe in a one-off perspective aren't that distracting. But when you start to stack them, they start to become very distracting. So, they might be minor functional issues like login information or the way something is presented in a portal or some of those things. The data's there, so you could make an argument that, "Wow, it's there. Somebody gets it," or maybe it's in a format that maybe isn't ideal but the information at its core is there.
If that's part of who you are and how you want to operate and you can't change that, there's really ... it's very frustrating, because you're not really representing what you want to represent to your constituents and your audiences. So, being able to make those changes in a platform environment ... We've seen a lot of examples where we've gotten feedback from portals. I mean, nobody loves their donor portals, right? Let's just say people love their donor portals, but the idea of, "Wow, wouldn't it be great if we could make this change here?" The fact that we can do that, it's a decision. It's not us trying to motivate another party to do it for us or get functionality in a product roadmap that we don't own. Those types of things are really important. It actually shows that we're really able to cater and contour the environment for our audiences.
I think that's super important. We've seen that play out over the last couple years where we've been unable to do it and we've been able to do it. It really shows that we're trying to improve things because we have the ability to be able to make those changes. They might be minor to some, but they're significant in the totality of it all.
James:
I think whole minor to some, significant to the totality is so critical about experience. I think in our sector in particular, we're talking about philanthropy, philanthropy tech here, I think there's a lot of throwing around some days, rightfully some days, not so rightfully, of the term, sort of user experience, UX, human centered design, all those terms. I do want to call on this lens, because I think with Tides in particular, you have such a diverse audience, right?
Jonathan:
Yeah.
James:
You have all your donors. You have your incubators. You have these social purpose organizations that are just trying to do the work. So, I imagine that 20%, even if it's just where a button is, is so critical to this wide audience that you're accountable to.
Jonathan:
No, absolutely. Also, just even the spectrum ... Again, maybe Tides could be an outlier here, but the spectrum of even just the classifications of the audiences. You might have very sophisticated users that are highly technical that expect. Also, I think the expectations just in the world, you know, what systems they're interacting with in other areas of their lives now versus where maybe you were isolated years ago and a donor portal was, I'm picking on donor portals, but any interaction with things, you were just happy to be able to have access to the data at any step along the way.
When you're working with individuals or you're working with organizations ... We're based in San Francisco. We also have a location in New York. We're working with tech companies. We're working with founders. We're working with high-worth individuals that know that it doesn't need to be like this. So, the idea of being able to make those changes and make those tweaks and improve the user experience based upon feedback and based upon interaction, this is something that it's a back and forth and it's for the larger goal of really making the work happen and getting the resources where we need to get the resources and moving that. That's the end goal.
So, how do you get these distractions out of the way? If these things are distractions, it's really frustrating to not be able to move some of these distractions out of the way around UI, around, "That button over there is this." Again, buttons, reports, some of these other things that are maybe parts of the overall process, but if they're not done right, and again, you start stacking these things up, it can be an overall. It's a much larger thing when it's just some of its parts, if that makes sense. So, to be able to have those decisions. Also, it's just empowering for your staff too, because now your staff is also helping you, your internal teams or people, are also helping you to be able to keep improving. There's not this fatalistic, "Well, that's just what it does," or, "Maybe the next version, they'll come out with and they'll do it."
We have the ability to do it. What that does to you also, James, is it changes the dynamic to some degree, because then you have these requests. Then you've got to now have a process and think about how you're going to create that pipeline for improvements or what constitutes ... how do you weigh some of these improvements? Those are all things that we've been navigating or working on, like Salesforce, for example, where everybody's coming to you with improvements and ideas. At least you're getting that feedback and you're able to have that feedback loop. Now everybody's working on trying to improve versus, "Okay, this is how you guys have to do it until we make them change something," or something along that line." It's a different conversation to have. Everybody's on the same team to work through that. So, it's a good conversation to have. It's definitely more complex, but it's where we want to be to keep improving.
James:
Got it. There's a lot of lessons learned there. I really enjoy the word navigation, because it is a system to navigate. I also think Tides, even to get here to today, played a journey from our understanding and having worked together around technology. You sort of started on a platform, and I think you made a bit of a turn and then now you're back to a platform approach. Do you want to share a little bit of wisdom or lessons learned about how that journey came to be and what you've learned from that process?
Jonathan:
Sure. I mean, a few years ago when we were looking for a new grants management system, we'd had a Salesforce instance that we were using for some aspects of it. Honestly, we weren't in the mindset to really go out and say, "Let's go build something, or let's go work in a platform environment." I don't think the organization was necessarily ready for that. We really wanted ... I think this is probably other organizations that might be out there listening, you don't want to be unique. You want to believe that what you do makes total sense. Everybody probably does that, right?
So, you're open and flexible to tweaking maybe some of the processes to make it compatible with something where other stakeholders, other organizations are maybe invested in and want to keep evolving the platform. That's kind of where we were, and we did that. Again, I think we kind of underestimated that 80/20 thing where that 20% that we couldn't change or we couldn't move around turned out to be really, really important. One of the things we did was really take an inventory and really say, "Well, what's going to make this work for us?"
Organizations are very hard on themselves when they make systems selections, I think, because they change too. So, even in our process, by the time when we made that decision and we implemented it and got it going and we had it up and running, we had also changed a lot of our core business processes, some of our leadership and kind of how we were going to run. So, when we came back to Salesforce, it was after really looking at the landscape and really looking at what was out there and really also taking a self-inventory on what we needed to be important.
I think maybe at earlier selection it was just ... I'm sure other organizations are out there thinking this too, "Just any investment in any new system is going to be better than what we have, because it's so old and it's just horrible." I think after moving to another system and then having to reinvest and look at a new system or a new platform decision or whatever, really taking that deeper self-inventory on what's important, what's going to make a difference for us, and then really making that call and being open to saying, "Let's make this right. Let's make the right decision here. Let's get us on a path that we can keep evolving this based upon how we change as an organization and how the sector is changing, how our audience is changing, the type of partners that we need to work with. How are we going to handle those relationships? Can we have a spoke that we can really tether to that we can keep evolving with?"
James:
Interesting point on organizations being hard on themselves when it comes to picking a solution. We see this too. We work with organizations, and there's this anxiety like, "If I pick the wrong thing, this is all going to mess up." I do also think coming from where a lot of foundations are coming from, which is from fairly dated technology, literally because it was just made decades ago, almost any interim step is better. I guess maybe one way to think about it is, in your perspective when you look back, was that stop gap worth it? Did the organization end up learning a lot about itself that it wouldn't have learned otherwise so it could get to this point today? Do you think you could have kind of made that jump anyways? I'm really curious about your perspective on that.
Jonathan:
No, no, it's a great point. I hadn't thought about that all that much recently. No, it definitely was an improvement, because it got us to a point where we had to clean our data. We got us to a secure environment. We got us to a lot of other things that ... We got us off an environment or a platform that was end of life that was unsupported. So, we were in a better spot even though it was an interim step. Then getting us stable at least, it wasn't awesome, but at least we were running, we were executing, we were doing what we needed to do for what we needed to do. Then that gave us enough runway to really have us be able to look at those things.Also too from a staff perspective, I didn't have the staff then to really ... at the time we did the ... So, now we've got staff, we've got more stakeholders in the organization to really be able to get us on that next step. It's an interesting point that you brought up. I don't think we could've made that leap and really understood the value and the commitment to move to that if we didn't know that just anything wasn't going to be better. We needed it to be better and be able to do that.
I think also too, you really need to be able to have IT staff or technical staff that are really ... Tides is very lucky. My team is ... I'm just so happy and so proud of my team. They're really embedded and connected, and they really care about the business processes that we need to deal with around grants, around finance, around the different areas of the organization. So, they are really seen as partners to the functional areas and connected to that. So, they want that to be better.
It isn't a transactional thing where we're going to tell you what we need, then you go make it and then come back and say if we did it or not. It's really a back and forth and it's really a collaborative team effort. I don't know we were there when we made these kinds of decisions and went down that road. It really made us come together a lot better to make sure that we were putting in a solution that was going to be scalable for us longer term. Then also finding and connecting with amazing partners in the space, like Grantbook is right there, and being able to say, "We don't have to do this alone. We don't have to reinvent the wheel or build it from scratch. We can leverage a partner that has that knowledge and has done with other organizations." So, we can leverage some of that that we're never going to have in-house, that knowledge and that experience from other implementations and some of the challenges. Then also to spot, augment maybe some of our capabilities like around project management, around change management and other things.
I think that's where, to Grantbook's credit, I mean, I think that's where you guys are positioned to be able to help and help on the technology side but also on the intangible side of some of the project management, change management, other things that are really going to be able to get you over the hump on these kind of things.
James:
Totally. I think this is where, again Jonathan, you and Tides because you've gone through this, there's this wealth of knowledge to continue to explore here. Because when you moved towards a platform approach, I think you mentioned it, instead of relying on a vendor and then saying, "Oh, let's put it on your road map. Why isn't it on your road map? Is it on your road map yet?", you end up having a lot more power. With a lot more power comes really great responsibility, and tensions can rise up in an organization if your team feels like, or people perceive your team, basically being a product team.
I'm wondering how—you touched on this earlier—how have you structured your team in the organization to meet where a platform can take you? How is your team working with others to make this a success?
Jonathan:
Yeah. No, I mean, I think the team is really, really important. You've got to have an empathetic team on the IT side that are really connected and want to have that technology be meaningful and be meaningful in the process and want to extend. So, my team is really ... they're application support folks, solutions architects that are really embedded in thinking about improvement in managing the kind of development queue. Then there's a cross-functional team that we work with from finance, some, I'll call them client services, but I know other foundations have program staff, but really all connected.
There's got to be that respect and trust and work in there from an IT side. My team is technically, if you look at the financials, they're in IT, but they don't feel that way. If you ask them, they're not. They're just technical leads in these different areas to help information what needs to happen on some of these things and maybe add some structure and then also either directly implement or work with amazing partners to get some of these things. You've got to have that translator.
I look for people in my team that, first of all, they've got to care. They've got to be connected. They've got to have that empathy. Then they've also got to want to be able to translate and step into things and step into environments that they don't necessarily understand yet but be open to that and grow with that and then help partner that. Again, I think this is something I'm sure probably other organizations ... We're not necessarily always dealing with cutting-edge stuff. Although, I think some of the platforms that we deal with, we really are. We've got to have it anchored back to what we're trying to do and how effective we're trying to make these things.
Honestly, maybe some of the C-suite or whatever they have, they may or may not fully understand what we're doing on some of these things, but the idea of being able to put it in terms and translate it for folks so they can appreciate that and show that we're connecting and improving and innovating across the different areas. So, I keep it very, very simple, and I think you and I have had these discussions before. My department really runs the organization, innovates the organization and grows the organization. Most of what we do are in those three buckets. It's almost like a portfolio, the way I think about it, where all of those are very, very important and very, very valuable. So, I want to make sure that we're showing that transparency that we're hitting those with the different areas of the organization.
James:
With your team a little bit more embedded and working with other functions, one of those roles, and this is something we've discussed, that becomes a little critical for them is to demonstrate the value of leveraging technology more deeply, thinking with a little bit of a tech lens, thinking a little bit from a design lens, maybe not always just mocking something up in a Word doc and being like, "Make this but in a platform," which happens a lot, and that's okay. I'm wondering, how has your team started to navigate that? How have they demonstrated the value of having technology and a more IT mindset at the table?
Jonathan:
Yeah. I mean, you need the stakeholders in the different areas that are going to be open to that. I know my team and they've definitely been able to have wins, show some wins, make some wins, take the effort. Maybe choose your battles too. I mean, a lot of these things where maybe that's not the coolest way to do it or the nicest way to do it, but it's something that somebody's going to own with you. Maybe we can improve it in the next rev.
So, don't go to the mat on stuff just from a pure technical perspective. Definitely consider the people and the process aspect as well. Then also, and we don't do enough of it, but we always talk about it and we try to do more, is training and really just having people sit with the systems. Especially this year, it's been challenging because everybody's back to back to back Zooms and everything else, but really trying to just have people work through it.
Honestly, the thing that I've been really impressed with, James, is when I've seen my staff in work sessions with folks and somebody goes, "I really want to do that." "Okay, well let's just try it and see what happens." Having people see that connection from request to delivery and showing how that works makes them go, "Okay, they're listening to me. I feel heard. I feel connected. I've got feedback there, and I feel that I'm connected and co-owning this with everybody." I think those areas are really, really important, especially on something like a platform like Salesforce, it's not that you can't do something. It's more should you do it, and then how?
I think that's where there's so many different areas. I think the same thing with vendors and partners that are doing development with us or whatever. I don't necessarily want them to do the things that we ask them to do. I really want Grantbook to come back and say, "Yeah, we know you want to do it this way, but we have five other ways that we think are better." I want to be able to have that trust and that respect to be able to say, "Wow, they're looking out for our best interest. Maybe we don't need to create this custom thing. We can leverage this new ... "
That's happened multiple times, I can tell you, with Grantbook where somebody from Grantbook has come out and said, "You know, we couldn't do it that way six months ago, but Salesforce just came out with a new function that now we can do it that way." I've been thinking about that. It's just you want partners that are going to be thinking about your best interest, even when you're not asking them to. So, that all builds into this circle to be able to make what you do better.
If that's the important thing and that's what people take away, that's awesome. I would argue that the only way you're going to make some of this stuff better from an impact and scales perspective is with technology. So, I tend to want to downplay the technology piece just because I think I don't want people to, in past lives, I don't want people to think that I'm coming with a tech heavy lens. I'm really coming with an impact scale lens and better lens, and it turns out those things require technology if you're doing them right, in my opinion.
James:
I think that's a very important perspective to take, because I think people do often ask, "What is the driver? Why even do any of this?" For some folks, it can seem like a bit of a make-work project, even though they can't pull a report for anything worth its weight in water. I really appreciate this lens like, this is all for impact. This is all for mission and purpose. It will help us scale it. If someone buys into this, and a lot of people are ... A lot of folks are leaning into it, and some of them haven't even done, what I'm going to call, recovery, which I think you folks did. You had some fairly end-of-life technology. You took a bit of a half-step, or however we want to call it, the first step, that allowed you to remediate a few things. Then you went forward into a platform build. I think some folks honestly just want to make the jump. If they are making the jump, I'm wondering, sort of looking back, if you could give any advice to yourself, a younger Jonathan-
Jonathan:
If I knew now what I knew then. Yeah, yeah, yeah.
James:
Yeah. What would you say? What tips would you give folks? What do you really need to have in place before you open the doors to this sort of implementation.
Jonathan:
I mean, I think these are all things that I think you know, and I know I knew and I'm sure people know at the time. It's just not so much to choose your battles, but you kind of go with what you got. I would've loved to have maybe stakeholders that were bought into certain things and had different concepts around some of those things from an organizational standpoint. Also, I would've liked to have a stronger sense of what our process was, what we wanted to move around on.
These are all things that I think everybody in all these organizations are probably trying to do, but at a certain point you're also kind of motivated. The walls might be on fire, so I've got to get moving on this. I think that's the trade-off that a lot of organizations make is, "Wow, we can really do a ton of analysis, and for six months, redo our processes and really focus on that." The reality is, people aren't motivated to do it unless there's a destination to put it in.
That's where you have this. I've done other financial systems in past lives are large logistics systems and re-engineering and everything else in other sectors, in other areas, and it's kind of this chicken and the egg thing where you don't really have the motivation to do it unless there's something pending. I think just trying to give more time on that and really be able to get buy-in on what the processes should be and really be able to focus in on that.
Now, again, I think that the young Jonathan would say the exact same thing, but you're also in certain scenarios where you've got to move on things. So, really choosing your deal breakers, what areas you need, what you can live with, what you can't. I think it's easy when you do requirements even at a very basic level or a very detailed level for everybody to throw everything in as deal breakers, but there really are priorities. So, really sifting that out and getting the real high priority deal breakers, "We can't live without these things," at a minimum, and then everything else in a gray area and then really calling out the things that you don't care about that maybe other people have or other people need or whatever, really sifting through that.
That's not a direct systems thing. That's just kind of getting into self-inventory on that. That's really challenging to do when you're dealing with systems and you've got to make a move and somebody wants something better. So, really understand what's going to work for you, and then build that partnership across the different stakeholders and get those functional owners bought in so it isn't a tech sell. It's really a functional solution to sell, and technology is supporting that. I think you can always do more there. I mean, you can always empower the people that are dealing with the systems in a frontline way and understand what they're dealing with, what are their challenges, what's going to move the needle for them and connecting with that. Sometimes you don't necessarily get that when you're doing these selections.
Honestly, really putting that stuff together and moving. I tend to favor action versus inaction. Some of those things really make a lot of sense. I think the other big pieces don't expect that you need to build everything on your own. Even in a platform like Salesforce, there are a lot of standard tools in there, a lot of standard objects, a lot of standard functionality that you can repurpose. So, you don't have to build all this custom stuff from scratch. You can leverage that.
Then also, find awesome partners that know what they're doing that are looking at it from a holistic perspective that are able to say, "Well, you kind of do what other people do in this way, but it's slightly different." Then take that feedback and work with it. I think all of those ... you can always do more of those. It's definitely tricky for everybody, and I've been there. I'm going to be there again, I'm sure, at some point here. You can do your homework. You can do your front work, but at a certain point, you do need to move on things.
I think just trying to make the best educated guess or educated decision on things at the time. You're always going to have 20/20 hindsight on things, but the idea of being able to move forward and trying to improve and build that partnership and build that trust with people that you're there to help them succeed and grow.
James:
I do really appreciate how we do talk about tech, which is fairly hard. Then sometimes we even talk about processes, which are softer, but it's still fairly hard. I do appreciate it all coming back to a certain extent to a level of, this is going to sound a little cheesy, but I think there's a level of kindness and just openness and understanding that everyone needs to bring around this. It seems like if you get that ethos in the organization, it makes things a little easier as you navigate through because it's going to be a journey for everyone...
Jonathan:
I think there's also ... If you get momentum and then people are seeing ... I think a lot of people are just used to also seeing things stop or start and then drop. So, if you can get momentum and you can show that this thing is happening even though you're making small strides on it or whatever, I think the momentum factor can kind of build confidence and kind of get people on board as well.
James:
Excellent advice. That is an excellent piece of advice to give, and I think for us to all take to heart, even if it's not perfect. If you're still going and the car's moving or the bike's cycling, whatever it is, you're doing...
Jonathan:
Transparency, transparency is a big one. Showing what's happening, why you're doing it so you can be consistent on your messaging and you can say, "Yeah, it didn't work the way we wanted it to, but that's okay. We're undaunted. We're moving forward with this, and here's how we're going to go." That's been a lot of ... to keep the momentum moving even though you might not be moving at the peck that you want to make.
James:
Very fair. We could talk forever, Jonathan. Right? Because there's so much here. It is so rich. As we think about wrapping up, there's one or two questions that we always like to ask folks in a bit of a speed round towards the end, just because these are things everyone is curious about. I mean, Tides is huge, so this is probably hard to answer, but what are some of the key tools in your giving tech stack? What are the key things you folks rely on day-to-day?
Jonathan:
Yeah. I mean, Salesforce is that client interaction layer, so we're doing Salesforce Communities. Then we're doing a lot of work off the standard objects, Salesforce Cloud Service, other things. So, a lot of Salesforce stuff and a lot of Salesforce add-ons, DocuSign, some of these other tools that are in there as well, obviously, on the Salesforce front end. Then NetSuite is our core financial system that we implemented a few years ago. We're doing some kind of very interesting stuff with Salesforce as well. Then there's an integration between Salesforce and NetSuite around the grants processing.
We're also doing NetSuite out to our bank where we're sending XML payments, ACH, wire, other things via that. Box is also another one of our big platforms just from a secure file storage perspective. We also have a lot of integrations going into Box from our bank around bank reconciliation, check images, things like that, basically that lockbox functionality. Once we went kind of work from home with shelter-in-place, really getting things scanned in, coming in and then bringing them into Box, bringing them into other systems as well. Those are the big ones.
Obviously Office 365, some of the other things. Then I think Jitterbit right now is our platform as a service integration tool between the systems and doing a lot of different streams and everything else. There are a lot of good integration tools out there. The other thing around project management, probably like other organizations out there, we have a lot, probably way too many. That's just because of the different capabilities and different needs that people have that might be more task oriented. So, maybe they just like tasks or they like the way that it's represented in the Kanban or something for a Trello or Smartsheet or whatever. Then we have more strategic planning stuff around Cascade, which is really great to be able to take a mission/vision approach and get into initiatives and other things. Also Google Docs and other stuff.
I mean, there's a lot there. We've tried to kind of funnel that down, but it's a challenge, as people can tell. People are comfortable with the tools that they're comfortable with. So, you want to be inclusive, but you also want to be sane. So, I think navigating that is a whole other discussion.
James:
I was going to say, we could do a whole other episode on application portfolio management and all of that, I'm sure.
Jonathan:
Yeah. Yeah, yeah, yeah.
James:
Well, maybe to help us wrap up, I'm wondering if people listening, if they're curious about anything around Tides or Tides' work. Anything you want to share where they could go?
Jonathan:
Yeah. I mean, our marketing communications folks are doing a great job obviously on our website and on our Twitter handle @tidescommunity, they're really doing a lot of activity to try and capture all the different things that our ecosystem around Tides doing in the social impact space, social change, around our environmental justice and a lot of work around underrepresented populations in the United States and around the world, so voting rights, other things.
I would say that the Twitter handle Tides community is very actively maintained and also doing a lot of work on LinkedIn where they're just trying to get more partners and educate on all the different things that Tides and our project and our donors and our partners are doing. So, those are great spots to hit.
James:
Perfect. Well, thank you so much, Jonathan. I think it's been an absolute pleasure and a ton of wisdom and experience and lessons learned dropped into our conversation today. So, thank you so much.
Jonathan:
Oh, James, thank you so much. No, it's been a pleasure. We love Grantbook, and just happy to have this conversation with you about stuff that, boy, I think about all the time. So, great to talk to somebody about that. So, thank you.
James:
Definitely. Well, I hope you can take a bit of a break from thinking about it too much as we enter our winter holidays.
Jonathan:
Me too, me too.
James:
Be safe and be well. Okay, Jonathan?
Jonathan:
Appreciate it, James. Take care.
James:
Thank you.
And so wrapping up here, just a quick reminder that in the time between recording this conversation in December 2020, and publishing this podcast in April 2021, Jonathan has moved on from his role as Director of IT for Tides. We’re sharing this podcast with permission from the Tides team.
The More Good Podcast is produced by Sara Saddington. Grantbook is a strategic technology consulting firm for grant makers around the world. Don't forget to subscribe to the More Good Podcast wherever you get your audio and learn more about our work at grantbook.org.
