"Pillars of Hope" is a tongue-in-cheek name for steel starter bars, also known as starter rods or rebar extensions, that protrude from the roofs of houses after construction. Leaving starter bars sticking out is a pragmatic approach, saving time and money when adding the next floor, as the structure is already partially prepared for the expansion. The "hope" in the name reflects the anticipation and optimism of adding to their homes in the future when the family grows or their financial situation improves.

Growing up in the UK, I never encountered the practice of leaving exposed starter bars on houses. However, while travelling through Central America and Asia, I was surprised to see these exposed rods in many towns and cities. At first, I couldn't understand why so many buildings seemed unfinished, making the skyline somewhat messy. Only when someone explained their purpose to me did it make complete sense.

Steel bars in concrete combine the tensile strength of steel with the compressive strength of concrete, creating a remarkably effective and widely used building method. The starter bars embedded in and protruding from the existing structure provide a strong and stable connection between a new addition and the existing building. The bars transfer loads and anchor the two together.

Pillars of Hope are a conspicuous example of futureproofing. Other examples in buildings are electrics or plumbing, where you might leave capped-off pipes or electrical connection points in anticipation of future work. Laptops and desktop computers with empty expansion slots also use this approach, as does a first edition of software that includes an update manager.

In software and agile development, I like the sentiment from the book Rework: "A kick-ass half is better than a half-assed whole." Have no parts of your product not yet working or "under construction" that are visible to users. Don't leave any visible "starter bars" sticking out of your product. And try not to solve problems that you don't yet have. While it might seem worth adding something now to make a future feature easier to build, it's a tricky balance. So often, you choose to do something else in the future instead and are left with some software pillars of hope sprinkled throughout your code—technical debt you may have to pay off later.

While my first reaction to steel rods sticking out of houses seemingly willy-nilly was that it was chaotic and messy, when I think about them as Pillars of Hope I now find it kind of beautiful—looking out over a skyline and seeing the aspirations and future development of families, homes and a city sketched out on the rooftops.

Edit: Several people told me that leaving starter bars sticking out of a roof makes the building 'unfinished' and not liable to tax on the work. While this is repeated in many places, I'm not 100% sure of the truth. If you have experience with it, please get in touch!

Pillars of hope

Chickens and pigs is a metaphor for who's got skin in the game. Or to leave metaphors behind, who's involved in a project vs who is fully committed.

Also known as the bacon and eggs principle, it's from the old joke (sometimes told as a short story), "In a bacon and eggs breakfast, the chicken is involved, but the pig is committed."

Many people may be interested in and share their opinions on a project or decision. But only some will be responsible for delivering the project and directly accountable for its success.

Everyone may be interested in a bet, but only some players have money to lose.

The chickens and pigs metaphor used to be part of the scrum guide for developing software but was removed. While it memorably distinguishes accountability in a project, there's a danger that it alienates or diminishes valuable input that might make a project successful.

For a more conventional grouping of stakeholders in a project, see RACI

Chickens and pigs

VUCA stands for Volatility, Uncertainty, Complexity and Ambiguity.

The VUCA framework is a reminder to consider how to lead and adapt to the challenges of living in a volatile, uncertain, complex and ambiguous world.

In his book Leaders Make the Future, futurist Bob Johansen provides counterpoints to each that leaders can use:

We live in a VUCA world, but we can handle it.

The VUCA framework originated in the US Army War College.

VUCA is an acronym, as opposed to an initialism. Also see OODA Loop.

VUCA

Saying "no" isn't easy. But there are different ways to say "no" to someone's requests without feeling like you've let them down while being realistic and constructive and ensuring the requester feels heard.

I really like this framework of three types of "no" from Judd Antin:

With the Yes No, you say "yes" to the need and "no" to the specific ask. 

So, a child asking for an ice cream may indeed need something to eat even though they might not get an ice cream. Or the request to make the sign-up button larger might well indicate that it's easy to miss, though a better solution may be to change its colour or the layout of the page.

With the Material No, you are saying yes to the request if you have the time/budget/people/tools to do it.

So, you would love to get the kite out of the tree if you had the tools to reach it. Or the request to make an additional change might be possible on the basis that you can push back the launch date or add another person to the team.

With the Priority No, you are saying yes, we can do it as long as we're happy to drop something less important.

So, you can take the extra cuddly bear in the car if we can choose a different one to leave behind. Or that you can do that project on the basis that we postpone another we had planned.

In each type of "no", the intent is to support and meet the needs of the person requesting while clearly explaining the reasoning for what you'd need to get it done. In each case, the "no" leads to valuable discussions of larger issues of what the real need is, what's required to get a job done, and what's really important.

Read Judd Antin's article, How to Say No, in his series One Big Thought.

Here's a version with all three types of "no" in one image and individually The Yes No, The Material No, The Priority No.

Three Types of "No"

Cake Wrecks is the blog and book of when professional cakes go hilariously wrong, by Jen Yates. But a cake wreck is also a useful metaphor for how easy it can be to misinterpret instructions—often by simply taking something literally when it was expected to be interpreted. Examples from Jen's collection include a smart-looking cake with "Nothing" written across the front, a graduation cake with "I want sprinkles" next to a graduation cap, or a cake sporting a full "Happy birthday on a gluten-free cake." If you haven't seen them, you could do much worse than look some up now. It's easy to laugh at these examples, but it's also easy to find real examples in day-to-day work.

I learned about cake wrecks from Jeff Patton's excellent book User Story Mapping. He gives cake wrecks as an all too common example of communication in software development. For example, a user story or specification for a feature is written and passed on to developers who, in the absence of other communication and with perhaps cultural or status barriers, may carefully build exactly what is written rather than what the writer intended. Cake wrecks are funny and silly—except if it was for your special occasion—but mistakes in projects are expensive in time, money and relationships and are worth avoiding.

The recipe for avoiding a cake wreck is, in principle, simple:

Don't assume that what you see is what someone else will see

Use stories and specifications as tools for talking about what's needed and not as equivalents of it

Create a safe space for everyone to question what they don't understand or don't agree with

Give everyone the 'why' behind a project and autonomy and flexibility to suggest other ways to meet the goal

Check in during a project and adjust as needed

Cake wreck

When adding features to a software product it's easy to underestimate the overall time and cost they may take up. To keep the full impact in mind it can be helpful to think of Features As Pets.

When I think of Features As Pets it helps me look past the initial cost of designing and developing a feature and consider its full lifecycle. For example:

you're going to want to tell your users about it

you'll want to check it's being used as intended

you'll need to support it and check that it works in all different places and fix it when it breaks

you may need to work hard to make sure it's compatible with new features you add

you may have to return to the code and refactor it to improve performance

you may need to upgrade libraries and maintain security patches

finally you'll have to decommission it gracefully when it's no longer needed including dealing with data you may have stored

New features are probably one of the key differentiators of your offering compared to others, but it bears a little consideration before adding something — a feature is not just for Christmas.

Features Are Like Pets is from the excellent Intercom on Product Management podcast (Apple, Spotify, ebook).

Features are like pets

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for determining what to release to your customers and when.

The idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. In the beginning, they’ll probably have to put up with a lot if they want to use it, but with each successive release, they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning, and all along the way, the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it requires rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

This diagram is explained in the brilliant product management book User Story Mapping by Jeff Patton.

A release strategy for happier customers, sooner

Shares information passively, with the neat effect that having a good one in an office can go a long way to getting people on the same page without explicitly calling meetings or sending out updates to do so. Handy to also have a good space in front of it for talking, discussing and generally collaborating. A common term in agile development, originally I believe from Alistair Cockburn of Thoughtworks. To quote from his article, of many possible:

- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date”

Information radiator

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Agile sketches