Build trust

One of the most significant benefits of using plain language as a technical leader is that it helps you avoid misunderstandings and build trust. Consider a couple of my most detested phrases:

"Let's put a pin in this."

"I'll circle back later."

Besides potentially sounding dismissive, phrases like these don't help your team understand what to expect. Will you revisit the topic later today or in two weeks? Should they take any action in the meantime? Should they wait for you to bring up the subject again, or was this your subtle way of saying "no," to an idea?

Instead, choosing more specific language helps to let your team know what to expect as well as builds their trust in you when you deliver on those expectations. Try something like, "I'll give this some thought and follow up with you tomorrow." and then set a reminder for yourself to do just that.

When you make commitments, speaking plainly about what you plan to deliver and when you plan to deliver it helps your team members as well as senior leadership to understand your intentions. When you deliver on your commitments, your team members and senior leadership will appreciate your clarity, and they will trust you more in the future.

Speak clearly and save time

When everyone on your team is on the same page, there is less back and forth, and you can avoid misunderstandings and rework.

While ambiguous or vague language can lead to different interpretations, plain language ensures that all team members have a precise understanding of the requirements. Additionally, when you use plain language, you encourage your team members to seek clarification whenever something is unclear. This helps eliminate the tendency to make assumptions about requirements or expectations, which often leads to rework.

Don't shy away from making goals and expectations explicit. Don't say that you'd like something to be addressed "sometime this week," unless you're happy to have it on Friday at 5pm. If you ask someone to complete a task, provide a clear description of what "complete" means. Your team members will appreciate your clarity, work with more confidence, and be more likely to approach you with any questions or concerns.

Know your audience

If you wish to be well understood, it is essential to know your audience and tailor your language to suit them. When you are speaking to a non-technical audience, using technical terms can be unhelpful and confusing. Similarly, using unspecific words like "integration" does not help a technical audience understand what you are asking for. Instead, be specific and use language that your audience will understand.

Even when working with your developers and using technical terms, you should still be specific. For example, instead of saying, "The API should return an error," you could say, "When a user signs up and the request is sent to the createUser API endpoint, the API should return a structured error with a human-readable message if the process fails." While there may be things that seem obvious to you, it's unreasonable to expect team members to read your mind. Err on the side of specificity and help ensure that everyone on your team understands the goals.

Generally, avoid using technical jargon and business buzzwords as it's possible that your team members may not be familiar with them. When you use plain language, you ensure that everyone on your team understands what you are saying, and there is no miscommunication.

Take it to work today:

1. Speak clearly and avoid business buzzwords to prevent misunderstandings and rework. Use plain language to articulate requirements, expectations, and feedback, and encourage open communication to avoid assumptions and misalignment.

2. Build trust by making commitments using plain language that both your team members and senior leadership can understand. By delivering on what you promised, you demonstrate reliability and accountability, which builds trust and strengthens your relationships.

3. Know your audience and choose your words carefully to suit their level of technical knowledge and understanding. Be specific and avoid unspecific words that may cause confusion or ambiguity. By adapting your language to your audience, you can ensure that your messages are effectively received and understood.

A team's culture is a direct reflection of its leader's contentiousness, leadership style, and values. In this article, we'll explore the concept of unit cohesion and how it applies to software teams.

Unit Cohesion in Software Teams

Unit cohesion is the degree to which a team functions as a single unit, rather than a collection of individuals. This is a quality that is supported by values such as collaboration, communication, and taking ownership of your work.

In software development, unit cohesion is critical. Teams that are cohesive work together more effectively, communicate more clearly, and are more productive.

By focusing on your team's culture, you can improve unit cohesion and maximize your team’s capabilities.

Culture is Reinforced

Culture is not something that organically occurs within a team. It's brought about through your encouragement and direction. As a technical leader, you have a pivotal role in shaping your team's culture. You can do this by setting expectations, providing feedback, and modeling the behavior yourself.

If you want to create a team culture that values collaboration, actively promote that behavior. To institute a culture of open communication, practice being communicative yourself. When you actively reinforce the positive behaviors you want to see, your team members have the opportunity to follow suit.

Some foundational values you may wish to adopt are working collaboratively, communicating openly, and taking ownership of your work. When your team members feel connected to each other and their work, they will be more motivated to work together to achieve success.

Culture is Practical

As a technical leader, it's easy to get caught up in vague value statements. You might say that you want your team to be collaborative or communicative, but what does that actually mean? Practical actions are more effective than vague value statements.

Invest some time in writing down the practical manifestations of the values you wish your team culture to exhibit, then model these behaviors. For example, to model collaboration, always make a point of helping your team members get unstuck before moving on to your own work. Or, to model communication, encourage your team to ask for help when they need it and emphasize that there are no dumb questions. Ask questions yourself to demonstrate. By providing practical examples, you give your team concrete actions they can take to help build a positive team culture.

You Are the Culture

Remember that as a leader, you are the primary driver of your team's culture. Your actions and example setting will have a direct impact on the behavior of your team members. When you lead by example, you create a culture that values the behaviors that lead to success.

By actively shaping and reinforcing positive behaviors, providing practical guidance, and leading by example, you can create a cohesive team that works together effectively and produces high-quality software. Remember that culture is not something that simply happens; it requires intentional effort and direction from leadership. As you work to develop your team's culture, focus on practical actions rather than vague value statements, and lead by example to set the tone for your team's behavior. By doing so, you will be able to improve unit cohesion and create a team that is not only successful in its work, but also enjoyable to be a part of. A positive team culture is not just a nice-to-have, but a critical component of any successful software development team.

Take it to work today:

1. Make it practical. Write down the values you'd like to see in your team culture and the practical behaviors that support them.

2. Make it personal. Communicate these behaviors to your team and emphasize your own intentions to model them. Ask your team to hold you accountable.

3. Be consistent. Model your values at every opportunity and continue to reinforce them as standards for your team.

Documentation plays a crucial role in helping new hires onboard more efficiently and effectively. When new team members join, they are often faced with a steep learning curve as they try to understand the company culture, coding and development processes, and infrastructure and architecture used by the team. Clear and comprehensive documentation can help reduce this learning curve and get new hires up to speed more quickly.

Here are some more ways in which documentation can help new hires onboard:

1. Provides a clear roadmap: Documentation provides a clear roadmap for new hires to follow, especially in their first two weeks. Outline the steps they need to take to get set up with the tools and processes that they will need to be productive. This roadmap can help new hires save time and feel more confident in their ability to navigate the onboarding process, and reduce their reliance on other team members for guidance, which also saves your team members' time.

2. Ensures consistency: Documentation helps ensure that everyone on the team is following the same processes and procedures, which can help avoid confusion and mistakes. This is particularly important for technical teams, where consistency in coding and development processes is critical to the success of the project.

3. Facilitates collaboration: Documentation can also help new hires understand how their work fits into the broader picture of the team's goals and objectives. This can facilitate collaboration and help new hires contribute more effectively to the team's work.

Clear and comprehensive documentation is essential for helping new hires onboard more efficiently and effectively. By providing a clear roadmap, ensuring consistency, and facilitating collaboration, documentation can help new hires feel more confident and productive, and help the team achieve its goals more effectively.

Embrace changes to your role

As a technical leader, your role will inevitably change as your team grows and evolves. While you may have started out as a hands-on technical contributor, you will need to shift your focus towards management and leadership as your team size scales up. Embracing this change and adapting to it can be challenging, but it is essential for the success of your team. It's an important opportunity to grow and develop new skills.

Delegation is crucial for effective team management, as it allows you to focus on broader-scope tasks while ensuring that your team is making progress on their work. Here are some practical tips for guiding team members in a hands-off fashion:

1. Set clear expectations: When delegating tasks, be sure to communicate clear expectations about what needs to be done, the time frame for completion, and any specific guidelines or requirements. This will help your team members understand what is expected of them and work more efficiently.

2. Provide support and resources: While you may not be directly involved in the task, it's important to provide support and resources to help your team members succeed. This could include providing access to tools or software, connecting them with knowledge holders or customers, or offering guidance and feedback as needed.

3. Trust your team: Delegation requires trust, so it's important to have confidence in your team members' abilities to handle the task at hand. Be available to answer questions and provide guidance, but avoid micromanaging or interfering in the process.

By delegating effectively, you'll be able to free up your time for management and leadership tasks, while your team members will have the opportunity to develop new skills and take on more responsibility.

Consider delegating leadership, too

As your team grows, it may become necessary to create specialized sub-teams to manage certain areas of responsibility. For example, you might create a team focused on infrastructure and architecture, another team focused on coding and development, and a third team focused on testing and quality assurance. By delegating leadership to people on these specialized teams, you can ensure that each area of responsibility is managed effectively, while also allowing yourself to focus on the bigger picture and ensuring you still have time to dedicate to one-on-one meetings.

Here are some tips for delegating leadership effectively:

1. Choose the right people: When delegating leadership, it's important to choose team members who have the right skills, experience, and motivation for the role. Look for team members who have demonstrated leadership skills in the past, or who have a strong interest in the area of responsibility you are delegating.

2. Set clear expectations: Make sure that you set clear expectations for the sub-team you are delegating leadership to. This should include goals, timelines, and metrics for success. Be sure to communicate these expectations clearly and regularly to ensure that everyone is on the same page.

3. Provide support and resources: Delegating leadership doesn't mean abandoning your team members. Continue to meet frequently with sub-teams to learn how they're doing firsthand, and whether they need additional guidance or resources.

Take it to work today:

1. Invest in documentation: Writing comprehensive internal documentation is crucial for helping new hires onboard more efficiently and effectively. By providing a clear roadmap for new hires to follow, you can save time, ensure consistency, and facilitate collaboration.

2. Embrace changes to your role: Recognize that as your team grows and evolves, your role will need to shift towards management and leadership. Embrace this change and adapt to it to ensure the success of your team.

3. Consider delegating leadership: As your team grows, consider creating specialized sub-teams to manage certain areas of responsibility. Delegating leadership to these sub-teams can help you manage your workload more effectively, and free up time for other important tasks. Be sure to choose the right people, set clear expectations, and provide support and resources for your sub-teams to be successful.

As a technical leader, scaling up a high performing team requires you to invest in comprehensive documentation, embrace changes to your role, and consider delegating leadership to specialized sub-teams. By investing in documentation, you can help new hires onboard more efficiently and ensure consistency in your team's processes. By adapting to your changing role, you can ensure that your team is set up for success as it grows and evolves. And by delegating leadership to specialized sub-teams, you can free up time for important tasks and manage your workload more effectively. These three tenants can help ensure that your team operates more efficiently and effectively as it grows and develops, and continues to achieve long-term success.

In this edition, we'll discuss some best practices that you can adopt to streamline your code review process and make it more productive.

You should not be doing code reviews

Hot take alert: you, as a technical leader, should not be doing code reviews yourself. Or only very rarely. Why?

You don't scale.

As a technical leader, your role is to guide your team, build the roadmap, and ensure the overall quality of the code. Code reviews are a critical part of the development process, but they can also be time-consuming, especially if you have a large team. Instead, you should delegate the task of code reviews to your team members, who will benefit from the experience of examining and learning from each other's code. This can help develop a culture of collaboration.

This doesn't mean that you should completely check out of the code review process. Your team needs you to provide context and direction from a big-picture, product-focused perspective. As a technical leader, you are the liaison for other parts of the broader organization, and it's your responsibility to bring information to the team that will help them understand the larger picture. You have the strategic vision and technical expertise to provide guidance on how the code fits into the product roadmap and the business goals.

Your team members may be focused on the nitty-gritty details of the code, but you have the perspective to see the bigger picture. By providing context and direction, you can help your team make informed decisions about the code they are reviewing.

Invest your time upfront

Invest your time upfront in creating clear guidelines and expectations for the code review process. As a technical leader, it's your responsibility to set the tone for how code reviews should be conducted. Create a code review checklist that covers the most critical aspects of the code, such as coding standards, test coverage, and performance. Establish clear guidelines for how to provide feedback and ensure that everyone is on the same page.

Your team members will be able to conduct code reviews effectively and efficiently, freeing up your time to focus on providing context and direction. You can review the feedback provided by your team members and ensure that they are following the established guidelines. By doing so, you can ensure that your team is equipped to conduct effective code reviews, and that the code produced meets the highest quality standards and aligns with the broader goals of the organization.

Don't check out completely

Delegating code reviews to your team members doesn't mean that you should git checkout completely (sorry, couldn't resist). As a technical leader, it's important to stay involved in the process and provide guidance and support when needed.

Be available to answer questions and provide feedback on the overall quality of the code and how well it meets the business goals. Review the feedback provided by your team members and ensure that they are following the established guidelines. Provide guidance on how to address any issues that have been identified, and offer suggestions for improvement where necessary.

By staying involved, you can ensure that your team is conducting effective code reviews and that the code produced meets the highest quality standards.

Take it to work today:

1. Delegate code reviews to team members: As a technical leader, your role is to guide your team, build the roadmap, and ensure the overall quality of the code. Code reviews are a critical part of the development process, but they can also be time-consuming, especially if you have a large team. Delegating the task of code reviews to your team members will help develop a culture of collaboration.

2. Invest time upfront in creating clear guidelines: To ensure that code reviews are conducted effectively, invest time upfront in creating clear guidelines and expectations. Create a code review checklist that covers critical aspects of the code, such as coding standards, test coverage, and performance. Establish clear guidelines for providing feedback and ensure that everyone is on the same page.

3. Stay involved in the process: Your team needs you to provide context and direction from a big-picture, product-focused perspective. Review the feedback provided by your team members and ensure that they are following the established guidelines. By staying involved, you can ensure that your team produces high-quality code that successfully achieves the broader business goals of the organization.

That's all for this edition. Remember, by delegating the task of code reviews to your team members, investing your time upfront, and staying involved, you can create a culture of collaboration and produce high-quality code while not becoming your team's bottleneck.

Expect to learn something new every time

Expecting to learn something new every time is a powerful mindset for embracing iteration in software development. No matter how experienced you are, there is always something to learn, new insights, and new opportunities for growth to be had. Here are some practical examples of how this mindset can be applied.

1. Direct interaction with users. The chance to interact with the people who use your product is a golden opportunity to learn something new. By observing how users interact with your product, you can gain valuable insights into what works and what doesn't. You'll likely discover users trying to do things in a way you've never conceived of, or applying your technology to situations you haven't considered.

2. Retrospectives. Retrospectives are a valuable tool for reflecting on the development process and identifying opportunities for improvement. Every time you conduct a retrospective, you have the opportunity to learn something new about how your team is implementing processes and where those processes might be improved. By approaching retrospectives with the expectation that you will learn something new every time, you can create a culture of continuous improvement and iteration.

3. Collaborating with your team. Working alongside your team members is an essential part of the development process. By approaching collaboration with the expectation that you will learn something new every time, you can create a culture of knowledge sharing and continuous learning. You may discover a new perspective on a problem or learn a new way of communicating with your team members. These discoveries may not be so easily made if you're always in "boss mode."

Even experienced developers should approach code reviews, user testing, retrospectives, learning new technologies, and collaboration with the expectation of learning something new every time.

Prepare for a certain amount of failure

Failure is an essential part of the iteration process. It's how we learn, grow, and adapt. But it can be hard to embrace failure, especially if a company culture values perfection. Setting proper expectations for outcomes can help to take the pressure off -- you don't need to get it completely right the first time around.

In our last edition, we discussed addressing different issues after-the-fact with senior management. It can also be challenging to set the right expectations upfront with senior management and your team. Here are some concrete suggestions for how to do so effectively:

1. Communicate the value of experimentation and learning to your team members and senior management. Explain how iteration can lead to better products, more efficient workflows, and more satisfied customers. Provide examples of successful iterations that your team has done in the past, what you learned, and how you used it to make improvements. This will help to make clear the importance of embracing failure and taking risks.

2. Set clear goals and objectives. This can help to take the pressure off and allow for experimentation. Define what success looks like for each iteration, and communicate this to your team members and senior management. Be specific about what you want to achieve, but also leave room for experimentation and learning.

3. Use data to measure success. Data can be a powerful tool for measuring how effective an iteration turned out to be. Define success metrics, or key performance indicators (KPIs), and communicate these to your team members and senior management. By using data to measure success, you can take the emotion out of failure and focus on what's working and what's not.

4. Continuously communicate and adjust expectations. As you learn and grow from each iteration, present your findings to your team members and senior management. Adjust your goals and objectives as needed to reflect what you've learned. By continuously communicating and adjusting expectations, you can create a culture of iteration that is responsive and adaptive.

Setting proper expectations for outcomes is critical for embracing iteration successfully. By communicating the value of experimentation and learning, setting clear goals and objectives, using data to measure success, and continuously communicating and adjusting expectations, you can create a culture of iteration that leads to better products, more efficient workflows, and more satisfied customers.

Leave your team room to experiment

Iteration requires experimentation. It requires trying new things, taking risks, and exploring new ideas. As a technical leader, it's your job to create an environment that encourages experimentation. Here are a few things you might try:

1. Continuous Integration/Continuous Deployment (CI/CD). Can you make your team more efficient through automation? Teams can experiment with different CI/CD tools and workflows, such as Sophos Factory, Jenkins, or GitHub Actions, and fine-tune their processes to optimize for speed and reliability.

2. Alternative development processes. Would your team lend itself to a particular way of working that isn't currently being served? You can experiment with different flavors of software development methodologies, such as Scrum, Kanban, or Extreme Programming, and adjust your processes to fit your unique needs.

3. Learning new technologies. Teams can experiment purposefully with new technologies by setting up a "hackathon" or a "tech day" where team members can explore new tools, frameworks, and libraries. This not only allows teams to learn new skills but can also spark creativity and innovation.

Encourage your team to take risks, try new things, and learn from their mistakes. Provide the support and resources they need to experiment safely and effectively. And most importantly, celebrate their successes, no matter how small.

Take it to work today:

1. Expect to learn something new every time: Encourage a culture of continuous learning and improvement by approaching code reviews, user testing, retrospectives, learning new technologies, and collaboration with the expectation that you will learn something new every time.

2. Prepare for a certain amount of failure: Set clear goals and objectives, use data to measure success, and continuously communicate and adjust expectations to create a culture of iteration that embraces failure as an opportunity for learning and growth.

3. Leave your team room to experiment: Communicate the value of experimentation and learning, set clear goals and objectives, use data to measure success, celebrate successes and failures, and continuously communicate and adjust expectations to create an environment that encourages experimentation and learning.

Embracing iteration is not always easy, but it is essential to success in software development. By expecting to learn something new every time, preparing for a certain amount of failure, and leaving your team room to experiment, you can create a culture of iteration that will lead to more efficient workflows, better products, and more satisfied customers. So go ahead, embrace iteration -- the results may surprise you!

When your team didn’t deliver

It can be frustrating and embarrassing when your team doesn’t deliver on a project or goal. But as the leader, it’s important to take ownership of the situation and not pass the blame onto your team. Instead, focus on what you can personally do to improve the situation.

First, take a step back and assess. What specifically went wrong? Was there a breakdown in communication of expectations? Did your team lack the necessary resources, research, or support? Consider holding a postmortem with your team to ensure you hear of any contributing factors first-hand.

Once you have a clear understanding of what happened, you can start to develop a plan to address the issue. To aid your thinking, consider making a two-column list. Note the specific problem your team encountered in the first column, for example, “We lacked a clear definition of the product to be delivered.” In the second column, propose a remedy; for example, “Write down and agree on product requirements before work begins.”

With this list in hand, answering to senior management could not be more straightforward. Like you, they are leaders with responsibilities for their teams. Like you, they want to know what happened and how it’s going to be improved upon in the future.

Communicate your list openly and honestly with senior management. Take responsibility for the outcome as your team’s leader and clearly and specifically explain the steps you’re taking to ensure that future outcomes improve. Show what you’ve to learned from the situation and that you’re committed to the future success of the broader organization.

Once you’ve discussed your remedies with senior management and incorporated any suggestions they may have, put these into practice with your team that very same day. In the product requirements example, don’t hesitate to take the time to ensure that all current work underway has a list of requirements to meet your new standard. Continue to reinforce your standards as the team adapts to the new process.

When there’s too much on your plate

As a technical leader, it’s easy to feel overwhelmed and like you have too much on your plate. Instead of letting responsibilities pile up to the point of affecting your work-life balance (startup leaders, I see you!), take a step back and focus on what you can control.

First, prioritize your tasks and responsibilities. If you have more than one “priority,” you’re doing it wrong. What is the most important thing your team needs to accomplish right now? What items must necessarily happen later? Do some items block others? Sorting through what feels like a bucket of backlog soup may seem like a daunting task, but it’s one that pays back the time investment tenfold. Dedicate a day, if necessary, to ensure you get priorities straightened out for your team.

Next, examine what you do in a day. Ask yourself if there’s anything you do that a team member could do instead, and be honest with yourself about the answers. You may feel hesitant to give more work to already busy team members, but this is a flawed perspective.

If you’re currently doing work that team members can help with – such as code reviews or requirements gathering – delegate these tasks to your team members. Don’t, however, simply pile it on top of the work they’re already doing (that didn’t work for you, did it?) but reprioritize their tasks as necessary to ensure you stay within their individual capacity. Don’t hesitate to ask someone to pause work on a bug fix in order to spend time reviewing code for a more important bug or feature. Communicating relative importance clearly and objectively can help your team to understand the order of operations and to feel like they’re in the loop when it comes to the bigger picture. By delegating more tasks, you’ll be able to free up some of your time and focus on the things that only you can do.

If, after prioritizing, it becomes clear that there’s too much expected from your team in a given time, communicate this to senior management. Ensure you state clearly what your team can accomplish within a certain time given the people and resources you currently have. If necessary, ask them to re-prioritize what they’d like your team to get done, so you can focus on delivering quality work for each desired goal.

Emphasizing your success

When it comes to answering to senior management, it’s important to emphasize your successes and accomplishments. It’s equally important to do so in a way that demonstrates extreme ownership and leadership.

First, be specific about what you’ve accomplished. Provide concrete examples and data to back up your claims. Show senior management that you’re able to achieve tangible results. Saying, “We did a great job making feature X faster,” is not as effective as saying, “We delivered feature X in two weeks and our customers are seeing a 200% improvement in response time.” For maximum impact, capture facts like this in charts and graphs. People with little time love visuals.

Next, give credit where credit is due. Acknowledge the contributions of your team members and colleagues. If someone made a particularly significant contribution, mention this specifically. Demonstrate that you’re in touch with your team and invested in each person’s individual success. Good leaders care more for the success of their team than for personal glory.

Finally, be humble and willing to learn. Even if you’ve achieved great success, there’s always room for improvement. Be open to feedback and use it to continue growing and developing as a leader.

Take it to work today:

1. If your team didn’t deliver, assess what went wrong and make a plan for future success. Take ownership of the situation and communicate the specifics of how you plan to succeed next time. Receive any feedback and suggestions in good faith.

2. When there’s too much on your plate, prioritize and delegate. If necessary, communicate your team’s capacity to senior management and ask them to re-prioritize your team’s goals so that the most important items are addressed first.

3. When highlighting your team’s successes, be specific. Offer facts as numbers or charts and graphs, and mention any specific team members whose contribution stood out. Emphasize your team instead of too-easily accepting personal glory.

Answering to senior management requires extreme ownership and leadership. Whether your team didn’t deliver, you have too much on your plate, or you want to emphasize your success, approach each situation with honesty, humility, and a willingness to learn and grow. By doing so, you’ll be able to build trust with senior management and demonstrate your value as a leader.

The best leaders are helpers

As technical leaders in software development, it's easy to get caught up in the day-to-day tasks of managing teams, setting deadlines, and making sure projects are on track. But as a servant leader, your focus should be on helping your team achieve their goals.

This means taking a step back and looking at how you can best support your team. Do they need more resources, better communication, or more time to complete their tasks? Whatever it is, your job is to make sure they have what they need to succeed.

Facilitate greatness, or get out of the way

Another key tenet of servant leadership is facilitating greatness. As a leader, your job is not to micromanage your team, but to create an environment where they can thrive.

This means trusting your team members to do their jobs and empowering them to make decisions. It also means removing any obstacles that might be standing in their way. This means taking a proactive approach to identifying and addressing issues before they become bigger problems. If your team can't work, you can't work.

Here are some concrete examples of how you can remove obstacles for your team:

1. Providing resources: Whether it's tools, software, or hardware, make sure your team has everything they need to do their jobs effectively. This might mean investing in new equipment or software, or simply making sure they have access to the resources they need to get their work done. If you don't know what your team needs, ask! They'll tell you.

2. Clearing roadblocks: Sometimes, your team might hit a roadblock that they can't solve on their own. As a servant leader, it's your job to step in and help clear the way. This might mean helping to deep-dive code, working with other teams or departments to resolve issues, or advocating for your team's needs with senior management.

3. Encouraging communication: Communication is key to any successful project, but it's especially important in software development. As a leader, you should encourage open and honest communication between team members and ensure that everyone is on the same page.

4. Removing distractions: Software development can be a demanding and stressful field, so it's important to make sure your team members have the space and time they need to focus on their work. This might mean reducing unnecessary meetings or distractions, or taking busy-work type tasks off their hands.

5. Addressing conflicts: Conflicts are bound to happen in any team, but it's important to address them quickly and decisively. As a leader, you should be proactive about identifying conflicts and working with your team to resolve them in a positive and productive way.

Your team gets all the glory

Finally, it's important to remember that as a servant leader, your team gets all the glory. Your job is not to take credit for their successes, but to shine a light on their achievements and help them celebrate their wins.

This means recognizing and rewarding their hard work, as well as creating a culture of appreciation and gratitude. When you are recognized for an achievement, put the credit where it's really due: on your team. When your team feels valued and appreciated, they'll be motivated to keep pushing themselves to do even better.

Take it to work today:

1. Be a helper: Make it a priority to help your team members achieve their goals. This might mean providing them with the resources they need, offering support and guidance, or simply being available to answer questions and provide feedback.

2. Facilitate greatness: Empower your team members to do their best work by creating an environment where they can thrive. This might mean removing obstacles, encouraging communication, and trusting your team to make decisions.

3. Give your team the glory: Show your team members that you value their contributions by giving them the credit and recognizing their hard work. When your team members feel appreciated, they'll be more motivated to continue doing their best work.

As a technical leader in software development, it's critical to prioritize servant leadership. The success of your team is directly tied to your ability to serve and support them. By focusing on helping your team achieve their goals, removing obstacles, and fostering a culture of appreciation, you'll not only be a better leader, but you'll also empower your team to do their best work. Remember, a team is only as successful as its leader is at serving them. So lead by serving, and watch your team achieve greatness!

It's more needed than you know

As a leader, it's easy to fall into the trap of believing that you need to do everything yourself to ensure it's done correctly. However, this is simply not feasible or sustainable. Delegating tasks not only frees up your time to focus on higher-level responsibilities, but also helps to develop the skills and confidence of your team members.

Practice recognizing the tasks you don't have the time or resources to accomplish yourself. Time blocking is one especially effective way to do this: if you schedule your day by the tasks you want to complete, it can help make it apparent when you're putting too much on your plate. Delegate the items that aren't critical for you to do.

By empowering your team to take on new challenges and responsibilities, you're investing in their growth and the future success of your organization.

Don't worry, you're not a dictator

Delegating tasks can be a daunting prospect, especially if you're used to doing everything yourself. This is a common state of mind for many technical leaders, especially those who come from a background of bootstrapping startups.

It's important to remember that delegation is not about micromanaging or being a dictator. Instead, it's about trusting your team members to do their best work and providing them with the necessary support and resources to succeed. Actually, your team wants (and needs!) you to tell them what to do. Clear expectations and guidance ensure that everyone is on the same page and can work towards a common goal.

Be clear, concise, and courteous

When delegating tasks, it's crucial to be clear about what you want to be done, why it needs to be done, and when it needs to be completed.

This not only helps to ensure that everyone is on the same page, but also allows your team members to plan and prioritize their work effectively.

Remember, delegation is a two-way street, and communication is key. Listen to what your team members need from you, and provide direction in a clear, concise, and courteous way. This helps to build trust and foster positive working relationships.

Take it to work today:

1. Delegating tasks frees up your time, but also helps to develop the skills and confidence of your team members. Practice time-blocking to determine which tasks to delegate.

2. Trust your team members to take on new challenges and responsibilities. By doing so, you're investing in their growth and the future success of your organization.

3. Remember to communicate clearly, be respectful, and provide the necessary support and resources to help your team succeed.

Happy delegating!

That's why it's important to run meetings that are focused, efficient, and productive. In this edition, we'll explore how to run a meeting that maximizes the value of everyone's time.

Half the work happens before the meeting starts

As a technical leader, you're responsible for making meetings useful and productive. One part of that is making sure everyone knows what to expect before the meeting even starts.

Create a clear agenda that outlines the purpose of the meeting, the topics to be discussed, and the desired outcomes. Share the agenda with your team in advance and encourage them to come prepared with their own ideas and questions. This allows you to spend valuable synchronous meeting time discussing your team members' input and coming to agreements.

By setting expectations upfront, you'll help ensure that the meeting is productive and that everyone is engaged and focused.

Curb the conversation

During the meeting, it's important to keep the conversation on track. As the technical leader, it's up to you to guide the conversation and make sure that everyone has an opportunity to share their thoughts and ideas.

If someone raises a new topic that's not on the agenda, acknowledge it and suggest that it be addressed at a future meeting. If someone is monopolizing the conversation, politely interrupt and encourage others to speak up.

By keeping the conversation focused and efficient, you'll ensure that the meeting stays on track and that everyone's time is respected.

Make it concrete

At the end of the meeting, it's important to summarize the key points and action items. Ensure that everyone knows what their next steps are and who's responsible for what.

Follow up after the meeting with a summary of the action items and their due dates. Just like where you store your docs, share this summary in a place it will actually be seen and reviewed, instead of putting it out of sight and out of mind in the dusty corners of your team's wiki pages. This may mean linking it in your chat channel, sending it via email, or even presenting it at the next day's stand up meeting. This will help ensure that everyone stays on track and that progress is being made.

Take it to work today:

1. Before the meeting: Set a clear agenda and communicate it to your team members in advance. Encourage team members to come prepared with their own ideas and questions.

2. During the meeting: Keep the conversation focused and efficient. Write down new topics and suggest they be addressed at a future meeting. Politely interrupt if someone is monopolizing the conversation.

3. After the meeting: Summarize the key points and action items. Make sure everyone knows what their next steps are and follow up with a summary of the action items and their due dates.

Running a successful meeting is a key skill for any technical leader. By setting expectations upfront, guiding the conversation, and summarizing action items, you can maximize the value of everyone's time and keep projects moving forward.

• How to have effective, time-saving meetings

• How to delegate work without feeling like a dictator

• How to set up productive code reviews

• Getting ready to scale up and grow your team

The first of these arrives this Monday. To make sure you get the full article in your inbox, switch to a paid subscription today and lock in 20% off forever. You'll get a weekly short-and-sweet article with critical technical leadership skills you can put into practice that day.

Get 20% off forever

Paid subscribers can interact with the broader TTLD community and comment on posts to let me know the topics they'd like to see me cover next. Join us today and become part of the TTLD community!

See you next week,

Victoria

More often than not, you may not realize that instead of helping, you're getting in the way. It's time to step back.

Here's how you can build awareness of when to help out and avoid getting pulled into those technical rabbit holes when it isn't helpful.

Timing is Everything

You won't be the first or last engineer to hijack a meeting by getting into the deep technical issues of a problem — but as a leader, getting lost in the weeds is a bad look.

Ensure you go into each meeting with a clear idea of what you'd like its outcome to be. Write it down in plain view for the rest of the team. Not only does this help you stay on track and keep your team on topic, but it serves as an objective measure of success in terms of how the meeting went.

When meetings with a specific intent inevitably start to wander off-topic into technical problem-solving, politely keep your team on track. Say, "This is a really interesting idea! Let's set aside some dedicated time to discuss it further." Ensure you schedule that time promptly so your team knows you'll stick to your word.

Standups and other progress-update meetings are particularly susceptible to getting derailed by overenthusiastic technical leaders. When team members share a problem they've encountered, it's tempting to dive into specific questions and offer suggestions and guidance, even as everyone else in the meeting waits patiently for you to finish. Instead, make a note of your thoughts and follow up directly after the meeting with something like, "I was thinking further on the issue you brought up at standup — have you tried..." That way, you can be curious and helpful while still respecting everyone's time.

Perfect Your Handover

Especially when technical leaders are technical seniors as well, it can be tempting to help out more junior team members by essentially doing their work for them.

I've seen ill-informed leaders do everything from writing instructional epics on exactly how to approach and resolve issues, to driving hours-long pair programming sessions that result in a finished PR. This type of "help" doesn't respect your own time (you don't scale) or your team member's ability to learn and problem-solve on their own. This isn't leadership, it's hand-holding.

Should you refuse to help altogether? Of course not, but balance is paramount. If you have knowledge or an idea that you feel is likely to lead to a solution, pass it on. Instead of creating a detailed map of start to finish, however, think of it more like showing the way to the trailhead. Explain your context, thought process, and how to find more information to whomever's working on the issue — and leave it at that. By handing over a warm trail, you're able to provide direction while still leaving the path open for learning, exploration, and, potentially, an even better solution. Let your team member know they can always ask you for further clarification or ideas — just not full-fledged solutions. That's their job.

Enlist Your Team

If someone's struggling with a technical issue, it's not your sole responsibility to resolve it (again, you don't scale). It is, however, your responsibility to see that they get the help they need.

You can do this by having a clear idea of priorities and reallocating your team's work when necessary. If someone else has expertise that could help with a higher priority issue, ask them to help out. You can even set up the call yourself, stick around to explain the context and share your ideas, and ensure everyone is on the same page. After that, leave them to it. Trusting your team to help each other out and find solutions is a mark of a mature technical leader.

Take it to work today:

1. Stay on topic. Be a respectful leader by keeping meetings fixed to their purpose and not getting lost in ad-hoc technical problem-solving.

2. Learn to hand over a warm trail to a potential solution, instead of hijacking issues from those assigned to solve them.

3. Trust your team to help each other out, and reallocate work time to honor overall priorities.

Well-run tech teams can build great software, but rarely does this happen on the first try. Proof-of-concepts (POCs), prototypes, and even early releases of applications often prioritize speed over maintainability. They’re filled with learning opportunities — decisions made with less time or knowledge than your team has now, and ways of doing things that you could now do better, if you started over today.

Even more mature software and applications have lots of room to improve. Ask a developer on any team, and they’ll likely be able to point out some part of their product that could benefit from being made more maintainable, or some dead code that needs cleaning up, if only they had the time.

At every stage of a software product, there arises an opportunity to take things away, resulting in tangible improvements to the code base — and consequently improving the product, along with developers’ experiences. Here’s the case for throwing things out.

Call it a First Draft

Software is a competitive industry, and many teams feel pressured to produce high-fidelity, feature-rich applications, even for POCs. Few teams follow a more rigid prototyping process, and may think it a waste of time and developer effort to “redo” an initial version. On the contrary, creating and throwing out an initial prototype can save untold development hours spent on technical debt in the future.

Prototypes, even first versions, are rarely created with long-term maintainability in mind. Often, such a goal would be impossible — the early development process inherently allows developers to explore, answer questions, and research better ways of building. The discoveries that enable long-term maintainability occur while this first version is being built. You can’t put the cart before the horse.

The next time your team creates a POC or v1.0.0, have a retrospective meeting. Ask developers, “If you could start over, what would you build differently? If someone new joined our team, what part of the product would be hardest for them to understand?” While the answers may not necessitate a scorched-earth rebuild, now is the time to be open to throwing out major parts of the codebase that threaten tech debt and future problems with maintainability. If it makes sense to rebuild, rebuild sooner than later. It’s an investment in the future of your team.

Your Customer Tells You What You’re Selling

Customer feedback is a vital component of a successful software product. The sooner you can get it, and the more you can get, the better.

If possible, show early versions of your software to customers. Take advantage of proper user interface evaluations with real users if you have the resources, and if not, at least attempt to garner user input through reviews, surveys, and forums or social media. Young products may discover that the parts or features the customers like best or want most aren’t the next items in your roadmap. Now is the most opportune time to throw out those initial plans and listen to your users.

Begrudgingly admitting later on that you should have pivoted sooner risks producing a sub-par product. You’ll need to look for ways to bolt-on the functionality that customers desire, possibly creating more tech debt in the process, instead of having a more purpose-built application overall.

Delete Dead Code

As software matures and applications grow, teams iterate to incrementally improve parts of the code base. Very often, code that is no longer used remains in the code base, sometimes relocated into an “old” directory, or worse yet, left alone without so much more than a comment to indicate its deprecation.

Dead code bloats your code base, which for growing software products, can translate to more time spent on I/O — everywhere from developers that pull code to their local machines, to CI/CD automation that clones your code base multiple times per day in order to run. If you use hosted cloud services, that extra unused code could be translating into higher costs for storage, I/O, and memory use.

Dead code also confuses developers. Out-of-use files, similar in name or appearance to in-use ones, easily trip up your team members when snippets appear in search tools or an effort to find-and-replace. New team members aren’t prevented from reading these files either, and an eager eye may miss the one-line comment that denotes a file as deprecated. Keeping dead code around costs time, money, and cognitive effort — for no good reason at all.

If you use version control (and if you don’t, we’ve got other things to talk about first…) there’s no excuse for leaving dead code hanging about. Delete unused files, configurations, and outdated docs to save resources and prevent confusion.

Take it to work today:

1. Be prepared to throw out early versions. Lessons learned from early development are valuable. You can use them to their full potential by being open to doing things differently at an early stage.

2. Get feedback to find out what you’re selling. Listen to customers and what they want, taking advantage of proper product evaluations if possible. Let this drive your roadmap, and toss items that customers don’t highly value.

3. Delete dead code. Avoid unnecessary cost, cognitive effort, and wasted time by taking a strict stance against keeping unused code around.

Increased productivity usually coincides with the need to implement more structured processes. Structure benefits your team by clarifying and focusing work efforts, communicating expectations to management and stakeholders, and building trust between the team and its leadership. The approach this edition will recommend can apply to any process, but is particularly useful when choosing a software development workflow.

Many options for development workflows abound. The naive approach would be to read about all of them, choose the one you like best, then foist it on your team. While this approach will not certainly result in failure, it does certainly fail to take advantage of the knowledge and experience of the talented team you've built up thus far.

Structure is best implemented from the bottom-up. As a leader, it does not usually serve you well to find a box that sounds good and then try to put your team into it. Instead, think of structure like a scaffold that you build around your team, so that it supports them. Here’s how.

Implementing a Software Development Workflow

Following a formal process that you've created can help to establish trust between you and your team. It creates opportunities for you to make decisions and then follow through, sticking to your word. Part of what helps to build that trust is implementing these structured processes together — as a team.

Just as we discussed all the way back in 002, explain, don't dictate. Start by holding a meeting with your team with the intended outcome of deciding on a process to try out. Discuss the goals of implementing a more structured workflow process with your team. You may wish to more easily track work, to have a regular release schedule, or to better communicate expectations to customers. Ensuring your team understands overall goals will help to build engagement and trust.

Different members of your team may have opinions about specific workflows that they'd like to share. Perhaps there's an aspect of Scrum that someone really enjoys. Someone may feel that Waterfall is best suited to your product. Someone else may dislike Kanban for particular reasons. It's important to become familiar with how your team perceives different options and to understand the reasoning behind those perceptions. You'll likely find you learn something new.

That said, avoid going down rabbit holes of debating which established process is the right choice for your team. The goal of the meeting is not to decide to, for example, "do Scrum," but to determine the individual stages of the process that the team believes would be beneficial. Always manage the conversation in terms of coming to conclusions — not be-all, end-all decisions, just the ideas you'd like to try out in an initial run.

The outcome of a successful meeting may look like a simple list of phases or point-form notes. Ensure you capture what each phase is going to be, the expected outcomes of each one, and how long it should last. For example:

1. Planning (1 week): decide the specific tasks we're going to work on this cycle.

2. Research (2 days): create an initial plan of attack, off-line prototypes, and determine possible roadblocks.

3. Build (2 weeks): write the code, test, iterate.

4. Test and Deploy (3 days): run any integration tests, deploy, and communicate to stakeholders.

At the end of your meeting, you may have a process that matches up quite closely with an established software development workflow, but likely with small differences that will make all the difference for your team.

Try It Once

After deciding on a process to try, stick to it for at least one cycle. Remember that this is your first iteration — learn from it! If during the cycle it becomes apparent that changing the time frame of any phase would be beneficial, implement these changes in the second run through. Avoid making mid-cycle changes to the process: this creates a sense of instability and can degrade trust.

At some point in the process, it may be discovered that the full scope of the work you set out to do cannot be accomplished during the given time. In these situations, trim down the scope in order to ship the work that can be completed on time. Use feature flags to gate any partially implemented features. Trim scope instead of letting the cycle length creep — you'll get better at planning and estimation in future cycles.

Iterate

After each cycle, discuss what worked and what didn't work with your team. Decide on any changes to try for the next cycle -- you can experiment with cycle length, phase length, or add some periods of free, unstructured time between cycles for tackling bugs or tech debt. Iteratively developing your software development process makes it maximally useful for your unique team.

Take it to work today:

1. Start with a scaffold. Build an initial "first try" process around your team, with your team.

2. Try it out. Stick to your plan for at least one round. Determine what works and what didn't.

3. Iterate. Experiment with changes in the next cycle to create a process that uniquely benefits your team.

Most leaders understand the importance of documenting knowledge and processes, but too often de-prioritize writing things down in favor of writing more code. This is a short-sighted and misguided approach. It consistently results in large tech debt, poor knowledge transfer, and the team's reliance on one person to have all the answers (usually you).

That said, simply writing down more things isn't the answer either. It's important to know what to write down, who to write it for, and perhaps most importantly, where to put it. The good news is, as long as you remain consistent, these habits are quick to instill in a team and instantly beneficial to everyone — especially new hires.

Better, consistent documentation for my teams meant less time spent hunting for information and more time spent producing — which made for both happier developers and development leaders alike.

Let's see how.

What to Write Down

Your team makes decisions and solidifies processes all day long. Ensure this information doesn't get lost in the ephemera of last month's Slack chats and Zoom calls.

Processes

If you need to do anything more than twice, write down how to do it.

You need not create an essay for a three-step process. Use bullet points or numbered steps, with a sentence or two of context. Imagine that you've taken the day off and that someone without the knowledge you have in your head needs to find these instructions and execute this process. Not only will this be beneficial if you do actually happen to be out of office one day, but you yourself will likely benefit from the step-by-step reminder, especially after returning from a vacation.

For complex processes or technical documentation, provide more context. Start with the big picture, e.g., "This document describes how to deploy a new version." What's obvious to you may not be so clear to other team members and new hires.

When describing each step, more than simply writing down the terminal command to run, leave a few sentences describing what it's supposed to do and what other pieces it affects. Based just on what you've written, someone else on the team who's new to the process should be able to start troubleshooting it.

Decisions

Slack is not documentation. When looking for a decision that was made last month, don't subject yourself to keyword-searching dozens of irrelevant threads and messages. When decisions are made, make them easy to reference again by writing them down somewhere more permanent (more on that below).

Not only will this make information easier to find, but it solidifies shared team knowledge for anyone who was out on leave or who happened to miss the conversation or meeting. Giving your team one place to reference important decisions ensures everyone is on the same page.

Who to Write It For

Make no assumptions about your reader. Everyone on your team has knowledge and expertise — but not the same knowledge and expertise as everyone else.

Every piece of documentation you or your team creates should be written as if it was going to be relied upon by a brand new hire — because it will be. For example, while you don't need to go so far as to explain coding fundamentals in your style document, note and link to references for any particular code styles and linting tools your team uses. When creating a README for an internal repository, write it with the same diligence as you would if it were a public repository.

If you're unsure whether something has a sufficient level of detail — test it out! Have a team member who's unfamiliar with the subject read it over and ask any questions they may still have. If those questions seem pertinent, fill in the blanks in your documentation.

Where to Put It

There are a myriad of tools your team uses to communicate. For this question, the answer is highly personal to how your team works — but there's only one right answer.

Put documentation where your team will read it.

A strategy that has worked well for my teams in the past is to keep documentation as close as possible to its subject. Product documentation and technical guides live in the code repository. Team-related docs live next to where the team makes plans, such as in Notion, Confluence, or Basecamp; these include process documentation, notes on code style and tooling, and onboarding checklists for new hires.

Enlist Your Team

As a leader, it's your responsibility to champion the creation and upkeep of documentation. That doesn't mean you write it all yourself.

Make a point of asking for docs whenever team members introduce new code or propose a great new idea. Ensure you ask for docs to be updated when changes are made to the codebase or processes. Whenever your team or other leaders make decisions, say, "This sounds great! Let's make sure to document this in Notion so we can act on it as a team."

Review documentation with the same diligence as code — they're both executable instructions, after all.

Remaining consistent with your team helps instill the habit in everyone.

Take it to work today:

1. Write documentation for processes and decisions such that a new team member can understand and act on them. If it’s not documented, it doesn’t exist.

2. Put documentation where your team will read it. Keep docs close to the relevant work.

3. Instill the habit of creating and updating useful documentation in your team. Lead by example.

As your team scales up, you don’t. If you find yourself with a backlog of questions to answer and PRs to approve, the bottleneck might be you. Here’s how to get out of your own way and let your team succeed.

The PR Bottleneck

One of my favorite team leadership successes came from implementing a straightforward change. Before the change, only one or two leaders were reviewing and approving all pull requests for a team of ten developers. As you can imagine, PRs stacked up quickly. Despite the reassurance of automated tests, the constant overload of reviewing code lead to fatigue and a diminishing quality of reviews from team leaders.

After the change, all PRs were reviewed and approved by one or more team members. Leaders needed only to take a brief look before confidently hitting the merge button.

The result? Backlog cleared. Happier leaders. Increased collaboration, sense of team unity, and knowledge sharing overall. Happier, more confident, and more knowledgeable individual contributors.

The example highlights an important but counterintuitive principle for leaders: strive to make yourself less necessary. Here's why it works.

Trusting Your Team

It’s common for small software teams to rely on their leader or managers to review and approve PRs. It’s a practice propagated by both teammates and team leaders: individual contributors are wary of taking responsibility for a review that misses a bug or security issue, and team leaders don’t trust that developers will consider all the possible pitfalls of a less-than-careful approval.

Both these perspectives are fear-based and wrong.

Individual contributors are often far better at reviewing pull requests than their managers. They’re closer to the code and appreciate a level of detail that their leaders don’t see (without in-depth digging and the consequent time investment). It’s true that code is better reviewed by a fresh pair of eyes - which is why I recommended that all individual contributors only review PRs that are not their own.

When contributors review each other’s code, they also engage in conversations that advance the level of knowledge sharing and collaboration across the team. For the team in my example above, this increase in collaboration lead to a much greater sense of unity. Team members developed an appreciation of each others' talents or specific area of expertise - as a result, they knew who to go to for help in the future for any particular issue. With that in mind, not having contributors perform code reviews is a huge missed opportunity.

Leaders who feel reluctant to turn over the task of reviews and approvals to their team are similarly missing the bigger picture. It’s true that leaders often have more context and consider a wider scope for the effects that code changes can have; using this as a reason for not trusting your team is an error.

Instead, it’s up to you as a leader to share this context and these larger considerations with your team members at every opportunity. It’s not only relevant for code reviews, but while building the features that create the PR in the first place.

Share What You Know

Sharing information that you have as a leader can also empower the team to answer a lot of their own questions. There’s no good reason I can think of for leaders to withhold context such as a long-term roadmap, discussions surrounding feature prioritization, and customer feedback from the team. The latter in particular can be rewarding and motivating for contributors.

Rather than simply firefighting questions you receive from the team, observe them and ask yourself what information you could make available that would have helped them to find an answer for themselves. In a future chapter, I’ll give you a sustainable strategy for doing just that.

Take it to work today:

1. Don't be a bottleneck. Look for processes where you can remove yourself as a gatekeeper, such as by having individual contributors review and approve PRs.

2. Trust your team. Utilize their individual talents by empowering them with autonomy.

3. Don't become a gatekeeper for knowledge. Share context and the bigger picture with your team.

This is especially true for software developers. An engaged developer finds pride in their mission, helps out their teammates, and wants to go the extra mile to produce high-quality work. A disengaged developer... doesn't.

The onboarding experience is a highly underrated yet vital part of building a strong technical team. Not only does it determine how a new team member feels about working for you, but how they approach every other position they'll hold in the future — especially if it's early in their career.

A great first day can demonstrate culture and good habits that successful teams aspire to achieve every day afterwards. Here's how to make day one amazing.

Your Developer is Your Customer

You've hired them to join the company, now you need to sell them on joining your team.

Day one sets the tone. Go out of your way to ensure your new teammate is getting the guidance they need, either from yourself or from one or two assigned team members.

It doesn't matter how comprehensive you think your team documentation is (and it should be!) — speaking from experience as both a hirer and hire-ee, your team docs are going to be hard to find and hard to read on day one.

Why? Because starting at a new company means a lot of tasks and information coming your way right off the bat. HR will want forms filled out, there will be accounts to sign up for, preferences to set, new machines to set up, and (hopefully) a flurry of chat messages coming in saying, "Welcome to the team!" All this means that some leisurely day-one downtime for finding and browsing your team docs isn't going to happen.

There's no replacement, on that hectic first day, for a real human guide. Your new teammate needs someone available to answer questions, send links, and point to where vital tribal knowledge is stored. Ensure you're serving one of your most important customers today.

Time Block

In the blitz of things to do, time passes quickly on day one. If you don't block out specific windows of time, there won't be enough hours in the day to accomplish vital tasks.

To allot time blocks to necessary tasks means you'll have to know how long they take. If you've been in your position for a while, re-familiarize yourself with the current onboarding processes. Ask HR for the forms a new hire needs to fill out. Try and set up new accounts and multi-factor authentication to see what the process entails. Understanding what a new hire goes through can help you anticipate possible pitfalls and triage what needs doing on day one.

Set up time blocks for the absolutely-necessary stuff, then don't let them bleed into one another. If you hit a block and can't complete a task within the allotted time, you — as the leader — have messed up somewhere. Don't degrade your new hire's first day trying to fix it on the spot. Move on and solve it later.

Deploy on Day One

Your foremost goal for your new teammate should be to deploy on day one.

There's a lot wrapped up in that sentence. To make this possible, you and your team need to have all your ducks in a row. How long does it take your team to deploy? Are you practicing continuous deployment? Is your code review process solid (does it exist?)? Do you have automation set up for things like integration tests, pipelines, security testing, etc? If the idea of a new hire deploying on day one seems worlds away to you, this is a great goal to set your sights on. Start getting those processes up to speed.

A new teammate who can deploy on their first day is a sold teammate. Not only is everything in place for them to start working on issues tomorrow, but they've already, on their first day, materially contributed to your product. What a sense of accomplishment, of being part of the team. Guaranteed, they’ll be sufficiently impressed to be telling a loved one today, "My code is live in the app right now!" That's an achievement worth celebrating.

Take it to work today:

1. Treat your new teammate as you would treat your most important customer today. Assign them a buddy (or two) and ensure they have the guidance they need.

2. Time block the day to ensure the most necessary tasks get done. Stick to your schedule.

3. Deploy on day one.

In reality, technical skills are a highly overrated part of a strong candidate's good qualities. When looking for a quality hire, tech skills are not the best indicator of long term success at your company, regardless of seniority level.

Leaders often make the error of heavily weighting technical skills because they don't know what else to look for in a candidate. In this edition, I'll show you what to look for — and how to find it by stealing my go-to interview questions.

Why Tech Skills Matter Less Than You Think

In what remains a couple of the worst and best interviews of my career, I interviewed two candidates who perfectly illustrated this point. Both were applying for a software engineer position.

The first candidate was every recruiter’s dream. She’d been a software developer for many years and previously worked at two of the Big Five. She had all the skills on our requirements list, so of course I agreed to the interview. We even skipped the screening call (that was a mistake). I’m abstracting identities to preserve privacy — I’ll call her Alice.

It was one of the most abrasive interviews I’ve ever conducted. When asked about her methods, Alice was intransigent. She swore and talked down about prior coworkers; her language was unprofessional. When asked one of the company’s standard interview questions — to explain a basic concept — Alice was assumptious and arrogant. She prefaced her answer with, “I mean, you should all already know this, but…”

Would she have been a highly skilled employee? Probably. That doesn’t mean anyone wanted to work with her.

On another hiring journey, a candidate was applying for his first "real" software development job. He was a recent graduate and had no experience to speak of other than personal projects. I'll call him Drew.

By most companies’ standards, Drew would not have seen an interview. He didn’t meet the minimum “years of experience” that so often serves as a poor gatekeeping mechanism.

The only experience Drew had to speak of was an application he built and had been maintaining for the last few years while completing his education.

Why did I agree to the interview? I saw qualities in Drew’s personal projects that often foretell a successful, long-term colleague. I’ll describe what those are below, and how to find out if a candidate has them.

Spoiler alert: Drew joined the team, produced excellent work, and quickly earned a promotion within his first year.

This isn't at all to say that technical skill should be disregarded. Any candidate you consider ought to have the technology chops to (at least) approach the work you want to hire them to do. Nevertheless, technical skill is one of the easiest qualities you can help a software developer improve upon.

Taking on a teammate without the following qualities is a lot more work.

What to Look For: Key Qualities of a Good Candidate

Qualities that forecast the long-term growth and success of a software developer at your company include these top requirements — yes, they’re in priority order:

1. Autodidactism. Can this person determine what they need to learn, then go find the resources to learn it? Can they successfully comprehend new concepts and explain them to others?

2. Consistency. Is this person true to their word? Can they stick with a long-term project? Is this someone who doesn't give up easily?

3. Proactiveness. Do they wait for problems to arise before tackling them, or do they seek out potential issues and nip them in the bud? Do they think ahead?

4. Humor. Can this person avoid taking themselves too seriously? Are they emotionally mature? Will they get along easily with the current team?

How to Find It: My Go-to Interview Questions

Over years of experience, I’ve distilled a list of go-to interview questions to help reveal the qualities I value above. Here’s what to ask and why.

Tell me about something hard that you've done.

My favorite question first. If you value the key qualities above, you want a candidate who can think of at least one hard thing they’ve done in the past. It doesn’t matter if they ultimately succeeded or failed at whatever their goal was. Ask for the story, for how they handled it.

Did they seek out a challenge? (Proactiveness) How did they know what to do next? (Autodidactism) Did it take a long time to surmount? (Consistency) If they did fail at something, how did they handle it? (Humor)

Tell me about something you regularly do that benefits your life in some way.

Consistency check. It's not easy to build long-term habits, even beneficial ones. Many people start projects or engage in noble efforts only to abandon them when the novelty wears off. How did this candidate decide to start doing this regular thing? How long have they been at it? What's the cost-benefit calculation, or how do they decide it's worthwhile to continue?

Assuming you get this role, what would be the next step in your future career?

I'll admit this one has thrown a few candidates for a loop. People rarely think beyond the job they want next, and it may be stranger still for someone who’s interviewing you to ask about the position you want after the one you're interviewing for.

I like this question for its ability to reveal candidates who think ahead. Even if someone has no specific plan for a future role, a good candidate will be able to describe a general direction and the aspects of the future work that are important to them. I've found that all of this is a good indicator for proactiveness.

What kind of team or leadership do you want to work with?

No other question for me is as revealing as this one when it comes to finding out if your candidate is emotionally mature. This type of maturity is required in order to differentiate between the types of collaboration and leadership styles you've worked with — to understand them, and form an opinion about which ones best complement your own personality.

Ask this question of a few people and you might find it's an excellent indicator of their level of experience as well. Why? More senior developers have, by constraint, worked with a greater variety of people, teammates, company environments, and leaders. They'll be able to tell you quite plainly whether they prefer a scrappy startup-style environment with a flat hierarchy, or a structured organization with strict division of labor and top-down guidance. There's no wrong answer here, though you'll want to ask yourself if your team is going to provide the kind of environment that this candidate thrives in.

Oh, and make a joke.

Speaking of the quality of humor, don't take yourself too seriously. Try a lighthearted joke at some point in your conversation. Not only will this help remind you and your candidate that you're both human, it can help to take pressure off for folks who tend to be very nervous in interviews (and thus act less naturally than they otherwise would). It's a good soft-skills test too. See how your candidate responds, and consider how their response would fit in with the rest of your team.

Be Prepared to Answer, Too!

At the "Do you have any questions for me?" stage of one of my most fun interviews, the candidate picked his favorite interview question that I'd asked of him and turned it right back around on me. It was good thinking on his part — if you were interviewing for a new position, wouldn't you want to see these qualities in your teammates and leaders as well?

Give some thought to how you'd answer all the interview questions you ask. Not only does it show conscientiousness on your part when you're able to answer them for a candidate, but it will help to develop these great qualities in yourself as well.

If you’re wondering what my answers to these questions would be, ask me in the comments!

Take it to work today:

1. Value the key qualities of a good candidate, not just technical skill.

2. Steal my go-to interview questions to effectively look for these when hiring.

3. Know how you'd answer these questions for yourself.

By the way, if you’re interested in a hands-off, technical filter for screening software developers, I built ApplyByAPI.com to fill that need.

This edition covers an often misunderstood, sometimes vilified, but altogether necessary third pillar.

Optimization is a delicate balance. It's very easy as a leader to under or over-optimize your processes. Developing the skill of knowing how much to do, and when, is vital to your team's success. I'll teach you what to look out for and how to keep yourself in check.

First, Awareness

How do you know when to optimize?

Two concepts are helpful here: your Inner Inefficiency Detector (IID), and a simple cost-benefit formula.

Develop Your IID

A well-tuned IID can make the difference between a decent leader and a great leader. Make a habit of stepping back and re-evaluating processes and decisions. Ask yourself:

• Is it better now than it was before?

• Does the team feel this is overly complicated? If so, why?

• Is there a simpler or faster solution, and if so, why are we not considering it? What's the most naïve solution?

• Is this plan going to be maintainable?

It takes some practice at introspection to discover inefficiencies. Make this a routine step in your cycle. Before long it becomes much easier to steer your team away from wasted time and effort.

Some typical things that set off my IID are:

• New tools are proposed that don't add necessary functionality

• More time is spent categorizing or sorting information than utilizing it

• Overblown solutions are proposed to account for use cases that may never exist, or that the customer hasn't asked for

What would you add to this list?

Cost and Benefit

Keep in mind that the ability to optimize doesn't always mean it's a good idea.

Only optimize when the potential gains are positive and worthwhile. For example, you may consider overhauling a process that currently takes two weeks to run. If this process needs to run every month for a year, it currently takes 24 weeks (2x12).

What is the maximum amount of time you're willing to have your team spend in order to optimize this process? Consider both the cost (time and money) spent overhauling the system as well as the amount of time the improved process will still require.

If you spend four weeks creating improvements and get the process down to one week, you've spent four weeks to save 12 weeks over the next year. The time spent on optimization should also be considered, so in this example, your improvement is from 24 weeks to 16, saving 8 weeks.

Run the cost-benefit calculations for your situation before jumping into optimization to help decide if the process would be worthwhile.

Second, OODA

The OODA Loop is a vital concept any leader should be familiar with. The steps Observe, Orient, Decide, Act lay the foundation for you to make informed and relevant leadership decisions.

Here's how the OODA framework applies to anything you want to optimize.

Observe

Gather real information about the thing you want to optimize. A pitfall of many (especially technology) leaders is the desire to solve problems that aren't actually there.

This is often a rationalization to use a Shiny New Technology or to be able to boast some new groundbreaking effort.

Do you have metrics, first-hand accounts (talk with your engineers!), or (internal or external) customer stories that support what you want to see optimized? Are you certain you understand the root cause of the problem, and have you spoken directly with the people experiencing it?

If there's anything you can measure to judge your own success, measure it. This is helpful for determining whether what you're doing is working, for communicating goals to your team, and for summarizing efforts for executive leaders.

Orient

Part of the duties of a leader is to make "good" decisions with the information at hand. What makes a decision "good"?

In the Orient stage, you hone your leadership abilities. The information you gathered can be cross-referenced, analyzed, and synthesized with other information. Your previous experiences, along with insight into different parts of the organization and the goals of its different groups, will combine to help you make the best decision you can with the information you have.

By placing your new information within the full context of what you know, you orient yourself in order to make a "good" decision.

Decide

No decision has a 100% chance of working out the way you hoped. As a (good) leader, you take responsibility for whichever way it goes. It can be helpful then to view each decision you make as a bet.

Bets are probabilistic. There's some chance that everything you planned will work, and there's some chance it won't. Your goal is to use the output of the previous orientation stage to make a bet that is likely, but not guaranteed, to work out.

Considering decisions in this light can help to take the pressure off and put the next stage in perspective.

Act

Once your decision is made, don't hesitate to act. Provide guidance to your team for enacting your decisions right away (don't forget what you learned in 001!).

Indecisive leaders may backtrack or even try to return to the observation stage for more information before putting a plan into action. This is damaging to your cycle time as well as your team's impression of your capability and confidence.

Rather than falling into the trap of thinking that you're committing to this action forever, view this stage as a new testing phase. Putting plans into action is the only way you can learn if they are steering you in a positive direction.

Recall that this is the OODA Loop. By taking action at this last stage, you fulfill the prerequisites for the first. Action begets results that you can further observe and learn from.

Take it to work today:

1. Practice introspection to better spot inefficiencies in your processes.

2. Decide if the cost of optimizing is worthwhile.

3. Use the OODA Loop framework to iteratively optimize anything.

The phenomenon I call Task Sprawl is an insidious beast. It spawns slowly, feeding on the best intentions of issue-labellers and kanban-board-organizers. Its hold on your organization's productivity is carefully disguised as reassurance and oversight. Very rarely will any long-term team members be able to detect its presence -- it's simply been there too long, imperceptibly embedded in the process, like paint on the wall.

Task Sprawl symptoms include:

• "I don't know what to work on next."

• "You spent all of last week on A. Did you do anything for B?"

• "Did anyone write down the decision we reached about that bug last week? Where is it?"

• "Is XYZ finished yet?"

If your organization is like most, you may have a bit of a Jaws-like feeling about now.

Task Sprawl has a much more significant impact than just the time required to fumble through conversations like these. It can lead to a feeling of overwhelm in managers and engineers alike. It contributes to indecisiveness. It removes autonomy and the initiative to problem-solve from your senior developers. It slows down everyone's ability to produce. In other words: lost time, increased stress, wasted money.

There's only one solution to Task Sprawl: a central, single, prioritized task list.

If that sounds unachievable, if you're already sure of a dozen reasons why it wouldn't work... I hate to tell you that the problem might be you.

Don't worry. Just like other topics covered in these docs, prioritizing to overcome Task Sprawl is a skill you can practice and learn to excel at. Here's how.

Practice Prioritizing

The main purpose of having a single, central list is to make it impossible for any two items to have the same priority. It's a huge red flag whenever a leader says, "The team's current priorities are..."

If your priority has a plural form, you're doing something wrong. Strong leaders choose one thing at a time for the team to focus on; weak leaders say, "Everything's important! Do it all at the same time!"

There may be situations in which multiple things need to happen within the same window. In these cases, split your team and give one priority to each group. Avoid creating situations in which one person is working on more than one "priority." This unnecessarily creates confusion and stress because you as a leader failed to make a clear decision.

One thing that I’ve found helpful is to organize tasks in the form of a Directed Acyclic Graph (DAG). Identify which tasks depend on the completion of, or decisions resulting from, another task. This can help to create a pragmatic order.

Now that you know what to do, how do you get there from here?

The Quick Fix: Recovering from Task Sprawl

All hope is not lost! With sufficient motivation, recovering from this productivity-killer doesn't take long. Here are two approaches you might take depending on your situation:

You're the manager:

• Explain the detriment of Task Sprawl to your team

• Communicate that the goal of change is to make their lives simpler and improve your ability to help out with tasks

• Ask the team where they spend the most time looking at and updating tasks (Jira? GitHub? GitLab? Notion?)

• Track all your new work in that once place from now on

You're not the manager:

• Explain how Task Sprawl is making it harder for you to get things done

• Explain that finding information about tasks is difficult, knowing where to update tasks is confusing, etc.

• If others on the team feel the same way, have them chime in too

• Show your Manager where and how most people on the team are tracking work

• Propose that all work be tracked in only that one place from now on

Don't spend more time moving your current tasks into the chosen tool -- that's just more effort spent on a temporary problem. Wrap those up wherever they live, and make the change with all new tasks starting today.

It can be tempting to move to a Shiny New Tool with this change. It might even feel like a welcome fresh start. I highly recommend against this.

Stick with one of the tools your team is already using. Figuring out where tasks are already being written down most of the time is a key element for avoiding sliding back into Task Sprawl in the future. Why? Because changing the working habits of everyone on the team is a high-friction endeavor. While you might be excited about a Shiny New Tool, getting everyone else to learn it and remember to use it is adding to the list of things on their plates.

We don't want to add effort; we want to subtract.

Consider the different emotional reaction the below statements evoke.

Adding: Instead of using Jira, Notion, and GitHub, we're going to migrate everything to Google Spreadsheets! It's going to be great!

Subtracting: Instead of using Jira, Notion, and GitHub, we're just going to use GitHub Issues from now on.

If you've already got a multitude of things to look at and to do in a day, which would you prefer?

The Long-Term Fix: Avoiding Task Sprawl

Whether you're just standing up a team or want to avoid falling back into inefficient habits, how do you encourage your organization or team to avoid Task Sprawl in the future?

Keeping these three D's in mind can help:

Discipline

Develop the discipline to avoid investing in each Shiny New Tool that pops up. Avoid giving in to one-off requests to track and discuss parts of work in different places. Become a watch-dog for ensuring that important discussions take place where the work is tracked. The next time a Slack conversation starts making decisions, say, "All this sounds great! Can you please help me ensure these ideas are recorded [where the work is tracked]?"

Direction

Stick to tools and processes that are directionally aligned with your goals. Where do you want your team to spend the most time? If you would like to see more thoughtful exploration of ideas and decisions happen before the building begins, choose a tool that encourages long-form text (e.g. Notion). If you want tasks to be tracked and discussed close to the work so that finding related items is easy, ensure those discussions happen where the work is being done (e.g. GitHub issues and PR comments).

Decision

Keep in mind that your business needs, customer desires, and development staff will all change over time. It's your primary duty as a leader to account for the information at hand and make decisions. One day, you may have cause to make a change, use a different tool, or split priorities over more than one team as your organization grows. The most important factor for prioritization is the strength of your leadership. Decide on which central tool to use, assume responsibility for your decision, and give your team direction.

Take it to work today:

• Practice prioritizing.

• Centralize on a single tool.

• Ensure long-term success with discipline, direction, and decision.

The first few newsletters will cover the most fundamental pillars of good leadership. Being well-practiced at these will set you up for success in any field.

Every edition will give you practical leadership skills you can take to work right away. Let’s go.

Poor communication will tank the best teams.

The good news is that good communication is achievable by anyone. It has little to do with your personality or temperament or even your mood on any particular day.

Good communication is a skill you can practice, and like all skills, mastering it is straightforward: follow the recipe until it becomes second nature.

There's a recipe for good communication. Like other recipes, one of the best ways to learn it yourself is to teach it to someone else.

One of the most important things leaders can do for their teams is to set standards. You can write them down, or lead by example, and hopefully you do both. To ensure people on your team practice good communication, you set a standard for it. In this way, you teach it to them. You follow it yourself.

The main gap between poor communication and good communication is knowing how much to say. Here's the recipe.

1. Don't be lazy

Especially in technical fields like software development, it's good practice to communicate your thoughts to others as if it were the first time they'd ever heard of something remotely like this. Yes, it takes more time and effort (initially). Don't be lazy.

When you explain things with full background and context, you're not assuming the person you're speaking with is dumb. Instead, you avoid making the assumption that they're familiar with what's in your head at the same level that you are. Hopefully, in a strong and diverse team of many different talents and backgrounds, everyone is bringing a slightly different strength to the team. (We'll cover more about hiring a strong technical team in a later edition.)

Since everyone's strengths are slightly offset in terms of focus areas, it's (hopefully) likely that you have more detail about the project, product, or parameters you need to explain than someone else does. If you want to respect your team member's time and not leave them to fumble around for answers later on, don't leave anything out.

This is also useful when explaining things to yourself, which is why I came up with a system for writing good documentation. (That one is public — feel free to share it!)

2. Explain, don't dictate

A benefit of diversity of experiences is the likelihood that your team members will come up with different ideas and solutions than you would. When explaining an issue and the solution you'd like to see, focus on the ultimate results instead of the pathway to get there.

This is a "mission command" style of leadership. In it, you trust that your team is made up of smart, resourceful, creative people. You offer the desired end state, any relevant parameters or constraints, and any other influences on the process that you're aware of. After that, it's up to your team to make it happen. You avoid micro-managing, which is better for both your mental health and that of your team members.

Dictating precise solutions, even when you know the domain well, does not create speed. As a domain expert, you might happily offer resources or common pitfalls that you're familiar with. Dictating the solution path, however, can slow your team down by causing tunnel vision. Team members end up putting all their resources towards a solution that might not work out — at no fault to them — because you haven’t sufficiently emphasized the desired end goal.

Instead of saving time, this only postpones the natural breadth of initial exploration of the solution space to the less-than-ideal, mid-sprint, we-sort-of-started-building-already moment.

3. Define success

Success can be defined in many different ways. Here are a few, to give you an idea:

• The product works really well and the other teams love it

• The product mostly works and everyone is buying it

• The product is finished quickly and management is really happy

• The product took twice as long as expected and the customer thinks it's perfect

• We met the arbitrary success metric

Many different forms of success can be valid, but aren't necessarily intuitive. If your team doesn't know what the metrics are, what the desired outcome is, or who is ultimately going to judge your success, it can be very hard to achieve it.

You team wants to succeed. You have the knowledge of what success means, so share it at every opportunity.

If you don't know what your team's success looks like, you'd better find out. Talk to your boss, your board, or your customers, and agree on something to aim for. Your team needs the direction, and so do you!

Take it to work today:

1. Don’t be lazy

2. Explain, don’t dictate

3. Define what success looks like