Resources for Managers

Some lead developers go on to become architects, others go on to become directors. In either case, skills managing people are an important part of the equation.

• Malcolm Gladwell on mentoring people to reach mastery, and the 10,000 hours it takes
• Simon Sinek on Why good leaders make you feel safe
• Malcolm Gladwell on Hot Ones - just here because I love 'Hot Ones'
• Eliyahu Goldratt - on Ford, etc. establish flow, prevent over-production
  • Reduced number of kanbans, reduced number of items per container.
  • Figure out which disruptions to fix.
• Peter Drucker's 5 Questions Animated
• Dr. Henry Cloud on How To Set Boundaries
• John C. Maxwell on Four essential characteristics of a Mentor

• Tom DeMarco on Slack

"All projects that finish late have one thing in common - they started late.", Tom DeMarco

"The real reason for tight scheduling is the product doesn't have great value. If it has marginal value, we're only willing to spend so much time on it.", Tom DeMarco

"In a romantic relationship, you should never bid a fixed-price contract. You've got a relationship that's bound to end up with someone feeling bad. If you want the relationship to last, you commit to sharing the risk.", Tom DeMarco

"Estimating is a wonderful thing - something you need to be able to do, even very early.", Tom DeMarco

"Chronic overtime is not a sign of a great company.", Tom DeMarco

"There's a big shift happening in software development - the prosperers are not the people who have the best skills or who work the hardest but who have the most diligently assembled sets of components that they can then use on a limited set of kinds of projects.", Tom DeMarco

• It's Your Ship by Captain D. Michael Abrashoff

  Leaders must delegate to be effective.

• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco

  Make a habit of building Slack into processes, so that it's there when needed.

• How to Stop Worrying and Start Living by Dale Carnegie

  Worrying effectively is an indispensible skill for leaders.

• Influence: The Psychology of Persuasion by Robert B. Cialdini

  Learning how sales works improves pay outcomes.

• When I Say No, I Feel Guilty by Manuel J. Smith

  Teams accomplish more when healthy boundaries are established.

• Find Your Why by Simon Sinek

Other author's to consider:

• Dale Carnegie - Dale's studies on how to worry effectively are indispensible to someone whose job involves worrying.
• Robert Cialdini - There is always a client for your work. If you aren't selling to that client, someone is selling your work to them for you. Robert's writings can help you understand how to make your sales advocate more successful on your behalf.
• Eliyahu Goldratt - Called 'sensei' by the agile classic "The Phoenix Project".
• Scott Berkin - on some level you're reading this because you like making things happen.
• Peter Druker - The Effective Executive
• Vicki Robin - Managers ask people to exchange their hours of life for money. Managers who deeply understand this trade-off get more from their staff when it matters, and ask less of them when it doesn't.
• Malcolm Gladwell - 10,000 hours.
• Ron Chernow - 'Titan' is relevant to an understanding of how large organizations can function.

• Make Slack / Single Team Priority / Brag to Enable Next Steps
• Deadlines / Decisions
• Have Exactly Two Solutions
• Offer Leaders Levers / Never Waste Bad News

TODO: Agile cycle. TODO: Connect these to retention.

TODO: Link to the book 'Slack' as authority on the subject of slack.

Make Slack / Have a Single Team Priority / Brag to Enable Next Steps

Use 'pull' not push. To the greatest extent possible, let team members choose their work as long as it aligns with the team priority you have communicated. Unless they are still in training, they know their jobs. If they are still in training, assign a senior or lead member of your team to guide them through choosing their work.

For the team, choose one priority every day for the entire team. Only ever ask status questions related to today's priority. Never, under any circumstance, ask a question about something that is not the team's top priority today. Recruit and motivate people and the other work will still get done. When following this rule, there are some questions you will never ask. This is good because those questions were not important. Control your worry.

It is not possible to follow the advice in this book while worrying. Controling worries is a topic for an entire separate book. I recommend Dale Carnegie's masterpiece on the topic, "How to Stop Worrying and Start Living".

Diligently track team member victories, and never miss a chance to brag about them. Use one plain text file per year (for the whole team) with clean Markdown formatting. Have a real disaster recovery plan for this text file. Plan offsite backup and restore, and test it on this file. This victories.md file is critical to making time and space for your team to do great things.

Another way to make space for your team to do great work is to build relationships with colleagues. Invest early and your collegues will make space for your team to work when it matters. Again, this is a topic for an entire book. Dale Carnegie, once again, has proced a masterpiece on the topic "How to Win Friends and Influence people."

While I don't have a word to add on "How Not to Worry", I have a couple of tips to add on building relationships.

Write down people's exact words when taking notes. This makes them feel validated. Surprisingly few people do this, and people will notice and feel respected by you immediately. It's a simple trick build trust. Try it on your CEO, CIO, CISO or director sometime.

Tip number 2 is to keep track of the trust you have earned, and hold yourself accountable to it. Trust built is easily lost, and so we must stay vigilantly aware of those who trust us and whether we are unfailingly acting worthily of that trust.

Often this vigilant worthiness just takes the form of blunt honesty. I have many times told a colleague "What your team deserves from mine is X, but what we can deliver is Y. We will work to close this gap."

Everything critical fits in two weeks. Nothing in technology takes less than two weeks. The smallest problem can explode to consume two weeks. The largest deliverable to can be boiled down to an ugly essence that can be delivered in two weeks.

Set deadlines to ensure delivery. Default to every two weeks. Deliver crap rather than delivering nothing.

"All you have to do to succeed in software is to consistently suck less with every release."

- [Max Kanat-Alexander](https://www.codesimplicity.com/post/suck-less/)

If a team's work sucks just a little less with each delivery, stakeholders will stick with them until the delivery becomes excellent.

Make blocking decisions in less than two weeks, even when they are the wrong ones. Be honest but unremorseful when you learn you made the wrong decision. That was two weeks ago. You were a less experienced leader then.

Don't make non-blocking decisions at all, lest those decisions become blockers for your team.

For any problem, the team should have exactly two blessed solutions per problem: production: Legacy and Preferred. There is no limit to the allowed number of Deprecated solutions; but any new work on a Deprecated solution must result in the new work being accomplished in one of two ways: with either the Legacy or the Preferred solution.

• Preferred - all new work is done here if possible.
• Legacy - any new work that we don't know how to do on our preferred solution still happens here.
• Deprecated - any time work on a deprecated solution is updated in any way, it must be transitioned to use the Preferred or Legacy solution.

When Preferred starts to become another kind of Legacy, while New Preferred starts to emerge, a leader's job is to step in.

Some leaders misunderstand this principle, and try to stop New Preferred. Those leaders learn the hard way that New Preferred cannot be stopped.

Instead, a leader can champion New Preferred as simply Preferred, while taking an important stand on the Legacy issue that no one else wants to have anything to do with.

When New Preferred arrives, the leader should shift their stance on Old Preferred and Old Legacy. The old Preferred is now Legacy and the old Legacy is now completely unacceptable (Deprecated).

When a champion wants to convert everything to New Preferred, allow and encourage them, but with one critical piece of guidance: solutions in the old Preferred (now Legacy) technology are not to be altered until all Old Legacy/Deprecated solutions have been converted first. They are welcome to champion a new system, but they must start with cleaning up the worst problem areas first.

Your adoption leaders should grow to understand that they can adopt anything they like, as long as they put in the work to retire the "old way" at the same time as they work on the "new way".

When this is working - pull requests and deployments should only ever include updates to Legacy and Preferred solutions. When a Deprecated solution needs changed, it must be fully updated to use only the Legacy and/or Preferred solutions. As soon as the first solution on a new Preferred solution is approved for production use, all terms are shifted and all future changes must use only the newly named Legacy and Preferred solutions.

Leadership needs to think in large broad strokes. Present information to them to help them make excellent decisions.

Slack is how a manager makes space within a team. Presenting information to leaders is how a manager makes space around the team.

When presenting to leadership, categorize all work into 3 types:

• Operational - This label tells a leader that their approach to this work should be to just make sure it happens.
• Strategic - Tells the leader this was their own idea.
• Enabler - This label tells leaders this is where they can invest to get surprising value in the future.

The core message for leadership is that this work is simply not optional. It must be fully staffed at all times or bad things will happen. Leaders can strategize to reduce operational workload, but must commit to fully staffing for it until that strategy proves successful.

Cleaning up technology debt and investing in exploring new innovations.

A common mis-step is to only talk about technology debt cleanup, and causing all innovation to stop as soon as the leaders feel 'caught up'. Be sure to talk about "Enablers" and about continuous investment, because any team that is only 'caught up' will not stay 'caught up' for long.

Enabler work is a lever for leadership. In a crisis, leadership may move all resources to supporting operations, leaving enablers on hold. They will lose their best people daily while doing so, but it may be the right thing for the organization to survive during a true crisis. The rest of the time, leadership should push the "Enabler" level as high as it will go, only briefly pulling it down to enforce organization-wide rest cycles, before pushing it back up to max, again.

In times when the organization is not about to cease to exist, the "Enabler" resource dedication should never be below 20%, but should generally be guided by how successful the leaders want their organization to be 80%, 90%? Any team that cannot dedicate at least 20% to enabler work is unquestionably understaffed and is accruing techincal debt toward eventual extinction.

Strategic work is the part that is fun for the leader. This is actually a series of priorities that the leader can move in and out of the top positition (the only position that matters), to test their theories about what the organization needs next.

Leaders will learn over time to not strongly differentiate between strategic priorities and the enabler work they are built on, and instead set exactly one top priority and make room for enabler work that supports it. But they must learn this by being enabled by managers who clearly label 'enabler', 'strategic' and 'operational' work for them. There are no shortcuts on this journey.

Most importantly, to enable your leadership - never waste bad news. Because they are expected to take full responsibility for any bad news, we owe it to them to ensure bad news reaches them as quickly as possible.

To particularly serve our leaders well, we should keep a backlog of pre-packaged 'enabler work' that can be acted on immediately after bad news. This lets the leader quickly announce a plan to do better in the future (suck less), and it gets a valuable set of enabler work off of the backlog and into action.