Super long Article: How Zano Raised Millions on Kickstarter and Left Most Backers with Nothing

I saw this tweet on my timeline.

I really wanted to read it but I only had 15 minutes for it. So I bookmarked it and tried to skip past, but curiosity got the better of me. I followed the link, scrolled all the way to the bottom and spotted this bit:

Way too long; didn’t read

That was a heading of the super short summary. So I read that part, and it was insightful. If and when I managed to find time again, I might read the whole thing. But for today, that section of the article makes up my recommended reading.

Source: How Zano Raised Millions on Kickstarter and Left Most Backers with Nothing — Medium

Software programmers are not blue-collar workers

Like many skilled workers, software developers are smart creative people. Leading or managing such people requires finding a way to guide, support and empower them, while letting them do their job. Writing software is inherently a process in which trade-offs and compromises are made continually and iteratively till the end. It is therefore essential that all parties stay as close as possible together so that they can weigh decisions when it matters and actively take part in the game.

Like many skilled workers, software developers are smart creative people. Leading or managing such people requires finding a way to guide, support and empower them, while letting them do their job. This sounds easy, but I have seen many organisations and individuals failing at it, leading to the very issues they were trying to prevent. The recurring mistake people commit is that they treat skilled workers in the same manner that they would do blue-collar workers.

I have built and managed technical teams throughout my career, I’ve always been aware of the need to balance communication with smart and skilled folks like software developers. I continuously practice software development myself. By staying hands-on on both sides of the equation, I’ve continuously kept tap of the challenges involved. It’s one thing to be programming, but leading and managing developers is an entirely different game.

Instructions can be crippling

Some believe in providing extremely detailed instructions to developers, as a way to manage work. That is misguided for a number of reasons. Every software programming endeavour is as unique as can be. Micro decisions need to be made at every step of way, the conditions that might have been prevalent in a prior project context would have been largely superseded by new ones. However detailed, instructions will leave gaps that developers will run into. As such speed bumps are encountered, people want them to be removed swiftly and they would feel better if they could that themselves. If developers are not properly empowered, such gaps will lead to frictions, could cause tensions and result in defensive behaviours. While well intended, detailed instructions is not a very effective instrument for managing software development work.

If everything goes, nothing does it

The other extreme to too much instructions is having none. Without any guidance, anything goes. Such software development will lead nowhere. For software development to succeed, all those involved should be able to describe in a consistent and coherent manner what the aim is and what the final product should be. Software developers don’t work in isolation of other units in an organisation, they need to know what is intended, what is expected of them. An optimal set of guidance accepted across teams is a necessity, not a luxury. Working out exactly what such guidance is and how much of it is needed, is part of the job that leadership must facilitate.

Bean counting may be useless

Some are painstakingly tracking developer hours, lines of codes, and other misleading metrics, in the firm belief that that is the way to manage development resources. For the kind of work that doesn’t require thinking or coming up with solutions, typically repetitive tasks, that may yield some results. In software development projects this is a fruitless endeavour, developer productivity does not lie in any of those things. Bean counting is only useful if used anonymously as a learning tool, and perhaps as supporting documentation in the event of a dispute over resource usage. This last one is typically what software consulting bureaus are worried about, they then unfortunately put so much emphasis on it that it becomes a damocles sword over people’s head. Finding the metrics that matter is a skill.

Perfectly codified work is demotivating

If software development work could be codified to such extent that it could be flawlessly executed without any thinking, exploring, personal problem solving skills, then nobody would ever want to do it. That would be the most boring job ever for anyone. It makes people feel insecure, a feeling that could be summed up in an imaginary thought quote:

If I am not bringing anything special to this work, I can be easily replaced by someone else, or a robot! I don’t like that. I want to be perceived as being special to this project, I reject any shoddy instruction that would make my job look plain and simple.

This is also something that team managers and leaders should be careful about. When providing guidance turns into hand-holding, people stop thinking for themselves and the group may walk blindly straight into trouble. And when trouble strikes, finger pointing is often what follows. Besides, people learn when they can get themselves stuck and work their way through hurdles. When the conditions are right, the outcome will almost always exceed expectations.

Architecture: just enough guidance

Writing software is inherently a process in which trade-offs and compromises are made continually and iteratively till the end. It is therefore essential that all parties stay as close as possible together so that they can weigh decisions when it matters and actively take part in the game. In my experience, what works well is to provide just enough guidance to developers so as to establish appropriate boundaries of play. When that is well understood, leadership must then work to establish metrics that matter, and closely manage such metrics for the benefit of all those involved.

Treating software developers as blue-collar workers to be told “here, just go and write software that does this and come back when it’s done” is fatally flawed. People who typically make such mistakes are:

  • project managers, who are clearly making assumptions that only they espouse and neglecting the basics of creative work process
  • architects, who believe that developers are lesser capable workers that just need to do as told, follow the blueprints
  • technical managers, who have the impression that managing people is about shouting orders, being perceived as having authority
  • people enamoured with processes, tools and frameworks, oblivious of the purely human and social aspects of software development

In my experience, the root cause of such mistakes are relics of obsolete management practices that favoured hierarchy over social network. Note, my use of the term social network has absolutely nothing do with the multitude web sites that hijacked this vocabulary. By social network, I am referring to situations when a group of humans are engaged in making something happen together, it is social because of the human condition, and it’s a network because of the interdependencies.

This subject is vast and can be treated over a much larger text than I am doing here. In this post I’ve only touched upon a few of the most visible and recurring aspects, I’ve stopped short of discussing issues such as applying learning,  methodologies or tools.

If you recognise some of the shortcoming listed above in the context where you are in, and if you are in a position to influence change, I suggest that you at least initiate a dialog around the way of working with your fellow workers.

Software is hard: things get lost in translation

Software can be hard, especially when one is not prepared for it to be so. When something goes wrong, more often than not people are looking at the wrong place or laying blame at the wrong place. This blog provides an oversimplification of the issue.

It’s a euphemism to state that software is hard. It’s hard work. Anything seriously worthwhile is going to take grit and toil. Don’t let all the self-help marketing tell you otherwise, if you do you would actually make it even harder for yourself.

One reason software can be hard is that snowball effect is very common and can quickly result in avalanche-like consequences. So I wrote one reason, not the only reason, not the main reason, just one reason. I am not going to produce long studies, hard numbers or anything of that kind here. Instead, I give an oversimplification of the way the snowball effect, the trickle down with an ever-expanding area of influence, can be visualised.

Illustration, how small issues can trickle down
Illustration, how small issues can trickle down

Whenever something goes wrong, which is to say very often, a good way to go about finding solutions is in re-examining things all the way from the top and work your way down. Which place to start, which direction to go (top-down, or bottom-up ) is a matter of taste, choice, context, but usually just a personal one. Since, quite clearly, it is a complex matter, looking for solutions in a random manner can be extremely inefficient and may never yield any result.

A corollary of this situation is that, software can result in ever-expanding benefits if things go well. Such benefits could be much more than winning the lottery for example. If you revise the diagram, take expressions like “things can get in the way”, “human condition”, “distraction” and turn them respectively into “things can contribute”, “human insight”, “epiphany” or “serendipity”, and you have a different diagram and positive outcome.  Concerns like “fear”, “doubt”, “politics”, “unexpected changes” typically have a double-edged sword effect to them. These can have positive effects when properly leveraged, or negative effects when they actually lead us to inaction or unproductive behaviour.

With software, bad things and good things, don’t only travel top-down or bottom-up, they typically start somewhere and expand like fluid dropped on a piece of absorbing cloth.

Whether are a manager or a doer, next time people rush into quick explanations or laying blames, invite them to look just a little further, to take a deep breath, to just sleep it over, and reconsider their positions. More often than not, the outcome could be different. Taking that chance to just delay conclusions a tad is usually a good bet, a profitable investment strategy.