Skip to main content

Kimberly Blessing

The Myth of the Queen Bee: Why Women (Sometimes) Don't Help Other Women - The Atlantic

For women with low levels of gender identification—who think their gender should be irrelevant at work and for whom connecting with other women is not important—being on the receiving end of gender bias forces the realization that others see them first and foremost as women. And because of negative stereotypes about women, like that they are less competent than men, individual women can be concerned that their career path may be stunted if they are primarily seen as just a woman and therefore not a good fit for leadership.

To get around these kinds of gendered barriers, these women try to set themselves apart from other women. They do this by pursuing an individual strategy of advancement that centers on distancing themselves from other women. One way they do this is through displaying Queen Bee behaviors such as describing themselves in more typically masculine terms and denigrating other women (“I’m not like other women. I’ve always prioritized my career”).

The point is, it’s not the case that women are inherently catty. Instead, Queen Bee behaviors are triggered in male dominated environments in which women are devalued.

Kimberly Blessing

Managing, Mentoring, and Hiring: Why is it so damn hard?

4 min read

Think sticker

The super-cool Think Brownstone stickers I gave away at BarCamp!

I had the privilege of leading a problem solving discussion at BarCamp Philly this past Saturday. The session was proposed at the last moment (while the first sessions were going on) in response to a few conversations I had over morning coffee -- I was amazed to end up in a packed room full of very vocal people! It's clear our community has a lot to discuss on the topics of management, mentoring, and hiring. Thanks to everyone for participating and making this such an engaging session!

Here are photos of the blackboard notes/mind-map -- they're a bit blurry, but you still make out most of the text and the lines connecting ideas.

  1. Define the Problem "Screen Shots": 1, 2, 3, 4, 5
  2. Mentoring focus "Screen Shots": 1, 2, 3, 4, 5, 6

A transcription of all the blackboard notes follows -- but I think the big takeaway of the session were the mentoring action steps we identified:

  1. Define mentoring: what are you trying to achieve?
  2. Carve out the time: make it important, protect it, make it part of everyone's job
  3. Ask: not for mentoring but for information, for input, "how can I help?"
  4. Do things together and make it visible
  5. Express thanks

Before you go through the full notes: I'm serious about getting together again to continue the conversation! Please leave a comment on this blog post, email me, or @/DM me on Twitter so I can be sure you get an invite to the meetup!


Define the problem

    • No mentoring at many places
    • Hard to mentor if you're not being mentored
      • No managerial/organizational support
        • Do you set aside time for mentoring activities?
    • No one gives a shit when trying to mentor
    • Bidirectional mentoring: [other party] not always interested
    • Finding people / the right people
      • People with potential
      • Headhunters [=] Noise
      • [Many] unqualified candidates
      • Depends on company: hiring for culture, skills, experience?
        • Do we even know what we're hiring for?
          • Speedy growth
          • Same job title (not description) means different things at different companies
            • Different responsibilities, different expectations (on both sides)
          • As person being hired:
            • Why am I being hired?
            • What am I doing?
            • Is it OK to ask questions?
      • Dilution of credentials
        • PhD [in CS] but can't code
        • As jobseeker, educationally over-qualified, less job experience
          • Resume format hasn't changed, how do you present yourself?
            • Cover letter still important!
          • For developers, where is the code portfolio?
      • What is the qualification to get through?
        • Puzzles
        • Quizzes
        • Essays
      • Can someone meet our expectations?
        • [Example: job posting asking for] 10 years of jQuery experience
    • Hiring
      • Tools are shitty and inhibit process
        • Broad job posting not effective
      • Expensive! Job portal posting and lots of asshats apply
      • [Managing/researching applicants]
        • Resumator + LinkedIn
        • Stack Overflow
        • Ranking candidates
          • Bullet Analytics
      • Where to post jobs locally?
        • Technically Philly job board - will have job fair in 2014
        • Local network and community
          • Be an active participant in community so people want to work with/for you
          • Most groups are for senior/advanced people
          • How to go from email to action?
        • How to find junior talent?
          • Campus Philly
          • Drexel Co-Ops (people love them)
    • At this point, we were 15 minutes into our time, so we voted on one area to focus on; the group chose mentoring.

Focus on Mentoring

  • This is a skill in and of itself!
  • Big difference between mentoring and training
    • What is the hidden curriculum in your organization?
  • Finding time
    • Carve it out
  • Care more!
    • How to make those NOT in this room care more?
      • How do we encourage more soft mentors?
        • Make it a requirement
  • Coaching
    • Helping people express themselves makes them better at what they do
  • Apprenticeship
    • Formal programs
  • Context/structure
    • "Soft" mentoring instead of formal
      • Team collaboration and valuing others' opinions?
      • Recognition is important
      • How to find a mentor as a junior person?
        • Look for someone who is passionate about what they do
        • Look for someone who is open
        • Show them what you're working on
        • Ask
          • We aren't taught to ask good questions
            • Are we hiring people who won't ask by looking for purple squirrels (super ninja rockstars are self confident)
            • [Nor are we taught] to recognize others, e.g. acknowledge someone in code comments
          • Conversation starters:
            • What's wrong with this?
            • What am I missing?
            • What have you tried?
    • Some organizations separate mentoring from management
      • [Why?] This introduces BIAS in management process
  • Why is this a corporate expectation? Why don't kids go out and find [their] own mentors?
  • Manager != Leader, Leader != Manager
    • Being a mentor is a differentiator

Mentoring Action Steps

  1. Define mentoring: what are you trying to achieve?
  2. Carve out the time: make it important, protect it, make it part of everyone's job
  3. Ask: not for mentoring but for information, for input, "how can I help?"
  4. Do things together and make it visible
  5. Express thanks

Kimberly Blessing

Want to become an expert? Study (web) history

5 min read

Lately I've been spending a lot of time thinking and talking about the past.

I'm at the airport awaiting a flight that will take me to the Line-Mode Browser Hack Days at CERN. CERN, perhaps presently most famous for being the home of the Large Hadron Collider, is also the birthplace of the World Wide Web. More on that in a moment.

Screen shotMy first personal web site, circa 1997

Twenty years ago -- What the hell? Where did the time go? -- I started college. I arrived at Bryn Mawr College a French major, soon to switch to Romance Languages. My Italian professor assigned us reading on a Web page. I was one of the few people in my dorm to have a computer (and modem! and laser printer!). I had email before I got to college, on both AOL and Prodigy. Bryn Mawr had a gopher space, but no web site -- in fact, there were only about 500 web servers up and running at the end of 1993. And yet, that seemingly meaningless introduction changed my life. I took computer science classes. I changed my major to computer science. I started building web sites -- heck, I designed and built the first web page to be hosted at www.brynmawr.edu. For me, that was the start of it all.

And so here we are today. You, reading. Me awaiting my flight to Geneva. To CERN. Holy freaking crap! Understand that, for me, this is akin to visiting Mecca, except I am worshiping ideas, and code, and technology, and the propagation of all those things that has help fuel the evolution of our world into its presently hyper-connected state.

But I must admit that I was surprised, when telling some other web developers about my trip, that they didn't know about CERN's relevance to the web. The popular history of the Internet as an American creation dominates, and it has consumed the WWW creation story for some. So I educate and inform, to set things right, to help those whose careers are based on HTTP and HTML understand their domain's history.

Now, here's where I get preachy, because I run into scenarios like this -- where a web developer will make statements about web-related history that are completely wrong -- frequently. "Oh, IE doesn't support inline-block." Wrong, it has supported inline-block for a long time, but it couldn't just be assigned to any old element. (I've heard this one a lot lately -- perhaps because I'm interviewing and one of the coding problems I give can potentially be solved with inline-block.) "Old browsers don't support the HTML5 doctype," is another popular one. Misunderstanding the origin of CSS3 properties, incorrectly attributing computer accessibility to web accessibility, explaining IE compatibility mode based on one or two simple tests rather than reading the documentation -- even attesting to a lack of JSON support prior to 5 years ago (?!) -- are things I've encountered lately.

I admit that I am quite privileged to have, essentially, grown up with the web. I've been active with it, as a user and a developer, almost as long as it's been around. I do fondly remember using both Lynx and Mosaic to not just surf the web, but also test my own sites. I remember "playing around" with CSS to layer text, and trying to get it to work in both Netscape 4 and IE 3.

But I digress -- this isn't about me. This is about getting other web professionals to better understand our field. To be correct in what they say about the past, when trying to educate others. To not make false statements, based on lack of knowledge or direct experience, which lead to wrong assumptions and misinformed decisions about code and architectures.

I realize I sound like a crotchety old geek, complaining about the young whippersnappers who don't respect their elders. This isn't the case at all. I've had the pleasure of working with many younger people, or just less-experienced people, who have taken the time to learn about the web's history. (Admittedly, some of those people were required to, when they took my course on web app development.) And just knowing facts about history doesn't do much good, without analysis or thought of impact, for today or beyond.

Genuine curiosity and a desire to learn all that one can is ultimately what makes an expert. And, truth be told, any real "expert" will be the first to admit that they're hardly such -- they're still on the quest to become experts, themselves.

So, here I am, about to board my plane, hoping to enrich both my understanding of web history, and yours. Assuming I haven't entirely turned you off, I hope you'll follow my travels on Twitter.

Required Reading

Kimberly Blessing

Empathy is for Every One

3 min read

Title borrowed/tweaked from this Pastry Box post... with thanks to Viviana for the reminder.

I screwed up this week. I didn't mean to, of course. I did something, made a decision, for good and right reasons. I just did an incredibly poor job of communicating that something to others. Normally, that's not a really big deal, but in this case, it was. And so my screw up ended up occupying too many people's minds and time for too much of the week.

The first word in the name of this blog is People. I've realized that, throughout my career, when People didn't come first, things go wrong. And you can't just say that you're putting People first, you have to actually do it. To me, putting People first means having empathy for each individual, and considering their needs. Empathy is a crucial part of respect and trust, in my opinion.

I am best at putting People first when it comes to my team. Wherever I've worked, I have found empathy for those who reported to me, and I think/hope it has made me a good manager and leader. It hasn't always been easy, although it usually is. This week, my empathy for my team was running very high.

When it comes to the other end of the organization -- my peers and those higher in the leadership chain -- I realize that I sometimes forget about having empathy for the individual. Sometimes I get caught up in referring to "the management team" when all I see is bureaucracy. I have to stop and remind myself to see the People instead.

While empathy on my part can go a long way, it's ultimately a two-way street. I think we complain about working for our bosses, The Man, or Corporate America because those roles and organizations don't exhibit much or any empathy towards us. Too often, they demand respect due to their authority -- they intimidate and instill fear rather than communicate to understand and build trust. This, my friends, is debilitating.

Ultimately, I wasn't in a debilitating situation this week. I felt empathy for a member of my team, and I acted in that person's best interests. But I wasn't feeling any empathy for those I needed to inform about my actions, and I botched the communication. I'm shifting perspective and making amends, and writing this blog post to remind myself, because I know it will happen again.

Time to write "Empathy is for Every One" on a sticky note and put it on my monitor. Or, maybe have it tattooed on my hand.

Kimberly Blessing

Blog, Interrupted

3 min read

I started this blog in January of 2010, with the intention of re-contextualizing myself as an authority on career development for web development professionals. My goal was to post weekly about topics that would be relevant for early and mid-career web developers, or for new managers. The first month went decently, I thought: I had a long list of topics I wanted to address, I had a set time for writing (on my train commute), and I got great traffic and decent responses to what I published.

Then things got busy at work, and weekly posts turned into monthly ones. As issues and frustrations crept up at work, more time went by without posting. Without regular practice, constructing coherent opinions was time consuming and, due to what was going on in my day job, I found myself injecting too much cynicism and negativity in to my posts. Still, many readers and colleagues encouraged me to keep at it, and occasionally a post appeared.

Then, in February of 2011, my life changed when a family member became ill and I took on primary care-taking duties. Most of my time was taken up by phone calls to various state and government agencies, doctor's visits, shopping trips, extra laundry... and what wasn't taken up with care-taking work was spent trying to chill out. Now, almost exactly two years later, with that family member happily situated in the proper care facility, I have time to myself again. With this time, I'm starting to understand how much I've changed, and how much this experience has taught me about myself as a person, but also as a leader, a team member, a technologist, an advocate, an educator, a student -- the list goes on and on. I am still me, but my brain has been rewired. And, I think, it's for the better.

As for the blog, I do intend to continue with it. I still have a long list of topics to write about, and I need the writing practice! But change is constant and time is in limited supply, so I know that the posts won't be produced quickly. I can't promise that I will respond to every question I've received in the past few years, although I'd like to, since they were all wonderful and important questions I hear many people asking. I do hope that whatever I do write here will impart some knowledge that you, dear reader, find useful or interesting. Thanks for sticking it out with me.

Kimberly Blessing

Web Developer Job Search: Your Resume

6 min read

I estimate that I have spent a full work-week, over the course of my career, reviewing web developer resumes. That's enough time to produce some strong opinions on the topic. Allow me to finally continue the Job Search thread by sharing my advice for creating a top-notch web developer resume.

Resume Format and Structure

Your resume format should work to highlight your strengths. The chronological resume, perhaps the most traditional format, fails in this regard. A functional resume does a much better job of highlighting your experience in a specific role, but most web developers are good at more than one thing. I suggest mixing aspects of the two formats, organizing them in a way that makes sense for you and your strengths -- then you'll have a resume that stands out.

Here are the general sections found in a great web developer resume. With the exception of the first two, the rest can be ordered and/or further broken out according to your needs.

  • Objective: If you're searching for a job, you ought to know what you're seeking! Customize your objective, as needed, when replying to job postings. (Note: If you're not actively seeking a job, but still want to have a resume posted online, it's okay to omit this section.)
  • Summary of Qualifications: It's a cheesy headline, perhaps, and all too often the summary is filled with buzzwords -- but I have read really compelling summaries that made me want to know more about a candidate. Focus on describing your strengths and what you contribute to an organization.
  • Skills: This is where the keywords and buzzwords will start showing up. That's okay: you'll back them up with evidence in the other sections. You can subdivide this section in any number of ways: Technical vs. Soft Skills, Front-End vs. Back-End Skills, Design vs. Development Skills, etc.
  • Professional Accomplishments: Here you can include project accomplishments, awards, public speaking engagements, publishing credits, or descriptions of really awesome things you've accomplished. Like the Skills section, you can also break these out separately.
  • Work Experience: If you've done any combination of full-time work, freelancing, and volunteering, this is the most generic title you can use for your work history. Some people like to break out their professional experience from other work, but I think that can undermine the importance of having taken on freelance or volunteer work. If you list accomplishments for each job in this section, don't repeat them elsewhere, and vice versa.
  • Education: I don't like to see this section missing from a resume. Haven't gone to college? That's okay. Be proud of what schooling you have made it through and list it here. Oh, and that includes training programs, conferences -- anything you've forked out money for that you've learned something from!

Required Information

If your resume were to consist of only two things, it should be these:

  • Contact Information: You'd think this would be a no-brainer, but I have seen resumes where developers didn't list a phone number, email address, or personal web site (more on that below). In my opinion, it's a waste of space to display your full home address, especially if you are looking to relocate. No one's going to snail-mail you an invitation to interview, so city and state will suffice. HR will collect the rest of your contact information later.
  • URLs: I wish I could tell you exactly how many of those ~500 resumes didn't include a single URL... but my gut says that at least half didn't feature even a personal web site URL. Seriously? If you're a web developer, you should have some URLs to share. If you're brand-new to the field, put some of your school projects online. If you've only ever done intranet-type work, get permission to copy parts of the code and make it available, or create other projects of your own to demonstrate your skills. If you're serious about getting a web development job, you need this.

On the flip side, don't waste space on these bits of information: references (or the phrase, "References available upon request"), GPA, salary requirements, or personal information (except if you have hobbies that would be of interest to another geek and would increase the likelihood of getting invited in for an interview).

Frequently Asked Questions

Does my resume have to fit on to one or two pages? No, I don't think that it does. However, I think it's nice if a resume is so well edited and structured that, when printed, it fits to exactly one or two pages (one page if you're young, recently out of school, or switching careers; otherwise two pages). However, if you truly have so much awesomeness to report, then, by all means, go on! If you're really that super-duper, I'm sure I'll want to know all about it.

Does one resume fit all jobs? NO! Don't be afraid to tweak your resume format or content to the job you're applying for. In fact, if you have diverse enough skills and interests (design vs. development) you should probably have completely separate resumes for these purposes.

I am graduating soon and don't have much web development experience. What can I do to beef-up my resume? Use the "Objective" area to make it clear that you're looking for an entry-level position. Highlight your strengths in the "Summary of Qualifications" area and place the "Education" section next, so it's clear you're just coming out of school. List your technical skills, as well as any soft skills that you can support with extra-curricular or volunteer work. If you have been active in a tech community or have attended technical or web conferences, list those.

I'm switching careers. I've taken some web design and development courses and done some small projects. How do I reflect all of this in my resume? First, don't hide the fact that you're switching careers! Your prior experience, even if in a completely different industry, has (hopefully) taught you how to deal with people and has helped you understand your strengths. Start your resume with an "Objective" statement that spells out your desire to move into web development. Then list your skills, training and experience with the web so far before providing your employment history and other educational details. Highlight any experience that translates across industries, but otherwise keep the non-web details short.


I hope the above helps you create an awesome resume. Remember, your resume (supported with at least one awesome URL) helps get you in the door for an interview, so take some time to craft one that truly reflects you!

If you have questions I haven't addressed above, I'm happy to accept them in the comments below.

Kimberly Blessing

Working On Weaknesses

4 min read

Say NO to kryptonite t-shirt Even Superman has a weakness. (One of mine is wanting to own lots of cool t-shirts, like this one.)

In my last post, Understand and Leverage Your Strengths, I wrote about focusing on your strengths to make yourself (and your team) happier and more successful.

But a former direct report of mine wrote to remind me that, even when one understands and leverages his or her strengths, it's still possible to have a weakness or skill deficit that makes true success difficult to attain. What does one do in this type of situation? If this is something that's weighing greatly on you, here's my advice.

First, get specific about the weakness. Don't just summarize it as, for example, "I'm not a good communicator." What is it that you're not good at or comfortable with? Is it that your written communications lack structure or suffer due to poor spelling and grammar? Are you terrified of speaking before a crowd and thus get tongue-tied whenever you must do so? You want have a focused statement that spells out what you're addressing; for a bit of positive reinforcement, you might even specify what related skill you have that you're good at. Using the earlier example, you might be able to make the following statement: "While I am able to clearly summarize and deliver my thoughts verbally to one person or a few people in a regular team meeting, I get very nervous about speaking before larger groups or people I don't know well, to the point where my delivery of prepared statements can be very awkward."

Next, determine how much you need to grow to be successful -- and this means getting specific about what success means to you. Let's say that you're a web designer and you want to start doing some consulting work where you deliver design and front-end code for clients. You are already a decent HTML and CSS coder, so you have that covered, but you don't know any JavaScript and anticipate having to write some every so often. Rather than give up on your consulting business idea because you think it will be too hard to learn JavaScript, you may want to think about finding someone you could outsource that work to. Or you can work with some developer friends to create a small suite of scripts that you rely on. Or maybe you really should buckle down and try to learn JavaScript before you assume that you can't!

Once you've figured out the above you can create a development plan. Take out a sheet of paper. On the left, write down where you are today; on the right, write down where you want to be. Then identify the steps you need to take to get from one to the other and write those out in between. Assign some dates to each step, et voilà, you've got yourself a plan!

Does that sound too easy? It might, especially if the idea of addressing this weakness fills you with dread or fear. To that end, I strongly suggest that you seek feedback throughout this entire process. You may be surprised to learn that others don't view your weakness the same way you do -- this can be a really great perspective to consider. By talking about your weakness, you may come to terms with it. Or, you may be able to identify someone who could mentor you as you work through your development plan.

So, what's your weakness? Leave a comment and you just might find someone who can help you as you help yourself!

Kimberly Blessing

Celebrating Ada Lovelace Day 2010

8 min read

My Ada Lovelace Day post is a two-parter: the first part, recognizing two women who inspired me in math and computing; the second, recognizing Milly Koss, an inspirational and accomplished female computer scientist.

Ada Lovelace Day is an international day of blogging to celebrate the achievements of women in technology and science. Learn more

Mrs. Smarkola, Miss Herrick, and the Dawn Patrol

Article about The Dawn Patrol From the Grace Park Mini News, an article about Dawn Patrol by yours truly, circa 1985.

I am so fortunate to have been raised in the 80s, during the emergence of the personal computer. My school, Grace Park Elementary, and my teachers were excited about the TRS-80s and Apple IIes in the classroom, and many kids had Commodore 64s at home. Our teachers saw us get excited about learning; we were having fun playing with new toys our parents never had.

Our librarian, Mrs. Smarkola, was one of my most favorite people at school. When I think of her, I always imagine her with a large book in hand, head down, adjusting her glasses, focused on her reading. But I also remember her running the classroom full of typewriters and computers which was across the hall from the library. She'd walk from computer to computer, typing commands, turning them on or off, inserting tapes or disks, making sure each computer had an instruction sheet or book for the next activity. Around the time of fourth grade, a few of those computers moved into the library itself, and the whole school used them to check out and return books -- under Mrs. Smarkola's watchful eye, of course.

My fourth grade teacher, Miss Herrick, was one of those teachers that all of the kids in school were afraid of. Kids talked about her being "hard" and "mean" -- but when I got in to her classroom, I was in heaven. You see, Miss Herrick loved math. I loved math. We were a perfect match! She frequently gave us math quizzes with long division problems, which I always aimed to complete first -- because the first to finish got to "play" on the computer we had in the classroom. I'd guess that I spent more time on that computer than anyone else, and I think I was also the classroom "computer aide," to help other students with it. (BTW, to this day, I love doing long division in my head when I'm bored.)

So many of us kids at Grace Park were interested in computers and learning, that our awesome principal, Dr. Joseph Fleischut, authorized a program called "Dawn Patrol" which was run by Mrs. Smarkola and Miss Herrick. For kids who signed up and got to school about 30 minutes before the opening bell, it was a time to use the computers, typewriters, and library. As you may have guessed, I signed up nearly every day. It may have been during Dawn Patrol that I programmed a TRS-80 CoCo 2 to play the harmony to "Yesterday" by The Beatles, so that it could accompany me as I played the melody on the flute. (When I got to perform at the district concert with the computer, it choked under the hot lights of the stage, sadly.) It also may have been there that I first attempted to program a Joshua-like AI from WarGames. I definitely spent time playing the Oregon Trail and Carmen Sandiego games there, as well as being questioned by Eliza. But what I remember with the greatest certainty (and the utmost thanks!) were the ways in which Mrs. Smarkola and Miss Herrick (and Dr. Fly, too) encouraged me, nurtured my passion for math, computers, reading, and learning, and always praised me for my accomplishments -- key factors which recent studies say are crucial to getting more women in to STEM.

Adele Mildred (Milly) Koss

Milly Koss and Me I was introduced to Milly Koss in September 2006 when a historical marker was placed at the site of the Eckert-Mauchly Computer Corporation.

Milly Koss "had a distinguished career of more than 47 years in all phases of computer technology, implementation and management, including applications design and development, software/hardware selection, database technologies and computer security." Her name is known to some -- but not enough, in my opinion.

Milly was raised in Philadelphia and attended the selective Philadelphia High School for Girls. She earned a scholarship to attend the University of Pennsylvania in 1946, at a time when schools were primarily giving spots to veterans. She graduated in 1950 with a degree in mathematics. In the early days of computing, women were seen as ideal computer programmers due to their "patience, persistence, and a capacity for detail." Of course, in order for a woman to get one of these jobs, she had to have a degree in math and not be married. Milly Koss qualified on the first point, but not on the second: she was engaged. The first company she interviewed with rejected her for this reason.

Fortunately, she was in the right place -- Philadelphia was home to the Eckert-Mauchly Computer Corporation and, from the way Milly describes it, I imagine it to be a workplace much like any modern internet company -- except that 40% of their programmers were women. Milly interviewed with Dr. John Mauchly, who she described as being very nice, flexible, and open. He gave her a wonderful, exciting, creative job -- working with the UNIVAC.

Milly worked with Grace Hopper and was responsible for developing Editing Generator, a problem-oriented language for computer-generated reports, in 1952. Milly was interested in what "computers could do for programmers... how it could help programmers program." She also worked on sort routines for years, which she calls "the quintessential program for machines." She reminds us that today we should be grateful for that early work in automated programming, interpreters, assemblers, and compilers.

By the way, much of this she did while working part-time and remotely! According to Milly, when informed about her pregnancy, Grace Hopper told her to "take it home" -- meaning, the work. Milly would go in to the office one or two days a week, otherwise working from her dining room table. In an interview with Kathy Kleiman (who is the driving force behind the ENIAC Programmers Project), Milly said:

"What’s funny about that period, I’m not sure who my boss was. This was such an unstructured environment… Once I had a child they let me continue to work the way I wanted to. I inferred from that I was of value to them. Nobody lets you work that way unless they are getting value. I got increases. I got paid fairly well. Eckert & Mauchly was pretty good that way… There were no models, they didn’t care how you worked. There were no preconceived notions as to the way you could contribute. You did not have to be in the office…. We did not have huge management teams. We did incredibly new and exciting things and nobody had a problem.”

Milly later went to work for Burroughs Corporation, Philco, and Control Data Corporation, and Raytheon. At Burroughs and Philco she continued her flexible work schedule and would send her work in by mail! At CDC, she worked with early graphics algorithms and interfaces including light pens. Then Milly moved to Harvard University, where says she finally started feeling the hierarchy and loss of flexibility. She spent 27 years at Harvard, in multiple roles. She applied data management expertise to applications for the school and led an R&D effort to develop one of the first data warehouses, the Information Utility. She served as Associate Director of the Office for Information Technology and as the Information Security Officer for the university.

Milly retired in 1994. In 1997, she received a Pioneer Award at the Grace Hopper Celebration of Women in Computing. In 2000, she received the Ada August Lovelace Award from the Association for Women in Computing. With her many years of contributions to the field, I'm sure she also inspired many people -- women and men alike.

Additional Resources

Kimberly Blessing

Epic Management Fails

6 min read

"who's able here to honestly say 'I have a great boss'?" two hands raised... 320 persons in the room... Via Daniel Glazman on Twitter

Although I always identify myself as a technologist, I've been managing people for a while and that is the primary focus of my full-time work. Managing people is an art, not a science. It's very hard work, and I didn't completely understand this before becoming a manager. Honestly, I don't think most people -- even managers -- understand how hard of a job this can be.

I think that I've become a pretty good manager -- with time and experience, with feedback and mentoring. There were times when I wasn't so great, though. In an attempt at radical honesty (hat tip to Erica O'Grady), here is a list of my epic management fails and what I've learned from them.

  • I tried to keep my hands in the code. Somewhere I once heard that coders who become managers and still try to write code only do so because they're arrogant and they end up sucking at both. While I don't agree 100% with that statement, I can agree that diverting focus from management responsibilities can have a negative impact on people and projects. As a manager I've gotten so deep into code that I've trampled on the responsibilities and goals of my direct reports. I've also made commitments to deliver production-ready code but then been so distracted by management responsibilities that I caused project deadlines to be missed. While attempting to code for production work isn't a good idea for managers, I think that coding for practice -- to keep one's skills in shape or to have experience with what the team is working on -- is definitely a good thing. A technical manager who can coach a team on both a personal and a technical level is a huge asset.
  • I didn't prepare for one-on-one meetings. One of the top priorities of a manager is meeting with direct reports on a regular basis to review expectations, set and track progress of goals, provide feedback, and coach for achievement. If you ignore this responsibility as a manager, you're not doing your job, period.* Over time, I've realized that some managers avoid these meetings because they're not prepared. I've certainly made the mistake of meeting with an individual without having an agenda, or without having deliverables ready. Ever had an awkward review with your boss? Chances are, it was awkward because they weren't prepared. I find that I have to practice difficult conversations before I walk in to a meeting, and I even like to rehearse giving feedback. When I'm nervous about a meeting, I know I'm not prepared. When I realize this, I'll try to reschedule the meeting or, worst case scenario, I'll admit to being unprepared and beg forgiveness.

    However, even if you conduct regular one-on-ones, you can do it very poorly. For example, I've had managers who've spent most of my one-on-one time talking to or emailing other people, just talking the entire time without listening, and even zoning out (staring at the ceiling, a piece of furniture). Other faux-pas include glaring at the person (or eye-rolling, laughing at inappropriate times), only giving negative feedback, never offering assistance, and never asking for feedback.

  • I wanted more (or less or something different) for someone. I'm an overachiever and I've always had a vision for what I could and should be doing in any job. I know that not everyone is this way, yet somehow this fact escaped me early in my management career. Some of my earliest supervisees were just doing a job, with no vision for themselves in the future, so I adopted a style of pushing my own vision for a person's career. I could pat myself on the back for the times in which this worked out, but there were times where this approach certainly backfired -- such as the strong generalist who I thought should specialize in an area they didn't care for, or the developer who I saw moving up the tech ladder when they wanted to move into management. Having a dialog not just about about an individual's current role and goals but also about their future is crucial. I like to do this at least twice a year, now, to ensure that my direct reports and I are on the same page.
  • I hired someone despite having concerns about their ability to do the job. This is a tough one to address in generalities, but I'll try. Any hiring decision should be backed up with evidence gathered through a rigorous interview process. Every new hire presents some level of risk, but you want to have primarily positive feelings about a hiring decision, not concerns. I have, on occasion, made hiring decisions based less on evidence and more on what I thought could be possible, given training, coaching, and mentoring. Sometimes it has worked out wonderfully. Other times it's been a painful experience for both the individual who was hired and for me. I do believe in giving people a chance, though, so I can't totally knock taking these risks. These days I try to be open about expectations prior to hiring and I reinforce those expectations once the individual walks in the door in regular one-on-ones. I don't usually out-and-out express my concerns, though -- this can kill a person's confidence! But if I must, I'll also express my support for the person and assume responsibility for making sure the right things are in place for the person to be successful.
  • I let my own issues get in the way of my responsibilities. Anyone who's followed me on Twitter for the past year has seen this one first hand. I started a new job last January and spent almost the entire year unhappy with my role, the work, and number of other things. I focused on the frustration, vented publicly, and let public response further fuel my discontent. All of this distraction consumed me; meanwhile my team languished. I began planning an exit strategy and engaged an awesome career coach who ended up reminding me of my strengths and reignited my passion for creating positive change. I set to work on creating a plan to address not only what was making me unhappy but also what I felt was missing from making our organization a powerhouse. I'm now executing on that plan and seeing small successes, which I hope to grow into larger successes this year.

Do you recognize any of these epic fails, either personally or in a manager you've worked with? Does your organization have a strong culture of coaching and mentoring managers to prevent against these and other fails? Share your story below for others to learn from. I'll share my epic wins later!

Kimberly Blessing

How To Get Your Conference or Training Request Approved

5 min read

I'm a strong believer in continual learning and keeping abreast of one's field, not only because I like learning so much, but also because I know that a lack of learning leads to stagnation, boredom, and poor quality work. Most of the developers I know are also passionate about learning, and so they, like me, are always seeking to learn and discuss and debate and code. Even though we primarily function in the online space, there's nothing like doing all of that learning and engaging face to face -- so we love to attend conferences and off-site training.

Web Forms Panel at SXSW by Ari Stiles

But conferences and training often mean travel and registration fees, and sometimes managers and executives can't see spending money on these things -- maybe they don't quite understand the importance of investing in their people, or maybe skill development doesn't seem necessary to support the business. In any case, it's up to you, the individual, to do some convincing. If you're in this situation, what can you?

Build a Strong Case

Research the event(s) you're interested in, gathering dates and locations, presenter bios, and comments from previous attendees. Craft a proposal which summarizes this research and presents a strong business case for you to attend. Will you learn skills relevant to an upcoming project? Will you build skills which could have made a recent project go more smoothly, and will also help in the future? Will you be exposed to industry or domain knowledge which will better serve your organization in some way? Link the event directly to your work. Summarize the costs, including registration, travel, and meals, and if you can, estimate the ROI.

Request Funding

I think this is the part that scares people -- asking for money. But let me share a true story: In the first few years of my career, I never asked my bosses for training or conference money. I went to the classes they offered to me, and otherwise I requested time off to attend conferences on my own dime. Then my boss discovered that I was doing this. While he was thrilled that I was taking the initiative, he was concerned. (Was I planning on leaving? Did I think that I wasn't worthy of the investment?) At that moment he made me realize that just because I get a paycheck from my employer doesn't mean that their obligation to me ends there. He made sure I got my vacation days comp'd and reimbursed the training expenses, and from then on, I went to my bosses (and in grad school, my department chair/dean) with my conference and training requests.

It's great if you happen to know how much budget your company/department/team has allocated for training, travel and events. But even if you don't, always start by asking for full funding of your training/conference registration and travel. If you're the only person going to the event, or if the event is somehow more associated with your role than someone else's, you probably have a stronger case for full funding. Be sure to ask early to ensure the maximum budget is available to you.

But what do you do if your request is denied?

Negotiate!

If you really want to attend that event, don't give up! There are a variety of ways to get there, if you're willing to work for it.

  • Try before you buy. If your organization is considering sending a group to an event or doing some on-site training, ask the boss to send you to assess the event or trainer before sending a whole team or bringing a trainer on-site. As a manager, I've made many a training and conference decision on the feedback of a few key individuals who were sent out to do reconnaissance. As a trainer, I've met many folks at conferences where we've discussed the needs of the organization and how I can help, which I think made it easier for the folks in charge to decide on hiring me later.
  • Strength in numbers. Contact the event organizers and find out how many people you'd need in order to get a group discount. Then rally a group of coworkers around the idea of attending, and convince the boss to send a group. Yes, more people makes it more expensive, but more people asking places greater emphasis on the need for someone to attend and bring the knowledge back to share.
  • Volunteer. If you're trying to go to a conference where volunteers are needed, you can usually get free admission if you volunteer. Or, if you have a large blog or Twitter following, ask the event organizers if they will give you credit for referring others to register for the event; that credit may cover part or all of your registration fee.
  • Ask for partial funding. If you can come up with part of the funding (like travel costs) then ask your boss to support you by paying the rest (like registration). Again, if you have a large following on your blog or Twitter, you may be able to solicit donations to help cover costs. In either case, share in the goodwill by promising to share what you learn afterwards.
  • Finally, if you must: send yourself. If you can afford to pay your own way, sell your boss on letting you go -- without having to use vacation time. At this point I'd say that you're going for your own personal development and you needn't commit to sharing what you learn when you return. However I'd also caution you to not be stingy -- if do share what you learn, you're making a better case to be funded in the future.

What other approaches have you used to get funding to attend conferences or training? Have you tried these techniques only to still be rejected? Please share in the comments so we can all learn.