Ask HN: How do you manage your development team?

5 points by plasma 7y ago ↗ HN

Hi HN,

I lead a modest team of 4 developers, and our entire company is 7 people.

We use Pivotal Tracker [1] to keep track of bugs and features, and a spreadsheet with a high level roadmap set quarterly.

Monday morning we have a development team meeting to review current/future tasks based on business/dev priorities.

This process is okay, but we find there are ad-hoc, mid-week challenges I'd love to tackle better:

a) How best to triage ad-hoc requests from sales (feature improvements/requests) or customers b) Resolving product bugs/integration issues that may appear and need to be resolved that week c) Responding to ad-hoc requests from BD (eg, produce a report). Google teaches me this is 'toil' and to look towards automating these tasks, which were done, but there are still fringe requests. d) Allow development to work in their own priorities (internal improvements, refactoring, bug fixes, tooling, ...) amongst feature requests and customer-facing bugs that need to be resolved e) Ideally we had someone dedicated each week to resolving issues/bugs, not new features, but never done this.

We have some techniques to address many of these, but I feel we could do a better job so that during the week we are shielded from ad-hoc changes of our priorities mid week.

Any feedback appreciated, thank you!

1 comment

[ 4.3 ms ] story [ 14.0 ms ] thread

trcollinson 7y ago ↗

So I handle this in one of two ways depending on the needs of my company.

So first, you use pivotal tracker so you can do it the "pivotal way". (* Disclaimer: I am not a pivot but I worked with them for about 2 years as a client in their office.) Basically it's the extreme programming methodology. Have a prioritized backlog. Make sure items aren't too big (pivots shoot for 2-4 items complete per pair per day). Do not plan out a week at a time. Just make sure everything in the backlog is sized and appropriately understood by anyone on the team at all times. When a team member needs something to do, take the top item. It works surprisingly well. If you have a new bug and it takes priority over everything else, it's the top item on the list and the next available person takes it. The most important thing is always the next thing. After a while, you get used to people understanding how the backlog works in the business and if they want new big features, they stop adding requests to the top of the backlog.

Second, the "Basecamp way". Much longer time frames (I use 6 weeks). Buckets of work that are split out. Here's a page that describes it: https://m.signalvnoise.com/how-we-structure-our-work-and-tea...

I've found great success in both. I'm currently using the Basecamp way. I'm very open to questions if you have them.