Highlights from What Got You Here Won’t Get You There

Successful people consistently compare themselves favorably to their peers.

People who believe they can succeed see opportunities where others see threats. They’re not afraid of uncertainty or ambiguity. They embrace it. They want to take greater risks and achieve greater returns. Given the choice, they will always bet on themselves.

Successful people have a unique distaste for feeling controlled or manipulated.

If you press people to identify the motives behind their self-interest it usually boils down to four items: money, power, status, and popularity.

That’s the fallacy of added value. Whatever we gain in the form of a better idea is lost many times over in our employees’ diminished commitment to the concept.

It’s obvious that the best course of action for dealing with people like this is to not let them make us angry. Getting angry doesn’t improve the situation and life’s too short to waste on feeling bad.

But once you appreciate the payoff of saying nothing—that if you’re silent, you cannot make an ass out of yourself or make an enemy out of someone else—then you might have a chance of getting better.

I also suspect that’s a big reason why so many of us withhold information. It’s not that we want to keep people in the dark. It’s simply that we’re too busy. We mean well. We have good intentions. But we fail to get around to it.

If the answer was “yes” he gave them some very quick recognition, either by phone, e-mail, voice mail, or a note.

Stop blaming others for the choices you made—and that goes with double emphasis for the choices that turned out well.

No one expects us to be right all the time. But when we’re wrong, they certainly expect us to own up to it.

It’s not about you. It’s about what other people think of you.

Basically, we accept feedback that is consistent with our self-image and reject feedback that is inconsistent.

1. Let go of the past.  2. Tell the truth.  3. Be supportive and helpful—not cynical or negative.  4. Pick something to improve yourself—so everyone is focused more on “improving” than “judging.”

It’s my contention—and it’s the bedrock thesis of this book—that interpersonal behavior is the difference-maker between being great and near-great, between getting the gold and settling for the bronze.

Even though we may be able to deny our problems to ourselves, they may be very obvious to the people who are observing us.

Some of the best feedback comes from what you observe. If you accept it and act on it, it’s no less valid than people telling you the same thing at point-blank range.

In each phase you must target a different constituency. In phase 4, you woo up—to get your superiors to approve. In phase 5, you woo laterally—to get your peers to agree. In phase 6, you woo down—to get your direct reports to accept.

All I’m saying is that you cannot rely on other people to read your mind or take note of the changed behavior you’re displaying. It may be patently obvious to you, but it takes a lot more than a few weeks of behavioral modification for people to notice the new you.

There’s the part where we actually listen. And there’s the part where we speak. Speaking establishes how we are perceived as a listener. What we say is proof of how well we listen. They are two sides of the same coin.

Asking, “Is it worth it?” engages you in thinking beyond the discussion to consider (a) how the other person regards you, (b) what that person will do afterwards, and (c) how that person will behave the next time you talk.

The ability to make a person feel that, when you’re with that person, he or she is the most important (and the only) person in the room is the skill that separates the great from the near-great.

Eventually, you’ll come to see that expressing gratitude is a talent—a talent that goes hand in hand with wisdom and self-knowledge and maturity.

But injecting Jim into the mix—a friendly sympathetic human being whom, on the one hand, I do not want to disappoint (that’s human nature) and who, on the other hand, provides constant encouragement and input—brings it more in line with the follow-up process I’ve been describing here

Successful people have a high need for self-determination and will tend to accept ideas about concerns that they “own” while rejecting ideas that feel “forced” upon them.

What’s interesting (and reassuring) about this story is that it’s an example of a boss accurately assessing his shortcomings and his employee agreeing with him. That isn’t always the case. Sometimes the gap between what a boss says about himself and what the staff believes is wide, very wide.

Your memo has to be brutally honest. Your employees have to believe it is accurate. And most important, they must believe it matters.

Let them figure out what they should be doing on their own. Let them tell you where you’re not needed.

If you manage your people the way you’d want to be managed, you’re forgetting one thing: You’re not managing you.

Most leadership development revolves around one huge false assumption—that if people understand then they will do. That’s not true. Most of us understand, we just don’t do.

I tell people that change is a simple equation: Stop the annoying behavior and you’ll stop being perceived as an annoyance.

The smart ones believed that their corporation would “drop them in a flash” when they no longer met the company’s needs, so they in turn were willing to “drop the company” when it no longer met their needs.

As a general rule, people in their 20s want to learn on the job. In their 30s they want to advance. And in their 40s they want to rule.

Let that be your model for dealing with needy, demanding, allegedly “selfish” employees. To ignore them and resent them is to misunderstand them—and eventually lose them. You’re committing the corporate equivalent of a hate crime.

Managers at smart companies are catching on. They’re beginning to see that their relationship with top talent resembles a strategic alliance rather than a traditional employment contract.

Stop trying to change people who don’t think they have a problem.

Highlights from The Principles of Product Development Flow

“I believe that the dominant paradigm for managing product development is fundamentally wrong.”

In practice, sensible behavior prevails, despite the presence of a dysfunctional formal procedure.

Third, with a little help from option pricing theory, we will discover that we can actually design development processes such that increases in variability will improve, rather than worsen, our economic performance.

We favor highly granular planning because we don’t understand the statistics of variability.

We value flexibility, and we pay for it. In contrast, most product development organizations exclusively reward specialization.

One of the most interesting examples of decentralizing control without losing alignment is the way the military deals with the uncertainty of warfare.

If you only quantify one thing, quantify the cost of delay.

As this book progresses, you will see that the economics of flow is almost always dominated by the cost of queues. If we cannot quantify the cost of a queue on the critical path, then we cannot quantify the benefit of reducing this queue. If we cannot quantify the benefit, we can’t generate support for major changes.

Reducing risk, which is the primary mission of testing, clearly creates economic value for product developers. In fact, reducing risk is so centrally important to product development that it is indispensable for us to quantify its economic impact.

In product development, our greatest waste is not unproductive engineers, but work products sitting idle in process queues.

In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.

We can create enormous improvements in decision making with surprisingly imperfect answers. Do not let fear of inaccuracy prevent you from creating economic frameworks.

This leads to what we might call the Pareto Paradox: There is usually more actual opportunity in the undermanaged 80 percent than the overmanaged 20 percent.

Some product developers aspire to use the same approach in product development. They prepare a minutely detailed plan at the beginning of the project and measure performance against this plan. When they deviate from this plan, they take corrective action. They aspire to front-load their decisions. While this is a superb strategy in repetitive environments like manufacturing, it is a terrible one in product development.

Not only do these emergent opportunities arrive continuously and randomly, but they are also quite perishable. Opportunities get smaller with time, and obstacles get larger.

It is always useful to look for a way to reshape a bad choice into a better one. Decompose the choice into its pieces and keep the good parts.

The general principle is that we should make each decision at the point where further delay no longer increases the expected economic outcome.

The value of information is its expected economic value.

Low-cost activities that remove a lot of risk should occur before high-cost activities that remove very little risk.

Such aggressive filtering, before acquiring sufficient information to make a good economic choice, would eliminate all uncertain and poorly understood opportunities. However, it is precisely these uncertain opportunities that have large payoff asymmetries, making them the best sources of new drugs. Opening the filter to pass these asymmetric opportunities actually increases economic value.

In my experience, most managers make amazingly fast decisions when they are presented with compelling economic arguments.

Product development inventory is observable through its effects: increased cycle time, delayed feedback, constantly shifting priorities, and status reporting.

The more projects we have in process, the more projects we have to track and report status on.

This is actually a more serious problem than most developers realize because the waste created by following a bad path typically increases exponentially, not linearly, as we progress down the path.

Widespread queues demotivate workers and undermine initiative.

Managing the process upstream of the bottleneck is a valuable tool for improving flow at the bottleneck.

We simply cannot rely on randomness to correct the problems that randomness creates.

Waiting for complete information improves efficiency, but it leads to queueing.

Product development creates economic value by producing the recipes for products, information, not by creating physical products.

Risk-taking is central to value creation in product development.

We frequently encounter strongly asymmetric payoffs in product development. The value of a success can be much higher than the cost of a failure.

Either excessive or insufficient probability of failure reduces the efficiency with which we generate information.

Repeating the same failures is waste, because it generates no new information. Only new failures generate information.

Product developers should clearly distinguish exploratory testing, which should be optimized for information generation, and validation testing, which should be optimized for high success rates.

When our task list becomes very granular, the noise in each estimate is very high compared to the signal. Granular estimates produce good estimates of aggregate scope, but we should never schedule tasks at this level of detail. Instead, it makes more sense to aggregate many small tasks and to schedule them as a group.

The irony of this is that many companies try to reduce the risk of poor forecasts by taking more time to do a careful forecast.

A buffer converts uncertain earliness to certain lateness.

In product development, “left side” outcomes represent bad variability, but “right side” outcomes represent good variability.

Each engineering decision acts as a predecessor for many subsequent decisions. The number of dependent decisions generally grows geometrically with time. Consequently, a single incorrect assumption can force us to change hundreds of later decisions. When we delay feedback, rework becomes exponentially more expensive.

When engineers are experimenting with a new idea, rapid feedback is enormously energizing. Rapid feedback quickly supplies the positive reinforcement of success, and fast positive reinforcement always increases motivation.

It is generally safe to assume that we really don’t know where the optimum point is on the batch size response surface. As a result, we must test the response of the product development process to batch size reduction by reducing batch size and measuring the results.

Sequence activities to create maximum value for minimum cost, and remember that removing risk from a project is a key way to increase the expected value of the project.

Since it takes almost equal effort to ask for a big bag of money as a small one, people prefer to ask for big bags of money.

the practice of working in one phase at a time is so devoid of common sense that engineers seldom follow it, even when it is required by their procedures.

If a simple kanban system was trying to limit the WIP between two processes to 30 items, it might use six pallets that could each hold five parts as physical kanbans. The downstream process would take parts off a pallet and when it was empty, send it back to the upstream process. This empty pallet would signal the upstream process to make more parts. The upstream process is not allowed to make parts unless it has an empty pallet to put them on. This sets an upper limit on the amount of WIP between the two processes.

Toyota further enhances the effectiveness of this WIP constraint by cross-training workers at adjacent work stations.

A smaller batch size approach to WIP purging is to shed requirements during periods of congestion.

It is best to identify in advance which requirements we would consider eliminating or relaxing. We do this for two reasons. First, we can make a more well-reasoned decision before the pressure of a congestion crisis occurs. Second, if we preplan which requirements might be jettisoned, we can structure our product architecture to make it easy to jettison them. We do so by loosely coupling these elements to the rest of the system, so that we can cut them loose quickly.

A simple way to do this is for the development team to pay for variances during manufacturing ramp. Once the product has been in manufacturing for a fixed amount of time, responsibility for these variances can be transferred to manufacturing.

Which project activities are most suited for part-time resources? Those that are most prone to expensive congestion. These are high-variability tasks on the critical path. Activities that are more predictable can be handled with full-time resources, since such activities experience less congestion.

Unfortunately, most organizations love to load these highly productive resources to very high utilization rates. We need to change this mind-set. The big guns are not most valuable as an efficient substitute for small guns, they are most valuable for handling situations that the small guns cannot handle.

Experts allow us to apply tremendous problem-solving power to a bottleneck. Generalists can be easily shifted to any place they are needed. Is there a way to get both these benefits from the same person? Some organizations believe this is possible, and they characterize the people they are trying to create as T-shaped resources.

The ideal resource is a jack-of-all-trades and a master-of-one.

It takes advanced planning to do cross-training and to create T-shaped resources. It takes discipline to load experts to less-than-full utilization. The decision to use part-timers must be made early.

Detailed planning is very perishable, and this perishability increases with the distance to the planning horizon.

When we cram too many projects into the product development pipeline, we create queues. These queues create a frictional drag on throughput as developers spend more time expediting and less time adding value. The added load reduces output instead of increasing it.

Whenever we have any flexible customers, we can use pricing to reduce congestion. Because of the steepness of the queueing curve, even a small shift in demand can make a big difference in flow time.

We monitor the queue and intervene to restore it to the center of its target range, not to simply bring it back within bounds.

Cadence inherently makes activities automatic and routine. This lowers transaction overhead and makes it economical to use smaller batches.

This is an interesting case where the heirs of a brilliantly designed system failed to understand the underlying logic of the system.

When all jobs have the same delay cost, the preferred scheduling strategy is to do the shortest job first (SJF).

Projects should only visit nodes that add economic value. They should visit these nodes in the specific sequence that adds economic value most cost-effectively.

As a general rule, any inexpensive step that eliminates a lot of risk should occur early.

Instead, it is usually better to maintain a trickle flow of work through the alternate route, even when the primary route is under-utilized.

Decisions are made at a synchronous, cadenced meeting where people from adjacent processes can easily interact.

The curtain between adjacent processes does not have to be completely opaque. As work nears completion, we should make its character visible to downstream resources.

They assume that the plan is correct, and a deviation is always bad. Therefore, they try to close the gap between the two by making results closer to the plan. They often discover it is cheaper to prevent deviations than it is to correct them, so they also emphasize preventing deviations.

When goals are dynamic, we need different control systems. If we have stable goals, we try to prevent deviations, often by increasing inertia and avoiding risk. If we have dynamic goals, we try to quickly correct deviations, often by decreasing inertia.

Not all deviations have negative economic consequences.

By accelerating feedback, we can design processes with less WIP, thereby lowering delay times.

Whenever we have a short turning radius and a quick reaction time, we can proceed safely at a higher speed.

This develops a culture of magical decision making, where everybody feels they can make great decisions unencumbered by either analysis or facts.

When people see that their actions cause consequences, it changes their behavior. They feel a sense of control, and this causes them to take even more control of the system.

Under dynamic conditions, we need to pay attention to the timing of the revenue associated with the inventory. When revenue is growing rapidly, we may need more DIP to support this growth.

The Marines believe orders are incomplete without this information. They believe that intent needs to be understood deeply through the organization. They believe that when intent is clear, Marines will be able to select the right course of action.

In product development, we can change direction more quickly when we have a small team of highly skilled people instead of a large team. We can change direction more quickly when we have a product with a streamlined feature set, instead of one that is bloated with minor features. We can change direction more quickly when we have reserve capacity in our resources.

Since the Marines expect plans to change, they focus on simple, modular, and flexible plans. Simplicity leads to fast adaptation. Modularity solves the problem of adaptation because different modules can be configured many different ways. Flexibility is achieved by preplanning “branches” and “sequels.”

There is no substitute for moving to a quick proof-of-concept. There is no substitute for early market feedback.

They believe that one of the biggest mistakes a leader could make is to stifle initiative.

Highlights from Managing Humans

”You must see the people who work with you.”

The presence of rigid, e-mail-based status reports comes down to control, a lack of imagination, and a lack of trust in the organization.

The courage it takes to stop this meeting five minutes into the scheduled hour because there is no discernible way to make progress.

It’s great that your freak has chosen to freak out. The alternative is that they’re not saying a thing and have decided to leave the company.

A meeting agenda would help, but as most meetings proceed without one, you’re on your own.

It’s a noble act, speaking your mind in front of all your peers. But it’s also a waste of time.

Roles and agendas in these meetings are simple. Talkers are talking and listeners are listening. Get it? There is no problem to be solved other than the transmission of information. The quicker it happens, the sooner everyone is back to work.

Exhibiting your power and knowledge as a manager isn’t always the best method of communicating.

Blindly landing process without considering the culture it needs to support it is a recipe for disaster.

Each additional person levies a communication tax, and unless we figure out how to constantly improve our communication, we’re just going to get slower.

Bright-and-shiny inflection points are full of energy, but unless that energy is carefully channeled back into the building and immediately acted upon, all an off-site represents is a frustrating opportunity to dream, but not to act.

Use the development environment to build the product. This means you must be familiar with your team’s tools, including the build system, version control, and programming language.

Process is the means by which your team communicates.

What I am saying is that any big decision, any big problem, deserves time and consideration.

I know there is no controlling the world, but I will fluidly surf the entropy by constantly changing myself.

The game here isn’t just overcommunication and Grapevine eradication; I’m still worried I missed something in the plan, and the status spamming is another means of vetting both the plan and the progress.

These people, called managers, don’t create product. They create process.

We all get shit work, but it’s the responsibility of the guy or gal in charge to dole this work out fairly and consistently.

Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer.

A strategic hire is someone who is going to push their agenda, their opinion.

A tactical hire is a person who is filling a well-defined need.

Your job interview isn’t over until you’ve changed to become part of a new team.

There are chronically negative nerds out there, but in my experience with nerd management, it’s more often the case that the nerd is bitter because they’ve seen this situation before four times, and it has played out exactly the same way.

Yeah, they’re going to argue, but it’s the argument you want your teams to have. It’s not a fear-based “Should we or shouldn’t we?” it’s “Let’s do this thing, let’s make sure it gets done, and let’s make sure it gets done right.”

As an aside, let me stress how bad of a career move it is to not know who you are going to be working for when you arrive. The 30-minute interview you have with your future manager is a critical piece of information when you decide whether or not to make a move.

My personal favorites are mechanical organics. These folks have all the slick tricks of organic information gathering, but they’ve got the astounding organization skills of the mechanic. They know everything and never forget a bit. I mean it. Organic mechanics are frightening. They have extreme depth of knowledge, but there is no obvious organic thread that ties it all together. Here’s the scary part. There is a thread. There is a purpose. They just aren’t letting you see it. Organic mechanics will keep you on your heels and just when you think you’ve figured them out, they’ll change everything. I hate that. I mean, I love that.

Wait, don’t these holistics have product to ship? No, they have multiple products, but they’ve hired rock-star inwards to get the products built to specification and on time so they can focus on figuring out what to build next and who they’re going to need to build it.

I’m not suggesting that outwards don’t care about the daily professional shenanigans within the company; they do, but they’ve also hired a group of rock-star holistics to run their company. The rub is this: while it’s not their job to run the company on a daily basis, they are accountable for it.

What you need to know about your manager is how much he cares about this growth and, more importantly whether he sees this as his growth opportunity or the team’s.

You are not that person, because once you are rewarded for releasing crap, you begin a blind walk down a path of mediocrity that ends up with you working at Computer Associates on a product no one has heard of and that no one cares about.

New beginnings

At the end of 2015 personal and professional changes made it clear to us that we would not continue Hubbub in its current form. That realization made me reorient myself in Berlin and refocus on my core skills as an engineer.

I set myself the goal to work on a significant product as part of a larger team. I thought it would be useful to change up my professional life which thusfar had consisted only of freelance and client work. A long story short, as of this week I’m employed as a software engineer at ResearchGate.

Product design focused on user wants

This post was previously published on Medium and is now archived here.

There’s some recent writing about the decomposition of apps into either thin slivers of single purpose functionality per app or even breaking out of the traditional app domain entirely and delivering their functionality through for instance the notifications screen.

I think both of these are onto something but that the trend itself is more fundamental. I think there are three things happening.

1. Apps can be decomposed into high-level user wants.

A want starts with “I want” and is followed by getting or creating something often accompanied by some social intermediation. Such a want could be “I want to send a message” or it could be “I want to read (and reply to) my messages” or it could be “I want to find a place to eat.”

These are not utilities. Most interesting apps these days are lifestyle apps. Focusing on a single want does not mean the app becomes easier to make. Implementing a want with its very specific functionality, appropriate context, user interface and communication may be even more difficult. A want is a summary of what used to be called ‘user stories’ but focused on what people want to do not on what people are supposed to do. At the risk of sounding obvious: people don’t want to do things they don’t want to do. The exception to this is work where people do things they don’t want to do. People want apps that bring them entertainment, social connections or self-actualisation.

2. Apps cannot support more than a couple of wants well.

Any app that tries to cram in more than a couple of wants from different domains starts to creak and feel cluttered. This looks like the main reason why Foursquare unbundled the totally disparate wants of local discovery “I want to find a good restaurant now” and that of social broadcasting “I want to tell my friends where I am.”

Such unbundling is becoming the norm because an app cannot do everything well without containing multiple apps. Just think back of Facebook’s everything-and-the-kitchen-sink app with its own homescreen. The Facebook app itself is becoming more and more bare while wants are increasingly delivered by apps that don’t show they belong to Facebook.

This is a good indicator of what the future holds for these apps. I would for instance be surprised if complicated list management features would be a significant part of the future Foursquare mobile app. Lists do support local discovery but they will never have the mass appeal the app is focusing on.

3. Wants can be fulfilled anywhere you want.

This ties into Naveen’s piece about the notifications becoming the app. I would take this further and say that the app will be wherever people interact with a connected device. Building an app becomes a matter of translating a user want into the interaction affordances of a medium.

You could indeed read and reply to messages in a notification screen if that is where you spend your time. But soon you might do the same thing using the same app but on your connected watch. In a somewhat more distant future you might send a Yo! by slamming two IoT enabled rocks together.

The medium through which a want is fulfilled has become flexible. What matters is the want itself and appropriateness. A talented designer will figure out whether a translation makes sense and how to best implement it.

All in all this is a great development. Digital design is breaking out of screens enabling it to find us where we are and offer us the things we really want.

Loving the Vechtclub XL

A couple of weeks ago by now I finally got to visit our new office in the Vechtclub XL building in Utrecht. This turned out to be a great experience.

Office

One of the best aspects of the ‘club’ is that it offers an alternative to Utrecht’s terribly cramped and overpriced city center. Everybody wants to live and work in the Utrecht within the ‘singels’ but that privilege costs a lot of money and doesn’t give you a lot of quality of life. Only if you manage to strike a suitable property deal with the city you can do whatever the fuck you want.

Canteen

The Vechtclub XL is a fifteen minutes bike ride out of the city on a derelict business park, about here. There’s nearly nothing nearby which means the building needs to be self-sustaining. That necessity is actually causing that to happen. They are setting up a fully functional cafetaria with world class coffee and more facilities. Being there right now is not terrible. People make do with whatever they have already brought in and there are upsides such as somebody training for a barista championship, lunch being brought in once a week and other events being organized.

This is a continuation of a previous non-XL Vechtclub. Most of it has been funded by the people there who run it not as a cooperative —which looks to be vital. Development is autonomous and moves at a fast clip. The space which is already pretty great is improving continuously.

You can imagine that I was a bit envious and loathe to leave. The upside is that it’ll probably be all new again next time I get there.

Going down everywhere

I was looking around a bit to see if something similar is happening in Berlin or other places as well.

Adam Greenfield mentioned the Institut for (X) in Aarhus which looks very similar in its setup and goals. In Berlin there is the Alte Gießerei which is being converted into a similar setup. There are a bunch more spaces that do something in that direction but most of them do not manage to hit the scale or communal vibe that I try to describe above.