On a short project, clients need evidence not only that work is happening, but that the team knows when to continue, when to change direction, when to raise concern, and how to leave others capable of carrying the work forward.
1. Close the Feedback Loop – Show Responsiveness.
It’s extremely important to get feedback quickly and rapidly. Limit planning or infrastructure to chunks of half days. This way we can check in with the stakeholders about what to do next. Having little time to make mistakes doesn’t mean you don’t make mistakes. It just means you realize you’re making them earlier. The way to do this is by getting feedback quickly. We use a combination of in-person check-ins and videos reflecting the best kind of work possible.
How does this relate to building trust?
This relates to building trust because you are showing the client that you can adapt to changing needs and process thoughts quickly. You will not go and hide away in a place and do the wrong thing for a long time before someone tells you it’s not the right thing to do. So wasted efforts are reduced. Frequent check-ins also show them that you’re constantly reflecting on how to do things better. This reassures them that if they leave for a second, the work will keep going. You are going in the right direction; if you’re going in the wrong direction, you can quickly adjust while there’s still time.
2. Make Invisible Work Visible – Provide Evidence.
It’s tempting to want to set up a test suite, but it’s also important to understand that only a certain amount of testing is super important. Building trust in a client is important early on, especially in short engagements, so visible work is key here. Creating a plan for the limited testing is a good way to start.
Our client was resistant to setting up a testing suite and said, “Honestly, I feel like it doesn’t make sense to write tests because the UI is changing. In this case, his concern for time is valid. There were features we weren’t touching that needed to work and needed to be ported over to the new application. This meant there were some features we needed to make sure we did not break. Making sure regressions were caught early and fixed was extremely important, especially since, if they were caught after we left, then we left them with a product that was potentially worse off. A limited suite of regression tests for the most useful functionality is important.
How does this relate to building trust?
You are clearly showing them progress towards their goals. There is no doubt when concrete evidence shows that their investment is producing clear results they can touch and see. There is no contesting this.
3. Calibrate Priorities Frequently – Demonstrate Judgement.
Often, for such a short engagement to work, we need to be able to reassess whether the initially agreed-upon priorities can be met with the new information received after starting the project. Often the agreement to do certain things is really just a target or assessment of what can be done. Sometimes these priorities change depending on different findings, like analysis of the current codebase or analysis of the limitations of certain expectations.
Sometimes we work on something, see the result, and realize we need way more time to finish an agreed-upon thing. In such a case, the client may opt to reduce scope or prioritize something else that is high-value and can be completed in said timeframe. Regardless of the issue, the client will appreciate you checking in on priorities often. In such a short engagement, we did so at the beginning multiple times a week after some stints of development, especially because the client felt excited about some of these changes and things were not clearly agreed upon even by the team internally.
You want to reassess whether the priorities are the right ones. Sometimes an idea that seemed good on paper does not seem so good during implementation, or new information makes something less feasible or unnecessary. In these cases, it is very important to offer alternatives or discuss a reduction in scope. You should even reassess goals if there is a clear indication there might be a better direction or if the client realizes that’s a better option. Checking in to get feedback on how we are doing to work towards those priorities seems really important.
4. Surface Doubts Early – Manage Risk Honestly.
There were times I was questioning myself about how much juice I could get out of what i was doing. A perfect way to put it is the juice is not worth the squeeze. In retrospect, I should have definitely questioned the worth of my work earlier. Of course I did eventually decide, “Hey, this is a good stopping point, so let me switch,” but I did see the client visibly anxious about the amount of time spent on testing.
I was working on some CLI tools to make integration testing easier, and it took me a few days. It was Thursday, and the client was visibly anxious because they had a goal of “Get something visible by Friday” so he can show the stakeholder who was paying us to be there. He had been convinced of our value and worth but had to show the stakeholders we were worth the money to keep on. We were confident we were worth the money, and it was a slow process.
But in this situation, it was also about making our client look good, which is an important consideration when building trust for the first time and trying to do a good job. Ultimately, what we did was showcase and go through some of the testing work we did so that we could continue working on it, but we definitely could have established earlier some guidelines about testing with the client to assuage their anxiety about the visible work. I should have told my tech lead, “I think this integration testing is too thorough for a first pass.”
5. Create Self-Sufficiency – Leave them Stronger
Good consulting should enhance the client team’s capacity rather than just implement changes. Building a strong relationship with the developers is crucial as it fosters trust and facilitates meaningful feedback on technical decisions, like package upgrades.
It’s essential to make developers feel supported, not just by speeding through tasks but by providing thoughtful contributions—such as writing clear PR comments, improving documentation, and sharing skills to streamline their workflow. These actions may seem minor, but they significantly impact buy-in from the client devs.
Treat the client’s codebase with the same respect you would your own. This generates trust and encourages advocates for your work among those who interact with it daily. Ultimately, you’re not just doing your job; you’re helping others move forward alongside you, creating a positive ripple effect.
Trust on a Short Project
Trust is earned, and once trust is broken, it’s hard to rebuild. But if you are smart about how trust is built, then it can be extremely beneficial to maintain the relationships that add lots of mutual value to you. Building trust takes time, but if you have little time, you have to be very strategic with it. If you apply these tips, though, trust will be a byproduct of the principles you follow.