Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.
In today’s economy, job hunting is difficult at best. Things are so bad that people unable to find employment after a year plus of searching have stopped looking. This behavior, in turn, skews the federal unemployment numbers. The employment situation gets even worse when we consider that employers don’t want to hire the unemployed. (Even 2 & 1/2 years later, if you want a job, you need to already have a job.) Finally, there’s the missing white collar syndrome. Job skills suffer when they are not practiced. So a blip on the resume doing a year in fast food (for instance), can completely torpedo one’s chances of getting back on the career track. I know of at least one SQL Server DBA who lost his job several years back, got into the service industry to pay the bills, and now can’t get back into DBA work. I’m betting it’s because of his lack of recent technology experience. SQL Server has changed several versions since he worked in the field.
Now I’m the first person to say “take what you can” to anyone who asks me for job advice. If that means working in fast food, do it. I would do it myself, have done it myself. Bills gotta be paid, after all. But I would also find a way to work for non-profits or volunteer with the IT department so I could at least put that on my resume to fill in the job gap. I am not a job diva (too good to be slinging hash, changing oil, or picking up trash), and I don’t indulge in “job hate.”
And then I saw a DBA job posting that torqued me off and contains all the hallmarks of a fake DBA job posting. Once upon a time I would have been desperate enough, and uneducated enough, to go for it. I’m hoping no one else is that desperate, but just in case let me warn you. This appears to be nothing more than job bait-n-switch. (If you have evidence to the contrary, please let me know and I will update this post.)
The company advertises through Salary.com (probably a few other places also) and offers a Database Administration job “No Experience Required.” As if this weren’t enough to set off my mental alarms, the job posting itself did. Here, have a peek (emphasis mine):
Database Administrator (No Experience Required) (FDEJ2387Z)
FindDataEntryJobs.com is staffing for Part-Time and Full-Time Database Administrators. We are searching for hard-working employees willing to work in an office-related environment. This is a great opportunity for individuals to gain experience and begin a job in the data entry field. No experience is necessary to sign up for this position. Don’t wait! Sign up now!
•Assist with development
•Work closely with computer support
•Communicate problem and troubleshoot future problems
•Troubleshoot database issues
First, there is no database administration position that would ever have a job duties list that short or that generic. Database Administration is a very complex job that uses a variety of tools. No employer wants to waste time with a DBA who doesn’t know the technology (SQL Server, Oracle, DB2, Access), so they would at least mention what tools they use. And if they really are training their DBAs, they would at least mention what systems and tools they are training on.
Second, no employer with brains would trust their system to a database administrator WITH NO EXPERIENCE. Don’t get me wrong, it would be great if someone were willing to train DBAs up from the ground floor instead of making us all have some experience first. But that’s not the way the industry works. I had to train myself (and get certified) before being eligible for DBA job consideration. Letting a DBA loose on a production system without training? That’s a recipe for instant corporate suicide.
Lastly, the words “office-related environment” and the company name offer a huge clue as to what is really going on here. I’ve never seen a DBA job describe their environment as “office-related.” Usually I find that in administrative or business office job descriptions. And if we separate out the words in the company name we get “Find Data Entry Jobs.” News flash to these folks. Data Entry is NOT Database Administration. I have been a data entry clerk. I know the difference between the two.
Now I will often receive notification of open Administrative Assistant positions on my saved Database Administration job queries. This is understandable because “administration” and “administrative” do cross over. But posting a data entry position and claiming it is a database administration position (the more likely scenario behind the generic job duties description) is foul play. In my opinion this is either a phishing-type scam (intended to gather contact information from potential marks) or (more likely) it is an employment bait-n-switch intended to catch the desperate who don’t understand what data entry is.
This is my warning. If you are seeking entry in the high-paying world of database administration and come across any job posting similar to the above, ignore it. Run, do not walk, in the opposite direction. Because quite likely they are trying to get cheap labor to sit at a keyboard and enter information while pretending you are getting job experience for the position you really wanted and will never get (at least not with data entry job experience).
Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.
It’s early in the morning (or late at night) when Vital Process A fails. Maybe it errors out. Maybe it didn’t start in the first place. Regardless of the reason, there’s only one thing you can do. Fix it quickly. Fix it quietly. Fix it and whatever else you do, don’t tell the boss.
But… Why not tell the boss?
This morning I logged into work. I need to copy an old database backup to a “protected” drive so it wouldn’t get lost when the backup process cycled through tonight and trimmed the expired backups. As I navigated to where I needed to be, I noticed a missing folder. Annoyed by this, I refreshed Explorer a few times. Still no folder. This folder is created every month end as part of job stuff. So I checked the job and found that it never ran.
Vital Process A, which auto runs in the middle of the night, never ran.
Suddenly my sleepy morning of writing is interrupted as I go full tilt into DBA troubleshooting mode. I check a few more items, verify why the job didn’t run, send an email to my team, my boss, and my boss’s boss saying “I’m calling the vendor now, but, hey, this didn’t happen.” Then I call my boss on his cell phone because it’s New Year’s Day and he’s not checking his email. “Boss, I’m calling the vendor. I’ve got it handled, but there’s a thing.”
The boss is now in The Loop. He tells me to call him when I know more information. He heads into the office because Vital Process A is IMPORTANT while I get on the phone with the vendor and go about getting Vital Process A fixed remotely. Yes, I’m remoting in because I’m a good 30 minutes away from the office and driving there is wasting precious time that V.P.A. could be investigated or running. So I call the vendor, we have our conference and emergency data check, I kick off the V.P.A. and then I call first the coworker monitoring month end jobs, second the boss with the update.
As I write this, V.P.A. is running. I’m babysitting it in another screen. And it occurs to me that what I did this morning isn’t “natural.” IT people don’t call the boss when things go wrong. They just put their fingers to keyboard, keep their heads down, and fix the problem. Which is swell in most circumstances, and not so swell when it comes to Vital Processes.
“Don’t tell the boss.” It’s a survival mechanism, a mantra to keep us from getting ripped over stuff that isn’t our fault (and sometimes stuff that is). I’ve broken stuff before. We’ve all broken stuff before. If you haven’t, it’s because you’re not doing your job correctly, not because you’re a genius. Ask Bill Gates how much stuff he broke before he became a millionaire. Heck, ask him if he’s still breaking stuff. I bet he is.
The point is, “don’t tell the boss” is self-destructive behavior. Mistakes happen and the sooner we fess up to them, the lighter the fallout IF there is any fallout. Now, on minor processes, I fix the problem first (if I can) before I tell the boss. But this is a Vital Process. I don’t fix V.P.s first. I start the ball rolling, tell the boss, then continue with my work.
Why? Because if my boss gets called into his boss’s office to explain why V.P.A. failed and my boss doesn’t know that V.P.A. failed, then he can’t do damage control or give E.T.A.s or situational analysis. And if my boss doesn’t have an answer, then suddenly it isn’t just his boss wanting answers, it is a whole slew of managers, directors, vice presidents, etc. demanding to know what happened. And after my boss gets pulled through the wringer for being clueless, guess who gets called on the carpet and potentially fired?
I’ll give you three guesses and the first five don’t count (me,me,me,me,me,me).
So yes, I broke the code. I told the boss. And you know what? There was no yelling. There was no panic. There was just a “let me know what you need and keep me updated.” My boss is grateful for the heads up. He can start documenting what went wrong and now we have answers before we get any questions.
Plus, come review time, I can honestly tell my boss “Hey, I deserve a stellar review and a raise. Remember when I saved the day by resolving the Vital Process A problem?” The boss will remember I kept him in the loop and made him look good to his boss. And he will remember that I didn’t try to cover up major problems.
So the next time someone says “Shhh, don’t tell the boss,” think carefully. Because it might just be a situation where telling the boss is the first thing you should do.
Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.
Occasionally I make little notes, fun SQL facts, for myself about things I recently learned about SQL Server. Here are the most recent, mostly restore related.
A database cannot be restored to point in time by using two full backups right after one another (sad). -Side note: The differentials could not be used and the transaction log complained about being later in the LSN chain that I expected it to be.
Service accounts and application accounts tend to reconnect to the database after running Kill Users script if the DBA doesn’t act fast enough to switch the DB over to Single User (and take advantage of that switch) or Restore the database (etc)
The link between a Full backup and its Differentials is called a Differential Base, not a backup chain
A database restored WITH STANDBY cannot have Differential backups restored to it. Only Transaction Log Backups. (also sad. Why won’t SQL do what I want it to do on those rare instances where I need it to not do what it was programmed to do?)
A transaction log backup can be restored in the GUI via the Tasks->Restore->Database choice (if that’s the option clicked instead of the Transaction Log choice)
Backup files can be deleted in the middle of a restore (just happened to me yesterday when I was 80% done. GAH!)
Yeah. Those are my fun SQL facts of the week. Which ones do you have?
I haven’t posted a SQL Saturday post in a while because I’ve had a lot going on, not the least of which is working extra weekend hours. Also, Steve Jones over at SQLServerCentral.com wants me to write more articles for him, which I get paid for, and then post them over here only after the exclusion period runs out. Which sounds good on the surface, but then I get too caught up in things to write the articles for SSC and … well, both the blog and SSC fall to the wayside.
Which is a shame because, as I was so recently reminded, there aren’t enough women blogging or podcasting about technology.
One of my LJ friends posted this video, Where My Ladies At, from The Brain Scoop You!Tube channel. And to be sure Emily’s initial reaction to the question of sexism is much the same as mine. My workplace is an excellent environment where individuality and diversity isn’t just allowed, its encouraged. I don’t see active sexism. But once I got to thinking about it, I realized that female developers, DBAs, and help desk techs are few and far between. Don’t get me wrong, we have lots of female business analysts, QA testers, and project managers who are all very intelligent and skilled. But they don’t have their minds and hands in the guts of the machine.
When I first started this job, I was the only woman doing any kind of “hard core” technical work. It wasn’t until about four years into the job that a female developer was hired. She was incredibly talented, but then her husband got a job in California and they moved away. We haven’t had another female dev since. We had two women (at different times) who briefly worked for the reporting team, building Crystal Reports and doing some stored procedure design, but they were contractors who both left.
This year a woman got hired for our Help Desk, and again, she’s absolutely brilliant. Another woman, who has worked for Allstate nearly as long as I have, finally made the jump from customer service to technology. She’s third tier support for a vended application and has this year become the junior DBA of the team. She has a lot to learn still, but she is easy to train (and eager to learn). Then one of our testers made the leap to Business Intelligence and report design.
So now we have four women working the hard core technology programming / design / problem solving. Just four, including myself. And we’re all very good at what we do.
But some of the internal customers are afraid of me. Apparently the fact that I can say “no” to a request, or that I state my opinions, intimidates them. (I didn’t used to be Blunt Girl. Still trying to figure out when that happened.) When people ask me a question and I give them an answer they don’t like, they go to one of my male coworkers (or even my boss) seeking a different answer. Well, okay, that might be explained by the fact that until this year there were no other female DBAs. Yet there are the people who prefer to go to my boss, when he’s swamped, to ask about projects that I’m intimately familiar about. He has to come to me with these questions anyway, or call me into his office to talk with them, but they go to him looking for … what?
And this is not the first job I’ve worked where this has been a problem. Apparently my self-confidence throws people off, confuses them, and even puts them on the defensive. If I were male, would this reaction be different? It’s hard for me to tell, but I will tell you something else.
When one of the Help Desk men answers a question or solves a problem, he’s put in for the weekly employee recognition even though he’s just doing his normal job. When the sole woman on the help desk does the same, she’s just doing her normal job and nobody thinks to put her name up for that recognition. Why is that?
Don’t get me wrong. My workplace is awesome. The employees are treated well and listened to. The company does not tolerate harassment, sexism, etc. Yet there is this underlying current of the culture we were raised with, where women are agreeable, soft spoken, and have to work twice as hard before anyone notices they’re as competent as their male coworkers. To be fair, I’ve seen a lot of people struggling with the current culture shift. The rules are changing, which makes navigating these waters difficult at best, but there are days when I feel like they aren’t changing fast enough.
Which might be why there aren’t more women in technology.
So tell me your side of the story. Is there sexism in your workplace? How has it affected you and your office relationships?
So I’m basking the laurels of solving a performance issue, transforming a 2 day+ ETL process into a 15 minute process, when the next Big Thing comes down the pipes at work. I have to add five new columns to a feed that I created about five years back.
The feed itself was designed to use a newly implemented vendor system that we barely understood at the time. As our understanding of the system evolved, so did the feed. Two years and 46 scope changes later (all of which I worked on), we had working-yet-kludgy ETL process. It did what it needed to do, but wasn’t pretty.
Because the feed was based on scenarios instead of business rules, there are a lot of “if Skeeve is wearing yellow and it’s Thursday, then send this information, but only if the zeroes are negative and only if we didn’t forget the cheddar on the turkey sandwich. And if the sandwich is chicken, then send this other data, but only on Fridays” type of coding.
I eventually got around a lot of these scenario “rules” by creating data tables which drive the code instead of hard coding issues. But the feed is still a delicate and dicey thing that requires delicate handling whenever new changes are made. I know this. I’m the sole dev on this feed. No one else has ever touched it. So I should remember to check all the old stuff when I add something new.
My problem was that I got this last project update at the last minute (3 business days before it was due into Test). Yeah… Excuses, excuses. I powered through the weekend doing 60+ hours of work, and felt very pleased with myself for getting everything working perfectly by the test deadline. Except, well…
The day after testing started, the requirements changed. (I challenge any DBA or Dev to show me an environment where that doesn’t ever happen.) As I double-checked the changes, I found a small notation I’d missed. Whoops! So I head back to coding, fix the issue (which is fortunately minor), and get the changes sent to Test. Then today, the tester and BA come back to me and say, “Um, you missed this other thing.”
So I’m supposed to add five columns which send records based on scenario A and scenario C. But the problem is that half the new records that are supposed to send in scenario A ran into an old rule that says none of those records are to be sent in scenario A.
And now the pain truly begins as a new rule contradicts an older rule that I completely forgot about. #headdesk
It can be fixed. I will fix it. In the meantime, I will be banging my head against the desk and reminding myself that even for a veteran DBA, SQL is hard. Not so much the basic administration or basic coding, but the job itself. Just when I think I’ve got things handled, a curve ball comes up and smacks me upside the head.
And yet, that’s why I love being a DBA. Because despite the repetitive tasks, at the end of the day SQL is challenging, new, and different. There’s always something to learn and the complexity, while annoying at times, is fun.
Is SQL hard for you? Or am I alone in this opinion?
Today I want to talk about my job, the day job. As a Jack-of-All-Trades DBA, I am responsible for backups, security, production releases, data fixes, architecture, schema approvals, development (both T-SQL and BI), mentoring & training new employees, job maintenance, etc. Everything you can think of as a SQL Server DBA job is the responsibility of our very small DBA team. So I like to take shortcuts. Sometimes that’s a good thing, such as automating tasks to free me up to do other things.
Then there’s the bad.
Shorcuts are the easiest way kissing one’s job goodbye (a.k.a. getting fired). Taking the wrong shortcut at the wrong time can be deadly to one’s career.
A few years back, I was in the middle of a monster project (two projects, actually, that were related to each other) that took 2 years to complete successfully and had 46 scope changes. It had more than 46, actually, but we didn’t allow them to make any more after that. We insisted they treat the other changes as new projects. For 2 years, I fought with a vended solution, creating reports off that solution, pulling the data as an XML file into our database, building tables and procs for the data, creating SSIS packages to massage and manipulate the data and send it off somewhere else (ETL), updating our EDS data flow and tables to include this new data, and fixing problems every time something with the process broke.
It is at the point where I know the tables, procs, and data so well that I was the one tasked with making all future changes. When I have to make a change, I touch no less than 6 stored procedures, 5 SSIS packages, 2 XML configuration files, 1 XSD file, and usually 3-7 tables (depending on the project changes). Every time I fiddle with these feeds, I have to make a list of everything I’m changing so I can pass the word to the release coordinator and make sure nothing gets forgotten in the move.
But it wasn’t always this organized. About a year into the project, I decided I was the Golden Child. I knew the data (vendor side and our side) so well, I didn’t need to think about silly things like formula consequences or JOIN code. I could just write it and it would all work.
Unit testing? Who needs that? The test team would find any errors if they existed (which I was certain they didn’t). Besides, the data was coming from a vended solution that didn’t have a development DB / interface I could use, and I couldn’t run the front end process to generate the report needed to load my data into SSIS without encroaching on the Test / QA environments and having to do a lot of data entry, so unit testing was not feasible for me. I’d use stale data from Production to make sure the code and packages would run and when they completed successfully, I knew things would work.
So when the testers came back to me with error after error, I would go through the stages of grief. Denial. It couldn’t be my code. It was a data issue. I’d seen that before (and sometimes I was even right about it). Blame. It was bad requirements. The business unit had no clue what they were talking about or what they wanted (well, that happened too, but not as frequently as I wanted. Mostly they interpreted certain terminology to mean something different from what I knew it to be).
Acceptance. I’d rewrite the code to fix the error, throw the fix into Test and saunter off to do Something Important with my time while the testers did their thing. But then they’d come back with another error, or sometimes the same error, and the cycle would start all over again. The more they came back to me, the more angry I’d get. Defensive even. This code is my baby, my gem, it’s perfect, DON’T THEY UNDERSTAND? It should work! (Hey, authors, does this sound familiar to you? It’s amazing how often my two jobs dovetail. @=)
I didn’t understand the process, see. I didn’t get why unit testing was so important. Truth be told, I wasn’t even trying to unit test beyond “does it run?” And it reflected in my performance review that year and in the way I interacted with my coworkers. My temper got the best of me at times and I’d tense up the moment I saw an email or phone call from one of the testers.
Then I got a clue. I needed to unit test. Since I couldn’t generate the report from a dev database, and since I didn’t want to take the time to mock setups and stuff in an interface (even if I could have had access to a dev DB), I’d create my own fake file. I grabbed an old production source report, copied about 10-20 lines from it (including header and footer), wrote up my scenarios based on the requirements, then altered columns and added new ones with the correct dummy data. Then I’d run it against my dev database to see if what came out the end was the expected data. It took me a few tries to be able to recreate the files this way. Once I figured out the formula, suddenly I was finding errors well before my code was inflicted upon the hapless (and very patient) test team. In my last release, the major of errors were data related with only one being my issue (and even that was expected given the vagueness of the requirements).
Bugs get into Production all the time, no matter where we work. This is a fact of life. But when they can be avoided, they should be. Unit testing is worth the effort because all the additional time put into it saves three or four times the effort fixing the bugs during the time-crunched QA process. Or, heaven forfend, fixing the problem after it has offended customers and lost business.
If a query is passed to a release with obvious issues (like an ORDER BY clause in a subquery), I can tell right away the coder didn’t even bother performing an initial execution pass. As I almost learned the hard way, careless coding is one significant method of kissing the job goodbye.
So what is your unit testing experience, nightmare, or concern?
You know you’ve made an impact when people start coming up to you asking where you’ve found your full time writing gigs.
It’s been an interesting roller coaster ride for me since 2004. From hearing an editor refer to me as a veteran writer in 2009 (when I felt like I’d barely published anything yet) to having a friend ask me for advice on creating games to having people ask me actual writing advice, the past five years have been the weirdest series of firsts for me. I don’t consider myself one of the Big Wig Writers. Yes, I’m a member of three professional writing organizations. Yes, I blog about writing. Yes, I try and pimp my brand when I can. But I haven’t yet noticed that I have a substantial fanbase.
So when did people start thinking I knew what I was talking about?
Not that I mind being considered the wise hermit on the hill. It would just be nice to know when the transition from “wanna be writer” to “oh, hey, people actually want my opinion” happened.
To be clear for those who don’t know much about me yet, I am not a full time writer. Never have been and might never be. Why? Well, because I value my financial security too much to take that leap. I like paid vacation days, health insurance subsidized by my employer, and a paycheck that means I can indulge in random road trips and my comic & novel habit (which is now an honest to goodness research investment as well as an addiction!). My day job (SQL Server database administrator) lets me play with computers all day, solve problems, and program. I work for a wonderful company at an excellent division with fantastic people (including my immediate management team). It’s a stable paycheck.
Writing is not a stable paycheck. I put more effort in my writing than I earn from it. My current work in progress (wip as it’s called) is an original fiction novelette. Today is Day 8 of writing and I’ve rewritten the opening scene just as many times. I haven’t gotten past 1000 words, though I’ve put a lot of work into my worldbuilding and the background of “current events.” If I’m lucky, the publisher this is targeted to will accept it and I’ll get paid pro rates for the story. But to be clear, pro rates will NOT cover even a fraction of the time I’ve already put into the story. If I’m lucky, the paycheck will give me just enough money to buy lunch off the dollar menu for a week.
So if I’m not a bestselling author, why do I field questions from people who are asking for advice?
Most of my experience not only comes from doing but from asking. I have had a fantastic series of mentors both on the SQL Server side and on the writing side who had no problem sitting down with me and sharing their wisdom. So I teach and blog and answer questions whenever I can because I strongly believe in the concept of paying it forward. I do what I can to pass on the things I have learned to those who are truly interested.
A person doesn’t have to be a big wig to have valuable knowledge. DBA work and writing work is NOT a competition. I will not treat them like one. If people want to learn and contribute to the industries, more power to them. Do you have a question? Then ask. There is no such thing as a stupid question except the question that wasn’t asked.
All I ask in return is that when people are turning to you for answers that you pay it forward too.
To me, my SQL Saturdays posts aren’t just a method of information sharing or a way to teach new SQL Server database administrators. I also use it as a repository for my own purposes, recording bits of code or self-taught database lessons I want to remember for future work. Today’s post is T-SQL that I use for searching object definitions. I don’t use it nearly often enough for my fingertips to remember how to type from scratch each time, but I use it just often enough that I need to have it archived. And if it helps out anyone who reads this blog, then that’s just gravy, right?
There are three different queries I use. One for searching the text of views, one for searching the text of functions and stored procedures, and one for searching the text of job steps. They are listed in that order. Of course, the word MySearchTerm needs to be replaced with whatever phrasing the DBA is looking for.
SELECT v.Name, m.Definition
FROM sys.views v
INNER JOIN sys.sql_modules m
ON v.Object_ID = m.Object_ID
WHERE m.Definition LIKE ‘%MySeachTerm%’
ORDER BY v.Name;
–Search view definitions
SELECT so.Name, so.type, so.schema_id, su.Name, sm.definition
FROM sys.objects so
INNER JOIN sysusers su
ON so.schema_id = su.UID
INNER JOIN sys.sql_modules sm
ON so.Object_ID = sm.Object_ID
WHERE sm.definition LIKE ‘%MySearchTerm%’
–AND so.schema_id <> 1 /*schema_id looks for non-dbo schema objects*/
ORDER BY so.type, so.Name
–Search functions and stored procedures
SELECT sj.name, sjs.*
FROM sysjobsteps sjs
INNER JOIN sysjobs sj
ON sjs.job_id = sj.job_id
WHERE command LIKE ‘%MySeachTerm%’;
–Search job steps
Does this solve a particular need you might have? Are there other day-to-day queries you’d like to see me talk about in SQL Saturdays?
Let me know.
Today’s SQL Saturdays post discusses a cute little trend we have going on SQLServerCentral.com, SQL Spackle articles.
SQL Spackle articles are short and simple articles meant to spackle, or patch, existing knowledge gaps. While Microsoft’s Books Online covers a lot of information, it also leaves out information that DBAs and Developers have to discover on their own. Plenty of articles have been written by very knowledgeable people on the big stuff such as backups, restores, major code How-Tos. But several members of the SSC community noticed that the small stuff, which is needed just as badly, is rarely covered.
Hence the birth of the SQL Spackle article. At the head of each little article is the following disclaimer:
“SQL Spackle” is a collection of short articles written based on multiple requests for similar code. These short articles are NOT meant to be complete solutions. Rather, they are meant to “fill in the cracks”.
SQL Spackle fulfills a need rarely recognized by the technical community, those useful little code bits that everyone can share, use, and save in their own personal libraries to port from job to job. The intent is to reach everyone regardless of their experience and knowledge level. It seems to be working out fairly well, too.
So if you or someone you know is hitting a wall or looking for that little bit of extra info not included in the usual sources, check out SSC’s SQL Spackle library. There’s some interesting stuff, including one article of mine that just got published two days ago, Schema-Owned Tables and Generated DROP Scripts. (Because I keep running into this problem myself, and remembering the solution is easier for me if I actually write about and share it.)
Do you have ideas for more SQL Spackle articles? SSC pays for both these and regular SQL Server articles. Check out their Write For Us page. Join the fun and spackle a few holes in the process. You’ll be glad you did!
After fellow writer (and my VP mentor) Steven Gould retweeted my “Why the SFWA Debate Matters to Women in Technology” post, a male twit (aka twitter user) responded with the tweet asking what he gets out of it.
There are two ways that response can be taken. The first way is to be offended and assume he’s deliberately trolling or trying to pick a fight.” The second way is to taken the question seriously from an interested party. I am choosing to answer the question as if it were a serious inquiry.
Why should men care about the SFWA debate and women in technology? What do men get out of more women joining previously male-dominated fields, gaining positions of authority and trust? Quite a lot, based on my personal experiences.
1) Women are more likely than men to mentor the new recruits, regardless of the recruit’s gender. Most men, especially in technology, are so terrified of losing their jobs that they tend to horde knowledge and business history, believing they are immune to the eventual layoffs if they are the only person who knows how to do their job. Holding this information hostage tends to backfire more often than not.
2) Vital projects succeed more often and are completed more quickly with women on the team, even if the project was created by and is being driven by a male coworker. Why? Because women are more willing to build consensus and team build for the sake of the project rather than defending a piece of territorial turf that could sink (or mire in red tape) the project. Consensus and team work make for a smoother project path.
3) Women’s attention to details can save a project, or save the team a lot of work. Many men tend to overlook previously existing business rules, potential business scenarios that the business users forgot to mention, and regression testing. Women pay attention to details like this and are less likely to care about how foolish it is to ask the so-called obvious questions, bringing potential project problems into the light of day before the project gets too far along, looses too much time, or wastes too much money.
4) Women share the tribal knowledge. Again, where men assume other people may know a thing, or actively refuse to train and share the tribal knowledge in fear of losing their jobs, women know that the only way the team (and the business) can function properly is if everyone knows necessary and needed information. Whether that’s business history over a specific subject, training on specific procedures, or sharing information on customers and vendors and other teams, this information is vital to a healthy working environment. By sharing the tribal knowledge, women make it less likely a customer (et. al.) will get conflicting information about company policies or that team time will be wasted running around in circles while everyone tries to find the Right Answer.
5) When was the last time you saw Scott Adams have an incompetent FEMALE manager or CEO in Dilbert? I’ve never seen that character. There’s a reason for that. Incompetent female workers don’t tend to make it that high on the food chain where as there are plenty of self-sabotaging (and company sabotaging) male managers that have sunk corporate ships. While women are perfectly capable of embezzlement, theft, breach of trust, and other fiduciary crimes, we are statistically less likely to commit them because … well, we don’t like the consequences if we get caught.
6) Women are more likely to support our coworkers (regardless of gender), pitching in when help is needed and suggesting alternate solutions to problems, because women don’t just know the adage “United we stand, Divided we fall.” Women live it. It’s a required tenant of our every day lives, part of how we manage our family lives. We take the skills we learned in raising and being part of a family and bring it to the workplace. Quite effectively too.
Now granted, not all women fit this model. I’ve met micro-managing “I’m always right, you’re always wrong” type of women who don’t share and back-stab their coworkers. But they are rare in my experience. Rarer, at least, than their male counterparts.
So what do men get out of all this? Projects completed on time with a minimum of complaints, critical information to get their jobs done, training they may not receive elsewhere, and the ability to shine to upper management because when the team does well, it reflects well on everyone, including the men.
Agree? Disagree? What are your thoughts?