Positive Sum

Creativity Through Bad Ideas

Sun, 16 Feb 2025 00:00:00 +0000

Sometimes you may find yourself or your team wanting good ideas and someone suggests a brainstorming session. It can be hard to be creative on demand – sometimes people need to be warmed up. One technique I have seen to help people get their creative energies flowing is to start with “bad” ideas. I am not quite sure of all the neurological mechanisms at work behind bad idea brainstorming, but I have seen it work.

At the start of the session align participants on the goal of the brainstorming session. If you are not aligned at the start it will be hard to get your desired results.

Now have folks individually spend time writing down all of the things that would be the worst ways to achieve the goal. You want to engage the entire group and you might want to use prompts like the following:

What is the worst way to do this?
What is a terrible thing we could do here?
If our reputation did not matter, what might we try?
What would a cartoon villain do?
If we wanted to get fired, what would we do here?

Next, have the participants read off their bad ideas to the group. For each idea, have the group discuss why it will not work. This helps the group understand the contours of the problem. At the end challenge the group if they can collectively come up with even worse ideas and discuss why those are bad too.

Now have the group write down any ideas they have for solving the problem. Discuss these as a group and encourage the group to come up with even more ideas. Is it possible to invert any part of the really bad ideas to make a good idea?

A sample agenda for the meeting might be:

Align on the goal
Bad idea generation
Bad idea discussion
Good idea generation
Good idea discussion
Align on the next steps

A special thanks to Jody Medich who introduced me to this technique.

How to Ask Questions in Slack

Tue, 11 Oct 2022 00:00:00 +0000

When asking questions in Slack (or Teams or Discord or IRC) you should provide a lot of context in the initial question. This helps those on the other side of the question understand what you are trying to achieve and prevents them from spending time guessing at your intentions.

Better Questions

Consider the following interruption:

<Asker> Hello.

If you are on the other end of that message, what do you do? Inevitably you have to ask for clarification and the asker should know that. It is much better to just ask your question:

<Asker> Do you have any examples of database migrations?

In many cases, there are subtleties that you can reasonably anticipate the recipient will need to clarify to help you. When there may be ambiguity you can help your reader by providing even more context:

<Asker> Question: do you have any examples of database migrations? I need to add an index across multiple columns in the user table and add some columns to the login table for the new security feature.

How to Ask When You Have Authority

The example above is relatively technical, but the same pattern holds for many interactions. Some people have mentioned getting very nervous when they get a message from their boss:

<Boss> Got a minute?

What are you supposed to do in that case? People have confessed to me that they always assume they are going to lose their job when their boss asks them if they have a minute!

my favorite part about having a job is assuming you’re fired every time your boss calls you into their office
— Laurazepam (@andlikelaura) February 5, 2020

You can reduce the stress on your team by providing more context:

<Boss> Got a minute? I want to run our projections for the Pheonix project by you before we talk to finance.

If you are in a position where others are likely to interrupt themselves for you, and the need is not urgent, you can give them the gift of more focused time by letting them know when their response is needed:

<Boss> I want to run our projections for the Pheonix project by you before we talk to finance on Friday, do you have time before 2 pm on Thursday?

If you have hard news to share, but want to provide the full context via a higher bandwidth channel than Slack, it can still help to let the other person know the hard thing is coming.

<Boss> Do you have 15 minutes for a hard thing?

When you’re asking questions, provide more context than you think is necessary. It will cut down the back and forth and help everyone get to the answer more quickly.

Bottom Line Up Front

Mon, 10 Oct 2022 00:00:00 +0000

When writing you should put your main point in the beginning. People are busier than ever and their time is valuable. Do everything you can to get them clear, actionable information as quickly as possible.

Known as bottom line up front or BLUF, this style originated with the US military for writing memos. Experience has shown this is another miltiary technology that can be used to great effect at work. Business writing is different from communicating with your friends or the inductive writing taught in school which takes readers on a journey of discovery.

Your reader does not always want to know all the background information that led to a decision. But they will always want to know how this email will impact them. Your bottom line should answer this question every time. The following example shows this principle in practice.

Email Example

Instead of starting with a history of your activities, followed by a conclusion:

I noticed a slow query in our logs last month and I have spent the last week looking at our database usage. I noticed that today we are adding a million rows every day and

… lots more details …

All of these fixes together will take almost 5 months. The primary database will likely run out of space within six months. Should I start working on this next week?

Put the important information in the beginning and then supply additional details afterward:

Summary
At our current rate of user growth, our primary database will run out of space in six months. We need to start a mitigation effort next week to ensure our service will continue to function in the second half of the year. When can we talk about scheduling this work? I am available before noon Pacific on Thursday or Friday.

Details
A rough outline of the necessary work follows, along with my estimates for how long each section will take.

… supporting details …

First Things First

Sun, 09 Oct 2022 00:00:00 +0000

I routinely see startups make the mistake of failing to put the first thing first. The first thing is existential, has the highest impact, and can redefine the trajectory of the company. A startup should focus its time and energy on the first thing. Doing so increases its chances of survival and breakout success.

This advice sounds too obvious to be worth mentioning, so surely only naive people make this error? I wish that were true, but I have seen otherwise smart, hard-working folks waste time, energy, and money by not putting first things first¹.

No single reason dominates why people fail to put first things first, but it is worth enumerating a few common scenarios to help you more easily recognize failure patterns. Some folks are so busy working they do not stop to ask if their work is worth doing or worth doing right now. Sometimes people enjoy the task they are working on, especially when they are experts, and are reluctant to take up less enjoyable activities or things where they lack expertise.

Even though there are countless reasons you might not be focusing your attention on first things, you can dramatically improve your odds by regularly asking yourself what the highest impact thing you can be doing for the company is, and if your work is moving the needle on that thing. If you are not on track to move the needle it is time to make a change. By creating space for others to ask you the same question, you can help counter your blind spots. I try to solicit this feedback in my 1:1s and carve out time to think about this at least weekly.

When I introduce first things first I encounter three types of objections. The first is from folks who do not want to change. I feel that – change is hard! It is unlikely you will make smooth and continuous progress toward a better outcome. Learnings and reality are both lumpy. The alternative to hard change is knowing that you chose to not do the most to succeed and that you valued the status quo more. This realization makes starting the change easier.

The second objection to putting first things first is when people ask about routine work. How do you ensure payroll goes out and floors are swept? Here context and time management matter. When you are resource constrained there will always be some grunt work that you have to do, the key is in focusing on the most important and the most urgent items. You will have to triage.

The last objection is some variant of not wanting to prioritize². I see this every time someone tells me they have seven top priorities. Definitionally there can be only one number-one priority; by having so many number-one priorities you have none. There is no good way to prioritize between adding profile photos and reducing cloud bills if features and cost reduction are equally prioritized. Instead, you must use one of the many prioritization frameworks and create a rank order.

Prioritizing first things first is not only for founders and executives. It can be applied at every level of an organization by asking yourself if your work is having the highest impact on the things in your sphere of influence.

There was a team of very talented engineers with 12 months of cash left who spent over a month architecting a Kubernetes deployment infrastructure instead of building a product. Even in the best case, the deployment infrastructure wouldn’t have mattered for another year. They failed to achieve product traction and were lucky to be acquihired.

If they had asked themselves if their infrastructure work would have moved the needle on their business they would have realized the answer was “no”, and could then have spent more time developing their product thesis.

As a second example, there was an enterprise company taking a complex product to market where sales were less than 1% of projections. Instead of making the hard call to change, the CEO spent their time migrating payroll systems and approving accounting audits because they thought that was what a well-run company should do. Even though the company was well capitalized, it focused on addressing the sales problem a year too late and eventually wound down. ↩︎
Derek Sivers has a similar rule in his personal life: if you’re not saying “HELL YEAH” about something, say no. Time is always a constrained resource and this means that to make room for the most important things (HELL YEAH) you have to pass over other good options (merely yes). ↩︎

Start Your Sprint Mid-Week

Sat, 08 Oct 2022 00:00:00 +0000

For software engineering sprints, it is better to start sprints in the middle of the week as opposed to Mondays. This is counter-intuitive as the natural cadence for business is Monday through Friday, so why is software engineering different?

Individual software engineers need to estimate the amount of work they can get done in a sprint, and sometimes they are wrong. This means they either need to put in more work to hit their sprint deadline, or they need to have a conversation with stakeholders about the work slipping.

If you are going to put in more work, it is socially easier to do that on a weekday. If you need to discuss a sprint task with stakeholders, you might be able to reuse an existing Monday meeting for that purpose (but not always).

All else being equal, it is better to have happier coworkers, so start your sprint mid-week. I’ve used Tuesday and Wednesday in the past and most teams naturally seem to prefer Wednesday.

When You Should Interrupt Your Sprint

Fri, 07 Oct 2022 00:00:00 +0000

Even though software engineering sprints are supposed to be uninterruptable to maximize focus time for engineers, I think there are two cases where you should break the sprint:

An incident or outage needing the whole team
A large and unexpected business opportunity

In each case, it is worth considering what would happen if you did not break the sprint.

During an incident, your software is not functioning and thus delivering no value to customers. This state of operations imperils the company’s ability to exist and must be addressed promptly. It is much better to have the company up and running with a slight delay in the delivery of the sprint’s features than the converse.

The second case is a bit tricker and hinges on what it means to be both large and unexpected. Large means that the opportunity is so big that if you were to plan the sprint today, this would be the number one priority for the team. Unexpected means it was unreasonable to have known about this opportunity while planning the sprint. It might mean responding to a current event or a competitor’s misstep. Even at early-stage startups, your target should be at most one such interruption per quarter.

Why should you only interrupt a sprint for unexpected business opportunities? Engineers need uninterrupted focus time to do their best work. It takes time for an engineer to research a problem, put the opportunity into code, and test the solution. This time is why sprints are longer than a day. If the team is always worried that their work might be interrupted it will be harder for them to do the deep work needed.

Interruptions also make it easier for the counterparties to software engineering to believe they can change things without cost – which is false. Every place I’ve ever worked has had too few engineers for the opportunities available. Thus it is imperative to direct their work to the most important activities.

Popcorn for Remote Meetings

Wed, 05 Oct 2022 00:00:00 +0000

Remote meetings are different from meeting in person and require different affordances. One of the hardest is making turn-taking natural and low-friction because you lose the shared spatial awareness that you get in person.

I’ve found that popcorning can be effective in remote meetings. After one person speaks they then call on the next person to speak. It is that simple.

For smaller teams, it is relatively straightforward for participants to keep track of who should go next. This breaks down as meetings get larger, usually around 10 attendees, as every person now needs to keep track of if every other person has gone. For that reason, I recommend reserving popcorning for more intimate meetings like daily standups or sprint retrospectives.