I’ve been working some long days recently, trying to balance some big projects at work. I love the excitement and intensity that comes from leading big change, whether it’s setting up a new system or process, or chasing a big opportunity. But I often need to remind myself that great leaders don’t have to work long hours, over-working themselves into a frenzy of stress and bad decision making. Great leaders plan, delegate, recruit, mentor, and they build systems to ensure things get done well without having to be directly involved. Like Michael Gerber teaches in The E-Myth Revisited:
Work on your business, not in your business.
Gerber’s book is focused on a company, but the concept also applied well to people who lead projects or teams. Stop thinking of yourself as a hero when you’re super-busy with something — instead, think about how you can:
- Better plan projects
- Recruit great people to support the project
- Mentor others to be able to contribute effectively without significant oversight from you,
- Design systems/processes so others can work within those systems without needing your to guide them throughout in each step of the process
In my recent focus on internal IT infrastructure and process (more CIO and less CTO), I’ve been searching for relevant CIO resources — here are a few I’ve found useful.
The CMMI process improvement model is focused on improving the overall processes involved with designing, creating, and supporting technology products and services. While the overall framework can be confusing, I enjoyed Watts Humphrey’s explanation of the focus for each of the maturity levels in Looking Ahead:
- Maturity Level 2 – Move an organization from crisis-driven to plan-driven by focusing on the fundamentals that can reduce/prevent crises (planning, configuration management, requirements management, subcontract management, quality assurance)
- Maturity Level 3 – Create a learning organization by identifying what works best in an organization and standardizing it across the enterprise (e.g. process definition, training, decision making approaches)
- Maturity Level 4 – Focus on quantitative management and quality control to ensure that processes are measured and improved using tangible measurements
- Maturity Level 5 – Focus on continuous process improvement, taking best practices from within and outside of the organization and applying them to the organization
Ken Schwaber’s book on Scrum, which falls under the Agile umbrella of methodologies, is a great introduction to Scrum, and I love the mini case studies (1-2 pages) he puts in the book to make the concepts more accessible. Here’s how I’d summarize Ken’s description of the Scrum software development process at a high level featuring the Product Owner (client representative), ScrumMaster (process representative), and the cross-functional, self-organizing team.
- Product Owner defines vision with Product Backlog (spreadsheet showing requirements or user stories, sorted by priority, shows estimated complexity)
- Sprint planning meeting is 8 hour meeting: first half is Product Owner discussing priorities for next 30 day sprint and the team estimates how much can be completed in next sprint; in the second half, the team builds the Sprint Backlog (spreadsheet that shows tasks (should be 4-16 hours of work each), responsible team member, status, and hours of remaining work), decomposes the requirements into tasks, and updates the Burndown chart (line graph showing days of remaining work on Y axis and sprint number on X axis, which can project the end date with a trend line)
- Team develops, with a daily scrum (15 minute coordination meeting focused on yesterday’s accomplishments, today’s focus, and risks), focusing on delivering complete functionality by the end of the sprint (designed, developed, tested, and documented for users)
- At end of sprint, Sprint Review meeting is held (4-hour meeting where the team demonstrates new functionality to Product Owner and other stakeholders, and upcoming priorities are discussed
- ScrumMaster leads Sprint Retrospective meeting with team (3-hour meeting to refine how the team should revise it development processes)
- Repeat steps 2-5 until project is completed or funding ends
For a great 9 minute YouTube summary of Scrum, check out Intro to Agile Scrum in Under 10 Minutes
It’s very easy to get caught in a constant posture of reaction, where you are constantly putting out fires instead of actually improving teams/systems/processes. I was listening to a 22 Feb 2012 podcast from Michael Ellsberg (https://itunes.apple.com/us/podcast/the-michael-ellsberg-show/id673996932) recently, where he interviews Bryan Franklin; and I was struck by one of the comments Bryan made: He talked about how great leaders don’t “exhale” (relax) when the specific issue is resolved; instead they relax when they have put a system in place that prevents that type of issue from happening again. This idea of building systems is something many talk about; but it’s something that’s very difficult to prioritize above daily, tactical things.
This concept reminds me of so many related concepts such as:
This yields value as you continue to build systems in your life.
I just finished reading Michael Holley’s War Room: The Legacy of Bill Belichick and the Art of Building the Perfect Team and Reed Hastings’ 2009 presentation on Netflix’s culture. Both are full of great ideas on leadership, and as I read them I was struck by how delicate the balance is between creating a culture that focuses on following processes and a culture based on giving employees significant discretion. Holley’s book described a Patriots team that provides discretion framed by a comprehensive, complex set of recruiting (draft) and management systems, while Netflix’s culture slides emphasize an approach that could be described as “hire great people and get out of their way.” It’s interesting to see how different organizations balance these
two approaches as they grow. Netflix describes this challenge and their approach very well in slides 46-58 (it’s worth clicking on the link and skipping to slide 46 if you don’t have time to read them all). They focus on getting higher quality talent to manage the business as they grow, instead of becoming more process-based.
This is more of a question of attracting Theory X employees vs. Theory Y employees. It’s a question of can Netflix (or other companies) really accomplish the mission of growing a company of autonomous, talented people using a decentralized management structure indefinitely? Or is there a company size in which this breaks down due to either management complexity or the ability for a company to attract sufficient high-quality talent?
I recently finished reading The Phoenix Project, which was a great read. It’s a fictional story that teaches DevOps (the intersection of the worlds of software development and application operations), and is actually much more fun to read than you’d expect based on that topic. The story made it an easy read, while there was real meat — it was like going to training on DevOps best practices, including concepts from ITIL, Lean, and continuous integration (CI); and other recommendations on books and concepts to study further (like chatting with a mentor).
If your career is related to software development or deployment, I recommend it. Here are a few quotes that jumped off the page for me:
- “Remember, it goes beyond reducing WIP [Work in Progress]. Being able to take needless work out of the system is more important than being able to put more work into the system. To do that, you need to know what matters to the achievement of the business objectives, whether it’s projects, operations, strategy, compliance with laws and regulations, security, or whatever.”
- “Left unchecked, technical debt will ensure that the only work that gets done is unplanned work!”
- “Unplanned work has another side effect. When you spend all your time firefighting, there’s little time or energy left for planning. When all you do is react, there’s not enough time to do the hard mental work of figuring out whether you can accept new work. So, more projects are crammed onto the plate, with fewer cycles available to each one, which means more bad multitasking, more escalations from poor code, which mean more shortcuts. As Bill said, ‘around and around we go.’ It’s the IT capacity death spiral.”
- “Everyone knows that in manufacturing, as WIP increases, due-date performance goes down”
- “Brent is a worker, not a work center,” I say again. “And I’m betting that Brent is probably a worker supporting way too many work centers. Which is why he’s a constraint.” “Now we’re getting somewhere!” Erik says, smiling. Gesturing broadly at the plant floor below, he says, “Imagine if twenty-five percent of all the work centers down there could only be operated by one person named Brent. What would happen to the flow of work?”
- “The Third Way is all about ensuring that we’re continually putting tension into the system, so that we’re continually reinforcing habits and improving something. Resilience engineering tells us that we should routinely inject faults into the system, doing them frequently, to make them less painful.”
- “Studies have shown that practicing five minutes daily is better than practicing once a week for three hours. And if you want to create a genuine culture of improvement, you must create those habits”
- “I’m experimenting with putting kanbans around our key resources. Any activities they work on must go through the kanban. Not by e-mail, instant message, telephone, or whatever. “If it’s not on the kanban board, it won’t get done,” she says. “And more importantly, if it is on the kanban board, it will get done quickly. You’d be amazed at how fast work is getting completed, because we’re limiting the work in process. Based on our experiments so far, I think we’re going to be able to predict lead times for work and get faster throughput than ever.”
- “The wait time is the ‘percentage of time busy’ divided by the ‘percentage of time idle.’ In other words, if a resource is fifty percent busy, then it’s fifty percent idle. The wait time is fifty percent divided by fifty percent, so one unit of time. Let’s call it one hour. So, on average, our task would wait in the queue for one hour before it gets worked. “On the other hand, if a resource is ninety percent busy, the wait time is ‘ninety percent divided by ten percent’, or nine hours. In other words, our task would wait in queue nine times longer than if the resource were fifty percent idle.” I conclude, “So, for the Phoenix task, assuming we have seven handoffs, and that each of those resources is busy ninety percent of the time, the tasks would spend in queue a total of nine hours times the seven steps…”
- “’I’ve learned that while the finance goals are important, they’re not the most important. Finance can hit all our objectives, and the company still can fail. After all, the best accounts receivables team on the planet can’t save us if we’re in the wrong market with the wrong product strategy with an R&D team that can’t deliver.’ Startled, I realize he’s talking about Erik’s First Way. He’s talking about systems thinking, always confirming that the entire organization achieves its goal, not just one part of it.”
- “People think that just because IT doesn’t use motor oil and carry physical packages that it doesn’t need preventive maintenance,” Erik says, chuckling to himself. “That somehow, because the work and the cargo that IT carries are invisible, you just need to sprinkle more magic dust on the computers to get them running again. “Metaphors like oil changes help people make that connection. Preventive oil changes and vehicle maintenance policies are like preventive vendor patches and change management policies. By showing how IT risks jeopardize business performance measures, you can start making better business decisions.
- “She created these SOX-404 control documents for the finance team. It shows the end-to-end information flow for the main business processes in each financially significant account. She documented where money or assets entered the system and traced it all the way to the general ledger. “This is pretty standard, but she took it one step further: She didn’t look at any of the IT systems until she understood exactly where in the process material errors could occur and where they would be detected. She found that most of the time, we would detect it in a manual reconciliation step where account balances and values from one source were compared to another, usually on a weekly basis. “When this happens,” he says, with awe and wonder in his voice, “she knew the upstream IT systems should be out of scope of the audit.” “Here’s what she showed the auditors,” John says, excitedly flipping to the second page. “Quote: ‘The control being relied upon to detect material errors is the manual reconciliation step, not in the upstream IT systems.’
- “He saw a presentation given by John Allspaw and his colleague Paul Hammond that flipped the world on its head. Allspaw and Hammond ran the IT Operations and Engineering groups at Flickr. Instead of fighting like cats and dogs, they talked about how they were working together to routinely do ten deploys a day! This is in a world when most IT organizations were mostly doing quarterly or annual deployments. Imagine that. He was doing deploys at a rate one thousand times faster than the previous state of the art.”
- “It’s about continual experimentation, like Scott Cook did at Intuit, where they did over forty experiments during the peak tax filing season to figure out how to maximize customer conversion rates. During the peak tax filing season! “If you can’t out-experiment and beat your competitors in time to market and agility, you are sunk. Features are always a gamble. If you’re lucky, ten percent will get the desired benefits. So the faster you can get those features to market and test them, the better off you’ll be. Incidentally, you also pay back the business faster for the use of capital, which means the business starts making money faster, too.”