As your startup’s software development team grows, interesting and unexpected things happen.
When I worked at the opposite of a startup, Microsoft, development was divided into three roles. I was on a team of Program Managers (PMs), we worked with a team of Developers, and then there was a team of Testers.
In a nutshell, nobody wants to be a tester. Developers hate Program Managers. And Program Managers dress well while trying to tell everyone what to do.
In the beginning
Forgetting Microsoft, let’s look at a typical startup.
From what I see, most technology startups are founded by quite good (but not great) software developers. Founders are seldom very, very good developers because the very top percentile of coders are usually too geeky, socially inept, and bad at making and understanding what normal people want. But still, startups are usually founded by developers that are pretty good at writing software but are also good at program management. What is program management? Much of program management is about prioritization: it’s about creating an idea, and allocating your own or other people’s time to making it happen. Product Managers worry about the user’s needs and building “value”. If you’re not good at being user-focussed ideas and prioritization, you’ll be a bad PM, and you probably won’t ever get to the point of being a founder.
So anyway, the stereotypical startup begins with a program manager / developer hybrid that makes a proof-of-concept that people really like. Then she thinks to herself: I need more developers to make this real.
As the team grows to three or four developers, a problem arises: the new developers are really good at writing software but aren’t as good as the original founder (who now no longer has time to write lines of code) at focusing their time on things that really drive value. The founder gets worried: “how come when we tripled our team, our output hardly doubled? How come we’re not building the right stuff and the developers are wasting time on the wrong stuff? And how come we always argue and they won’t just do what I tell them to do?”
Getting to this point is normal: It’s common that an alpha, perfectionist, gifted founder will worry about why her team isn’t producing as much value as she thinks she could.
It’s at this crossroads that a weird contradiction occurs.
The contradiction
When developers are not working on user-centric, valuable things, one’s tendancy would be to go the Microsoft route, by ordering them around through a newly hired PM.
But founders don’t want to do that.
Why? Well first, PMs are a waste of money: what the heck will they be doing most of the time? And secondly, PMs are usually the thing founders hate the most, bad PMs are why the founder quit their old job — I’ll come to this later, but the fact is that the very best developers hate being told what to do all the time and good founders know this instinctively.
Still, if a founder isn’t going to hire someone to order developers around, a contradiction becomes more and more obvious because of the following two clashing truths:
- Great developers are usually bad at deciding on what to work on
- Great developers hate being told what to work on
Gah! So what to do?
Well if you don’t do anything, here’s what will happen: everyone will fight a lot. You’ll have hour long meetings talking about whether or not to have a very insignificant feature, and by the end of the meeting, everyone will hate each other and no decision will be made.
So one solution, the easy solution, is to be (or appoint) a dictator. This is mentioned in a post on the Freshbooks blog (they’re talking about design but I believe it still applies).
Dictatorship, in my opinion, is bad. It’s bad for a number of reasons including the following:
- Dictators are selected by power, not merit. So there is inevitably a situation when the decision maker is not the most qualified, and even if a more qualified person joins the team, there is no system to dethrone the dictator.
- Dictatorships don’t scale well, and what if she gets hit by a bus?
- No one (no one) wants to work under a dictator. Result: unhappiness and lack of satisfaction. Dictatorships go against the “empowered employee” philosophy.
- Most importantly the best developers turn into sucky developers if you start dictating over them
If there is too much fighting and nothing is getting done, then a dictatorship might be a good idea. But as soon as things stabilize, look for ways to restructure where you can have the benefit of progress without the deficiencies of a dictatorship.
So if hiring people to tell the developers what to do is a bad idea, and you can’t just let inexperienced developers just do whatever they want (because then they will start recoding everything in ruby, then realize that ruby locks too much, then start working on developing their own C extensions to ruby to make it non-thread-locking, and then everyone will forget what you were building in the first place but congratulations for improving ruby, here’s a glass statue).
So how do you get out of the contradiction?
I have a few suggestions:
The goal for you as the original PM for your product (when you were managing yourself), is to, instead of being the PM to all the new developers, is to teach them how to be good PMs too. Like anything, being good at something doesn’t make you a good teacher.
Teaching is empowering; dictating is demeaning.
How do you teach PM to devs? In teaching, you create a feedback loop; the tighter and stronger the loop, the faster things learn.
See, the developers that you had that were working on tasks that were a waste of time, they were doing this because they are disconnected from the results of their actions. So all you have to do to encourage teaching is to stop isolating devs in cubicles, and expose them to the results of their actions.
Some things to try:
- Make developers present their own work at conferences
- Make developers present their work to you and other non-technical members of the company
- Make developers talk directly to investors
- Connect developers directly to the support email box, so they hear right from the customers (this works!)
- Reward good, on task work with positive words and emails (this goes a long way)
- Instead of just conveying requested features, spend more time talking to your developers about the underlying values and problems you’re trying to address. Over time, the individuals on your team will self-learn how to convert abstract values into work items.
The goal for you is to remove the layers usually present between the work a develop does and the people that it affects. For example, if developers are seeing their users’ pain, they will want to fix it. Furthermore, the goal is to give direct credit and ownership over projects — people put their heart into things they own.
Aren’t there some things that just can’t be done in a team?
I’ve often heard it said that certain work just can’t be done on a team. You can’t write a great novel in a group, for example. I encourage you, if you think that way, to think about novel ways in which you can change the nature of what you’re working on so that it does work in a team. Because there is so much to risk if you design your processes so that “one dude makes the final decision” — the biggest risk being that none of the great software developers I know would ever work on such a team: they will quit.
There are times when multiple people on your team will have contradicting opinions on subjective things. I still believe that there are innovative ways to make decisions. Use testing, for example, to make different designs compete against each other. “Let’s try your suggestion for a week or so and test to see if these X and Y metrics change” is a fair, diplomatic way to solve an argument.
Teaching and management have something in common — there is no magic formula. Some of your developers will want to be managed more closely, some will work best when point form feature requests handed to them, but, still, everyone wants to feel ownership and self-determination.
Good luck!
