Month: December 2017

How managers cripple their best team members

 

If you have been in the development community long enough, you must have come across the concept of a 10X developer. This is a mythical programmer that can do ten times the work of another normal programmer in the same amount of time and with higher quality.

I say mythical because, in my opinion, only teams can perform at that level. Yet, there is no denying men and women of special ability do exist. Furthermore, they are the stuff upon which great teams are built.

Will and Ariel Durant put it as

If we knew our fellow men thoroughly we could select thirty per cent of them whose combined ability would equal that of all the rest.

Or to use one of our own heroes, Steve Jobs

A players hire A players, B players hire C players

With this factors in play, once every while, a star team forms that performs superbly well. This team is almost certainly composed of very capable individuals. Unfortunately, the teams tend not to be stable because once formed, other forces conspire to break them apart.

In this entry, we will be looking at how you can be unwittingly killing off your greatest asset, your team.

Assigning a team member to multiple teams

This is by far the most common practice I have seen. To be honest, I have done it to my team members as well.

The benefits are visible and alluring. To name a few:

  1. Some resources are very expensive and need to be shared. For example, a specialist in machine learning who we pay say 500k would not make economic sense to be housed only in a single team
  2. Knowledge of the expert gets to be shared across the entire organization
  3. They just get sh*t done!

Unfortunately, the costs are not visible.

The strange thing about the most capable people is they have the hardest time saying no. Deep within them is the craftsman integrity, if something is required of them, they will get it done. Over time they get more overworked as they shoulder the heavy burden imposed by their own competence. Being humans, some other members will loaf off tipping the dynamic into an even worse state. Eventually, you end up losing this overworked resource to another organization.

Shifting a team member across multiple functions

This kind of rotation is important for new team members who need to understand how the business works. It’s also very useful for those who need a change of role. With that said, moving employees haphazardly across the organization means they never have the gestation period necessary to properly settle into one team.

You see, we are social animals, whenever a new animal joins our pack, they immediately become the object of interest. We ask ourselves questions such as:

  1. Will they conform to how we work?
  2. What is their working style and will it affect us?
  3. How does their presence change the power dynamics?

Eventually, the team does accept the member and hopefully, they become productive.

Fail to allow for this time and you have an individual who feels they constantly have to combat the social challenges of being the newcomer instead of producing what you pay them to.

Not providing proper communication tools for remote members

I am a big fan of flexible and remote working arrangements. With that said, I still believe a team should meet often.

As referenced in problem with big teams

Peer pressure is far more effective than the concept of a boss and much more powerful

If the team members can not see each other, how will they get the time to develop the necessary social bonds for interdependence to take over?

A rule of thumb would be:

If any one team member can not make it to the physical meeting, the meeting should be conducted as if the entire team is remote

This means stop being stingy. Invest heavily in communication equipment. The payoff will definitely be worth it.

What do you do to protect team members? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

When things go wrong

Have you ever noticed how colourfully the best-laid plans disintegrate when they come head to head with the real world?

The popular adage

Whatever can go wrong, will go wrong

seems to hold its own.

In the world of software development, its common to have an agreement with the stakeholders the product you are developing will be fault free and meet their needs. What then happens once the delivered product fails to meet these agreements?

Yes, even with Agile, sometimes you miss the mark and now have to hash it out with the client.

In this entry, we will be looking at how such situations can be handled in a way that makes you better for it.

Raise issues as soon as possible

As I have mentioned before

Bad news does not age well

In my experience, the most tempting reason for withholding information about the fires going on is to try to fix it before anyone else notices. Sometimes the strategy works out and you are solid. Most times, it just doesn’t. What ends up happening is you dig an even bigger hole for yourself.

Years ago when mobile phones had just hit the market, I was playing around with my parent’s phone, somehow I ended up turning it off. When I turned it back on, it requested a PIN. So I did what any reasonable child would do, started guessing! The effect was the SIM locked and the phone now asked for a PUK. Again, I continued guessing the numbers. In the end, the SIM card permanently locked and we had to part with Kshs 2000 to get a new line. If at any one point before the number blocked I fessed up, the problem would have been trivial to solve.

In your own professional practice, when a problem arises, drop the hero mentality and instead see if you can enjoin the other stakeholders to jointly solve the problem.

Take the journalist approach

It’s very easy to blame. After all, our brains love certainty even when there are no grounds for it. Thus when an issue comes up, it is easy to blame another stakeholder or even yourself.

Even if you are right, it doesn’t matter, the problem is still there!

My personal philosophy is never let any good disaster go to waste. If you have encountered a problem, this is the time to establish the what, how, when and why. By probing the incident, you will end up with insights into how you can improve your work process.

As a side effect, you learn how to separate the facts of the issue from the opinions formed around it. Humans are attached to their opinions, thus by focusing wholly on the facts, you are able to get a more productive approach going.

Prioritize the relationship

A Pyrrhic victory is a victory that inflicts such a devastating toll on the victor that it is tantamount to defeat.

In almost all engagements, the relationship is more important than the product delivered. We will allow great latitude for someone we trust.

Problems are by their very nature divisive, you must fight the urge to prove yourself right and the other parties wrong. When things do go south, this is the time to think deeply how you can use the opportunity to instil even more trust in your clients. No one is perfect, this means mistakes are inevitable, it is however quite valuable to know the other person will always be straight with you.

When complaints do come, the contract is not your shield and defender. Even if you somehow captured this case in writing and thus are not to blame, the client is not happy and that is a problem. It is better to then engage in a conversation to find out where you misunderstood each other and how best you can mitigate the situation with the remaining time and resources.

Keep moving forward

Peter Palchinsky was a Russian engineer who came up with a formula to improve almost any process.

first: seek out new ideas and try new things;
second: when trying something new, do it on a scale that is survivable;
third: seek out feedback and learn from your mistakes as you go along.

There you have it, to grow you must make mistakes, the key is to ensure the mistakes are survivable.

Thus after the mistake is done, comfort yourself, see it as a ladder to even greater things. After all, if it did not kill you, you learnt something from it.

How do you handle missteps in your own organization? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail