Archive for June, 2009

Spotting Future Leaders

Saturday, June 27th, 2009

Everyone knows — good engineers are not necessarily good managers. 

In fact, some great engineers turn out to make terrible managers

So, how do we know if an engineer is tracking to a leadership role?

We use the following questions to help assess whether an engineer is ready for a management or team leadership role:

  1. How does the engineer provide leadership from their current position as an individual contributor?
  2. Is the engineer recognized as a leader among peers on the team and on other teams? 
  3. Prioritization - Do they have a good sense of what is critical vs what is somewhat important.  Do they cut through the noise (non issues) to focus on the critical issues?  (vs they are distracted by less important issues)
  4. Do they dispatch obstacles effectively and efficiently?
  5. Time management - Are they using their time effectively?
  6. Organization - Do they know how to organize and plan?
  7. Peer relationships - Are they collaborative?  Do they have good working relationships with their peers and managers?  Do they help others succeed?
  8. Self aware - Are they aware of their weak spots?  Do they know their strengths?
  9. Learner - Do they know what they don’t know?  Do they listen and learn from others?
  10. Driving for results - Do they effectively balance focus on objectives and results with engineering and technical considerations?
  11. Dealing with ambiguity - Are they flexible?  Do they handle incomplete direction or information effectively? 
  12. Judgment / decision skills - Do they make good decisions?  Do people ask for their opinion?
  13. The drama factor - Do they operate without creating distractions and disruptions on the team?

Identify your future leaders.  Develop them to do these things well.

-Donny

Clean Slate Development? Or Iterative Transformation?

Friday, June 26th, 2009

This can be a tough question.  The desire to rebuild a software system from scratch is difficult to resist, but duplicating complex software is almost impossible.  (from Grady Booch’s On Architecture podcast series).  The software industry’s project failure rate has improved in the last decade as software teams adopt agile methods and iterative strategies for improving their software systems and architectures.

In general, rewriting your system from scratch can be an appropriate decision when:

  1. You have no other option.  The legacy app is too brittle.  You can’t touch it without significant risk of disruption
  2. Failure is an acceptable option.  You have unlimited resources or a solid portfolio of projects to hedge the high-risk, clean slate, long-term project
  3. The primary project objective is self-actualization

value-of-iterative-over-rewrite

With ‘clean slate’ projects:

• Delivery of new capability is deferred, along with the ROI of the new capability (consider the time value of new capability)

• Hidden costs include the substantial effort required for parity capability and stabilization of new code, new issues, and new constraints

• Accurate schedules and cost estimates are virtually impossible

 

With iterative transformation of your software system:

• Your resources focus on new capability (vs parity capability and stabilization of a new system)

• Uncertainty and risk are managed through short, well-defined iterations

• Your customers realize the value of new capability sooner

• Early and frequent delivery provides an effective feedback loop, leading to course corrections and additional value

-Donny