You have 1 article left to read this month before you need to register a free LeadDev.com account.
Drink your own champagne and share it with your friends. Invest time to save time. Cross-pollinate, delegate, get blendy, and let the good vibes roll.
Rather than forcing tooling mandates or tracking stringent developer productivity metrics, much of GitHub’s success lies in fostering a culture of internal knowledge sharing. “It’s really important for me to cross-pollinate and teach those new skill sets,” says Batra. Staying on top of technologies just around the corner is critical, as they often have the “highest potential to improve productivity,” says Batra.
For Batra, productivity is also intrinsically tied to culture and team dynamics. In this week’s edition of DirectorPlus, she shared a window into what GitHub is doing to enhance internal productivity, including dogfooding their own technology, regularly assessing developer satisfaction, setting aside time for learning, and empowering internal contributors.
Drink champagne and embrace chaos
AI is a hot topic. And it’s no surprise that GitHub has a strong opinion about the role of programming assistants like Copilot in enhancing developer experience. GitHub engineers actively dogfood their own tools (or drink their own champagne, as Batra lovingly calls it).
By the nature of their technology, there is already a “shared passion for productivity” throughout the company, says Batra, creating a helpful feedback loop as developers use GitHub productivity tools within their daily workflows. “How do we want to improve those tools to improve productivity and happiness?” she asks.
But GitHub is not only shipping AI products – it must also scale teams internally to make these projects. Since the field of AI changes so frequently, this goes beyond just hiring a set of machine learning experts. You really need people who “thrive in chaos” and can consume new information rapidly, says Batra. “Their passion for productivity is a little higher.”
Take a breath from the day-to-day
It’s sort of an oxymoron, but you need to put aside time to save time. One way GitHub is improving productivity is by creating a culture that values experimentation. “We need to create a safe space for developers to experiment with productivity,” says Batra. Otherwise, tinkering with productivity improvements is bound to disrupt their day-to-day work.
Hackathons, or passion weeks, are great for this, says Batra, as they allow approved time for engineers to test new tools, such as a new Copilot feature. Sure, there may be a blip where you are less productive, but ultimately this investment will enable a higher productivity ceiling, she says.
GitHub is actively setting aside time to learn with its Day of Learning (DOL), a monthly company-wide day featuring numerous hour-long sessions. Held online, with no meetings allowed, talks are led by internal employees and cover various technical topics.
One recent session was on entitlements for non-engineers, which introduced people without a software background to setting access controls for YAML and git-based workflows. Other talks recently covered OctoBot, a Slack-integrated tool, and discussed how to optimize API endpoints to improve performance.
“A lot is happening on that day, and people tune in when they want,” according to Batra. DOLs have grown in popularity and have produced measurable qualitative results. “We saw a huge change in our surveys around learning and development,” she says.
Amplify vibes, not productivity metrics
To quote Depeche Mode, “Everything counts in large amounts.” Amid an economic downturn in tech, productivity enhancements are the name of the game for many looking to produce more with less.
Lately, there has been much talk in the tech industry about frameworks for measuring developer productivity, like DORA and SPACE. Some practices measure contributions at the individual level, like the number of commits, feature rollout rate, or bugs introduced.
But, measuring individual developer contributions poses issues, says Batra. For one, not all teams are set up the same. The work of a front-end team is vastly different from that of a back-end or platform team, she notes, making their metrics impossible to compare. Secondly, what works for one area might not work for others, making universal changes tricky to mandate.
GitHub doesn’t have a universal metric across every development team. However, it does have a developer satisfaction survey, which can help gauge happiness with tools and identify good spots and bad spots, says Batra. A good engineering leader can spot successful teams, but these cues are often more qualitative.
“It’s sort of a vibe,” says Batra. “If you asked which team is the most successful in terms of productivity, you’d get the same sort of teams in the list over and over.” Then, if you examine these teams closely, you may find interesting signals to apply elsewhere. “It doesn’t hurt to look at metrics – the question is whether that leads you to fact-finding or conclusions right away.”
Find innovators and cross-pollinate skills
Scaling productivity goes beyond single team members. Once you find successful teams, make them share what they’re doing with other teams, says Batra. Technology groups should leverage internal talent and embed leaders who naturally adopt new technologies across the organization.
In her work, Batra has also found that successful teams are diverse and interdisciplinary.
“Whenever I see really good teams, they have really good chemistry between engineering, product, and design,” she says.
Not only do productive teams have great relationships with various stakeholders, but individuals at GitHub often step outside the box of their roles to offer knowledge from past experiences or flex latent skills. As long as people contribute equally, having well-rounded team members can unlock productivity gains. “Why not blend?” says Batra.
Consider the DRI model
Another point on team dynamics that can affect productivity is who’s at the helm. As an engineering leader, Batra looks for ways to delegate her responsibilities – within reason – to improve productivity. However, selecting leaders you can trust is important at the project level.
GitHub teams often assign a directly responsible individual (DRI) per project. Inspired by the DRI model at Apple, this assigns a single person as the sole tie-breaker in disputes. They call the shots and have the trust of everyone on board. Having a DRI avoids ‘decision by consensus,’ which stunts progress.
Interestingly, this person could sit more on the technical or product side. What matters most in choosing a DRI, according to Batra, is they have a minimum amount of technical experience and a history of sound judgment and listening to the right people. With a good track record, “chances are they’re polling from the right place,” she says.
Collaborate like a start-up
Although GitHub is now a corporate company with thousands of employees, it maintains a relative start-up mentality and flexible work culture. GitHub is fully remote and asynchronous, with teams spanning countless time zones, from Hawaii to Helsinki and beyond. Arguably, these traits alone make any organization better poised to leverage the working habits of today’s diverse engineering teams.
That said, the daily developer workflow is complex and unique across teams. It involves many tools and actions, including pull requests, repository management, search, notifications, checking a project dashboard, fine-tuning the local developer environment, and more. As Batra notes, many pieces come together to allow a developer to become productive. Therefore, it takes a persistent, coordinated effort to gather the right context and promote effective collaboration.
