Simple UX plea

Dear UX designers,

If I'm not authorized to perform a specific function in the application, please show me a grayed-out button or disabled select list, rather than not showing anything to me.

This way, I know that I'm not authorized, and I won't waste hours scanning the application looking in other corners of your app for the functionality you have simply hidden.

Thanks.

Verbal Combat

And here is where the decision is made. Do I retreat to my established viewpoint? Do I dig in my heels? Or do I consider the alternative, offered by my combatant? And suffer the indignity of being judged wrong?

Truck Factor Mitigation

One of the strong selling points of pair programming is that knowledge of the code base, techniques, and domain are shared across multiple people. We joke that this reduces the "truck factor" for a team. Truck factor is the risk to the team or project of any specific person getting "hit by a truck".

Some other phrases: "beer truck factor", for those who like to imagine being hit by a worthy cause, or "lottery factor", as one colleague suggested, since it is a happier ending.

High truck factors can be good for the individual. After all, if your specific knowledge or talent is critical to the firm, so too, is your ability to negotiate for higher compensation or to easily acquire extra latitude for resources and decision-making authority. Management does not want to scare away the geese that lay the golden eggs when they have no idea how the egg-laying works.

A high truck factor has a downside for the individual though. When you finally get tired of the same platform/domain/language and want to move on, the hand that feeds you is likely to restrain you from departing to other projects. Sometimes, the only departure path is to leave the company. That can be a good thing for getting out of a rut (and introducing potentially lucrative contract work with your prior employer), but can also force you to start from scratch in building a reputation in a new situation.

What of leadership/management? How do we reduce the truck factor for managers? They don't typically pair. What happens when opportunities arise for a promotion, or an exciting lateral move, but the leader is tied to his current position with no replacement in site? Perhaps he needs to turn the new position down. Perhaps the external market is tapped for a replacement. Perhaps he just adds the new position's responsibilities to his current responsibilities. These are smells of poor succession planning.

If you're a technical superstar, or simply a master of your technical niche, or
if you're a domain expert, or simply master of your domain niche, or
if you're a leadership expert, or simply the most ingrained leader in your current role:

Identify, train and groom your successor(s)

You never know when that lottery ticket will hit.

Talent acquisition and retention

My friend, Brad Cross, posted an interesting blog entry recently on how compensation relates to attracting and retaining technical talent. This particular phrase resonated for me:

"Great workers long to work on interesting and challenging problems and collaborate with other great people who have a strong sense of vision and purpose in their work. They long for an open and supportive environment grounded in mutual respect that enables them to make their own decisions as appropriate."

His blog post goes on to relate the disconnect between the 10X productivity difference between the best and the worst software developers and the incongruence of the meager salary differential proffered by employers to recognize this difference (hint: it's not 10x).

Brad's post is thought-provoking, as usual.

No applause, just throw money

I have an aversion to the applause that occurs in some iteration showcases (aka sprint reviews) on agile teams. The showcases are the meetings at the end of an iteration where the team shows working software to project stakeholders. Unfortunately, many teams end up displaying PowerPoint presentations instead or in addition, but that's a topic for another post.

I once witnessed a team that had 2-week iterations and held a 2 hour review at the end of each iteration. Each team member presented what he had worked on and accomplished over the course of the iteration. First of all, two hours was too long for this team for a 2-week iteration. They simply did not produce enough demonstrable working software to warrant a two-hour meeting. Worse, they often resorted to presenting partially completed stories - another problem, but again, fodder for a future post.

Having each team member speak and present his accomplishments might have been a good thing for that particular team. It can provide a similar social pressure that stand-up meetings provide - nobody wants to stand up and say they didn't accomplish anything, so each team member strives to deliver demonstrable value. The problem I had with this particular team was that the norms established that everyone applaud each person after his little piece of the presentation. Not only was the applause time-consuming, it was gratuitous. Folks in the meeting applauded simply because they were expected to, not because of any remarkable achievement.

In some cases, the team member didn't really accomplish anything of note on his own and the applause was simply out of place. It is as if my dog takes a dump in the middle of the carpet during a party and the crowd rushes up to pet and praise him, and offer him doggie treats. Clearly, this confuses the dog.

Though applauding every presenter is certainly overkill, I argue that applause at the end of an iteration showcase should be eliminated (or better, never started in the first place). In any case, it should never be de rigeur, and should never be instigated by an outsider who may have no clue as to whether the team really accomplished something special.

Applauding showcases for mediocre or even poor iterations can have a deleterious effect on motivation. Consider this possible thought going through a team member's head: "They applauded for this crap? They have no clue what we're doing".

We have a habit of rewarding performance. If my kids come home with straight-A report cards, I heap praise on them. If a see a C, I begin my own inspect and adapt cycle at home. But in report cards, the grades are clear, and are mostly objective. That is - the "A" reflects a large number of assignments, tests, and projects, and the teacher assessing the outcome has a substantial pool of similar production to compare against. Outcomes of iterations/sprints, on the other hand, are hardly objective, and are not comparable to other teams' output. It is truly only the team members who know, in their collective heart of hearts, whether they really deserve applause or not.

So my suggestion: omit the applause until the code gets into production and the customers' rave reviews start flowing. That's when the party should start.