During my career at Red Hat, I’ve had the great pleasure of being a go-to person to bootstrap $things. After a good amount of repetitions, I’ve arrived at a bit of a blueprint on how to do it. Each go at it becoming more and more refined and incorporating lessons learned as each $thing presents its own nuances.

As an engineer exploring ways to bootstrap $things, Simon Sinek’s book Start with Why deeply resonated with me. I began looking for frameworks that let me capture “why” in a way that has unyielding precision, and found the Patrick Lencioni’s Six Critical Questions section in his book The Advantage.

I’ve now used this format several times and am continually impressed by how durable it is. If you can capture the essence of the new $thing in this format, you can look back on it even years in the future, and your intent remains unambiguous.

Further, and most importantly, executive stakeholders and beyond can see exactly what’s being bootstrapped, the why and how. This leaves no ambiguity — all that remains is execution and follow-through.

From Patrick Lencioni: “Creating alignment at the executive level is essential to building and maintaining a healthy organization. There is probably no greater frustration for employees than having to navigate the politics and confusion caused by leaders who are misaligned. Even the slightest bit of daylight between executive team members can cause an overwhelming effect on employees below. There are six simple but critical questions that need to be answered, eliminating all discrepancies among team members.”

This approach reduces the risk of that daylight ever seeing the light of day.

Most recently I bootstrapped the internal special interest group for Site Reliability Engineering called SIG-SRE. I even made a fun video for the kickoff 🙂

Here are the (lightly edited for this blog) Six Critical Questions for clarity + answers for that project:

• Q1: Why does SIG-SRE exist?
  • The SIG-SRE project is an effort to seize horizontal opportunities created by Red Hat offering managed services.  SIG-SRE will support efforts like Operate First, internal communities of practice, and Red Hat University.
• Q2:  How do we behave?
  • We develop consensus amongst accountable parties and output process and procedure to be implemented amongst teams.  We will extract strategic value from in-practice SRE teams and bring reusable value back to ourselves.
• Q3:  What do we do?
  • We will lead in building the practice of SRE across the company.  We will bear down on the core shared problems that enable Red Hat to build a competitive managed services business.
• Q4:  How will we succeed?
  • We will take an upstream first (Operate First) approach to ensure Red Hat’s core ethos is carried forward into the managed services space. You can see this commitment delivered here.
    • The vast majority of participants will participate in on-call rotations for their existing service teams.
    • We will be accountable for goals that the SIG participants set, guided by the needs of groups and the company at large.
  • Use the Open Decision Framework
  • Ensure new processes include clear roles and responsibilities (RACI)
  • Ensure the SIG is deeply tied into training efforts to enable existing associates to succeed (e.g. PMs, traditional developers)
• Q5:  What is most important, right now?
  • Build consensus about the opportunity and approach.
  • That the SIG becomes a force multiplier, allowing engineering teams to benefit from economies of scale, lifting all our boats.
• Q6: Who must do what?
  • If this problem space resonates with you, discuss with your management chain and tech leads how your team can best support SIG-SRE by allocating specific engineering and BU/PM resources.  We will not achieve escape velocity with favors and part timers.  The value to a team in allocating engineering time to the SIG should come back to them, in multiples, in a measurable way, in a finite time frame.