Archive for January, 2011

Who to hire: a domain expert or a “best athlete”?

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
You just got funding for an aggressive new project, and are looking to fill some mid to senior level open positions.   You have written the job specifications (don’t even think of starting the hiring process until you have that in hand).   Who are you looking for: someone who has done the job before in a relevant domain, or a talented generalist who can be trained to do anything?

My answer is that it depends. There is a time for everything: a time to hire domain experts, and a time to hire best athletes.  I have hired, and have been hired, as one or the other at different points in time.  The question is how much of a tearing hurry you are in.

I once had the privilege of hiring several best athletes to build up a cross disciplinary research and advanced development team from scratch.  This team was not tied to mission critical product releases.  The most important attribute I looked for, other than their respective functional disciplines, was creativity and versatility.  I needed quick studies who enjoyed being stretched.  My team sported some of the best problem solvers I ever met.  None of them had domain expertise, and it didn’t matter.  I had plenty of time to teach them what they needed to know.  It was great fun working with this team and we were very successful in our pursuits.

In another instance, my company had just landed a $1.5M funded development project with an aggressive schedule.  We started a targeted search to staff the project, where we screened out anyone who didn’t have experience in an obscure branch of computer graphics.  We rapidly ran out of people who met our stringent screening criteria.  The last addition to the team was a “best athlete” – an excellent programmer who didn’t know computer graphics.  For all his stellar track record, he simply couldn’t keep up.  There was no time for him to learn what he needed to know to succeed.  The fault was ours for forcing a fit.  In the end, we regretfully parted ways when his contract came up for renewal.

Training someone to do something they’ve never done before is a transformational experience for both the mentor and the mentee.  But you must have the time and space to do it properly.  As a hiring manager, I feel that it is a breach of trust to the employee to put them in a position where they neither have the necessary skills nor have enough time to learn it on the job.  It is equally a breach of trust to the company and its shareholders for spending valuable time and resources attempting to cross-train someone who is not right for the job, when deadlines loom and a project delay or failure has catastrophic consequences to the business.

Generally, if time is of the essence, I err on the domain expert side.   People who take the time and energy to become experts in their fields frequently turn out to be fantastic all-around athletes too.  That would be the best of both worlds.

Want a killer UX? Wireframe and iterate

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
This post is about how to iterate on UI and deliver a stunning user experience to end users on a shoestring budget. The secret is to do it the old fashioned way: wireframe it first, then make compositions, then test the storyboards with users, then code it up.

I’ve been part of several development projects where my project team was forced to cut corners on up front design.  Sometimes the product management and design teams were busy doing other stuff.  Other times (GASP!) the company didn’t actually have product managers or designers.

Typically the feature would be communicated in the oral tradition.  If we are lucky we sometimes get napkin sketches.  Engineering is then requested to code it up so we can “see what it looks like”.  The requirements are generally very sparse, marginally communicated, and the user workflows are not thought through.

This of course results in something with a UX that is at best rough around the corners and at worse inexplicable.  Changes are requested, new code is written, and this cycle repeats itself until the project overrun is intolerable and the feature is released to the wild with multiple compromises.   The project ends up taking 2 or 3 times as long as it should.  We get lots of 1 star reviews.  Everybody is cross with everybody else with how things turned out.

Instead of rushing to code stuff up, if the PM and designer take the time to start with user storyboards, flow charts and wireframes, iterate until mainstream use cases are solved, then move to the compositions depicting the graphical layout of every screen in the feature, and then validate with end users, the exact same project would take half as long in elapsed time and will work 10 times better for the end user.

This is because the PM and interactive designer have the best access to actual end users, and are the most qualified people in the company to dictate how the feature works.  Also, tools like Microsoft Visio makes it possible to do 20 iterations on a wireframe in a day, whereas it is simply not possible to iterate that fast in code.

In a startup environment, we sometimes measure success by the wrong metrics: we equate speed to market to success.  A better metric would be speed to market with a great user experience and satisfied customers.    It’s much better to invest up front in a good design – you will save money and time in the final analysis.

My life in an InMap Infographic

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
I just tried out the new Linked In visualization tool that lets you visualize your social graph on Linked In.  You can get it here.

Here is mine:


There it is: all the people I know from 3 startups founded by my old friend Beth (blue section at the bottom). The company that made it out of startup land and got profitable (orange section). Two other companies (green and purple). Classmates and my husband’s coworkers (pale blue and chrome yellow).  People I have met in other places (scattered throughout).

This is cool beyond words. You must check it out!

Unbricked!

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
I fixed my previously bricked Lenovo Thinkpad T61! Here’s how I did it with all of my old software.

  • Buy a new SATA drive
  • Install it according to Lenovo’s instructions.
  • Restart, go into the BIOS and change the drive mode to IDE or compatibility mode.
  • Insert a full-up Windows CD (not an upgrade CD) in the optical drive and restart
  • Install Windows XP. (Yes, I know I should have upgraded to 7, but that costs money.)  When you are done you will have the computer back up, but it won’t see the ethernet adapter since the drivers won’t be there.
  • Go to a different computer with internet connection and download the right Lenovo ethernet driver. Save it to a USB drive.
  • Stick the USB drive into the computer that is being rebuilt and install the ethernet adapter driver.
  • Reboot.
  • Plug in the computer – now it should get on line with the ethernet connection. Immediately download and install Chrome and Firefox so you aren’t stuck with having to use IE.
  • Now download and install the Thinkvantage System Update package from Lenovo.
  • Reboot. Now most (but not all) drivers would be installed (everything except what counts: the Wi-Fi drivers.)
  • Download and install the Wi-Fi drivers from the Lenovo site.
  • Reboot again and set up your wireless network. Voila! you are on line.
  • Now install your antivirus software, and reboot again.
  • You are now ready to spend the next 8h reinstalling everything that used to be on this computer.

A big thank you to all my awesome coworkers – especially Paul C., Paul F. and Meher – who flocked to my rescue when I asked for help. You all rock!

What to do on a snow day

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
We were snowed in on Wednesday with a very impressive Nor’easter.

I got very little of my pressing to-do’s done, since almost every company I urgently needed to talk to was closed due to inclement weather. So I sat down and Thought Big Thoughts.  Is this project on track on a global level?  Having killed the last 25 mini-milestones, are we more or less confident we are making headway towards the big milestones?  How can we juggle things around to improve efficiency and decrease overall elapsed time?  How do we optimize all this?

I had some good insights, and ended up reprioritizing certain tasks based on the quiet reflection that never would have happened without the snow day.

Running around with my hair on fire all the time is really quite harmful.  I just have to make time to reflect and recalibrate outside the craziness of the daily dose.  I’m making a recurring appointment with myself for this.

Bricking (and unbricking) a laptop

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]

This past Monday I bricked my laptop.

Many people have asked me how I did it.  It’s easy.  Plug in your priceless, personal, vintage computer (that you haven’t backed up for months) near the edge of your desk, then knock it down as you walk by.


I recorded the diagnostic process in hopes that it will help someone else (surely I’m not the only klutz who knocks computers to the floor).

  • I rebooted it a dozen times to see if it would fix itself.  It didn’t, but I did conclude the motherboard was probably still alive, since the Windows splash screen always came up before the Blue Screen of Death.
  • I looked up the error codes in the Blue Screens of Death.  Since the codes kept changing, this was not particularly helpful.
  • My friend Paul took out the hard drive and shook it to see if it rattled. It didn’t.
  • I brought up the BIOS startup troubleshooting utility and ran a full diagnosis.  The hard drive passed some tests and flunked other tests, suggesting it got scratched in the fall. Everything else passed.
  • I put in a Windows Installation CD to try to repair the installation. It didn’t see the hard drive at all.
  • I put in a Ubuntu boot / installation CD and it booted perfectly.  I even caught up on the latest non-news on the Verizon iPhone.

From this exercise I convinced myself that:

  1. The hard drive is probably hosed, but the motherboard and peripherals were hopefully fine.
  2. A cheap $25 replacement hard drive from Lenovo outlet might just fix the problem.

So now I am waiting for my $25 solution to arrive so I could unbrick the computer.  Then I get to spend, oh, 80 man hours installing all the software back on this computer (including the dreaded Pro/E installation).  FAIL!

There is one bright note in this.  If it works, my computer will become less cluttered and should run faster.   That, and buying some time before I have to upgrade (and giving solid state drives a chance to come down in price).

😦

Managing a geographically distributed team

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
Lots of teams are distributed these days, sometimes nationally, sometimes globally.   We go where the talent is, and requiring people to clock in at headquarters every weekday is no longer a smart way to do business.

This poses challenges as a distributed team cannot coordinate by osmosis the way a colocated team can. They can’t figure out what everyone else is doing by hanging out at the lunch table or chatting about projects in the bathroom (yes, we do that around here).

Here are some strategies to make sure the team bonds well, interdependencies are clearly understood, and the project runs effectively and efficiently.

  • Do a face to face kickoff if at all possible.  Face to face contact establishes rapport much more effectively than video conferencing or phone calls.  Getting the team to meet each other at the start of the project provides much-needed social context.  This helps everybody understand how to work with each other.
  • Establish a weekly coordination phone call and stick to it come hell or high water. No matter how frequently you touch bases, having an official project check point sets expectations that progress will be assessed on a weekly basis and is very helpful in keeping everyone informed and coordinated.
  • Do impromptu Skype conferences. I like Skype – you get video / voice calls and screen sharing for free.  (Anyone remember the PictureTel days? This is so much better.)
  • IM. Again I like Skype, but anything else does too as long as your whole team agrees to adopt it and log in when they are working.
  • Go to voice whenever an email thread starts to get long.
  • If there is significant time difference between key parts of the team (e.g. if part of the team is in India, Taiwan, or China), be ready to be very flexible with your time and be prepared to get up early or stay up late (or even get up in the middle of the night) to communicate with your remote team members during their working  hours.  In return. they should do the same for you sometimes too.
  • Organize periodic face to face events – call in remote contributors to headquarters to reinforce the personal connections between team members. While we like to think technical work is all left brain, there is much intangible benefit in the personal relationships between people.  A well bonded team generally works more productively and effectively than a team of people who barely knows each other.

In the final analysis, I believe there is no substitute for face to face communications.  However we can go far with a little structure and a little technology.

How to conduct a competitive RFP

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]

In recent months I have had three opportunities to conduct a competitive RFP on three different initiatives. I have learned so much about this process. Here are some key takeaways:

  • If you are looking for someone or something new, ALWAYS comparison shop. It takes twice as long.  But you will think through the selection criteria much more clearly, have a much deeper understanding of each candidate’s strengths and weaknesses, have much better leverage on price, and will almost always save money in the long run.
  • Make sure you write a thorough RFP and take special care in assembling the supporting documentation.  A proposal or quote is only as good as the RFP package.  Clearly outline what you are asking someone to quote, break it down into phases, make it very clear how you want the response to be structured, and include an RFP questionnaire to ensure the response covers key areas of interest.
  • Where possible, do a budgetary quotation on something you know the price of. For example, if you are looking for someone to develop a new iPhone app, you could have them look at an existing iPhone app and ask them how much it would take for them to create that app.
  • Give vendors enough time to put forward a thoughtful response.  A week or two is appropriate for most projects.
  • After you receive each response, follow up with a phone call to go over each line item, ask the candidate partner to clarify any ambiguities, and clearly express your issues and concerns.
  • Respond to their response in a timely and respectful manner.  They have worked hard to provide you with a quality response, and they deserve to be treated professionally even if you have decided against working with them.

360 reviews

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
About 10 years ago,  I was unexpected promoted to VP Engineering.  I suddenly became the leader for a lot more people than I was ready for, or was trained to manage.  I accepted the promotion on condition that my company provided me with career coaching.

The first thing the career coach did was to request a 360 review.   I understood the value right away, but I was feeling highly  insecure about having my career coach interview my brand new employees.  I felt that this would be a display of weakness which I could not afford in a time when my entire quarter was devoted to employee retention.  So my coach did a 180 instead – he worked with my boss and my peers, but not with my reports.

I look back on this exercise today and found my younger self incredibly lacking in maturity and common sense.  By not allowing my coach access to my employees, I basically cut the legs off the review process.  He was able to only work with information provided by me, my peers (who already bought in to my presence on the management team) and my CEO (who promoted me in the first place, and therefore presumably thought I was a good trooper).   Where would the negative feedback come from?

Ultimately my coach was helpful in teaching me frameworks and strategies to deal with my organization, and he helped me with many difficult communications via role playing, but at the end of the day he was working in a vacuum regarding what my employees thought of me.

If I was to do a 360 today, not only would I include my current and/or past reports, I would try to include people I had to lay off, people I had promoted, peers, supervisors and board members (if I have a close enough work relationship to make this an acceptable request).  I will get a much more complete picture of how I am perceived in the workplace.   Then I can apply these tricks in dealing with the negative bits of the 360 review.

I am a big fan of constructive criticism.  What you can measure you can improve.  I need to be told I stink sometimes (and I think everybody can benefit from a healthy dose of honesty from time to time).  A 360 is a fantastic way to achieve this.  I’d love to do another one some time soon.

Learning violin: perseverance and work ethics

[tweetmeme source=”chenelaine” only_single=”false” service=”bit.ly”]
I picked up violin when I was about to turn 40.

This is actually less stupid than it sounds.  I have played the piano since I was six. So I had a bit of an edge over my young child who started violin around the same time:

  1. I could read, and she couldn’t (although she rapidly rectified this situation).
  2. I could read music, and she couldn’t. (I have the dubious last laugh. She’s learning under a modified Suzuki system and she is practically illiterate in note reading even today. I can sight read circles around her.)
  3. I have practiced every rhythm known to man on another instrument while she has to learn each one from scratch.

All the same, it was a fantastically humiliating experience to be an adult beginner in a notoriously finicky instrument.  Unlike piano, where there is a limit to how horrific you can sound (if you keep it tuned), there is no limit to hair raising sounds you can make with the violin.  Even more humiliating is the comparison: a song that takes me weeks to polish will take my (musically talented) child approximately 3 days to master.

It was rough the first few months and yet I stuck with it. Slowly I improved.  I found that this experience is a source of life lessons in perseverance and work ethics.

  • Don’t let anyone tell you that you can’t do something / are too old to start something.
  • Don’t give up on the first failure – keep trying. If you care enough you will eventually make progress.
  • The longer you work on something the better you get (the 10,000 hour rule).
  • That said, you have to take breaks from time to time or you will plateau and/or burn out.
  • You cannot skip steps. You must master each skill before you can move on, or your overall performance will suffer.
  • You can feel great about relative success (comparing what you can do now to what you were able to do a year or two ago).
  • Yet you can still feel crappy about absolute success (comparing what you can do with other amateur musicians).
  • Good teamwork is fantastic to experience (playing in small groups with other beginners is a lot of fun.).
  • Having a long term goal keeps you going (I aspire to play second violin in the town orchestra before I turn 95.).

A few Suzuki books in, I am still highly engaged.   I hope to make some real music in the future.  I will keep working towards that goal!



%d bloggers like this: