Diary of a Software Manager

Custom work is tough to turn down. I really admire the way the folks at 37signals vow only to add features that make their core products better for all their users. Unfortunately, not all businesses are as successful as they are. It’s really tough to turn down money when your profits are thin. Enter the custom project.

We recently had a bid accepted by a large company everyone knows by name. They liked one of our products and want a whitelabel version of their own. With three weeks left until launch of the product, they asked for about a month additional work to be done. Again, we couldn’t turn down the money. The result was that I had to move resources off another project to work on this additional bit. A couple of bugs and misunderstandings later, I’ve had most of my team working on this project for the last month.

While everyone is off working on the custom project, we’re not taking care of our other products. We’re not fixing important bugs, we’ve pushed other dates back, we’re ignoring other customers requests. These things tend to drag on. If you’re going to take on custom work, make sure the check is big enough to cover the increase in staff you’ll need.

I work for a company who provides software products and services, but is not a software company. Historically, the methodology we follow is based on sales selling whatever they possibly can and development rapidly developing whatever “it” is. There is typically no thought given to what we should be focusing on. One of the fundamentals of the agile methodology is the idea of a constantly prioritized backlog. This idea is easy to lose sight of in small companies. Profits might be thin and it’s tempting to build whatever a customer will pay for.

When I took over the group I manage, every person in the company was welcome to visit any developer on the team and request that their top priority were completed. To help alleviate constant interruptions developers had to deal with, I started handling all requests. At some point, it occurred to me that I might not be the best person to set the priorities of the company. I’d like to have a say, but not the whole say. The more I read about agile, the more it made sense to have a product owner.

Ideally, the backlog would constantly be prioritized and before every sprint, we’d just grab the first N number of items off the stack to work on. This is a simple and brilliant concept. It keeps developers developing without constant interruption and ensures the most important features are always worked on.

I’m still struggling with changing the culture to mirror that of a software company instead of a machine shop where we can just flip a switch and have our developer machines output a different widget. Hopefully we get there and we get to see the results of implementing such a noble goal as to institute an ordered backlog.

Good read from Luke Wroblewski (as always) about 37signals design process. I already talked about how enamored I am with Rework. The thing that strikes me about Luke’s post, is how feedback is handled. Sorting through feedback is one of my most important jobs as a manager. You get lots of ideas about how cool “this feature” might be. It’s the manager or designers job to figure out where users are having problems and fix them, not to implement every single feature that is requested.

In 4 separate emails today I wrote something along the lines of:

As far as a date for this, we don’t have any. The next thing up for us is [project X] but we’re still ironing out exactly what that means. We can’t even estimate the work with any kind of accurately until we break it down. If we broke down every request that came in to where we could accurately estimate it, we’d never develop anything.  Also, it’s almost assured that priorities will change before we finish what we’re working on now. Here’s a link to the roadmap, that’s the best I can do.

I give that response so much I should just attach it to my email signature. I do it in the hopes that if I repeat it enough then it might start to sink in. I drive my boss insane when I do things like this, yet I won’t give it up. It’s a difficult thing to sell the idea that dates are not important, especially when you work for a company where almost all of the senior management staff come from backgrounds other than software. To me, it seems insane to look back on a long history of missed dates which were arbitrarily given by someone who didn’t fully understand what work was required and demand we keep doing it.

I’ve been immersed in 37signals founders Jason Fried and David Heinemeier Hansson’s Rework. It’s hard to single out one point since the entire book has been so enlightening, but one bit that hit home was the need for a curator.

You don’t make a great museum by putting all the art in the world into a single room…The best is a sub-sub-subset of all the possibilities.

At my company, we constantly run from feature to feature, implementing solutions that are about 80% complete and moving onto the next thing. The result is a lot of half baked and buggy features. At a museum, the curator is responsible for choosing what pieces to display. What isn’t on the walls is as important as what is on them. If you are going to implement something, do it well. If you don’t have time to do it well, don’t do it.

I’ve been on a long hiatus and broken my rule of a post a day. We decided to put the house on the market and it took what little time I have away. Since feedburner tells me I only have 4 subscribers, I’m guessing I wasn’t missed too dearly. Anyway, I’m back now and hope to keep it up!