It’s understandable. You spend days, weeks, maybe months agonizing over ever detail, every pro and con, every possible outcome. You’ve done your due diligence, and you’ve made the best decision you can given the situation. You’re confident in your decision, and you’re ready to move forward. Then comes the inevitable push back from your team. They have questions, concerns, and objections. They’re not happy with the decision, and they’re not shy about letting you know.
It’s easy to dismiss that negativity as ignorant, personal, or a vocal minority (“you can’t please everyone”), after all, they have a fraction of the perspective you have as a leader. You might seek to “control the narrative”, by dismissing such voices as inviting negativity, undermining your authority, or asking questions that you’ve already answered, thinking its unproductive to further discuss a decision you know is final. Those are all understandable and human reactions.
Attempting to “control the narrative” by silencing dissent is not only ineffective, it’s also counterproductive:
Like your own reaction, your team’s reaction is equally human, and I’d argue, actually a good thing.1 It means they’re engaged. It means they care. While you’re ready to move on, they just go the news, and they’re still processing. The difference between good leaders and great leaders is in the follow through. Specifically, in their willingness to engage in the emotional labor of helping their team figure out how to move forward, together.
That dissent isn’t disengagement or obstructionism as it may be easy to misread. Quite the opposite. They’re likely “caremad”2 - they’re upset because they care about ensuring the best possible outcomes and are trying to figure out how to do that. The reality is, questions and dissenting voices are a sign that people care about the decision being made. They want to understand the reasoning behind it, and they want to have a say in the process. And as a leader, it’s your job to listen to those voices, take their concerns into account, and plot an emotional path forward.
The best leaders I’ve worked with have always been open to dissenting voices. They’ve always been willing to listen to the other side of the argument, and to engage with it, even if they’re not willing to change their mind. The playbook is simple: be transparent, open, and accountable. This means:
While some see leadership as bold and courageous decision making in the face of a difficult situation, I would argue that covering one’s ears and humming in the face of after-the-fact questions shows a lack of leadership in the moment. It’s the equivalent of saying “I would have gotten away with it if it weren’t for you mangy kids…” (for those that grow up watching Scooby-Doo and other Saturday morning “who done it” cartoons).
The alternative to the “I don’t like what they’re saying so they shouldn’t be allowed to say it” approach is to embrace transparency, openness, and accountability. This means acknowledging the complexity and uncertainty of the situation, explaining the rationale and evidence behind your decision, inviting and addressing the questions and concerns of your stakeholders, and admitting and correcting any errors or shortcomings. This also means being humble and curious, listening and learning from others, and being willing to change your mind or course of action when warranted. This also means being clear and consistent, communicating frequently and honestly, and following through on your commitments and promises.
I’d take an engaged team that can have healthy, productive, and respectful disagreement any day over a team that’s checkout out, indifferent, or apathetic. If they don’t care enough about this thing to speak up, it’s likely that there are other, bigger things that they’re not speaking up about either. ↩
A portmanteau of “care” and “mad”, meaning a software developer who is passionate, enthusiastic, and diligent about their work, and who cares deeply about the quality, functionality, and impact of their code and products. A caremad developer is not satisfied with mediocrity, but strives for excellence, innovation, and continuous improvement. For example, “She’s caremad about accessibility, she always makes sure every feature is compatible with screen readers and keyboard navigation.” ↩
I’ve written before about bringing software development methodology to management, so what if we apply this cathedral vs. bazaar metaphor to people management styles?
The cathedral manager is like the architect of the cathedral. They have a clear and detailed vision of what they want to achieve, and how to get there. They plan everything in advance and assign specific roles, tasks, processes, and standards to their team. They monitor and control their team’s work, and give them precise instructions, feedback, and guidance.
The cathedral style of people management is characterized by a high degree of control, direction, and standardization with problems and solutions being identified and defined in a top-down manner. Its advantage is that it can produce predictable and reliable results, especially in complex and stable environments. It can also create a much needed sense of order, clarity, and security for members of the team, who find comfort in knowing what is expected of them and what they can expect in return.
The disadvantages of the cathedral style of people management are that it can stifle creativity, speed, and innovation among knowledge workers, especially in dynamic and uncertain environments that require a lot of experimentation and adaptation. It can also create a sense of rigidity, bureaucracy, and hierarchy for the team, who may feel constrained, micromanaged, and disempowered.
The bazaar manager is like the organizer of the bazaar. Leaders in this style tend to have a broad vision, a flexible plan, and a flat network of roles and responsibilities for the team. The manager acts as the facilitator, the coach, and the enabler of the team’s work, defining goals and objectives and providing guidelines, feedback, and resources, while empowering the team to define their own tasks, processes, and standards, encouraging them to explore and innovate.
The bazaar style of people management is characterized by a high degree of autonomy and collaboration, with problems and solutions being identified and defined by the team. Its advantage is that it can produce innovative and resilient results, especially in dynamic and uncertain environments. It can also create a sense of freedom, empowerment, and ownership for team members, who can shape their own work, express their own voice, and pursue their own growth.
At the core of the bazaar style is the belief that team members are competent, self-motivated, and capable of aided self-direction. They encourage their team to explore their interests, share their ideas, and contribute their skills to further the team’s goals. This approach can also foster a culture of openness and trust among the members of the organization, who can learn from each other, support each other, and challenge each other.
As a manager or as someone who is managed, you should know which style you prefer, and which style your manager prefers. You may find that your team is a mix of cathedrals and bazaars styles, or it may even change depending on the scenario, and that’s okay. Here are some common ways in which the two styles can differ:
The key is to find the right balance between the two styles, and to be able to switch between them as needed.
The cathedral and the bazaar is not only a metaphor for software development, but also for people management. By understanding and applying these metaphors, we can create more effective, innovative, and resilient organizations that can thrive in any environment. We can also create more satisfying and fulfilling work experiences for ourselves and our team members, by aligning our preferences, goals, and styles with the appropriate management model.
As a manager, you should ask yourself: are you building a cathedral or a bazaar? And as an employee, you should ask yourself: do you prefer working in a cathedral or a bazaar? And most importantly, are you and your manager on the same page?
]]>Agile development can trace its roots back to the production floor of Toyota as far back as the 40s and 50s. At the core of the Toyota Production System (what eventually inspired the lean manufacturing movement) was the concept of an andon, a concept we continue to see driving benefit in modern software development today.
In short, an andon is a system of lights and signals that allows workers to alert managers and colleagues of any problems or defects in the production process. With the pull of a cord or the press of a button at each station by any worker, the entire production system grinds to an instant halt. It may seem counter-intuitive to make it easier for anyone to shut down production, but the idea is that if you stop the line as soon as a problem is detected, it can be fixed before it gets worse. It’s been so successful in driving continuous improvement that Toyota (and most other manufacturers) continue to use the concept to this day.
The andon is designed to empower workers to stop the line, identify the root cause of the issue, and implement corrective actions, rather than letting it pass unnoticed or hoping someone else will fix it later. The andon is not only a tool for quality control, but also a culture of continuous improvement, where everyone is encouraged to speak up, share feedback, and collaborate on solutions. The andon fosters a sense of ownership, accountability, and learning among the workers, as well as transparency, trust, and alignment among the managers.
Transparent collaboration in software development and other knowledge work is like the andon in a production system. It allows anyone to spot and call out critical issues early on before they get worse, and to engage in constructive dialogue and problem-solving with their peers and stakeholders. Some of the benefits of transparent collaboration are:
Of course, transparent collaboration is not without its challenges and trade-offs. It requires a shift in mindset, behavior, and culture, as well as a set of tools, processes, and norms that support and enable it. It also requires a balance between openness and privacy, between collaboration and autonomy, and between feedback and focus.
The benefits of transparent collaboration outweigh the costs, especially in a complex, uncertain, and dynamic environment, where the ability to adapt, innovate, and deliver value is essential. By adopting the andon principle in you own work, you can leverage the collective intelligence, creativity, and experience of our teams, and create better products and services for your users and customers. Here are some ways you can apply the andon principle to your software development team:
Software development is not the same as manufacturing, but it shares some similarities. Both are complex, iterative, and collaborative processes that involve creating and delivering value to customers. Both also face challenges such as quality, efficiency, and innovation. And both can benefit from the andon principle.
The andon principle is not a silver bullet, but it’s a powerful tool for spotting and solving critical issues early on, and for fostering a culture of collaboration in your software development team. By adopting the andon principle, you can empower yourself and your team to stop the line when necessary, to collaborate and problem-solve with your peers and stakeholders, and to create better products and services for your users and customers. So, next time you encounter an issue in your software development process, don’t hesitate to pull the andon cord. Your team and your customers will thank you for it.
]]>I’ve written before about the benefits of working asynchronously, but less obvious, it also changes the way we think and work. Async work allows for more reflection, research, and synthesis. Those working async can and should take the time to think, learn, and synthesize before sharing their ideas, opinions, or solutions, distilling them down to the most critical. This improves the quality and clarity of the communication, and most importantly, the overall throughput of the communications channel.
Think of it like gzip compression, but for human-to-human communication. Yes, there’s slightly more processing overhead at the start, but it allows greater communications throughput using fewer “packets” (communicate more using less).1 How can you communicate more, less frequently? Here’s a few tips I often keep in mind:
Remote work requires communicating more, less frequently, because asynchronous communication involves less frequent, but richer communication, meaning there is less time talking about the work and more time doing it, allowing the system to optimize for throughput and flow.
Not to mention, thoughtful, written communication, helps ideas to scale more effectively (there’s a reason the printing press spurred the Renascence). It shifts communication from a one-to-one relationship, to a one-to-many. Next time you’re about to “send a quick DM” or “schedule a quick chat”, consider what steps you could take to optimize for the long tail of information retrieval and discovery. Just like building a web app, “writes” are expensive, but “reads” should be “cheap”, so avoid introducing mental N +1s into the system whenever possible. ↩
A small nod to inclusively to go a long way to create a sense of belonging and reduce ambiguity, when working with global teams, schedule and communicate with a global (and remote) audience in mind.
]]>Pull requests capture not just what change was made, but who made it, why, and what alternatives were considered. They create a cross-linked web of context for others, and capture the discussion around the change, which is often an equally valuable technical artifact.
When I write a PR, I write it not just with the immediate reviewers in mind, but how it will read for outsiders down the line who might land on in from search results or a cross reference. Beyond documentation, PRs are a great place for your colleagues to ask the type of “dumb questions” that gives you the confidence to ship.
To that end, here are a few practices I follow when authoring pull requests to ensure I’m capturing sufficient context for myself and future contributors:
Update FILE.md
and instead use the title to capture the essence of the change in a way that is clear when scanning a list of PRsCODEOWNERS
. Not only does this bring visibility to the PR, it also makes ownership clear by explicitly calling out the responsible team. Be sure to include why you’re @mentioning the team (what action is requested, if any) so that it’s surfaced in the notification.fixes
related issues - to create a trail of breadcrumbs to improve discoverability and allow others to opt-in to additional context. As an added bonus, it will auto close the tracking issue for you.Yes, organic documentation takes slightly more time, but it’s less overhead than keeping static documentation up to date, and I promise you, it’s well worth it - your future self (and future coworkers) will thank you.
For even more tips, check out how to write the perfect pull request on the GitHub Blog.
]]>When starting up a new initiative or collaborating with a colleague for the first time, it’s often tempting to “throw some time on their calendar” to “kick things off”. Such kick off meetings often consist primarily of an information download, sharing context from one coworker to another with a specific call to action or request for feedback. But information transfer isn’t always the best use of synchronous time, especially when you consider the overhead of scheduling (especially across time zones), scaling (O(n) vs O(1)), and memorializing outcomes (as durable artifacts available to others). Not to mention, different people have different learning styles - not everyone absorbs information best via voice and in real time.
Instead, next time, consider transferring that context asynchronously (as a GitHub issue or Google Doc, for example), and then scheduling a meeting only if the conversation requires it - you’d be surprised how often it does not. A few minutes of reading or a few comments on an issue or Google Doc can often replace waiting days for mutual availability and a dedicated 30-minute block of time. In this sense, you can think of meetings as a point of escalation based on complexity, not as the default starting point for a workstream, initiative, or conversation.
You may be skeptical. I was curious, so I wrote a quick script to pull stats from my own calendar. My first year at GitHub (2013), I had a grand total of 16 internal meetings. Yes, we were smaller back then, but we were also dogmatic about being async first, almost to a fault. As we grew, my second year I had 43 meetings, and things gradually increased from there. This year, I’m on track to have over 600 meetings. There’s got to be a better way!
Working asynchronously by default fosters a more inclusive culture, facilitates discoverability and permanence, create space for learning, allows for greater work-life balance, and produces better outcomes, faster. Async is also the key to making remote work, work.
If you receive a meeting invite (or if a colleague requests permission to send you a meeting invite) without context, an agenda, or a read-ahead doc, consider politely declining, or at least asking for one - it’s well within your rights (you can even link to this discussion post as a “get out of jail meeting free” card). After all, if the person requesting the meeting hasn’t taken the time to distill their thoughts into writing, why should they be able to decide how you spend your own time?
If you’re not a software developer, you can think of GitHub like Dropbox, Google Drive, or SharePoint, but for software development. It’s primarily used by software developers to collaborate on software and track their progress, but can be used by anyone involved in the software development process.
Repositories are the most basic unit of GitHub. Each repository represents a real-world project, initiative, or team. Repositories contain issues, discussions, and pull requests (more on that in a moment), as well as “code”, which for non-technical roles, is often text files in the form of Markdown (more on that too).
Markdown is how text is formatted on GitHub. If you wanted to format text in a text box that didn’t support formatting, you might use *
s to represent bullets, or wrap a word in _
to emphasize it. That’s Markdown. Markdown is plain text, with optional lightweight formatting that GitHub can render. It sounds like “coding”, but you’ll get the hang of it in no time. To get started, check out the official GitHub docs.
Pro-tip: To convert a Word or Google Doc to Markdown, you can use my very own Word to Markdown converter.
Issues are how work is tracked on GitHub. You can think of them as “To Do” items (or “tickets” in some contexts). Issues describe the problems you or your team want to solve, with the list of potential problems being referred to as team’s “issue backlog”. You can comment on issues, like you would a blog post, assign them to people, and close them when they have been completed. Issues can also be labeled for ease of discoverability and for tracking additional metadata. For especially complex problems, the body of the issue can even include a task list with checkboxes, to track progress of individual sub-tasks.
Discussions are like issues, but don’t have a specific outcome or sense of state (open or closed). You can use discussions to ask questions, collaborate on ideas, and share announcements. You can think of discussions like blog posts, an online forum, or a chat room for your repository.
Pull requests are how you propose changes to a repository. If issues describe the problems, pull requests describe the proposed solutions. Others can also review your proposed changes and comment on, make suggested changes to, or “approve” your pull request. Pull requests modify files within the repository. Once approved, your pull requested is “merged” into the repository and your proposed changes are “live”.
Repositories contain files. These files can be anything, but are often text files in the form of Markdown. You can edit these files directly on GitHub, or you can clone the repository to your computer and edit them there (more on that below). You can also upload files directly to GitHub by dragging-and-dropping them. Generally filenames are lower case and use hyphens instead of spaces. Files, as Markdown is generally how long-lived information is shared and stored (documentation, policy, procedures, etc.).
At the core of GitHub is a version control system called Git. Git tracks changes to files over time. You can think of it like tracked changes in Google Docs or Microsoft Word (or if you’re into Sci Fi, a time machine for your files). You can see who made changes, when they were made, and what the changes were. You can also “roll back” changes to a previous version of a file.
Git tracks changes as “commits”. A commit is a snapshot of the file (or files) at a point in time. Each commit should have a brief, descriptive message describing the changes from the previous version, to help you and your colleagues understand what’s going on.
Branches are like parallel universes or alternate timelines for your files. You can make changes to a branch without affecting files on the “main” branch. Branches contain one or more commits, and when you’re ready, you can merge your changes (commits) into the main branch to update the files there. You can think of branches as saving a copy of a file so that you can work on changes without affecting others’ work, but in a way that makes it easier to merge any changes you make back in with the original when you’re ready.
GitHub flow describes the process of making changes to a repository. The basic steps are:
GitHub sends notifications to you when someone mentions you in a comment, assigns you to an issue, or requests your review on a pull request. You can also (and often should) “subscribe” to repositories to be notified about some or all activity. Likewise, you can unsubscribe from individual issues if you’re not interested. By default you’ll receive notifications via email, but you can also configure GitHub to use “web notifications”, or even set up notifications in your Slack or Teams channel.
One of the most powerful GitHub features is @mentions. You can tag anyone into an issue or pull request by typing @
followed by their GitHub login. They’ll receive a notification and can respond. You can also use @mentions to tag teams, like @github/eng
or @github/eng-ops
. When @mentioning users or teams, it’s best to provide context in the comment so they know why they are receiving the notification.
Another powerful GitHub feature is issue and pull request cross references. You can reference another issue or pull request in a comment by including its number (for example, This is related to #123
). When cross referenced, links are created between the two issues or pull requests, making it easier for others to discover and understand the context of the conversation.
Almost everything you’d want to do on GitHub you can do entirely through the web interface. You can view, create, edit, or delete files, browse and comment on issues, and merge pull requests. If you’d prefer to work on your desktop using your favorite desktop software, you can install GitHub Desktop. GitHub desktop provides a visual interface for “pulling” (downloading) repositories onto your computer and interacting with GitHub.
If you’re using the web interface, you don’t have to worry about pushing or pulling. If you’re using the desktop client, you can think of pushing (in some cases called cloning) as downloading (pulling the files from GitHub) and pushing as uploading (pushing the files back to GitHub).
In addition to Markdown you’ll often see emoji and animated GIFs used heavily on issues and pull requests. You can think of emoji and animated GIFs as the facial expressions and body language of GitHub. They make it easier to convey emotion in written text. I like to describe the communication style on GitHub as “professional but informal”, meaning don’t be afraid to use emoji and animated GIFs to make your comments more expressive (while remaining appropriate, of course).
If individual tasks are tracked as issues, project boards are how you track the progress of a project as a whole. Project boards are a visual representation of what issues are on deck, what issues are in progress, and what issues have been completed (todo, doing, done).
With so much information available on GitHub, it’s often intimidating to find what you’re looking for. Here are some tips for using GitHub’s powerful search to find anything on GitHub:
widgets
will find all repositories, issues, pull requests, and discussions that contain the word “widgets”.org:
or repo:
qualifiers. For example, org:github
will find all issues in all repositories in the github
organization, or repo:github/docs
will find all issues in the github/docs
repository.involves:@me
modifier. For example, widgets involves:@me
will find all issues, pull requests, and discussions that contain the word “widgets” and that you are involved in.language:Markdown
to your search query.You may see one or more status checks on your pull request. Checks are automated tests that run against your proposed changes to enforce certain rules (such as formatting, spelling, or style). If a check fails, you’ll need to fix the problem before your pull request can be merged. You can click “details” next to a failed check to learn more.
Project work generally flows in this order:
As a project proceeds in one or more repositories, high-level project progress is tracked on one or more project boards (which visually organizes the state of multiple issues).
Closes #123
)If you come across a term or concept not covered here, be sure to check out the official GitHub glossary.
Happy GitHubbing! 🎉
“Too long, didn’t read”. This is for the folks who have a question or request, but don’t have time to read the whole document. Put it up front and make it visually distinct. The TL;DR can be as simple as:
If your question or request isn’t answered below, open an issue in
X
or post inY
and someone will point you in the right direction. Wondering the status of an in-flight project? Check outZ
.
When is your last day in the office? When do you anticipate being back? If the exact date of your leave is unknown, you can provide an estimated range, or describe the leave in relative terms (for example, event + 2 weeks
). Keep this section up to date as your plans change. Here’s an example of what that might look like:
Start | End | Dates | |
---|---|---|---|
First Leave | Event | Event + 2 weeks | 1/1/2020 − 1/15/2020 |
Second Leave | Event + 4 weeks | Event + 6 weeks | 2/1/2020 − 2/15/2020 |
{: .table .w-75 .mx-auto} |
How do you want to be contacted while on leave, if at all? What do you want to be contacted about? What’s considered urgent? Set expectations as to how often you will be checking email, Slack, your phone, etc. if you are going to check them at all, so that colleagues know how to get in touch with you, and when to expect a response.
Enumerate all your ongoing responsibilities, along with a point of contact that will be responsible while you are on leave. Be sure to include “points of escalation” for anything not accounted for within your doc, and be sure to check with each named individual to ensure they are comfortable with the responsibility and have the bandwidth to take it on. Consider a dedicated “responsibilities to handoff” section for any key milestones, deadlines, or events expected to occur while you are out. Example:
What | Who |
---|---|
Widget production | Walter |
People management | Paula |
{: .table .w-50 .mx-auto} |
List any recurring meetings you normally run or attend, their frequency, and who if anyone will be taking your place at those meetings. Be explicit with any host or presenter responsibilities, and include links to standing agendas or other supporting documents.
Meeting | Frequency | Responsibilities | Who |
---|---|---|---|
Staff meeting | Mondays @ 10AM | Set agenda, run | Susie |
1:1s with directs | Weekly | Take notes, follow up | Danny |
{: .table .w-75 .mx-auto} |
For everything you touch regularly, list your primary point of contact. This will allow others to unblock themselves if they have a question or request of another department or team. Example:
What | Who |
---|---|
HR | Henry |
IT | Iris |
Legal | Larry |
Finance | Fran |
{: .table .w-50 .mx-auto} |
List any projects, initiatives, or other work you’ve been involved in recently, and any that you hope to be able to hand off to others while you are out. I linked out to our team project board, which captured the in-flight work, and created a “@benbalter’s GitHub Fan Fiction” document, with the backlog of ships that I had hoped would be GitHub cinematic universe cannon before going on leave. My fan fiction looked something like this, framed in terms of problems and solutions:
Problem: I’m going on leave and want to ensure that the work I’ve been involved with recently is not lost or forgotten while I’m out.
Ben’s solution: Write a great leave doc.
Ideal DRI: @benbalter
This is your long-tail appendix of anything you think your colleague might need while you’re out. This could include links to team documentation, commonly referenced spreadsheets or reports, planning materials, or anything else you think might be useful.
You could have the best leave or transition document in the world, but if nobody knows about it, it’s not much use. Socialize the document with key stakeholders well before your leave to ensure accuracy and completeness1, and make your document readily discoverable while you are out by linking to it from your chat status,2 the out of office on your calendar, and any other “APIs” you have for communicating with colleagues.
If you’re preparing to go on leave (or transition to a new role), feel free to use the template below as a starting point.3 Of course, if you have any suggestions or proposed improvements, pull requests are always welcome.
# @your leave document
## ⏳ TL;DR:
## 📅 Dates
## ☎️ Contact preferences
## ✍️ Points of contact
## 📹 Regular meetings
## 👥 Rolodex
## 👉 Stuff you touched recently or hope can be picked up while your out
## 📁 Important links
I often ask, “Are there any questions not answered here that you can imagine might arise while I am out?” ↩
Using an internal or external link shortener (for example, bit.ly/benbalter-leave
) to create a more memorable URL for your colleagues to regularly reference your doc. ↩
If you’re looking for even more extended leave resources, @isethi has a great talk on navigating parental leave as a senior engineering leader. If you’re preparing to go on parental leave, be sure to check out her parental leave checklist template as well. ↩