You know what's required for the project․ You know the project limitations and deliverables․ You know what to build for the project․
You open your IDE․ You write code․ You make progress․
Then you get a message․ A meeting is scheduled․ A new time-sensitive task arises․ You're asked to review some code․ When you return to your original task‚ you may have forgotten some information about it․
The problem is not self-control․
It is the absence of protection for sustained effort․
In Part 2‚ we discussed reasons that real engineering means clarity‚ not coding․
Now‚ my next question is:
Once you have a plan‚ what strategies can you use to maintain mental resources for executing the plan?
This is a function of Focus‚ one of the F in CRAFTER․
🧠 Cost of Multitasking
Modern software engineering is typically a group effort․
A developer's day could include tasks such as using an IDE and other collaboration software‚ including Slack and Teams‚ reviewing and working on pull requests‚ attending meetings‚ checking production alerts‚ and engaging in other conversations about unrelated tasks․
Individual activities may be fine․ Frequent and unpredictable switches between activities are a concern․
Consider a developer working on a complex business rule․ That developer learns about the domain and business rule and other relevant information and begins writing code to implement the business rule․
Then they receive a notification․
The interruption could last one minute․ Costs of the interruption include the time it takes the developer to resume work‚ including recalling prior thoughts and tasks and any assumptions helpful to completing the task․
This is an additional cost of context switching․
The cost is not only the time spent replying to the message․ It also includes time spent refocusing on what you were working on before receiving the message․
Repeated interruptions can lead to:
- Additional time required for orientation․
- Increased risk of overlooking corner cases․
- Longer debugging time and development cycle․
- More unfinished and poorly made work․
- Less confidence in estimates or other commitments made about delivery times․
The goal is not to prevent collaboration․ Software engineering is a collaborative process․
The goal of the project is to develop conventions for working together that make it possible for engineering workers to perform difficult cognitive tasks․
Focus is not the same as working more․ Focus means reducing distractions that keep you from doing other work.
🎯 Deep Work as a Protected Engineering Resource
Deep Work is prolonged‚ focused concentration on a challenging task․
Options for software engineers include:
- Educating yourself about a topic that you know little about․
- Implementing well․
- Testing a production defect․
- Refactoring a complex part․
- Evaluating architectural trade-offs․
- Proof of concept․
These projects require skills beyond those needed to write code using an IDE․ They require skills related to maintaining mental models over time․
CRAFTER sees Deep Work as a useful guide and resource․
A general aim for most jobs is to dedicate 2-4 hours a day to Deep Work‚ if that much time is available during the workday․ This can be a goal for most people in most jobs․ It is not a general requirement or average time dedication for most jobs․
Some days include more meetings‚ code reviews‚ help with other people's problems‚ pair programming‚ system outages‚ and other interruptions․ Less time may be appropriate on some days․
The operational goal is not to earn a specific number of hours․
It is intended to protect time for work-related activities from other demands․
For framework principles‚ see CRAFTER‚ (F) Focus․
Plan the code block outside the IDE
A focus group should have a purpose․
Instead of writing:
Work on payment processing․
Define a concrete outcome:
Monitor payment status updates and identify the missing validation․ Develop a minimal implementation with tests․
Having a clear agenda reduces the amount of discussion required during the meeting․
Before starting‚ establish:
1․ Outcome: What statement should be true at the end of a session?
2․ Boundaries: What parts of the system are included?
3․ Next steps: What is the first concrete step to take?
4․ Interruptibility policy: What other events can interrupt the session?
This learning outcome is associated with the Focus concept taught in the CRAFTER course module Cognitive Clarity․
Clarity provides direction․ Persistence ensures you can continue on the path․
🔕 The Zero-Noise Protocol
The Zero-Noise Protocol is a technique for protecting work time from interruptions and other distractions․
During the block:
- Slack and Teams notifications are turned off․
- Notifications on the phone are disabled․
- Email notifications disabled․
- Unrelated browser tabs and programs are closed․
- Incoming requests are executed at the end of each block except in cases of predefined interrupt conditions․
The purpose is not to become unreachable․
It is to distinguish between default and mandatory availability․
Define an emergency exception
A protocol that fails to handle emergent situations is not good engineering practice․
Teams should plan how to respond to emergency situations․ Possible responses include an emergency chat channel‚ phone call‚ and other incident-related approaches․
For instance:
- Production problems with the customer experience can break the blackout period․
- A security incident may result in a block being compromised․
- A common status-related question can be answered later․
- Optional code review during a future shared work period․
The specific requirements depend on the team's needs and objectives․
The main concern is making exceptions explicit‚ not according to how urgent other warnings are believed to be․
Make the protocol visible
A status label can inform other employees about the arrangement:
Deep Work through 11:00․ Ways to reach me for general questions: leave a message․ Way to reach me for production crises: same as before․
This tells your coworkers when you are available without them having to guess when you are available․
Protect the group‚ not just the individual․
Zero-Noise works best as a team practice․
If one engineer does not want to receive notifications and the other engineers want rapid responses‚ this process will be difficult to sustain․
Teams can take steps to mitigate these problems‚ including:
- Predictable collaboration windows․
- Designated authority to provide emergency services․
- Explicit response-time expectations․
- Policies about how to escalate incidents․
- Time off meetings‚ where possible․
Zero-Noise is not a communication method․ Zero-Noise is an agreement between team members to reduce disruptions to focused work while remaining available for operational purposes․
🔄 Default Asynchronous Communication Tools
Some interviews can be done other than in person․
Many discussions between engineers can be done asynchronously to allow them to participate in discussions at times that suit them best and other work activities․
Examples include:
- Routine status updates․
- Justifications that do not interfere with work․
- Code review comments․
- Documentation questions․
- Design proposals․
- Feedback requests where timing is not important․
Asynchronous communication does not mean failing to communicate․ Asynchronous communication means choosing the right communication channels‚ depending on the complexity and urgency of the topic․
Write texts to reduce communication effort
A good communication from an engineer provides enough information that the recipient of the communication does not have to ask questions to learn more about the problem․
A practical structure is:
1․ Context: What project are you working on?
2․ Problem: What is unclear or hard to understand?
3․ Evidence: What have you already checked?
4․ Decision required: Response or other action needed from you?
5․ Timeline: How quickly does the person need the information?
For example:
Context: I am mapping payment statuses․
Problem: The status value returned by the external API is not one of the defined enum values in our application․
Evidence: Existing maps show three possible statuses․ The latest answer adds a new value to the possible set of values․
Decision required: Map the new status to an existing internal status or add a new internal status?
Deadline: I need to know by the end of today's map-making session․
This is better than:
Can you do me a favor when you have time?
The first message gives the recipient useful information for making a decision․ It also explicitly tells the recipient what decision to make․
Use collaboration windows
A team can establish times when team members will respond to general communications․
For example:
- Morning hours are typically reserved for planning and other urgent work․
- Midday: answering questions and collaborating with other employees․
- Afternoon: more study time‚ if needed‚ depending on other commitments․
These are recommendations‚ not rules․ Teams should adapt these recommendations to their locale and other team considerations․
The aim is to reduce interruptions while not substantially increasing total communication time․
When synchronous communication is needed
Some issues are best resolved in a short phone conversation․ I would use this method in the following situations:
- This is a complicated problem with several ways to interpret it․
- Multiple individuals need to reach a decision through negotiation․
- The team is responding to an incident․
- Written debates are getting in the way of communication․
Asynchronous communication should be the default for many work tasks‚ not a religious stance against other types of communication․
The policy is to communicate using whatever method is easiest for you to use that effectively resolves the problem without creating other problems․
🧩 Context Switching and Technical Responsibility
Interruptions are one source of fragmentation․ Work in process is another source of fragmentation․
When an engineer has multiple tasks to complete‚ these competing tasks distract the engineer․ In the absence of other distractions‚ the engineer will be thinking frequently about how to prioritize tasks and recall information about incomplete projects․
This creates internal context switching․
CRAFTER offers a solution with a simple rule:
Limit Work In Progress (WIP) to no more than three active projects․
This is a policy imposed to encourage good prioritizing․ It is not a policy that every engineer or team should have exactly three tasks․
The idea is not to overextend yourself and to finish important projects․
Differentiate current jobs from queued jobs
A task need not be completely forgotten because we are not currently performing it․
Have a list of potential future projects ready‚ but work on a limited number of projects․
For each task you were given‚ include:
- Its intended outcome․
- Its current state․
- The next step in the process․
- Any blocking dependency․
- Rules for deciding when an investigation is complete․
When a new request is made‚ do not add it to the list of current requests․
Ask:
1․ Is it more important than what you're doing now?
2․ Do I need to act now?
3․ If it needs to be active‚ what other process will be delayed?
4․ Who should know about this change?
This makes it clear about extras and prevents additional requests from being added without the requester's knowledge․
Ownership means maintaining continuity
Technical ownership doesn't mean you will be working alone․
An engineer can depend on other engineers and peer reviews‚ as well as a product owner․ Responsibilities of an engineer include maintaining the continuity of a project and other forms of communication about the work done on the project․
A task should not depend on the memory of a single person․
Document important decisions or assumptions and next steps in an appropriate place‚ such as a ticket‚ pull request‚ or Architecture Decision Record (ADR)․
This can speed your recovery from interruptions and help you work with others by assigning tasks and providing information․
Good ownership reduces the mental burden of picking up work on projects for engineers and other staff․
📊 Methods for Measuring Employee Focus Without Surveillance
CRAFTER offers Focus tools to help spot trends that make it harder to implement engineering solutions․
Metrics are best used to identify issues․ They are not good for evaluating or monitoring engineers' performance or progress․
| Metric | Rule | Use Case |
|---|---|---|
| Deep Work Time | Recommended goal: 2–4 hours per day‚ depending on role and other considerations | Determine if sufficient time is available for deep work |
| WIP Limit | Three or fewer tasks in progress | Reduce multitasking and task switching |
| Notifications | Record interruptions while engaged in Deep Work | Identify sources of avoidable distraction |
These actions are useful only with other information․
A low Deep Work score could mean you attended many meetings and completed other collaborative tasks․ It could also mean you had a busy day in other ways․ A low Deep Work score doesn't necessarily indicate poor performance․
A high level of interruptions for a team suggests that process problems may exist for the team as a whole‚ including unclear escalation rules‚ rather than personal problems with a single team member․
Likewise‚ meeting a numerical objective does not mean good engineering has been performed․
The goal is to ask better questions:
- Do engineers have enough uninterrupted time for complex work?
- Are interruptions preventing other work from being done at planned times?
- Do you have several tasks to work on?
- Do interruptions occur in particular workflows or processes?
- What small change can we implement to make things better for team members?
Use answers to improve the system․
Measure the conditions of execution‚ not the engineer's worth as an engineer․
See CRAFTER Focus Metrics on this GitHub repository page for metric definitions related to the framework․
🗓️ Your Daily Priorities Process
CRAFTER's daily activities follow the Focus process principles․
1․ Pre-Flight‚ 10 minutes
Before beginning demanding work:
- Review current priorities․
- Choose one key task to focus on․
- Help establish the goal or objective․
- Determine relationships and knowledge gaps․
- Prepare equipment and disable notifications for apps you don't need․
The purpose of the warm-up is to prepare for activities in the session rather than spend some session time deciding what to do in the session․
2․ Deep Work‚ Breaking the Noise Barrier
Focus on completing the assigned task without other interruptions․
Remind yourself why you are doing something․ Don't get distracted by new tasks because you think they are interesting or important․
If you need to work together‚ write a question and use other communication methods as needed‚ unless an exception to the block agreement applies․
The length of protected time should be reasonable given the length of the project and the workday․ It's better to protect less time than to set unachievable goals․
3․ 20-Minute Rule
If meaningful progress isn't being made over a period of 20 minutes‚ stop using strategies that aren't working․
Pause and reassess․
- Set goals for yourself․
- Assess what you know and what you don't know․
- Present a flowchart or other graphic illustrating the relevant relationships․
- Assess assumptions and other facts․
- Determine if other actions or help may be needed․
This policy is not designed to prevent students from attempting to work through difficult problems for 20 minutes․ Rather‚ it is designed to encourage students to try different approaches if they work on a problem for 20 minutes without success․
Sometimes the best option is to do more research․ Sometimes the best option is to seek advice from a subject-matter expert․ Sometimes the best option is to reconsider the question itself․
The important thing is to perform the next step mindfully․
4․ Postflight‚ 10 minutes
End the session with a review of session highlights․
Possible applications are:
- Creating a commit․
- Creating or updating a pull request․
- Reporting the results of the study․
- Updating status information for the task․
- Documenting a decision or challenge․
Then introduce an action item for the next meeting: Note an action step to be performed at the next meeting․
For example:
Next: Test for an unknown payment status․ Use the results of the test to modify the mapping function according to your expected internal state․
This small step can save time and effort in reestablishing project background information later․
See the CRAFTER Daily Protocol: The Core Loopfor instructions on this process․
🚀 Quick Answer: Introduce Focus This Week
You don't need to do anything differently than what your team members are doing to begin․
Try a small experiment:
1․ Choose a task․ Look for a task you can continue working on․
2․ Set aside time specifically for work․ 45-90 minutes may work well‚ accounting for other obligations․
3․ Suppressing Other Alerts․ Disable other alerts and specify a way to alert workers in an emergency․
4․ Limit work in progress․ Train staff to handle no more than three tasks at once and make trade-offs visible when priorities change․
5․ Provide feedback․ Take time to record accomplishments and next steps before starting other tasks․
6․ Evaluate the experiment․ Determine which interruptions could have been avoided during the experiment and ways to prevent interruptions in future experiments․
Don't evaluate the experiment based on the amount of time you spent without notifications․
Determine whether it helped you finish tasks more quickly by reducing the number of times you had to switch between tasks․
🔮 What's Next?
Focus aids performance on implementation-related tasks․ Other skills that help engineers throughout their careers include adaptability to new information and other implementation-related issues․
In the next part of CRAFTER, we will explore Technical Mastery: how engineers develop and apply technical expertise to build reliable systems, make sound engineering decisions, and maintain sustainable execution.
🧬 Conclusion: Focusing Is an Engineering Skill❤️
Engineering productivity isn't just about typing faster or responding to more emails․
Complex tasks require time to understand a problem and develop and maintain knowledge of a problem‚ including considering and balancing other factors‚ to apply effective solutions․
Interruptions to this kind of work have costs beyond lost time by workers completing interrupted tasks․ Other costs of interruptions include decreased worker concentration and quality and increased uncertainty about when tasks will be completed․
CRAFTER Focus offers a number of practical solutions to this problem:
- Protect time for Deep Work․
- Apply Zero-Noise policies and have clear emergency procedures․
- Communicate asynchronously when you can․
- Decrease work in progress․
- Demonstrate technical knowledge and leadership by sharing visible decisions and next steps․
- Introduce measures to assess work conditions‚ not individual employees․
- Wind down at the end of each session so you can easily start the next session․
These methods won't completely prevent interruptions․ They don't need to․ Engineering is a social profession that requires collaboration‚ responsiveness‚ and adaptability․
The purpose of the method is to reduce‚ not increase‚ distractions; foster‚ not hinder‚ collaboration; and eliminate‚ not require‚ self-discipline․
Focus is more than concentration․ Focus involves setting up the proper environment for concentration to be effective․
That is what Focus is in CRAFTER․
Top comments (0)