Learning From Bad And Good Managers Of My Past

May 21, 2012 Leave a comment


A recent Management Essentials training session at work encouraged us to reflect on our experiences rather than just gave us a bunch of management tips out of context.  I have always learned a lot by observing others and I have long said that even less than stellar managers shaped who I am today. One of the exercises was to reflect on our past managers and list what made them either good or bad. In nearly 16 years, I have had 12 past managers, only two of whom I considered as great managers. When I examined the “great” and the “bad” lists, I noticed that they were very similar – the characteristics were often opposites of each other.  Looking at the two lists, there were four points that defined the difference between the good and bad managers of my past:

1. Communication

There is a reason why every management resource tells us that communication is the key to everything.  The relationship with your manager is personal and communication is how that relationship evolves.  All but a few managers at the bottom of my list were able to establish comfortable two-way communications with me.  I easily adapted my communications to them and they did the same for me.  At important moments, the best were able show me they heard and understood my point of view and then gave me the information I needed.  It was their ability to show me that they understood me first that made it easier to accept the information that followed.  Without it, I would have felt I was following orders that didn’t fit my context.  The managers at the bottom of my list consistently practiced one-way communication, unable or unwilling to even hear what I had to say, no matter how I adapted my messages.  I was failing to customize my communications for them, but they also failed to meet me part way.

2. Straight-forward honesty

One manager once confessed to me that he had worried I would not accept the job after he told me about all the challenges with the department.  I laughed and told him that his honesty was what sold me on the job.  No one likes being lied to.  It undermines trust and it is hard to consider someone a great manager if you can’t trust them.  Honesty sometimes stings, but it’s certainly better than the alternatives.

3. Trust

Trust also needs to be two-way.  Managers who did a half-decent job with communication and honesty earned my trust.  At the same time, if I was doing a half-decent job with communication and honesty, I expected to be trusted. This was the case for most of my past managers.  However, some managers did not inherently do that, straining the relationship.  Unfortunately, these were often the same relationships where communication and honesty were a struggle.

4. Comfortable in their current role

This one is complex because it manifests itself in many ways.  All my managers had their own ambitions.  The best of them, though, were comfortable and secure in their current role, knowing that their performance in the present would lead to the next opportunity. Others were more focussed on their future goals rather than make the best decisions for the here and now.  In some cases, their preoccupation with their ambitions affected their ability to handle management politics and made their personal insecurities show.

What about the managers in your past?  What characteristics have separated from the great ones from the dismal ones?  Please share your thoughts in the comments.

Related Articles

The Realities Of Being A Manager

The Rewards Of Being A Manager

An Ode To the Bad Managers Of My Past (Ask A Manager)

Managing or Leading. Who Cares? Let’s do Both. (lenbrzozowski.wordpress.com)

Enhanced by Zemanta

Filed under Leadership Tagged with , , , , , ,

Stop Pushing All The Rocks Uphill. Focus!

May 13, 2012 Leave a comment


Have you ever felt that your to-do list was longer than what you can possibly get done?  Or your product had a ton of features that need to be developed but it still needs to be shipped way too soon?   We often respond to this pressure by trying to do more, often at the same time.  However, that is not the right thing to do in this situation.  By trying to do everything at once, the result is lack of focus, which will affect your performance, the performance of your team and the quality of the product.  Whenever you find yourself in this situation, it may help to think of this analogy, which I picked up from another manager and often share with my own teams.

Successfully completing a project, building a product or running a business can be compared to pushing a pile of rocks up a hill:

Product backlog

The rocks can be viewed as product features, tasks that need to be done or even decisions that need to be made. They are different sizes, but they all take effort to move them all the way up the hill or to get the features/tasks/decisions DONE.

If we try to push all the rocks at once (i.e. do many things at the same time), the results will usually look like this:

Doing too much at once results in incomplete features

One or two rocks will make it all the way up the hill.  Those are the features or tasks that get completely done and meet the expected quality.  The others… didn’t quite make it.  These are the features that don’t quite work as expected or may have problems.  It could also be the work that was done quickly and comes back to bite you later. Shipping a product with incomplete features will be noticed by your customers.  Meanwhile, you and your team have been stressed out for days, weeks or even months trying to get all that work done at once.  It’s just not worth it!

Instead, if we focus, prioritize that list and move each rock up the hill one at a time, we are much more likely to get this result:

Focus and prioritization gets more things done

It takes patience to focus on one rock at a time and to get it DONE before moving on to the next one.  With focus it takes less time to finish each one.  If it’s a product, it means the most important features are done first at the expected quality level.  In both scenarios, there are still things left undone, but if you prioritized well then these are the least important.  The most important items are done and done well.

This principle is behind two key points in Scrum.  By rigorously prioritizing the backlog as each feature is completed, the team is always focussed on building the most important features first.  In addition, the team does not move on to a new feature until the first one is completely done and meets the expected quality level.  That includes testing and documentation, not just being code complete.  It is really tempting to get many features mostly completed and take care of the less fun work later.  It is also really tempting to work on items that are most interesting to the developers, for whatever reason.  Priorities must always be based on return on investment – the most important to the business with, ideally, the least cost or risk to develop.

So, next time you are tempted to push all the rocks up the hill at the same time, stop and prioritize.  It will make a big difference to everyone.

What are some ways you can apply this analogy in your own context?  Please share your thoughts in the comments.

Related articles
Enhanced by Zemanta

Filed under Leadership Tagged with , , , , , , ,

How Scrum Can Improve Team Productivity

May 6, 2012 3 Comments


When converting to Scrum or other Agile techniques, managers often wonder whether it will really improve productivity.  The whole process seems chaotic, so how can teams be more productive than traditional project management and development practices?

This is the story of three teams in the same department and how we were able to measure their productivity during their first year of using Scrum.  The data comes from the teams’ burn-down charts with work and capacity estimates using Ideal Days.  The charts use 3-month rolling averages to more clearly show the trends.  80% productivity would be the ideal target.

Balancing Development and Support

Productivity of a stable team committed to scrum

The first team had to balance both development and support.  Approximately every six weeks, their main client had to deliver milestone builds to the end client and the crunch on that project often meant even more support.  At the start of their first sprint, the team was skeptical, but they committed to giving Scrum a try.  They noticed the improvement immediately and never looked back.   Of the three teams, they were the most diligent in applying the practices of Scrum, but it was still very difficult to predict their support work.  As you can see from the chart, there was still a big gap between the work they initially committed and what they delivered.  They kept track of their support work, did thorough retrospectives after each sprint, partnered closely with their clients and put in a lot of effort to stabilize and improve their product.  After about three months, the work paid off and their productivity started to climb.  Soon they were consistently meeting or exceeding their commitments and their clients were happier with the product and support service.  The drop-off at the end was due to the team being restructured as their client entered a different phase of development.  If they had continued, I think they would have improved their productivity to more than 70%.

Blue Sky Goals

Productivity of a team excelling at Scrum

The second team was the most enthusiastic from the start.  They still had to do support, but their product was more stable and their main client was a smaller team, so it was easier to predict and budget support work.  In addition, 2 of the 5 programmers were expecting babies in August and would be taking six weeks of paternity leave at the same time the others were planning short vacations.  Nothing like the impending arrival of babies to motivate a team to improve their productivity.  It also helped motivate the client to set priorities.  Vacations can be negotiated, but babies were coming whether we liked it or not.  Like with the first team, this team also tracked their support work, did thorough retrospectives and partnered closely with their client, resulting in steadily climbing productivity.  As they started meeting their commitments, they started challenging themselves by committing a little more each sprint.  I insisted they not commit more than 80% of their capacity, so they started setting “Blue Sky” goals.  These goals were tackled only if their regularly committed work got done.  Once they started reaching their Blue Sky goals, I let them commit more than 80% of their capacity.  After their paternity leaves, though, the new dads were tired, so they stabilized back at around 80%.

The Pressure To Commit More 

Productivity of a Scrum Team That Over Commits

The last team to adopt Scrum was under tremendous pressure to make up for lost time.  The team was formed in January after the previous team responsible for the product had either quit or moved to one of the other teams.  Their product was way behind schedule and it was having a major effect on their client.  It took about three more months for the team to ramp up, get familiar with the technology and each other.  They were committed to applying Scrum practices, learned from the other two teams and had a lot of early success.  However, their client continued to pressure them to deliver even more.  Although, I insisted it was better they stay conservative and over deliver, they started committing more and more of their capacity, even committing more than 100% for three sprints.  As a result, they started missing commitments.  Between the pressure and their inability to predictably deliver, the team’s morale started to drop, affecting their productivity.  In the end, we split the team, with half seated in an isolated location, focusing on the new features and the other half supporting and evolving what already worked.

The Verdict

Scrum can improve your team’s productivity.  They need to take the time to think about what they need to do, pay attention to how their time is spent, learn from their successes and failures and be realistic about their commitments.  Also, having a couple of babies on the way doesn’t hurt either!

Related Articles

Visual Project Planning

Best Scrum-ban-plan Board Ever!

Taking An Agile Project To The Next Level

My Agile Journey

Filed under Process Tagged with , , , , , ,

How Do We Solve The Women In Tech Leadership Problem?

April 22, 2012 2 Comments


Before our attention was diverted with the blockbuster acquisition of Instagram, Facebook recently caught media attention for not adding any women to its board of directors.  As a result, the women in technology leadership problem has been a hot topic around the blogosphere, which I read with avid interest.

Being a former engineer, I am used to working and leading in male-dominated companies.  There were always some women in my working circles, so I did not notice a huge gender imbalance and never really gave it much thought.  However, for the first time in my career I am working with a large team that has less than 15% women.  Now I am noticing the difference.  We would hire more women… if we found them on LinkedIn or they applied.  There are just not that many women with the skills we need.

The following blog posts were the first that caught my attention:

I enjoyed @skirtsocial’s point of view in the second article: it is not that women are not interested in technology leadership careers, we are just particular about where we choose to get involved.  Her article was sparked by The Tech Ceiling (The Daily) and also references The Men and No Women of Web 2.0 Boards (All Things D, Dec 2010) and Where Are the Women Executives in Silicon Valley? (NY Times Bits, Dec 2011).  They are all worth reading.

I applaud the first article mostly because of the blog on where I found it: a middle school parent’s blog.  If we are going to encourage young women to not think about gender roles when deciding on a career, that’s where it starts.  Marissa Mayer’s story is also a great one to share because where she ended up is not where she had planned when she started university, which is something that happens to most of us but most students don’t know.  It’s worth reading the full article, originally published on the Huffington Post: Google Exec Marissa Mayer Explains Why There Aren’t More Girl Geeks.

At the same time, Dan Rockwell on Leadership Freak wrote an interesting series on the differences between women and men in leadership roles.  While Facebook attracted attention to the technology sector, the gender imbalance in leadership roles is not just there.  Getting women interested in technology is only one challenge.  An even greater challenge is women rising to the top seats in any corporation.  The discussion on these posts is fascinating:

As I wrote in my own recent reflection on my career, the women in tech leadership problem is complex.  There are no simple solutions.  All of us in industry, both men and women, need to get involved.  We all need to be role models.  Girls also look up to their fathers, brothers, uncles, teachers and mentors and can choose to be just like them.  We also need to help our school systems.  Our impressions of career choices start in school and many teachers and guidance councillors have a limited view on the possibilities.  I agree with @skirtsocial: how and where women choose to get involved will be our choice, but we should be excited about how many possibilities we have.

What are your thoughts on how we solve the women in technology leadership problem?  Please share your thoughts and experiences in the comments.

Enhanced by Zemanta

Filed under Coaching Tagged with , , ,

How To Ask Your Manager For Help

April 8, 2012 Leave a comment


Superheroes in Transit

Superheroes in Transit (Photo credit: jmv)

Have you ever found yourself in a “can’t win” situation at work?  You are working hard, doing your best, but yet things still seem to be going wrong.  What do you do?  Be a superhero and try to fix it yourself?  Or do you reach out and ask for help?

Contrary to popular belief, asking your manager for help is not a sign of weakness or failure.  Some situations do need to be escalated to management to help resolve.  When done well, escalation can actually earn you more respect from your manager and your peers.  It is certainly better than failing because the first thing you will be asked is why you didn’t ask for help.  Here are some tips to escalate effectively.

1. Do your part first.

No matter the situation, make sure you have done your part first.  If the issue is with another employee, department, or company, make sure you have tried to resolve the issue directly with the people involved.  As a manager, the first question I always ask is: “Have you talked with them directly?”  Escalating to your manager before trying to resolve the issue directly will hurt your reputation. Make a list of the steps you have taken and have it with you when you go talk to your manager.

2. Be concise.

Unless you have a particularly close relationship with your manager, resist the urge to rant, vent or blame.  Just briefly explain the situation and the steps you have taken to do your part.  Keep your voice and words as neutral as possible.  One caveat:  you still need to convey a sense of importance and urgency, otherwise your manager may not realize that help really is needed.  Conveying this, though, should not involve excessive emotion.

3. Be specific.

“Here is where I need your help…” What follows needs to be thought out.  Think about what your manager’s responsibilities really are.  Do you need him to talk to his counterpart in the other department to help get things moving?  Did she make that contract with the outsourcer that is not delivering?  Then you’ll need her help addressing the problem with the other company’s management.  You get the idea.  Just dumping the problem on your manager and not being specific and thoughtful about where you need help will result in no action.

4. If you’re offered help, take it!

If the situation has been going on for awhile, a good manager will notice and probably ask about it.  If you are offered help, consider yourself lucky and take it.  If you haven’t had a chance to think about how your manager can help, it is fair to ask what they had in mind or to respond with: “Thank you for the offer.  I will take you up on it.  I just need to think about how you can best help and will get back to you.”

When you’re in the middle of the situation, your first instinct will be to solve the problem by yourself.  Learn to identify where the line is and ask for help when needed.  If your extra effort is obscuring the fact that someone is not delivering their part, then you’re going too far.  There is a difference between being a team player and doing someone else’s job.  Often, people don’t have faith that their manager will actually help.  However, if you don’t ask, you are guaranteed that result.

How have you escalated an issue and what were the results (either good or bad)?  What did you learn from the experience?  Share your thoughts and experiences in the comments.

Related articles
Enhanced by Zemanta

Filed under Coaching Tagged with , , ,

← Older posts

Follow

Get every new post delivered to your Inbox.

Join 576 other followers