Six ways you can use GitHub data to stop the meeting madness

I love meeting people, don’t get me wrong. Especially as things open up, I cherish every connection and conversation more than ever before. Simple things like meeting for coffee, taking a stroll, and a good old-fashioned phone call are the highlights of my day. This article is not about these kinds of meetings. Rather, meetings are useless, especially when machines can automate them. Join our mission to end useless meetings.

Why developers hate meetings

In my previous company, we surveyed 100s of developers, and I interviewed over 30 developers. What I learned is that developers don’t arbitrarily dislike all meetings. What they really dislike is inefficiencies, poorly planned and poorly executed meetings. Developers operate on a maker’s schedule and need time units of 4 hours at a minimum for deep work. A single meeting at the wrong time can disrupt a whole afternoon, splitting their focus time into smaller units that are hard enough to get set up and into the zone. Developers and makers need more focused time. And meetings are disruptive when developers want to get into the zone.

This is the inherent tension between managers and developers. As Paul Graham notes, managers are on a different schedules. Managers get stuff done through meetings, but if they are powered with information and the ability to act, they will have less meetings too.

In recent years, organizations such as Facebook and Atlassian mandated “no meeting” days to address this problem. The intent being to increase productivity with “no meeting” days, traditionally a single day each week where meetings are banned. It allows space for people to focus on deep work tasks and also puts pressure on meetings the rest of the week to be more focused. In my experience, this comes at the cost of scheduling overflow and especially when team members are in time zones across the globe, it causes inconvenience and may sometimes stall the progress of the collective team.

You can also be maniacal with your calendar, blocking time and clustering meetings to maximize focused work and most importantly learning to say “no” to meetings when they are useless. Personally, I believe this has far better results, and drives a culture where people respect each other’s time. In software development and the world of agile and scrum, there are many types of meetings. In a single sprint that spans 2 weeks on average, you have a sprint planning meeting, daily standup meeting, sprint review meeting, sprint retrospective meeting. Many of these meetings are “status” meetings. If everyone had the right information at hand, these meetings could virtually be non-existent. If everyone updated their Jira tickets, we would have what we need. Yet, why do we have so many status meetings?

What hurts more, updating Jira or going to useless meetings

This brings us to the main point here, if everyone had the right information, they would meet far less. We could eliminate status meetings completely, if everyone knew what was going on, and how they needed to support each other to achieve team goals.

The problem with existing systems like Jira is that developers have to change context moving from one system like GitHub to another like Jira, and also who likes “work about work”? Shouldn’t we just focus on work, and not take any time away from meaningful work? Typical activities that take makers away from their skilled work -

• Gaining clarity and alignment
• Communicating about work
• Searching for information
• Switching apps
• Chasing status of work

Getting everyone aligned on the big picture is absolutely critical, as we describe here. It’s hard to stay motivated and produce valuable outcomes, if we don’t know how our work aligns with customer value and company goals. Once you are aligned with the “why” (the customer) and “what” (the product), we can leverage technology in such a way that it helps your work, eliminates meetings and gives you more time for focused work.

Get real time updates through GitHub

Information should be available to all, and technology can one day eliminate many meetings and give valuable time back. Here are 6 ways technology and specifically GitHub data can stop the meeting madness: ## 1. Automatic status updates Connect GitHub with your work management system, and ensure your work stays in sync between the two systems. Associate GitHub commits, branches and pull requests with issues and automatically update status of work so you never have to leave GitHub and your deep work time. Your team members have visibility of your code activity in the context of the assigned issue, without you having to slack them on a status update, or join a daily standup.

2. Jira tickets or it didn’t happen!

Don’t sweat tickets. If you choose to start coding and have never linked with a work ID, you shouldn’t have to sweat it. Machines should automatically create tickets that track all associated commits, branches and Pull Requests. Your work is always accounted for and more importantly your team members have visibility and know what you’ve been up to, resulting in fewer interruptions. Never create tickets, unless you really want to.

3. Let em know you are stuck

Code reviews can slow you down as a team, especially when there isn’t good code review hygiene such as raising huge pull requests and not doing self reviews. Code reviews require focused attention and time, and can also get lost in the reviewers inbox. When code reviews are stuck for more than a day, the system should nudge the reviewer. At the same time, the system can update the ticket on different stages of work, and how long code reviews are taking, ensuring everyone has visibility into where things are. This data can be aggregated to understand how to influence great code review practices, and improve the organization’s ability to ship faster.

4. Understand the codebase

Starting at a new company or a new team is overwhelming for most people. The codebase is new and the style of programming could be different than before, and software needs to be understood before developers can contribute. Instead of relying on documentation that can get stale quickly, or schedule a slew of meetings, technology should crawl your codebase and provide real time answers to questions such as, what are the microservices and components and how are they related to each other? What is the code, artifact and deployment related to each service? What are the core dependencies, and who are the people in the sphere of knowledge and influence?

5. How time is spent

If you know how you’re spending your time, you’ll know whether or not you’re on track to accomplishing a goal. This is a question that we must answer for an individual, a team and the organization as a whole. How many times have managers been asked, “what is your team working on”, “what is the organization’s investment allocation to different activities”, “what products and capabilities should we invest/divest in”. These are extremely important as companies scale, and existing systems should automatically generate this information from the source of truth, from its code activity in GitHub.

6. Help me Help you

When stakeholders have visibility into the right information, they have the ability to make tradeoffs and decisions. Product Managers, for example, want to help and it is difficult to do so when they are unaware of engineering measures and activities that developers are spending their time on. They should be empowered with information without requiring a meeting, or waiting till it’s too late risking customer and product. Imagine if systems can synthesize information around a development team’s activities, and empower stakeholders with the ability to understand the current state, weigh in on tradeoffs and help make quick decisions.

Make a cultural shift

Meetings have earned a terrible reputation in the workplace, but meetings are not always useless. They should not be meant as a memo or just provide status updates though. Next time you have a meeting, ask yourself

• As a meeting creator
• What is the objective and desired outcome?
• Is this really a meeting? Or is this a memo or status update?
• Do we have the right information and people to achieve our desired outcome? As a meeting attendee
• What value can I bring to this meeting?
• What happens if I don’t attend the meeting?
• What are other higher priority tasks that I should be spending time on?

As a management team

• How can technology eliminate “memo” and “status” meetings?
• Do employees feel comfortable saying “no”?

What are the best ways to connect, build relationships and celebrate?

Teams rely on meetings to coordinate work and people, and good meetings provide an opportunity for people to align thinking, socialize, enjoy each other’s company and express joy or frustration. For developers, meetings can help build relationships with support teams, customer success managers and product managers. So when something goes wrong in your production, this relationship helps you communicate better and resolve things faster. Meetings are also extremely useful for one-on-ones to foster relationships.

However, technology when used properly can eliminate wastage and an abundance of meetings out there. Not all meetings are bad, so let’s use them carefully — “Meetings should be like salt — a spice sprinkled carefully to enhance a dish,” says Basecamp founder and CEO, Jason Fried. “Too much salt destroys a dish. Too many meetings destroy morale and motivation.”