Learning to Delegate, part 2: Infrastructure [08/08/2008 11:49:23]
I drew the picture above about two weeks ago while trying to think through why I had so much trouble delegating.
I called it my "day job" because I feel like I spend most of my time doing pretty low-level grunt work when what I really want to do is write, build cool software, and build my company.
The problem is, I always feel like I'm blocked when I try to delegate work. That's what the little walls represent. The way I see it, I have four main roadblocks:
- poor issue tracking - I mostly work out of my email inbox, but that doesn't scale. Plus, relying on email as an issue tracker slows down my response time because nothing gets back to the customer until I've completely solved the problem. I need a real ticket system.
- poor process documentation - knowledge of how I prefer to handle things is stuck in my head. It's not enough for someone to know Linux and Apache, they also have to know my system, and my documentation sucks. The fix is better documentation.
- poor administration tools - some of the things I do on a regular basis require logging into a server as root or manually entering SQL commands. I'd much prefer to restrict support people (especially junior support people) to a web-based control panel.
- poor scheduling - In my recent experiments, I've been assigning a work queue to each contractor. The problem is people work at different speeds and have different availabilities, so some tasks get held up waiting on one guy, while another guy's starved for work. Instead, I should just have one central prioritized stream and let everyone (including me) work on the most important things whenever time permits.
The knowledge base icon (upper right) and the basecamp/cerberus/odesk (lower left) indicate my initial attempts at working around these problems. Basically:
- I've been compiling notes on my support operations into a knowledge base, but it's not web-enabled yet.
- I've stuck a few support issues into cerberus. It's a nice tool and comes with full PHP source, but whatever tool I use I'm going to want to hack on, and I'd rather just use something open-source.
- I signed up for a 30-day free trial of Basecamp. It's pretty, and it was a breeze to get started, but it's more like a to-do list than a real issue tracker.
- I also have a few bugs stored in trac. Trac is a nice wiki and the subversion integration is great, but the issue tracker is fairly weak.
So. I've been thinking through what I really want out of my issue management infrastructure, and I came up with this:
What I Want in a Tracking System:
- a web-based front-end
- integration with my customer-facing control panels
- ability to track both private support tickets and public development issues
- a strong email interface
- integration with my knowledge base
- reporting ability (eg: most common issues over time)
So I started digging through roundup, an issue tracking system written in python.
The roundup docs are a bit overwhelming and hard to navigate, and there's a lot of technology under the hood. It's really more like a generic database framework or content management system with web, email, and command line interfaces that just happens to be configured as an issue tracker out of the box.
I sketched out the default issue-tracking schema as I read through the documentation last week:
It turns out that the schema is entirely configurable, though. The only thing it requires is the user class, and even then you can change or replace most of the fields.
I spent pretty much all day configuring roundup yesterday, and here's what I came up with:
You can see it running here, though there's not much to look at yet: I don't have any data in it yet and you can't create private tickets, but if you have a cornerhost account, you should be able to log in with your normal username and password.
Once I get my data in there, I think I'll have a pretty solid infrastructure for delegating both my support and my development work.
For the time being, though, I'm still working out of my inbox. My goal for today is to go through and answer everything, and if there's anything I can't fix immediately, create a ticket or an issue so the customer can get email updates as when work on it later.
The step after that is to go through my huge list of projects and get them into roundup so I can start doing what I really want instead of settling for a tech support day job.