Be the 1 to Put Skin in the Game – 2

This post is the second part of this series. Click here for the first post.

Sharing Knowledge

It is possibly the greatest irony of the IT industry that we are experts at technology which manages information, yet, we tend to manage information so poorly ourselves. As a government employee, I was subjected to the horrors of SharePoint. Microsoft’s platform is the outcome of a forbidden affair between a compiler and a Swiss-Army Knife that resulted in a piece of software trying to do everything but doing none of it well. The agency I worked for tried to use SharePoint for the following:

• File-sharing — works great until you start working with large files
• Code version control — an epic fail
• Peer reviews — would be great if you could leave annotations/notes on files without first locking them and then using an Office application
• Task/workflow management — mediocre outcome at best
• Process documentation — works fine if you can find what you’re looking for
• Project management — normally consisted of storing MS Project files, not a good fit.
• Team websites — might work okay if the wiki wasn’t trash
• Form processing — would be fine if building new forms with validations wasn’t a nightmare
• Meeting scheduling — Why? Just why?
• Room scheduling — see above…
• Performance reviews — Again, why?
• Requirements Gathering — Works well for storing requirements, not so well for gathering.

Apart from the first three items (for which there clearly are better-suited tools), the remaining all have one thing in common: they attempt to codify human interactions. This…never…ends…well. My point is not to cast ugly shade on SharePoint but to show the flaws in choosing the wrong tools and codifying human interaction.

Sharing vs. Storing

Before I go on, I want to draw your attention to this section’s title; specifically, notice that it is sharing knowledge and not storing knowledge. Sharing means the knowledge is not sitting in some repository waiting for the unsuspecting worker to stumble across it. Sharing means the information is actively being used, changed and updated, sent to co-workers, studied, and so on.

At Analyst1 and my former jobs, I’ve noticed a few frequent forms of knowledge shared between workers:

• Repeatable processes
• Active problem-solving
• Asynchronous feedback
• General communications, conversations, clarifications, etc.
• Formal announcements, proclamations, etc.

From the team’s perspective, communications in any of the forms listed above must be discoverable and accessible. These were the two major issues I had with Microsoft SharePoint while working for the government and with Atlassian Confluence while working for the large corporation. Thankfully, Analyst1 found a better way that comes down to a wise balance between the use of Slack and Confluence.

How We Use Slack and Confluence

Slack and tools like it are a perfect blend between a document repository like SharePoint and a chat application. Analyst1 uses the channels as overarching repositories usually labeled by the function of the team using that channel (e.g., #develop, #product_planning, #operations, #marketing, and so on).

This is all very intuitive, but it is the almost dogmatic use of threads to which I had to adjust. If you respond to a post, you had better do it in that post’s thread. This organization keeps the conversation coherent, focused, and easily discoverable.

Slack brings one more powerful tool to the table, a search engine that is second to none. Slack’s search engine is awe-inspiring in its ability not only to find what you are looking for but to bring the most relevant items to the top of the list. Again, this makes knowledge discoverable!

Analyst1 takes an unusual approach (at least by bureaucratic standards) to making things accessible in Slack: there are no private channels. Obviously, you can message individuals privately, but everyone may join every channel. One of my favorite channels to monitor that has absolutely nothing to do with my role is #pursuits. I love to hear about our sales team making pitches, delivering presentations, and winning contracts. It motivates me, and it lets me know the health of the company. This approach also supports the idea of an open organization and breaking down silos. It lends itself to swarming. It sparks innovation, idea sharing, and problem-solving.

Slack avoids codifying the interactions between team members. Everyone can join the conversation; ideas are shared freely; conversations flow almost as naturally as spoken ones; all of this is stored for later reference. Another often overlooked benefit of Slack is the ability to link back to messages and threads. Many of our user stories in Jira link back to Slack conversations to capture the context and origins of requirements.

So, where does Confluence fit into this picture? It has a distinct role: storing our processes (normally checklists or instructions) and documents (user manuals). Any active collaboration stays in Slack. Confluence’s commenting/annotating feature lends itself nicely to providing feedback on these items.

And Not E-Mail

One final note, e-mail is rarely used. It is a static, impersonal, asynchronous communication method inaccessible and undiscoverable to all but the recipient. In most cases, e-mail is used only for the last bullet-point (formal announcements, proclamations, etc.) This ensures that Slack functions as a single source of truth, cuts down on context-switching for employees, and ensures we can take advantage of the amazing search capabilities Slack offers. Additionally, information is organically (and almost transparently) organized thanks to the use of channels. This offers built-in categorization that would, otherwise, have to be manually implemented on e-mails with features like tagging, folders, etc

Owning the Results

Frederick P. Brooks, Jr., one of history’s most renowned programmers, started his book The Mythical Man-Month by positing, “Why is programming fun?” He listed several reasons, but it was the last that resonated with me, such that I haven’t forgotten it though it’s been five or six years since I read the book. Brooks wrote:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination…Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. (p. 7-8)

There are many rewards in building software: solving problems, seeing your creations work, knowing others are enjoying and finding useful that which you created, and finding new and unique challenges every day. For these several reasons, it is easy and natural to own the results of your craft. One expects developers to find joy and reward in simply performing these tasks.

However, when I speak about owning the results at Analyst1 and any small company, I mean the successes and failures of that company as a whole. There is more on the line than simply meeting a deadline. Unlike the government and large companies, the costs of failure are far steeper here. But, so too are the rewards of success. Each member at Analyst1 plays an integral role in the success and failure of the company.

Each person knows that they impact the health of the company and the livelihoods of their co-workers.
In addition, threat detection software can be used for an effective response. With an abundance of intelligence coming from various sources and different applications, it becomes challenging to connect the dots and make informed decisions.

Take the Step Above

Are you ready to put some skin in the game? For me, it was an intimidating step when I left the comfort of a job that offered the security of knowing my impact was minor and a missed deadline could be remedied by pushing it a little further out. Despite that, working at Analyst1 has given me more fulfillment than any job before. The team is tightly knit by the threads of a shared goal and knowing that each person could be the difference between victory and defeat. The risks are higher, but the satisfaction in achieving our goals is all the sweeter for it. Ultimately, I found a pride amongst the team that one can earn only by accepting that responsibility and meeting it head-on.