Skip to main content

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

On the Writing Process

4 min read

I am not a storyteller.

This was the thought I had the other day, after reading Neil Gaiman's tribute to Lou Reed. Those guys are storytellers.

I love listening to stories. Reading stories. I love the way they take me on a journey. I'm able to just sit back, take everything in, have the plot laid out for me, the characters developed, and the whole thing resolved, all for my enjoyment and entertainment.

A good storyteller is a magical thing.

I bring this up because storytelling is an incredibly effective way of communicating. Because I am not a storyteller, communicating is often very difficult for me.

I recently published a blog post that took me over six weeks to write. Now, I wasn't working on it continuously for six weeks of course -- but I did have all of the important information I wanted to communicate identified six weeks ago. Structuring it so that it made sense is what took so darn long. And, by the time I published it yesterday, most people had moved on from thinking about that topic, and so it went over like a dud.

That's okay, I tell myself. I'm only writing for me: to practice writing, to capture my own thoughts. And then I call bullshit on myself, because I'm reloading the stats window and watching to see who retweets the link.

Once upon a time, writing wasn't hard for me. I just sat down and wrote and wrote and wrote. Creative writing, they called it -- and through 6th grade, it was among my top favorite things in school (probably after math and computer time and reading). Come junior high, I had to discipline myself and structure my thoughts to write five paragraph essays.

Ugh, five paragraph essays: an introduction, three supporting points each in their own paragraph, and a conclusion. I really sucked at those, and I have the bad grades to prove it.

Mr. Weaver, my history teacher, and my grandmother both spent a lot of time with me to help improve my structured writing approach. No longer could I just sit down and write, because the editing process made such a mess of my work that I couldn't look at it any longer. And so I began writing out individual sentences or thoughts on index cards, and sorting those into groups and then writing connector or transition statements on new cards and adding them to the mix. And, in the end, all I had to do was copy my index cards to paper and submit. Done. A+. I still have the first paper I ever wrote this way (on Henry Clay) -- and the supporting index cards! -- to show me that this approach works.

And this approach works for a lot of things. It's great for making slide decks, which I do a lot of in my work -- and with all of the practice I have, I do it rather quickly. I also wonder if this approach to writing didn't influence the way in which I code, since I really love the modular approach.

But when it comes to writing -- well, it's hardly writing, is it? I mean, it is, but it seems rote. Perfunctory. Emotionless. And so this is why I struggle to write now -- because I write from an emotional place. But my emotional place doesn't do well with logic and often communicates its point by feeding information between the lines, and so only the most careful of readers will get the point.

Storytelling is all about emotion -- great storytelling makes you feel something. Most of my writing falls flat from lack of emotion. But at least it gets the point across...?

So, what to do? Write and ramble and never quite get my point across? Or structure my thoughts, compose the thesis, defend it, all stocky and blocky and templatized and boring? How does one combine the two approaches?


PS: I wrote this in one sitting, and mostly in one shot straight through. The end is where I got hung up the most -- when I was trying to figure out what my point was. The opening and a few of the statements I wrote in my head, in the shower yesterday.

Kimberly Blessing

Why I'm starting a new blog

2 min read

Welcome, and thanks for checking out my new blog!

My old blog, Obi-Wan Kimberly Is Your Only Hope, is still online and won't be going away. The content is all still relevant although the code needs major updating. It's still on my to-do list and it will happen, eventually.

I've been saying for a while that I need to get in the habit of writing more often. I love reading blogs by tech folks that write every day, even when they don't write about technical topics -- Tim Bray writes one of my favorites. If I can make time to read every day, I can make time to write everyday. I know how to form new habits, duh.

I'm starting fresh to free myself of constraints. I'm using a default WordPress theme in order to stop myself from making excuses about design tweaks or code changes. Even though I'm calling the site "People, Process, Technology", I'm going to allow myself to write about whatever's on my mind. (I'll explain why it's called "People, Process, Technology" soon, though!) In short, this site is a blank notebook for me. You're welcome to read through it, at your leisure.

Thanks again for stopping by and I hope to see you again soon.

Kimberly Blessing

Life Lessons from the Labyrinth

2 min read

I came upon a labyrinth in the woods.

I considered the labyrinth, and its goal at the center.

There are two ways to the goal:
- follow the path, trust it will get you there, or
- skip the intended process and jump to the center

Wondering what I would get out of trusting the process, I followed the path.

I worried that I was traveling in circles, when I observed an obstacle in my path. I had to duck to avoid hitting tree branches. I kept moving.

I saw myself moving towards the goal, and I was pleased. At one point, I was close enough to touch it, but I did not. I was traveling in a circle but felt momentum pulling me in. I knew I would get there.

Then I took a drastic turn and moved to the outside of the labyrinth. I was far from my goal, and I questioned why the path had diverted me. I was so focused on my anger over being as far from the goal as I was at the start that I neglected to see the tree branches ahead. But I had encountered this obstacle before, and I remembered to duck. But this time I had to be more flexible -- there were more branches than before, so I had to bend further and for longer. I could have stopped, abandoned the path. But I kept moving.

Upon exiting the tree branch obstacle, I found myself moving closer to the goal again. I felt a sense of calm -- not excitement. I was glad I had been challenged by another obstacle on my path. My commitment to the goal had been tested, my faith in the path had been tested. I knew I would succeed.

I came closer to the goal. I did not think about jumping the path to the goal. I did not even fixate on the goal getting closer. Instead I found myself thinking back on the path that I had traveled, and what I had learned along the way.

And, before I realized it, I had reached the goal. I looked around at the path that had gotten me here, and thanked it. I thanked myself for not abandoning the path.

And then I exited the labyrinth, ready to face the day.

Written June 26, 2011 at Bryn Mawr College

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

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

Web Developer Job Interview Questions

1 min read

Every employer has a different recruiting and interviewing process, but at some point you're going to be asked technical questions. (Or, at least, one would hope that you'd be asked technical questions... if not, look out.)

If you've never interviewed for a web development job before, or if it's been a while, you might be wondering what to expect. Rather than list a whole slew of questions here, I'm going to give you access to a real screening questionnaire -- one that I've actually used as a hiring manager to help identify which applicants have a solid understanding of core web development knowledge. (Harder questions get asked over the phone, and the hardest ones in person.)

What are you waiting for? Check out the questions!

Interviewers and hiring managers, what other questions do you ask early-on in the recruiting process?

Kimberly Blessing

Preparing for Your Web Developer Job Search

6 min read

It's a new year, and perhaps you're a Web Developer looking for a new job. As a long-time Web Developer, here are three things I prepare when looking for work, whether it be freelance or full-time. And as a hiring manager, these are the same three things I'm looking for from the candidates who apply for work!

A Resume

I don't care whether I get one page or three pages from Web Developer candidates -- as a hiring manager, I do review the whole thing. Just don't fill it with fluff. I'm looking for dates of employment, size of company/product/team, type of work performed, and skills utilized. The general stuff which you do on a regular basis (emailing with Outlook, writing documentation in Word, slicing of assets in Photoshop or Fireworks, etc.) can just occupy a general skills section rather than be repeated for each job. Starting the resume with a technical skills overview gives me a quick snapshot of what you say you're capable of, and is a likely place for a hiring manager or recruiter to start with questions -- so don't list technical skills which you can't back up with experience! (Saying you have experience with HTML 5 when you haven't done much more than read a few blog posts is a sure-fire way of getting your resume nuked in a company's recruiting database, thus removing you from future consideration.)

While a beautifully formatted resume is always nice, don't agonize over it: using a Word resume template is just fine. Keep in mind that your resume doesn't always get through to the hiring manager in the format you sent -- so prepare a plain text version for textarea uploads. I know that typos sometimes make it in to a resume, and the occasional one will be forgiven or overlooked -- but do make sure to spell and grammar check everything! After all, if you don't QA your resume, how will a hiring manager know if you QA your code? (Need help? Read this and this.)

A Portfolio

To me, your resume is a formality of the hiring process, just metadata. Your portfolio is the real content which will be reviewed with a far more critical eye. The fact that portfolios aren't requested 100% of the time when seeking Web Developer positions only speaks to a hiring process which still treats the Web Developer role like a traditional programming job. Web Developers know otherwise, and if you truly want to be seen as a professional Web Developer, you'll have a portfolio at the ready. Do not slap something together on an as-needed basis -- proactively prepare a portfolio and send it even without request!

A portfolio should highlight your best work -- not all of your work. Don't include every project you've ever worked on. Choose three to five of your code samples which exemplify things like your coding style, ability to reconcile project requirements versus technical constraints, attempt to put HTML 5 into practice, etc. No one project will demonstrate all of those things, obviously, so make it clear why each project is included -- give a short narrative for each project to point someone to what you want them to focus on. Remember, you won't be the room when the portfolio is reviewed (unless it's brought up during an interview, which the portfolio will help you to score), so hand-hold the reader a bit.

I'm going to write a more in-depth post about what should go in a portfolio and how hiring teams review portfolios, so stay tuned.

A Web Site

May I vent for a moment? I can't believe how many Web Developers apply for jobs and don't have a Web site of their own. Where, pray tell, do all of these folks do their testing and noodling with servers and code? Why would you not want some online repository of your code? OK, venting done.

Yes, I do realize why some Web Developers don't have Web sites, but when you're searching for a new job, you need to have one. No, you don't need to have a blog with a lot of profound blabbering about technology, but yes, you should have an online copy of your resume and portfolio. When a recruiter or hiring manager Googles you (oh yes, we do!), you should want something more than your Facebook page to come up in the results.

I really think the most important reason for having the Web site is to host your portfolio. With an online portfolio, you can still highlight a few key projects while hosting copies of all of your code. This way, at a moment's notice, you can direct someone to (or, in an interview, walk someone through) a code solution that exemplifies a point you're discussing. Plus, you can preserve your code as it was when you finished it (delivered it, launched it) -- no longer will you have to make statements like, "I made the templates for the CMS but someone else maintains them now, plus the content folks don't know XHTML, so I don't know if the pages still validate." Worried about keeping copies of your code online? Just password-protect your site. If you give each recruiter a unique username/password to access your site, you'll be able to check your server logs to determine who's actually checked it out.


How will having all three of these things prepared and submitted help you in your job search? First and most importantly, it will get you in the door faster -- literally. If you have decent experience and great code samples which are hosted online, I'm more likely to tell a recruiter to just bring you in for an interview, rather than go through the preliminary phone screen. Why would you want to wait and let someone else get interviewed (and possibly get an offer) first?

If you're looking for your first Web Development job out of school, as a new career, or if you're switching from freelance to full-time employment, the portfolio can be especially helpful in leveling the playing field. If you're able to demonstrate strong skills but have little or no job experience, you're more likely to get an interview than someone with years of experience but no portfolio.

Of course, while you're in the midst of a job search, all of these tools are equally useful for getting short-term contract work, too!

What else do you think is crucial to a Web Development job search? Leave your thoughts in comments. If you have questions, I'm happy to answer those in the comments as well. Best of luck with your job search!

Kimberly Blessing

Last week's links

1 min read

Kimberly Blessing

Extraordinary World

2 min read

The past 13 months have been a mixed bag of successes, failures, changes, growing pains, and learning opportunities. This time showed me who my real friends are and helped me realize what's truly important to me. Silly as it may sound, the eleven Duran Duran concerts I was able to attend during this helped greatly with the process of finding and re-centering myself.

Duran Duran aftershow bracelets

Now the tour is over and life must return to normal. I've come to learn that normal for me isn't what it is for others -- the expectations I have of myself leading an extraordinary life constantly drive me to seek out unique opportunities. For a while, there were people in my life who made me feel as though this was an odd way to live, and I was always apologizing for doing the things that I loved to do. But the events and activities of the past year -- and the love and support of friends -- have helped me find myself again, and have shown me that an extraordinary life isn't wrong. In fact, it's what my whole life has been preparing me for.

2009 is going to be a very interesting and exciting year!

My collection of photos and videos from Duran Duran's Red Carpet Massacre tour on Flickr