As a developer, I’ve often worked with a team of others, where we discussed the software we were building, what architectures and patterns to adopt, etc. While we all learned to work together, there were plenty of times that it felt as if we were working separately on code, but arguing often about how to make a decision about a technical approach or a priority.
As a DBA, I’ve often worked alone, though usually interfacing with different teams as needed. In these cases, I’ve often had to learn to make my own decisions and then justify those to others later. The few times I worked with a team of DBAs, it seemed as though this was still the model, independent work, though with everyone deferring to the senior DBA.
Building a team takes work, and it can be difficult to do so without the support of management. I’m always amazed at how many managers undermine the building of a high performing team, often in contrast to their words or the company’s statements. Many don’t even realize how poorly they promote teamwork, or how they actively prevent it.
Assuming you can get support, what do you want in your team? I saw a neat post on the habits of high performing teams. These are some of the things you want to install in all your members. I’ve rarely had high psychological safety, though I think we do now at Redgate. I especially like the idea of leveling experience points. I hadn’t thought about it in these terms, but that makes perfect sense to me.
That last section, where we assume our peers are competent and intelligent resonates with me. I haven’t always done this in the past, but I have tried hard later in my career to listen more, and to assume others are working with the best information they have. Perhaps that’s different than my information, so I should try to have a discussion, not a lecture or a dismissal of their effort.
That’s something I wish I would have learned a lot earlier in my career.
Steve Jones
Listen to the podcast at Libsyn, Stitcher or iTunes.
