An office tradition at my company invites employees to celebrate Halloween by dressing up in costumes. It is surprising how innovative folks can be in a conservative insurance corporate setting. Conservatism is cast aside as scarecrows, mummies, witches and other Halloween characters roam the halls.This year I sported my Lone Ranger costume I put together for a costume party last year. Sometime during the day the mood struck me and I tweeted a photo of my gun slinging ranger self. The tweet read: “So, Do you agree or not agree with my database design?” It seemed like a pretty humorous thing to do.
After tweeting, I thought of the irony of the tweet. I often do feel like the Lone Ranger many times in my role as database designer. This is not unique to my current employer. I have seen a similar pattern at all of my employers. A database designer and DBA are assigned to a large project team of mostly application development team members.
As much as project and IT management tries, there is a good bit of friction in this data to application development relationship. The data voice is easily ignored or minimalized by the majority members of the team. A lot of this friction has to deal with ownership of “the design” that most likely started with business systems analysts and moves forward to other application development team members.
How do data modelers, data architects, and DBAs overcome the perception that they are interlopers on the project that just slow the project down? Of course, there is no simple answer. Here are six things each of us can do to be a team member and be recognized as a team member.
- Build relationships – Today’s fast paced development methods and ever changing technologies requires each of us to understand the world beyond our role. This requires us to know our fellow team members, what they are trying to accomplish, and how they plan to accomplish it.
- Add value– There is no time today to work on tasks and deliverables that are a dead end. Constantly evaluate the usefulness and applicability of your deliverables. They should always add value. If they don’t, you shouldn’t be creating them.
- Teach – You most likely never thought of yourself as an educator. It is important that you educate (and not lecture) team members on your role, deliverables and importance of your work to the project and enterprise.
- Learn – Whether you have five years or twenty years IT experience, you should always be open to educating yourself beyond your area of expertise and responsibility. “You never truly know someone until you’ve walked a mile in his shoes.”
- Barter– Learning how to give and take works in most professions as it does in life situations. It works very well on a project team. Knowing when to compromise without sacrificing your duties is a skill that will serve you well.
- Stick by your guns– Although bartering is important, knowing when not to compromise is just as important. Data folks assure the integrity, security, compliance and completeness of data (to name a few common attributes). Never barter away something that compromises data.
Team dynamics is complicated. Much of this dynamic is dictated by corporate culture that may be beyond your control. There are always opportunities to work within a culture to affect change. Using the above characterizes in your everyday work gives you an advantage in making change. Be part of the change you want to see.
Modeling Global User Community President
Follow ERwin online through Twitter, Facebook, and LinkedIn.