Greg Padak

The name of this talk is "Default to Open," and primarily speaking, this is about transcending organizational silos. This is targeted towards a lot of folks across the spectrum, wherever they may sit in an organization. So this is for practitioners, software developers, line-of-business folks, executives, managers, everybody, really.

It's not overwhelmingly technical, so if you're expecting some practicum-type things, that's not where we're going to be headed with this one. But we will be focusing on software development and the people that are around it.

My name is Greg Padak. I am a GitHub solutions engineer, and I've been at GitHub for a little over a couple of years. Prior to joining GitHub, I was, and still am, a DevOps practitioner. And to me, that's given me several years of experience doing essentially something that I really love.

I like getting into the field. I like getting to talk to a lot of people. I like getting to see a lot of technology challenges. And what this has really afforded me is a very unique perspective on what's going on with businesses of all sizes, their transformations from more traditional software development organizational structures to some more, let's just say, flexible, agile-oriented sorts of systems that they want to take advantage of.

And though I do work for GitHub, GitHub's more than half remote, so we've got some pretty good practice in this endeavor when we're talking about people that are not always co-located with each other. So I'm based in Atlanta. GitHub is based here in San Francisco. And this is a story on how to drive more meaningful development outcomes.

GitHub specifically has a lot of information on this front. We actively help over 70,000 enterprises worldwide build transparent collaboration workflows to further their business objectives. I'm one of the lucky folks who gets to talk with them on a daily basis, and it's a lot of fun to see folks that are engaged in this process while they're doing it.

Now, GitHub is a bit more popular for our open source presence. We're the world's largest source code host, and also open source code host, for that matter. And put another way, we're the world's largest repository for data about software development patterns. So given that we're over 50% remote workforce, we see a lot of advanced practices both at GitHub and then with all the other teams that host their code on GitHub.

Let's talk about a little bit of history real quick. For folks who have been around the DevOps circles for some time, most of us know that back in 2008, there was an Agile conference. Andrew Clay Shafer and Patrick Debois discussed something called Agile infrastructure. And this is a thing that I have found really interesting: applying the development methodologies that started to work really well for software teams to operations and infrastructure challenges.

But the ultimate goal of the DevOps movement was to break down silos between development and operations. And that DevOps term was popularized just a year after the Agile infrastructure discussion.

So now that it's 2016, we're in a place where we can do a little bit of reflection on how things have been going. And pretty well. So we did it. Mission accomplished. We have development and operations folks talking to each other.

But we still have a long way to go. For a lot of enterprises, the silos between Dev and Ops are still putting up a bit of a fight. In the meantime, though, we need to open up some new fronts to go ahead and explore for every organization, because one of the core tenets of the DevOps movement demands that we do so.

We need positive feedback loops that we've been building over the last several years, that are key to driving continuous improvement through iteration, to be very much a part of how we do business.

So that's our focus today. We want more meaningful development outcomes through iteration. At GitHub, we talk about iterating on our product. We talk about iterating on our people, our organization, and that's an extremely healthy way to look at our enterprise.

We also talk about iterating on our office, our HQ building. So that's how we went from having a replica of the Oval Office at the front door to having a cafe where folks can get some coffee, work, get away from their desks, hang out, that sort of thing. And I think we're on HQ release 3.1 at this point. So we've been working on a little bit of everything. And it takes time. It's iteration over time.

This talk is not about directly changing your organizational structure. We have to accept a little bit that the formalized structures that we're used to are not necessarily going to bend and break or change overnight. We want to get around that and transcend those structures. So we're not going to talk about making changes to your direct structural organization. And even if we wanted to make those changes, they'd be less impactful in driving the outcomes that we're looking for than the behavioral areas that we're going to talk about today.

So this is what we're going to focus on. I'm going to talk about some challenges. We're going to talk about some aspirations for outcomes of healthy behaviors. And we're going to go ahead and take a look at some strategies to elicit those behaviors. And if you don't like any of those, we're going to go ahead and take a look at some strategies to completely negate those behaviors.

We're not going to do that. Just kidding. It's going to be great. Trust me.

So let's look at some challenges.

This looks pretty familiar. This is a classic vertical organizational structure. And communication in this structure can be really straightforward. The classic vertical organization was built to allow communication to flow up and down the stack while ensuring that individuals got the attention they need and deserve. We also get a pretty model to know who is accountable for whom and for what, and that can be pretty satisfying on a human level.

Now, it's not without its challenges. From the top down, for instance, things are really clear when you're trying to push the vision down to the folks just below you. You can see each of your direct reports on the way down, and you kind of just get a general feel that things are working out as they should.

When you're on the bottom of one of these very large organizations, though, you do get to hear the message, maybe see it. It could be written somewhere. It could be in an intranet article from two years ago. But it may get a little bit foggy. It takes a little bit of time and effort to make sure this is clear.

So thinking on this from more of a software perspective, developers that depend on the work of other developers can be far away from each other organizationally. As you see here, we're already getting more folks involved in our organization, and we need more people to help manage it. We find ourselves needing to create more and more structures to focus on different areas of responsibility.

Silos begin to form around those responsibility sets. And as organizations group off, they focus on business units, functional areas, geographic groupings. What does that look like for development, IT, and the various business units you might be working with?

The unfortunate outcome of this is that most organizations today struggle with awareness of what's going on between different teams in their enterprise. So two teams end up building a similar solution to the exact same problem more often than you might think. That's lost development time. But how could they have known any differently, right? They just wouldn't have known.

I've had the opportunity to work with a couple of firms, mostly on the East Coast, that could point to specific examples of where this happened to them. In one case, we had two teams of people that had never, ever seen each other. They had never met, and they didn't realize until they had brought all their code onto the same place and started searching for something related to that code that they ended up finding a very similar JavaScript framework that each of those two teams had written to solve the same exact problem.

Yeah. So, whoops.

They had no idea. They would never have known that. Now imagine them coming to the consensus of which one they were going to use after they figured that out. It's a lot of fun having two different competing solutions like that.

So if we look at this organizational structure, we have the developer, the yellow dev, over on the left-hand side. And what if they want to talk to the green dev that's up on the top right? I'm going to have to point these out because it is hard enough to see.

As these orgs get more complex, you may have no idea who to go to for information, or worse, you act without that information that you didn't know you needed. And then possibly even a third choice, you just don't act, because nobody got to you. Nobody got to tell you about that sort of thing that you really need to care about, so you didn't take care of it.

It's pretty chaotic, despite the overall orderly look, knowing what we know now: that we have some problems that are going unanswered.

Information flow gets pretty inefficient as we start thinking about going up and over to these different business units, silos, and whatnot. You rely on folks in management positions to push aside their brutally scheduled lives to make sure that that message that you want to pass their team actually gets to them. And this gets more complicated as communication has to cross business units.

So if this goes more than one or two hops, we're going to have loss. It's just a natural thing. Before you know it, you have an enterprise-grade game of whisper down the lane, which is not going to be super helpful for the outcomes you're looking for.

Now, this is a bit more realistic. This is a much larger organization and probably a little bit closer to what you're looking at. There are about 1,200 people listed on here, and our yellow, green, and purple friends are still on there, which you may not be able to see at the moment.

Just want to ask a quick question, though. How many people are at companies with 1,000 folks or less?

Maybe about half the room. So you get some subset of this, so it might be a little bit easier. But the other half are at a group that's much larger than this, and you just can't spot these folks. It's not that simple.

So unless they somehow find each other, like magic, they may never know that they're working on the exact same problem. It just may never happen. If it does, it's going to be a complete accident, which is pretty awesome, but it doesn't work like that.

Organizational distance between developers directly correlates to bugs and delays, and there's a real cost with that. It presents itself in that bug-and-delay bit, but there's also a chance for outages or security events. This sort of stuff is pretty grave when it gets to a point where we have serious business peril that comes from people not being able to collaborate.

And we've got some other problems, too. Developer churn. Folks can leave a company easier than they ever have before. We're not sticking around at companies like GE for 40 years after we leave school and sticking around until the pension package comes at the end of the retirement line. That's kind of gone. We're dealing with folks that maybe stick around for two to three years, and then they can head off to something else if they think it's a little bit more interesting.

It's super disruptive to employers. And when you're at a large scale, you may not feel like you see it, but ultimately, if folks leave from an important project, they pull from other teams. That costs effectiveness on that team to try and satisfy what is viewed as a mission-critical need.

Good enough solutions. So these are fun, and they're cheap. But they may not do what they need to do to get people excited about what they're doing at their job.

Managers have to make hard budget decisions with a lot of rules. A lot of rules, a lot of oversight. It's from their own leadership, maybe procurement teams. There's a lot of external influences that are coming after them. And when solutions come with dollar signs, it makes things a little bit more difficult.

So oftentimes, we practitioners are forced into these "good enough" solution situations. It may get the job done, but it can quickly turn into something like a broken windows sort of deal.

A good enough solution: I'm going to script my deployment process because I don't have an orchestration tool that I can afford. There are plenty of orchestration tools out there, but I can't buy one because I don't have money.

We want to use email distribution as a way to notify people instead of going through another tool that's designed to handle communication in batches based on some purpose. We're working around this. We're trying our best, but it's just good enough.

The broken windows that occur when people have to maintain this thing, it directly affects team morale. And it isn't just about tooling either. This could be about compensation and recognition as well.

So this is the question that you should be asking yourself. The numbers are easy to play with. Did it kind of for math. It's nice to be able to move the percentage point up and down a little bit. But how much are you willing to pay for a productivity increase for expensive resources?

People are usually the most expensive line item on any business' cost sheet. It's an unfortunate reality. That is a reality. But they're also the difference-making soul of your company. So investing in tools to give them an edge amplifies your competitive advantage.

1% may not be worth spending a certain amount of money, but you want to go after tools that get people to a 20%, 50%, 100% increase in productivity. And then you have to figure, if those folks are taking down a pretty decent salary, you're going to want to make some kind of investment monetarily to augment their capability set.

So those are the challenges. I know, just a few. Only a couple challenges, no big deal. Should be pretty easy to overcome. We'll get through that.

The desired behaviors and outcomes that we're looking for are going to be the sort of things that you would like to see. These are good indicators that you're attacking these challenges head-on. That you're arriving at the right conclusions in terms of how you can overcome organizational structures and how you can go ahead and make sure that your software development process is really kicking on all cylinders.

Here are the three primary behaviors, and they're kind of grand, a little bit general, but we're going to get into that. We're going to talk about immersion into the workflow, some voluntary information disclosure, because telling people to tell people things isn't a lot of fun. And finally, we'll take a look at context creation and awareness.

When you're immersed into a workflow, you don't really feel it around you. You become insulated from blockers and speed bumps, and you just kind of execute. It's really straightforward when you're feeling deep into this immersion. This is something we all want, but it can be really hard to get.

When things are going well, we ship small changes, very small changes. These changes include documentation. They include tests, some other ancillary work, things that don't necessarily seem like they're the most important order of the day. But it works extremely well with a no-broken-windows philosophy, where you're trying to keep morale high and continue shipping and continue meeting needs.

These small changes need to be able to stand on their own and be deployable outside of your Agile process or your SAFe process, that sort of thing. Do not let systems like Agile and SAFe hold you back from incremental improvements in your software ecosystem. Just don't let it happen. If you want to have a small change that goes on its own and stands on its own, you should. And you should break outside of those molds where it makes sense.

Might be a no-brainer at this point, but you want to be using CI/CD systems. But there's some caveats to that. You want to use CI systems that accept webhook events from upstream systems. Believe it or not, there is such a thing as getting CI wrong.

What happens? It is completely possible to misuse continuous integration. How many folks have done a DoS attack on their SCM system?

Definitely guilty. Go ahead. Do you know somebody who has? How many of you did it to GitHub?

I can find out if you're lying.

Do not fall into a couple of traps. These traps are polling, constantly reaching out to your SCM system every five minutes, maybe every 10 minutes, for new changes.

Don't get into the nightly builds trap. Nightly builds were state-of-the-art at one point. It was the coolest thing. We did all this work all day, our CI system ran while we were sleeping, and when we came back, our QA team had this perfect new, fresh build of the code that they could start working on today.

But that's kind of a trap at this point. We can now get to a point where a development event, a software developer pushes code, a certain thing happens with a testing framework, somebody opens a new issue, somebody opens a pull request on GitHub, and that is the key to what creates the software build that runs your automated test suite that injects that data back into where your decisions are being made. That's the behavior we're looking for.

And ultimately, this is all about friction. High-friction environments cause workarounds, hacky solutions to be put together, and even worse, avoidance of other people that you're working with on a daily basis. And those people are all involved together in the creation process.

So when the pressure gets high, and it always does, especially maybe around the holidays if you're trying to ship some new code to handle a specific market rush, when the pressure mounts, emotions can start to get the better of people. And it really, really hurts when there's high friction. It can really boil over.

What we want is low-friction environments with less interrupts and well-tuned tooling. People will thrive in that kind of environment. And the benefits not only include positive emotional responses about their work and who they work with, but you'll see active participation and a willingness for people to take ownership of both problems and opportunities alike.

This is what a bad workflow looks like. This is an example developer calendar when they're getting inundated with meetings. And honestly, I'm sure some people probably have had it worse. I know I've been in a place where that's just filled in completely.

When we're finding bugs, we're finding it during our highly synchronous code reviews or during a QA process. We do code reviews once a week maybe. And our deployment structure is around when operations or project management says it's okay. That's not going to help your developers and their esteem about how things are going.

This also increases technical debt. And it also drives extra stress on people. None of this is good.

You want something like this. This is way better. Maybe a 9:00 a.m. standup, maybe some training every once in a while, a nice little review of how releases are done. Not everybody's going to keep the sheet this clean, but it's a good aspiration. Creators need room and time to think. That's the important takeaway here.

Let's talk a little bit about context and awareness. This behavior is about increasing agency for your developers. And when I say agency, I mean the freedom to act, the freedom to know and to act, and to not necessarily have to have oversight or approval to take an action that you believe to be good for the business.

When developers, and really practitioners across the entire spectrum, have agency, there's a positive tone change for how folks interact with each other. Uninformed contributors can be combative when they feel left out. Informed contributors are fully weaponized product makers.

Coordination and trouble tickets, issues, however you want to interact with folks, you want to see direct mentions of teams and people to get experts in on the conversation at the right time with the right context.

So I want to reach out to a team that knows exactly what's going on when I need them. When I'm ready to get to a point where I'm going to deploy something in production and I just need one check, I want to be able to go to the experts that are going to give me that feel-good approval that we're ready to rock.

But up until that time, I had the agency to develop whatever I saw fit to meet the needs of the business. That's what we want to see.

Few groups do this better than the Electron team. Electron is a GitHub-owned JavaScript framework that allows people to develop cross-platform applications in the web. We have some folks at GitHub that work here, but really it's the open source community that makes this strong.

Their repository READMEs are some of the best I've ever seen in the business, really. And if that wasn't enough, they ship a website that stands on its own as a great overview of their project and how you can get started. If you haven't worked with Electron before, just go ahead and check them out on GitHub. I've got the top-end website that you can hit to go ahead and navigate on over there. And there's even better stuff inside than what I'm just showing here.

The takeaway here is that agency plus contextual awareness makes developers better and bolder. And that allows these folks to maximize the potential impact they can have on your business.

Okay, voluntary information disclosure. Well-informed people are the key to building better software together. You know you've done your job right as executives, managers, leaders of teams, when folks share what they've learned about something without ever being asked to do so. This should be happening all the time.

This is also what I call institutional glue. This is a very feel-good, outside-of-your-general-job-function sort of deal that happens when folks have the agency to act outside of their job function.

As a software developer, I may be paid to write software. But at the same time, it might behoove me to step out of that role and talk to some folks in operations. A very common DevOps philosophy: that we're going to go ahead and talk to folks about how our entire application is going to look out in the production stack.

Maybe I have some opinions about the database structure, how much RAM is being directed to it, if we put this thing on software-accelerated storage or not. As a developer, I might have some opinions there, but I'm not explicitly paid to have opinions there. We want folks to reach outside and go ahead and volunteer the information they have about this. And if they learn something new while they're working with that other team, they need to be bringing that back to where they usually work from day to day and share that with their teammates.

It's hard to automate. You're probably not going to automate this. But people will inherently act in the best interest of creating context for others if they have the access to that sort of information.

All three of these behaviors working together create happy and productive developers, practitioners, IT specialists, project managers, everybody in your business. And there are a lot of positive business outcomes that come with it.

Agility: you become a more responsive business. Your quality of your code and your product increases. You'll find bugs early in the process, reduce your delays to your deliverables. And you'll retain talent more so than you may have in the past.

When you have happy, productive developers, they want their friends to come be happy with them, right? Not everybody's happy. Not every business has mastered this. When you bring your happy friends to your company, it's a massive boon to recruitment in addition to retention.

So happy developers ultimately equals better software and stronger business outcomes.

That sounds great, right? All the behaviors that we want to see, hard to attain necessarily. But what I want to do with the remaining time of this talk, we've got about 25 minutes or so. Maybe we'll finish up a little early if we get lucky here.

I want to show you some strategies that you can use to help create these behaviors and to help solve the challenges that we know we have in large businesses.

This first one's a bit of a requirement. We need to buy into this process in order for the additional strategies to be worth it. So we need to invest. We need to invest in a single platform for collaboration and coordination.

Now, I do want to talk about this tool concept very briefly, but I also want to take an aside for a second and say that the DevOps movement as a whole has focused an awful lot on tools lately. And I mean over the past few years. We've got a tool for everything right now. We've got several tools for everything right now.

And I still believe that the most important part of this whole thing is about people and process, not necessarily the tooling. That being said, we need to acknowledge that adding tools does not directly change culture. But it will offer the opportunity for you to change culture if you follow up with what you need to do for your people and your process.

So to do that today, you need one platform to standardize on that allows for collaboration and coordination. This is table stakes now. This is absolutely important to achieve more meaningful development outcomes in a modern software environment.

Everyone in the enterprise needs a seat at this table, and that table needs to be an open and inclusive environment, a very thoughtful environment where we want to solicit the opinions of others.

Being technical isn't a skill set. It's absolutely a mindset. And when you're exposed to a platform in this manner, everybody starts to speak the software language together.

The first thing this platform needs to be is ridiculously extensible. And I'm not trying to exaggerate. I'm really not. But a platform needs to have this type of extensibility because it's going to be at the core of everything you're doing in your software business. Everything you want to accomplish is going to rely on what this platform does at the center of your system.

So to prevent yourself from being a victim of vendor lock-in or anything like that, you need your platform to integrate with every possible tool out there. And when looking for integrations, you want to stick to the best-of-breed tooling that injects useful information back into the platform, which creates yet another positive feedback loop that we can keep feeding.

Additionally, you want to give your people the freedom to experiment with more tools without locking them into one. You can set up very happy paths for people to follow, but you also need to allow for the additional room for folks to experiment. This is an absolute necessity, and it can only be done if you have an extensible platform.

So here's some examples. I want to qualify this a little bit, what ridiculous extensibility means. As an example, up on the top left, I want to use the Stripe API as a great call-out for what it means to be doing this right. It provides a magnificent experience for developers that interact with it.

Has anybody implemented Stripe API into one of their applications?

A few. You want to check this out. Even if you don't plan on using it, check out their API docs because I think you're going to get a feel for that kind of thing that you want to expect from these folks.

An additional good example here is GitHub's integrations directory. GitHub is pretty well known for its own extensibility, but between the API and the pioneering work that we did on webhooks, this relatively new integrations directory has positioned our platform to allow maximum experimentation with tools that add value to every step of the software creation process.

In a sense, ridiculous extensibility means you welcome all comers, and you make it easy to make something special out of your data and your source code.

The next thing we need is the ability to create teams ad hoc, and we need this to not be tied to our LDAP or our AD groups. We don't want to reach out to an ops team to say, "We need to build these specific teams now, and we need to get a distro list. And can we make it this specific thing that's going to read out to this specific OU or a specific DN that's going to work out so that I can understand what it is every time?"

We don't want that. We want to be able to do this dynamically. We want team creation to be more of a fluid concept because teams are going to change their structure pretty regularly in this type of world. We'll give some more examples on that in a bit.

Project creation is another bit. So excuse me for the physics joke, but we want project creation to be incredibly frictionless, right? Focus, clarity, and coordination for a particular set of activities needs to be lightweight.

In a lot of IT cultures today, project creation is extremely expensive, and here's an example. You're hanging out with your friends, your colleagues. You're talking in the hallway about a particular outcome you're looking to deliver, maybe some software you want to write, something that's going to solve a problem, scratch an itch you've had for a long time. And somebody says, "We need a project for this."

So what does that mean? How much do you have to do to create a project at your company today? The question is, where can we get together quickly to do some work?

A project doesn't have to be tied to a line item in a budget. It can be as simple as a handful of people that whimsically tried to find a way to do something just for the greater good of the company. It didn't come from some mission on high. It came from a quality-of-life improvement desire that folks just came upon, out of pure happenstance.

This happens all the time. To use an example of GitHub, we had an effort to bring back Hack Weeks. We used to do Hack Weeks back in the day. It was kind of a thing that we were really happy about, ancient times in GitHub, which is like four years ago.

We used to use Hack Weeks to build up a couple of additional features around our platform, because they were things that we were interested in that didn't have to do with our general business needs. Recently, we brought back Hack Weeks, and we ended up coming up with things like contributor badges.

So contributor badges are just a nice little additional way to identify a given user, and we deployed it to the site a week after that. And then the next thing you know, we got organizations like Mapbox that are using them.

Back to the project thing a little bit. One last bit that you need for a project is a way to visualize it easily. Not everybody is going to be able to engross themselves in the project and just kind of follow it along in their own minds. They might need a way to see it, some sort of artistic creation of what's going on here. You need to be able to visualize your progress easily.

This is an example of what's going on with Mapbox's Native OpenGL renderer. Does everybody know what Mapbox does? They take GeoJSON data, and they plot it on some maps. It kind of looks a lot like Apple Maps, Google Maps, that sort of thing. Super helpful tool. We use it to render our GeoJSON on our site.

And it's definitely a good set of projects to check out if you're looking for folks that are using these practices that we're talking about today very well.

Another thing, this might seem a bit obvious, but I feel compelled to mention it just the same. You need to get source code interaction and documentation for your projects in the same place. This is all about that context creation and awareness, and the opportunities for folks to find information and share it with others. And there's going to be a good example of that later as well.

So we made it to the title of the talk. We want you to default to openness. This is a strategy that has been proven to pay off over and over again with every single business that I've talked to, every single business that GitHub has talked to.

When folks buy into the idea that they need to have things in a much more open and inclusive environment, then we're going to be in much better shape as it comes for folks that act with agency for the better of the business without being told.

We've got our platform. That's a definite requirement. And I really wish you could say that we just push everything up to GitHub, we're just going to choose that, and we just wrap up this talk, we all head out of here, take a nice little break. But it's not that simple.

We still need a little bit of extra help, some additional strategies to help us get this to a point where those behaviors aren't just an accident, like a happy accident, Bob Ross style. That doesn't happen in real life.

So I want to give you another example of where openness is somewhat counterintuitive. I have some friends at a very large enterprise in Atlanta, and stop me if you've heard this one before, but they made some headlines in the last couple of years, and it was a bit of a security issue.

They were working through this whole security bit, and they resisted the urge to lock everything down. That's a very natural thing. We have a security problem. We need to shut out access for everyone completely until we get to the bottom of this thing.

But they didn't do that. They resisted that urge. Instead, they wanted to open things up even more to more people. And why did they do that? Does anybody want to take a guess as to why they thought this was a good idea?

To get help.

What, to get help? Pretty much, right? So they felt if there were more eyes on the code, if there were more eyes in their process just open to it, that they never would have made the news in the first place. And we've seen this play out a number of times since I've been at GitHub when talking to very large customers.

So this looks a bit familiar from earlier. I want you to pay special attention this time to how diverse this group is and what effect they could have when they're dialed into your software development process.

What if your security team was plugged into what's happening with a feature that handles PII as it's being created or updated? Maybe patient information if you're dealing with healthcare. Maybe this is something around some compliance issues.

Now, sometimes we can't let everybody see all this stuff, and I understand that. So if you got your Coca-Cola vault or something like that, and you want to keep folks out, I totally get it, and I support it. I still recommend that your secret sauce be stored somewhere in a repository with tightly scoped access.

Let everybody see everything? Very close.

So how approachable is your team and its mission? Ideally, you write everything down. You keep it close to your code. When you're writing everything down, you also need to write with a voice that understands that not every person is an expert in the challenge that you're working on.

Here's a great example. This is the Atom text editor. Within their organization structure and how they've brought their repositories out, the top three repositories they want to point you to: the core project itself, the flight manual, the documentation, and then the website where all of this is packaged up and hosted, and where you can download the project. So you can get at everything right here.

This is an open source example, but think about bringing this inside your own enterprise. So if you want to inner source this sort of thing, you can take projects inside of your own company, expose them to the rest of your company, but you have to do it in a way that when they come and find it, that they can actually see what's going on.

And when they get invested, when they come and work with you, they're going to be able to act a lot quicker. They're going to get engaged immediately, and they don't have to call anybody up to ask how this thing works. They don't have to email you. They just read the docs. And if they don't like the docs, pull requests are welcome.

Let's talk a little bit about discoverability. Access to what's going on elsewhere in the organization increases the quality of activity.

A lot of folks get really wound up in having a lot of activity. If developers are writing a lot of code, that must mean it's good for the code. Well, that's not really true. More time writing code does not equal better code. More time writing tests does not equal better tests. And I should probably spend more time writing tests.

More time invested in how operations works doesn't make your operations work better. It's not one for the other. It doesn't work quite like that.

Higher quality activity improves these sorts of relationships. Higher quality activity doesn't have to happen all the time. Higher quality activity saves you time in the process. And this isn't a bad thing, but there are some important considerations in how you discover these ideals so that you can have that higher quality activity.

You need to be able to search everything from one place. When your repositories and projects have open visibility, people across the entire enterprise can find them when they're searching the platform. A great search index that ties everything together is an absolute requirement for discoverability, but you need to be able to focus the scope as well, so you can find something actionable.

It's super important, super important, that everybody in your enterprise, regardless of their role, knows how to search well, knows how to focus what they're looking for.

Here's an example of what we've done with an internal product. We have a search API at GitHub, and we plug the search API into a search portal, essentially, which is the place where all of our employees come in and take a look at what they're trying to find to be a better GitHubber.

This product is called GitHubber, and this is how GitHub employees find pretty much everything. Everything you could ever want to know about GitHub.

And as you can tell, when we go through this process, say I want to learn a little bit about how enterprise support works with our customers. Well, these articles are just GitHub-backed repositories that we were able to find because we exposed the search API here.

Now, this could have been done by pure happenstance, but just by the very minimum of what I was looking to find, I was able to bring up this whole nice little bit.

So your enterprise has this data. I can guarantee you somebody is already writing a lot of things down. Being able to put a nice search engine on top of it, to be able to pull that data out when you're looking for it, is going to be super key.

Okay. So we're going to blow through some really fun stuff here. This is the best part of what I like to talk about, and this is all about informal organizations.

The formal organization is that structure that I showed you before, where we've got that top-down bit. Informal organizations, they're generally leaderless. We don't have to look to any one person to lead us, to tell us that we're doing it right, to tell us what we're accountable for, to measure us during our progress review.

Informal organizations are extremely powerful. And it comes back to that whole team creation aspect that I mentioned before.

So at GitHub, Team Pizza Penguin is working on a specific problem, and it happens to be written in JavaScript. Well, we might have a serious JavaScript problem, and we have a couple hundred other JavaScript devs in the house. That might be an exaggeration. We have at least 50 other JavaScript devs in the house.

But how do we get to those people? We can't just ask their boss. I mean, we could, but it may not work. We want to be able to notify all the JavaScript devs with a direct @mention in the context where it's relevant. They're the experts. We have a problem. We need them now if we want to deploy tomorrow.

So here's how the ad hoc teams work. We've got these different organizational units. Maybe we've got a cross-organizational JavaScript dev team. Maybe we have a security team that goes across these different organizational elements, different security specialties. Maybe we have a group that's focused on our SQL databases.

A lot of folks are very interested, very skilled, and very capable, but they may not hold the role of DBA.

This person here may report to this specific group, be a part of the security and SQL teams. So we give a mention to a specific security event that we want to make sure that we want to take care of, or we may just want to reference someone to say, "Hey, are there any security loopholes with what we're going on here?"

Maybe it's a total double hit, and this person's looking for a database security loophole, which looks like it's right in their wheelhouse based on where they're sitting right here in this informal organization. But you wouldn't have found them by going to their normal, formal organizational role. You just would not have found this person.

This individual is part of the JavaScript devs and SQL teams. They're dangerously close to being a full stack developer. So we've got somebody that is going to be able to help with our front-end development as it's reaching into our database layer.

That's an extremely powerful person to talk to when we have an issue about maybe increasing performance, pulling data out into our front end for our end users.

Think of this as like a matrixed organization, but without all of that dotted line stuff that clouds reporting structures, priorities, who answers to whom, that sort of thing.

We want to leave no one out when it matters the most. You do not know who the person is going to be to come and save the day when you have a serious problem. No matter your skill set, your specialty, there is a way, and likely a need, to find you and solicit your opinion.

If you're the person that I need, if I have a problem this afternoon that only one of you in this room can solve, I don't know which one of you that is. But I'm going to hope that if I reach out for that informal team that I'm looking for, that you answer the call. And I think you will. I think you will when we organize this way, because it's what's right for the business. It's what's right for the folks that you're invested in this whole thing with.

Let's talk about another practice: team radars. And I'm going to say something a little controversial, maybe. I think, personally, that daily standups have had their time in the sun.

Scrum, standups, that very Agile Manifesto-ish kind of thing that we've got going on, they've done a really great job at getting people focused on their projects every day. They've been pretty key to helping folks pull off Agile transformations coming out of that traditional waterfall model.

But they should not be an everlasting component of how you do business.

Instead, I'm suggesting an alternative. I'm suggesting using team radars. Team radars are time-boxed threads where folks show up asynchronously and report their status, their blockers, everything that's going on there.

So if the blockers go on the radar when people are blocked in an asynchronous fashion, we might even accompany that with direct messages to folks that we think can help us get past the block, those heroes in the room that I was talking about before.

When you have daily standups, you may save the disclosure of that blocker until tomorrow. So it's 3:00 p.m., I'm stuck. But it's 3:00 p.m. I can't just go around and start talking to people and hope that the person that's going to solve my blocker shows up here.

But instead, with the asynchronous format, we can just go ahead and place it on the radar, and we don't have to wait until tomorrow's standup.

We wait until tomorrow with the standup process because that's when everyone will be there, so I have a good chance of getting my problem resolved. But that's just the problem there. If everybody is at the daily standup, then they're not doing something more important somewhere else.

You get some bonuses, too. How many folks have a team that spans time zones?

Wow, that's like everybody. All right. So imagine how difficult it can be to get all of those folks together. With something that's a bit more asynchronous, we don't have the need to put that at a time that works for everyone but is inconvenient for everyone.

So we may bend over backwards to make sure that we're up late after dinner to talk with the folks in our Asia-Pac office, or something like that. But they're also probably getting up super early to accommodate that for us. So everybody loses when we're trying to find a time that works with everyone.

If your team spans different time zones, then your Scrums and standups might be at a time that works for everybody, but it's super inconvenient.

Radars are great for other things. We can cross-link interesting information. This is a focal point where that voluntary information disclosure behavior comes out.

So for me, at GitHub, I have this responsibility to work with our product and engineering teams to figure out what's coming that our customers and end users need to know about eventually, maybe the next GitHub Enterprise release, for instance.

There are formal ways to do this. I could write something up, publish it, announce it to the whole team, tell the company that I did a thing. Or when things start to get interesting, I can report those to those informal orgs, bring it back to the team radar, @mention folks that I think might be interesting.

I love to invite my teammates to go check out information for themselves and see our engineering teams in action. The benefits to context creation, awareness, and immersion are incredibly massive here.

So let's get away from radars. Let's talk a little bit about chat. Chat's a big deal. And I just want to ask, who uses some sort of chat client, server, something or another right now?

Good. All right, cool. I can just stop doing this part.

Chat's a wonderful tool. But if you think about it, going back in the day, you probably used chat when you had your AOL subscription. That was middle school for me. And then I discovered mIRC after that. And I'm pretty sure, if I think about it, the first bit of software I ever wrote was a script to tell people how I was wasting my summer on mIRC. Hopping on a video game or something like that. It's a total waste, right?

But the important thing is that chat rooms are cheap. And modern interpretations of chat, well past the mIRC deal, even though they're based on the same underlying technology, look more like Slack, for instance, which are super focused on platform-oriented behavior, which is something that we've already discussed is super important.

So you remember that ridiculous extensibility thing? You can get some of that with your chat system, too. You don't have to just get it from your unified platform. You want to integrate your chat system with your platform.

The potential for adding to that feedback loop with your platform gets even better with this. So now it can have another type of asynchronous communication in full view of all your peers that are interested in a specific team or project scope.

When you have a great discussion in chat, you can just link that back to your platform, maybe to your team radar, especially where it's relevant to your code. So maybe to the team radar, maybe to your active project, a given pull request, an issue. And then the folks that weren't there, they can go back and relive that discussion with just one click.

So here are some examples. In our chat rooms, we show Git and GitHub data, as well as using scripting to get an idea of who and what needs our attention. We can see what's going on with our repository. We can see who @mentioned us, a specific team recently.

And what I really want to impress upon you is that you really need to take ChatOps for a spin.

Does anybody use some form of ChatOps? Do we know what that means?

We got a few hands. The idea is really super simple at its core. You write scripts that could be called from a chat room that allow activities to take place and report their outcomes in the full view of all your teammates.

So this concept is getting more and more popular over time. GitHub was one of the first groups on the scene when we open sourced Hubot, our robot overlord over at the GitHub office. And Hubot does a lot for us. I mean, we have to ask him to sometimes, but he's not always that nice.

But we get interesting information, like deployment results, build results, we can put in front of our whole team to see and possibly react to. Imagine a failed deployment for some reason, when we have a room with 80 of our closest colleagues that are super interested in what's happening with that specific application that was just deployed.

They're able to act right away. They see it just at the same time that I do, or maybe when they come back from what they were working on.

But we have ChatOps for everything. It's a little tough to see, but what I can tell you about this is that this doesn't have to be technical sort of stuff. Anybody can access this.

The power of ChatOps is that you get simple information, and you can get complex information. You get whatever you really want to solve for. So we can look up the address of the office. We can look up diagrams for our architecture.

We can even just ask, "Where can I deploy this application?" Just to give some sort of feedback on what rooms we're allowed to run the deployment command for. Is production unlocked? Is dev unlocked? Can we go ahead and use that environment now to test our new feature?

So ChatOps is for everybody. Everyone and everything that you can do.

Okay. So we did it. And I'm hoping that if I've done my job today in giving you some concrete takeaways, that you're going to be able to turn some of this stuff into interesting information that you can impart to folks at your company that didn't make it out here.

When you default to open, you can drive more meaningful development outcomes for you and yours at home. The one thing that I want everybody to remember is that visibility is everything. Access to information is everything. When it's tied down to certain individuals and they're hoarding that information, it's bad for everyone. Everyone loses.

When we have access to this for everyone, and it's completely equitable, folks will do the right thing. They'll share. They'll share that information. I firmly believe that.

So I just want to thank everybody for coming. I know you had your choices of talks today, so I really appreciate you coming out and hanging out with me for a little bit.

Once we're done here, I'm going to go ahead and post up these slides. I am gpanik on GitHub, testinginprod on Twitter. We have all of seven minutes to grab some questions from the floor if we want to do that real quick. And once that's done, we'll have some folks, my colleague, Aaron, my friend Aaron, will be in the back scanning some badges and all that stuff.

So feel free to hit me up either outside the room or back at the GitHub booth on the show floor.

So thank you, everyone.

Q&A

Questions.

Cool. All right. We have a question. Awesome.

Q: So you talked about team radar a little bit.

A: Yeah.

Q: Do you have any good templates for that or any examples? It looks like it was just in an issue, or is there more formal support from it from GitHub or GitHub Enterprise?

A: So, with GitHub Enterprise, and GitHub both, we do have the ability to set up templates just for issues in general. Another nice thing that we have the ability to do, which isn't super publicized, is that you can URL encode what goes into an issue when you open it.

So we can create a just one-time URL that you place at the top of your README, says "Create Radar." And that's going to populate out with something that you think is ideal for that sort of deal.

Now what we do internally, we've turned this to another level and scripted up what we want to pull from to be our basis for what we know about our issues, our projects, our pull requests that are open, what needs to be reviewed, who's traveling.

And we've done that by taking APIs from Google Calendar, GitHub APIs. We've pulled from some other systems, like maybe Salesforce or something like that, to report back on interesting information that we care about. And then we go around the horn for everybody to put down checklists of what they plan to accomplish.

As the week goes by, folks are able to update their progress just by checking boxes or posting back to this whole deal. So in terms of templates, I think I can help point you to some stuff. We don't have an open source repository or anything saying, "Here's how radars work."

Got one back there.

Q: So with radar, what are some of the challenges that you've had?

A: Since we started using radars?

Q: Yes. Radar, sorry.

A: Well, the first challenge was that we didn't know people were going to really enjoy using it. So we put out a really awful first implementation of this, and we ended up tying it around somebody's specific username, so it was their whole chatbot sort of thing that plugged in this deal before. And we didn't really have a standard.

And what happened is other teams started seeing what we were doing. They wanted to get at it too. So one of the biggest challenges that we had was, how do we productize this thing, kind of like the other gentleman had been asking, to the point that we could give it to other folks, and also build the practices around it?

The other problem that I personally have had is that even though we've put all of this interesting information into a given radar, so this week might've been a really interesting week. I could say that I met this gentleman at DevOps Enterprise Summit. We had a really great talk. Here's a write-up of it. Post it to that radar.

But if you don't then take the interesting data from the radar and put it somewhere else for it to live on forever, then the only way you get at it is by luckily searching for that, and bringing that issue back up in that exact context. So it's a little difficult to get at after the fact.

Some level of curation after the radar has been closed and you've moved on to the next week is definitely something that's helped us since then that folks probably wouldn't come up with on day one.

Aziz: Can I add to that one?

Greg Padak: Sure, yeah.

Aziz: I'd say, make sure...

Oh, okay. Just going to add to what Greg said. This is Aziz, by the way. I work with him.

Hi, everyone. Aziz. I work at GitHub with Greg.

One of the things that you have to realize is that these things change. Radars, whatever you think is going to be great for your team of five people isn't going to be great for a team of 35 people. So just keep it healthily dynamic, flexible.

Just have somebody that cares about it to write the software or keep it up to date, and just be flexible. And to Greg's point that he made earlier, just default to openness. Make sure that more people can see it than less.

Greg Padak: Cool. Any other questions?

Got one over here. Gentleman in the blue. Yeah.

Q: When's GitHubber going to be available to everyone?

Greg Padak: So we have a product team that can answer that. We don't have any plans to productize GitHubber specifically. But if you wanted to do something like it, the biggest key to that tool is the extension upon our internal systems.

So we went through a process of curating what systems need to be exposed to this application and made sure that those were all reachable via our OAuth relationship to what we can do to go see these bits and bytes. So I think, does Hubot own the OAuth token for GitHubber? Probably.

Aziz: Probably, yeah. GitHubber's a Rails app. It just pulls content from GitHub repos.

Greg Padak: The concept is the important part.

Aziz: Yeah.

Greg Padak: That you can build a web portal that pulls down data from just about anywhere that's platform oriented. So it's all in that one place, and you can expose it to folks that don't necessarily have access to all these things or are used to using each of those tools.

Aziz: There are lots of documentation, deployment, web technologies that are available for people. In large enterprises, you may have a few running. The key we find isn't necessarily the technology that lets you go, other than having a great search engine.

The technology is less important than where the content lives, and the content is somewhere where people can contribute to it, again, in an open manner. All those articles have an owner associated with them that's visible not only in the article, but inside of the repository itself.

So if we want to propose a change to...

Greg Padak: Expense policy or something.

Aziz: ...the expense policy or a conference benefit or something like that, we can open a pull request and talk about it, and say, "Hey, you own this. Do you have an opinion, because you're the person whose name is on it?"

And then usually they'll pull in other people, like, "Oh, well, you need finance people to come look at our expense policy changes," if it's a little too hard for somebody to submit opinion.

Greg Padak: This is how we ended up with expense automation, literally having this conversation.

Aziz: Right. So the power isn't in the application GitHubber. The power is in the platform that it serves and the process that we've built around how we maintain the content within it, really, at the end of the day.

Greg Padak: But no, we're not planning on shipping it as a product necessarily. Not today, at least.

Any other questions?

Cool. We got, like, 18 seconds anyway, so we've got to get out of here. So again, thank you, everybody, for coming. Really appreciate it. See you all around on the show floor.