Roughly one year ago I handed over a software project that I bootstrapped for an internal project to build an innovative e-commerce business around second-hand garnment and sustainable clothing (🇫🇷). The time-window was pretty short (six weeks for the first PoC) and there was only one extra developer on the project but we made it and I could transfer the project to perpetuate and stabilize the business while I moved to other opportunities. At the same company a few years before I was invited to fix a pressing issue that could have led to severe liabilities. An important pipeline was stalling and risked putting many business processes to a halt. Institutional knowledge was partly lost and mostly transmitted by oral lore. Recovering the pipeline backlog and deprecating this pipeline took months, this project had from six to a dozen of people depending on how you count. The company is still around, so we can also call that project a success.

In both cases these projects were recognized as tactical endeavours. That is, one-time feats to achieve, with a fair amount of freedom to digress from some company guidelines and processes. Even though the scale and timeframe differed, what made both these critical topics click was not the technology, but the team dynamics. I made some internal presentations for each of the project, but I also wanted to share a bit to the outside world how I approach these projects. This article discusses my recipe to tactical projects.

A recipe for tactical projects

I wrote a couple of Twitter threads relating how I approach these tactical projects. A first lengthy thread discusses briefly my checklist and then motivates some items. The checklist gives you a set of tools.

The follow up thread is much shorter and stresses the approach and the importance of giving boundaries more than instructions. This approach gives you a set of behaviours.

We’ll get through the checklist then discuss key behaviours to encourage during tactical projects.

A checklist of communication tools

Successful projects require communication. If we stretch a bit, all the tools from the checklist I am about to give are a form of communication support. Communicating efficiently is hard because abundant communication is noisy: you cannot just fix communication issues with more communication but with better communication. In tactical projects, I believe that better means intentional communication. That is, do not multiply communication supports and focus on one usage per support. Such intentionality leaves no room for ambiguity as where to look for information and where to publish information.

Here is the checklist:

• 📖 one jargon-doc to map concepts
• 📆 one periodic-meetings doc
• ♎ one open-point/arbitrage doc
• 🙋 one communication channel for people
• 🤖 one dump channel for robots
• 👈 one entry-point doc which links to all the other docs

As for the specific tool you use for these documents and chats, the offering is pretty good today as long as they allow an online and direct-edition mode. Examples of good tools for such docs are GoogleDocs, Notion, Confluence. Pick the ones you are familiar with and that you already use.

Let’s now dig a bit each of the checklist item.

In depth review of the checklist items

This section just dives deeper in each topic. Each item deserves a lenghty discussion but I will be concise for the brevity of the whole article. Do not hesitate to contact me if you want me to expand on one aspect.

the jargon document

There is some selection bias in so-called tactical-projects, and often such projects will have the characteristics of the difficult project to rescue: business rules are blurry if not lost, documentation and specification may have drifted enough that even subject-matter experts have forgotten there is a documentation.

The problem you face with such a situation is the inability to get started, and the risk of having to roll back a lot of work once it is delivered because code is written with some miscommunicated assumption. Indeed, oftentimes terms may be overloaded and a same word will have different meaning depending on the interlocutor. The worst I have seen was a term that was defined in French, but when translated to English, was a slightly different concept for the same stakeholder. A seasoned engineer was agast when I told him so, because the code would not make a difference (and business-wise, the two concepts would coincide often enough for the happy cases, but could lead to corny edge cases otherwise). To solve communication issues, the first step is to have some mutual understanding between stakeholders.

Your role here is not to fix everybody’s language. That would be hopeless and too disturbing for most people anyway. Are we stuck then? Of course not! all hope is not lost: you can bring mutual understanding by exposing the differences in concepts for the same word. A common mistake I have seen is to write a glossary. You do not need a glossary, what you really need is a Rosetta stone .

I provide an example jargon-file in this jargon spreadsheet . Of importance is that you leave room for each stakeholder to disagree with your use of a term. In this way, everyone feels respected because there is no bias favoring the viewpoint of the file author. This is why the jargon file has a matrix of terms and stakeholders.

the periodic-meetings doc

When in the heat of tactical projects, you need some amount of synchronization with all stakeholders and teamates. Often, a few topics will be the focus of attention for a couple of days or weeks. You should forget synchronization emails because emails sent to many people invite cross-talk in replies and re-sharing truncated bits. If you use email to communicate, only use email for outbound communications to less-involved stakeholders (e.g., C-level executives).

Instead, I posit that you want some form of journal where you synthetically review these topics. At the same time, when reviewing these topics, it is marginally more expensive to review exhaustively what is on the plate of whom. Indeed, most of your efforts should be focused on the key topics du jour and only a few will work on other topics. Giving attention to these secondary topics is also important for the morale of those and for the habits of everyone because the focus will eventually shift. Additionally, keep some room to review HR topics, especially days off so that no-one is surprised when someone leaves for two weeks.

The following link is a template for periodic-meeting notes I like to use. You do not have to follow this template but I’ll tell how to use it. For each team meeting, add a section by copying the template section just below in the doucment and editing the date. You can prepare a section ahead of time and should encourage to fill-it in as they progresss (in my example “dany” has marked an update in advance). During meetings, review items, prioritizing new entries on key topics and action items from previous meeting. Copy and indicate carried over entries from previous meetings until resolution or decision to drop. Ensure that there is some markup to quickly identify people and action-items with their current state (e.g. AI for action item, @name of [name] for people, bold fonts, strikethrough for done tasks). It’s better to be clear than to be consistent. Updates should be synthetic and provide links to other work document to follow the specific topic in more detail (e.g., tasks in issue trackers).

The document will grow, I’ve seen such a document with hundreds of pages on Google Docs and they work pretty well. Only create a new periodic-meetings doc if editing the current one becomes unbearable (e.g., the software becomes too slow). Sticking to a single document has a multiple benefits: First, you have a single entry point to know what are the topics du jour and the blockers on these topics. Second, you get a quick access to who-works on what and a sense of who-needs support (e.g., if a name does not show up, maybe the person is suffering a loss of motivation). Finally, the document is easy to search with ctrl-F: everyone knows how to do that and the UX typically is better than cross-documents searches.

open-point/arbitrage

Tactical projects will mix people with different seniority. Further, you will need to pro-actively cut corners. Sometimes you will have to hand-over the project at the end of the tactical mission. Thus, it is better to keep track of all the key arbitrages in a single document. Arbitrage will often be required for technical aspects (e.g., architecture, database structures, naming conventions) but could also span business aspects (e.g., decision to drop or limit data-recovery to a time-bound).

I provide a design-document template in my talks section, which I recommend for large projects. For tactical projects you will not have the luxury of doing such good and time-consuming work. That said, you still want the benefits from some formal process: you want a minimal context and a listing of alternatives one can think about, then a status.

It is useful to have a table of content and a todo/done status in the titles to quickly see what has been decided yet and what needs arbitration.

Once the document is in place, spam it around. Encourage people to submit new open-points, link to them during the periodic-meeting.

As for the two previous checklist item, you can find an example open-points document.

one communication channel for people

Modern organization use some online group chats tools. If you don’t, start with this. Group chats are easy to adapt to different processes and work organizations. I’ve seen as many group-chats organizations as I have seen teams: some teams used a single channel, some other teams would create transient channels for open points. Overall I’ve seen success and failures in either setups. For a tactical project, I tend to prefer having a single communication channel. Indeed, the size of teams in tactical projects allow a single channel to be busy without becoming jammed (if you need to involve many teams, maybe you’re not on a tactical project but would need a whole backbone of engineering management).

The one communication channel serves for orchestration rather than as a support for communications. That is, use the channel to schedule/reschedule the periodic-meeting and ping people that the meeting starts. Also use the channel to first notify that something of note requires attention or requires arbitration. Key points should be discussed and related in the periodic-meeting notes or in the arbitration docs.

Avoid multiplying channels for open points because you will churn through them and lose track of what is ongoing and what is done. Having many chats with distinct and partially-overlapping sets of interlocutors is a recipe for cross-talks. You end up bringing the wrong topic in the wrong chat by mistake, when you need someone that was not invited first, they will lack the history (let’s be honest, chats history are horrible to process for humans).

If your channel tool allows to annotate channels with some topic message, link to the periodic-meeting notes in the channel topic.

An exception to have a few more channels is if you have regulatory requirements (e.g., some info must stay more confidential or require some clearance). But for this use case, private chats probably are a better venue as they feel more transient

one communication channel for robots

Automation is a special case that warrants an online chat as well. Automation will spam you about CI runs, people who pushed code etc. Overall, automation is screamy, pollutes, and does not respect your daily break.

Avoid overloading the communication channel for people with automated messages. This distinction is less important if all the stakeholders are tech people who understand that an “alert” may not be a reason for alert, nor that daily failures are expected.

The same points against multiplying channels as for the communication for people apply: you should favor a single channel until it becomes unbearable. Co-locating alerts with deployments notifications may help spot regression as well.

one entry-point doc to bind them all

Even though we introduced only five tools, that’s already five things to remember. An unreasonably cost-effective to help people navigate your tactical project is to curate some form of entry-point document that links to other documents like a menu. No discussion should occur in this document. It’s purely a for-consumption information to locate notable pieces of information pertaining to the project.

The list of things you can communicate in such a simple document is completely open. The entry-point document would typically carry links to some forsaken specifications or some internal report from external consultants five years ago. Linking these in the entry-point document should help distributing lost knowledge. Sometimes it is useful also to pinpoint one specific function in some source code and that is key in a business process (e.g., where some complicate computation runs).

One could argue that bookmarks are the right tool for this job, however the bookmark UX is really poor on average. Bookmarks are hard to share and synchronize. Few people likely have the habits to organize bookmarks. Plus, sometimes the content you want to likn-to is only on a file-system share, which you cannot easily put in web-bookmarks. This entry-point doc itself could be a bookmark you suggest, if not THE only bookmark.

Be generous in what you list in this document, the barrier to entry should be low enough. Avoid spamming anything you find so that people find value in browsing through the entry-point doc. I would say, any document or piece of code that is a reference and that has some time-validity in months or more is welcome in such a document. Do not link every ticket, pull request, version of data extracts from this document (the periodic-meeting notes should discuss these). If you prefer accepting junk rather than missing nuggets, add some visual separation between what entries made it into the list with versus without proper vetting.

Keeping the entry-point doc up to date is everybody’s duty, but you’ll have to evangelize this duty. Keep uttering the sentence “you’ll find a link in the entry-point doc” and be a good role model (say “I’ve added the link to the entry-point doc” until the other party gets into the habit of linking into the doc pro-actively). The tipping point where people see the benefit generally happens when you are faster to find a link for some piece of work than the author of the work.

The document itself does not need a lot of organizing, again Ctrl-F searches do wonder. You could use some spreadsheet or another shared doc. I’m giving an example as yet another google doc. Spreadsheet are really useful when you want to add coloring with automated formatting.

final words regarding the checklist

My checklist is based on experience with a number of tactical projects plus a few large projects that needed course-correction. I have not needed all of the items all the time, but the periodic-meeting notes is probably the most useful one. Indeed, filling the periodic-meeting document is a forcing function for many beneficial behaviours (e.g., it reinforces the team-spirit with the shared ceremony when reviewing the document, it identifies blockers fast, it let you plan ahead).

Lightweight processes and low-tech tools are enough for tactical projects. However, do not be fooled, tools are merely tools. Tools are here to reduce friction and relieve people from typical corporate aches. Reducing friction is not enough to build momentum. Successful tactical projects also require a fair amount of energy spent on keeping the team members productive, efficient, and motivated. We discuss these aspects of successful tactical project in the next section.

Behavioral aspects

Having nimble and intentional communication tools should lessen the friction and encourage discussions towards fast-decision-making. That said, nothing will happen if no-one leads the group and no-one champions the tools. You’ll probably need to initiate some management-style changes. The tactical project lead will act like a maestro giving rythm to the team, you’ll need some light ceremonies to build momentum, and give the right degree of freedom to individuals. Let’s unroll all of this.

The maestro analogy

A team is a social group, with complicated interactions and tensions between individual and the group. To achieve a tactical mission you need to ensure the team members feel motivated and energized on an individual level. At a same time the whole group must find the right tempo. As a tactical project leader, it is you role to set the tempo for the team.

I think that the orchestra and maestro analogy is a good fit for tactical projects. Think of individuals as players of different instruments, some play brass and some others may play strings. Each player has their own favorite style: some play jazz, some prefer classical. For your tactical project you may need them to play modern chamber music, hence contenting no-one. Even if you cannot play all instruments, you should know how the music should sound and have a good understanding of the partition a few measures ahead. As the person in charge of the tempo you need to know when to race and when to pause, you need to prepare transitions from adagio movements to presto sequences. In summary, setting the right tempo is not synonym with racing at the maximum speed.

How does the maestro analogy translates in the practice of tech teams? I would say that the most important thing is to ensure that every team member understands the tactical mission and how they contribute to it. The maestro does not play instruments but coordinates when individuals need to start, slow down, etc. Every music performer understand they are needed for the whole play to sounds great. For your tactical #project, everyone should be able to understand if they are on track or late, if they are facing a roadblock or if they have spare energy to help a stuck colleague. Such an awareness level requires careful attention to how knowledge is distributed: who knows which system the best? who can be onboarded on which parts of the project? and how long would such a transfer take? Only individuals can answer these questions, and to ensure that you get honest answers, you need to make sure that people feel safe to discuss their worries openly. In particular, you need to validate individuals as the right owners for their project-scope if you want everyone to be committed to the success of the tactical mission.

Once you have individuals that are committed, you get momentum. Your second goal is to keep the momentum – a goal best achieved by reducing friction. In particular, every team member should understand the group dynamics. This aspect is where your energy will yield the best lever: you should lead by example and encourage people (sometimes “vigourously encourage people”) to use the shared communication tools. For instance, to ensure the entry-point doc is up-to-date do not say “please add it to the entry-point doc”, rather you do it yourself but vocalise something like “ok, I’ve added it to the entry-point doc, took me ten seconds”. Publicly take notes on the periodic-meeting notes, and at some point your teammates will pro-actively do it. In short, demonstrate that you are adhering to the behaviors you want to encourage, and since you will be spending most of your time communicating, this will translate into an increased usage of the agreed-upon communication tools. At the risk of repeating myself, ceremonies are the easiest way to foster such behaviour changes. So let’s discuss it separately now.

Ceremonies

Ceremonies such as stand-up meetings with all the team members are common in tech companies. In general, such ceremonies are good in tactical projects as well because they help consolidate the team interactions. That said, like the checklist of communication tools, ceremonies are merely tools and they will not solve your problem.

An under-appreciated value of recurring ceremonies is their agenda-locking power: people have fewer pretexts to daze-off a known-recurring meeting. I find that daily meetings are too much overhead because there rarely is much ongoing in a single day (people may even resent days when they have no updates). At the opposite end, bi-weekly or monthly starts to be too far apart. Put in simple mathematical lingo, the number of updates is roughly proportional to the amount of work done. Too-close meetings will lead to low-value overhead, whereas too far-apart meetings become longer and harder for everyone to follow. Is there an optimal spacing then? well, unlikely, and even if there were one formula, the formula would require information you do not have. Fortunately, the tactical leader sets the tempo. Thus, you can adapt the schedule of such ceremonies to the number of people around and the urgency of the next deliveries. Daily meetings and even twice-daily meetings could be a perfectly-fine setup when you are very near a deadline. A set of rules is that there is almost no point in meeting if your feedback loop is slower than the delay between two ceremonies (you should here focus your effort on speeding up your feedback loop). If your feedback loop is very fast (e.g., you can try changes and analyze results multiple times a day) you are in a spectacularly good place: but to avoid fully-saturating everyone’s agenda you should encourage people to try multiple things and aggregate learnings of multiple rounds during full-team ceremonies. Thus, feel free to adapt, but be listening to people in order to avoid erratic schedules.

In my typical tactical project setup, I generally try to have a weekly to twice-weekly meetings. During these meetings we beam the periodic-meeting notes on the screen and we go through updating and reviewing all items together. Thus, everyone can see the notes in live and everybody can see people editing the notes in live. We do not do a full round asking people taking turn. We primarily focus on what the document contains. People who make the effort to list their updates in the doc get their topic discussed first. At the beginning of the project, I type out all updates myself so that people understand what I expect of them regarding the level of details, the conventions for highlighting action items etc. Then, as momentum builds up, I no longer need to take on this job as people pro-actively fill-in the updates. If a person has no updates for one meeting it’s ok, when an absence of updates is recurring, you likely need to dig more into the situation and sense if you need to unlock something.

Lage ceremonies are taxing, and for you as a leader, doubly so. Spend some effort to ensure that people get motivated during ceremonies. Time-keeping is a simple way ensure there is some rythm during ceremonies. Then, find ways to spice-up meetings. Sometimes subtle changes are enough to relieve some pressure off people and remind them there is life outside work. Simple things like changing the template on special dates (e.g., add an Easter Bunny 🐰 emoji around mid-April) or adding memes relevant to a recent achievement along the way are enough to break the bureaucratic routine of work ceremonies.

If you succeed in setting the right tempo, you will notice that people welcome the time of the ceremony. If you are the one who is late they will ping you and ask you whether to start without you (and you should definitely answer ‘yes’). If you are absent, delegate and you will be surprised that the output in your periodic-meeting notes is consistent with when you are present. From experience, the lack of a timekeeper is the first flaw to appear in ceremonies if you are absent for too long, but if you stress this point enough, handing-over the token of ‘ceremony leader’ should be easy.

To summarize, keep your ceremony predictable. Invest a lot of personal energy into setting these ceremonies up: lead by example, set the tempo, be a good time-keeper and time-sharer. Maximize re-use with the periodic-meetings notes document. Ultimately, no-one will dread a regular ceremony where the organization is smooth and where everybody can get a chance to voice concern or receive praise.

The only thing you may get irrecorevably wrong while setting up a recurring ceremony is if you are (or appear as) “the one giving orders”. One way to prevent such a situation is to adopt a directing style where individual have a lot of agency. Such a style deserves a discussion in itself. Thus, let’s discuss how to set boundaries so that individual can roam freely within the boundaries and impress you with their results.

Directing with boundaries

People sincerely hate micro-management. The key difficulty when managing people, and probably even more so in tactical projects, is that you do not know what people judge as micro-management versus honest sheppherding. Individuals have different history and hence they also differ in perception and tolerance threshold. As a result, you have to probe with trial and error. Be carefull how strict or permissive you are with each individual. This style requires two things: empower individuals, and properly set boundaries.

To empower individual, remind individuals that they are the expert in their specific zone. Indeed, in tactical projects, there will often be little overlap between topics as the team is spread thin. Therefore, even a junior engineer will soon become the best person knowledgeable on some piece of code or some lost business rules. All it takes, i a couple of focused days studying the gory details of your forsaken system. Remind them of this simple fact, praise them as they become the go-to person for some fields in your project. Praising is a double-edged sword: people may feel the impostor syndrome. If there is enough emulation in the group, impostor syndrome should not be an issue. There will be more than enough energy in the air for everyone to course-correct lack of confidence or self-esteem.

If you empower individuals and give them a lot of wiggle room to implement solutions, you then need to properly set boundaries to avoid two things: one the one hand you need to prevent territorial issues when scopes may collide (e.g., some technical work and some business-rules work which both led to changes on the same system but with diverging visions regarding technical choices or implementation schedules). On the other hand, you may end up with a dysfunctional system because some key assumptions you hoped to leverage was not properly communicated and overlooked (e.g., you wanted some new function to be idempotent because down the road you plan to change the architecture and are at the early phases). In both cases, the main risk is a breach of trust, which will have compounding effects for the remainder of the mission. In short, boundaries are good for the group.

Boundaries that are good for the group are in tension with empowering individuals. Hence, it is worth practicing the art of designing boundaries. Instead of providing schemas of what to build, rather, you explain some key behavior or invariants that you would like to see being built. Provide some toy examples, agree to validate that the individual understood the concept (e.g., you commit to personally review the tests). Motivate, and rephrase boundaries, informally (e.g., the zorgulino criterion is that all time you make a change, you need to see only diffs in the positive direction in the all-accounts total) and formally (e.g.,this value is non-decreasing of version numbers etc.). Adapt your message to how your peer answers, some will prefer the informal style, some will prefer the formal one. Some will want the whole explanation, others will want the description of the problem and will want to guess the consequences. It is extra work to explain (and sometimes repeat many times) what are key invariants and key properties that you want in your system. Repeating is worth all the time it took. On the first hand, articulating such properties to a peer will clarify and sediment your understanding. On the other hand, keep in mind that you have smart individuals who can also see issues that you have missed and anticipate second-order effects that you had discounted too fast. These are the characteristics of a win-win situation.

If you manage with boundaries, you will enable the best of the individual, and the best of what the team can achieve: the most favorable conditions for your tactical project.

Conclusion

Tactical projects are stressful, the specific problem at hand may not be super appealing (forsaken data pipelines with unclear business rules, desperate deadlines for some uncertain business with apparently more career risks than opportunities). You may not be able to establish yourself in the long term in the company if you only do tactical projects. However, these projects can be fun and rewarding.

Tactical projects ask for a lot of energy, especially when setting up the team structure and building the initial momentum. Tooling and procedures should privilege low-tech tools so that no time is lost installing or learning tools and procedures. Tools help you minimize friction. You can significantly reduce friction if there always is the same answer to ‘where do you find the doc’ or ‘what did we decide about’: lookup the entry-point doc and follow the links. After the initial phase, you will also need to consistenlty spend efforts on adapting the tempo. Ensure that people are energized and get some rests and some small achievements. Pick one ceremony and make the most out of it: engage your teammates. Verify that they have enough but not too much on their plate. And when directing individuals, ensure they have agency to operate on well-defined boundaries. Things will click and you’ll meet success.

A number of the above teachings are also applicable to organizations of larger sizes than a tactical project. Some adaptation to the checklist will be in order. However I believe that what you really need is to relay and repeat the pattern at different scales. It is definitely possible to have one ceremony with team-leads of a dozen of #teams sharing a periodic-meeting notes and a large jargon file. It is still possible to settle boundaries for teams, which will help you devise and follow up on larger plans. However you will face scaling issues as you will need to get a good sense of what a team is working on at different scales (a problem we are helping you solve at EchoesHQ, my current employer). You will not have the energy to give the tempo into every team and every individuals, you may face alignment issues, leading to bad team-play. That said, such a problem could be solved by empowered managers as well.

Some tactical-projects teammates, bystanders, recounted they have seen progress on topics they thought were doomed. Individual in tactical teams told me how they were considering to leave the company or ask for an internal move, but stuck as they saw something different and started learning from other team members. Most importantly, I have build pretty strong bounds with a few colleagues during tactical projects because the energy in the air is vitalizing.