InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

562,907 Jan unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

19 Pitfalls of Technical Leadership

Posted by Deborah Hartmann Preuss on Jun 19, 2006

Sections
Process & Practices
Topics
Agile ,
Teamwork ,
Leadership
Tags
Management ,
Coaching and Mentoring ,
Performance Evaluation
Hacknot's list of Great Mistakes in Technical Leadership, while not particularly intended for an Agile audience, contains some sage advice - good leadership is not restricted to Agile teams. As always, Agile teams still need to balance advice from traditional sources against Agile values and principles.

The article goes into detail on each point, but here is the basic list, as a starting point:

Mistake #0: Assuming the team serves you
Mistake #1: Isolating yourself from the team
Mistake #2: Employing hokey motivation techniques
Mistake #3: Not providing technical direction and context
Mistake #4: Fulfilling your own needs via the team
Mistake #5: Focusing on your individual contribution
Mistake #6: Trying to be technically omniscient
Mistake #7: Failing to delegate effectively
Mistake #8: Being ignorant of your own shortcomings
Mistake #9: Failing to represent the best interests of your team
Mistake #10: Failing to anticipate.
Mistake #11: Repeat mistakes others have already made
Mistake #12: Using the project to pursue your own technical interests
Mistake #13: Not maintaining technical involvement
Mistake #14: Playing the game rather than focusing on the target
Mistake #15: Avoiding conflict
Mistake #16: Putting the project before the people
Mistake #17: Expecting everyone to think and act like you
Mistake #18: Failing to demonstrate compassion

One caution worth repeating here, for team leads and for everyone on teams with a flatter everyone-is-a-leader structure, is this:
Pair programming seems to be most appealing to those who like to chat about their work ... continually. An excessive focus on group consensus-based decision-making for all technical aspects of the project, even the trivial ones, may be a sign that a Technical Lead is more concerned with the sociology of the project and their place amongst it, than with leadership and making efficient use of people's time and effort.
Apparently, even collaboration needs to be kept in balance, to avoid the descent into the other MDD (Meeting Driven Development), the antithesis of healthy Agile collaboration.

For those who prefer patterns to antipatterns, here are some useful references:
  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

3 comments

Watch Thread Reply

Nice by Sandeep Khurana Posted
Hacknot's been down... by Jason Carreira Posted
Re: Hacknot's been down... by Deborah Hartmann Posted
Sort by date descending

  1. Back to top

    Nice

    by Sandeep Khurana

    Nice. Just would add one thing, managers in the project with no technical skills should stay away from day to day workings of the project.

    Reply

  2. Back to top

    Hacknot's been down...

    by Jason Carreira

    I haven't been able to get there to read this... Been hours now...

    Reply

  3. Back to top

    Re: Hacknot's been down...

    by Deborah Hartmann

    Me too. Have they been (gasp) hacked? :-D

    Reply

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.