Iteration

🐾

We do the smallest thing possible and get it out as quickly as possible. If you make suggestions that can be excluded from the first iteration, turn them into a separate issue. Don't write a large plan; only write the first step. Trust that you'll know better how to proceed after something is released. You're doing it right if you're slightly embarrassed by the minimal feature set in the first iteration. This value is the one people most underestimate when they join Techmission. The impact both on your work process and on how much you achieve is greater than anticipated. In the beginning, it hurts to make decisions fast and to see that things are changed with less consultation. But frequently, the simplest version turns out to be the best one.

People that join Techmission all say they already practice this iteration. But this is the value that they have the hardest time adopting. People are trained that if you don't deliver a perfect or polished thing, you get dinged for it. If you do just one piece of something, you have to come back to it. Doing the whole thing seems more efficient, even though it isn't. If the complete picture is not clear, your work might not be perceived as you want it to be perceived. It seems better to make a comprehensive product. They see other people in the Techmission organisation being really effective with iteration but don't know how to make the transition, and it's hard to shake the fear that constant iteration can lead to shipping lower-quality work or a worse product.

The way to resolve this is to write down only what you can do with the time you have for this project right now. That might be 5 minutes or 2 hours. Think of what you can complete in that time that would improve the current situation. Iteration can be uncomfortable, even painful. If you're doing iteration correctly, it should be. Reverting work back to a previous state is positive, not negative. We're quickly getting feedback and learning from it. Making a small change prevented a bigger revert and made it easier to revert.

However, if we take smaller steps and change smaller, simpler features, we get feedback sooner. Instead of spending time working on the wrong task or going in the wrong direction, we can present the smallest change, receive fast feedback, and course correct. People might ask why something was not perfect. In that case, mention that it was an iteration, you spent only "x" amount of time on it, and that the next iteration will contain "y" and be ready on "z".

Don't wait

Don’t wait. When you have something of value like a potential blog post or a small fix, implement it straight away. Right now, everything is fresh in your head and you have the motivation. Inspiration is perishable. Don’t wait until you have a better version. Don’t wait until you record a better video. Don’t wait for an event like a circle meeting. A proposal that isn’t released is a liability since it has to be managed, becomes outdated, and you miss out on the feedback you would have received had you implemented it straight away.

Set a due date

We always try to set a due date. If needed, we cut scope. If we have something planned for a specific date, we make that date. For example we created over 10 videos on the 22nd of the month. But every one of them doesn't contain all the scripting we planned. If we planned an announcement for a certain date, we might announce less or indicate what is still uncertain. But we set a due date because having something out there builds trust and gives us better feedback.

Cleanup over sign-off

Waiting for approval can slow things down. We can prevent this with automation (GForms feedback) or clean-up after the fact (Trello feedback), but we try to ensure that people don't need to wait for signoff.

Start off by impacting the fewest users possible

If you do a gradual roll out of your change prefer: few users over many users, internal users (GED students only) over external ones, environments you get faster feedback about over (Slack) low feedback ones (emails), etc.

Reduce cycle time

Short iterations reduce our cycle time.

Work as part of the community

Small iterations make it easier to work with the wider community. Their work looks more like our work, and our work is also quicker to receive feedback.

Minimal Viable Change (MVC)

We encourage MVCs to be as small as possible. Always look to make the quickest change possible to improve the user's outcome. If you validate that the change adds more value than what is there now, then do it. No need to wait for something more robust.

Make a proposal

If you need to decide something as a team, make a concrete proposal instead of calling a meeting to get everyone's input. Having a proposal will be a much more effective use of everyone's time. Every meeting should be a review of a proposal. We should be brain-writing on our own instead of brainstorming out loud. State the underlying problem so that people have enough context to propose reasonable alternatives. The people that receive the proposal should not feel left out and the person making it should not feel bad if a completely different proposal is implemented. Don't let your desire to be involved early or to see your solution implemented stand in the way of getting to the best outcome. If you don't have a proposal, don't let that stop you from highlighting a problem, but please state that you couldn't think of a good solution and list any solutions you considered.

Everything is in draft

At Techmission, we rarely mark any content or proposals as drafts. Everything is always in draft and subject to change.

Under construction

As we get more users, they will ask for stability, especially in our UX. We should always optimize for the long term. This means that users will be inconvenienced in the short term, but current and future users will enjoy a better product in the end.

Educating users on the longer-term plan helps create a shared understanding of how a small change will incrementally grow into something more. For example, we could share how a dropdown will evolve into a much more nuanced solution in the future. We can take the following steps to articulate our plan:

Open a feedback issue that provides context about the initial MVC (example)

Ensure the direction page articulates a long-term plan (example)

Announce the MVC in Trello, link to the feedback issue, and link to the direction page (example)

Low level of shame

When we talked to Nat Friedman, he said: "A low level of shame is intrinsic to your culture." This captures the pain we feel by shipping something that isn't where we want it to be yet.

In many organisations, you take a risk when you put forth any work that's not perfect — where you haven't spent endless cycles planning for contingencies or counterpoints. Because of this, you're incentivized to invest a lot of time and effort into preparing for 'What if?' scenarios before any work is presented.

The downside to that is clear. If you do eventually put forth the work, but it needed to be course corrected a long time ago, you've now squandered a lot of time that you could have spent improving it via iteration.

Having a low level of shame requires you to combat a natural inclination to conceal work until it's perfect, and instead celebrate the small changes.

Cultural lens

Cultural differences can bring unique challenges and expectations to iteration. For some, expressions like "it doesn't have to be perfect…" can challenge cultural norms. We encourage you to bring your authentic self and seek shared understanding when iterating. Giving feedback and ensuring psychological safety are necessary for every iterative attempt.

Focus on improvement

We believe great companies sound negative because they focus on what they can improve, not on what is working. Our first question in every conversation with someone outside the company should be: What do you think we can improve? This doesn't mean we don't recognise our successes; for example, see our Say Thanks value. We are positive about the future of the company; we are present-day pessimists and long-term optimists.

Do things that don't scale

First, optimise for speed and results; when it is a success, figure out how to scale it. Great examples are in this article by Paul Graham.

Make two-way door decisions

Most decisions are easy to reverse. In these cases, the directly responsible individual (DRI) should go ahead and make them without approval. As Jeff Bezos describes only when you can't reverse them should there be a more thorough discussion.

Changing proposals isn't iteration

Changing something without implementing it is a revision, not iteration. Only when the change is rolled out to users can you learn from feedback. When you're changing a proposal based on different opinions, you're frequently wasting time; it would be better to roll out a small change quickly and get real world feedback. Never call a revision an iteration because it is always the opposite.

A few challenges have arisen with how we approach iteration. The best example may be the proposal of a two-month release cycle. The argument was that a longer release cycle would buy us time for bug fixes and feature development, but we don’t believe that is the case. As detailed above, we aim to make the absolute smallest thing possible, and that doing otherwise will only slow us down. We work on a two-week release cycle.

Embracing Iteration

In order to embrace iteration, the quality of your first iteration should not matter and it shouldn't discourage you from starting. We should have the attitude that we are trying to achieve as much as possible in a small amount of time; it's where we are at the end state of an iteration, that counts. The benefit of iteration is to get feedback from the end-user. Focus on sharing context on the end of the first iteration rather than a hypothetical future state requiring multiple iterations.

Make small requests for change

When you are submitting a proposal request for a change, or a process change in the handbook, keep it as small as possible. If you are adding a new page to the handbook, create the new page with a small amount of initial content, get it merged quickly via Handbook Usage guidelines, and then add additional sections iteratively with subsequent merge requests. Similarly, when adding features via Trello, consider ways to reduce the scope of the feature before creating the request to ensure your request is as small as possible.

Always iterate deliberately

Rapid iteration can get in the way of results if it's not thought out; for example, when adjusting our marketing messaging (where consistency is key), product categories (where we've set development plans), company structure or product scope alignment (where real human stresses and team stability are involved), sales methodologies (where we've trained our teams) and this values page (where we use the values to guide all Techmission team members). In those instances, we add additional review to the approval process; not to prohibit, but to be more deliberate in our iteration. The change process is documented in the Techmission Handbook Usage page and takes place via request approvals.

See it in action

Iteration is so important to Techmission that the MD hosts Iteration Office Hours to provide guidance and assist in breaking large, complex topics into MVCs and smaller iterations of work.

You can view these on our Techmission Unfiltered YouTube channel.

Iteration Competency

Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate iteration when we do the smallest thing possible, getting it out quickly for feedback and making changes based on that feedback.

Techmission Iteration Grade

Demonstrates Iteration Competency by…

Knowledge Assessment

Develops own knowledge by trying and failing. When asking questions isn't content with silence or unhelpful/incomplete responses, seeks out primary sources.

Knowledge Assessment for Individual Contributors

Actively looks for opportunities to iterate and contribute to boring solutions. Balances short term gains and long term benefit with team’s help. Ships things that aren't 100% knowing that you'll either be able to improve them in the next revision. Asks questions with abandon. Publicly shares failures if you'll help colleagues learn.

Knowledge Assessment for Individual Contributors

Independently balances short term gains and long term benefit. Identifies opportunities to deliver projects in an iterative way.

Knowledge Assessment for Individual Contributors

Is able to take long term goals and turn them into small actionable steps that can be implemented in an iterative way. Identifies and prevents decisions that are not “two-way door decisions”. Ships. All the time. Sounds like a broken record in discussions with more junior members of the team; always asking if we can make something smaller.