Tag: entrepreneurship

  • Value for Money

    There’s one observation that I pretty much always bring to the table when I discuss the rates for our work at Lunar Logic. The following is true whenever we are buying anything, but when it comes to buying services the effect is magnified. A discussion about the price in isolation is a wrong discussion to have.

    What we should be discussing instead is value for money. How much value I get for what I pay. In a product development context, the discussion is interesting because value is not provided simply by adding more features. If it was true, if the following dynamics worked—the more features the better the product—we could distill the discussion down to efficient development.

    For anyone with just a little bit of experience in product development such an approach would sound utterly dumb.

    Customers who will use a product don’t want to have more features or more lines of code but they want their problem to be solved. The ultimate value is in understanding the problem and providing solutions that effectively address it.

    Less is more mantra has been heard for years. But it’s not necessarily about minimalism, but more about understanding the business hypothesis, the context, the customer and the problem and proposing a solution that works. Sometimes it will be “less is more”. Sometimes the outcome will be quite stuffed. Almost always the best solution will be different that the one envisioned at the beginning.

    I sometimes use a very simple, and not completely made up, example. Let’s assume you talk to a team that is twice as expensive as your reference team. They will, however, guide you through the product development process, so that they’ll end up building only one third of the initial scope. It will be enough to validate, or more likely invalidate, your initial business hypothesis. Which team is ultimately cheaper?

    They first team is not cheaper if you take into account the cost of developing an average feature. Feature development is, however, neither the only nor the most important outcome they produce. Looking from that perspective the whole equation looks very differently, doesn’t it?

    This is a way of showing that in every deal we trade different currencies. Most typically, but not necessarily so, one of these currencies is money. We already touched two more: functionality or features and validation of business hypothesis. We could go further: code quality, maintainability, scalability, and so on and so forth.

    Now, it doesn’t mean that all these currencies are equally important. In fact, to stick with the example I already used, rapid validation of business hypothesis can be of little value for a client who just needs to replace an old app with a new one, that is based on the same, proven business model.

    In other words in different situation different currencies will bear different value for a purchasing party.

    The same is true for the other side of the deal. It may cost us differently to provide a client scalable application than to build a high quality code. This would be a function of skills and experience that we have available at the company.

    The analogy goes even further than that. We can pick any currency and look how much each party values that currency. The perception of value will be different. It will be different even if we are talking about the meta currency—money.

    If you are an unfunded startup money is a scarce resource for you. If at the same time we are close to our ideal utilization (which is between 80% and 90%) additional money we’d get may not even be a good compensation for lost options and thus we’d value money much less than you do.

    On the other hand, if your startup just signed round B funding abundance of available money will make you value it much less. And if we just finished two big projects and have nothing queued up and plenty developers are slacking then we value money more than you do.

    This is obviously related to current availability of money and its reserves (put simply: wealth) in a given context. Dan Kahneman described it with a simple experiment. If you have ten thousand dollars and you get a hundred dollars that’s pretty much meh. If you have a hundred dollars and you get a hundred dollars, well, you value that hundred much, much more.

    Those two situations create a very different perception of the offer one party provides to the other. They also define two very different business environments. In one it is highly unlikely that the collaboration would be satisfying for both parties, even if it happens. In the other, odds are that both sides will be happy.

    This observation creates a very interesting dynamics. The most successful deals will be those when each party trades currency that is low-valued for the one that is valued highly.

    In fact, it makes a lot of sense to be patient and look for the deals where there is a good match on this account than to jump on anything that seems remotely attractive.

    Such an attitude requires a lot of organizational self-consciousness on both sides. At Lunar Logic we think of ourselves as of product developers. It’s not about software development or adding features. It’s about finding ways to build products effectively. It requires broader skills set and different attitude. At the same time we expect at least a bit of Lean Thinking on account of our clients. We want to share understanding that “more code” is pretty much never the answer.

    Only then we will be trading the currencies in a way that makes it a good deal for parties.

    And that’s exactly the pattern that I look for whenever I say “value for money.”

  • Why We Fail to Change

    I’d love to get a beer each time I hear a story about management imposing a change on teams and facing strong resistance. It would be like an almost unlimited source of that decent beverage. Literally every time I’d fancy a beer I’d be like “Hey, does anybody have an agile implementation story to share?”

    One common excuse is that people don’t like the change. That is surprising given how adaptable humankind has proven to be. I rather subscribe to the idea that people don’t mind the change; they don’t like being changed.

    Unfortunately being changed part is the story of oh so many improvement initiatives. Agile implementations are among most prominent examples of these change programs of course.

    So how is it really with responding to changes?

    First, it really helps to understand typical patterns of introducing change. The model I find very relevant is Virginia Satir’s Change Model. Let me walk you through it.

    We start with existing status quo that translates to a performance level. Then we introduce something new, which we call a foreign element.

    Virginia Satir's Change Model 1

    Then we see an expected improvement and they lived happily ever after. Actually, not really. In fact whenever I draw that part of the model and ask what happens next people intuitively give pretty good answers.

    After introducing a change performance drops.

    Virginia Satir's Change Model

    It is kind of obvious. We need time to learn how to handle a new tool, practice, method or what have we. Eventually, we get better and better at that and we start seeing the results of promised improvements. Finally, we internalize the change and the cycle is finished.

    Because of its shape the curve is called a J-curve.

    It is an idealized picture though. In reality it is never such a nice curve.

    Virginia Satir's Change Model

    What we really see is something much bumpier. It is bumpy already when we maintain status quo. It gets much bumpier when we start messing with stuff. It’s not only that rough average goes down but also worst case scenario goes down and by much more.

    It’s pretty much chaos. In fact, that’s exactly how this phase is called in the original Virginia Satir’s model.

    Virginia Satir's Change Model

    An interesting observation we can make is that the phase called resistance is a short one that happens just after introducing a foreign element. Does it mean that we should expect resistance against the change to be short-lived?

    Yes and no. Yes, if we consider only “I’m not even going to try that new crap” type of resistance. It is typically driven by lack of understanding why the whole change was proposed in the first place. There is however the whole range of behaviors that happen later in the process that we would commonly call resistance too.

    Some people aren’t ready to see, even temporary, drop in performance and once they face it they propose to get back to the old status quo. When facing a stressful situation many people retreat back to what they know best and the old ways of doing things is exactly what they know best. There are also those who are impatient and not willing to give people enough time to learn the ropes. The last group often includes managers who funded the change in the first place.

    In either case the result, eventually, is the same. More resistance.

    Virginia Satir's Change Model

    Inevitably we reach a pivotal moment. We’ve been through the bumpy ride for quite some time already and yet we haven’t gotten better. In fact, we’ve gotten worse. Not only that. We’ve gotten worse and less predictable. The whole change doesn’t seem like such a good idea after all.

    So what do we do?

    Virginia Satir's Change Model

    Of course we reverse the change and go back to the old status quo. Oh, and we fire or at least demote that bastard who tricked us into starting the whole thing.

    One interesting caveat of the whole process is that a change is not always simply reversible. When we changed specific behavior and yet didn’t get expected outcomes reverting the behaviors may be difficult if not impossible.

    For the sake of the discussion let’s assume we are lucky and the change is reversible. We are back to the late status quo and we simply wasted some time trying something new. Oh, and we built a stronger case for resisting the next change. We petrified the existing situation just a little bit more.

    One reason why changes are reverted so often is the perceived risk of the change.

    Virginia Satir's Change Model

    Pretty good proxy for perceived risk is predictability. Typically the more unpredictable a team or a process is the more risky it is considered. In this case, the important thing that comes along with a foreign factor is how much predictability changes. Not only does performance drops but it also becomes much less predictable.

    While the former alone might have been bearable, both factors combined contribute to the perception that the change was wrong in the first place.

    There is another dimension that is very interesting for the whole discussion. It is the scale of change. How much we want to change the existing environment: team, process, practices, etc.

    Virginia Satir's Change Model

    We can imagine a series of small changes, each modifying the context only slightly. The whole series lead to a similar outcome as one big change rolled out at once.

    We can call one approach evolutionary and the other revolutionary. We can use inspiration from Lean and call evolutionary approach Kaizen and revolutionary one Kaikaku.

    Virginia Satir's Change Model

    Fundamentally the J-curve in both approaches would be shaped the same. The difference is in the scale. The revolutionary change means one big leap and rolling out all the new stuff at once. This means a single big J-curve.

    The evolutionary approach introduces a lot of tiny J-curves one after the other. In fact it is possible to have a few of changes run concurrently but let’s not complicate the picture any more.

    What are the implications?

    Virginia Satir's Change Model

    Let’s go back to the scale of the risk we undertake. With Kaikaku unpredictability we introduce is much higher than what we’ve seen in the late status quo.

    Kaizen on the other hand typically go with the changes small enough that we don’t destabilize the system nearly as much. In fact it is pretty likely that unpredictability introduced by each of the small changes will be almost invisible given that we don’t deal with fully predictable process anyway.

    The risks we take with evolutionary approach are much more bearable than ones that we deal with rolling out one big change.

    That’s not all though.

    Virginia Satir's Change Model

    Another thing is how much destabilization lasts. In other words what is cycle time of change.

    Big change, naturally, has much longer cycle time as it requires people to internalize much more new stuff. It means that exposure to the risks is longer. Given that the risks are also bigger it raises the odds that the change will be reverted before we see its results.

    With small changes cycle time is shorter and so is exposure to the risks. Again, not only are the risks much smaller but also they are mitigated much faster.

    One last thing worth mentioning here is that so far we optimistically assumed that all the proposed changes have positive outcome. That is not always true.

    With the evolutionary approach even if some of the changes don’t yield expected results we still gain from introducing others. With a revolutionary approach each part that doesn’t work simply increase likeliness of reverting the whole thing altogether.

    It is not to say that Kaizen is always superior to Kaikaku. In fact both evolutionary and revolutionary approaches have their place. Stuart Kauffman’s Fitness Landscape helps to explain that.

    Stuart Kauffman Fitness Landscape

    Imagine a landscape that roughly shows how fit for purpose your organization is. It should simply translate to factors such as productivity etc. The higher you are the better.

    The simplest and safest way to climb up would be to make small steps uphill.

    Stuart Kauffman Fitness Landscape

    While the approach works very well, eventually we reach a local peak. If we continue our small steps in any direction it would result in lower fitness for purpose. Simply said we wouldn’t perform as well as we did at the peak.

    If we look only at the closest terrain we might as well say that we’re already perfect and there’s no need to go further.

    Stuart Kauffman Fitness Landscape

    Obviously, someone saying that wouldn’t be treated seriously. Well, not unless we are discussing a patient of a mental facility.

    The solution is seen when we look at the big picture. If we moved to the slope of another hill we can get better than we are.

    Stuart Kauffman Fitness Landscape

    That’s exactly when we need a big jump. It doesn’t have to automatically land us in a better situation than the one we’ve been at initially. The opposite would often be the case. What is important though is that we land on the hill that is higher. That translates to bigger potential for improvement.

    Stuart Kauffman Fitness Landscape

    Once there we can retreat back to good old strategy of small steps that allow us to climb up. Eventually we reach the peak that is higher than the previous one. Then we can repeat the whole cycle looking for even a bigger hill.

    Of course, similarly to the case of J-curves the picture here is idealistic in a way that each change, be it small or big, is a successful one. In reality it is more of experimentation. Some of the changes would work, some not.

    Stuart Kauffman Fitness Landscape

    As you might have guessed, small steps here represent the evolutionary approach or Kaizen. A big jump is an equivalent of revolutionary change or Kaikaku. Depending on the context one or the other will be more useful.

    In fact, there are situations when one of the strategies will be basically useless. That’s why introducing change without understanding current context is simply begging for failure.

    One more implication of the picture is that, given lack of any other guidance, evolutionary approach is both less risky and more likely to succeed. That’s why I prefer to start with when I’m unsure about the context which I’m operating within.

    One last remark on the Fitness Landscape. What you’ve seen here is a heavily oversimplified view. In reality fitness landscape wouldn’t be two-dimensional. Stuart Kauffman discussed it as three-dimensional model although I tend to think of it as of a multi-dimensional model.

    It means that each change can improve our situation in some dimensions and have an opposite result in others. We will have different combination of effects in different dimensions – some more desirable and some less.

    If that wasn’t enough the whole landscape is dynamic and it is continuously changing over time. In other words, even after reaching local optimum we will need further continuous improvements to maintain our fitness for purpose. The peak will be moving over time.

    I know the post got long by now (thank for bearing with me that far by the way). This is however the starting point for the discussion why introducing the change very often triggers resistance. It provides pretty good explanation why some many improvement initiatives fail. This is also one of my answers to the question why many agile or lean adoptions are doomed to failure from the day one.

    Trying to significantly change an organization without understanding some underlying mechanisms is simply begging for frustration and failure.

    Finally, understanding the change models will influence the choice of the methods and tools we’d use to drive our change programs.

  • Minimal Indispensable Feature Set

    Minimal Viable Product (MVP) is such a nice idea. Let’s build something that is as small as possible and at the same time viable, which translates to “provides value and thus make sense to build it.” Two adjectives in a mix where one counterbalances the other and vice versa.

    Since I currently run a web software house I hear the term MVP very frequently. Or to be precise I hear the term MVP being abused very frequently. On some occasion the viable part would be ignored. Much more frequently though the way people understand MVP has virtually nothing to do with the minimal part.

    During the early discussions about products our potential clients want to build I would typically ask about a business case behind a project or an app. It’s not about what it is that someone wants to build. It’s about why it is worth building that thing in the first place.

    Note, I’m not judgmental. We contributed to better or worse ideas but I don’t reserve the right to know what’s worth building and what’s not. In fact, my questions have a very different purpose. What I want to achieve is to learn the value behind the app so that we can have a meaningful discussion about stuff in a backlog.

    Now, this is the part where typically I’d really like to have people read Lean Startup before they are even allowed to talk to any software shop about building their product. And then, read it once again to understand what they are reading in depth.

    The reason is that most of the time I can instantly come up with a batch of work that is one third, one fifth or one tenth of what was labelled an Minimal Viable Product by a potential client and it would still validate a business hypothesis behind a product. It likely means that with a bit of effort and better understanding of the context our clients would be able to cut it down way further than that. It may mean that they’d be even able to validate the basic idea without writing any software at all.

    These so called “MVPs” wouldn’t recognize a real Minimal Viable Product even if it kicked them in the butt.

    A sad part is that most of the time discussion around what really is minimal is futile. While I can provide my insight and encourage to learn more about the topic an argument often boils down to “we really need to build it all because, well, we don’t believe anything short of that would work.”

    The long story short, I believe that MVP is in the top 5 most abused terms in our industry. By now referring to MVP is mostly meaningless unless you ask a series of questions to understand what one means by that. We could have skipped he MVP part, have the same discussion and we’d save a little bit of time.

    That’s why I believe we need another frame for discussing what the initial increment of a product is.

    What I caught myself on a number of times was proposing our clients a different constraint. Let’s step aside from discussing what is minimal and what is viable. Let’s figure out which features will be the part of the product in every single, even most crazy, scenario that we can think of. And I really mean every single one of them.

    What I try to achieve with this discussion is to find the set of features that is a common denominator for all the options of building the product. There’s always something like that. A core process that the app support. A basic idea that the app is built upon. An ultimate issue that the app attempts to solve.

    What I don’t expect is to see the full solution, even the most basic one. It would be an MVP on its own and we’d be back to the square one. What I expect is just a bunch of bits and pieces that are required to eventually build the app.

    It is neither minimal nor viable.

    It is indispensable though.

    There are a couple of reasons to do that. The first one is that it reframes how both parties, the client and us, think of a product. We don’t try to settle on what is viable and what is minimal. We simply go with something that we know will be useful.

    The other one is that it addresses the huge challenge of building a relationship. In fact this part goes really deep. It typically starts with a question how much building something would take. Some sort of an estimate. Well, it’s another thread. I’m not fundamentally against the estimates and see value in understanding generally how much something would take. At the same time I acknowledge that humans are simply not well equipped to estimate as we can’t learn to assess stuff in abstract measures. At the end of the day though, the smaller the batch size of work the smaller the potential risk and the smaller the estimation mistake.

    In other words the smaller the initial batch of work the easier it is to start working.

    It is true from another perspective as well. The most important modifiers of the cost of building a product in a client-vendor scenario isn’t anything related to the product itself. It is the quality of collaboration. It’s about both parties feeling like they’re the part of the same team. It’s about short feedback loops. It’s about working together toward the goal.

    Unless it is about lack of transparency, distrust, and exploiting the other party.

    The tricky part here is that you don’t know where at this spectrum you are until you start working. Building the smallest possible batch of work together pretty much gives you all the knowledge you needed. Seriously, you don’t need more than just few weeks to get a good feeling where collaboration part is going.

    That’s why this the idea of Minimal Indispensable Feature Set is so useful whenever more than a single party is involved in building a product.

    Minimal Indispensable Feature Set is perfectly aligned with building an MVP. In fact it is a subset of an MVP. At the same time it addresses the part of the setup that goes way beyond simply defining of what product is.

    We live in a world where more and more frequently the building part is outsourced to another party. Getting the collaboration right at least as critical as getting the product idea right.

  • Project Management in One-Man Project

    Recently I came across a very interesting question on Project Management Stack Overflow. The question is how to organize project management in tiny projects, where everything is done by a single person or just a couple of them.

    The interesting thing here is that when we think about the point where organization introduce formal PM role we usually see at least a few dozen people. So how about startups, where just a few people are working in the whole organization?

    Let’s consider one-man project. I leave aside all tasks directly related with software development, so for the sake of this article I don’t care about version control or bug tracking. Which leaves us with a few of basic areas.

    • Scope management

    You actually need to know what you’re going to do. At least on general level. Actually in startups it’s not a good idea to have detailed plans of development since, well, what you start with is wrong and you’re going to change the course along the way. However if you don’t know, even roughly, where you’re going and you can hardly tell what is your goal then you might look for another project or another job instead because you’re not succeeding. So yes, a bit of scope management is crucial – you have to know that you’re building a tower and not, say, space ship.

    • Task management

    You already know where you generally are going. Good. Now you have to figure out the next step. Or the next feature you’re going to build. Then you build it. And you repeat the process. I mean from the point when you figure out the next step, not from setting the general direction. Of course you don’t have to be so short-sighted to plan only a feature ahead but you do need to break the scope down to smaller tasks and start building your tower brick after brick. And of course you need to know which brick goes first and which goes next.

    • Product management

    This is kind of tricky. Actually if you know the scope and you dealing well with tasks you pretty much have this one covered. Given that you’re building the right thing that is. Product management in such small project is all about making sure that you’re building the right thing. It’s not on brick level but you need something more than just a picture of tower pinned over your desk. You actually have to know that you want to keep bad people in hostage there so you need cells, torture chambers and such. Then you need to figure out how these things should work so clients… I mean hostages are served… I mean tortured well.

    • Communication with users and/or clients

    Finally, you need to verify whether your dream about best of the breed torture tower is something people actually want. You need to regularly confront your ideas with clients or users or both (depending on your target group) to make a sanity check: are we still going into the right direction. Yes, you need to talk with those tortured poor souls to learn whether they’re happy with the service. You might also check your butchers – they do use your product as well. If the tower isn’t ready, go find potential customers and potential users and get their feedback. Since you’re running one-man project you don’t have clearly defined requirements so this part is even more important than in typical projects.

    Now, I’m well aware these areas aren’t strictly connected with project management as some corporate PMs out there know. In big teams PM can be isolated from product management and from end users, scope can be thrown at the project team in huge specification before the project starts, but well, we don’t discuss big teams working on boring BDUF project here, do we?

    By the way PMSE (Project Management Stack Exchange) site is awesome not only in terms of inspiring blog posts. You will find there a lot of great stuff so what are you waiting for? Go check the site.

  • Fighting with Status Quo

    Last time I wrote about status quo and how it becomes protected value within companies. I could tell you countless stories of people being (mentally) hurt by status quo. I could tell barely a few of these when status quo was defeated.

    How to fight with status quo then?

    A short answer is: change rules of the game. Until new status quo emerges everything will be different.

    To elaborate a bit more, status quo is painful in terms of lost opportunities. Every time some talented and eager engineer hits the glass ceiling or a poor candidate is promoted over a good one or suboptimal organization is sustained the company loses. It loses in terms of productivity, performance and employee satisfaction. At the end it loses money since at the same cost there could be done more or there could be done equally much but at lower cost.

    A good supporting question is: who sees all these problems?

    Everyone who tried to improve something but failed because reluctance of people happy with whatever it is today. That would be one group. Another one will be made of few people who are high enough in organizational structure to see how things work, but at the same time have no real power, or interest, to change it.

    Another supporting question: can these people introduce change?

    No, they don’t. They don’t have enough power. They are either too junior or too new or work too far from the core of the organization. Sometimes they would even try to fight the reality just to learn they have virtually no chance to win. Status quo defenders are numerous and powerful and they prevailed many try-outs like this.

    If you came to this point you can basically do two things:

    • Change behavior of people who defend status quo. To succeed with this you need to open their eyes first. It may be possible but it doesn’t have to. How to do this? Well, bottom-up approach doesn’t work. If it did their attitude would already be different. What you need is someone with respect. Someone who would coach status quo keepers showing them ways of improvement. Make them aware there are different styles of management. Make them aware how they can improve their leadership. Make them aware how much they can personally gain if they enable changes in their teams. If this approach succeeds game rules will start changing slowly but constantly. Unfortunately this would work only when you have managers who were unaware of the problems. If they were consciously maintaining status quo chances are good your efforts would be ignored.
    • Get someone experienced and give her power to change things. It could be one of these peripheral managers but as an insider she would be naturally perceived as an enemy by her colleagues. It’s better to get an outsider, someone who successfully cleaned up a company or two. Hire her and give her enough power to allow her to enforce changes over the current organization. Let the outsider change the rules. If you choose your candidate wisely, you’ll go through a number of clashes, some people will leave, other will be fired but in the end organization will work better. Why? Because every significant change in the company, every leaving, creates opportunities for those who want to improve organization and destroys at least a few glass ceilings. Of course you can rebuild every flawed element you’ve just destroyed but after all one of reasons you have your superhero outsider is to prevent that happening.

    As I write this I’m perfectly aware how rare are cases when companies decide to undertake such actions. But every time I hear about another management failure which is triggered by defending status quo (and believe me I hear that a lot) I have the same thought: “Why won’t you, my dear execs, do anything to heal your organization?

    I surely am biased but it happens now and then that I believe I have a few recipes which would instantly improve overall performance, let alone some consistent work on fundamentals. After all management isn’t that hard if you have someone to learn from.

  • Big Companies Are The Best… In Maintaining Status Quo

    What happens when company grows from 10 to 100 people?

    Initially there’s a group of highly motivated and hard working people led by one or a couple of visionaries. Everyone knows each other well. Everyone knows what anyone else is doing at the moment. Then some success happens and organization grows. At the beginning it scales up trouble-free. Somewhere along the way teams emerge. Suddenly company needs a few managers. Who is promoted? What a question. Of course those who were in the pack when employee counter was one-digit.

    First hierarchy self-emerges. No one really thinks about this much. After all it’s all about a couple of teams, not full-blown organization. Then the company grows further and by the time it reaches 100 people there are probably at least two levels of management. First managers add new folks to their teams to the point they need middle management to deal with their 30-something people.

    Note: at that point there still isn’t much planning when it comes to organizing company structure. It is created in the meantime while people aren’t focusing on their work.

    What happens when company grows from 100 to 1000 people?

    By the time organization has 100 employees self-emergent structure becomes suboptimal. It is no longer a bunch of people working toward common success. If you don’t hire great candidates only, and let’s face it: you don’t, there are some people on board who just work there and don’t really care for anything beyond their paycheck. There are also few managers who shouldn’t become managers at all but should stick to engineering. To add some spice the company still grows at constant rate.

    The bigger it grows the more power management gets. Execs no longer work with line employees most of the time. They work with excel sheets and if they meet someone they are other execs or senior managers at best. Real power is moved one level down – to managers who make hiring decisions, promote employees and deal with all people-related issues. Who are they? Remember this few veterans who were around from the very beginning and become very first managers in the company? Well, now each of them leads one of multi-team departments with close to 100 pairs of hands each.

    Sure, there are reorganizations but most likely they happen out of the center of the company. Core remains unchanged. Why? Well, that is damn good question.

    A short answer is: because big organizations are great in maintaining status quo. I don’t want to argue whether a few hundred people make a company big (it does not) but somewhere between 100 and 1000 people this attitude appears and it is there for good.

    And here’s a long answer.

    • Think about management skills of early-managers. Most likely it is their first management job. Most likely they were engineers initially. I’ll be brutally honest: chances are good they doesn’t really suit management job. The problem is they don’t even know that. They can’t. They may even do their best and still suck as managers. If they have grown with the company they may lack just good role-models in management. I could bet my money against their management skills in this situation and, on average, I would win.
    • Now, put yourself in shoes of these veterans. They are with the company from the beginning. They career seems to be well-earned. They aren’t aware they may suck at what they do. When they were engineers they had simple verification of their work: test passed, client didn’t complain thus everything was good. With management it isn’t so easy. Their team won’t come to them to say they suck. Hey, you just don’t go to tell such things to your boss. We can even consider managers are aware they suck a bit. And what would they do? Resign to leave a position for someone better? You must be kidding me.
    • So what do execs do with this? Pretty much nothing. They’re chewing through their Excel sheets and as far as numbers are fine everything else is too. And if numbers start to stink who would they talk to anyway? Well, managers I guess. They’re disconnected with most of the rest of people for a long time already.

    Maintaining status quo is a safe choice for everyone who has enough power to make any important decision in the company. Those who see problems and would like to change something are either somewhere on periphery of organization or very low in hierarchy structure. The former aren’t taken seriously the latter hit the glass ceiling.

    What more, existing status quo propels the same behavior all over again. If the company promoted three out of four engineers from early setup to senior management the fourth one pretty much expects the same. And most likely he will get the promotion, no matter whether he was the best candidate or not.

    Of course you can find counterexamples. I don’t say every company works that way. I guess when Google hit 500th employee mark they were still nothing like that. I know startup where all 3 co-founders had experience in management so they aren’t likely to hit this reef either. I know companies which will never make it past 50 people so they definitely shouldn’t care about these issues.

    Anyway more often than not defending status quo is a problem. I’ve seen it at all stages from few dozens to few thousands of people. And it always looks like decision-makers weren’t aware of the fact or, if they were, like they didn’t care. When company grows to specific size it is just easier that way.

    In the next posting I’ll give an idea what can be done to change the situation. Stay tuned.

  • Role of Leaders in Startups

    Who should be a leader of a startup? An easy question. One of founders. Or even better each of them. They are naturally predestined to leading role. They got the idea. They own the company. They keep all things running.

    Now the more important question: what kind of leaders are they?

    Why is it so important you ask? Well, having a great idea, being a CEO of a company and managing it on a daily basis tells you nothing about leadership. You can end up working either for a great leader or for a sick asshole. No matter which one is true as far as the startup has money leaders won’t change anytime soon.

    Because of a small size of the startup role of leaders is defined a bit differently. Not only they motivate their teams and set up a strategy of the company but they’re also personally responsible for building company culture and enabling company growth.

    In a big organization one asshole doesn’t make much difference – you either work for dozens of them or he’s going to be the only low-performer among great leaders. In a big organizations company culture is already set and it takes a lot of effort and a lot of people to change it (for better or worse). In a big organization one person won’t hamper growth even if that’s CEO who believes leadership is all about yelling at people.

    In a startup one person makes a difference if he leads the company. If he’s a sick weirdo don’t expect healthy atmosphere all over the place. If he makes working for him a hell you won’t see many long-runners in the team as everyone comes and goes as soon as they realize things just won’t change with that kind of boss. In small organizations poor leaders are the main reason why companies suck.

    If you worked for a person who is physically unable to build anything bigger than a couple dozens of people or creating healthy atmosphere at work you exactly know what I’m talking about. Big corporations can be filled with these types and they’ll manage. Startups don’t have luxury to be lead be them.

    That’s a final post of Entreprenurs Time series. I hope you’ve enjoyed it. Please leave your feedback and let me know whether I should post this kind of series in the future.

     

  • Lessons Learned: Startup Failure Part 2

    Last time I shared mistakes we made while working on Overto – startup which was closed down some time ago. Today another part – things we did right and are worth replaying next time I’ll be engaged in a startup.

    Setting up a company behind

    Setting a company, which is quite an effort in Poland, from the very beginning was really a good idea. All founders knew each other well so lack of trust wasn’t the main reason standing behind the decision. We just wanted to give ourselves a bit of motivation making it a real business. However thing we didn’t really plan was that we gained much credibility showing company’s details instead of letting people think the whole thing was created by some student during holidays and won’t be supported in any way in future. Seeing a company behind a service doesn’t guarantee you it won’t die but at least you can be sure someone cares.

    Long discussions before start

    Before launching the project we had very long discussions about what we plan to do and how we want to do it. Of course not every detail was checked but when I compare Overto to other startupish projects I was working on it was really well-thought at the beginning.

    Wide range of roles covered with our experience

    We had really good pack to run an internet service. Development, administration, user support – in all those areas we had experience from the past. There weren’t many things which could have surprise us. We weren’t forced to look for a specialist in any technical aspect of building our application.

    Working in the same place

    For some time we worked in the same building which helped much in decision-making process. We could all meet ad-hoc whenever something important had to be decided. After some time we spread among different places and suddenly we saw how much value was in working in the same office.

    Despite we invested some money to fund the project I don’t treat it as a loss. For experience I gained it was a low price. Another time when I’ll decide to jump to that kind of project chances of success will be bigger.

    First part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Lessons Learned: Startup Failure Part 1

    Some time ago we closed down Overto – startup I was involved in. It was a failure – pretty obvious thing since we’ve closed the service. Since we learn much on our mistakes I think a reliable analysis why the business have failed should be valuable for you. For the beginning things we screwed.

    No one working full time

    From the very beginning we knew none of people engaged is willing to leave their daily jobs to commit fully to the startup. We thought we’d able to run internet service after hours. To some point that was true. As far as nothing bad was happening with the servers and the application it was all fine. We were working on new features when we had enough free time. Problems started when we faced some issues with our infrastructure. We weren’t able to resolve issues on the fly and had several downtimes. You can guess how it influenced user experience. That also backfired on service development since we had to focus on current problems instead of adding new functionalities. Lack of person working full-time and being able to deal with maintenance and bug fixing was the most important reason of failure.

    Catching the market

    That’s partially a consequence of the previous point. Since we spent majority of our limited time on trying to keep the service running we weren’t able to catch the changing market. We needed to cover new areas to move the application to another level but we couldn’t complete ongoing development. The whole project stopped in beta version and for users it didn’t look like anything was about to change.

    Lack of marketing skills

    Thin line between life and death of internet service is a number of users. For the initial period of time the numbers were growing systematically. Then we hit the ceiling of what we could achieve effortlessly. It was a time to do some marketing. Unfortunately no one of us was skilled in that area. Even worse, no one had enough time to fill the gap. That would be another stopper if we dealt with the problems mentioned above.

    Business model

    We hadn’t checked very well a business model we set up on the beginning. We were surprised a couple of our features weren’t as unique as we’d initially thought. Ironically that wasn’t a big problem since we had a bunch of ideas how to adjust the strategy in a new situation. Anyway, you should plan to change your initial business model.

    Screwed chance of selling the business

    After we’d decided we won’t be able to maintain the service in the long run we had a chance to sell it. To make a long story short we screwed negotiations starting with way too high price. We thought more about how much work we put into the project than how much it can be worth for potential buyers. Things are worth as much as one’s willing to pay for them, no matter how long it took you to produce them.

    Waiting too long with final decisions

    I think that one is a bit sentimental. Since the service was our child we were reluctant to make a decision about closing it faster and limit losses. We’ve been tricking ourselves thinking that everything would be fine while we couldn’t get the application back to work properly.

    Second part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Almost Completed

    One of projects I’m contributing to is a micro-ISV service. Maybe it’s not the perfect example of micro-ISV, because at least several people are engaged. It’s not single-person business, but the basis is the same. Whole idea was in its origin a world-changing service (or close). The main person working on the idea is a guy who loves it and strongly believes that the service will be great success. The rest of team keeps adding new brainstormed ideas to current concept, keeping ourselves on fire.

    Just like most of micro-ISVs. Just like most of micro-ISVs which failed. I wrote some time ago that faith and will to contribute in the long run are essentials when trying to build a product or service as the micro-ISV. But that’s not all. Another factor which is probably even more important is consistency.

    I’ve seen different “micro-ideas” (like you can call micro-ISV’s ideas for products or services) which had potential at least to earn for themselves. I played my role in those projects as a co-author, as a supporter, as a user. Range of ideas was wide – from a very fresh look on Internet entertainment services to yet another communicator. All of them I can call (more or less) failures. None of them fulfilled author’s expectations in area of revenue, number of customers or users etc. Many weren’t even born to be shown to the world – they died during pregnancy.

    When you have your application completed in 90% it’s usually much less than halfway to successful release. And when you’re 90% completed all the fun is the past. You developed the most enjoyable and the most challenging parts of a code. You exploited all your creative ideas during design. Now you have to focus on boring little improvements of website. Now you have to force your creative soul to think how to make your customers happy instead of thinking how to enjoy yourself with the work. Now you have to fix all those unrepeatable tiny little bugs which allow your frustration to grow. Now you have to deal with The Boring Time. And if you allow yourself to become bored – you lose.

    90% of completeness is just the beginning of the road. In this case 90% finished often means 100% failed.