Category Archives: company

Find yourself some pigs

Posted by on June 13, 2012 No comments

I’ve heard this story first time from Yatin Gajjar, senior Sun Microsystems engineer in 2007 when I’ve visited their Palo Alto offices. We were talking about our very young startup at that time, and the story of pig and chicken was brought up. I never new the origins until I’ve found that the metaphor has been applied to agile development and scrum. Of course it makes perfect sense.

In the context of startups, having a strong core team is paramount. You cannot build anything just on your own. It is always a team. It is never an individual. The team that will push the development, company and community building activities forward, against the obstacles and difficulties. Pop culture glorifies individuals, because it makes it easy and we like the narrative about them. Teams are messy. Team dynamics is never something easy to talk about, never clean and tidy. But, there is this need for strong, core team where everyone can carry their own weight. This is something I’ve understood pretty early on. However, what I have discovered just recently is my inability to quickly distinguish between chickens and pigs. And this is extremely important skill to have if you are a founder. I guess it comes from experience and trying things out with multiple people on a number of occasions. It takes good people skills to be able to tell quickly who is who. It also relates to you as a founder. If you are not committed, you will end up doing what you do as a hobby, and you will never reach the critical escape velocity to take your venture off the ground. So be honest with yourself – are you a pig or a chicken in your startup adventure?

The bottom line is:

  • you have to be a pig; be honest with yourself
  • you have to find other, like-minded pigs, to help you pull it off; at least one; one is good
  • you have to avoid chickens, at least initially; chickens are not good core team material; they will be invaluable later on

Three-day monk

Posted by on June 2, 2012 No comments

Sometimes I start something passionately, dedicate myself to the cause, and fully immerse myself in an activity. It can be anything – starting a new project, doing a proof-of-concept, or starting an essay for example. If a goal can be reached within one or two days, I often succeed. However, if the goal requires more time, it often drags for weeks, or years. More often it makes for an abandoned project.

Japanese have a phrase: 三日坊主(みっ・か・ぼう・ず）which roughly translates as three-day monk. It means exactly that. It means I am hyped up, fully committed, fully dedicated, but for a very short time. Only to fall back to my old ways and habits, and never achieve what I’ve set myself to achieve.

The way to avoid the three-day monk trap, is to dedicate  some time to the activity every day. To make it a daily habit. It does not need to be long amount of time – it can be short. But consistently bring the activity to the forefront of your mind, and to do it. Keep doing it. If you plan to blog or start new project – go to your blog and write a draft, or a beginning of a draft, or a first sentence. Start. Next day come back, add to it. Next day add more. You do not have to spent hours or days on an activity. You do not have to immerse yourself for extended periods of time. Doing it more frequently and consistently will bring better results.

 

What defines you

Posted by on May 13, 2012 No comments

Direct vs. Indirect control

I often spend a lot of time planning, envisioning, and wishing for a particular outcome to happen. It occurs in different areas of work – in software projects, in design, in management. This is normal. This “wishful thinking” gives us direction and focus. It helps to identify elements and activities that shift odds in our favour. This “wishing” helps to create a plan. It does help, indirectly, to achieve our desired outcome. And so on. This is how we all get some things done. We “wish” for something to happen, we do “our thing”, and then the outcome happens. As we wished for, or not.

Often, the outcome decides if the undertaking is considered a success or a failure. This is a form of mental jump that we do. A form of “simplified thinking”. The trap is that our “wishful thinking” and “outcome” blur the value of our work with all the value that is created in spite of us. Our mental processes blur the elements that are in our direct control from the elements that are not in our direct control.

Craftsmanship

One realisation that occurred to me is that things that are in my direct control are, by far, much more important than things that are not. And, what’s more important, things that are in my direct control define me, whereas things that are not in my direct control, do not. What follows from this is that the outcome alone does not define me. This is somewhat counter-intuitive and a bit entangled, so let me explain. I work on a project. I control a number of elements, e.g. the quality of the code, the usability of the interface, the architecture of the system, the engagement of end-users, and so on. Those things are in my direct control. These factors shift the odds of the project being adapted and used by users. But, I do not control directly the end-user uptake. I can only, indirectly, influence it, and I can shift the odds by doing high quality work, but there is a number of elements that will always be beyond my control. The trap is that I often disregard those elements, and treat them as if they were non-existant. This is a mistake for two reason: first, I lose focus on things that are in my control, and second, I tend to take credit (or blame) for things that were completely out of my own control or influence (things that just happened, in spite of my own efforts or doing).

The result we wish for is often a combination of elements in our direct control, together, with elements that are outside, elements that we do not control directly. Focusing only on the outcome might distract you from the quality of your work. Instead, you should direct your focus to all the elements that are in your direct control.

Instead of the outcome, you should let the quality of your craftsmanship define you. 

The interesting paradox is that the outcome of a project is strongly influenced by the quality of work and all the elements in our direct control. Hence, the elements in our direct control and the actual outcome are entangled. Focusing on the mastery and the craftsmanship will ultimately help to achieve the desired outcome and it will prevent taking blame (or credit) for things that are beyond our control.

 

Programming: the art of writing

Posted by on April 24, 2012 No comments

To some people, especially those who cannot program computers, the art of computer programming seems more like “monkey and typewriter” type of activity. This misconception is far from the truth. Computer programming is a complex and highly rewarding intellectual activity, much closer to writing a novel, than conducting an engineering task. The art of computer programming always appealed to me — it is a vast land somewhere on the intersection of science, mathematics and artistic expression of myself. Focus, creativity, discipline, and an inner sense of beauty, all have to come together, for the final piece to be created.
Sure, there is a lot of bad software around. Same as there is a lot of bad novels or films. Especially those created by committees and executive boards. There is, however, a growing number of small indie developers writing high quality, beautiful software.

Stephen King said: “The scariest moment is always just before you start.”

Programming is a skill, a tool, that you can use to express yourself. It is a way of being in the world. How to get started? First, you have to master the craft itself. Simply write. Write code. Write software. For yourself, for your mom, for your friends. Keep writing. Anything. In any language there is. There is no other way but doing it. Start small. Tasks that can be achieved in under an hour will work for you like etudes for musicians. Practice.

“Talent renders the whole idea of rehearsal meaningless; when you find something at which you are talented, you do it (whatever it is) until your fingers bleed or your eyes are ready to fall out of your head. Even when no one is listening (or reading, or watching), every outing is a bravura performance, because you as the creator are happy. Perhaps even ecstatic.”

Then, once you grow and become more confident, plan bigger. Plan a novel or plan a symphony. There is lots of parallels between writing computer code and the act of writing, in general. You need to have the concept in your head. You need to feel it, you need to know what it is. Then, you need to organise a routine, a discipline, and let the creativity take over.

An excellent and accomplished writer, Stephen King, has written a spectacular book “On Writing: a memoir of the craft“. The book provides many insights into the process of being creative, and how to write. It applies to computer programming, too.

“There is a muse, but he’s not going to come fluttering down into your writing room and scatter creative fairy-dust all over your typewriter or computer. He lives in the ground. He’s a basement kind of guy. You have to descend to his level, and once you get down there you have to furnish an apartment for him to live in. You have to do all the grunt labor, in other words, while the muse sits and smokes cigars and admires his bowling trophies and pretends to ignore you. Do you think it’s fair? I think it’s fair. He may not be much to look at, that muse-guy, and he may not be much of a conversationalist, but he’s got inspiration. It’s right that you should do all the work and burn all the mid-night oil, because the guy with the cigar and the little wings has got a bag of magic. There’s stuff in there that can change your life. Believe me, I know.”

The advice on making a first prototype (or first book draft as he calls it):

“I believe the first draft of a book — even a long one — should take no more than three months…Any longer and — for me, at least — the story begins to take on an odd foreign feel.”

And, how te evaluate your proof-of-concept:

“Write with the door closed, rewrite with the door open. Your stuff starts out being just for you, in other words, but then it goes out. Once you know what the story is and get it right — as right as you can, anyway — it belongs to anyone who wants to read it. Or criticize it.”

Talking on entrepreneurship

Posted by on April 22, 2012 No comments

Murad Kamalov research seminar talk “Is entrepreneurship an option for University Graduates?”

Last month, Tomek and I were hosting in Dunedin a researcher and entrepreneurial from Helsinki Institute for Information Technology (HIIT) and Aalto University, Murad Kamalov. Murad is Ngarua‘s collaborator and co-founder of doThinger. He has spent 4 weeks developing functionality and talking about startup life and entrepreneurship in a number of venues around Dunedin. One of the presentation he has done was during the monthly CodeCraft meeting, and another during the weekly research meeting of the New Zealand Distributed Information Systems group.

Murad has discussed the history of entrepreneurship activities in Aalto University and how a group of students started a movement that results now in initiatives that raise multi-million investments and engage over 400 participants in the launch events. He has discussed how StartupSauna and Garage48 work. Getting a successful startup off the ground requires more than just pure technological excellence. It requires the environment in which strong teams of complimentary skill sets can be established, it requires proper mentoring and support environment, experimentation and exploration.

We believe entrepreneurship and startups can be a valid option for university graduates, especially those with technical backgrounds and ability to develop proof-of-concept ideas rapidly using in-house skills. What do you think?

 

Physical server room.

Posted by on October 31, 2011 No comments

Our server room, also known as an office, has been emptied yesterday. We have migrated all our infrastructure to the hosted managed solution, and moved out of the physical room. None wanted to work in there. No windows, cramped, poor lighting, and isolation provided somewhat spirit crashing atmosphere. It was great with few people in there – we had good times on meetings and various celebrations. But the costs of keeping physical server room vs. managed hosted solution outweigh the benefits.

We have been in Centre for Innovation for about 5 years. That’s a very long time, and a lot of things happened in there. The most important milestone was the lesson of agility and outsourcing. Moving out and moving on. Not easy.

The art of interviewing

Posted by on November 19, 2010 No comments

Today School of Business at University of Otago organised a workshop about interviewing. There have been 4 speakers from various disciplines sharing their experiences. There are some of the notes that I’ve taken during their presentations.

The first set of guidelines was focused on interviewing children, but some of the recommendations are well applicable to adults too. Avoid power relation, make the participant feel comfortable, perhaps wear clothes and hairstyle that mimicks your participants, choose a neutral location, bench or lawn outdoor may work well, joint lunch or just eating something, and background noise (park, cafe) helps to establish a common platform and keep a conversation flow. Always test your own questions on yourself, to see how comfortable you might be going into some of the topics yourself. Be empathetic about your participant, and do not push the envelope. Keep the conversation flow going, and not be disruptive with the topics and questions. Try to integrate them into the flow as uninterruptedly as possible. If some of the questions or topics are not covered, bring them up at the end of the session. All the themes/questions/topics must be prepared in advanced, but the actual flow of the interview should follow the natural course of the discussion/conversation. Be adaptable. Use dictaphone, and only takes notes about topics to bring up at the end. Focus attention on conversation, not note-taking. Try not to be judgmental in any form or shape, about the topics being covered, or the opinions expressed by the participant. Try not to impose your own opinion on the participant.

Naturalness is very important, but it is rather difficult to achieve. Tape recorded is essential, but use it with care, it tends to skew the participants. Be flexible about the protocol. Try not to follow religiously laddering style interview as it tends to annoy people.  People are quite apt to report when and what they have done in the past, but may not be able to tell the reasons why they have done something or decided on something. Try to explore why people do things: reasons, motivations, objectives. One technique to try out is triadic interviewing (show three elements and ask for similarities and differences, so that the participant is forced to provide a deeper analysis of a subject matter).

Ask for comments and questions at the end. Take photographs, notes and comments about the context in which the interview was conducted: it will help later to reconstruct the context and remember details of the conversation.

Use: audio, notes, drawings, photos, video, etc if appropriate. Always take backup batteries.

There are some interesting issues related to the ethics of the interviews, on record and off record statements. Be open, honest, transparent and personal.

Programming: the fun of creating something

Posted by on September 3, 2010 No comments

I was talking recently with few (more senior) friends and they all told me that even though they cannot spent as much time programming as they used to do few year back, in their early days of academic career, they immensely enjoy the activity and try to find time to continue doing it.

There is something incredibly fulfilling, something very satisfying in the activity of creating something from nothing. Programming comes as close to the ideal as one can imagine. There is nothing to start with, and all that is needed is an idea. Just a thought. Then you need to think more about it. And more. And then you start to express your thoughts in a structured way. In a program. And a bit more, and then, suddenly, there it is. Something real. Made up almost exclusively in its entirety out of our creative thoughts.

Something concrete has been created. Out of your thoughts. People can interact with it. Can use it. It can change people’s life.

Programming is fun, and as close to the pure joy of creation as one can get. It can all be done almost entirely in your own head. Does not require lots of resources. You can always do it. In your spare time. Hey, you can make a decent living just doing it for a job.

Anecdotal Evidence: US IP Lawyers are still doing quite well

Posted by on July 23, 2010 No comments

My sister works for a small legal firm in Seattle, where they manage IP portfolios. Even though most of the US economy is struggling, my sister’s firm is growing very quickly. When you consider the fact that the US economy has spent years migrating away from wealth production, in favor of wealth management, then this isn’t a very surprising development.

Otago Innovation Seminar Series

Posted by on July 22, 2010 No comments

July 16, 2010, Friday, Otago Innovation Seminar Series,
CFI – Centre for Innovation
Speaker: Peter Foster from Symansis.
Spent 9 years in research area in Lincoln, UK (postdoc). Then 30 years in the industry, doing R&D.

What’s important:

  • Good idea must meet a well defined market need.
  • Good project design and project scheduling.
  • Make sure you have IP protected (you have to lock a market niche).
  • Be prepare to fail. Fail early, cancel projects early. Not all projects succeed.

There were a number of challenging questions that Peter posed and tried to answer. Among others:

  • Are you ready to fail? Can you survive initial failure? How long can you carry on without external funding?
  • How can you access available market? Market channels? Distributors? How to reach your customers?
  • Questions: direct sales or distributors? Own label or white-label?
  • Novel products require you to think about educating the users, and prospective users. Make sure the current users write about their use and experience to others. This is very important. Try to encourage them to publish about your product.

Developing a product that hits the market is a huge step, big leap from having “just” a prototype.

Tenacity.