March 29, 2008 at 5:51 am
Comments posted to this topic are about the item The Exceptional DBA
March 29, 2008 at 9:03 am
Wow, that's quite a project you've taken on, Tony!
Here's my take on the two scenarios you gave:
#1. Gather the information on cost versus benefit by research, talking to users of the reports (if possible), and so on. Write up your findings in a manner the CFO can understand - break it down by cost of product, usability, known problems, potential problems or issues, maintenance costs, and so on. Schedule a meeting with the CFO to discuss your findings. Be open to the possibility that there is information you don't have that would change the cost/benefit ratio. Ask question of the CFO in relationship to your findings; for instance:
Is there information I'm not aware of that makes this purchase critical for the company's success?
Is there a specific need driving this purchase? Can you share the details of that with me?
Will this product position us for future benefits, even if we won't see immediate savings or benefits from it?
Is there additional information you'd like me to research related to this? I'd like to help the company make the best decision.
#2 The first thing I'd do is meet with the project manager. Outline the issues in a non-confrontational manner ("Houston, we have a problem...") and ask what you can do to assist them in their job. Come prepared with possible tasks or items that you could help with. Have suggestions for how to improve the project and meet the deadline ("Can I suggest some things that I think might help us reach the two-week goal?") Consider it a "team training" opportunity, because even though they are inexperienced, they are critical to the success of the project - and they probably have skills you don't have. You may also need to work with them on future projects, so build a solid base of trust and mutual support. Help them ferret out the major issues that are slowing the project down, and explore possible resolutions to those. Does the project lack a critical resource? Is there someone else outside the current team that could help get it back on track? Offer to support the project manager in requesting what is needed (i.e. joint email, or visit to the CTO's office - whatever is necessary to get the project on track.)
I'm not a DBA, really a developer trying to learn enough to write decent scalable code, but the things that will make an excellent DBA extraordinary are not the technical issues, as you've already indicated, Tony. It's the "soft skills" - the ability to deal with people, encourage them in their field of expertise, lend assistance when needed without forcing your own personal "rules" or viwepoints on others. Communicate with both team members and upper management at a level (and with verbiage) that they understand. Be a problem-solver - look for solutions (as soon as you're done complaing about the problem - we're all human, after all! 😛 ) I'd say if your team members enjoy working with you most days, you're already on the right track. If upper management listens to what you have to say (whether they agree with you or not), you're doing something right. If you'd like to keep improving on both of those, the best way is probably to ask your team mates and your manager that most simple of questions: "What do you need from me so you can do your job effectively."
Steph Brown
March 29, 2008 at 9:52 am
1) If you're in position of something that will be implemented but won't be effective, it seems the CFO makes the questions and the answers by already having chosen the solution to its problem. Because you're a professional and you see details that he cannot, you assume that it won't work. But the problem is not here. YOU should be the decider of the technical solution. So :
a) Your CFO recognize you as a technical authority, he has a problem for which he already has fancied a solution; tell him gently that how urgent and/or important it is, it is a classical project that should holds within a window of money, time, and human resources. Have an iterative process that slices the features he wants in several sub-features. As a technician, you should detail the precise tasks that each feature involves and not say "well, implementing a BI is 2 weeks/months/years" without knowing what you will precisely have to do. The matter is not to have precise estimations of what time it would take, but what we gonna do exactly (and most important, what we are NOT going to do). Based on that, you will have more people or more resources or more money or most probably, a reduced feature set, that would be less sexy but more realistic.
b) Your CFO does not recognize you as an authority in choosing BI solution and does not want to hear what you have to say, he just wants the job to be done and has read a lousy article in "BI magazine" that comforts him in asking you to do this way. Go see the one he reports to, aka the CEO. Ask him to remind the CFO that he is not a technical authority and that you are responsible for technical success and failures. If necessary organize a meeting with all three because if it is really important it would lead to a more strategic decision.
If the CEO fully supports your CFO and does not want to recognize there is a problem or a misunderstanding, it means either you are too low technically or that they are stupid. Go back training or find another company, because you will never learn or work efficiently there.
2) If the project has really to be launched in two weeks, a honest product manager will recognize that there are sacrifices to me made, only a junior fanciful guy would still want everything to be finished (in that case, go see the one he reports to). Most important, communicate and never take this kind of decision yourself; this guy has done mistakes, he has to take the responsibility of it. But even better: help him. Present him some realistic alternatives.
Make a inventory of what is finished and what is not. Ask your project manager for the priorities and focus on the first priorities, forget the rest. Be honest and realistic of what you can do. If necessary, implement some "hacks" that will do the trick in a dirty way BUT presenting good interfaces to other layers/partners. For example, if your job is to fill a table with some values, have your table ready at least in its structure. If the values of some columns are the results of computations, present approximated results, even roughly. Negotiate two have two or four more weeks to finish the job after the launch date.
It is easier for a manager or a director to tell that the project is working in a 1.0 version but some features had to be delayed in a 1.1 version, rather than tell that everything is fucked up.
If you see that every project manager in the company is doing the same mistakes but they never want to hear about compromises, and the hierarchy blindly support them because "we have to catch up with the market/the customer", go away. They need technical slaves that will undergo a very high pressure but they don't need a high-level guy as your are. 🙂
March 29, 2008 at 7:57 pm
Exceptional DBAs are not just defined by what they know, but what they do. I guess we all know roughly how a good DBA would react if a server is under-performing, or goes down. But consider the following scenarios:
1. Your CFO wants to implement a new BI system that you believe will cost the company tens of thousands of dollars in wasted resources, and even then won't do what it needs to do.
2. An inexperienced Project Manager has caused several delays to a database project. Finally word comes down from the top that it must be completed in 2 weeks. No excuses.
So what do you think? How would an exceptional DBA react to circumstance such as these?
Well, Jeez-o-Pete! I thought we were talking about "Exceptional DBAs"!!! Consider the first sentence you have in the quote above…
"Exceptional DBAs are not just defined by what they know, but what they do."
Exceptional DBAs certainly are defined by what they do. Considering the scenarios you posted, I'd say that the DBA that lets such scenarios arise is NOT exceptional nor has s(he) done nearly enough. Truly exceptional DBAs don't have these scenarios arise because they're actively involved with the multiple heartbeats of whatever company they serve. Truly exceptional DBAs seek out meetings concerning subjects as those you've identified in the scenarios and will make sure they get an invite and make sure they attend. Truly exceptional DBAs are always looking for better ways to do things, especially with the CFO and CTO, and are constantly anticipating the needs of the Reporting and BI needs/requirements for the company. Truly exceptional DBAs come out of their little Ivory towers and talk with the "lay people" sitting in the cubes to find out what problems may be coming up. Any DBA that has these 2 (and other) scenarios arise is not doing all they can do. They are not exceptional DBAs.
Any DBA that doesn't get close enough to the CFO to understand the needs of the Finance department and it's ultimate leader is not exceptional. Any DBA that gives the CFO the opportunity to make their own data related software decisions simply hasn't done a good job. No matter which department it is, data drives that department and the DBA takes care of the data. The Exceptional DBA will have a true understanding of what is needed and will have already done the necessary research to make irrefutable recommendations to the CFO and have both the CFO and the CTO nod their heads in full agreement both separately and together. In fact, the truly exceptional DBA will have already identified all the needs, proposed the plan to the CTO, and maybe even have the CTO make the pitch to the CFO. The truly exceptional DBA would not be caught by such a surprise as that identified in Scenario 1.
Like I said… data drives the company. A truly exceptional DBA will have at least one hand on the reins of every database project. Project Managers, inexperienced or not, don't cause delays… lack of information and resources cause delays. Exceptional DBAs can and should take a huge amount of ownership on all data projects. They should be involved with the planning and design of such a project. They should act as a mentor to the developers helping them to achieve the best, highest quality code possible in the shortest time possible. An exceptional DBA will recognize inexperience on the part of a Project Manager and ensure that the Project Manager has all the information and awareness of all the required and available resources possible to do the best job possible. The DBA knows the project schedule as well as the Project Manager. If the Project Manager fails, the DBA has failed.
How will a DBA find the bandwidth to take on such ownerships and responsibilities? An Exceptional DBA will already have the Server Tuned to the max. 99% of all server related maintenance will be automated. Failures and performance problems will be emailed and sent to the DBA's phone and laptop. Security tasks such as adding/deleting/changing users and/or roles should be so well automated that it should only take minutes a day. All performance and other server related reports should be fully automated. The DBA should have 90% of all code reviews almost fully automated in an interactive fashion. I'm not saying a DBA should have nothing to do, but a DBA should have the time to do those things necessary to prevent being surprised by the likes of Scenario 1 and 2.
So, relating to the final sentence of the quote above…
"How would an exceptional DBA react to circumstance such as these?"
… the answer should be "They don't because a truly Exceptional DBA doesn't have to react to circumstances that don't occur. A truly Exceptional DBA would have anticipated these scenarios and properly handled them long before the became a 'circumstance'".
--Jeff Moden
Change is inevitable... Change for the better is not.
March 30, 2008 at 7:06 pm
It is a really interesting topic to discuss about what an exceptional DBA should be.
An exceptional DBA can be judged from many perspectives. But IMHO, to be an exceptional DBA, the first thing is to be out of any "office Politics", only when you are independent and with no self-interests involved, can you give an unbiased judgement/recommendatition to what you face and thus maintain your credibility.
Using Tony's first scenario as an example, if we assume the CFO is qualified for his/her role, I do not see how come the CFO not consulting with "this exceptional" DBA first. On the other hand, if the CFO already consults with "that exceptional DBA" instead of "this exceptional DBA", I guess "this exceptional DBA" needs to try thiinking harder in another person's shoes to understand why.
March 31, 2008 at 6:41 am
Oddly enough, I've come across scenarios similar to both of these cases. For the CFO and BI application, I had heard that our executives and the financial folks were looking for BI (they didn't phrase it like that) and were trying to put together a project to get prioritized. I managed to complete all the outstanding projects I had for the year a few months ahead of schedule and did a bit of investigation into what they might have wanted after discussing it with my manager. I did a cost-benefit analysis and built a prototype. I then booked a meeting with our president and CEO, as well as others in our head office and presented it to them. They said it was exactly what they were looking for and encouraged me to go forward with it.
For the second case with the inexperienced project manager, we had a project we recently wrapped up with a deadline that had moved up significantly a couple of times with a "do or die" type of deadline. However, I had known far in advance that the project was coming up and what would be involved. I made sure that I was put on the project early on by talking to my manager about it and was able to even sit in when they were listing the business requirements. I also asked someone else who would be invaluable if he could request to be put on the project as well. Since our project manager was inexperienced in project management (not that I'm experienced either) I tried to pick up the leadership slack to ensure that the work was progressing well. Sometimes this required "vigorous discussions" with business and technical managers. I worked with her to provide ideas and insight since a good chunk of the work was being done on the SQL Server and she was unfamiliar with it. I managed to learn about project management and she managed to build her skills and learn about the SQL Server so that next time things will run even more smoothly. Oh and this project had the most successful implementation I've ever seen.
March 31, 2008 at 6:46 am
See? Exceptional DBA... 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2008 at 7:01 am
Most answers I've read talk about technicals and such details which apply at a different stage from my point of view. Of course I understand that some might find my point of view irrelevant but up to now, working with compagnies as small as a few employes as for some with thenth of thousands employes (and for my own compagny, all at the same time) I would defined:
1- Go with the company politics / process
Most small company, I'm the one who commit the technology, implementation and so on, so most often, executives (often president) have a complete report on available technologies with positive and negative effect on each scenarios and all information is shared from the beginning. You are the source of information not other.
For big company (or when first part do not apply), I require a sign off on the subject, part of the process. (If they are ISO compliant, they are forced anyway to do that)
2- Build up your plan, gantt chart and so on. Also having a plan from an outside company (consultant for example) can help you. Submit it to the project manager telling him that it's the plan ressource needed to complete your part of the project. (That should already be done and submitted)
Let him do the talking, its his job after all not yours.
If you follow the politics and process I wouldn't really matter about anything. If you still get threatening, reprisal, why not find some other company that value human a bit more?
After all, in most projects, the human is much more important that anything else.
March 31, 2008 at 8:06 am
IMHO accountability, ownership and foresight are the keys to an exceptional DBA than technical effectiveness.
It might just be my small corner of the world but I'm finding it less and less common for someone to take personal responsibility when it is much simpler to push the issue off as being outside of their area of responsibility.
In the first example the DBA should be prepared to present his case in terms that management will understand. Simple stating that it is a waste of resources is not enough. It would be in the DBA's best interests to determine what exactly the need for a BI suite is and provide options to meet their needs. Take responsibility and ownership of the area you maintain. One way or another the DBA will be held accountable.
In the second example there has clearly been a project breakdown. The DBA should meet with the project manager as soon as possible (an exceptional dba would have done this in the first place) to define the minimum requirements, assign responsibility, and allot time and tasks to meet the timeline. Never place blame in a situation like this. Find solutions, use past experience and fresh knowledge to ensure that although the first release may not be perfect you are not creating extra work when the time comes to review.
Foresight comes into play before these issues even arise. An exceptional DBA needs to understand how the business operates on an interpersonal and business task level. While we're not always made privy to the "big picture" having an idea of what scenarios may arise and how to approach them can be the difference between a good DBA and an exceptional DBA.
just my two cents,
April 18, 2008 at 11:21 am
I'd like to thank everyone for their responses. Of course, there is no single "right answer" to either of the dilemmas posed, but I think everyone touched on the essence of the responses that Brad suggests:
#1. The CFO and the potentially disastrous BI system.
You quietly and thoroughly investigate the product and produce a paper on the problems with the application and why it won't fit well within the organization. You ask your boss to pass it to the CFO, without asking for any credit because you realize that if the advice comes from your boss, then it will carry more weight with the misinformed CFO.
#2. The delayed project and the inexperienced Project Manager.
You immediately take responsibility for the delay. You don't care whose "fault" it was, you are the DBA on the project, so you take responsibility for it. You immediately call a meeting of all those involved and outline exactly how you will lead the team to a successful completion of the project.
It's interesting that no-one touched on the idea that, occasionally, a DBA might do work "behind the scenes" for which they don't take credit. Has anyone ever done this?
I was particularly intrigued by the responses of Jeff Moden and Ian Massi, who suggest that exceptional DBAs probably wouldn't find themselves in this situation in the first place! While, of course, this isn't always possible (especially if, for example, you just joined the company), I do strongly support their arguments. The exceptional DBA is a core part of the business and the CFO fully understands their fundamental role in any data project, and so would consult them right up front. The exceptional DBA is rarely caught up in "do or die" deadlines because they know that projects are coming way in advance, and prepare for them.
I like these ideas. I guess, to sum it up: the exceptional DBA does not wait to be asked.
It was a difficult choice, but the winner of the $50 Amazon voucher is Ian Massi.
Cheers,
Tony.
April 18, 2008 at 12:04 pm
Contratulations to Ian, and thanks to Tony for distilling the responses down to just a few sentences.
Corporate culture does play a part in what an "exceptional DBA" can do. Inviting ones self to meetings works right up to the point that you get "dis-invited" by upper management who doesn't understand your value. I suspect the exceptional DBA does not work long in such a place, but finds a new company that values their skills and knowledge.
As for being behind the scenes and "not taking credit", is there any other way to work? 😎
Seriously, an exceptional DBA (or developer or manager) is much more interested in getting a project done so that everyone succeeds, than they are in tooting their own horn. Perhaps no one mentioned it because it's just an assumption about the way we work? Sure, we might grump a bit after the fact if we're not appreciated, but while the work is going on there is only one reasonable focus (IMHO) - making the project a success!
Steph Brown
April 18, 2008 at 12:44 pm
I am quite grateful to have won this, especially since I rarely win anything. It's nice to know that there are like-minded people who deal with the same types of challenges as I do.
April 18, 2008 at 4:56 pm
Very nicely done, Ian! Congratulations!
--Jeff Moden
Change is inevitable... Change for the better is not.
April 18, 2008 at 7:27 pm
Tony Davis (4/18/2008)
Cheers,Tony.
Let me get this straight: to paraphrase this using terms Jeff can associate with, the exceptional DBA lives by the following motto:
"Best defense - no be there"
......
😀
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 18, 2008 at 7:29 pm
Ian Massi (4/18/2008)
I am quite grateful to have won this, especially since I rarely win anything. It's nice to know that there are like-minded people who deal with the same types of challenges as I do.
Nicely done indeed Ian....It definitely can be a lonely little world we navigate in....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply