Presenting at SDC on Empowering a Team as an Individual Contributor

I had the opportunity to present at the SDC on "Empowering a Team as an Individual Contributor" (9/1/2013).

http://www.meetup.com/SoftDev/events/134325872/

Most developers are individual contributors (IC) – in other words they do not have direct reports. But even as a non-manager, you can empower an entire team. This is due to the nature of software engineering, where developers create their own tools, a star developer can be 10x as productive as an average developer, and a single developer can use technology for team-wide impact. With the right mindset ("add business value"), and using a combination of hard skills (automation, tooling, code generation, open source, code reuse, etc…) and soft skills (interviewing, mentoring, communication and knowledge sharing, etc…), you can be that IC developer who helps lift your entire team, and have fun along the way.

The one ratio to rule them all

I was reading from "Good to Great", excellent book, and it mentioned one of the things successful companies did was chase a simple, single ratio. Sure, there's always more to it, but that one ratio helps focus the team. For most software departments, that ratio is something like:

(Requested Features / Incident Count ) per developer per month.

Basically, you want to crank out lots of features and have very low incidents. "Emergency" deploys, production bugs, outages – those essentially count as incidents.

All the good things either help increase requested features, or decrease incidents, and hence drive this ratio up.

Increase: Requested Features	Decrease: Incident Count
·         Application frameworks ·         Reusable blocks ·         Code generation ·         High quality, motivated, developers ·         Tools ·         etc…	·         Automated build and deployment ·         High unit testability ·         Low QA bug count ·         DevOps, application monitoring ·         Developer conscience ·         etc…

Most of the time, a team gets into trouble when it starts chasing things other than this ratio:

·         Hours on a timesheet (instead of actually producing something)

·         Face time in meetings or the office (instead of actually producing something)

·         Thinking how their manager thinks (which may not actually increase feature output)

·         High Lines-of-Code count (more codes != more features)

·         "Feeling" busy (merely feeling busy doesn't mean cranking out useful code)

·         Cool technology for the sake of cool technology  

·         Job security via undocumented process

·         Coding to show how smart you are (as opposed to code to make the requested feature)

·         Rating/grading the quality of developers (as opposed to making the business happy with working features)

·         Avoiding mistakes (as opposed to the addition of value)

Sure, these things by themselves aren't bad (avoiding mistakes and using new technology), but they are secondary to the real goal. As long as a developer – or worse, an entire team –  chases them instead of the real goal, they will always be less than great.