Email to grand-boss

I felt like I should have gotten high-fives from the Bobs after sending this email to my boss's boss last night ;-)

--------------------------------
From: SEK
To: Grand Boss
Sent: Wed 2/27/2008 8:03 PM
--------------------------------

Hi Michael,

Thanks for discussing the implications of MT’s departure and your ideas on how we can cope with that as a group. As well as the ideas on making the group more efficient (contractor usage, etc)

I love to provide input into these areas – if you haven’t noticed, I have a lot of ideas on how to improve process, reduce costs, and in general make IT Apps more efficient.

Diminishing marginal returns and per project contractor ramp up times are definitely a drain on our project implementation efficiency that we should weight against the cost. Strangely enough, the thing I most hate to hear from “the business” is “cost is no object”. Every time that has happened in the past (not just as Cricket), the work which gets done is non-relevant, non-fun, and in the end against every businesses objective of making money.

I wanted to answer your question on how long it would have taken me to implement the CSP POS project all by myself.
We actually got really lucky with the contractors on the POS project. I rate our efficiency as follows:

Starting with myself at 100%, I’d say Protik comes in at 90% - He’s been a great asset on the team. He’s been on the same page with the project goals since day one and also assisting with much of the management task load. After that I’d rate the 3 most efficient contractors at 50% each, and the 3 less efficient contractors as 25%. That’s 415% total, but Protik and I probably dropped from our individual speeds due to management responsibilities.

In conclusion, I wouldn’t be surprised if I would have been able to complete the development in 3x the time that we took. I’d probably have had to have been whipped a few times to achieve that speed on my own. Since my #1 personal work goal is to learn skills needed to run a software company, I was excited at the challenge of managing the large team and put in a lot of extra effort to keep the team as efficient as possible. Plus there are some benefits of having additional people to bounce ideas off of and pawn off the time consuming tasks like builds and deployments.

And to answer the 2nd question, regarding how to improve our development efficiency and price performance in regards to contractors:

1. We can hire people temp to hire instead of contractors. That way we get the best of both worlds. We can evaluate them before they are locked in, and if we hire them fulltime, they are likely to stay around for a while, accumulate business knowledge, etc.
2. We can hire more Junior developers as opposed to people who are already Senior/Super Senior. Sure they might not bring quite as much to the table, but MVA is a good example of how getting the right type of less-experienced team member can really help the team. If you think of a sports analogy, developing younger talent is the lowest cost way to improve talent on the team.
3. Opposite of #2, we shouldn’t get pessimistic on the talent market because we were unable to land the super stars we we’re looking for. I have personal experience with both John Dinh and Paul Webber. They are both super star developer level and the fact that we didn’t hire them on fulltime is probably just an indication that we were aiming too high. Back to sports: A team full of super stars doesn’t always gel anyway. I mean, you’ve already got me, I’m like the Kobe of programming ;-) Totally kidding of course! (I’m really the Steve Nash of programming)

This email is definitely already long enough, but my improvement push lately is to be as concise as possible. So at any given time I have 3 words which I bring up with Mike at every 1:1 meeting. We often come up with good ways on how to progress on them during those discussions.

• Process
  o Document and follow repeatable processes
• Consolidation
  o Reducing the number of production systems developed and maintained by IT Apps
  o Consolidation within the code – reduce duplicated code within the system – use a consistent coding style and form
• Sustainability
  o Fight Entropy – businesses, systems, or code which isn’t improving, definitely isn’t staying the same!
  o Refinement of systems, processes, over time to increase efficiency (and thereby cut costs)
  o 20% of CSP dev efforts devoted to sustainability, maintenance, consolidation, non-project driven refactoring
  * Management approval for efforts like Kaizen - approval for members to spend at least 5% of their time towards continual improvement.

Thanks (and I can’t believe I stayed late to complete this email),
-Stan

PS: the reason I did stay late leads directly to low cost software development tip #4 and a huge part of the reason why MT had to leave: “Capitalize on Developer Passion”
I’d propose that developer passion, and not whipping, is the reason why previous development efforts, potentially including your antidotes from the meeting were low cost while providing big benefit to the business.