Posts Tagged ‘project management’

How to avoid firefighting in validation

One of the attendees to my DVClub talk last week just blogged about my talk.  I thought he did a good job summarizing what I said.  Cadence sponsored the lunch.  Here’s the link. (and a picture of me in the process of talking- not so flattering 🙂 )

Advertisements

Speaking at the Silicon Valley DVClub

I’m speaking today for the silicon valley Design Verification Club.  I think the presentation will be linked up to the website with some audio soon.

My topic “Tales from the Trenches: Validation Missteps Making us fulltime Firefighters”.

Pulling a Fast One

I had a great mutual complaining chat on Friday with a co-worker about a two members of our project team who were attempting to pull a fast one over the rest of us.  Here’s the context…

We are simultaneously working on two products- Product A and Product B.  A is the money maker for our division and flagship product of 2010.  B is a strategic product being developed in parternship with another company.  They share some common development peices.  Each one is very important to the organization, but at the end of the day, it is all about making money in 2010.  It’s about being a sustainable, money making organization.  As a result, the priority if we have to make tradeoffs between the two is Product A.

Here is where the “fast one” comes into play.  One of the lead engineering managers is actually prioritizing B with his team, in hopes that no one will really notice and he’ll still get A out on time.  Unfortunately, his manager knows this and is in on it.  Whenever anyone else on the team questions him about the priorties, he always says A first.   We can’t really prove he isn’t telling the truth, but you can sense it by the program updates.

Why does he feel he can do this?  Does he really think he’s smarter than the rest of us?  Does he just think he can get away with it?  It’s not really a problem if both products get to market on time and adhere to their schedules.  It does add unnecessary risk to product A in several ways- less ability to compensate for slip ups and unknown issues we encounter, other functional areas of the product have to work extra to compensate, and general lack of transparency within the team.

In my company pretty much everyone is an engineer.  What I mean is that our marketing team- they’re engineers, our manufacturing team- engineers, our project managers- engineers, our people managers- engineers.  You get the picture.  Engineers think they can do everything.  We’re the people who think we can do it ourselves better than almost anyone else can.  We know we’re smart and think we can learn fast and execute well.  For the most part we can- though sometimes it’s alot better to have someone with expertise and skills in that area.  (that’s a whole other post…)

Part of thinking we can do everything also means we typically think we’re smarter than those around us- even fellow engineers.  So some believe they can pull a fast one over the rest of the team.  They really can’t though.  You look at their body language, the words they use, you poll their team- it’s pretty obvious what is going on.

The sad thing is how much this single action affects both product teams.  Without transparency, and with the engineering director supporting this manager, not correcting him, other people will start to follow suit.  They will start saying one thing, and doing something else.  Pretty soon, the whole team suspects everyone else of not telling the complete truth.  We start pointing fingers and blaming each other.  We spend more time covering our own asses than working together to constructively solve problems and get products out on time.

It’s a vicious cyle that sadly starts with just a single pair, thinking they can sneak something past of the rest us.  That they’re just a little smarter.  That their great engineering skills will enable them to solve their way our of whatever issue this priority change will get them into.  I just hope our team confronts them and are able to change it before we become completely dysfunctional.

Engineering, the voice of reason

This pretty much sums up the day I had today.  (Kudos to my friend Deb for sharing) Sometimes my team gets a little over zealous in their commitments and doesn’t think through the technical details and dependencies in putting a system level product together.

My Day Today

A few years ago when I left my individual contributor engineering role and became a project manager I was scared of losing my engineering.  I felt like I had worked so hard to get that engineering degree that I had better use it to do true engineering design and test work.

What I found out is when you are a good engineering, those good engineering skills shine through.  I’m a good project manager because I’m not afraid to get into the technical details of problems or brainstorm creative work arounds to pull in schedules.  My first year as a project manager I wanted to tell people “hey I’m an engineer”.  I just somehow felt so much less technical.

As that year went on, I gravitated towards technical discussions and wasn’t afraid to share my technical opinions.  Now, a few years into it, and even with a whole new team, people by default think of me as an engineer first and project manager second.

I’m happy to know that when it comes down to making products, engineers are the voices of reason.  We look at the data, we have open discussions, we’re objective, and we often can recommend alternatives.