The economy of unicorns

Team leaders and managers try their best at matching the financial goal while maintaining good vibes among their subordinates. May it be in a very hierarchical company or one with no official one, you’ll find wonderful people that are driven to make things happen, to help others cross the finishing line and put that final point at the end of the book. Their wingmen work at the Human Resources, gently writing down the current problems, the future ones, and setting a list of what is needed.

That unicorn we need ASAP

From my experience and point of view, the IT problems rarely root into productivity issues, while the common ones can be easily pointed out on bad design, bad architecture, bad documentation, bad tests, bad planning, bad reporting… In fact, any domain that needs more than writing some code down until it seems functional. You can’t guess everything right before the start – but you’d think after decades of web development the companies would have already white marked all of the common mistakes, and why observing steps and processes is crucial.

What I more than often observe are projects facing internal problems, which quickly launch a chase for an external solver, to the point where the only developers left with consistent knowledge about the application and its entrails, are simply expelled one after the other – or quitting – while the replacements onboard the sinking ship, often not prepared or warned about the depth of the “sea-ssues” they will have to cross.

By a pinpointed and nitpicking list of skills, or a warm and friendly approach to anyone willing to do some sort of code, a unicorn has been found in the company, or freshly hired; while the internal, measurable problem never has been adressed. This is almost always justified by costs – an argument which puts an end to any questioning or in-depth analysis.

In the end it became sort of a norm to use developers as disposable bandages on wobbly projects, snatching the worn ones for fresher ones. As time passes and the application lives its life, the client naturally expect the cost to lower even more, while his expectations on results stay high – so are the expectations of managers and recruiters. That’s how a company ends up chasing unicorns : developers that will do better than the preceedings with not only less time, less money, and less knownledge but with a messier project.

Developers want to be unicorns

We have our wobby project, and now our unicorn must not only be productive and effective, but of course socially appreciated and integrated. Because we need to maintain the team vibes, and seriously, who wants a hardcore nerd when it’s 2018 and programming is a thing. Nowadays there’s a social pressure in the IT field that adds up to the professional one.

At the core of computer programming lies a concrete but easily found inheritance from our nerds ancestors: intellectual performance. At times when the cliché programmer was lonely in his field and passion, his motivation deeply rooted in the science of code itself. As it consists in automation of tasks and problem-solving, so the first computer specialists grew their field exponentially thanks to the incredible intellectual performance they brought.

When it became a flourishing business, this inner representation of one’s self as a code performer, a master of intellectual abstraction, transformed the frogs into princesses. This historic need for intellectual recognition in the field of IT, met a growing capitalism. For the worst, capitalism feeds on this kind of recognition’s need : everything becomes more of a competition. But one you don’t always easily unmask, as it is an internalized value which the individual carries within him – while it is a key to his or her social integration.

I think this situation explains why there’s so much of a turn-over among IT companies; why there’s so much shiny new frameworks, methods and tools developed all the time; why there can be endless debates around the better solution while no further digging about the problems is made.

From our first job to our whole carreer path, we are teached to believe our end goal is to become that employable, adjustable, friendly – simply magical – unicorn. The unicorns get the raise. And to be part of the IT unicorn herd, damn, you’ve got to be certificated, learn two or three new things every year, master a frightening amount of tools, keep afloat sinking ships and staying socially faultless.

Designing by design*

* Design is the creation of a plan or convention for the construction of an object, system or measurable human interaction.

Basically, you take decisions on the concrete doing of something.

The impressive rise of new methods for planning, organizing, deciding – and such – is the first type of answer to the problems I evoked above, that companies seem to be willing to invest into. While I frankly dislike the use and abuse of shiny “new” and “fun” methods without pragmatic reasons other than temporarily motivating teams to finally do the actual thinking and designing they are paid for, I recognize it’s a breeze of fresh air in the IT world.

This trend of re-thinking everything and anything, taking another point of view, playing legos and drawing stuff is on something. Yes, the digital future depends on our capacity of designing it right, which requires imagination and anticipation. The very basis of our work is to sit down and find ways of making our abstract thoughts into something concrete.

Redeveloping a sinking Java application into a React one, redesigning the look’n’feel of a disliked application, making UX workshops with the users, searching innovation through messy drawings, creating new shiny roles in the team... The trend wagon won’t be more or less useful than the previous tools you had on your project. You know that you weren’t using them the right way – or at all. New tools just give the feeling of novelty which motivates your employees for a bit, like a new coffee machine would – but what an expensive one.

The first step to face a project’s problems is find out what part of the design did you refuse to invest in, and why. Designing is about making choices about the “how-to” – when you took a bad decision, you should invest in finding why and learning from your mistake. Leadership is hard precisely because you must assume your choices and make your team follow the goals that are set – even when it’s difficult.

Keep lying to yourself or your team about the end goals, the economic context or your choices, and there’s a bad design that’s going to be made somewhere along the line – I bet another unicorn or magical wand quest will then begin.

The IT economy is by definition pragmactic : any company sets its first goal to making some money to pay the checks and the electricity bills. Stop trying to hide that kind of fact, beating around the bush, finding fake qualities in the client, and be honest about the other important things.

By doing that, not only will you use that energy in more productive ways, but you will give your team the actual keys to think, and design by the budget and by the context. Expectations of performance will be more realistic, lowering the team stress-level and making the whole project more friendly, keeping developers aboard and making the whole thing stable. Stability is required to build any bridge or building. You should keep that in mind while building an application.

The beauty of contracts is that your commitment details are written down – work with facts, not unicorns.