Andrey Khavryuchenko himself

On software development business: startupping

Yurii Rashkovskii recently blogged about the structure of (consulting) software development house.

There he suggests:

Here we come to a structure for a consulting company that I like. Instead of being employees of some company, professionals of different kinds (i.e. developers, designers, sales, etc.) could team up and define their rules of game transparently. They can decide which cut of income is being spent for what — like 10% for reserve fund, 50% to developers, 30% for designers and 10% for sales. In this structure they are all in charge and if they could play together efficiently, nobody will be frustrated.

Doing this business for 10 years, I’d say that this plain idea won’t work as expected.

The real issue is that every person in such software development team should

• understand what he’s doing; that is the team has to have a quantitative model of their business
• share the common goal – why they are doing that? To become rich one day? To do an interesting stuff? Or what?
• share all or at least knowingly distribute the risks

I’d say that all these three points are nearly impossible to have at once.

Take, the model. Hardly any of the software shops, I’ve seen, has a live documented software development process. I mean not the documents from ISO 9K ok CMM certification bundle that’s safely collecting dust somewhere. I mean the process that’s actually used and measured.

Let alone any company would be able to say and prove with numbers that they’d reach some milestone with 95% budget and clock time accuracy.

So I would safely cross out item 1 from “dream team” checklist.

Given that there would not be a quantitative verifiable reference, everyone in the team would understand the main business process differently. And that would lead to misunderstandings, conflicts and broken trust.

Moreover, even if at some point of time, team converged on the common understanding of the ultimate goal, they will still differ on the plan to reach it. No verifiable company model will lead to different predictions and actions of the team would become unfocused pretty early.

Alas, crossing 2nd item. Hardly they’ll have a common goal for a long time, necessary to build a sustainable business.

Finally, the most complex stuff. The risks. I find that just handful of developers understand that at all. We’ve too accustomed to the deterministic nature of our workhorses – computers. We tend to forget that real world is much more complex that any of our workstation and just could not be analyzed in every detail. Some should be viewed from statistic viewpoint.

I’ve seen no team that would be able to answer the question of when the particular piece of software would be finished and why. Those, who where “the best” at this always put the most risk on the end developers: they had to work overtime, under constant stress, lower quality and, of course, with no or little extra compensation.

Since that basic question could not be answered yet, how can each team member assess the impact of his action (or non-action) on the team and his personal revenue risk? What should guide him to make his frequent decision: “What’s better: spend couple hours refactoring or developing new feature?”

That way someone will alway try to underplay others by lowering his personal risk, no matter how it affects the company risk profile.

Summing it up, the attempt to build such a team, would reach the common attractor: those who have most of money and information will take nearly all monetary risks and, in attempt to refund them will strike a “solid company structure” upon the rest, who will bear the clocktime risk.