I had the opportunity to present at the SDC on "Empowering a Team as an Individual Contributor" (9/1/2013).
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.
Tuesday, September 3, 2013
Monday, February 11, 2013
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
· Automated build and deployment
· High unit testability
· Low QA bug count
· DevOps, application monitoring
· Developer conscience
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.
Posted by Tim Stall at 7:33 PM 0 comments
Labels: management, metrics
Subscribe to: Posts (Atom)