Monday Oct 09, 2006

Dealing With Schedule Slips is the Easy Part

Someone asked me recently, "What do you do when a project gets behind schedule?", and it's prompting me to write one of my rare \*work-related\* blogs.

When a project gets behind schedule you have to figure out what the root cause or causes are, and you and your team address them. You try to get back on schedule by adjusting either your scope, feature, resources or in some cases your quality dial. If you can't get back on schedule by adjusting those dials, then hopefully there's some slack somewhere in your schedule that you can start eating into. If none of this works, you have to make that painful walk into your director's or VP's office and explain what's going on and what your options are. You tell them what your team recommends. You want to make sure they know what's caused the slip, but at the same time make sure they know that you as the program manager are ultimately responsible for it. Be ready for questions about why your risk analysis didn't identify this schedule slip ahead of time. It stinks, totally.

But wait - dealing with a slip is actually the easy part! The hard part is - knowing that your project is getting behind schedule! Here are some reasons that can be hard:
1. One of your team members is getting behind schedule but doesn't realize it, or they think you won't realize it.
2. Someone is getting behind schedule but they think they can catch up, and they don't want to alarm you or the team.
3. Someone is getting behind schedule but they don't tell you because they think the schedule is bogus and that everyone is playing "scheduling chicken".
4. Someone is getting behind schedule but they don't feel comfortable talking about it openly with the team.
5. Your schedule milestones are open to interpretation and people are interpreting them differently.

There are a few ways to try to address these issues.
1. Get everyone's buy-in on the schedule at the beginning of the project. Make sure you have explicit understanding, agreement and commitment from each team member and their management.
2. Show that you have faith in the schedule. Set the tone for the team that you take it seriously and that you'll hold everyone accountable for meeting their commitments.
3. Make sure schedule milestones are clear and quantifiable. For example if you have build for "Stopper bug fixes only", make sure your team understands what the criteria are for a stopper bug and make sure they know the process you'll follow to make that determination for each bug.
4. Treat everyone in the team with respect and encourage them to be reasonable and fair with each other. If you and your team can't create a good team atmosphere, #4 above will bite you again and again.
5. Get to know each of your team members early on and ask questions about exactly what they'll have to do to meet their commitments to the team. Try to gain their trust so they won't hide information from you as the project progresses. And learn enough about what they're doing so that if they do get behind schedule, it won't be easy to hide it from you.
6. Develop an especially strong relationship with your downstream stakeholders. Technical writers, localization team, manufacturing counterparts. They will see the project from a totally different perspective than you and they are often the first ones to detect that a project is getting behind schedule. Make sure they feel comfortable enough to share that information with you, and make sure you reward their trust by taking action when they alert you to something that's going awry.

In the end if your project is getting behind schedule, the sooner you can figure that out the more options you'll have. So make it a priority to keep your finger on the pulse of your team's schedule.

Tuesday Sep 05, 2006


It all started when a group of us were on a concall with one of our friends from the open source community, Yusuf Goolamabbas. Yusuf asked, "When's the last time one of you installed a Linux distro like Centos or Ubuntu?" Sad but true, since we joined Sun none of us had installed anything but Solaris and Windows. It's obviously unacceptable for us to be this unaware of our competition, so we decided to stage the first ever

Sun China Engineering and Research Institute Install-a-Thon!

crowd shot

crowd shot

crowd shot

Tracy Tan organized the event and recruited six engineers to install the following OSs.

Centos 4.3 (16 minutes to install from network):

centos ui

RedHat EL 4 (25 minutes to install from network):

redhat ui

SuSE 10 (22 minutes to install from network):

suse UI

Ubuntu 6.06 (30 minutes to install from network):

ubuntu UI

Windows Visa Beta 2 (50 minutes to install from DVD):

vista UI

And of course we couldn't miss the opportunity to see one of our own, most cool products - Solaris Express build 46 with Looking Glass (30 minutes to install from network):

looking glass ui

crowd shot crowd shot crowd shot crowd shot crowd shot

It was totally fun and a great learning experience. Many thanks to everyone who worked together to make this happen, especially Tracy, Matt, Daniel, River, Steven, Jerry, and Samuel!

Wednesday Aug 16, 2006

what people in Silicon Valley were talking about last week

I went back to Sun's headquarters in Menlo Park, California last week and talked to lots of people, both within Sun and outside. These are the topics I found one needs to be pop-culturally literate nowadays.

1) Ask a Ninja. People tend to quote the ninja - particularly after a couple of drinks.

2) One red paperclip. The first line in this guy's blog is "My name is Kyle MacDonald and I traded one red paperclip for a house."

3) The Shanghai dog-killings. I suppose people brought this up because I live in China. Still I was surprised to see what a profound impact it had on dog-lovers in the U.S.

4) Kinda like "America's Funniest Home Videos", except really funny.

Finally I have to say how happy I was to hear people say, "Oh yeah, I've been keeping up with you. I read your blog." Note that my best friend, my mom and my husband are not among them but whatever. Sue, David, Xiang Xiang, thank you for reading!

Wednesday Jun 28, 2006

Browsing OpenSolaris Source Code: Surprisingly Entertaining!

It's all about the comments - they're really interesting! Do you ever pick up some random autobiography at the bookstore and flip right to the section in the middle where you see pictures from that person's life? It's kind of like that....

For any non-geeks out there, when an engineer writes code they can sprinkle in 'comments' that are tagged with "/\*" signs, and on the OpenSolaris website they're colored in light grey. When they're done commenting they close the comment with "\*/".

I like the comments because they tell you what a particular piece of code is doing, kind of translate all the code bric-a-brac into something a human can understand. Then if I squint my eyes and look at the code bric-a-brac I think, "Yeah, now I kind of see how it's doing that..."

I also like them because they're often very funny. Sometimes you can see the programmer's personal style in the comments and sense a little bit of the person behind the technology.

If you want to browse kernel code and comments you can look here:
(Again for any non-geeks out there - the kernel is kind of like the brain of Solaris.)

If you want to browse the desktop code and comments you can look here:
(The desktop is kind of like the face of Solaris.)

Monday Jun 12, 2006

Top 3 Things I Look For As An Interviewer

I've done dozens of interviews since I came to Sun in Beijing so I've formed some pretty strong opinions about what I want to see in a candidate and I'm jotting them down here. You might say I'm crazy to tip my hand like this but I figure if you know I'm going to interview you and you had the good sense to google me, you deserve this.

1. Give me specifics. I do a lot of behavioral interviewing so when I ask you, "Tell me about a time when you [insert anything here]", tell me about a time when you [inserted anything here]! The best indicator of future performance is a person's previous performance in a similar situation, so please describe real situations from your past.

2. Answer my questions. You wouldn't believe how many people spend 10 or 15 minutes not answering a question! Listen closely to what I'm asking and answer it. Get to the point and let's move to the next question.

3. Check out Sun before you come to the interview. I'll probably ask you what you've read about Sun in the news lately. You can talk about OpenSolaris, hardware, Sun's recent cost-cutting announcements, whatever. But show me that you really want to work here.

BTW, here are the top 3 words I love to hear from a candidate in interviews:
1. "customer"
2. "goal"
3. "risk" (preferably preceded by "calculated")

Thursday Jun 08, 2006

If You Had Known Back Then What You Know Now?

"What do you know today that you wish you'd known when you first became a manager?" I'm a brand new people manager and I asked this question of a few experienced ones. What I got was a good sampling of manager wisdom:

- Trust your gut.
- When you find good people hire them. You can figure out later which job they'll go into.
- Give people time.
- Change the definition of "success" and thus the satisfaction that you get from being successful. From "success" = "doing good engineering" to "success" = "I coach my people well, therefore my group is doing good engineering".
- Be very aggressive about dealing with personnel problems.
- Hire for potential rather than current ability/experience. Potential must include willingness to learn, evolve and even paradigm shift.
- Actively invest in your team and build relationships as if they would be for a lifetime.
- Never promise something you don't know you can deliver.
- Never tell a lie.
- Don't change your style to suit your team. Be yourself.

If you're an experienced manager and have your own bit of wisdom to share, please leave a comment here and I'll add it to my blog.

Monday Jun 05, 2006

What does it Mean to "Handle" an Executive

It might happen to you one day. An executive, usually VP or EVP, will be travelling in your area and someone nominates you to be the "handler". You might wonder, as I did, what the heck that means. Now that I've been through it I thought I'd jot down a few tips for future handlers.

To sum up the job in one sentence, a handler makes sure that an executive's trip in a foreign country is as productive and smooth as possible.

In order to achieve this you have to do a lot before the exec arrives and while they're there.

Before they arrive:

- Clarify what your job as handler will cover. It could be any of the following:
- Decide what events the exec will attend.
- Decide whom the exec will meet with.
- Schedule all the meetings.
- Prepare slides that the exec will present at conferences.
- Brief the exec before customer visits.
- Take notes during customer visits, note action items.
- Speak in the local language to the driver, waitresses, etc.
- Interpret for the exec at meetings.

- Clarify what your "interfaces" are. In my case, my exec's admin had already booked his plane tickets so I clarified with her that I would be responsible for him from the moment he arrived at the Beijing airport until the moment he departed four days later. I told her I would book all his appointments while he was in Beijing and that if anyone went to her for an appointment she should kindly send them to me. This worked out great.

- Book the exec's hotel, car, driver, etc. Ask their admin for their preferences regarding smoking/nonsmoking, king size or queen, etc. Make sure the car has seat belts in it.

- Get someone to help you with the scheduling. In my case a wonderful admin named Jia was responsible for arranging meetings for my exec. She was also my "home base" while I was escorting my exec all over town. Whenever something came up I knew I could call Jia and get answers to questions or changes to my exec's schedule. Her help was invaluable and I wouldn't advise anyone to attempt to handle an exec without some admin support back at the office.

- Prepare a detailed itinerary. Remember to include travel time from one venue to the next as an itinerary item. Jia included the following for each event:
- Name of event
- Start time
- Stop time
- Location
- Primary contact person
- Purpose
- Comments

- Prepare a notebook for yourself which includes:
- The agenda for the exec's trip
- Maps to every venue
- Agendas for each conference the exec will attend
- Phone numbers in case you lose your cell phone (if you have this then you won't lose the cell phone, know what I mean?)

- Google your executive before they arrive so you'll have something to talk about with them.

- Find out which venues have wireless access. The exec is going to ask you this for sure every time they sit down somewhere.

- If you have kids, arrange extra childcare for them. They'll be asleep when you get home at night and you'll leave before they wake up in the morning. I asked my family to just pretend I was on a business trip.

-Prepare a bag for yourself with the following:
- Laptop
- USB stick
- Cell phone with phone number for every person the exec will meet with
- Breath mints

During their visit:

- Have a good breakfast every morning. You're going to be running around all day, make sure you have some fuel for yourself.

- Bear in mind that your exec will probably be fighting jet lag so find out what their preferred caffeinated drink is and get one for them after lunch.

- You might wonder whether your exec wants you to join them for social events at lunchtime or dinnertime. I told my guy honestly that he should just let me know if I should join him or quietly disappear.

- Be sensitive to the fact that they will be tired in the car so they might want to sleep or just stare out the window. Let the exec take the lead on starting conversations.

- Some executives stay on schedule very well, as mine did, but others will tend to run over on every single meeting.

I told my guy that I wouldn't try to end his meetings if he was running over time, but if he was running over I would make sure he knew it, and that he knew what the impact was to his next meeting.

- Executives' schedules can be erratic. Customer visits get scheduled at the last minute, conference organizers approach you at the last minute asking if the exec can attend a rehearsal for a keynote speech, etc... Leave some slack in your exec's calendar that you can pull in if needed. In my case Jia and I scheduled an afternoon at the museum on Day #4 for my exec. When other meetings came up we cancelled the museum trip. While some meeting requests come in at the last minute, other meetings will get cancelled with very little notice. You don't want your exec to have unexpected downtime so try to have some meetings, perhaps 1:1s, that you can schedule with very short notice if something else gets cancelled. And try to alternate critical meetings with less critical meetings so that if one gets cancelled you can possibly bring the other one in.

- If your exec has a meeting in a hotel and you have to disappear during it, and if you are a woman or else a guy who likes to pamer himself, go down to the hotel spa and get a manicure. You deserve it, this is a rough week.

Finally I would say - have fun! This is a rare opportunity to see what an executive's day-to-day life can be like, at least when they're travelling. It's also a rare opportunity to develop a personal relationship with your boss' boss and see what's behind the executive bio and the professional portraits. I have to say my time with my exec was one of the most fun weeks I've had during my career at Sun. And he was really grateful for my help.

Tuesday May 23, 2006

What's I Look For in a QA/QE Engineer: A Program Manager's Perspective

One of our recruiters asked me to write an article about what Program Managers look for in QE or QA engineers. It's gonna go into some recruitment magazine we're putting out. I was surprised to discover that I actually had a lot to write and I thought I should post it in my blog. It's a long read but hopefully helpful for anyone who's applying for a QE or QA job at a technology company and expects to be interviewed by a program manager.

What's Important to Me in a Quality Assurance Engineer:
A Program Manager's Perspective

As a Program Manager at Sun Microsystems I have worked in many capacities and managed many kinds of projects. I started as a Localization Program Manager then went on to be the Release Program Manager for one of Sun's newest and largest consolidations: the Java Enterprise System. Today I'm the chief-of-staff for Michael Hayden, the engineering director for the Operating Platforms Group here in Beijing. In all of these roles I worked closely with Quality Assurance Engineers and I've come to know what I can expect from a good one, at least from my perspective as a Program Manager. When I interview QE or QA engineers (for purposes of this article I'll refer to them collectively as QE) here's what I'm looking for.

Customer focus
QE engineers are the first customers of a product and they can be the strongest advocates for the end users. When QE engineers are writing their test plans, executing the tests, reporting results and following up on bug fixes, the customer's experience should be their main concern. They need to advocate for the customer at all times.

Good high-level communication
When a QE engineer escalates an issue to a Program Manager he or she should have a good high-level description of the issue and where he or she needs help, if at all. Here's an example of a bad way to approach a Program Manager when a QE engineer has encountered an issue:
QE engineer (comes into Program Manager's office, looking very frustrated): “I was just testing the build and I clicked on the 'send' button but when I sent the mail all the characters are garbled. Prasad said in the bug report that he fixed it but it's not fixed! What are we going to do?”

The following questions will start running through the Program Manager's mind: “What product are you testing? What build are you testing? Is that the latest build? What 'send' button are you talking about? Who is Prasad? Have you talked to Prasad about this? Are there any differences in his environment and yours? Are you able to verify fixes for any of the bugs that are supposedly fixed in this build? What can I do to help in this situation? How much longer do I have to work until I can retire....?”

Here's how that could have been better:
QE engineer (comes into Program Manager's office looking very calm and in control): “I've been verifying bug fixes this afternoon in the latest build of product X. Most of them are fixed, but I've got an issue with bug 637xxxx. The responsible engineer said in the bug report that it would be fixed in this build but I'm still seeing it. I'm going to talk to Prasad now to find out why he thinks it's fixed but I wanted to give you a heads-up that if this bug really isn't fixed, it might be cause for a re-spin. I'll get back to you in an hour or so.”

Here's what's running through the Program Manager's mind now: “I'm so glad this guy is in control of the situation. I know he'll come to me if it gets out of control. I'm gonna send good feedback to his manager when the project is over. I love this job.”

Good peer-to-peer communication
A good QE engineer has to have good written and spoken communication and at Sun we have so many global, remote teams that written communication becomes especially important. The importance of good written communication is obvious when a QE engineer writes a bug report. If the responsible engineer has to follow up with questions in order to reproduce the bug, the original bug report wasn't thorough or detailed enough. I won't try to give a class in QE 101 here, but everyone who has studied QE knows the kind of info that makes a bug report successful. The summary needs to be clear, the priority and severity need to be appropriate and justified, the steps to reproduce the bug must be included. Any details about other environments where the bug is not reproducible are also very helpful. Basically, remember what you learned in your QE classes at university and apply it on the job.

While written communication skills are obviously key, spoken communication is also crucial. QE engineers must be able to give updates at team meetings and at times they'll need to call other QE engineers or development to talk through a problem live. Without good spoken communication skills you can leave your audience more confused than you found them.

Good English
QE engineers don't need to be able to have philosophical debates in English but they do need to have a good English vocabulary and decent pronunciation. Don't worry about impressing people with your stellar vocabulary - stick to simple words and phrases and get to the point as quickly and efficiently as you can. Don't forget some of the most useful phrases that a member of a software development team will ever use:
“Sorry, I don't understand.”
“I need help.”
“It's under control.”

It's not enough to identify a bug; good QE engineers need to know how to get bugs resolved. Quite often this means you'll have to go to development engineers to help them understand the issue and to help them understand the importance or urgency of a fix. Never assume that the ball is in someone else's court and you can sit back and wait for the resolution. Program Managers notice who is moving things along in a project, and they make sure those people's managers also know.

Knowledge/Hard Skills
An outstanding QE engineer knows the product they're testing, the best way to test it, and the best way to report the results. I've run across QE engineers who couldn't do simple calculations like tests passed/tests executed or tests executed/tests planned. These skills are what I like to call hard skills and they are something each QE engineer should bring with them to the job.

Ability to identify risks
A good QE engineer can identify risks early and identify ways to avoid or mitigate them. For example, if a test team is going to need a certain kind of hardware for a particular release, that information needs to come to the project team and the Program Manager at the very beginning of the release when there's still time to order and set up the hardware. If a test team highlights too late that they're lacking hardware or resources, there's generally no way to avoid the risk. The best the team can do is try to mitigate it.

Reasonable attitude
I've heard QE engineers say, “This bug just has to be fixed” however they can't explain why the fix is so critical and they aren't willing to talk about alternate solutions like implementing a workaround or releasing a patch or documenting something in the release notes. None of these solutions are perfect but there is also no perfect software. Good QE engineers know how to partner with the Program Manager and the rest of the team to find the best solution for the customer, they don't stonewall or shut down when their opinion isn't taken at face value.

In summary, I hope these points will be useful to you as you search for a job as a QE engineer. And if your search brings you to Sun I look forward to working with you!

Sunday Apr 30, 2006

Without This Team Sun Would Fall Apart

April 26 was Professional Admin's Day - a chance for us to say "thank you" to our amazing admin team at Sun in Beijing. They keep everything running smoothly for us and keep smiling all the time. Each of them is strong, smart and resourceful, and they work together very well as a team.

We celebrated by having lunch together at the Shangri-La Hotel. The buffet was so huge - we realized that we should have planned to spend the afternoon there instead of just a couple of hours.

admins in restaurant

And later went for a stroll around the hotel's beautiful garden.

admins under tree

If you want to read a hysterical version of this outing from a person who wasn't even there, check out Sin-Yaw's recap.

Monday Apr 24, 2006

So You Want to be a Program Manager

I'm going to break with my own tradition and write something work-related in this Sun-sponsored blog....

I manage the program managers and administrative assistants at the OPG (Solaris) office in Beijing. I have an awesome team, every one of them is smarter than me.

I also have a constant stream of people who come to my office and say they want to become a program manager. I thought I should write here what I tell all of them.

First of all, you should do some research to find out if you really like program management, and if you've got a talent for it. I advise all aspiring program managers to do all of the following:

1) Take a project management class. If you work at Sun you can take SunU classes like Frontline Leadership, PRINS, PLC, or Essential Meeting Facilitation. If you're outside Sun you can take PM classes at your local college or university, or you can get certified through a program like the PM Institute.

2) Sit in on several program managers' meetings. You'll get to observe many different styles, and you'll see how effective each one is. Just pick a meeting you're interested in and ask the program manager in advance if you can be a fly on the wall.

3) Get a program manager to be your mentor. Remember that no one is going to ask you to be their mentee - you'll need to initiate it.

4) Volunteer for program management activities in your current job. Whether you're an admin or a QE engineer, your manager will appreciate it if you offer to help organize some management task. And it'll give you a chance to see if you like this kind of work. Note that you'll need to take initiative, your manager probably won't think to assign this sort of thing to you. You'll need to recognize the need and volunteer.

Stay tuned for the next article in this series, where I'll discuss the qualities I look for in a program manager.


The grilled cheese sandwich of blogosphere


« July 2016