If you want to come but there are now registration slots left… just come anyway.

If you are completely unfamiliar with both iPXE and gPXE let me summarize.  The industry standard way to network boot is via PXE.  A PXE client is burned into the ROM of your NIC, but because it has to fit in a tight space it is very dumb.  iPXE is an open source PXE client that is modern and very intelligent.  It can execute scripts, it can inspect the system interfaces and SMBIOS, it can download images and scripts via HTTP, FTP, NFS, and more, it has SAN support for booting off of AoE, FCoE, and iSCSI, etc.  It can be used in several ways, including burned into your NIC’s ROM as a replacement (uncommon), booted from USB/ISO/etc media, or most typically it is itself PXE booted such that your dumb PXE client in your NIC boots to iPXE and it then does all the heavy lifting.  If you are doing any type of network booting you should know what iPXE is and if you ever want to do anything fancy, iPXE is the way to do it.  One example many of us like to use is creating an iPXE script which calls out to a web app (PHP commonly) which looks up information from SMBIOS (such as serial number, service tag, MAC address, etc.) and interfaces with a database to make decisions on which image to boot.  You can do lots of fun things.  Most of your next-gen bare metal provisioning tools, such as Razor, rely on iPXE.

There are two really exciting things for me, just added in the last couple months.  The first and most basic is that SmartOS boots natively from iPXE.  In the past, primarily with OpenSolaris, you had to chainload PXEGRUB to boot Solaris, but it looks like some patches were accepted and now you can dump GRUB completely.

The other existing development is the addition of native menus in iPXE.  Historically, if you wanted to create a versatile netboot server you would use iPXE/gPXE to  chainload SYSLINUX’s menu.c32 program which would render your boot selection menu and boot your selected OS.  But no more!  iPXE can do it all on its own now thanks to the addition of 3 commands to iPXE: menu, item, and choose.  With these new commands and liberal use of “goto” labels you can create some extremely complex and powerful setups with no other helper programs in the way.

Lets take a look at a simple menu:

#!gpxe

######## MAIN MENU ###################
:start
menu Welcome to iPXE's Boot Menu
item
item smartos    Boot SmartOS
item
item shell      Enter iPXE shell
item reboot     Reboot
item
item exit       Exit (boot local disk)
choose --default smartos --timeout 60000 target && goto ${target}

## Utility menu items:
:shell
echo Type exit to get the back to the menu
shell
set menu-timeout 0
goto start

:failed
echo Booting failed, dropping to shell
goto shell

:reboot
reboot

:exit
exit

########## MENU ITEMS #######################
:sdc
kernel /sdc/20121001T165806Z/platform/i86pc/kernel/amd64/unix -B hostname=r720test,standalone=true
initrd /sdc/20121001T165806Z/platform/i86pc/amd64/boot_archive
boot

:smartos
kernel /smartos/20121004T212912Z/platform/i86pc/kernel/amd64/unix
initrd /smartos/20121004T212912Z/platform/i86pc/amd64/boot_archive
boot

You can see here that the “menu” command declares a menu with a title. The elements are items with a label and description (you can assign hot keys as well) and an item with no value is an empty line, and you can use the “–gap –” argument to create section headers, in the form “item –gap — —–SmartOS——-”. Finally, the choose command puts your selection into a named variable and also allows you to specify a default selection and timeout specified in milliseconds. Just about everything else is handled by the “goto” command and labels sprinkled throughout the script. Most importantly, we use the value obtained by the choose command to “goto” the label with the commands to boot the given OS. You can also have multiple menus, one which goes to the other and back, by being creative.

When you couple all this together, you get an iPXE that is more powerful than ever before and extremely exciting.

I’ve taken this opportunity to update the SmartOS Documentation for PXE booting,  using iPXE directly as above is now the officially recommended way to netboot.

The whole point of an SOP is to produce consistent results regardless of who’s using it. That means that all SOP’s need to be in a similar, familiar, and easy to follow format that is suitable to anyone who may need to use it. That, therefore, means that to get those consistent results there can be no room for ambiguity, it must be explicit and convey any necessary context along with it. Ambiguity is the mortal enemy of consistency. Case in point, if you’ve ever been asked to recompile software with a large number of configure flags, if your unable to determine which flags were used in the past you’ll go cold with anxiety over whether or not your building it properly. When you go back and ask who it was built in the past someone might say “Don’t you know how to compile software?” and the answer is likely going to be “Yes I do, but I don’t know how YOU compile software.” Whats important is that the person implementing a procedure be given all the information and context necessary to understand, and if necessary, interpret the information as appropriate for the given situation.

The first key to better SOP’s is to provide a template for others to follow. Without a standard template each author will write the procedure in their own unique style. Some people will write you a book, others will just paste some lines from their terminal into a code block. The template therefore must enforce a certain flow that ensures we include all the needed information but in a concise and complete way. Plus, we want SOP creators to focus entirely on writing the content, not debating the format.

Here is the template I use for Joyent Operations SOPs (in Confluence markup):

* Author:  {page-info:created-user}  created at: {page-info:created-date}
* Version: 1
* Revisions: {page-info:current-version}
* Reviewed by: (User @ date)
* Time to implement: 1hr
* Products this applies to: (SKU1)

{toc}

h1. Description & Scope

h1. Prerequisites

* Root access to node
* [SOP-222: Something|SOP-222: Something]
* [SOP-224: Something else|SOP-224: Something else]

h1. Procedure

h3. Step 1: Do this

{noformat}
Example
{noformat}

h3. Step 2: Do that

h3. ...

h1. Procedure Validation

# Login and verify external connectivity (ping google.com)
# curl zone IP address, page returns
# etc.

h1. Notes/Jira Examples

* [http://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro]
* [http://confluence.atlassian.com/display/DOC/JIRA+Portlet+Macro]
* [https://studio.plugins.atlassian.com/browse/CONFJIRA-154]

Lets step through the above template.

All SOPs must be numbered for easy reference. Even the template itself is SOP-000. The SOP title is in the form: “SOP-102 Creating LDAP Users”, for instance.

The top of the SOP is full of metadata. The author, creation date, major version number and number of revisions made and products (or projects or whatever) that this SOP applies to. You’ll notice 2 other fields: “Reviewed By” and “Time to implement”. These are perhaps the most important of all. After an SOP is created it must be reviewed by someone else in the group, preferably with as little knowledge of the subject as possible. They should read and follow the SOP as written, starting a timer when the begin and stopping the timer when they are complete… it is that stopwatch time which becomes the “time to implement”. This is extremely important, the time estimate for implementation by the author will be way too short because they know what they are doing, the time it takes a complete n00b will be more useful and truthful.

Moving on through the template, “Description and Scope” are where we provide context. What are we talking about, what does it entail at a high level, what does this impact, etc. We want to include as much information as possible to set the stage for the procedure that follows. Then we include a bulleted list of “Prerequisites”. The single most common part of any procedure that gets skimped on is the prerequisites and they are also generally the most time consuming.

The meat of the SOP is the procedure itself. I strongly believe these must be in a “Step 1… Step 2… Step 3″ format; it must be easy and intuitive to follow and in some cases may be used as a checklist during sensitive procedures. Its important that these truly start at the beginning and go to the end. “Step 1: Login to server X” may be overly simplistic but necessary for clarity if multiple machines are involved. I also like to have the final step be “Done” to make it clear that you have reached the end.

Just as important as the procedure is the “Validation Steps”… to ensure a quality job we must not only preform the proceedure but validate it in one or more ways to ensure it was really done right. This has the added side effect of giving the person doing the work the satisfaction that it was done properly and they didn’t screw something up along the way.

Lastly is a place to include external links as appropriate. If possible I like to link in tickets (we use Jira) which have relied on the SOP before, so that if by chance there is some confusion they can find examples of the work being done in the past.

An optional section that I’ve used before is a “Rationale”. In this section you would include notes on why you chose to implement the procedure in the way that you did. This allows for continuous improvement of the SOP. In most cases there are many ways to solve a problem, conveying why you chose the method you did will help you hone the procedure in the future while learning from the past. Without it your likely to have regression or duplication crop up.

This is the model that we’ve used at Joyent for several years and it has stood the test of time. I believe it to be a very solid standard for writing SOP’s and sharing knowledge within the organization and avoiding any one single person becoming a constraint. If you have refinements or a better method, I’d love to learn about it.

Go find all the docs in the SmartOS Wiki: Configuration Management on SmartOS

As I stated in a recent talk, and then was humored to see quoted on Twitter a couple times since, I never really intended to run a “Solaris Desktop”. I didn’t want a desktop, rather I wanted a server on my desk. Building a desktop operating system is really hard, it involves supporting all manner of new and strange hardware. Its hard enough on desktop PCs but its absolutely redicuous when you consider all the variations of laptops. On my workstation I always installed a standard Intel e1000g dual port NIC, a Sound Blaster 16 or 128, and a well supported NVidia graphics card. So long as I could start an X server on dual displays and start Enlightenment, my window manager of choice, I was happy. The only apps I rely on are a browser and several dozen Eterms… little else. What was important to me was that I had a platform on my desk with which to experiment and prototype on Solaris for later implementation in the data center.

With the addition of ZFS, Solaris became an extremely powerful testing platform. Several large disks in my workstation formed a Zpool on which everything but the base OS was installed. The OS root itself was on a small 16GB SSD (it was bad ass once upon a time). This allowed me to frequently do fresh installs of new releases of Solaris and OpenSolaris. After install, I just imported the Zpool which put my home dir, /usr/local, /opt, etc back into place and I was running again.

What has always bugged me about Solaris is that the software packaging solutions have always been aweful. For a long time we were limited to whatever shipped with Solaris or was available from Blastwave. But Blastwave was little comfort because so frequently a single package install would have an absurd dependency on some very foundational package therefore forcing an upgrade of everything, like it or not, which invariably would break something. In my former Linux days I was fond of Linux from Scratch and latter became a fan of Gentoo, therefore my solution for Solaris was to hand build all my fundamental applications myself and then simply drag those binaries from release to release for a very long period of time. While I appreciated having the latest and greatest Solaris on my desk, I certainly missed the ease of simply installing an RPM and being done. The idea of trying the latest KDE was a seemingly insurmountable challenge and waste of time.

About 30 days ago two factors caused me to finally throw in the towel on Solaris as a workstation OS.

The first was that I finally joined the club of folks who have spilled liquid on their MacBooks. After 3 years of faithful service my Mac was dead. This happened on a Saturday and I suddenly realized that on Monday I’d be unable to join our corporate Jabber channels and I wouldn’t have Skype access. Suddenly I became aware of how much I was relying on my MacBook for daily communication and that I was essentially going to be cut off. Getting all these types of services working on my Solaris workstation was possible, but hardly seemed worth the effort and I only had a day to get back to full capability to be ready for Monday morning.

The second was that Solaris is dead. Illumos is the future of the platform and the desktop options there are very weak. All my work these days is on SmartOS, which is dedicated hypervisor platform, so there was no way I was going to whip it into a workstation platform in short order, not to mention that it’d be a fruitless exercise even if accomplished. It was clear that having a server on my desk that also possessed the basics required for a passable X environment was at an end. Besides that, thanks to KVM support in SmartOS it was becoming increasingly clear that I was completely out of touch with the Linux world which I was now supporting more frequently as a guest OS. And, last but not least, Linux now has ZFS support, so I could theoretically install Linux, get ZFS supported added, and then import all my important filesystems. It was time to return to a Linux workstation.

I’m getting older and lazier, so going back to the Gentoo lifestyle wasn’t interesting to me. Ubuntu continues to be all the rage, so I decided Ubuntu 12.04 was the way to go. And, I turned out to be right… within 4 hours of the MacBook toasting I had installed Ubuntu 12.04, gotten my displays working properly, installed all the software I needed, including Skype and Enlightenment, added ZFS support and mounted my home directory and was looking at my desktop environment as though nothing had happened. It was a wonderful experience.

Getting ZFS Support working with Ubuntu is very simple. Simply install the ZFS for Linux PPA packages and reboot. The only mistake I made was that I initially had installed Ubuntu 32bit, thanks to my outdated Linux knowledge of compatibility issues running a 64bit kernel. On the 32bit kernel ZFS took almost an hour to locate and import the pool… after I reinstalled Ubuntu 12.04 64bit and adding in the ZFS packages again, my Zpool imported just fine. One thing that helped me here was that my pools are very old; in order to provide maximum flexibility in which OpenSolaris release I used, I never allowed my pools to be upgraded, therefore allowing me to run older OS releases if needed, therefore ZFS for Linux had no problems importing my old version pools.

After using ZFS on Linux for some time now I can say that it works very well but the performance is less than stellar. The performance is good enough that I NFS export all my old file systems for use, but bad enough that I created a fresh home directory on ext4.

I did play with Unity a bit before switching back to Enlightenment DR16 (the best window manager ever created). Unity is a really excellent desktop and a first rate contender against Windows 7/8 and even OS X… but ultimately I still prefer the speed and minimalism of an old school window manager. The only thing that actually bugged me about Unity was the way they tried to be very clever about window titles… they sort of blur out from left to right. While I realize its a nifty visual device, to me it looked like a theming mistake and I disliked windows with the title “Firef…”.

One thing that did surprise me about my return to Linux was how little the desktop applications had changed. Finding that Pidgin was still the IM client of choice threw me for a loop. I experimented with Empathy but had horrific stability issues, which is a shame because its a much nicer client than Pidgin. Ultimately I found a theme mix that worked for me and settled on Pidgin was but was sad there weren’t more viable options (yes, there are alternatives, but they sucked more than Pidgin). Getting Skype running easily was a pleasant surprise, no pain not problems and people I called told me it was the best I’d ever sounded on Skype. The other various apps were less exciting than I had hoped, I was sad that Eye of Gnome hadn’t died a long time ago. I think the two high points were realizing that I could use the Arduino IDE on my workstation and looking at Shotwell. Shotwell is an amazing application, but its not enough to convince me to move all my photos out of iPhoto.

In the end, 3 days later I had been issued a replacement MacBook Pro which I got just as Mountain Lion released. Thankfully installing Mountain Lion and then recovering from my TimeMachine backup went well and I was back to my normal workflows. While I’m sad that, at least for me, the era of Solaris as a viable workstation had come to an end, I am glad at all the new life Illumos distros have as first class server OS’s. I may not have the server on my desk any more but the era of the all-things-to-all-people OS is, imho, done.

I’ve also decided this is an amazing opportunity for me as an OpsDad… given that its a 24 hour trip for me (OAK to LAX is 1.5hrs flight time) I’ll be bringing my two eldest children (Nova 8yrs & Glenn 7yrs) along.  As professionals its not often we can bring our children with us on a “business trip”, so I’m looking forward to giving them a really kool adventure.  I strongly encourage all OpsDad’s included their kids whenever you have the ability to do so.

UPDATE: The event went great, thanks to everyone who attended.  For those wanting the slides, here is the deck: DevOps Demystified

Register here. (If I know Joyent, beer will be provided!)  Come over and say hello!

UPDATE:  You can view the whole event on Ustream! My talk starts at 40m in. You can also download the slides.

Video streaming by Ustream

Once upon a time, my blog was a predominately Solaris blog.  In fact it became over time the most read Solaris blog.  Thanks to Google it actually still is, because I have verify few active readers, the vast majority come to the blog via some Google search for this problem or that and find what they are looking for.  As a result, many people don’t even realize I stopped blogging about Solaris some time ago, which I find a bit funny.  At Velocity this year several people came up to me and thanked me for the blog, whom I then would ask “Does it bother you that I’m talking about DevOps now instead of Solaris?”  Each of them gave me a blank look and said “You stopped blogging about Solaris?”

I stopped writing about Solaris for several reasons.  The first was that I’d covered so much ground that I would start to write about something and realize I’d already done so a year before.  Another was that some of the things I wanted to write about where simply too large or complex for a blog, but not quite enough for a book.  Yet another is that sometimes, as a writer, you can start to take yourself too seriously and give too much thought to critics and thus feel that many things you want to write about are “too basic” or “too dumb” to write about.

Another big reason was of course Oracle taking over Sun and there being a very unclear future for the community at large.  The Illumos project brought OpenSolaris back to life, but given that so many people in the Solaris community are from the enterprise space (directly or indirectly) it was unclear whether Illumos would truly provide an alternative to Oracle Solaris.  And besides that, I had become far too involved in Sun and OpenSolaris internal politics and governance and other non technical crap which I feared becoming involved with again under Illumos… thankfully the Illumos community actively stamped out any of the old politics before it took root again, but I was happy to provide a wide birth while it sorted out.

Yet another reason was that for a long long time I’ve wanted to change formats.  For at least 6 years now I’ve wanted to move from “blogging” to producing screen casts.  For many topics there is only so much you can digest from a written entry, at some point its easier to just show you.  I’ve started down that road many times but never gotten it off the ground.  Maybe one day it will.

However the largest reason was that about the time OpenSolaris imploded I was pretty well burned out on the whole thing anyway.  Using Solaris was far less a challenge than managing and operating a large environment.  I became obsessed with the question “How do you run a cloud?”  That’s the question that drove me into learning all sorts of strange things.  I blogged about some of them in the last 2 years, but held back quite a bit because it was unusual fare for my Solaris audience.  I could write about Deming and Ackoff and Ford and Ohno all day long… but who would want to read it?  Lucky for me, DevOps came along about the same time and a community of like minded individuals formed around these same ideas.   I’ve been thankful for that community and how its brought so many of us together who were each on our own individual journeys.

And so, there are my excuses for being a bad blogger… not that I actually consider myself a blogger in the first place.  I just like to help people and this is the best vehicle to do so.

Now for how you can help.  What would you like me write about?  Should I go back to writing about Solaris features?  Should I write about all the new Solaris variants (SmartOS, OmniOS, etc)?  Should I write more DevOps nuggets?  Are there “old” topics that still should be discussed that no one is talking about anymore?  At the end of the day, I still fundamentally believe in SA’s helping SA’s.  How can this SA help you?  Its time for me to get back in the game.

WIP is the hidden killer of productivity among what Peter Drucker calls “knowledge workers”, most of us know this phenomenon as “multi-tasking”.  Multi-tasking is an illusion that a person is doing more than one thing at a time, however in reality most of the time you are in fact context-switching back and forth between multiple tasks very quickly and thus not fully engaged in either.  In some cases the consequences of multi-tasking are trivial, such as driving and talking on the phone, you are dividing your mental attention between both the conversation and your driving, but this is generally acceptable.  However, even in this common case, should either the driving situation or the conversation become serious, the facade of multi-tasking will reveal itself for the lie that it is; your attention can only be truly devoted to one thing at a time.  Think of a time you got into a serious discussion while driving… how much of the drive do you actually remember?

Anderson’s adaptation of kanban involves creating a card board by drawing rows and columns into which index cards or post-it notes can be placed.  Each kanban (card) represents work (a discrete task).  The rows  (swimlanes) are workers (a person, a team).  The columns are steps in the value chain representing state and have a work limit associated which limits how many cards may be in any given state at a given time.

In its most simplistic form, as shown above, there are 2 advantages gained: visualization and constraint of WIP.  Anyone can easily see how much there is to do, how much as been completed, and whats in progress, but most importantly we enforce our per-determined WIP limit.

Indeed truly constraining WIP is the strength of this system.  Any manager could create a “no multitasking” policy, but without visualizing the flow of work there is no way to enforce it.

But you probably already know all this, if your reading this, there are lots of “intro to kanban” blog posts and videos out there.  What few people know is what kanban is in a LEAN context… where it really came from and is intended to do.

Kanban was created by Taiichi Ohno as the primary signaling mechanism of the Toyota Production System (TPS) which enables “Just-In-Time (JIT) manufacturing”.  JIT is the evolution of Henry Ford’s “mass production” in which work was done in large batches and produced a lot of excess goods, aka waste.  The Toyota Production Systems foundational principles is on the reduction and elimination of waste (“muda”) so they decided to only build what they need when they needed it.. obviously there must be a buffer of finished goods inventory (cars waiting on a dealers lot to be sold), but they would keep that amount as low as possible.  So now, let me explain kanban again, but this time in the manufacturing (TPS or LEAN) context:

Kanban is Japanese for card.  At the assembly line sits a worker who puts the break assembly on the car.  The worker has a number of  “kits”, a plastic container which includes all the needed parts to build one break assembly.  The kits have kanban attached to them, so when she picks up a kit, she takes out the kanban and puts it into a tray and then builds the assembly.  Every hour a boy comes around and collects all the “used” kanban from the trays and goes to the parts dept.  The parts dept then refills the trays, attaches kanban to them, and sends them back to the assembly line.  So we’re effectively controlling and signalling the flow of goods in this closed loop. Here is an example of a real kanban:

But here is the really really important part… the kits are assembled from supplies of parts which have their own kanban, which control their flow.  So when a box of Part B is pulled from inventory to create a kit, that kanban signals the ordering of that part from the supplier.  The result is that instead of buying 200 of Part B every week because it matches our production schedule, we only order as many of Part B as we have kanban signaling us to do so.  At a Toyota plant, they don’t receive parts every week, they receive them every couple hours!  Kanban proliferated throughout Japan because when your using it for JIT, it requires that your suppliers do so as well to keep up with your speed… and their suppliers as well.  Here is a pallet of parts, look for the kanban attached:

So Just-In-Time manufacturing, with signaling from kanban, pulls along the entire supply chain from the final assembly line.  If you aren’t using the parts, they never get ordered… no mistakes.

Lets look at how this put Japan on top of the car industry in the 1970′s.  In 1973 there was an oil crisis, oil prices soared out of control.  People stopped buying cars.  The American mass production systems continued to build cars, which, thanks to “planned obsolesces” (new cars each year), caused a lot of those cars to go straight into scrap heaps.  American car makers suffered terrible losses all because the push based mass production system depends entirely on accurate forecasting, if its off you makes to few or, in the 1970′s, way too many.  Toyota, however, stopped making cars because people stopped buying cars… and because the supply chain only moves based on the speed of the final assembly line, it stopped too.  Toyota took losses on the small amount of inventory it had in the market, but didn’t continue to spit out cars until they were sold.  JIT saves the day thanks to kanban!

Both David Anderson’s Kanban and LEAN’s Kanban use cards, but I hope you can now see that the goals are very different.  In another blog post I’ll go into more detail on how we can apply LEAN principles to get the most out of your agile implementation.

Despite that obsessive level of awareness, nothing can tell you more about who you are then your children.  In particular, by observing things your children do that you never taught them, they just started doing of their own accord because “it seemed right”.  Genetics at work.

I fight frequently with people about documenting processes.  But maybe I’m just anal?  Then the other day my son comes to me and shows me this:

This is Glenn, my eldest son (6 years old).  He wanted some lemonade, but mom and I were busy.  He decided it might help if he simplified his request into a process.  You can see here that we start with a bottle of lemonade, then we pour it into a glass, then WHAMO!  we have our amazingly refreshing beverage to enjoy.  It is the perfect process with an input, output, and processing in the middle.  Brilliant, and he hasn’t even been to business school yet.  How much simpler does process get?

What about policy?  Policy is just a business word for “rules”, nothing more.  In my opinion, the worlds most amazing and effective policy is this one:

That yellow line is policy.  Its not a brick wall, but we treat it like one.  Thanks to that little bit of paint two cars can drive towards each other at 70 MPH, passing with only 6 ft between them, without fear.  It doesn’t get simpler or more powerful than that.

Parents and authority figures in general, tend to layer into a child the concept of right and wrong as absolutes. Take the cookie and you shall be punished, so don’t take the cookie! All throughout our culture we do this, define a rules and corresponding punishments. The result is a general fear of rules, because they are seemingly there for the sole purpose of justifying punishment.

Any rule, any law, any policy, can be viewed as a guide or as a guillotine. When I asked many of my peers what they thought about policy a surprising number quickly answered “Its there so that you can fire people.” Its shocking how many people believe that. One would think that policy is there to enforce lessons learned in the past, as a guide for decision making, pre-computed solutions to problems which might be difficult to conflicting. So then why is it that they are considered simply a justification for punishment? Inconsistency of course… everyone seems to ignore, discount, or outright disregard policy on a day-to-day basis and it only comes to peoples attention when someone is being called out.

Policy and process are wonderful things. At least, they can be. They are the means by which we share knowledge within an organization. Common tasks, problems, and dilemmas can be quickly handled in a tried and true way, consistent throughout the organization, because we have policy and process. But in order for them to work, there are some ground rules, if you don’t follow them they are doomed to be the millstones of frustration most of us see them as:

• They need to be simple and straight-forward for the average employee.
• They need to be indexed, so that they can be easily found.
• They need to be relevant to the business, not just copied from someone else.
• They need to be consistent, so that they do not contradict each other.
• They need to be helpful and solve real problems.
• They need to be up to date. Old policy and process can be worse than none at all, because people are afraid of the reliability and may waste time debating a course of action, which is exactly what process and policy should speed up.

The last point is the hardest. Knowledge management is still something we’re shitty at. Wiki’s have helped a lot over the last decade by making everything searchable and empowering everyone to update documents quickly and easily. But the fundamental problem is that of scaling. Not scaling the infrastructure but of the human mind. Many a sci-fi story has depicted the person who desire to know everything, and when the wish was granted, their head promptly exploded in one way or another. In many large companies when you hire on you’ll receive a book or binder with all the company policies… did you read it? Of course not: tl:dr.

Thus, what we’re really talking about here is culture. Genetics. Your children get them from you in the blood, but in a company we must teach them to others through words and actions. Preferably when employees are new, through on the job training/mentoring/tasking. Will you ignore policy and process? If you don’t care, they are likely useless crap anyways, and everyone can fend for themselves and hopefully get it right. But what if instead they were useful, and they were a reference available to simplify life? You don’t read the dictionary, but you know that its there and handy when you need it… so should be process and policy.

I feel passionate about these things because I hate to see employees stressed out because they aren’t sure what to do or how to do something. Useless anxiety. Wasted energy. Muda. I see managers beat on their people for not knowing… but who’s fault is it really? There are hard problems in the world, lets focus the energy on new problems and codify what we’ve learned in the past for everyone to benefit from. This is the nature of continuous improvement… building a collective body of corporate knowledge and continuously expanding, refining, and even replacing it when appropriate.