It’s all about Compensation…

Compensation is not the only reason for employee’s motivation but improper and random Compensation Policy is often the biggest reason for employee’s dissatisfaction.

When we ask someone, does your organization value the people who really contribute towards “Achieving Organization Goals”? ; Most often answer is “Yes, We do. We have Pay for Performance Compensation system in the place”.

A Pay for Performance Compensation System is a fashionable thing to have.  It is important to remember that, It’s not about having a system in place but how system is getting executed, it’s about adoption by the people (Is it really open for feedback ? ).

Nothing is perfect, but a compensation process should be a system for the people and by the people.  Parameters used as decision variables in implementing Pay-for-Performance (P4P) affect employees motivation and are therefore very important.

Three critical decision variables in this process include:

• Individual Performance: It’s a key decision variable from which the whole “P4P” system is derived. Contributors will we rewarded and it really motivates the individual. While it’s great to have criteria specified, many times individual criteria can kill the “Team-Sprit”.  Human nature to perform better than others for better rewards can be a dangerous thing for team goals. Often it is the collective goal that is critical to the organization. It doesn’t mean we should not have individual criteria, but expanding its scope (read Team Performance) can help resolve the conflicts it creates
• Team Performance:  Addition of “Team Performance” as a decision variable with “Individual Performance” is the best way to convey that “we need to deliver as a team”. Proper guidelines on team size, scope of work and qualifying criteria should be published to make this decision variable clear and avoid unnecessary debate.
• Company Performance: If your organization is doing well, it can decide to share its happiness with its employees too. Most companies make sure to include a component of company performance into the mix.

Compensation (salary revision, bonus payout    etc) depends on budget, and the above three parameters should be factored into how the budget is allocated.  Using a combination of the above three factors, added to clear communication strategy will result in improved satisfaction.

The above three guidelines are “Context-Independent” Pay-for-Performance  factors but “Forced Parameters” cannot be ignored while talking about any compensation system; so let’s talk about these “Forced Parameters” and their influence on the P4P process in next post.

Stay Tuned…

The net worth of your network

Social currency, in spite of the word social in there, is not online presence. It is simply the power of one’s network – online or offline. It did not have a fancy name, but was recognized since my grandfather’s days as:

• People who you don’t know have the power to shape your future. Get to know them, and be known by them.
• Build a supportive community around you of people you like, and who like you.
• People who know of you, don’t always know you. Share who you are, what you have done, and what you want to do. It will help them know and help you.
• Learn that building relationships starts with small meaningful encounters that go well, and leave a positive impression.
• Help others. Your good karma will come back to you when you least expect it.

Question: In today’s world of interconnected, geographically removed people, is this possible without an online presence?

When trend lines fail

When you work in technology, and are inclined to study disruption, you will begin to realize that it is easy to be mislead by trend lines.

Trend lines work great for markets that are steady and predictable.

They tend to be less than great, for markets in transition or experiencing new external market forces.

I’m not suggesting that we should avoid analytics and trends, I’m just saying that we need to be careful that we are not investing in fantastic buggy whips (or carriages if you are feeling pedantic).

I see real change coming in the world of HR Technology.  A shift from systems build to benefit HR, to systems built to maximize business results (of the people, by the people and for the people).

I am not the only one who is starting to sense this shift (examples: here and here).  As we watch the market for HR Technology and Business systems, I strongly recommend we keep our eye on the ball — things are getting truly interesting in our world.

Time to be a leader not a follower, but if you must be a follower,  be sure you are following the right people.

More focused, less busy

You and I know that one of the things that defines me as a leader is my focus on the goal.  I am relentless when I get my mind set on making something happen.

and yet, even I have times where I find myself being more busy than productive.

Busy is a state that is becoming my norm.   Busy is rarely a productive state for me.

Ironically, I do not love the opposite of busy either.  That, for me, tends to be boredom which is not my thing.

So as I contemplate busy vs. focus I realize that the important piece for me is what I am busy doing and how I apply my focus to a useful and important goal.

Lately, I’ve been a bit out of balance in this area, and the result is not bringing forward the best of me.  I have not been working from a position of strength.   I have been surviving on [figurative] muscle and not winning by working smart.

I have decided to give myself a personal goal to skip the busy and bring on the focus.  In order to do this I will need to be better at deciding, what I do and what I let go.

While I have a demanding job, and I need to deliver, it is my job to set the priorities.  Being too busy to think, is not being the best I can, for my job or my life.  I refuse to settle.

My new approach is to be more focused and less busy.  I am taking back control and I am going to make great things happen.

Stay tuned.

Technical Leadership – Impacting The Customer Experience

In Technical Leadership – An Introduction, I talk about how growth is associated with doing different things, and not necessarily doing more. The first change is the transformation into an independent problem solver. The second change involves learning to focus on how rather than what  we do. The next transitions are all about expanding one’s circles of impact. This post is about growing to make a positive impact on the overall customer experience.

Improved customer experience could be a reduction in support calls; it could be reducing turnaround on support calls, say by reduction in escalation rates; it could be helping sell to a key account by figuring out ways to stretch the product to meet their needs; it could be understanding a customer requirement, and helping the development team design an enhancement to the product; it could be improving testability to ensure better release cadence; it could be many other things.

This transition involves a shift in one’s focus. We are no longer just eliminating our pain. We now understand how our actions affect the overall customer experience. We then try to eliminate their pain.

There are three things that directly affect our ability to make this transition.

• Networking: It is important that we expand our circle of impact to other functional groups. The more people we impact, the more access we have to information that opens opportunities for us to make a bigger impact. It is a positive feedback cycle that builds upon itself. It also requires a lot of time, work, initiative, and genuine empathy. Don’t pack your day with todo tasks, and expect to achieve this just by ‘meaning well’. We may luck out a few times, but without doing this deliberately, we will eventually hit a ceiling.
• Mentoring: As Meg rightly points out,  mentoring and growing others is important in every transition. It is crucial to this transition. Failure to do this will forever cast us as the expert in whatever pain relief we brought in the past. Every time there is a similar pain, management will reach out to us, leaving no bandwidth for us to make the next transition. We will get ample kudos, but no time to network, and no growth. If  you are in a growing business, expect that there will be more to do each day, and you may need more than one successor.
• Win the team:  Often, we forget the very key role our peers play in our successes. It is key that they look to us for a solution for whatever problem we are trying to solve. We can never know everything, and will need their support. No matter how clearly management makes anything our charter, if the team does not buy it, they won’t support it, and we will fail. On the other hand, the team will readily share and collaborate if they know, trust, and respect us.  This is generally not so much an issue for someone who has grown through the ranks, and made the leadership transition in the current team. However, this is important for someone hired to specifically make impact at this level. A newbie is an outsider, not trusted fully, and certainly not considered a leader. It is important for the newbie to first win the respect of the team. It is really hard to do this without stepping on landmines, and this is the reason that new leaders, who have been very successful in their previous job, often fail in their new job.

Hope you find this series useful. Look forward to your comments, and stay tuned for the next in the series.

Whose job is it to tell you that you are wrong?

I’m not sure if I’ve ever read this advice before, probably did, so please let me know if I need to add attribution.

You should put someone on your team who will watch for (and tell you) when you are wrong.

Seriously.

Make them a direct and make it clear it’s their job.  Teach them how to tell you in a way that you can hear (not in a McLaughlin way)

You need this badly.

As a senior leader, I am often wrong.

The key is to make sure my wrongness doesn’t do serious damage.  This is where having  a safety net, in the form of a person, is so helpful.

As a technical leader I tend to make this role an architect responsibility.  Someone who not only helps watch my back, but can also  answer all my confused questions to work out the right path with confidence.

I have been so lucky to have people willing to take on this role for me.  I would have made so many more mistakes without them.  As luck would have it, those who have played the role somehow work out that it is a good idea to tell me I’m right once in awhile, just to keep me happy.

I am blessed.

Who, do you have watching your back?   Have you given them the charter to tell you when you are wrong?  Hurry and add that to their job description, I promise you will be glad you did!

Technical Leadership – The Leadership Transition

In Technical Leadership – An Introduction, I talk about how growth is associated with doing different things, and not necessarily doing more. The first change is the transformation into an independent problem solver. The next transition, I call the leadership transition

As we negotiate this next transition, we often get vague advice, such as “be a leader”, or “work smarter, not harder” that leave us intimidated, rather than inspired.  In plain words, this next transition is from solving problems to improving how we solve problems. It involves discovering, prioritizing, and mitigating pain points – specifically those encountered by us and our peers. This is when we don’t just do work, but focus on how it is done, and then go on to make it better.

A few of us make this transition just by chance. A few us find good role models and mentors who lead us through this change. Unfortunately, many of us are not so lucky. We either don’t know how to create the opportunity to work at this level, and end up blaming circumstances and lack of opportunity, or worse, we mess it up by trying to do something too big too soon. When we do the latter, we trip over, and get a reputation among peers of talking without knowing. It very much harms our chances of making the transition later on.

So, what is one to do?

A good approach is to start working on small improvements that we know we would want to use ourselves, and do it in stolen time (time spent over weekends, or time gained otherwise). We provide our work to others, but do not require or expect others to uptake. As we observe what resonates well with others, we become aware of pain points that we as a team feel vs. those that we as individuals feel. We then are able to get management buy-in for real time (our own, and sometimes in form of help from others) that can be spent on these activities.

It is also important to continue to work on different types of problems. The pain points can differ depending on the nature of work, and having that 360° view helps us prioritize what we can work on to have the most impact.  Should we, as a team, focus first on more modular code, on that merge tool that will do automatic bug updates, or on that diagnostic tool that will help us get all the information for a customer case in one shot?

As we address their pain points, we gain the respect and trust of our peers. We establish ourselves as leaders. It is very important to measure our success at this stage by the impact we make on our peers (including those in other functional teams like QA and support) – and by that alone. The real consumers for our work are our peers, and if we do not make a difference that can be felt by them, we are not adding real value. Moreover, their trust and support is key to the next transitions. Stay tuned for more on that.

Confession of a cascading goal hater

Ok, of course I’m not really a hater… more of a dis-liker…but there aren’t t-shirts for that.

The truth is I really don’t like cascading goals, which is very odd as, I love goal alignment.

I feel an explanation might be in order.

As you all know I’m all about ownership and personal accountability in the professional world.  We own our careers and we should also own the goals we set for ourselves and our teams.

Too often I see people wringing their hands about how hard it is to align to the goals that are cascaded to them.  They are not sure how their group can impact “shareholder value” and they are pretty sure that a goal about shareholder value might not be anywhere near as important as a goal to get their job done well.

Cognitive dissonance ensues and instead of line of sight, organizations find themselves with lines of confusion.

This is where I think the answer lies not in waiting but in doing.  I do not think it is the job of your boss to work this out for you, especially if you are in any kind of leadership position.  I think it is your job to bridge the divide.   Here is how I think you should address goal setting for yourself and your team.

First, get a plan..

Figure out what is important for you and your team.  Work out what you think the most important things are and jot down the ideas as notes.   Organize them and prioritize them.

Then, look for the alignment opportunities..

Look at how what you want to do might impact your boss.  See if you can identify anything you should be doing that would better support your bosses career.  Take a moment to determine what you think her objectives might be and see how what you want your team to do might support those goals.

Now, here comes the powerful part… have a conversation.

Sit down with your boss with your notes and ideas.  Discuss how you think the goals you want to work on align with what she needs to achieve.   Take a moment to be sure you know her aspirations and her objectives.

The alignment comes, not from the system but from the shared purpose.  Get aligned on purpose and the goal setting gets so much easier.

Quit using goal cascading as a reason to get stuck… use it as a way to stand out.  Jump in with both feet and own the process.

It will be harder.

It will take longer, and you will actually achieve something as a result.

Participate in the HR Systems Survey

Thanks to SystematicHR for reminding me that CedarCrestone is conducting their annual HR Systems Survey. This is a terrific survey that adds a lot to the understanding of trends in the industry. As they state:

The survey collects responses from HR and IT management and business leaders with knowledge of the HR technologies in use and planned. CedarCrestone invites representatives from organizations with over 300 employees to participate. Responses will be kept confidential and only used in aggregate results.

Go check it out and participate if you qualify. In addition, SystematicHR also pointed out that the Bill Kutik Radio Show had an episode a few weeks back where Lexy discussed a lot of interesting facts about the survey.

Technical Leadership – The First Transition

In Technical Leadership – An Introduction, I claim that real growth involves changing what we do. This post is about the first change.

We join the workforce as interns or college recruits with limited work experience. We are eager to learn, and to work hard, but need to be told exactly what to do, and, at some level, how to do it. Oh, we are expected to have some basic skills, and even some self learning skills. However, we do need a lot of guidance. We need training programs, pointers to documents and books, and someone overseeing the results of our work.

The first transition is from ability to work on well defined, simple problems with help to solving loosely defined, complex problems with more independence.

The most common error as we make this transition is not knowing when to ask for help, and when not to. We know that in order to make this transition, we must first show that we can address the current well defined problems with little outside help. In an effort to show this, we end up not asking for help at all. The result is that we sometimes take inordinately long time to do what could have been done very simply. When this happens growth opportunities come slower.

On the other hand, asking for help for everything, can leave our colleagues frustrated, and become career limiting.

So, what is one to do?

A good approach is to take every opportunity to succinctly talk about what we are doing – at the manager staff meeting, at the water cooler, at lunch with friends and colleagues. By sharing what we are trying to figure out, and how we are approaching the problem, we give our colleagues the opportunity to give us those pointers – to docs, training, and other resources – that can help us achieve our goals faster, and demonstrate growth potential.

Often, developers associate this transition with going from bug fixing to writing features. It is not. A simple, well defined problem may be a bug, but it is a certain type of bug. [A hello world (or such) program is also a well defined, simple problem - though of little use to a typical workplace.] Working on a race condition bug, on the other hand, is a loosely defined, complex problem that is worthy of a senior developer who has successfully made this transition. In fact, the most complex issues are often issues with code already written and in use by customers. The live customers add some very interesting complexity to any problem

In order to make the next transformation, one needs to work on different types of loosely defined and complex problems – difficult bugs, customer escalations, feature development, tool development, etc. – but that is a topic for the next post