At Treehouse, we have 6 developers in a team of 50+ people. I’m told that’s unusual for a web-based startup, and that typically the company’s staff (and hence direction) is dominated by a team of developers.
There’s good reason for this difference – at heart we’re a content production company, so that has to be our focus. The development team at Treehouse is really there to support that goal. We don’t get to set the priorities for what gets worked on and what doesn’t, but we’re all ok with that.
We had lately fallen into a trap though, and as the team leader I’ll admit that it was mostly my fault. With 40+ internal ‘clients,’ the list of “really important things to do” is kind of overwhelming. There’s a huge temptation there to just plow through the list as quickly as possible, and that’s what we were doing – each of our developers would spend 1-3 weeks completing project A, and then immediately turn around to start on project B.
The reason this is a trap is because it ignores the importance of self-motivated work in creative disciplines (And yes, software development is a creative discipline – I wish I had a nickel for every time I heard someone say something dismissive like “it’s just engineering…” but that’s a topic for another post, perhaps). Staying on top of the priorities for the rest of the company is a great thing, but it also can turn into kind of a grind when you never get to tackle any of those awesome little ideas you have day-to-day.
This was manifesting itself on our team, and it was really apparent once I started looking for it – we believe pretty strongly in the 4-day work week and maintaining a healthy work/life balance at Treehouse, but the dev team (including myself, back when I actually wrote code) was consistently spending a lot of time working on nights and weekends. Why? Because stuff we did during working hours was all the stuff we had to do, and on nights and weekends we could work on those little things that we wanted to do. It’s fantastic to work with a team of guys who are that motivated, but that’s a solid recipe for burnout.
To try to address this problem, I’m giving the developers at Treehouse time to be awesome. Specifically, after every major iteration they do on the app (one of those 1-3 week chunks of work), I’m encouraging them to take some time (a few hours, a day, maybe a day and a half) to do something they think is awesome or important even if it isn’t on our “big list of stuff to do.” Maybe that means refactoring an ugly part of our code, or adding in a “nice-to-have” feature to the site, or fixing a workflow for our teachers in admin that’s been bothering them. The big thing is that it’s something they choose, and is something they think is awesome.
We’re just starting this policy, so I can’t yet report on results, but I really like the theory of it. Delays to our company-wide priorities are going to be minimal (we’re talking about a few hours here and there), and while I don’t expect it to totally eliminate the extra work that the team is doing, it will allow the team to be more expressive in what they work on. I think it’s a win-win.
I am curious, though, if anybody has any other ideas or thoughts about my “take time to be awesome” initiative.