Here's a question to managers and startup and founders out there, but first a bit of context on my situation:
We are a small team that has recently created. As such, we've been given a fair amount of control over how the team are structured. This involves everything from how we work, how we progress in our careers and how much we are paid. While this is a really nice position to be in, it raises a number of concerns.
In an ideal world, I believe that a flat structure would be best. We are all technical people, working on a series of short (months in length) projects that tend to be self contained. There is no immediate need of a hierarchy. But in this case, how do you define “progression”?, both how people are paid, and their “title” within the group.
To get around this, the obvious answer is a well defined “hierarchy”. Progression and pay are well defined ahead of time and everyone knows how it works. The problem is that we have only just been created, and as such the variance of the pay within the group is big. Initially this isn't an issue – we all agreed to be here for the amount we are paid, but over time it can become an issue: without well defined progression, this issue of separate pay will become an issue and half the group will leave.
Another problem (and a separate one, one that we will also need to address) is that judging the direct merit of each others work is hard. Mostly because the work is a spectrum between “core” work, that is required, and “new features” which can bring in a large profit (or fail), and disentangling the two is hard.
There has to be somewhere in between these two position. And we can't be the first to find ourselves in this position, and I'd like to here from others who have been here:
- What worked well?
- What worked badly?
- What would you have done differently?
Next, if you (as developers naturally do) struggle with the idea of management, structure and order, read "The E-Myth Revisited".
Peopleware TL;DR: Good teams are united by a strongly defined purpose (eg. get X defined and tests written by date X), and that is almost NEVER the same as the goals of the business (which is to make money). Don't create internal competition; overtime kills productivity; physical/mental space allows creativity; interruptions are deadly.
The E-Myth TL;DR: Aimed at small business owners, but as a team lead you're effectively running a business, and the rest of the company is your customer. It's a mere 5 hour read... JFDI :)
And if you're feeling really bookish, "The Mythical Man Month" - if you're under 50 this will shock you, because you'll realise that software in 1970 had the exact same problems that we do in 2015.