<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=338168267432629&amp;ev=PageView&amp;noscript=1">
Project Management

Have A Great Relationship with Your Software Team

Let’s talk about how we collaborate across industry lines: Bixly bringing tech and software expertise and our clients bringing their own industry expertise. Sometimes, communication can get muddles, but this is our approach to successfully bring the team together! Full Transcript Below: Cris: The expertise and a team that …


Let’s talk about how we collaborate across industry lines: Bixly bringing tech and software expertise and our clients bringing their own industry expertise. Sometimes, communication can get muddles, but this is our approach to successfully bring the team together!

 

Full Transcript Below: 

Cris:

The expertise and a team that brings expertise and not just bump heads.

Andrew:

Can you keep the client’s vision in front of us as we go.

Cris:

So actual, tangible task lists of things and completions. How do we put this feedback in front of them? So that way they can have it in a useful state.

Cris:

We get to talk today, which I think is a fun topic and it’s very kind of relational, but we’re literally talking through relationships with your dev team. So how do you have the best, most effective relationship with your dev team? And we get to just pontificate on some of the things that we do and how we have good relationships with our clients and with our dev teams and make everyone happy.

Combining Client Expertise with Ours

Cris

So how are we going about combining our tech expertise with that of our clients and our industry expertise in their industry? How do you marry all that world and have good clients that bring expertise and a team that brings expertise and not just bump heads? How do we do that? How do you recommend clients do that when working with their dev teams?

Andrew:

Well, we really try to… I think we start with really understanding the client’s problem and really, metaphorically, getting on the same side of the table as them. And we’re trying to solve this problem together. Let’s understand it. Once we understand it, we can start to translate it into technical terms that the dev team can work on. So I think it’s just about starting with let’s all get on the same page. What does the problem look like? What does success look like? And then we can help you translate that to actionable items that the devs can actually run with and turn into a real application you’re going to use in your business.

Cris:

Gotcha. So rather than just come in and spitting up a bunch of knowledge and expertise that we have, and then the client doing the same thing on the other side, it’s let’s find that common ground together. What’s our problem that we’re going after together? And then we can obviously leverage our different areas of expertise, because we may not know a particular industry that the client is bringing to the table, but we know the problem if we talk it through, and then we can figure out how to solve said problem.

Andrew:

Yeah. You know your industry. You know what the problem is, and you know what success looks like. We know technology, and we can help you bridge that gap into a technology solution that actually solves your problems.

Delivering Feedback

Cris:

Got it. Okay. So obviously building through projects, there’s lots of feedback. There’s always feedback loops. How do we present feedback to clients? How do we put this feedback in front of them so that way they can have it in a usable state and get something from it?

Andrew:

Well, the most common way we do that is just with regular remote video conference calls with our clients. So we want them to see us, in many cases to see the devs, and we can bridge that distance by just FaceTime and really being able to continue to keep the client’s vision in front of us as we go. We share with them what we’ve done over say the last week or day since we last met, what we’re going to do next until we meet, and what are just any kind of roadblocks we have in our way. And then the client can help us talk through those things, and we can help translate those again into dev tasks.

Cris:

Yeah. So actual, tangible tasks lists of things and completions. And then also on top of that, demoing product obviously.

Andrew:

Oh yeah. You get feedback.

Cris:

We’re actually showing them, here’s what we did. And then how are we receiving the feedback from them as we put this stuff in front of them, whether that be logs of tasks completed or actual app demo? How do we receive the feedback and how can we as a dev company receive feedback well to help the client move forward?

Andrew:

Well, we just receive the feedback through communication and our normal channels. There’s nothing really particularly technical or difficult about how we receive feedback. It’s really, I think, the understanding of the heart of that feedback, if there’s any frustrations maybe the client has, or expectations that need to be realigned. So we take that, we look at a plan, we adjust that plan if necessary to fit the client’s new, latest, most evolved thinking. And then we just iterate with the devs until we can incorporate that feedback and make it a reality.

Cris:

Gotcha. Not every client that we’ve worked with has been amazing, and I’m not here to just dish on bad clients, but how do you handle those relationships where it’s maybe a little bit more volatile? And this is really a real question because as chief of operations, you’re very involved in projects. Why do people keep coming to us and working with us as a company? Whether they’re good, bad, or otherwise clients, they kind of just all like to work with us. There’s something there. So what are we doing? How do you deal with those bad clients, those good clients, and everyone in between?

Andrew:

And most clients aren’t bad.

Cris:

They’re not. No, they are. They’re fantastic.

Andrew:

I’ll look at, try to identify the source of their frustration. Most often it’s a breakdown in communication, whether that being that they haven’t really made the project a priority. So they’re kind of out of the loop or that for some reason, they envisioned it was going to be something different than it actually was. We now address that through roadmapping and prototyping, that kind of thing, so our clients are seeing things much earlier in the process. So we have a lot of efforts in place now to really set expectations early, to help mitigate that risk. But if we do run into issues later in the project, we usually just compensate with over-communication. We take the time to really make sure they understand. Let’s really get a good feedback loop in there.

Andrew:

And I just kind of become a stickler about dates and okay, “We need this from you by Tuesday. Okay. We’re going to provide this by Thursday. We’re all going to review together on Friday.” We go from having maybe like one 30 minute check-in to a few check-ins to make sure everybody’s in the same page. And again, really, it just comes back to, let’s all have the same expectations. Once those are aligned and there’s a good feedback loop, it’s not real common for there to be frustrations because we know what they want, and we’re delivering what they want. And if for some reason we run into a roadblock, we talk about that with them and figure out a way to get around it.

Receiving Feedback

Cris:

Gotcha. So we can adapt to those roadblocks and adapt to the different customer needs that come up. So how do you see us managing that kind of tight rope of presenting and receiving feedback between our dev teams and our clients?

Andrew:

Well, we like client feedback. It’s kind of scary when they don’t have feedback. So we really appreciate feedback. And then we look at the feedback in terms of trying to classify as, “Okay, is this more like something that’s in our area of expertise? Is it more technical?” They’re suggesting something that we’re really more in the experts on and know more than they do where we should insert ourselves more or is it more just something around their business and something really they’re the expert on. So if it’s something that’s around their business, we’re going to really help them unpack their expertise and, “Okay, what do your customers need here? What do they expect? What are the pain points?” And really draw… With that feedback that they gave, we’re going to draw that expertise further out of them so that we can make that something actionable. If it’s something-

Cris:

Because we may or may not know that industry.

Andrew:

Probably don’t. Yeah.

Cris:

Probably don’t because there’s no way in the tech world that we can know all these industry verticals. We’ve touched on that. We’ve worked on them. We can relate this business process or problem to another vertical, but we may have not actually worked in that particular vertical. So we want your feedback. We want your expertise. We want to receive it and distill it down, but apologize, I cut you off.

Andrew:

And then if it’s more technical, in other words, it’s something that they don’t really know what they’re talking about, which does happen. Then we respectfully interject and help them understand why this thing that they’re suggesting is maybe not the best idea or maybe it is. Maybe they do know something we don’t know. There’s been cases where a client will say like, “Oh, we want — this screen, we should have these seven different colors on it.” And it’s starting to look a bit like a circus tent. And you have to respectfully convey that to them, that this isn’t really… Let’s look at some other designs. This isn’t really a way it’s done or it’s going to be confusing to users.

Andrew:

Or a really common one I see is, let’s ask the user to perform… Give them options to perform seven different operations on this page. And it can become overwhelming, confusing. And because they’re not a UI expert, they maybe don’t see that. And so we help them say, “Okay, this is the objective you’re trying to do. You’re wanting to add this functionality, but how can we use our design expertise and UX expertise to break this up into segments, which are just much easier for the user to digest?”

Cris:

Yeah. So it really is this tight rope walk of leveraging the client’s expertise, leveraging our expertise, and knowing when you need to stick your heels in the sand a little bit and be strong, but also present the reasons why you are the expert and this is important. And when to say, “You know what? This is not in our lane. So let’s draw more back up from the customer.”

Andrew:

And when this comes up, something I often do with the clients is, they’ll suggest something very specific like, “Oh, we just need to add yet another button to this page.” It’s like, “Okay.” I try to really understand why are they doing that? What are they trying to achieve here? What’s the problem. And I’ll just tell them, oftentimes there’s more than one way to achieve that thing. So if you really explain to me what you’re trying to accomplish, rather than just what to do, I can present you options. And there may be options that are faster and cheaper than what you’re suggesting. They may say build a whole new page that has all this stuff. And it’s like, “Well, do we really need to do all that engineering? Couldn’t we just do it this way for 20% of the work?” So that’s just an example of the way we interject our expertise.

Cris:

Sure. And this is also, I think, working on the assumption of a more non-technical client. We’ve worked with some very technical clients. And so again, presenting feedback, receiving feedback also is how much of an expert are you on this particular topic problem and how much of an expert are we? And you just find that balancing act. So we love working with, I would say, both non-technical and technical clients alike and everyone in between.

Andrew:

Right.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday. I hope you enjoyed that conversation with Cris and Andrew as they discussed how to have a great relationship with your dev team. And that could be a dev team that you have internal to your own company, your own team members, or even if you’re working with a company like Bixly, an outside firm. If you have any questions at all, don’t hesitate to put them in the comment section. And don’t forget to check out the description box down below. We have a bunch of really helpful links for you guys, including a link to our free custom software guide, as well as a link to our website bixly.com. And right at the top of our website, you’ll see a button that says get my project roadmap. And that gives you a free 60-minute call with Cris to talk about your next app idea. Until next time, this has been an episode of Bixly Tech Tuesday.

Similar posts

Get notified about the latest in Tech

Be the first to know about new tech from the experts at Bixly!