Tag: management

  • On Communicating

    6. Prepare your intent.

    A little preparation goes a long way toward saying what you wanted to say and having a conversation achieve its intended impact. Don’t prepare a speech; develop an understanding of what the focus of a conversation needs to be (in order for people to hear the message) and how you will accomplish this. Your communication will be more persuasive and on point when you prepare your intent ahead of time.

    2. Talk so people will listen.

    Great communicators read their audience (groups and individuals) carefully to ensure they aren’t wasting their breath on a message that people aren’t ready to hear. Talking so people will listen means you adjust your message on the fly to stay with your audience (what they’re ready to hear and how they’re ready to hear it). Droning on to ensure you’ve said what you wanted to say does not have the same effect on people as engaging them in a meaningful dialogue in which there is an exchange of ideas. Resist the urge to drive your point home at all costs. When your talking leads to people asking good questions, you know you’re on the right track.

    – Travis Bradberry, 8 Secrets of Great Communicators

  • Management and Practice

    The dog days of summer continue. I’d like to say that this gives me lots of time for careful reflection and reading but that hasn’t been the case. Fortunately, there’s no shortage of good material this week.

    First, the Wall Street Journal talked to Henry “Managers not MBAs” Mintzberg to find out What Managers Really Do. Mintzberg looks at how managers handle interruptions, and discusses three ways that managers can create results.

    In a similar vein, Michael Loop has an old-but-good article on how to move a software project from crisis to cruise. Read how he runs his staff meeting – I’m going to give this a try this week.

    Finally, I just finished reading “Talent is Overrated” by Geoff Colvin. Excellent book, despite being blurbed by Noel Tichy. (Note to author: don’t get blurbs from narcissists. Especially those who you interviewed in the book. Looks desperate.). Colvin’s description of deliberate practice reminded me of something I read last year that explained what business leaders can learn from how elite athletes train and improve.

    And so what, according to Colvin and Graham Jones, was the secret to exceptional performance? Here’s a hint:

  • Getting a New Team to do Cool Stuff

    When I took on my current job I was given an established product team and a mostly-new engineering team. We also had a brand new engineering manager, QA manager, and program manager working with us.

    Our job was to launch an all-new version of Toolbar while we maintained our existing versions and continued to support new corporate partners. Engineering and QA had just been moved overseas. We didn’t have any well-defined processes in place to build and maintain software. Without a clear process, or “rules of working” that described how individuals would be accountable within that process – the first few months were difficult. We struggled to prioritize current bugs against future features, and to support our existing partners while we tried to create a foundation for a new kind of partner business.

    The team leads and I spent a lot of time trying to setup, execute, and debug a product development process that worked for us. In the first few weeks I spent most of my time figuring out where our strengths and weaknesses were. Being a product guy with an engineering background I focused on finding the holes in our product and technology: features we were missing, things that didn’t quite work, where our technology worked well and where it was a smelly mess, and so on.Over a period of weeks we began to tighten up our product definition, and to understand, prioritize, and fix some of our deep rooted engineering and process problems.

    We were pretty effective, and shipped a version that was mostly well received. But I felt that the “re-launch” of the new team didn’t go as smoothly as it could have. Our team and process hadn’t been fully formed, and I didn’t have a good model to determine what to fix first. The other managers and I used our experience and intuition to decide what to look at first; we then gathered some data and made some decisions. But I, at least, never had a complete framework in mind. I’ve since done a bit of reading on the topic and mean to sum it up here.

    Forming Storming Norming and Performing: Back in 1965 Bruce Tuckman created the Forming – Storming – Norming – Performing model of group development. In a nutshell, the stages are (borrowing from the wikipedia article):

    • forming: the team meets, learns about opportunity and challenges, and begins to tackle goals as a group
    • storming: “team addresses issues such as what problems they are really supposed to solve, how they will function independently and together and what leadership model they will accept”
    • norming: “Team members adjust their behavior to each other as they develop work habits that make teamwork seem more natural and fluid.”
    • performing: “Some teams will reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision.”

    Tuckman’s model goes on to describe why each stage is necessary, and how leaders should act in order to be most effective at each stage. Much of this is common sense, but the article is still a good read, and most “team building” training in place today seems to build on Tuckman’s work.

    The Agile Maturity Model: In his post last week Tyner Blain details an Agile Maturity Model. He outlines a “hierarchy of needs” that somewhat follows Tuckman’s example. Read it for yourself, but Blain’s six levels were:

    1. Staffing the engineering team correctly – And I would replace “engineering” with “entire team” correctly. This takes the form of managing for performance as well as re-shuffling roles and responsibilities to match skills with needs.
    2. Assuring Quality is in your team’s DNA – This was huge with us. Individually, every person on the team was committed to quality, but we had no shared understanding of what level we should be shooting for. What makes a “P3” bug a “P3?” What kind of architectural limitations can we live with, and when should we refactor? We needed to come together to answer these and other quality questions, and get us to the point where we could ship a product that we were all proud of.
    3. Reducing overhead in the release process. – Oh GOD yes. You can’t have a fast, agile team, productive team that has fun unless you’ve taken most of the drudgery and variability out of the release process.
    4. Feeding the beast. – This is what I’m currently struggling with. Once you address the first three points and begin to move faster, you find yourself constantly running out of requirements for the team to work through. One way to solve this problem is to set clear, higher-level objectives and empower the engineering team to work directly with the QA, design, and product teams to build stuff. I’m a bit of a control freak, but I think that there are big gains to be made if you can empower your team in this respect.
    5. Managing stakeholder expectations – ’nuff said
    6. Continuously learning from your markets – this is a topic that deserves a post unto itself – it is the foundation of creating wonderful products.
  • Design by Objective

    I’m a big fan of managing by objective. Wherever possible, I believe that PMs, engineers, testers and designers should begin their work by first agreeing to (or at least accepting) a list of user and business objectives that a feature or product should fulfill. This will be useful in framing the many discussions that will follow.

    This week in Why Microsoft Had to Destroy Word Peter Merholz discusses how Microsoft made some tough decisions in the design of Word 2007. He specifically talks about how Microsoft and Tivo set out “design tenets” or “design mantras” which then governed the design and implementation of key features. Worth a read.

  • Rule 2: Don’t be a victim.

    As a product manager it is tempting to blame failures on the action – or inaction – of others. This is dangerous because it allows one to avoid responsibility for the commtiments they make.

    To be a great product manager you have to be a good leader. That means holding yourself accountable. The best definition of accountability I’ve seen describes accountability as “a personal choice to rise above one’s circumstances and demonstrate the ownership necessary for achieving desired results (Connors, Smith and Hickman, ‘The Oz Principle‘).”

    When I worked on the Yahoo! home page a colleague approached me with an idea that would generate significant new revenue. So the two of us sat down to check his math and figure out how to implement it.

    It turned out that he was right, but that to implement his idea we’d need to rely on a dysfunctional team in a distant office. As a result, completing the project would require both of us to spend a lot of time doing other peoples’ jobs.

    So we started the project and began to muddle through. Soon enough, the predicted problems arose and began to slow our progress. Frustrated, I took the issue to my boss and asked for his advice. I described the problem to him and he gave me some detailed guidance. Then, we wrapped up the conversation something like this:

    “Will this make money for Yahoo!?”

    “Yes.”

    “Is it good for the user?”

    “Yes.”

    “Do you still want to do this?”

    “Yes, but it will be a huge pain in the ass to implement.”

    “Then don’t be a victim. If you really want to do this, you can – and I’ll give you all the help you need. It’s up to you.”

    And so I had my revelation.

    This project would require me to get my hands very dirty – but the business benefit was huge, and if the project succeeded I would get a lot of the credit. So I decided to commit and push it through.

    It turns out that the problems weren’t nearly as big as I originally thought. After a week or two of messy work – which consisted mostly of managing people who didn’t work for me – we got things on track and launched the feature. And it actually performed as expected, and drove a significant amount of new revenue into our business.

    Too many people fall victims to their dependencies. Victims blame others for their failures rather than taking accountablity for things that happen and trying to correct for them. Leaders take accountability for what they commit to do.

    That said, smart leaders are very careful what they commit to. You can only take on a few of these “special missions” at once and so you need to save them for the most important things. You also have to accept the fact that sometimes, the most important things will be things that you are ordered to do, not necessarily the things that you feel the need to do. When this happens, argue vigorously, accept the orders of your superiors, and plan for the “I told you so” contingency. That way, if it turns out that you were right all along, you’re still in a position to fix the underlying problem.