From time to time friends and colleagues ask us for advice. Quite a few of them are directed at us because we’ve managed to build and grow a very successful team of software developers. We thought we’d share a response our CTO, Chris Shoemaker had to a question recently regarding the percentage of time an engineer should be focusing his or her time on implementing features.
The answer, as with most things software development related is: It depends.
Generally speaking, you might divide an engineer’s work into two categories.
There's a category of what I'll call "non-engineering" work that engineers do - stuff like personnel meetings, interviews, switching desks/offices, tps reports, etc. The amount of time spent on things in that category is pretty much a function of the company. In my opinion, if that's more than 3 hours/wk of an engineer’s time, then it's not a very effective use of their time. 2 hours/wk would be a better goal.
That leaves about 95% of the week available for the second category: "engineering" activities. In that, I include specification work, prototyping, research, testing, addressing technical debt, daily standups, sprint planning meetings, retrospectives, peer code review, debugging, and, of course, feature implementation. The proportion of time spent among these activities varies dramatically according to the intention of the engineers, and the maturity of the project.
Let’s use some extreme examples to demonstrate what I mean.
Suppose that specification had been done up front, and there was little to no existing code, for a very low risk technical feature, with an experienced engineer, and only short-term value in a feature (no expectation for long-term use), then I could see that engineer spending 95% of their week on feature implementation.
On the other hand, in an sprawling code base, with high technical debt, with the intention of gaining long-term sustainability, then I could easily see a team of experienced engineers spending all their time on maintenance, debugging, refactoring, etc. This would probably qualify as 0% "feature work".
Or, in a young project, with ambitious goals and high technical risk, it's common to spend all available time researching options and tools, experimenting, and simply ruling out non-viable approaches. This would probably also qualify as 0% "feature work".
Typical software engineering projects aren’t at any of these extremes, but are balancing a complex array of goals and environmental factors. Each project has its own profile of allocation of effort among various activities, and it’s even changing over time.
So, depending on the categories, I guess my answer is "somewhere between 0% and 95%." Like I said: It depends.
Want to work with us? Get in touch: hello@mojotech.com