Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Category: entrepreneurship

Lateral Skills Are Core Skills

We can consider so many things both in our professional and personal lives as value exchange. The most obvious case: I exchange 40 hours of my time each week for a set amount of money that lands in my bank account each month.

As a business, we do the same thing. We commit our engineers to spend their time on whatever our clients need them for, and in exchange, we receive an agreed-upon rate for each hour of that effort.

In fact, I often use that frame when describing how we perceive our contributions. We aspire our clients to be happy with the value we deliver for the price they pay for the whole team.

What Is Value?

Now, the tricky part in these examples is value. While we can easily assess how many hours anyone spends on a task, the time doesn’t automatically translate to value. What’s more, it’s not even purely a matter of how one will spend that hour.

I can work on an activity that has only certain odds of success. If the outcome ultimately emerges as a failure, no value will have been delivered. The reasons for that may be entirely outside my sphere of control.

As an example, think of all the effort I invest into helping a potential client improve how they will approach building their new product just to see them choose a different partner. In this case, my work has not yielded any value for Lunar.

However, even if I work on something that we assume to have intrinsic value, it’s still tricky. Let’s look at adding a feature to a product. (And yes, I know that not every feature is value-adding. In fact, there are some whose net value would be negative.)

Assuming the feature I’m building will have a positive effect, the big question is how big of an impact and how much our client values it. That question is almost universally highly challenging.

Most of the time, we can’t know the answer upfront. We need to build the thing to be able to validate the outcome. Most of the time, however, we don’t try to check that anyway. Even if we did, most of the time, the early validation will now give the complete picture.

Think of The Shawshank Redemption. Its theatrical release was largely a flop. And yet, over the years, it gathered a strong fanbase, still keeps the #1 position as the best movie ever at IMDB, and eventually, it at least paid off production costs. Not a bad outcome for a flop, eh?

While there obviously is a correlation between the opening weekend box office and the eventual financial success of a movie, we can’t precisely know the financial success/failure just after the first few days.

The same goes for value assessment in most of the knowledge work. You could just as easily consider whether paying an employee any specific salary yields a valuable (enough) outcome. And the smaller chunk of work you look at, the more the mileage will vary.

Making Value Exchange Work

We use two basic coping mechanisms to work around uncertainty about value.

The first one is ignoring the actual value altogether and sticking with our early assumptions of what we expected it to be. It’s like deciding to build that feature because “it will bring us so many new subscribers” and never looking back. Sure, before committing to the development, we might have asked for an estimate. If it was acceptable enough (and the work didn’t take much longer), it was the last time we did any assessment of the work.

We thought it would bring us a ton of subscribers, and it was a sound decision to pay $10k for that. Oh, and since we already paid for that work, who cares whether it actually brought a single new soul to our solution?

Well, I’d say this means giving up on a ton of learning here, and that’s of huge value by itself, but I clearly must be wrong, as very few product organizations do any post-release validation.

The second way to dodge the uncertainty of value is by looking at a bigger whole. I don’t try to assess whether an engineer has been productive during every single hour or day. Heck, I’d be perfectly fine with a slower week, too. However, I want to know whether their long-term performance justifies their salary.

By the same token, I want the whole team working for a client to deliver good value for money in the long run. So, if we look at the weeks or months of work of the whole group, we are happy with the value of everything they deliver (of course, in the context of what that effort costs, again, in total).

In extreme cases, you could look at movie studios or VCs investing in startups. They are happy to weather plenty of bad investments as long as that one movie or that one startup yields a 100x or more return.

Lateral Skillsets

We all make one subconscious assumption here. That is, even though we exchange different things, they are of similar value for both parties. If we ask for $90 an hour for our developers, that hour would be priced roughly a similar way, whether by Lunar’s client or me. Or rather, we would price the skills our client rents for that hour similarly.

This assumption, though, often doesn’t hold true.

To stick with the engineering/software development context. When our potential clients want to assess our team’s skill set, it will almost always be heavily skewed toward technical skills. After all, when you hire developers, they will do development, right?

But let me redefine the situation here. Imagine you seek someone to turn your idea into an MVP. You have two candidates with very similar technical skills. However, one builds their experience by working on many different small engagements, including several very early-stage products. The other spent big chunks of their time working on very few large and complex solutions.

Which one would you choose?

I bet most of us would go with the former over the latter, as we’d deem their experience more relevant. This relevancy, however, stems from a lateral skillset. It’s not an ultimate value. It’s value in the context.

Product management skills may actually emerge as the most crucial for that role, even if we don’t consider it so upfront. At the early stage of product development, building the wrong thing is rarely salvageable. Building the thing wrongly, on the other hand, can typically be saved.

If we had considered a different gig, we might have chosen differently.

This is but one example of lateral skills that may make or break any endeavor. A broad range of people skills, project management savvy, business context understanding, and more may be similar game-changers here.

And yet, without the specific context, the broad market would largely ignore those traits. Even within the context, they are most often omitted.

Asymmetric Value Exchange

The lateral skills are what change the economy of the whole value exchange. The job market would value two similarly technically skilled developers, well, similarly. After all, across a wide variety of challenges, they will provide comparable value.

However, within the early stage product development context, the first one will deliver something extra. They wouldn’t be working extra hours, their code wouldn’t objectively be better quality, they wouldn’t be faster.

Yet something that costs nothing extra to that developer–their lateral early product management skills–would be highly beneficial for the product company.

That’s what breaks the simple economy of value exchange. I add to the mix something that’s of little to no cost for me but gives the other party a big upside.

In other words, I give up nothing while they gain a lot.

Suddenly, the whole deal has so much more wiggle room, which can be used to make it more attractive for both parties.

Not only that, though. It also generates additional options for value delivery. Our developer may use their time building a feature that ultimately will not help. However, thanks to their experience, they can also suggest (in)validating the whole part of an app prior to committing to development. That, in turn, may lead to much more significant savings.

In this case, exploiting lateral skills makes the value exchange asymmetric. Why is it important? It’s because whenever you can find a partnership with an asymmetric value exchange, it’s a plain win-win scenario for both parties.

Since lateral skills typically create these scenarios, we should pay much attention to them.

Side Skills Are Core Skills

If I looked for a technical partner to help me with an early-stage product, I would primarily be looking for stories about discovery work, building MVPs, validation, etc.

As a matter of fact, I’d be explicitly asking for failure stories. I mean, we know the data. New products do fail. So, if the only thing someone has to show is a neat streak of successes, you can be sure they’re in a fantastic realm.

One of my mantras is, “Many of our past clients paid us to fail, so you don’t have to. You get all the experience we got from that as a part of the package.”

These lessons do not fall into what’s commonly perceived as “core skills” for software development teams. And yet, we do consider them core. We shine most when we’re able to utilize those side skills.

So, go figure out what constitutes those lateral skillsets in your context. These are the core traits you should be looking for, whether hiring or choosing a partner in your endeavors.

March 6, 2025
Autonomy and Transparency: Both or Neither

How does transparency feel? Early in my career, I had an occasion to experience that. I was working in a typical organization where lots of things, payroll included, were secrets. Then the salary list leaked out. It wasn’t a huge leak, i.e. it didn’t go public, but I was close enough to the source that I could take a look.

When I was about to open the spreadsheet with the data, I was thinking about my expectations. I hoped that information about salaries would help me to make sense of how people in the company are perceived by the leaders. I thought that it might provide me with role models to look up to. I was ultimately looking forward to transforming new knowledge into some inspiration and motivation for myself.

That was totally not what happened.

What I saw on the payroll was a lot of unfairness. I saw numbers I couldn’t possibly justify. I couldn’t make sense of the system that produced these numbers. Most of all, I was painfully aware that there was literally nothing I could do to change that. After all, I shouldn’t have seen the data in the first place.

Ultimately, I got frustrated.

Transparency without Autonomy

With the benefit of hindsight, I see a broader picture of that experience. On one hand, I am aware that back then I couldn’t have had the whole perspective on what was valued in the organization and thus my sense of unfairness might have been exaggerated. I didn’t have insight on systems thinking to be able to rationalize the shape of the payroll as a pragmatically predictable outcome. Should I understand that my outrage and my frustration wouldn’t be that big.

The bottom line remains the same. I should have been expecting frustration as the only logical outcome of such an experiment. I put myself in a situation when I was about to get access to data that was important to me on an emotional level and yet I knew I had no influence whatsoever on shaping the future state of that data.

I got transparency with no autonomy to act. Heck, I couldn’t even ask all my “whys” to better understand what was going on. I put myself in a position where my frustration was guaranteed.

Transparency without autonomy is a recipe for frustration.

It’s like telling people stuff that they don’t like, or agree with, and then telling them to live with it. You don’t like who gets a raise? Live with it. You don’t agree with who gets promoted? Live with it. You don’t agree with disparities on the payroll? Live with it. You get the idea.

A side note: I refer to autonomy and not authority. There’s a significant difference between the two. For the sake of this discussion, the crucial part is autonomy defined as the actual use of decision-making power, not just the availability of decision-making power.

Autonomy without Transparency

What about the opposite situation? Can we let people act while keeping them from accessing sensitive data? The answer to this case is rather obvious, I think. Acting in an organizational context means making decisions. Can we then make decisions with limited access to relevant information?

Yes, we can. The question is: would that be good decision-making? Even though a common perception that more information available to a decision maker would result in a better decision is a myth, it is still crucial to have access to a few most important bits of data.

In our context most important often translates to most sensitive and thus available to few. If we let people decide without making such information accessible we’d set them up to fail. Their decisions simply won’t be informed and thus random and low quality.

Decentralizing control requires decentralizing both the authority to make decisions and the information required to make these decisions correctly.

Don Reinertsen

To stick with the original example, just try to imagine people deciding on raises without knowing what salaries are.

Transparency and Autonomy

OK, so neither autonomy nor transparency alone does make sense. What does, then? If we aim to improve either one we need to think about both at the same time.

Each time we loosen transparency constraints we should answer: how can people act on newly accessible data? What will they be able to do if they aren’t satisfied with what they see? The answer doesn’t have to be full control over changing the part of reality that we’ve just made transparent. They do need to have influence, though.

When we were making salaries transparent at Lunar Logic we didn’t give people the power to set the salaries. Well, not initially. We gave them as much as, and as little as, influence: an option to start a discussion about a salary and space to share their opinions about any raise under discussion. Even if the final decisions were still being made by the same person as before the change there were clear options anyone could exploit if they were dissatisfied with any number on the payroll.

While eventually influence has transformed into full control over decisions, the key move was the initial one. The one that gave people influence.

The guidance is much more straightforward if we start with the intention of extending autonomy. We simply need to answer what information we consider when making this kind of decision and then make that information available.

Most often the hard part is realizing what range of information we really consider. When we started experimenting with the decision-making process at Lunar Logic, the first step was to let people spend company money without asking permission. The part of the process was, and still is, what we call the advisory process.

As a part of advisory processes, I was often consulted about planned expenses. The most important lesson for me from the advisory processes was how unaware I was of all the data, experience and mental models I was using when I was making decisions myself. This, in turn, made me realize how much more transparent with all these we need to become to get autonomy working. A simple example: if we want people to spend company money wisely they should know what’s the financial health of the company and how specific expenses may affect it, i.e. regular financial reports should be available to everyone.

Moving the Bar

The bottom line is this: when we raise the bar of transparency we need to raise the bar of autonomy as well. And vice versa.

It is not as obvious as it sounds. Each change fuels and influences another. It is more of a balancing act than a prescribed set of moves one could repeat in every situation.

There is a caveat too. Transparency is a one-way street. You simply can’t undo making salaries transparent. You can’t make people unsee the payroll. Then again, transparency doesn’t go alone. It must be followed by autonomy. This means that changes on both accounts are almost impossible to reverse.

In fact, rolling autonomy back is a bad idea not only because it is connected to transparency. Even if we looked at autonomy in isolation there’s a painful penalty to pay for removing autonomy that has already been granted. It is an equivalent of saying “we weren’t serious in the first place about giving you that power”. Not only we are back to the square one but also people would be discouraged to embrace autonomy in the future because they got burned.

The obvious advice in this context would be to tread carefully and to take one’s time. We will find ourselves in a place where we feel like we took a step to far. What we can do is to take a break until we learn how to embrace the new situation.

At Lunar Logic it happened sometime after we made salaries transparent and gave people influence over raise decisions. Suddenly we found ourselves in the middle of what we now call the raise spree–a lot of raises were happening simultaneously with little consideration of their ripple effects. Instead of removing autonomy or double guessing individual decisions, which would end up the same, we focused on educating ourselves. How individual raises would influence other decisions about salaries and the overall financial condition of the company. Only as soon as we felt comfortable with the autonomy we had we moved the needle again.

Neither or Both?

If we stick to the assumption that increasing autonomy and transparency should go together, the question we should ask is: should we even bother? If it’s the choice between both and none, why not to choose none and stick with the status quo?

The younger version of me would say that more transparency is always better than less. Well, now I would argue with my younger self. There are edge cases, like the one that I started with. However, in general, I believe that it is easier to lead a company when more information is available to everyone. At least in a part, it comes from a fact that not only is it more transparency, but also more autonomy. The latter releases a part of the burden of people in leadership roles.

I do have a better answer when it comes to autonomy. Dan Pink points autonomy as one of the crucial factors that our motivation depends on. Little autonomy, little motivation, he says. Given how discouraged autonomy is the modern workplace we can only do good if we pursue it more. It won’t happen unless we care about autonomy and transparency together.

For me the answer is obvious. It’s both; not neither. As difficult as the evolution can be, it’s worth it.

April 17, 2019
Cultural Fit versus Cultural Fit

There is a remark on hiring I’ve heard quite a few times recently. It’s about sending a rejection message to a candidate. It goes along the lines: “Just don’t tell them that they’re not a good fit for the culture. That’s bullshit. That means nothing.”

A Bad Fit

I can’t say that such a remark lands well with me. I do, however, understand where it is coming from. As the industry, we started paying attention to the culture. It’s on our radars. We may have only a vague understanding of what organizational culture is but it is already a part of the discourse. This vagueness of understanding of the concept actually comes handy when there’s no tangible reason to reject a candidate but we still somehow didn’t like them.

They are a bad cultural fit.

Whatever that means.

See, the problem I have with many of these statements is that they’re used as a bludgeon without much thought invested to why “we didn’t like” a candidate. Because of that we often throw the baby out with the bathwater.

A Good Fit versus Likability

When hearing about lack of cultural fit I often follow up ask what it means that a candidate wasn’t a good cultural match. The answer, most often, is something like “that’s a person we wouldn’t get on well with”, or “that’s not a person I’d like to hang out with”, or “it’s not my kind of a person”. These boil down to how likable a candidate is for an assessing person.

The problem is that likability is a terrible way of assessing cultural fit. Not only is it not helpful, but it is also counterproductive.

If we chose likability as our guiding principle to judge cultural match we would end up with a group of people similar to each other. They’d have similar interests, many shared views and beliefs, etc. We would be building a very homogeneous culture. An echo chamber.

Sure, there wouldn’t be much conflict in such a group. There wouldn’t be much creative thinking either. There would be premature convergence of the ideas, little scrutiny, few alternative options would be explored.

If we consider knowledge workers such a team would have appalling performance. Thus my problem with such a shallow understanding of cultural fit.

Shared Values, Diverse Perspectives

So what is an alternative? How to define cultural fit in a way that would yield a high performing team? General guidance would be to optimize for representation of different, diverse points of view while creating an environment where people are encouraged to contribute.

These two ingredients—diversity and enabling environment—balance each other in a way.

We want diversity to have an option to learn about other, non-obvious ideas. Such ideas won’t come from people similar to ourselves. We thus want to have a range of different people in a team. And when I say “different”, I think of different walks of life, different experiences, different beliefs, different preferences, different characters, etc. This might be translated to maximizing diversity.

However, diversity for the diversity sake is not the way to go. This is exactly where the second part kicks in. We want to sustain an environment where people share their diverse opinions, and not simply have them. For that to happen we need to have a common base that encourages people to feel comfortable enough to contribute.

That common base is a set of shared values. I won’t give you a list as I don’t believe there’s the way. There are many ways to build such an enabling environment. There are, of course, usual suspects: respect for people, emotional safety, or autonomy, just to mention few. The important part is that such a set of shared values provides an informal, and typically implicit, contract that makes it safe to contribute.

Cultural Fit

With that founding principle, the definition of a cultural fit would be very different. A good match would mean that we share core values but beyond that, a candidate is as different from current team members as possible.

This means that friction will happen. Conflict too. Not everyone will feel comfortable all the time and not everyone will be getting on well with everyone else.

This means that when we decide there isn’t a good fit we may come up with a much more tangible explanation why. It is because we don’t share values—e.g. we perceive a candidate as disrespectful—or we don’t sense any aspect in which a candidate would stretch diversity of the team in one of the desired dimensions.

Note: not all dimensions of diversity are equal. There’s little, if any, value in my experience as a sailor in the context of product development. There’s more value in, say, cognitive studies that someone else went through. That’s why I add a quantifier “in the desired dimension” next to “diversity”.

Some time ago at Lunar Logic, we rejected a candidate for a software developer role whose focus was purely on their technical skills. There’s nothing wrong in that of course unless this is the only dimension a candidate uses to look at themselves and at others. There was some mismatch in shared values, e.g. little understanding and appreciation for teamwork and collaboration. We didn’t see much diversity that they would add to the mix either—we already have quite a bunch of excellent developers.

Interestingly, the decision was made despite the fact that we liked the candidate and were getting on well with them. That’s a complete opposite of what a naive approach to cultural fit would suggest us to do.

We believe that we are better off with that decision. More importantly, we believe that the candidate will be better off too. As long as they find a company where there’s a better overlap in shared values not will they contribute more but will also be appreciated better.

March 5, 2019
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.”

June 20, 2016
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.

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.

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

February 24, 2015
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.

December 29, 2014
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.
April 14, 2011
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.
January 29, 2010
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.
January 28, 2010
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.

January 26, 2009