Are you a lone lemming or the master of your domain?
Many organizations hire only one database administrator. This lone DBA is in a unique position which can be both rewarding and challenging. I have spent years as a lone DBA and am able to compare the experience to years as a member of two different types of teams, a database operations team and a development team. I have learned that attitude and the use of professional powers can be the lynch-pin in the lone DBA’s success.
Take a few minutes to follow along with the stories of two lone DBAs, Joe and Cara, and see how their careers play out.
The lone lemming
The lone lemming, in this case, is Joe. Joe’s co-workers know very little about what Joe actually does. At least half of his day is consumed by daily tasks and the other half of the day is consumed by ad hoc query requests. This forces any dreams of improving his environment or working away from being a reactive DBA the lowest priority on his list and that has not changed in the last five years. Sadly, Joe is seen as error prone and is not sought out as a technical resource despite the fact that he makes infrequent mistakes and loves to learn. Often decisions are made about his technology without his input and he is expected to implement those changes without question.
Joe is currently a victim of being a DBA with one year of experience repeated ten times. The alternative is what most people expect, a DBA with ten years of experience. The difference between the two is that fact that Joe has not continued to grow or be challenged during his time as a DBA. He repeats the same daily tasks and maintenance, he has worked for the same company for many years, and that company is not big on change. Effectively Joe stopped learning in his first year and since has just been collecting a paycheck to maintain the status quo.
The worst part of Joe’s situation is that he has become disgruntled enough to complain about being over worked and generally unhappy with his job. The public complaining and disgruntled attitude has been destroying Joe’s expert and legitimate power for years, resulting in his exclusion from decisions.
Power and influence
I feel like I painted a pretty bleak image with Joe, the lone lemming. The be frank, I was thinking of two particular DBAs that I have met in the past. The negative scenario is intended to illustrate a reality that some lone DBAs live in. The root of Joe’s issues comes from a lack of power. In any business there are multiple ways of gaining and using power. For this post we will focus on two of them because they are the most positive sources of power and most applicable to Information Technology departments.
Expert power
Expert power is the power that is gained by possessing knowledge or skills in a particular area that is shared by or exceeds the knowledge and skill of your peers. In a technology position we are often judged by our ability to perform tasks and solve problems so building expert power should come naturally to us. Where many people struggle is by reaching for expert power in illegitimate ways, such as making up (bullshitting) an answer or, in generally, refusing to admit ignorance. Expert power comes from the other person’s trust that what you do and say can be backed up. An, “I don’t know,” makes the other person feel secure in their trust of your comments because they were not led astray. Following up with the answer, after researching or learning more, furthers the build of expert power.
Legitimate power
Legitimate power is the power that you gain from positional authority. If you are the only DBA in the company then you are implicitly the lead DBA for the company. You earned your position within the company and others will respect that title and role until you give them a reason not to. Legitimate power is more fragile than expert power since expert power comes from respect and trust. However, legitimate power, when used correctly, can also grow respect and increase its influence. The primary difference is that legitimate power is immediate and can easily be wasted while expert power takes time but can endure more mistakes.
Joe’s use of power
Over the years that Joe worked at DNTCN (Did Not Think of a Company Name) he miss-used or neglected his two strongest powers. The first offense was neglect. He neglected to exercise his legitimate power which allowed it to wither away like muscular atrophy. Exercising legitimate power is about reminding your co-workers of your responsibilities and ownership. Throwing a title in their face is not a very good idea but there are more subtle ways of going about this. A couple examples are:
- Demanding, in professional terms, that you should be included in meetings which affect your areas of responsibilities.
- Make decisions for systems that you own. Gaining input from others is great but you need to know that the decision is yours.
- Accepting responsibility for problems caused by or involving the systems that you own.
The second offense was his miss-use of expert power. Expert power is earned over time which means that Joe may not have ever had any expert power at all. This is not the same as lacking knowledge or skill, however. Expert power comes from your co-worker’s realizing that you are knowledgeable. If you horde information or fail to let your accomplishments be known, then you are failing to build your expert power. If Joe is more public about his successes, he might still have lost all of his expert power by reaching too high. Likely he answered questions when an, “I don’t know,” or, “let me look into it and get back to you,” was more appropriate. Every time he is wrong a sliver of expert power chips off and every time he refuses to admit the failure a large chunk of power is gouged out. Conversely, admitting ignorance strengthens expert power. Often the positive effect of admitting ignorance is greater than the negative effect of making the mistake in the first place.
The master of your domain
Joe has set a negative tone for being a lone DBA. Cara (another hypothetical lone DBA) embraces her lone DBA status and enjoys the life style. This is because she is the master of her domain.
Here are some of the benefits that Cara savors.
- Tackles a new challenge every time there is a chance for her to work with a part of SQL Server that she doesn’t often use.
- Provides input into nearly every IT project for the company, since most projects involve a database in some way.
- Publishes and maintains company policies for data management.
- Is a key voice in disaster recovery planning and testing sessions.
- Works heavily with automation.
- Acts as a code (query) reviewer for her co-workers.
- Her boss understands her work load and acts as a shield for ad hoc or pop-up requests.
- Takes advantage of consultants for large projects since the management team trusts her when she says, “this is too much for one person to handle.”
- Builds the ability to take time off by sharing knowledge and documentation.
- Company purchases tools to aid her in her daily activities.
- Company purchases books and other training tools.
- Is sent to training events regularly.
- Her resume spans multiple pages.
Cara has such a positive and thriving career because of her attitude about the job. She exercises legitimate power and provides input into technology decisions which affect her. The simple act of being in the right meeting can drastically change Cara’s work load.
Managing expectations
Cara’s presence and lead DBA status are important when technology and project decisions are being made. If she is present for the project planning meetings then she will be able to manage their expectations of her. For example, there is a new project coming up and one of the managers heard that transactional replication was great. They outline a complicated spider-web of replication publications and subscriptions on the white-board. They believe that it will only take one day to setup due to the availability of SQL Server Management Studio GUI’s to configure it. This is Cara’s chance to save her own year. She can explain to them the complexity of their desired architecture and express the true timeline. She also can express that, with her current work load, she is only able to allocate about 10% of her day to this project, which further extends the deliverable date. She also will shine light on the long-term time commitment which is required for maintenance.
At this point Cara needs to recommend a solution. It might be as simple as her agreeing with the architecture but needing them to understand her timeline limitations. It could also go as far as Cara recommended as different technology which requires less maintenance, or hiring a consultant to handle the implementation and setup the necessary monitoring and documentation for her. In that case, she is only accepting the on-going maintenance into her work load and other projects would not suffer. Regardless of the outcome of the meeting, Cara’s use of legitimate power had her in the room and a group of managers heard her objection to the timeline. That alone will keep Cara from burning out like Joe.
Standards
Piggy-backing off of the same scenario as before, where transactional replication is recommended, Cara can present technology choices as company standards. Cara knows that managing several different types of technology is more difficult than one solution repeated several times throughout her enterprise. For this reason, Cara has, in her role as lead DBA, documented policies for how data is replicated for disaster recovery and reporting purposes and prefers log shipping, where reasonable.
While in the project planning meeting, Cara needs to object to the complicated architecture diagram on the white-board and reference the company policy, that she authored, about where and how the reporting data can move. Cara should have one of two goals, either cut the complexity of the architecture to conform to the standards or convince the team that this system can meet business needs with the log shipping method instead. Having a pre-approved standards document is extremely helpful in this situation but, even without one, Cara is still the lead DBA and her stance should still be heard and considered.
Expert power’s passive mode
While Cara is wielding her legitimate power, her expert power is supporting her passively. Every word out of Cara’s mouth is supported by years of established trust and respect gained from the skills that she demonstrates. When she explains how long it will take her to implement the given architecture, no one questions the numbers. They know that she is familiar enough with the technology and her work load to know exactly how long it will take. They also trust that, if they agree to an extended deadline, she will deliver on-time. When she recommends log shipping with secondaries in STANDBY mode the team will ask her thoughtful questions about the differences and seriously consider the shift, even if they end up preferring transactional replication.
Cara also has an opportunity to actively wield her expert power by pointing out any technical flaws or limitations in the design. Then she uses her knowledge to help mold the solution into one that has a chance of real success.
Be the master, not the lemming
It seems almost too obvious to point out that you should want to be more like Cara than Joe. The only difference between the two of them was their attitude and their use of legitimate and expert powers. These professional softskills are critical in any business environment. Being a lone DBA means that you have to build those skills which are beyond your technical abilities because you do not have a team lead or some other pseudo-management role to work on your behalf.
Written by Derik Hammer of SQL Hammer
Derik is a data professional focusing on Microsoft SQL Server. His passion focuses around high-availability, disaster recovery, continuous integration, and automated maintenance. his experience has spanned long-term database administration, consulting, and entrepreneurial ventures.
Derik gives the SQL community credit for plugging the gaps in his knowledge when he was a junior DBA and, now that his skills have matured, started SQLHammer.com as one small way to give back and continue the cycle of shared learning.
Derik is the owner and lead author of SQL Hammer, a Microsoft SQL Server resource.
For more information, visit http://www.sqlhammer.com. Follow Derik on Twitter for SQL tips and chat
The post Lone DBA, Lemming or Master of your Domain appeared first on SQL Hammer.