Stack Overflow & InnerSource (Part 2)
This is the second in a series of posts about how an internal Stack Overflow Q&A will complement your organization’s efforts to InnerSource. Read the first part here.
Recognizing the core values of an InnerSource strategy as transparency, sharing, meritocracy, trust, self-organization and empowerment, let’s talk about the damaging effects of information silos, tribal knowledge and reliance on SMEs.
Know Your Audience
Before you attempt to influence your company’s internal culture, it’s helpful to remind yourself that software developers are inquisitive and inspired builders that want to both learn and teach. In seeking to understand the root cause of an issue, developers will ask peers if they’ve had a similar issue, collaborate on a fix, and hope to preserve that solution for future users so that work isn’t redone. This oversimplified workflow is why GitHub and Stack Overflow are such vital platforms for the developer community.
Developers also love to explore this creativity outside of their day-to-day responsibilities at work. It’s one of the reasons that Larry Page and Sergey Brin instituted Google’s 80/20 policy, which grants its employees 20% percent time for side projects in order to unlock enterprise-wide creativity and innovation. They recognized that if they’re not empowering their developers who may be bored within the confines of their direct assignment to work on projects that they take interest in, the result will be developers that can feel like their time is being wasted. In turn, they’ll seek out new challenges. These side projects almost always adhere to open source principles.
The Danger of Information Silos
We’re in this position constantly: we’re in a bind so, in order to get out of it as quickly as possible, we email a colleague or crane our neck over to them if they sit close, ask the question and blindly trust that the answer we receive is accurate. Or, we pass a colleague in the coffee bar, spark up a conversation with, “oh hey, I’ve been meaning to ask you…”. Ten minutes later, we’ve not only resolved the issue at hand, but likely have continued a discussion that could have an effect on the project or product long term. Or, we’re in a Slack channel with our immediate peers banging back and forth questions to each other and, a month later, we realize that it’s the only channel we go to when we need to find an answer.
In large organizations that need to move fast in order to innovate and stay ahead of their industry peers, the information silos that keep knowledge within one group of people are incredibly detrimental. In the same coffee bar conversation (replace this with any form of ephemeral chat), only two people benefit from the knowledge exchange and you can argue that its really just one person (the asker), while taking precious time from the other (the answerer), with zero benefit to anyone outside of this duo.
Reliance on SMEs
Put yourself in the shoes of an SME. You know a certain topic like the back of your hand and, like the student who paid attention all semester, you’re suddenly the most popular kid in class when someone has a question related to what you know well. Colleagues come out of the woodwork to ask for an explanation on something that they don’t understand, Slack messages pile up, email threads eagerly wait for you to chime in, and you’re now expected by management to spend three hours of your day drafting up a Wiki on the topic. Oh, and make sure that you update the Wiki every time something changes because, if the information becomes stale or doesn’t help someone solve their issue, here they come again asking for updates.
Taking it a step further, reliance on SMEs simply doesn’t scale in a large organization. Even if you’ve been one place for your entire career, you can’t possibly know everyone there and what their expertise is. There are surely smart people in other parts of the organization doing similar work that you don’t know exist. Even if you do happen to know them, there’s likely no way to get access to that work or knowledge. On the flip side, new employees don’t know anyone and therefore have no one to ask! This slows their onboarding and affords them little contextual understanding of what’s happened prior to them joining.
When you consider the drag on an individual’s productivity that relying on SMEs causes, it begs the question: wouldn’t it make more sense to answer your peers’ questions once, let others chime in to validate that your answer is objectively accurate and unbiased, then put that answer into an easily searchable format for the next person who has the same question?
If you’re managing a team, leading a product group, or overseeing your company’s entire technical direction, your primary goal should be to empower your developers to be more productive. It’s certainly on the minds of the C-suite, as 96% say its a high priority for them to increase the productivity of their developers. By doing nothing to knock down these information silos to create a flatter, more transparent knowledge architecture, organizations are blatantly ignoring the needs of its most valuable employees. In doing so, echo chambers form, your developers become frustrated by lacking access to the smart people that exist in other parts of the org, tribal knowledge builds up and, all of a sudden, you’re fostering a toxic culture that impacts morale, retention and recruiting.
This is the second of a series of posts about how an internal Stack Overflow Q&A will complement your organization’s efforts to InnerSource. Finally, I’ll discuss how implementing an internal Stack Overflow Q&A will help your organization break down information silos, encourage internal collaboration and foster a stronger development culture.
