Building trust with your offering team
What would be your strategy for building trusted relationships with stakeholders?
This question appeared on an instant message chat with a colleague the other day. Quickly admitting that this is a hard question to answer, I shared the generic trust-building motivation response:
– Trust takes time to build.
– Trust depends on your approach to the situation as you move from outsider to insider.
– Your approach during the initial meetings is what lays the foundation for building trust. You can’t just show up for the first meeting with the team, stating that you are here to save them. Or start asking questions like why the offering should exist.
– Your actions will speak louder than words.
– The more they see you giving shape to their ideas, the more likely they will be open to hearing your thoughts.
While this might be the typical advice you hear when discussing the topic of building trust, it fails to highlight the journey to building trust. A better way to answer this question, and to showcase how these generic trust-building advice statements happen in the real world, was to share how I personally go about building trust.
How I build trust with my team
When I joined IBM Z, my first offering assignment was on a new project to bring some technology to the marketplace. The offering at that moment was more an idea and a couple of prototypes. The first issue was determining the direction of the offering. I spent those early days just learning their prototypes, understanding the technology, what insights it may give users, and asking for a couple of clients to talk with about the subject. After a few weeks of near-daily changes in direction, I suggested that maybe we should write down some hills to help us focus on the first-release goals and state the user value. I didn’t do a full-blown design thinking workshop. Design thinking had not reached this area of the business, so the team wasn’t ready to commit to a two-day workshop run by the new guy. We worked together over a couple of meetings to give their ideas shape. By week four, we had a decision on the direction.
With that direction, I started working on the interface design. I made hand sketches to give shape to their ideas at first. I would create recordings and gave demonstrations of the experience. As we iterated, I started to introduce my ideas into the offering, starting with answers to their questions, but later adding new visualizations or other means to provide the insights. I kept iterating using pencil and paper until we got to something that we felt met the user’s goal.
It is hard to find users to validate ideas for a new offering. Many clients lacked the test automation required to leverage the new invention; thus they couldn’t see past their current hurdles to see the value of the insights. However, internally we were able to find folks that had the testing automation and could understand the value of what we proposed.
These design iterations allowed me to start building trust with the offering team. My actions demonstrated that I had skin in the game. They saw me giving life to their ideas, so they started to listen to my other ideas. I have a front-end development background, so I suggested using a new development stack. I was able to convince the architect but not the lead developer. While they choose to go in a different direction, it caused them to think differently, and they agreed to modify the front-end stack to match my design (which was going to take some extra development work). We got the initial offering out the door and celebrated that first success.
After that release, I took on a management role for a different set of offerings. I wasn’t able to continue with the team for a year, but I kept in touch. I started introducing architects in the family of offering to design thinking through a couple of workshops as a way to guide discussion around creating a multi-offering shared based. After the year, I was able to convince the management team to build a design team for that offering. I offered to manage that new team. It wasn’t perfect. A few designers were able to build trust with the offering team; others were not able to build that trust. As their manager, I kept working with the design and development team to adjust assignments to improve the working relationship between the teams. Two of the four designers ended up leaving the team late in the year. I wasn’t able to backfill the loss, which meant their new project didn’t have the resources.
I got invited to a call to discuss, where we walked through the large amount of work for the two offerings as the design manager. They had acquired a third offering that now was looking for synergies between the two offerings. During the meeting, they kept asking if I could join the team to help start this new project. I eventually agreed since it was a short-term assignment. My initial thought was that I could work with the team for three months, establish a vision, establish a better working relationship among the 3-in-a-box (Offering Management [OM], Design, and Development), and hire designers at the start of the next year to continue the effort. The way they saw it was that they got someone who knew their offering inside and out, a strong collaborator who wasn’t afraid of getting their hands dirty with technology.
Trust is a funny thing; once you earn a team’s trust, you tend to keep it. However, you can quickly destroy trust by pushing your agenda or letting your ego shut down your ability to keep an open mind. I could have walked in that first day working with the team and pushed my vision for the offering. I could have told them all the best way we should be working and forced them to work that way. That path would have killed the trust I’d built. I took a different path.
There was an offering in the market that was being sunset. Our mission was to figure out how to improve upon this base experience and incorporate it into the new offering. The architect walked OM and me through the current experience. We all looked for ways to improve the experience. We started learning together about the market. We all added new ideas to the new To-Be experience. We used design thinking activities, which was the new normal with most offering teams, to create hills and build a roadmap of hills. The OM was able to find several solution vendors, customers, and internal users who could guide us along the way. We started to validate the ideas together with these customers.
Notice that there was is a significant change this go-round: the OM, architect, and I started working as a team. We were no longer handing off work to each other as before or waiting on someone else to make a decision. We were in lockstep through the definition phase, pushing each other to do better. The only way this happens is that we all trusted each other. We took our ideas to the entire developer team to begin the construction phase. We walked the team through everything.
As the developers were discussing how to build different aspects of the experience, I started sketching the UI and building small prototypes in real-time. My prototypes were searching source code for business terms using regular expression through some random source code. These prototypes allowed me to showcase my understanding of the discussion, guide the meeting, and give me sample data to use in the future.
As we were wrapping up this two-day technical session, the VP of development stopped by for an update. He asked me to walk him through the experience, and he asked the developers to explain how the new technology would work. I had to trust them as I didn’t have time to prepare anything. I didn’t have any storyboards or a prepared story. I had random sketches of possible interactions and the output of a couple of searches in a text document. I quickly scanned my scribbles and projected my laptop screen to the room (see figure). I walked the VP through the story. Other than the comment that my drawings were hard to follow, the VP understood the direction and was excited about what we were building.
We continued to work as a team throughout the development cycle. As with any new method of working together, team members (including me) sometimes got upset due to miscommunications or misunderstandings during the pressure of a release cycle. After cooling down, we moved on and continued working towards the goal. We trusted and respected each other enough to work through the issues together.
We delivered the first hill to the market on time. The other designers were able to build trust as well through their actions and leadership during the project. We ended the cycle with a better way of working, trust among all parties, and a vision of prioritized next steps. I was even able to hire on a couple of designers to continue working with them, so they would continue to be successful. I still check in on the team from time to time. Two years later, things are still going smoothly among the 3-in-a-box.
I hope you find yourself in my story–that these techniques and paths I’ve taken are something, you’ve tried as well. For those who are struggling, I hope that the story will highlight the following:
– Start with a humble approach (“How can I help?”) when working with a new team.
– Give shape to their ideas before mixing in your ideas.
– Spend some time learning about the real offering experience, their competition offerings, and an overview of the technology in the offering.
– Your actions will speak volumes more than your word when building trust — showing that you have skin in the game.
– Check your ego at the door and watch out for things that destroy trust.
– Nothing will ever be perfect. How you recover from those imperfect moments is what matters.
– Avoid being too pushy with new methods of work, meet the team where they are, and incrementally try new things together.
Next time you’re starting out with a team or even working with your current offering team, think about ways you could improve trust by trying some of these ideas. Don’t hesitate to modify them for your situation. Soon your offering team will be working better together.
BJ Scheid is a IBM Distinguished Designer at IBM based in San Jose, CA. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
