Tag Archives: change management

After Moving to Slack: Inbox Zero (at least twice per week)

TL,DR Version: Moving my entire Engineering organization to Slack and adopting a ChatOps collaboration mindset has reduced email volume over 95% and now enables us to resolve issues in 1/4th of the time.

I have always been a fan of using automation, web hooks, and chat-assisted operations to streamline work and enable collaboration across different locations. However, this traditionally required some Engineering and Operations (i.e., DevOps) investment in setting up collaboration servers, programming bots, etc. Slack has changed this, virtually eliminating all technical friction of moving to a ChatOps model. Here is our of how Slack enabled us to move to a ChatOps environment with far less email, faster response times, and greater overall productivity.

In late 2013, I joined a new company that—at the time—had no one on staff at the time with a DevOps-style background. After coming from several years of Chat-integrated operations, it felt like hitting the brakes. One night a few weeks later, I saw a Tweet by @mparca on February 9 about this new great service called Slack. I took a quick look and realized I could achieve everything that HipChat and Hubot did—with a simple push-button SaaS service. My initial set up (our organization, some channels, and hooks to Github) took less than 10 minutes. As it was free (for many features), I did not even need to process a Purchase Order (even better). I was off to setting ChatOps at a new place.

Initially, things went pretty slow. At the time, most of our tech stack and tools were hosted on-premise. Our chat tool of choice as a Skype (not a hook-friendly app). I got a few people to move to Slack, but not many.

Over time, as we implemented a full continuous integration and deployment chain, we added more and more hooks into Slack. First came a move to Atlassian (Cloud). Next Jenkins. Next Sentry. Then Ansible. Then Icinga. Then came custom RTM scripts for more complex things, such as letting our Data Scientists know they have left an idle PySpark context running for more than eight hours. What made this so easy was that everything but the custom RTM scripts could be done in less than five mouse-clicks (it is very helpful that so many collaboration and monitoring tools have enabled web hooks).

As we added more hooks, and started to bring more people onboard, I noticed an interesting shift. People joining our team began to just use Slack to communicate. One developer would come across an interesting new open source repo or article and share it with the rest in #general. Developers with DevOps privileges would jump on issues as soon as they saw a Sentry alert in #prod (saving the need to even text or phone the on-call engineer). Some people even answering questions in code review while they were doing things like waiting at the airport to depart on vacation.

Today our Engineering Teams (Product, Hardware, Software, Data, and Ops) all now primarily use Slack for communications. Most even use it in favor of texting. We Slack each other tickets that are ready for work, UAT, or release). We use group chats to have conversations to answer questions about stories, designs, bugs, and more. We use Slack channels integrated with Github for better code reviews. We use Slack to facilitate pair programming (and pair testing). Slack is now our default tool  for issue diagnosis, as sharing log messages, code snippets, and JSON is much clearer thanks to native markdown.

We achieve this with the following channel model:

  • One channel for each environment (so we can let people know if we are about to add nodes, run a load test, etc.). We have our respective Jenkins, Ansible, Icinga and Sentry hooks tied into each environment channel as well.
  • One channel for each code repository (to see PRs and conduct code reviews). We have aligned our JIRA projects with these to integrate tickets as well.
  • We have some basic team channels for more focused group conversations
  • We also have a #rm channel for simple-to-read log of what was released, when

As our organization moved to this model, life and work got easier in some rather visceral ways:

First, I have been able to dial down my notifications to only ping me when four things happen: I get a call, I get a text, I get a direct Slack message, or there is public Slack in a mission-critical channel. I no longer get endless interruptions, making me more productive at work (and more attentive in meetings and at home). If my phone does ping, it means there is something very important—which actually lets me react to these issues faster.

Second, my email volume is down over 95%. The bulk of the emails I now get are related to true business questions (vs. endless status messages and FYIs). As a result, I can answer email faster and now regularly hit “Inbox Zero” at least twice a week—while managing a 24x7xForever SaaS Engineering organization with follow-the-sun development and operations spanning California, Washington, Europe, and Asia.

Our full embrace of Slack did not happen overnight. It organically evolved over a period of about 18 months–a natural rate of adoption for organizational change. Because it was organic, we did have to institute policies  that forced usage. Instead we allowed our teams to naturally adopt Slack in ways that made work easier. I hope more organizations can make this transition as everyone could benefit from less email and fewer interruptions.

Natural adoption of Slack over other forms of communication would have happened if the usability was not as good as it is. One of my favorite features is how well Slack detects when I am no longer at my desk: if I walk down the hall, my phone chirps on key Slack messages; when I sit back down my phone stops and my laptop takes over.  This happens within seconds.

Oh BTW, we do all of this with the baseline free Slack account. That’s one less excuse to not give it a try.

PS – Want to work in an environment like this? Check us out.

Web 2.0 business service for ERP program implementation

Why social networking (a.k.a. Web 2.0) is positioned to help ERP implementation

Over the past decade, I have participated on (fully led, particularly led or directly supported) five different Enterprise Resource Planning (ERP) programs. These programs have use both of the leading vendors’ technology platforms – SAP and Oracle. Some have been small (budgets of less than $10-million), some large (budgets exceeding $250-million). Regardless of size or vendor, I have often seen that the largest problems that these programs have to overcome are not technological, they are social:

  1. Getting people in the organization to agree to the need of moving the enterprise on a single, integrated platform
  2. Eliciting people to share input into how their organizations, process and technology work (so you can map their business onto the platform)
  3. Vetting what your produced with enough of the organization to ensure it will enable it work more efficiently (i.e., conducting Red Team reviews)
  4. Finding the points of resistance in the organization to using the new system and processes
  5. Enabling the organization to ask questions, share insights and gain understanding as to how to use the new system after it “goes live”

If an ERP program fails to address any one of these problems, the organization will not realize the intended ROI from its program investment. If the program fails to address several of these, the program may very well fail (this leads to those many metrics on the failure rate of large-scale ERP programs).

As these problems are social in nature, Social Networking (a.k.a. Web 2.0 or — truly in this case — Enterprise 2.0 ) is well-positioned to help address them in a cost-effective manner.

Social Networking solution position for ERP implementations

(You will note that I started this discussion by stating an ERP implementation problem that social networking can address. This follows the business service concept I wrote about last month: that the purpose of technology is not to create widget but to enable people to be more effective in what they do for a living – or do everyday to live. Along this line, the first step after identifying a problem is to establish a position for the solution…)

For: Organizations exacting large-impact ERP program

Who: Want to increase the probability or realizing the promised ROI of large-scale ERP efforts (a 1% increase in probability can generate a $x million value on large-scale ERP programs)

ERP Social Collaboration is a transformational social networking business service

That pairs social networking with ERP Blueprinting, Change Management and Hyper-care efforts to elicit employee concerns, ideas and feedback in response to changes driven by the ERP program

Providing more effective business process reengineering (by exposing process gaps before they are enacted) and increased process adoption (by letting employees voice questions and concerns that can be addressed through communications and training)—ultimately leading to faster realization of ERP program ROI

Unlike traditional change management solutions that do not tap into wide scale employee “ground truth” and traditional hyper-care solutions that react to employ feedback after ERP roll-out rather than during ERP blueprinting or realization

Social networking solution perspective for ERP implementations

The best way to explain how this ERP Social Collaboration Business Service would work to outline a sample perspective of how it would fit into a real-world scenario:

XYZ is a global, large-scale enacting a multi-million-dollar ERP program. The ERP program does not simply deliver a new software application but also requires the entire corporation to realign itself around new global processes for management of human capital, order-to-cash, supply chain, accounts receivable, general ledger, etc. In order for XYZ to fully realize the promised ROI of the ERP program, these new processes must not only improve how resources are managed but also be fully adopted by all staff.

XYZ’s ERP Program Office sets up a social network that mirrors the large-scale processes of the program. Each business process work stream (e.g., Order-to-Cash, Supply Chain, Human Capital Management) will have its own community area with the following: the Business Process Owner’s Journal, a Virtual Business Process Workshop, and the Virtual Business Process Town Hall.

The Business Process Owner’s (BPO’s) Journal serves as a platform to communicate key messages to employees. Here, the BPO can share the goals of the work stream along with its timeline and status. After the program has launched (i.e., achieved go-live), the BPO can post success stories and metrics from his or her journal.

The Virtual Business Process Workshop uses social networking to improve process design. From here, the BPO can issues calls-to-action requesting all employees affected by the process change to share knowledge about existing processes, systems, and organizations. This will reduce the risk of missing key activities, interfaces, or standards during the blue printing phase of the program. It will enable employees to comment on each other ideas and additions, using network behaviors to correct mistakes and drive consensus, making future roll-out and adoption more successful. Finally, when blueprinting nears completion, the BPO can issue a second call-to-action to key opinion leaders to offer comments on the process design, essentially driving a Virtual Red Team exercise across the whole company. Again, this will leverage network behaviors to expose process weaknesses and prioritize risks and other areas of concern, making future roll-out and adoption more successful.

The Virtual Business Process Town Hall will become important as the ERP Program Office prepares XYZ for deployment of the new system and program. From here the BPO and Change Management Team can share inspirational and instructional videos and elicit questions, comments and concerns from affected employees. Again, network behaviors will drive the most critical points of resistance to the forefront, allowing the Change Management Team to concentrate resources on the highest area of need. This will also enable the Go-Live Help Desk to pre-populate their knowledge base with answers to the most commonly expected questions.

Integrating this solution with existing enterprise infrastructure allows XYZ to balance targeted outreach with elicitation of candid responses. By integrating with existing company directories, it can enable BPOs to target calls-to-action to the correct audiences and drive response. However, by anonymizing comments and response during Red Team and Town Hall activities, it can expose true risks that employees may be otherwise reluctant to raise.

The use of social networking allows XYZ to move essential change management activities forward from launch to blueprinting in a highly visible, yet controlled manner. This not only elicits information critical to success, it also facilitates greater ownership and adoption by employees throughout the company. Ultimately, this significantly increases the speed and probability of realizing the promised ROI from these large-scale, capital-intensive programs.

How far away is this?

This is not very far away. I know of a few different technologies (from several companies) that could be coupled together in short order (8-12 weeks) to provide this service. Once this is complete, it can be easily integrated in the standard ERP process implementation approaches (e.g., SAP’s ASAP or Oracle Accelerate) or offered on an a la carte basis (as a competitive advantage by ASAP- or Accelerate-certified Implementation Partners).