In March's Stride Tech Talk, Debbie Madden interviews Paul Blair, CTO at NYC Tech Startup, to discuss this year's trends in NYC tech and fostering an environment of trust in tech teams.
You've been inside over a dozen NYC tech teams in your career. From your perspective. what trends are you seeing in NYC tech this year?
Over the past year, DevOps tooling and automation have been getting a lot of attention, with tools like Vagrant and Docker coming into the picture fast. There's also been increasing interest in microservice architectures, although there's some healthy skepticism out there. Functional approaches to software development are continuing to gain adherents; one of my favorite functional languages, F#, has picked up a surprising amount of steam over the past year.
Loved your recent Stack Builders blog "Software Development Runs on Trust". Completely agree. If you had to sum it up, what advice do you have for us in tech on how to be a trustworthy individual?
It's interesting that you ask about becoming trustworthy rather than asking how to get others to trust us, or how to find others who are trustworthy. I think that's exactly the right focus: Starting by focusing on one's own reality rather than trying to change others or their perceptions. If you want to be worthy of trust, then people have to know that you're a person for whom reality comes first. You can be politic about the way you say things, but you have to demonstrate that you'll be straight with people, even when it comes to bad news or things that are difficult to say.
What would you say are the top 2 things tech leaders can do to foster an environment of trust on their teams?
I'd say, first, by leading by example. Leaders will only have teams who trust each other if they themselves can be trusted. Second, I'd push as hard as possible to create a culture of problem-solving rather than one of blame. This is something I go into in more detail in my blog post on establishing trust, but I think a good summation of the difference is in the phrase "people do not fail, processes do."
The most well intentioned individuals will still make mistakes. How can we maintain that environment of true trust and still give timely and useful feedback to team members who have made a mistake?
Let's think about the goal of giving feedback about a mistake. Clearly, you want the relationship with the person to continue--you're not firing them. So your goal is not only for that person not to repeat this particular mistake, but also for that person to continue to do their best work on the team. Blame or criticism that undermines team members' self-confidence works against that broader goal. Focusing instead on processes and safety nets can help a lot here: What part of our process made it possible for this mistake to happen? How can we improve our process so it won't happen in the future?
There's an excellent book called Turn the Ship Around! by David Marquet, a submarine captain who turned one of the worst-performing subs in the Navy into one of the best. There's a chapter titled "Mistakes Just Happen!" which is a great case study in dealing with mistakes in a problem-solving, process-oriented way that fostered leadership and trust. I recommend it highly.