Have you had your annual checkup yet this year? If not, might want to get a move on; no one likes surprise health issues! I think we can all agree that a proactive approach to one’s health is good. Why then, would you not also regularly check the “health status” of your business relationships? Knowing whether or not your relations are healthy can improve the business transactions within those relationships. In this spirit, come along with us while we lay out our selected five signs that the collaboration with your tech vendor will be healthy.
Client Centric Service
The first sign of a healthy collaboration with your tech vendor is client centric service. We all know the popular sayings, “The customer is always right” or “Customer first” but let’s be real, this is not a B2C situation. Though, a vendor which has a client centered approach is likely to deliver you, as the client, a better finished product. Let’s look at some key factors herein…
Communication: Clear, Fast & Easy
When it comes to collaboration, the importance of communication cannot be overstated. Yet, what type of communication are we referring to here? The three keys to watch out for are clear, fast and available. The communication should always be clear, direct and understandable without any room for misunderstandings. It should also be expeditious, coming in a timely manner devoid of delays or leaving people waiting in the lurch. Last but not least, engaged parties need to be available, no one likes playing phone tag.
Empathetic & Relevant
Additionally, an empathetic and relevant approach from the vendor is always desired. Vendors often will be able to see current or future potential problems in your business before you may even notice them. The vendor needs to genuinely try to understand what your problem(s) is and actively engage in a conversation trying to get down to the root of the problem in order to offer the best possible solution.
One way to check is to ask your vendor, “What do you do to create a culture where your developers will voice concerns if they see a problem?” At Slash we strongly believe in maintaining a work culture that encourages our developers to speak up as this benefits all parties involved.
Also, be sure your discussions are relevant. For example, if you ask the vendor about their services, and they tell you their operating hours… um well, you get our drift here.
A good vendor knows or understands what the client wants in advance; of course, this comes from experience and a desire to truly help the client. When your vendor prioritizes focusing on what your business needs and delivering the best product, it enables them to anticipate some of your needs. It’s like, “I know where you’re going already so I know what you need and can anticipate potentialities therein”
Slash believes all of the aforementioned points contribute to a client centric service; therefore, we focus on delivering this value to our clients. This sign will point you in the direction of a healthy collaboration with your vendor.
Our second sign for good collaboration is decision making. More specifically who and how decisions will be made absolutely must be discussed and decided; there can be no compromises here. Why are we so adamant? Well, for the vendor there’s nothing worse than having a client that constantly tells you, “I have to ask my boss first.” Therefore, the decision making structure needs to be established to ensure the product is delivered speedily. Of course, the most common individual during development who’ll play a big role in this is the Product Owner. That being said, at times you’ll have someone covering commercial decisions; plus the vendor will have a lead developer for technical decisions, and an iteration manager or scrum master for productivity issues.
If you interview a potential vendor and he doesn’t ask, “Who’s going to be making decisions?”, this should be a big red flag for you. Work needs to get done, and decisions must be made in a timely fashion; this can only be done if a clear structure is set into place of who makes what decisions. Decision making is one of the most important factors that defines the development speed. If you haven’t decided the decision process and perhaps there are 20+ stakeholders involved, decisions will likely take months rather than days and you’ll be in for a rough ride. Therefore, here at Slash we make it a priority to define the boundary of how much we must rely on the client to decide, and how much freedom we have to decide.
Speaking from experience, you don’t want to find yourself in a situation where you’ve left the vendor waiting an excessive amount of time for a decision to only discover they already moved ahead. You’ll find yourself saying, “Hang on, we never asked you to do that.” Yet your vendor will be thinking, “Yeah, but we were waiting for a decision for three months and we can’t have a team of developers sitting idle collecting salary while you’re taking your sweet time to make some decision.”
Moving on to sign number three, leadership. What do we mean by leadership here? To begin with, you should feel from the conversation with the vendor that it’s not a transactional conversation; i.e. – not, “What do you want?… Yes, we can do that.” If so, take note of the red flags and find the nearest exit! The vendor is not here to do what you want, but rather what you need.
The conversation should go more along the lines of, “What do you want? Why? How…? What constraints or obstacles are currently present?” and so on. This is a clear sign that the vendor can lead you in the right direction of a product that will deliver value to your business; a product you don’t just want, but more importantly need. The vendor will guide you to what you need and leadership is key in achieving this; asking a variety of questions, tough ones included. If you’re unsure if the person understood what you said, ask them to paraphrase it back to you. If they can successfully do this then you can be more confident in the collaborative effort, if not then the collaboration will suffer.
Be on the lookout for times in the conversation when the vendor is cornered so to speak. You’ll notice the red flag if the vendor tries to worm their way out of the situation rather than being direct and honest. Your vendor should never shy away from their responsibility to openly discuss any issues and possible workarounds and solutions therein. Nobody likes being taken for a ride so be sure it doesn’t happen to you.
The fourth sign of healthy collaboration is experience. When meeting with your vendor, ask them about a project or two that went badly. Why did the project go poorly? What did they learn from that experience? How have they changed and/or improved since then? Just as a baseball pitcher can’t have a perfect record, neither can your tech vendor. Naturally they’ve had some projects that didn’t turn out so well and even some that may have failed. Ask them to openly discuss this with you and see what they’ve learned from those experiences.
If something seems off, something is likely off; go with your gut and don’t let them fool you. Transparency is also key here in regards to experience. You should be asking your vendor who is going to be doing what work on the project and what their level of experience is. As you’ve rightly assumed, the salesperson is not the one doing the work so take a moment to get to know about the people who will be doing it. Learning about the people can also give you insight into your tech vendor’s approach to the development of the talent they have working for them. Are they actively helping their employees grow, becoming better developers? All this can be a good barometer for the experience of the vendor you’re dealing with.
Agile experience is a must and therefore our final sign of healthy collaboration. Agile is the new norm in tech development. Why is that, you may ask. Well for one, most companies want the development speed that ironically outpaces them genuinely knowing what it is they want. So naturally in this hectic environment the workflow must be clear and the vendor must be able to explain to you their preferred way of working. What are the team sizes? What are your expectations? How will the vendor approach this project and challenge?
The fact is that nowadays in the tech development world, there are few linear models left to develop. A linear model being the development of a product for a known problem and solution; one not requiring any experimenting or iteration. Previously and still in some cases, Waterfall was employed for these projects as the solution was well-known to a well understood problem.
However, today’s tech landscape is rife with unknown problems and unknown solutions; unknown unknowns. Therefore, Agile takes a very different approach than the traditional Waterfall in order to tackle these challenges. If your vendor lacks experience in agile and is trying to produce a product that requires that approach, your collaboration is going to be dead on arrival.
Before we sign off, just a quick note on practicalities. Naturally when you gather people to work together, it’s a good thing to know the people you’re working with and ensure there will be no major personality clashes. As well, this is tech development and you are well aware the developers working on your product are likely in various time zones so be mindful of this when scheduling anything. Additionally, it’s good to take note of calendar holidays so you don’t get mixed up with days they are on vs days they’re off.
Ultimately you want to have a healthy relationship with your vendor; not only during this project, but potential future projects as well. People don’t buy products and services, they buy relations, stories and magic. The level of collaboration will of course, depend on the product you’re having produced and be greatly influenced by your relations with the vendor. Either way, you want to be sure that collaboration is healthy, efficient and productive. So be on the lookout for those signs and happy developing!
Tag CloudAgile - Agile Delivery - AI - amazonecommerce - Animal Framework - Attracting talent - Autonomous weapons - B2B - blockchain - businessbuilding - Business building - Clean code - Client consulting - cloud platform - Code Refactoring - coding - Company building - Computer Vision - Corporate startup - cryptocurrencies - de-risking business building - Deepfakes - Deep Learning - DeepMind - derisking business building - Design Research - Developer Path - DevOps - Digital Ownership - Digital Product Strategy - ecommerce - entrepreneurs - Figma - founder equality - founder equity - front end developer - Fullstack Engineer - Growth strategy - Hook model - Incubator - innovation - Iterative and Incremental Development - legacy system - Manual Testing - Metaverse - methodology - Mobile Engineer - Natural Language Processing - NFT - NLP - online recruitment - playbooks - Podcast - Product Design - Product Development - Product Development Strategy - Product strategy - product versions - project management - Prototyping early-stage ideas - Quantum Computing - Recruitments - Remote Work - Research - research problem - Robotics - Sales machine - scalable software - Scrum - Self-Driving Cars - Serial entrepreneurs - Slash - software - software design - Software Development - Software Development Company - Software Engineering - Spotify Model - Staff Augmentation - teamwork - Tech Talks - tech teams - tech vendor - testing playbook - The Phoenix Project - Unit testing - user interview - user retention design - VB Map podcast - Venture Building - Venture building strategies - Venture Capital - venturecapital - virtual retreat - Web3