Some Site Additions and StuffThe Basics of Tiger Team Programming

Marine Corps Leadership Secrets - Part VI

August 11th, 2007

USMCThis is the last article in my series on applying United States Marine Corps leadership traits and principles to software development team leadership. In this article, we’ll look at some of the principles of leadership where the traits are put into practice.

Here are the other parts of this series:

Know Your Team and Look Out For Them

As team lead, you need to know what the strengths and weaknesses of each team member are. For example, if one person is strong on writing backends and another is strong on UI, assign them to tasks that play to their strengths. If you need to cross-train members, put a strong member with a weaker member. The better you know your team, the more effective they will be. Likewise, if you don’t know or ignore team members capabilities and preferences, you will soon run into difficulty. Use your judgement to make the right choices for you, your team, and your organization.

Also, watch out for your team’s welfare. If a project sponsor insists on your team developing a 12 month project in 6 months, have the moral courage to stand up to them. Don’t just roll over and let your team suffer under an unrealistic schedule.

Keep Your Team Informed

In the Marines and Navy, scuttlebutt was originally the term for a cask of water. Of course, as men drew water they talked and thus the term came to mean exchanging rumors and gossip. The ‘water cooler’ rumor mill is strong in some organizations. As a team lead, it is your job to make sure that you keep your team well informed about your organization and that they aren’t depending on rumors. Playing “I’ve got a secret” with your team is a sure way to damage morale. Have the integrity and dependability to keep your team correctly informed.

Certainly, there will be times you have confidential information. In those cases, show your loyalty to your organization by keeping it secret. However, you should also look out for your team in this case, particularly if the news is bad.

Set Goals You Can Reach

How many team leads have gotten into trouble by agreeing to schedules that they couldn’t keep? A lot, I would wager. It is your job to only accept work that your team can accomplish within the time frame given. Read up on project estimation and negotiation tactics to help protect your team from futile death marches. Your team may be good but don’t ask the impossible from them. Likewise, giving little make-work assignments one after another to a team of crack developers will frustrate them. Set the right goals for your team.

Make Sound and Timely Decisions

Knowledge and judgement are needed to make a sound decision while initiative is needed to make it a timely one. If you’ve made a bad choice, have the courage to change it before more damage is done. While you should avoid changing your mind frequently, sticking with a failing plan or development tool decision will only bring more trouble upon you and your team. Part of making good decisions is knowing when to make a change and when to stick with it despite the odds.

Know Your Job

Honestly, if you don’t know programming well you really don’t need to have a team lead job. This should go without saying but many organizations promote faces and personality over technical skills. As a technical team lead or IT manager it is your job to stay informed on the latest trends. You don’t want to be the kind of manager who says something like, “Oh, Ajax, I clean my kitchen with that” or “Orcas? Yeah, I saw one of those at Sea World.” Instead, you want to be in the know on all the latest trends.

If you don’t know, then have the courage to admit it. Don’t try to fake it in a ‘pointy haired boss’ fashion. Instead, learn from your team when you can. This not only improves your knowledge but improves the morale of the team too.


Encouraging teamwork seems like a no-brainer, doesn’t it? However, I’ve seen a number of teams fail because of interpersonal problems, cliquish behaviors, backstabbing, work hogging or avoidance and other such problems. Make sure that the people on your team are getting along. If they aren’t, find ways to help them deal with each other and, as a last resort, find a way to restructure your team. Ignoring these kinds of personal problems will only make things worse for your team. If you find one member is hogging all the work or avoiding taking on work, make an effort to better distribute the work. Whatever you do, don’t entertain gossip about a team member from another team member. This is a major morale killer.

Also, try to schedule social time together for the team. This might be as simple as lunch or drinks after work as a team once a week or so or something more elaborate on a less frequent basis. Be careful not to exclude some team members from these activities and try your best to schedule them in such a way that everyone can attend easily. While people may not show it, being ‘disinvited’ from such gatherings can be quite a morale killer.

OK, that’s all for this article and the series. Let me know if you liked it or have questions by leaving me a comment.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Development Teams

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (6 votes, average: 4.67 out of 5)
Loading ... Loading ...

2 Comments Add your own

  • 1. Tali  |  January 20th, 2009 at 5:31 am

    Semper Fidelis!

    Outstanding article! I wish High Schools taught a course on leadership and ethics as a required class for graduation. Thank you for writing this, I have bookmarked and plan on sharing with development teams!

    Sgt. USMC

  • 2. RAY  |  February 27th, 2009 at 7:44 pm

    Have you thought about printing this as a booklet for distribution? That would be very effective. People tend to grasp things better when they can hold and read this info. Plus it would be an excellent thing to pass out and go over at a managers meeting. i may be wishfully thinking, but it’s better to ask.

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities