Mission Statement

MS: Make it useful 5

So we have this blog, Mission Control. But we have no clearly defined mission, I guess. Let’s fix it.

I was recently asked about our Mission Statement, and even though I believe those are useless, it made me start thinking. And I figured I need to pull the series of posts about our mission. Just so to make sure everyone is on the same page. It is the first priority for a manager to make sure that no ambiguities squeezed in. So let’s get started.

Archimedes Lever/Wikipedia

Part 1: Make it useful

I have (successfully) delivered dozens of projects in my career. Actually, it is over 100, perhaps. Thing is, that out of them, I vividly remember about 10. That’s the point. Yep, only 10%.

I do not mean that the projects were not worth remembering, or that we did not do anything cool on it. I trust we did. Of course, technology evolves and these days what we done 8-10 years ago many would find not that cool. But this will always be the case with technologies…

Yes, for the matter of fact, in great deal of these projects I participated in senior roles and did not dive deep into details. But that does not make any difference for the remembering things.

What does matter is the fact, that on all projects that I do remember, I had witnessed the great follow-up on after-launch.

Simply saying, I saw people making use of the software that we developed. Either it was big-ass payment app that processed mlns of dollars, or it was the smaller simulation program that helped with cancer fighting in the UK, or completely tiny mobile app for the advertising game. So, size isn’t relevant. Technology isn’t that relevant (especially that it changes so fast). In all the cases, I knew that what we just did this was important cause it was useful for people.

Again, I am not saying that the rest of the projects that I do not remember that vividly were useless. I believe, most of them were pretty useful. It is just that we as developers did not get to have any feedback after delivery. We aim to change that.

So here comes the first point for the mission statement:

We are here to make useful applications that people will remember.

It’s ok that not all of the products last as long as the Ford Mustang on the picture above. Reality changes and we may not all get lucky to develop such masterpieces. It should be useful for the time being. And of course, we try to develop timeless pieces of software…. But that’s the point of the next post. Stay tuned. And pls, participate in discussion in comments.

5 Responses to “MS: Make it useful”

  1. Yury Kusik says:

    In my opinion, you can make useful products only when you really (I mean REALLY) care: when you believe in the idea, in the chosen way of solving the problem and you know that it is the best way to do it so you’re excited to see the results. Ideally – when you need the product yourself, and you want to use it in your day-to-day life. Well, yes, you can lead the product development getting the understanding of what it should be from current or potential users, customers, from generic market research and analysis of competitors, but it will never be as good as it could be if you really needed it yourself and therefore _naturally_ cared about it.

  2. Yep, this is known as “Eat your own dog food” or “Scratch your own itch”.
    For custom software developers it is not always possible…

    Care about the project is key. If there is no feedback from the users/customers on after-launch, developers naturally stop caring. This is what kills the culture of outsourcing houses as they grow bigger.

    Well, we are here to fight it, among other things. So, literally, the “so people will remember” part is Itteco’s senior management responsibility when “people” refers to “developers”, not “end-users” in this sentence. Once this is consistently being achieved, it is developers’ responsibility to take care of “end-users & customers will remember” piece.

  3. Yury Kusik says:

    I agree that “dogfooding”, as one of the best reasons to care, is rarely possible. But I wouldn’t bring users/customers feedback as a next reason to care :)

    My point is that intrinsic interest is more valuable, than one stimulated by the feedback. You can be just naturally interested about certain domain areas (e.g. somebody gets excited about certain solutions for financial market, and can’t care less about gambling sites and vice versa).

    Sometimes I come to check some projects/sites I worked on to see, how they developed since last time. And sometimes I even check the projects which I wasn’t even excited about, the projects I was sure that the approach was wrong, but still had to work on the project the way customer asked, so I come just to check if I was wrong being skeptical.

    I think the problem with “remembering” is, that the outsourcing model is “develop and forget” more often than not: it is expected to get something right with the first shot, on a fixed time and budget and that’s it. Usually, there’s no culture of long-term engagement, culture of “reworking” things, so people can’t just get attached to multiple projects that come and go.

  4. intrinsic interest – I sense the math background is speaking here :) .

    In real-life, people need to see the results. It’s like as if you are gone fishing, but actually not motivated by the real fish…

  5. Yury Kusik says:

    :) Ok, i can rephrase it as “intrinsic interest in results, in domain area”. I called it “intrinsic”, because it is rather created by person itself than by somebody else (either management or clients/customers).

Leave a Reply