Blog

Antti
Tarvainen
21 / 2 / 2012

What do we think of ourselves?

Wanting to find out how we feel about our company, I asked everyone in Leonidas to answer an anonymous survey of three questions. Here is a summary of the results, the good and the bad.

We can assume that an employee only recommends Leonidas to his friends if he believes it is a great place to work. The first question was thus: “Have you recommended Leonidas as a workplace to any of your friends in the last 12 months?”

Here are the results:

What makes Leonidas great

To learn why people felt this way, I asked a free-form question about what we do well. The actual question was “What are the most important things that currently make Leonidas an easily recommendable workplace?” I’ve collected below the aspects that were mentioned most often:

“Passionate skillful workmates.”

Although the exact words varied from “professional” through “craftsmaship” to “slick hackers”, fourteen answers mentioned that Leonidas has skilled people whom it is great to work with.

“No unnecessary bureaucracy or Dilbertism. Very flexible going regarding employee wishes and needs.”

Compared to most companies Leonidas has little bureaucracy. People trust each other, and it is easy to change things when needed. As an example, everyone has a company credit card he can use to order anything he needs in his work.

“General enthusiasm for learning and making great software.”

Learning new things and becoming better in the old things is ingrained in Leonidas culture. People feel Leonidas supports learning well both in the work and outside it.

“Good atmosphere and nice people.”

Leonidas is full of friendly people with good attitude. We like to work with each other and have fun together.

Things to improve

In any workplace there are things that can be improved. So I also asked what would make Leonidas an even more easily recommendable employer. Two things were mentioned by more than two people.

“Some consider the warrior image embarrassing.”

Leonidas currently has a curious image of low-brow high tech, which does not mesh well with how many of us see ourselves. We also highlight our prototyping offering aggressively, which does not adequately communicate how good we are at building actual production software. We create beautiful working software and we want the world to know it.

“Doing more things together / hanging out just for fun.”

We are a pretty fact-oriented and‚ dare I say, masculine crowd, so sometimes we inadvertently build imaginary walls between ourselves. Because we like each other, we want to tear down those walls. We should spend more time together. And maybe we should hire some of those feeling-types to remind ourselves of our love toward each other.

All in all, it looks like we are on the right track, but as always, there are things we can improve. So let’s get back to work and make this an even better company.

Toni
Jyrkinen
26 / 1 / 2012

Get your invite to RekrySauna

We are always on a quest to find the next superstars of software development, thus I present to you our next recruitment camp: RekrySauna. During the night you will get to know most of our enthusiastic team and discuss both job opportunities and ways of making great software in a relaxed environment.

The event will be held on February 9 at Teekkarisauna (Tekniikankatu 9, Tampere) from 17:00 onwards. If you love creating things using bleeding edge technology, please contact us with your CV at Sauna@LeonidasOy.fi. Let us know why it makes a difference for you to be invited, and we will get back to you as soon as possible. You may also come and say hi to us in Tietotalo, TUT before the event between 12:00 and 16:00.

Sami
Hangaslammi
18 / 12 / 2011

Introducing the Leonidas CodeBlog

Antti
Tarvainen
2 / 12 / 2011

Answer the Right Questions with Prototypes

Prototypes validate ideas. Rather than basing plans on guesses, you create something concrete and put it to the test. But what kind of a test? That depends on whether you are aiming for a sustaining or a disruptive innovation. The distinction helps us ask the right questions and build the right prototype. As a consequence we eliminate waste and create an effective innovation process.

Sustaining and disruptive innovation

The division of innovation into sustaining or disruptive types comes from Clayton Christensen and his book The Innovator’s Dilemma. In brief, the theory states that incumbent companies constantly build better versions of their existing products. They become experts at serving their core customer base, but are not quite as good at serving new markets. This is called sustaining innovation.

Incumbents are vulnerable to disruptive innovation that can occur when someone else comes up with a whole new value proposal. The new product may be worse in many respects than the incumbent products, but it more directly addresses the needs of its market. Because the makers of the existing products see the market differently, they may not even consider the disruptor a serious competitor at first.

The difference between sustaining and disruptive innovation, thus, relates to the product’s value proposal. In sustaining innovation, the values are the same as those pertaining to the existing products. Disruptive innovation, on the other hand, uncovers a whole new set of values.

A textbook example is how the iPhone became the leading smart phone. Before iPhone, in 2007, smart phones had a rather small market. The most important and valuable features of smart phones were ordinary phone features, along with the ability to write emails and use a calendar. When the iPhone arrived, it was worse than the incumbents in many ways: it had poor sound quality, it dropped calls, it lacked 3G, it didn’t have a physical keyboard, and it was very expensive. So, to the core group of techno-savvy business users, it was not nearly as attractive as the other choices. However, it had certain benefits that made it attractive beyond the traditional core group. It had a user interface that was a delight to use, it acted as an iPod, and it had the best web browser on the market. It was a new kind of smart phone for a new kind of user.

Both disruptive and sustaining innovations have their place. Markets and competition are marked by short bursts of disruptive innovation, followed by long stretches of sustaining innovation before the next disruption. After the disruption in 2007, the smart phone industry has seen four years of sustaining innovation. Practically all current smart phones now look like iPhones, and they are all better than the original iPhone. The competition is about who has the best features and the best specs; that is, who can generate sustaining innovation.

Coming back to our subject, when we create a prototype, the distinction between sustaining and disruptive innovation is important to us. We should know why we are doing it, and what questions need to be answered. This depends heavily on whether our innovation is sustaining or disruptive.

The questions in disruptive innovation

When creating something disruptive, everything is uncertain. We have an idea for a new kind of service or a new kind of customer that we are going to reach with our product. Yet, we don’t know for sure whether the targeted customer has any desire for what we are planning. So, we want to make sure that a market exists for our product.

Examples of questions to ask at this point:

• Would anyone use our product?
• Would anyone pay for our product?
• Would the use of this particular product spread among customers? Would there be enough growth to sustain our business?
• If not this product, then what would make users happy?

Often, the best way to answer these questions is to build a prototype, show it to potential customers, ask the right questions, and listen to their feedback.

Qualitative feedback may be all that is required. You meet a few potential users, and see how they react. The caveat, of course, is that the use of the product during these interviews is not the same as real use. The consumers whose feedback is being solicited may feel the urge to please the interviewer with their answers, so their responses cannot be blindly trusted. Interviewing users is a skill all on its own.

It would be better to obtain quantitative feedback as well. Depending on the target market, it might be a good idea to put the prototype out into the world, market it to potential users (e.g. via search engine text ads), and see how many sign up. This produces a concrete metric for the degree of interest in one’s customer base.

The questions in sustaining innovation

Sustaining innovation is different. You already know the customers and what they value. You want to improve the product you have, or enter the market with a product that is essentially the same as that of the competition, only better in some respects. In any case, you already know two things: what you are comparing your product against, and what aspects you want to improve.

Prototyping has a place in this sort of innovation, too. The improved version has not been built before, and you are unsure whether it performs as well as expected. This uncertainty can be reduced by asking the right questions and then answering them with a prototype.

Some questions you may ask at this point include:

• Would this improvement produce the efficiency benefits that we thought it would?
• Would users choose our product over the competition’s product, based on this feature?
• How often would they use this new feature?

The questions depend very much on the type of improvement at which one is aiming. If a new feature is being created, the questions relate to the use of the feature and its benefits. On the other hand, if you seek to improve the production process, the questions relate more to efficiency, and so on.

Quantitative metrics should be used when answering these questions. For example, with regard to process improvement, you could measure the difference in the use of resources (such as time) compared to the original version. When planning a new feature, an alpha version of the feature could be released to a set of customers in order to assess how they use it.

Qualitative metrics have their use here, too. It may be expensive to build a sufficiently-good prototype to answer questions quantitatively at first. In that case, the qualitative questions should be posed first to decide whether it makes sense to continue along the current path, or to make changes. Then, a better prototype can be built to measure things quantitatively.

Eliminate waste

One way to look at prototyping is that it eliminates waste from the innovation process. At the start of innovation, the most important result of one’s work is information: i.e., whether the current idea works, and whether it can be improved. So, what creates accurate and relevant information is valuable; what does not, is waste.

Instead of paying, and waiting, for an entire product to be completed, the construction of a prototype will help you to answer the questions quickly and effectively. However, it is not enough to build just any prototype. Ask the right questions, and you will eliminate a huge amount of waste. It is important to know whether your innovation is sustaining or disruptive. The questions are different, and the prototype will differ accordingly.

The division between sustaining and disruptive innovation is just one factor that can alter the questions to be answered. It takes skill and experience to know what the right questions are, and to build a prototype that best addresses those questions. We can help you.

Tomi
Laine
29 / 11 / 2011

Frozen Rails 2011

In September we had a week of conferences. Leonidas sponsored Tampere Goes Agile here in our hometown, while Edvard and Janne traveled to Strange Loop in St. Louis, and Sami visited the ICFP conference in Tokyo. Meanwhile, Toni and I went to Frozen Rails in Helsinki to hear the latest buzz from those in the Ruby on Rails world. We decided to look back on our Frozen Rails experience.

One of the sessions we most looked forward to was Jeff Casimir’s talk entitled “Blow Up Your Views.”  He called for a better separation of views and business logic. We had already been going in that direction in our projects: minimizing data transfer to a plain template and JSON while letting the browser do the rendering. Jeff’s presentation entertained us quite a bit and merged well with our view of how web software should work.

Are developers also designers? Developers should have at least a basic knowledge of design to avoid pitfalls because software is valuable only if it is usable. Jarkko Laine’s talk entitled “Full Frontal for the Backend Pack” was a reminder of the importance of interaction design in web apps. One of the things he talked about was using HTML5’s History API to maintain linearity in browsing, which is exactly what we have been doing when moving a rendering to the client side.

We were excited to hear Zach Holman talking about maintaining flow at GitHub. They avoid metawork, work asynchronously via Git, and use a simple branching strategy similar to ours. But above all, they love great software and creating it, as do we. We don’t go as far as communicating with pull requests to avoid interruptions, but we do have the ticking of a Pomodoro timer to indicate flow. Some parts of the GitHub method probably work well only when you are developing something like GitHub though.

The guys at GitHub presented another session towards the end of the conference, and Aman Gupta gave the most information-packed talk of the conference about debugging performance issues in Ruby. In a little less than an hour, he introduced us to a dozen tools, providing brief explanations and use cases. Obviously, we didn’t have enough time to learn everything there is to know about the topic, but he gave us a good idea of what tools will be handy and where to look for them.

It was nice to note the feeling of connection and unity within the Rails and Open Source community. The atmosphere felt very casual, and it was easy to strike up a conversation with just about anyone. We returned to Tampere feeling invigorated and excited.