How we work

Cycles

We work in 6-week cycles at Intempt. This fixed cadence serves to give us an internal sense of urgency, work as a scope hammer to keep projects from ballooning and provide a regular interval to decide what we’re working on.

The idea is not that everything we ever decide to work on has to take six weeks or can be completed in that time. But rather that we think about how we can break big projects into smaller ones that can be done in that amount of time, and that we bundle smaller things into a presentable scope of work that can be discussed.

This is particularly important for the product teams. Here we like to designate the work we take on with the scope in mind up front. We think of a small feature as a 1-weeker or a big feature as a 6-weeker (or anything in between). This designation helps us avoid a 1-weeker snowballing into a 4-weeker, just because people keep piling on more scope. Work is thus limited by a budget, and the budget focuses our discussion about what’s reasonable and what’s not. When a project starts slipping on its budget, the first approach should be to judo the problem and scope hammer the domain – and certainly not make it up by working more hours! Most things we work on can fit within six normal weeks.

Cooldown

In between each cycle, we spend two weeks cooling down. That’s the time to deal with bugs or smaller issues that come up, write up what we worked on, and figure out what we should tackle next. It’s sometimes tempting to simply extend the cycles into the cooldown period to fit in more work. But the goal is to resist this temptation. Yes, sometimes a little spill-over will happen, but it’s helpful to think about the end of the normal cycle as “pencils down”. That means that by week 5 of a normal cycle, we should be winding down, getting ready to launch, make sure QA is lined up, and all the other work that happens during and after the launch of new projects.

Communication

It’s hard to keep up on what everyone is doing and what it means, if you just watch the stream of latest activity scrolling along in Slack or weekly commits. (It’s also a waste of time and source of stress to even try.) Instead, we have four chief mechanisms for keeping everyone in the loop about the work that’s going on.

First, there’s the daily question of What did you work on today?, which supplies the nitty gritty details, but as a personal narrative. They’re a great conversation starter if you see someone working on something you either care about or want to learn more about. Please do use them as such! You’re obliged to answer this question at least twice a week when you’re not out.

Second, there’s the weekly question of What will you be working on this week?, which details your intentions for the coming week. Everyone is obliged to answer this question when they’re not out.

Third, there are heartbeats. These are the team versions of What did you work on this cycle? This is where we summarize and celebrate the work that’s been done. Product Management is obliged to write or designate someone on the team to write, this account one week after a cycle has ended.

Fourth, and finally, there are the kickoffs. These are the team version of What are you going to work on next cycle? This is where the plan for the coming six weeks is presented. Product Management is obliged to write, or designate someone on the team to write, this account before the start of the new cycle.

These mechanisms work together to free individuals and teams to run their days and cycles with confidence and independence. We have six opportunities per year to make big decisions about what to work on, and the rest of the time should chiefly be spent carrying out those short-term plans. By having clear expectations for communication, it’s easier for everyone to build trust in where we’re going and why.

All these questions and write-ups will be posted in the What Worked project for the current year.

Pitches

Whether you work on the product development or not, your voice and observations can help determine what we should be working on. The way to exert this influence is through pitches.

Write-up your idea of a new feature, a change to a feature, or any other product development you think we should be considering as a fully considered post (the more specific, the better). This gives the whole company a chance to consider and respond to the idea, and then we’ll have the idea encapsulated in a post, available for reference at any time.

There’ll always be more pitches than we have time to field, though. So it’s important to have realistic expectations about what will happen after you posted your pitch. The default is simply that everyone involved with product development (and probably most everyone else in the company) will read and consider your pitch. That’s a win right there. Even if the full pitch doesn’t make it in, it can impact other product decisions by shining light on a weak point.

While a few pitches might instantly strike a chord loud enough to go on the plate for the next cycle, it’s more likely that your pitch will sit for a while first. There are always more ideas than time, and we can only get a few things done each cycle. So chances are that even if everyone agrees the pitch is a great idea, it might not be the next most important thing for us to tackle. Don’t be discouraged by this. We’ve had many pitches that have sat for many cycles, if not years, before finally coming together and then happening.

‘Small Council’ is the team evaluating pitches for inclusion in the next cycle. Before the start of every cycle, Product  kickoff will list all the pitches that have been selected to be worked on.

Asynchronously

We have people working some different hours and we don’t enforce a lot of tightly-coupled workflows during the day, but that’s a feature not a bug. Most of the work you do at Intempt shouldn’t require you to be in constant communication throughout the entire day with someone.

It’s far better for everyone’s concentration and sanity if you collaborate as though most things will get an answer eventually, but not necessarily right this second. Your first choice of action should be to post a message, a todo, or a document about what you need to explain or need to know. Then others can read it on their schedule, when the natural lulls of the day allow it, rather than being interrupted right in their peak flow time.

Don’t take that as gospel, though. Some times you really DO need to tightly collaborate with someone for an extended period of time, and that’s fine. We have pings, hangouts, screensharing, or even in-person collaboration for when nothing else will do. (But most of the time something else will).

All that being said, you should still ensure that there is ample overlap with the people you work with most of the time. While most roadblocks can just as well be cleared in 15-30-60 minutes, they become real annoying if it’s a one-day turn-around every time.

In certain departments, like Support and Ops, it’s even more important that people are dependently available when they say they will be. That work has a lot of interrupt-based jobs that simply needs to be done right here, right now. So what applies to almost all work for design and programming and QA may well apply a little less frequently there.

In self-sufficient, independent teams

Organizational theory is thick with descriptions of the trade-offs between functional and project company structures. We seek to be more project than functional. This means a single project team should be able to go from idea to deploy as independently as possible.

Thus, the fewer other departments a team has to pass through on their road to rolling out a new feature, the better. We should be working on opening all these natural road blocks that form by default when you have awesome, strong product teams.

For example, a team working on a new Journeys feature should be able to test and integrate their work with CDP without involving CDP. CDP shouldn’t need a special heads up, and thus interruption and mental overhead or even guilt from lack of participation.

Similarly, a native feature that requires an change in how our Analytics system works should be carried out by that native team directly.

When we need to use the staging environment, that should be self-service too. Have a script anyone can run to restore it. Don’t require going to ops and waiting around for someone to do it for us.

None of this means we can’t talk together or ask experts with more experience or expertise for their advice. It just means it shouldn’t be a required, necessary step to make Intempt better.

As soon as organizational bottlenecks form, like a slew of features waiting for “the connector  integration”, we’re dragged towards more micro and detailed schedule management. It becomes a critical path with dependencies and making sure team Z is available just at the right moment for team A, such that nobody is blocked. That’s a poor fit for our organizational aspirations, so we have to work to counter that.

With managers of one

Managing at Intempt is a part-time occupation, next to being involved with doing the work itself. This means we rely on everyone at Intempt to do a lot of self-management. People who do this well qualify as managers of one, and we strive for every one senior or above to embody this principle fully.

That means setting your own direction when one isn’t given. Determining what needs to be done, and doing it, without waiting for someone to tell you to. A manager of one will spend their time well when left to their own devices. There’s always more work to be done, always more initiatives to kick off, always more improvement to be had.

Balanced

We limit ourselves to a 40-hour work week. Keeping our hours at work limited forces us to prioritize the work that really matters. A healthy amount of sleep and a rich and rewarding life outside of work should not be squandered for a few more hours at work.

There are occasions where teams or individuals need to work off-hours for on-call, maintenance or emergencies. This time should not be in addition to your normal working hours. Use your discretion to take time off to make up for the additional hours you put in during the week.

1. Intelligence: At Intempt we value intellectual rigor. The best heuristic is whether we ask the right questions of each other and of ourselves.

2. Learnability: Underpinning traits are curiosity, ability to self-reflect, humility, drive and demonstrated ability/track record of knowing *how* to find the right answers. Hint: See above, sometimes just simply ask the right question (directed to the right person). We hold strong opinions, weakly.

3. Character Building: We trust two character traits - initiative and people with "backbone". Very important because one without the other will not work. Four words of people who do well at Intempt is "I'll figure it out". You don't have to figure it out alone but you do have to figure it out with the team and this means knowing how to engage a busy team. Most people recognize when someone is working well and needs a helping hand and they'll go overtime for them. This is also character.

And then have tenacity - go over a wall, go under a wall, go around a wall or realize the wall isn't relevant anymore. Fk the wall. This is also character.

4. Communicate & Collaborate: We over-communicate through voice, emails, Git and Slack. We are over-transparent. We create a culture of respect, inclusion and trust. We create psychological safety without compromising your values. This is incredibly hard. This means making each other uncomfortable if we don't demonstrate our values. We are not afraid to give candid feedback, even when it is uncomfortable or exhausting. And yet, when a decision is made, we commit fully. Backbone is the conviction to disagree and yet commit.

Remember, the customer is the ultimate judge; better than anyone at Intempt.

5. Thinking & Writing: We write concisely and clearly. As a remote-first company, clarity of writing becomes increasingly important. Note great critical thinking precedes great writing; there is no great piece written without solid thought. So what is critical thinking? It is the ability to ask yourself critical questions about tactics. It means you have a systematic way of making decisions. You know upside, downside, constraints, resources and they're all wrapped up in the decision to do (or not do) something. What's the opposite of this? Lazy thinking is about making assumptions and the most awful of these is when you don't even know you made assumptions. You operated in a black box of assumptions that were non-transparent to your peers or more senior staff (and it didn't get caught till the end). This is a surefire way to not get trusted with larger projects or larger responsibility and you'll wonder why.

6. Consistency: Success does not come from occasional bouts of genius (we do take those with pleasure). Success comes from how we show up every day. Show up right and we get used to kicking the dumb idas to the curb and implementing more good decisions. These good ideas compound.

7. Get Shit Done: Sometimes these values can be hard to live out in context. It usually just means a situation is testing our values and the decision is too big for our breeches. This is paralyzing. You won't know if you made the right decision until after you've made it. But you have to just do it to feel it. So get shit done. Ship it. The market takes no prisoners and will show you the way.

Remember, what we are hired for. We're not hired to push code, words, pictures or meetings. We are hired to think critically, make decisions and solve problems - the way we express that is a variety of building and selling motions someone happened to call a software company.

If you want to work at Intempt you can check our job ads here