Marine Corps Leadership Secrets - Part III

In this third article in my series we will continue to take a look at how to apply United States Marine Corps leadership traits and principles to software development team leadership. (You can read Part I here and Part II here.) In this part I’ll be discussing the leadership traits of Justice, Enthusiasm, and Bearing.

Justice

A sense of justice. What does it mean to you? In the context of this discussion this means fair impartiality, of taking actions that are fair and just to all.

For example, to be just in your day-to-day work, this means that you don’t play favorites. If you always give the best assignments to the same person and the worst assignments to other people on the team, how to you think it would affect team morale? It’s easy to guess that those given the bad assignments would probably not think that highly of your leadership ability and it will impact their attitude and productivity.

Being just also means keeping your emotions and prejudices out of your decisions as much as possible. While this is often company policy when in comes to some groups, such as race or sex, just because a particular type of person isn’t on this protected list doesn’t mean that you’re allowed to treat them unjustly. You should treat all of your subordinates justly. If you don’t like someone on a personal level due to an annoying trait that grates your nerves at an emotional level, don’t take it out on them by assigning them all the grunt work or using them as a pawn for layoffs. Instead, work on getting to know them better or, if you can’t treat them justly, help them find a place within the company where you won’t be their supervisor.

In short, unjust treatment will harm team morale and undermine your leadership while just treatment for all will have the opposite effect.

Enthusiasm

This doesn’t mean that you have to be a rah-rah cheerleader. Software developers typically don’t like phony behavior and such insincere behavior isn’t what you’re looking for here. What you are looking for is showing an interest in the work your team is doing.

Let’s imagine a scenario where a developer on your team wants to show you a new algorithm they’ve developed. Sadly, many a team leader would blow off such a request in favor of other ‘more important’ meetings. This syndrome becomes worse at higher levels where the manager doesn’t have a good feel for the development tools being used and has a tighter schedule. How do you think the enthusiasm level of the developer who’s brushed aside will be afterward? That’s right, not so good. Do this enough and the whole team is in the dumps.

Maintain enthusiasm within your group by being a sincere cheerleader and coach for their efforts. If they’ve worked hard, acknowledge it and applaud their efforts. If they’re struggling, be a mentor and help them find a solution through positive methods.

Also work hard to avoid outside problems from dampening your team’s enthusiasm. While sometimes this is unavoidable, you can do your part by not complaining to them about the direction the company is taking. Try to keep things on a positive note as much as possible in these situations. Doing so enhances your leadership of the team and, at the very least, improves the morale of the team where mutual misery will only weaken it.

Bearing

Everybody knows the look of a squared away Marine in uniform. Movie characters like Jack Webb’s The D.I. or R. Lee Ermey’s Gunny Hartman in Full Metal Jacket or John Wayne in Sands of Iwo Jima have burned in this image. So, do you need to be all spit and polish, tough as nails, cussing and swearing to have bearing as a software development team leader? No, bearing is really deeper than physical appearance, it’s an attitude, a state of mind.

I don’t want to totally discount physical appearance though. If your company has a dress code, live up to it. Being slack in this area will only encourage yourself, and the rest of the team, to be slack in other areas. If you’re lucky and don’t have a formal dress code, consider casual dressing for success. You might be surprised how much a neat look improves your leadership.

But, beyond the physical, what is bearing? It is how you conduct yourself verbally and emotionally. If you rant and rave at your team, you’ve lost your bearing. If you cut down a team member, that’s loss of bearing. If you make a joke out of handing out work assignments, you’ve lost your bearing. If you engage in sarcasm, you will lose it as well. However, if you conduct yourself with dignity, show that you’re more interested in being understood than impressing others, and make yourself approachable, you will develop excellent bearing.

That’s all for this part. Part IV will be available soon where we’ll be discussing the final 4 leadership traits: Endurance, Unselfishness, Loyalty, and Judgement.

Here are the other parts of this series:

• Part I
• Part II
• Part IV
• Part V
• Part VI

Add comment July 30th, 2007

Marine Corps Leadership Secrets - Part II

In this second article in my series I’ll continue my explanation of how to apply United States Marine Corps leadership traits and principles to software development team leadership. (You can read Part I here.) In this part I’ll be discussing the traits of Decisiveness, Dependability, Initiative, and Tact.

Decisiveness

Nobody likes to work for someone who leaves important decisions up for debate by the group or who simply leaves them up in the air, unmade. Nor do they like to work for someone who is inconsistent or wishy-washy. Managers who publicly vacillate over making key decisions usually lose the respect of those underneath them. However, people will respect a leader who can make a decision, tell everyone the decision in clear, confident, terms and then stick to it. They’re a person who says what they mean and means what they say.

This doesn’t mean that you should be inflexible about the decisions you make though. Situations change and, when they do, a leader is required to decisively act upon the new information. For example, a development tool a lead decided upon isn’t working right due to serious bugs that the vendor isn’t going to fix anytime soon. Instead of muddling on toward failure, the decisive leader takes steps to fix the problem quickly and save the project.

Being decisive also means be accountable for your decisions. If you make the call, you are responsible for it. Don’t pass the buck to your team members, peers or your management.

Dependability

Can your team depend on you? Can your management depend on you? Dependability works both ways.

To be dependable to your management is really basic Work 101 stuff. It means you show up on time, that you don’t make excuses or complain without a good reason, and stay on the job until it is completed. If you aren’t doing these things for your management, then why should you expect those you’re supposed to be leading to do the same for you?

How can you be dependable to your team? You do this by first of all being an example as I mentioned above. You are the role model they’ll look to, for good or for bad. However, it goes beyond just that. It means that you are willing to stand with them if there is an emergency that needs to be handled or if there is extra work needed to complete a project. If the team is coming into the office over the weekend to work you should be there too if at all possible. If there is a disaster, like a failed database, you are there working to correct the problem, even working through the night and into the next day if necessary. Your dependability will inspire those working for you while shirking your responsibility will, over time, demoralize your team.

Initiative

If you only do what you’re told to do and wait for others to take action, well, you aren’t much of a leader. Take a look around and see what needs to be done to either help you reach your goals or that’s keeping you from reaching them. For example, if someone on your team is having a problem with their PC, take the initiative and help them get it fixed. If there is a new tool that would greatly speed the development of your project, take the initiative and get it in for testing. Are there classes you and your team could take? Get them signed up.

Don’t be satisfied with the status quo. Learn to think outside the box and to solve problems in new ways.

Tact

Tact. It means a sense of what to do or say in order to maintain good relations with others or to avoid offense. You may be surprised that this is on a Marine Corps leadership list after seeing movies or TV shows about boot camp. You see a lot of insults and screaming and yelling there. But, courtesy and respect plays an important role within the chain of command once a Marine leaves boot camp. Likewise, the courtesy you show to your team and to your management is important as well.

When you assign work, do it in a courteous, direct and personable manner. This helps insure the work will be understood and will be carried out correctly and with enthusiasm. If you give out assignments in a careless or brusque manner it might very well have the opposite effect.

Tact also applies to how your respect your team member’s time, property, and feelings. Wasting their time in useless meetings, not respecting their property, or hurting their feelings, intentionally or unintentionally, will hurt your authority within the team.

The simple management axiom is to praise in public and reprimand in private. This is one of the key ways to be tactful with your team. A public reprimand or even one that is private in name only can seriously damage your credibility within the team and harm morale. If you must reprimand, make sure that you are fair, firm and friendly about it.

With your managers, you should approach them in the manner that you would want to be approached if you were in their position.

Here are the other parts of this series:

• Part I
• Part III
• Part IV
• Part V
• Part VI

Add comment July 26th, 2007

Marine Corps Leadership Secrets - Part I

The United States Marine Corps prides itself on many things. One of these is the leadership training it provides to its NCO’s (non-commissioned officers) and commissioned officers. As a software development team lead, what can you borrow from their training to use in your daily activities? How might life and death battlefield leadership methods be of use in a corporate environment? In this series of articles I’ll be discussing the USMC’s leadership traits and principles that I was taught many years ago and how to apply them to your team leadership position.

Integrity

In this context, integrity means honesty, that you mean what you say and that members of your team know that about you. If you lie to them, they will discover it and they won’t trust you at your word again. When you’re talking to your team let them know if you’re giving them a fact or your opinion. Don’t make them guess about it. Also bear in mind that even off-hand statements may be taken as fact by your team so use care in what you say about sensitive topics.

There may be times when you have information you aren’t allowed to pass on to the team. Part of your integrity is keeping confidential things confidential. If you run into a situation like this where team members are asking for information you aren’t allowed to pass on, tactfully decline to answer the question.

Likewise, also show integrity in your dealings with managers above you. Don’t lie to them, because, once again, the lie will come out. Give them the straight facts as you know them and ask for the same from them.

What you should strive for is to be known as a person of their word, someone who can be trusted by both those above and below you within the organization.

Knowledge

Part of your job is to know the tools you’re using. In whatever language you’re developing in, you should not only know it well but you should also know where to find answers to the questions you don’t know. You should be a mentor to the junior members of your team and guide them into best practices and techniques. If you don’t know an answer, admit it and then find it out. Don’t try to bluff your way through. Your team will spot it and this will damage your respect and authority within the team.

Also, knowledge also applies to knowledge of your team. You should know the strengths and weaknesses of each team member. If you don’t know this you will run into problems. People aren’t cogs that you can stick just anywhere and get the best performance. Know how to get the best performance out of each team member.

Courage

While it is unlikely that you would have to demonstrate physical courage in your normal corporate environment, you will probably have multiple opportunities to exhibit moral courage. By moral courage, I mean knowing what is right and standing up for it.

Often this may mean standing up for yourself or a subordinate in a tough situation. For example, if your boss is a office bully it may mean calling them on their antics. If your manager is doing something illegal or violating company policies, it may mean dealing with that in a proper way. If a human resources policy is misguided, it may mean challenging them on it. Standing up for what’s right might cost you your job but the alternative is often much worse.

Another aspect of moral courage is having the courage to admit you were wrong not only to your team but to your management as well. Everybody makes mistakes from time to time. The trick is to not keep making the same mistakes over and over again. Instead, learn from your mistakes. It also means having the courage not to pass the buck or blame your team for the failure. A good team leader fixes the problem, they don’t fix the blame.

Here are the other parts of this series:

• Part II
• Part III
• Part IV
• Part V
• Part VI

5 comments July 25th, 2007

Scapegoating In Development Teams

What is a scapegoat? It’s a metaphor derived from the ancient Hebrew practice of placing the sins of the nation upon a sacrificial goat who was sent into the wilderness. In modern times, it refers to someone who is blamed for misfortunes as a way to distract attention from the real causes. In software development teams scapegoating of a team member (or members) usually happens because of a breakdown or lack of good procedures and processes. These are almost always associated with failed teamwork and leadership.

What Causes Scapegoating?

Scapegoating usually begins as a result of pressure on a team that occurs when things begin to fall apart during a project. For example, a development team doesn’t use version control and a key update is lost. Logically, it would be a lack of good process by the team as a whole that caused the problem. However, often people find it more comforting to find someone to assign blame to, preferably someone politically weaker in the organization than themselves. The typical end result is the firing or reassigning of the ‘goat’. However, this does not address the underlying fault so the team is doomed to repeat the cycle again and again.

In fact, scapegoating can become so bad in a department that people group themselves together in ‘alliances’, almost like a reality game show, to defend themselves. One group fights another, people get angry and stressed, people get fired, but what doesn’t happen is much work. Everyone is too busy fighting a nasty political game to get things done. In the worse case scenario, this problem infects management and even the rest of the company.

Another contributing factor to scapegoating are misguided and improperly implemented human resources policies like 360 degree performance appraisals or forced ranking. While these programs might be of value in some cases, most of the time they only increase the dog-eat-dog atmosphere in a dysfunctional team or company environment. These systems really fall apart when management has begun the ‘blame game’ along with the employees under their supervision by taking sides.

What are some signs that a team is moving into scapegoatism?

One of the early warning signs is when one, or maybe two, people are ostracized by the group or are shown obvious signs of disrespect. For example, people on the team make a point of not inviting a person to lunch when everyone else is going or openly use disrespectful language toward a person on the team. If a team lead or manager allows this kind of behavior to continue it will escalate into more serious problems ranging from lost productivity to workplace bullying.

Another sign that the team is moving in this direction is the formation of cliques within the group that seem always to be at odds with each other. While it is natural for people to hang out with other people they like at work this can become unhealthy to team dynamics if it begins to take on an ‘us against them’ mentality. This typically reaches a boiling point when a lead or manager is given the choice of deciding who was right in a conflict. Often there are no right answers and a quick decision one way or the other results in a loss of credibility and respect for the manager.

What can a team lead or manager do to prevent this problem?

The main thing to do is address the underlying causes of the situation. Since these are almost always process related things that cause stress in the team take the time to assess this area. Do you have process areas that need improvement? If so, work on correcting them. If you don’t think you do, check again, because you probably have overlooked something. Are human resources policies causing problems in the team? Lobby to exempt the team from them, at least temporarily. You are the ’spear catcher’ for the team and you should protect them from outside productivity killers. If the situation has already become so toxic that making these changes is impossible, then you may want to prepare your resume because things can only go downhill from here on out.

Watch out for people blaming others for problems, particularly unjustly or in a derogatory or gossipy manner. Urge team members to criticize the process not the person. Ask them what can be done to improve the process and keep them focused on this and not on the scapegoat. As team lead, you should avoid playing favorites when it comes to assigning work and socializing. If people under you are having problems, mentor them, find out what the problem is and look for solutions to the situation. Don’t write them off as worthless and give in to the desire to blame them for the team’s woes or use them as a pawn for the next round of downsizing.

Another important thing is not to ignore the problem. Some managers find it easier for them to ignore these kinds of problems and push them under the surface by ignoring communications or by not making any changes that would help relieve the problem. They may think that they’re not taking sides in a conflict and are staying above it but actually all they’re doing is simply abdicating their role as leader of the team or department. As manager, it’s your responsibility to take care of these problems, not to sweep them under the rug.

What are your ideas on this topic? Have you ever worked in an organization where scapegoating got out of hand? If you do or have, leave a comment about it.

Add comment July 21st, 2007

5 Development Team Productivity Killers

Here are 5 things that will seriously harm the productivity of a software development team. They are:

1. Not Sharing Information
2. Not Using Peer Code Reviews
3. Not Enforcing Coding Standards
4. Not Using a Version Control System
5. Not Using the Appropriate Technology

I’ve seen these things slow down and even kill several projects both in VB and other languages. In this article I’ll go over these common problems and give you some solutions to help you deal with them.

1. Not Sharing Information

It is common for programmers to horde information, particularly from newly hired developers or contractors or from members of other development teams. Why do they do this? There can be several reasons. One typical reason is pure office politics, protecting ones own position in the department and company. Certain human resources policies, like Forced Ranking, can
encourage this behavior. Others may include a fear of criticism by others or feeling protective about others possibly changing their code. Some may even feel like they’re protecting the company from losing valuable intellectual property by withholding key information from other developers.

This kind of ‘tribal chieftain’ knowledge quickly becomes a liability to the company because new developers have to constantly bother the ‘chief’ with questions, thus lowering the productivity of both. Even worse, it can kill team morale if the ‘chief’ is difficult to deal with. And, should the ‘chief’ leave the company, often development projects are thrown into chaos for months.

The solution to this problem is to encourage a free flow of information and find ways to reward it. For example, you may create a mentoring program where a long time developer is given the task of spending some time with new developers to get them up to speed. Or a ‘lunch and learn’ program could be implemented that would allow a small group of developers to discuss things over an always popular free lunch. These approaches and others like them usually build team cohesiveness and spread knowledge more evenly throughout the department.

2. Not Using Peer Code Reviews

Some people view code reviews as a waste of time, a productivity killer, but I think the opposite is true. As mentioned in the first item, too often one programmer doesn’t know what the other is doing. Peer reviews are another way to encourage knowledge sharing. Also, from a productivity stand point, having an extra set of eyes check the code will greatly reduce costly rounds of maintenance since often a programmer is too close to their code to spot problem areas or simply miss things that they meant to repair and forgot about later.

3. Not Enforcing Coding Standards

Nobody likes be in the role of ‘code police’ but some commonality is needed when more than one person is working on a project. If everyone goes and does their own thing it makes code harder to review and maintain. The most important thing here is to come up with an agreed upon standard and stick to it. You may want to use a VB.NET standard coding guideline like this one or you may want to continue to use old style VB6 standards. But, whichever you pick, stick with it and enforce it.

As a side note to this, any good coding standard should include comments. .NET makes this easy with XML Comments since it provides an easy to use and documentation tool friendly common template for them. Of course, you can use your own standard here but XML comments make this task much easier in .NET.

4. Not Using a Version Control System

This is common in organizations that started out small with one or two developers and expanded. Nobody had the time to implement a version control system or there wasn’t money in the budget for it. Soon, as the number of developers increase, the problems start. Nobody is sure which code is actually in production. Programmers find their code doesn’t work or is left out of a release. Rolling back to a previous version is impossible since nobody knows where the original code is located. Hacks to get things to work become commonplace. Soon the whole development process is bogged down in trying to maintain code that can’t be pieced back together.

You can save this kind of trouble by implementing a version control system from the start. It will more than pay for itself in the long run.

Also, everything should go into version control, not just application code. Web pages, documentation, and especially database table structure and stored procedure scripts should be included as well.

5. Not Using the Appropriate Technology

Too often programmers get stuck in the “I have a hammer so everything looks like a nail” approach to designing and developing applications. For example, a team may spend time developing a web based application when a desktop one would be a better choice or vice-versa. Another common trap is to always use a 3rd party code library for everything when it is only appropriate for a small subset of applications. Productivity often suffers when programmers try to force a square peg into one of these round holes. I’ve seen small projects expand into huge, time consuming, death marches because of the insistence on using an inappropriate tool for the job.

Avoid this trap by evaluating the practicality of a programming tool or method for a task early in the design phase. Don’t wait until coding has begun to do this. Also, don’t get stuck in the mode of declaring that all projects will use such-and-such a tool and so forth. Don’t shut out your options without proper evaluation on a per project basis.

Add comment July 16th, 2007