The many facets of leadership

Like any other manager of a functional group, the product development manager wears many hats.  He or she is a technical lead, a head coach, a Gantt meister, an HR specialist, a product architect, a social chair, a strategist, a tactical guerilla fighter, a human shield against distractions, a cheer leader, a measurer and communicator of team performance (whether good or bad), a translator of corporate strategy to his/her team, and a translator of technical jabberwocky to less technical stakeholders.

He/she must take care of his/her product as well as people.  He/she must work effectively with product management, sales, marketing, manufacturing (for hardware products), finance and operations to ensure the output of the development team plugs into a viable and implementable company plan.

How do you measure the performance of the development manager?  Which aspects are the most important to watch?

There is no right answer to this question because the hat prioritization depends on the organization, the state of the product development process, the personal dynamics inside and outside the development team, and the personality and style of the development manager.

For me, under most circumstances, the success of my team defines my own success.  There are two areas to watch:

• Team performance: Is the team hitting its milestones on execution and developing a great product effectively and efficiently?
• Team development: Are we nurturing and empowering team members to grow and prosper in their respective careers?

Team Performance
The greatest compliment anyone can give me and my team is to tell us that we are an execution machine. A team that performs well and executes its initiatives is a team that shines.  

Now how do you create conditions to help your team excel? First and foremost, the right people must be in the right jobs.  There’s no way to get excellent performance out of an organization if people don’t have the right aptitude and training to do the job they are asked to do in the time frame that the job needs to be done.   Performance will also suffer if people are made to do things they don’t like to do for extended periods of time.  

Second, we must clearly define goals and objectives, and then stick to them for long enough so the team has a chance to execute against those goals. To be in a startup is to be in flux. New data and learnings flow in all the time and we do need to be able to stay nimble and pivot rapidly when the data tells us to do so. That said, continuous thrashing is the best way to trash a team’s performance and morale. We must strike a balance between our desire to turn on a dime and our need to stay focused so we can execute against the best available information, creating deliverables that will help us test and learn for the next iteration.

Lastly, we need to succinctly define success in a clear and tangible way, then measure the team’s performance against these success metrics.  What you can measure you can improve.  There is nothing more motivating than being able to celebrate victories when we hit our milestones.  And when we miss, those are learning moments that give us valuable data to help improve our performance the next go-around.

Team Development
The second thing to watch for is whether team members feel happy and supported in their jobs, and whether they are growing and prospering along their chosen career paths.

I take the coaching aspect of a development manager’s responsibility very seriously. To the extent possible, the development organization should provide opportunities for team members to learn new things and stretch their skills in their areas of interest.  

While I believe the primary characteristic of a high caliber development team is its performance, a happy, motivated team in a trusted, supportive work environment that looks out for their interests and takes steps to help them grow can usually get more work done faster and with a better quality of output.

What do you think about all this?  How would you prioritize these hats in your own role?

Trust your gut

Recently a situation came up at work where we ran into a critical performance issue with one of our key suppliers.  Their performance raised grave concerns, and all the mitigation activities we undertook in the past week did not help.  The work output was simply not acceptable in either quality or quantity.

The ironic thing was that we had concerns going into this relationship.  The supplier came in with glowing recommendations, and they had expertise in a key area that was of vital importance to us.  During the due diligence process, something didn’t feel right.  But they submitted a credible RFP, so we went with them anyways, against our gut instincts.

Looking back, I now realize the warning signs were all there when we were processing the RFP’s.  The performance problems today were foreshadowed by cues we picked up in various conversations.  We picked them due to their domain expertise, but at this point, not only have we not enjoyed the benefit of that, we are also facing the prospect of a large mitigation effort to fix this mess, which meant lost dollars and lost time in the development cycle.

My M.O. in hiring in a time of great schedule pressure has trended in the direction of domain expertise.  But this time I made the wrong call.  I should have listened to our gut and gone for the best athlete instead.  There was another bidder who came in very strong, with a fairly competitive price, but who did not have the specific expertise we required.  I have a feeling that we would be in a much better situation if we had gone with them instead.

Lesson learned: trust your gut. If all logic points one way, but your gut tells you to go a different way, there is usually something profound at work and it’s worth stopping in your tracks and trying to figure out why.

At least we caught this issue early and will be able to address it swiftly – no point in letting a bad situation drag on.

Managing a geographically distributed team

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.

“Vision without execution is hallucination”

This time of the year, we get to hear all about everybody’s New Year Resolutions.  I shall lose some weight! I shall exercise! I shall spend more time with family! I shall volunteer! I shall learn the trumpet!

These resolutions have fantastic mileage.  Most people can recycle last year’s resolution every year.  This is because those lofty goals fall victim to vision without execution.  Without an actionable plan and a commitment to execute, these good intentions end up going nowhere.

The importance of execution is often overlooked in a startup where fluidity, creativity and innovation define “cool”.   The need to be nimble and quickly pivot can create an environment where visionaries thrive, but execution is glossed over.  But if execution is ineffective, even the best idea will fall down.  In this brutal economy, if you cannot execute on the milestones attached to a funding round, you may never get a second chance.  Your next appointment could be with the repo-man.

How do we set up an environment where our team can execute with excellence?  Here are some tactics that have worked for me.

• Clearly define the goals, objectives and measures of success, and communicate it up and down the foodchain.
• Having enough an actionable plan to get started and go for at least the first phase (which should last weeks, not days).
• Continuing to refine and build on the plan as you progress.
• Construct the right team with the right skillset to get the job done.
• Be ready to swap out team members if they turn out to have the wrong skillset or the wrong mindset.
• Measure yourself against success metrics early and often and call a spade a spade as soon as enough data is available.
• Celebrate victories, big and small. Reward team members for a job well done, early and often.
• Hold yourself accountable. Own up to failures yourself – don’t make excuses, and don’t wait for someone else to notice.
• Be open and humble.  Talk less and listen more, to tap into the wisdom and experience of other people.

What are your favorite tips for execution? I’d love to hear your thoughts.

Say “thank you”

The day before yesterday, one of our software gurus pulled a miracle out of his hat.  A server had been hacked, and he got stuck with the unsavory task of trying to retrieve what’s salvageable and to bring the same services back up on a different server, with almost no material support from anyone.

I thought it would take a week to bring it back up. It took him 2 working days (and nights).   So I emailed the software team and the senior management team to acknowledge this feat.  I also acknowledged his improbable achievement in other public gatherings.

In my mind, this guy put in effort above and beyond the call of duty and achieved a fabulous outcome.  The least I could do is to make sure everybody knew it was he who did the work, and that I was really impressed.

In startups this kind of acknowledgement is simply not done frequently enough.   When everyone is in a constant state of running around like chickens with their heads cut off, it is hard to remember to stop and say a simple “thank you” to the people responsible for the achievements that keep the lights on and help support the success of the company.  But we simply have to make the time.

Nobody reads minds. If you don’t express it, it’s like you never experienced that sense of appreciation.    Our employees make big personal sacrifices to be in a startup, with an often compromised compensation package, strange working  hours, and a perpetually high stress level.  Say thank you frequently, often, in public and in private.  Make sure they know your appreciation.  It’s the least we can do for our star performers.

A learning moment about Plan B

No, I’m not talking about that Plan B. I’m talking about backup plans (like the time I called a motel near my campsite to inquire about vacancies, just in case we needed to vacate our site due to heavy rain.)

As a compulsive planner, I really can’t help myself.  For every truly important Plan A (camping included), I generally have at least a Plan B, if not C through F.  I play to win.  I generally try to come up with many different ways to achieve an end to maximize the odds of success. This approach has worked marvelously well for me throughout my life for the things I truly cared about.  So I’ve felt smug about my great hit rate, until recently when I was challenged on my approach.

Someone who was a big champion for a Plan A noticed that I was making a Plan B, and he got noticeably upset.  He told me that my approach indicates that I was not aggressive enough in my pursuit of Plan A, that I don’t believe in it enough, and that I should channel my energy back to making the primary approach work.

So I sat back and thought about this.   Did I put any less energy in Plan A’s just because I have Plan B’s?  Definitely not.   I still chased  after the holy grail in full steam.   I simply believe in covering all of my bases since Plan A was full of risk.  Apparently this can be seen as a form of betrayal by people who are highly invested in Plan A.

As I am pretty left-brained, I find this sentiment illogical and hard to empathize with.  It appeared to me that this person was  responding emotionally, not rationally, to the situation, since I have the facts on my side.  Yet I accept that this person’s sentiment is no less valid than mine.  People Are Different And That’s OK (that was the first and most important takeaway from all my years in ethnography research.)

This was a learning moment.   I learned that I have to work harder in managing expectations in situations like this.  I am not going to stop making Plan B’s.  I just need to make it quite clear that this doesn’t mean I support Plan A any less.

I had a chat with the person, and all’s well that ended well.   I hope I’ll do a better job at managing perceptions next time.

Rallying a team behind unsexy projects

It’s easy to get a team psyched and energized on sexy projects – the kind that have huge and visible customer impact, which gets your senior management and your board all excited.  Think of a software UI and workflow redesign that makes it ridiculously easy for your target end users to achieve their goals within your product, or a release of a new product with new and highly visible features.

It’s not as easy to get a team psyched and energized on highly strategic projects which, when done perfectly, has no visible manifestation whatsoever (except in subtle ways, such as improved performance of a software application, or a reduced incidence of rare catastrophic failures).  Think of architecture work, refactoring, server architecture rework for hosted applications, cost reduction exercises for existing products and so forth.  These sorts of projects are like plumbing: nobody notices the work if it is done right.

There are many ways to rally a team.  A steady stream of ongoing feedback and encouragement is a must.  Small victories should be celebrated as they come up.  I make sure my team is well fed if they have to work weird hours in support of some big initiative.  I like a little champagne to celebrate major milestones.  A private word of thanks and some token of appreciation is always appropriate as well.  But a much bigger part of it is public recognition of a job well done.

For jazzy projects, this is easy: everybody can see the end results and the quality and speed of execution of the work is self-evident.  For plumbing projects,  it’s much harder: even senior management often misses the magnitude of the achievement.  One could have a team toil for months on a huge project with everyone else scratching their heads on what this team achieved with all those man-hours.

In these cases, it is imperative that we explicitly call attention to the speed of execution and the quantity and quality of the work done by the team in a public manner, and make sure the team is recognized for excellence in execution.  We simply have to work harder to frame the achievement in a way that is immediately understandable by people outside the fray, so they can appreciate and applaud the contribution that the team made to the cause.

Conflict of interest

I recently ran into a conflict of interest scenario in two separate situations.

Situation 1 had product management pitched against engineering. Product management wanted to get more bug fixes into the next release. Engineering wanted to stop changing the code so SQA could actually finish what they were doing.  The issue? I was filling in for the product manager while serving as the head of engineering.   In the end, the conservative voice of engineering won, simply because we didn’t have the resources to run yet another full set of regression tests on a new deployment.  But I am not sure the best decision was made about the stuff we left out this go-around – maybe I could have made it work if someone else was there to push back on my decision.

Situation 2 had development pitched against SQA.  Development wanted to get a beta release out for field testing sooner than later, to hit an externally imposed deadline. SQA thought it was absurd, as the beta release hasn’t  been put through its paces in beta testing.   The issue? I was filling in for both development AND SQA.  I wrote the code myself and badly wanted to see it exercised in the field.   I ended up ceding the release decision to Sales (with predictable results – the beta release is now in field testing.)  In hindsight, I pretty much made the de-facto decision to release the beta build myself.  No sales organization I know would turn down a demo build with new features, as long as it looked like it worked at least once.   Just thinking about this makes me cringe.

My key takeaway is that no matter how short staffed we get, it is absolute lunacy to have the same person fill roles which are meant to check on each other.  It’s a recipe for bad decision making.  Better to let deliverables slide out in time than give up on the healthy tension that helps ensure a high quality of output.

I’m OK with the first decision, but I feel nauseous each time I think about the second. I hope to God that Murphy’s Law is kind to me just this once, and that nothing bad happens with my horrifically under-tested beta release.

“We’re not curing cancer here”

Apologies to those of you who ARE curing cancer – more power to you! I only wish I can get to work in your field!

I picked this title for my post because those exact words came out of my mouth 3 days in a row.  The context was to help add a bit of perspective.

In an intense work environment, it’s all too easy to get wrapped up over the crisis du jour.   Everybody lives and breathes those issues continuously.   We wake in the middle of the night obsessing about stuff.  We work so late we miss putting our children to bed.   We start going to pieces physically and mentally after a period of continuous obsession.  We burn out.  Yet is this particular crisis worth the cost, knowing there are 6 more crises like that right on its heels?

If one only takes a step back and looks at the situation, 99% of the time the perceived crisis is really not a life and death issue that must be resolved either that day, or on a compressed schedule that requires superhuman stamina and 16 hour work days for 5 weeks for the entire team.

We aren’t curing cancer here, or bringing clean water to all the children in developing countries, or bringing about world peace. It really isn’t important enough to risk burning out.  Once you do burn yourself out, it takes a very long time to undo the damage, if it can be done at all.

Don’t get me wrong – anyone who knows me knows that I am a complete nut regarding sticking to my commitments and being accountable for my deliverables.   I expect the same of people I work with.  But one must apply judgement to what one should promise to deliver, and by when. Most of the time, it’s best to diagnose a situation, then come up calmly with a mitigation plan that contemplates human limits when projecting a target due date for associated deliverables.

I believe in keeping the work load at an intense but sustainable level, so that we have reserves to draw on when that real crisis does appear (e.g. if our servers come down, cutting access to all our customers).  We must learn to breathe a little the rest of the time, or we wouldn’t be in top shape to act effectively when a real need arises.

Work hard and play hard

A few months ago I wrote a post on cultivating a sense of community in the workplace.  I talked about the importance of socialization in a team.

This is easy to understand in the abstract but hard to get right in real life.  How do you balance productivity against community building?

Here are some signs the company is spending too much time on mandatory socialization.

• Everyone in the company is required to spend over 4h each week on mandatory, company-wide events designed to “facilitate communication” or “build morale”. That is 50% of one (mythical) work day (and 10% of your potential utilization).
• Organizers of these events do not consult others relative to the timing of these events, and push forward in the face of deadlines and milestones.
• It has become socially unacceptable to miss “optional” events, even if folks can’t absorb the lost time (and then they have to put in nights and weekends to make it up).

As Dilbertian as it sounds, a company exists to maximize shareholder value, not to serve as a social hangout.  An environment that favors “fun” (real or contrived) over hard commitments and important deliverables is in questionable territory.

That said, companies can easily err on the side of all work and no play.  Some signs that a company is doing a terrible job with its culture:

• You feel a chill in your bones each time you enter the building.  The chill stays with you throughout your workday (regardless of the state of the HVAC system).
• You can’t name the significant other of a single coworker (and most of them are in a relationship).
• You actually don’t know who’s in a relationship (and you’ve worked with the same people for 5 years).
• You feel intensely uncomfortable at company picnics where you need to mingle with coworkers.

Getting the right balance between work and play is tricky.  The best that we can do is to strive for a good balance most of the time.