Balancing personal energy and greatness in product design

About 3 min reading time

When coming fresh from school (if you went to one) as a programmer or designer in an early stage startup, chance is that you’re used to do things the right way when building.

In lab assignments, there is often a single correct, fast, and beautiful solution to the problem at hand. Very little is left to “real world factors”. The only parallel with the real world would be that there’s a deadline to things, but other than that, the problem is usually well constrained, has a clear definition of done, and is quite isolated in the grand scheme of things. You bring that set of problem solving mindset with you, which of course is great and what you go to school for.

Then in your first real world venture, you’re surrounded by tough sprint deadlines, performance problems you have no fucking idea about what they are, a not-so-perfect code base that should’ve been split up into proper abstractions several months ago. And other things. Like lack of automated testing, proper QA processes, and a list of Issues at GitHub which is growing.

What do you do? What do you do?

You try to make it as good as you can. As always.

You might be able to pour your heart and soul into the product, to do all those grand schemas and refactors and redesigns that you thought about from day one. But what about the long run? How long will you be able to attain that energy? Balancing that personal energy, fire, of yours is something I think is crucial. Without your creative fire, there’s just a machine that churns out code or pixels.

After a while, you either get depressed and produce things you deep inside perhaps aren’t that proud of, or, you find the sweet balance. Think of everything you’ve taught yourself this far, put it in a blender and create a mix that is informed, pragmatic, and contextual decisions.

Just as in the lab assignment, there usually is an optimal solution to a startup problem at the moment. Go find it! It might involve you not being able to create a whole new design language for the web app, or that you need to seduce dark forces in order to get some micro services to speak with each other in horrible ways.

I’d guess that your company even expects you to manage this balance, since it probably doesn’t want you burned out after six months. Working in a startup is a marathon, not a sprint (or is it in fact a marathon of sprints? Nobody knows).

Many programmers and designers with little startup experience are colliding with the “business folks” at a company in the beginning, since the latter always are optimising for financial success. The former are usually optimising for correctness, order, and simplicity in all their forms. In a startup’s case, its survival is hanging on financial success (VC, profitability — in one way or another), so the former group has to release their desire for correctness, and get on the train. It’s painful, but totally doable.

I used to be quite focused on making things perfect some time ago. Perhaps not perfect, but make it really, really good, even if few people used it. I could sleep at night, got a few pats on the back from the colleagues. But for what? Don’t get me wrong — building quality things are super important. A cohesive, pretty, and reliable experience is gold. But all the other things are not. There are thousands of things you can do, what are the things you should do? About “Saying no”, and so on.

A common saying is:

A job worth doing is a job worth doing well.

But what is “well” here? Is “well” the same as “shipping it”? Perhaps a better saying is

A job worth doing is a job worth doing.

in the sense of that if a task is important enough, you should do it. Otherwise not.

After some time, you’ll almost work as a machine when landing on the crystallised conclusion: when you’re able to identify the work involved, the end result (a definition of done), and priority. Exactly like the lab assignment in school.

This focus of energies is just as important in work as in life. Your energies are precious and finite.

(By the way: I hope I’m not coming off as a know-it-all by writing this in second person format. It’s just easier for me to formulate myself when I think of me telling this to myself).