Good relationships with colleagues in different specialties and different teams are a key to learning and succeeding. I was lucky to start my software career in an organization where we collaborated and learned from each other. Despite my shy nature, I intuitively forged relationships with people outside my team as well as within it. For example, I often baked brownies for the machine room operators. They were key to the success of my batch jobs!
Relationships for success
Thanks to this early experience, I naturally built bridges with people throughout the companies I joined. After finding and meeting the business analyst, I’d ask them to invite me to the requirements meeting (in the waterfall days!) I’d ask the system administrator to pair with me to learn how to configure our continuous integration pipeline. I’d ask a fellow programmer to pair and show me how to use the IDE. Customer support people helped me identify where to focus testing in the next release.
When I started my last new job, I asked the platform team managers if I could schedule a 1:1 with them every couple of weeks. At one early meeting, a manager told me about the new deployment tool that we would be migrating to. Shortly thereafter, the platform engineer embedded in our feature team asked me to create a testing strategy for our migration. I had another chat with the manager to pick his brain about all the risks we should be watching for. We ended up with a sound testing strategy and the tool transition was smooth.
What bridges might you build next?
You can see from these examples that it’s usually easy to start a good working relationship, even with people in other parts of the company. And, these relationships produce huge benefits for everyone. Sadly, there are companies with toxic cultures where talking to people in other teams or departments is forbidden. If you do have the freedom to contact colleagues outside your team, use this to your best advantage.
What does your network at your job look like? To figure out opportunities for helpful relationships, I like to draw a dependency map. It helps me think outside the box about what risks our team might face, and who could help us prevent or address them. I draw circles representing different parts of our app. I add circles representing dependencies on other systems and other teams. Then I can prioritize whom to reach out to next. Here’s an example of one of my dependency maps:
You can find more ideas on how to build bridges with people at work in the “Collaboration beyond development” chapter in Katrina Clokie’s book, A Practical Guide to Testing in DevOps.
(If your team wants to help in identifying dependencies, improving collaboration, or other topics listed on my training page, please get in touch with me.)
