Browsed by
Month: August 2016

Compliments

Compliments

way to go, good job, well done, you're the man, thumbs up, you rock - a set of isolated sticky notes with positive affirmation words

 

“I think how you handled that situation was just perfect!”

 

It’s wonderful to hear how great I am. Compliments are so nice. This employee was always telling me how great that idea was or how that decision I made was the right one. He never disagreed with me or asked me questions about anything I did. When I realized that all he was giving me was positive feedback, I knew I had fallen for the seductiveness of positive feedback and compliments.

Positive feedback and compliments are seductive because there is a temptation as a manager to believe that everything I do is perfect. This can lull me into becoming a complacent manager and complacency only leads to bad outcomes. I’m human; I make mistakes. If all I hear is how great I am, I may make more mistakes instead of less because I’m not listening, not aware of bad decisions, and / or entirely missing critical data.

I’m not saying employees try to manipulate by giving me compliments. Maybe sometimes that’s true, but many times the person is just being nice. They want to hear positive feedback so they give me positive feedback. What I want is balanced feedback. I want employees to question, offer other alternatives, and yes, challenge me. I’m comfortable enough that being challenged doesn’t threaten me. It’s a good place to be.

I like compliments, however I love questions that allow me to consider things I wouldn’t otherwise. I love to see employees coming up with even better solutions or ideas than I have because they are comfortable with challenging me.

When I receive compliments at work, I very carefully consider the compliment. Sometimes, it is deserved. But other times, that compliment raises a suspicion that I might need to re-evaluate what I’ve done.

To Lead is to Let Go of Control

To Lead is to Let Go of Control

What makes a good leader? I’ve given this much thought during the years I’ve been managing. I don’t believe any person in a leadership role sets out to be a bad leader – and bad leaders, unfortunately, usually think they’re good leaders.

What exactly does “leader” mean? I looked it up and one definition is “the person who leads or commands a group, organization, or country.”* It also means “a short strip of nonfunctioning material at each end of a reel of film or recording tape for connections to a spool.” *

While some may think of their current leader as bearing a great deal of resemblance to a nonfunctioning material, I’m going with the first definition of leadership and assume we’re talking about “the action of leading a group of people or an organization.” I also looked up the word management and here’s the definition I found: “the process of dealing with or controlling things or groups of people.”*

So, in looking at these definitions, I do manage people, but I also lead people. Leading is different from managing because as a leader, my intention is to inspire, motivate and provoke a desire for excellence from a large group of people, some of whom I will never meet.

You can’t control everything.

 

It’s true, I do manage my direct staff, and managing includes controlling things like budgets, but I can’t control everything. I have to depend on my leadership skills to inspire the organization to reach its goals and do some of the work of controlling things.

For me, a good leader understands he can’t control everything in the organization; he has to trust the peopleAdobeStock_100113673-3 working for him. To achieve organizational goals, a leader needs to motivate and inspire their teams. To encourage innovation, a good leader knows he has to trust the people working for him to be creative and to think of new approaches for products, issues, or problems.

In one group I led, we had software quality issues. Not minor ones either. Some of the quality issues were because management wanted to hit certain deadlines and corners were cut. In other cases, it was bad development practices. So each vice-president had a goal for their organizations to decrease the backlog of defects as a starting place for addressing product quality.

We all decided on a certain percentage to hit and then told the teams to fix all of the high priority defects to hit that percentage. Things were going great! Most every team was on track to hit that percentage. We were slapping ourselves on the back in congratulating each other in hitting our goal.

But then I met with a developer. You see, I often do skip-level meetings with staff . These skip-level meetings often begin with some discussion on how things are going and general chit chat, but sometimes someone will say something quite stunning.

This developer, after about ten minutes of the general chit chat, paused, looked me in the eye and asked, “Why is this goal in fixing defects focused only on the high priority defects? Wouldn’t a better approach be to determine where all the defects are in the code and then tackle the code that seems so problematic?”

I was stunned. I looked at her before replying because I was thinking, duh, should have thought of that! We did meet that year’s goal of fixing a percentage of high priority defects, but the next year? We did exactly as she recommended. And the team found there were a couple of areas in the code base that needed to be reworked or refactored thereby resolving most of the software quality issues.

I learned from this experience that as a leader, I shouldn’t try to control what everyone does – and I don’t want to control every single thing. That’s not my job. My job is to trust my employees to hear what I think is an issue or problem. Then I listen to what they suggest before I make decrees. The results are often far better than I expect.

*New Oxford American Dictionary

 

Down Sides to Skip-Level Meetings

Down Sides to Skip-Level Meetings

balancing act cleaned up

In a prior post, I wrote about having skip-level meetings with team members and the benefits of doing so. Skip-level meetings mean I skip one or two management levels and meet directly with individuals on their teams. We talked about the benefits of doing skip-level meetings, now let’s talk about the down sides.

One down side to skip-level meetings is that my managers may feel like I am going around them or disrespecting their authority. Perhaps the manager is insecure in their management skills or position, or perhaps they don’t entirely trust me. Maybe both.

I acknowledge those concerns; they are valid. Having successful skip-level meetings is a delicate balance. I don’t want to disempower the manager. So I am careful when I talk with an individual they are clear on what I will – and will not do. This ensures the employee does not get mixed messages about who manages their day-to-day activities.

I will listen and consider what they are saying. I won’t take action without input from their manager.

There are delicate situations in which I have concerns about a manager. The skip-level meetings are a way for me to determine if those concerns are valid.

When there is an issue with a manager, it means I need to get more data points so that I can discuss the issue with the manager. Sometimes the issue is successfully resolved, sometimes it means parting ways. Having the manager leave is difficult but it is more difficult to keep him if he is having a negative impact on the team.

Sometimes there is an issue with an individual on the manager’s team. That’s the manager’s responsibility, and I totally step out of the manager’s way. Though I do follow up to make sure the issue is successfully resolved.

In a skip-level meeting with someone, if that individual has a suggestion or recommendation for a particular situation, a good one, I first encourage her to talk with her manager. If there is reluctance, I try to determine why because I prefer that the employee talk to her manager. At some point, I need to step away so I’m not getting in between the manager and his employee.

I’m not always successful at the stepping away part. I’m sure I’ve frustrated some of my managers when I don’t step away. Why don’t I step away? Sometimes I really want to see something changed due to a recommendation or insight from the person with whom I met. Sometimes, change needs to be encouraged. That’s when I don’t step away – when there is a reluctance to change.

The upsides to skip-level meetings out weight the downsides.

In the long run, I think the down sides to skip-level meetings are out weighed by the benefits. We are a management team and need to support each other. And skip-level meetings provide a crosscheck ensuring we are all seeing what needs to be seen as well as taking care of the issues in the organization.

Image: NL Shop. www.clipart.com/433789

Introverted Managers Do Care

Introverted Managers Do Care

I’m an introvert. There I’ve admitted it in public! It’s difficult and uncomfortable for me to talk to people at team gatherings or company meetings. Even just talking to folks that report to one of my managers or directors is hard.

Yet, I find that if I sit closed off in my office, which I prefer to give myself some peace and quiet, this results in people thinking I am aloof and distant and uncaring. I’m always surprised when people think these things of me because I DO care.

So the question is how, as a manager, do I show people I care? Well, here is my recipe for showing folks you do care.

Find ways to show you care.

First, I began scheduling skip-level meetings. Instead of meeting with someone on my direct staff, I meet with those that report to my managers or to one of their managers.

Now I should note, this practice does freak my employees out at first. They don’t understand why I am meeting with them. They don’t expect an upper level manager to take the time to meet with them so they don’t always know what to say or what is expected of them and initial meetings can feel awkward on both sides of the desk.

However, I find that when I continue to meet with staff members, they start talking to me. And this is where it gets good. Because when I start considering what they say and implement some of their ideas, a really cool dialog begins. After all, they are the ones doing the actual work and often have ideas that I could never have because I’m not on the front lines like they are.

I really enjoy these skip-level meetings. I find the people I meet are interesting and have good ideas. If you want to build trust with your staff, this is a great way to do it.

Once I have skip-level meetings in place, then I begin leaving my office door open. And when folks walk by, I say hi. If they linger, I invite them in. This promotes even more of that great dialog.

I also walk around the office. I stop and talk to people. This is really tough for me because I really am an introvert and meeting folks for the first time is scary. Out there on the office floor, I have to talk to people I might not know. Serious eek!

However, I find as I keep doing it, I get to know people and what they are working on. Best off all, the feedback from their managers are those employees really appreciate me taking the time to stop and talk. They feel like I care. And I do. Doing this builds connections for me too.

Introvert1

Why should I care whether they think I care? Everyone wants to feel valued and seen. By seen, I mean really seeing the people that are working for me; the people making the organization and me successful. They aren’t just replaceable widgets. They’re humans with hearts and lives and feelings. And I care about every single one of them.

Cascading Goals Down into an Organization

Cascading Goals Down into an Organization

When the end of the fiscal year approaches it means it’s time to create goals for the next year. At a large company, this can be challenging, as often the corporate goals are sometimes very high-level.

Frequently, I’ve seen people get very cynical about high-level company goals. Or worse yet, software developers who think the company goals have nothing to do with them personally. That’s simply not true. Everyone in the company needs to support the company goals. The work each employee does impacts those goals whether they realize it or not.

Let’s look at an example. If a company has a goal to increase revenue by 30% , how do I, as the manager, translate that into something meaningful for my development teams? I definitely want to support increasing revenue, after all, I want my company to be successful. I want my teams to be aware of this goal for the company and that what they do impacts that goal.

Let’s assume I have a software development team working on a new release of an enterprise software product. The new release will be out in spring. The question to ask is: How will this product release contribute to increasing revenue?

If the release is high-quality, customers will be happy. If it is of low quality, customers will complain and that information could impact sales to other customers. And, if the changes the team makes to the user experience truly are easy-to-use and intuitive versus not so easy to use and not intuitive, that will also impact customers and sales.

So in this example I am going to create goals for my team supporting the revenue goal using these two requirements: high-quality and easy-to-use intuitive software. The goals could be written as:

  1. Release the software with no priority 1, 2, or 3 defects. This will be measured by the number of open defects.
  2. The user interface is intuitive and easy to use. Measured by the feedback from usability studies and comparison with prior testing.
© 2008 Annette Wagner. All Rights Reserved.
©2008 Annette Wagner. All Rights Reserved.

Both of these team goals support the 30% increase in revenue goal. The next step is to translate these product goals into individual contributor goals:

  1. For each software development team member assigned to the April release, they will write unit tests and fix all p1, p2, p3 defects found by QA/QE.
  2. The software development team is required to work closely with the user experience team to create a user interface that is intuitive and easy-to-use and to support user testing needs.

By tying an individual developer’s goals into the company goals, everyone understands how they as well as their  team contribute to the company goals. This not only makes those goals meaningful and achievable, it makes the goals understandable and doable by the team members.