leadership | keith.j.kay

Avoiding the Dictator Trap

This Atlantic article on how Putin has fallen into the Dictator trap got me thinking about how to avoid this as a business or team leader. How could a manager, team or project leader have to worry about being a dictator?

In the course of a 25 year career, I have observed many team and corporate leaders who don’t realize that everyone on their team is agreeing with them.

That’s a key element of the dictator trap.

“despots rarely get told that their stupid ideas are stupid, or that their ill-conceived wars are likely to be catastrophic. Offering honest criticism is a deadly game and most advisers avoid doing so. Those who dare to gamble eventually lose and are purged. So over time, the advisers who remain are usually yes-men who act like bobbleheads, nodding along when the despot outlines some crackpot scheme.”

Yes, we aren’t launching wars or having people imprisoned or worse, but people like to be liked, and people like to be told their ideas are good. However, if you aren’t specifically on guard for this, and more importantly building a team culture that not only allows, but encourages, hell even requires even that people speak up and challenge ideas then you will end up with a team who will just go and execute your poorly conceived project plan.

via GIPHY

The next team meeting you have, really listen to how your team reacts to your ideas. There will be some who immediately agree, and some who say nothing until they see where the team lands, and then they’ll agree what a great idea it is. Some may say nothing. But does anyone disagree or at least offer risks or ideas to improve your suggestion?

So what can you do as a leader to guard against this?

Speak last – Pose a question or bring an issue to your team’s attention, but rather than proceeding to share what you think should be done about it, ask the team for ideas. And. Just. Wait.
Call on people – If no one speaks up, then ask someone.
Call on other people – Be sure that you are hearing from the whole team, especially those who don’t normally share. Ask for their input and actually listen. Ask follow up questions to show you did.
Create a safe space for negative thinking
- I’ve written before about the value of a Pre-Mortem which is one tool for creating space for teams to think about failure without being negative or being worried about being perceived as a Chicken Little.
- Something else that I learned during my time in Special Operations is coming up with multiple COAs, or courses of action, then gaming each one out. Challenge the team to come up with more than one approach to solve an issue or take advantage of an opportunity. Far too often in today’s fast paced world, I have seen teams converge on a solution before really identifying other options. Coming up with 2-3 COAs then asking the team what can go wrong with each allows them to offer critiques without the risk of them being perceived as being ‘negative’. (Alternatively, develop a full SWOT if warranted.)
Do not tolerate agreement – sycophants are dangerous, and not just to the project or issue at hand, if you are constantly told you are amazing, your inflated ego may get you into some serious trouble at some point. Ask your team, for example “I’m glad we like this option, but why? What are its strengths and weaknesses?”
Be patient with negativity – a negative team member may be one of the hardest team members to deal with, but don’t allow yourself to get upset or impatient, they may just be a significant asset. If you shut down team members who speak up, they won’t do it next time, and the rest of the team will get that message. Ask, “I can see you’re upset/don’t agree with this, tell me why, what am I missing? How might we address you’re concern?”
Look for opportunities to change your mind – if you really want your team to trust you by being vulnerable and disagreeing, they have to see that you are able to change your mind, or go with an idea other than your own. If you are uncomfortable with this, you might have control issues you need to deal with, but then start with something lower risk and work up from there.
Be careful with a ‘can-do’ culture – I have more to say about this in another post, but while a can-do culture can be positive, if you’re not careful it can become toxic in its own right, leading to a lack of critical thinking. Don’t let people just agree. Dig in, ask why, how, what else, what could we be missing?

Is this hard? It can be. But that’s your job, if you want to be a leader your comfort can’t be your first concern. If you have trouble with this idea, you aren’t a leader.

Is it going to take more time? Sure, upfront. But your team will end up with a better solution/product/plan and you will spend far less time refactoring and dealing with issues. Remember the old cynical software project management maxim:

There is never enough time to do it right, but there is always enough time to do it over.
Every grumpy software project manager

Photo by Rob on Unsplash

Stoic Business – Momento Mori

Let us prepare our minds as if we’d come to the very end of life. Let us postpone nothing. Let us balance life’s books each day…The one who puts the finishing touches on their life each day is never short of time.
Seneca

In this post I will look at the lessons the Stoic concept of ‘Momento Mori’ holds for those in business leadership today. Momento Mori, in the stoic sense is literally to ‘remember that you will die’ and, tradition has it, comes from Socrates who said philosophy is “about nothing else but dying and being dead.”

A somewhat more practical way of approaching our mortality was written by Marcus Aurileus – “You could leave life right now. Let that determine what you do and say and think.”

So what does that mean to us as leaders and managers in the 21st century? My take are the following 3 things.

Check your ego

First and foremost, reflecting on our own mortality, and the smallness of our place in the universe and history, should engender a sense of humility. Reminding ourselves regularly that life isn’t all about us will help keep our heads from inflating with our own self-worth and self-focus. This will make you a better leader, as we all can recognize when our own leaders and managers are simply building up their resume and the justification for their next promotion, or if they are genuinely focused on the mission and the team. And we all know who we would prefer to work for.

Ruthlessly prioritize and don’t procrastinate

If you take a moment to really think about the limited time we all have on Earth, let alone the limited subset of that time we will spend in our careers, you should develop a strong sense of the scarcity of your own time and focus. Recognizing that, we should be ruthless in making sure what we are focused on is truly important and needed now.

Learning to say no, especially to time wasting assignments or activities is very difficult in todays ‘can-do’, ‘team player’, ‘yes-person’ obsessed corporate cultures (aside: this also afflicts, in my experience, the career focused officer corps of our military.) But doing so will not only improve you and your teams’ results, it will give you more control over your schedule and sanity.

If saying no is too difficult or poorly perceived in your culture, try “If this is a priority, what should I de-prioritize to focus on this?”

Steel yourself by remembering that every time we say “Yes!” to something, we are in fact saying “No” to something else, whether it is another important item, our health, our relationships, a small piece of our life we will never get back.

But saying no others is only half the battle, we also need to take a hard look at all the to-do/action items we’ve given ourselves and eliminate as many as possible to get down to focusing on those items that are critical and will make a positive impact.

Now that you’ve gotten to a core prioritized list, get after it. If these items are the most important, don’t put them off since we don’t really know how long we get to work on them.

Build capability

Knowing as we now do that our time is limited, especially when you consider that, according to the US Bureau of Labor Statistics, as of 2020 the average worker is only in their job 4.1 years, what we alone can accomplish will be far less lasting and impactful than capabilities we build that can sustain after we leave.

And by capabilities, I mainly mean investing in growing and mentoring people, although certainly leading major system and process changes can fit in this category. Investing in people however, as we would say in the Army, is a force multiplier because, if you’ve done it right, the people you invest in will see it as their duty to invest in others.

And in the end, that may be the only thing that lasts.

Photo by Mathew MacQuarrie on Unsplash

Stoic Business – The Pre-Mortem

This post is part of a series (maybe) on applying the lessons of Stoicism in the corporate world. This post focuses on the Stoic practice of Premeditatio Malorum or “the pre-meditation of evils”, whereby you think or visualize all bad things that can happen to you, perhaps something you are particularly afraid of. Then you imagine how you would deal with and recover from it. The idea being that this exercise acts as a sort of inoculation for if the dreaded thing does happen and helps strengthen you against the trials of life, and perhaps help you realize that it isn’t all that bad either.

This practice can be applied to any business initiative, product launch, or project using a technique called the pre-mortem. This is an exercise I have use myself on several projects and at the very least is a good way to generate your initial set of risks to track and manage. However, it is also a way to get a temperature check on your team in a way that creates space for them to think about failure without being negative or being worried about being perceived as a Chicken Little. Unlike their managers, project teams often know long beforehand that a project is in trouble, perhaps even at the beginning when their estimates have been slashed without changing scope (hmmm).

via GIPHY

Far too often in the corporate world we only present and evaluate a highly optimized and ambitious plan without accounting for the inherent risks. This is in direct contradiction to Project and Program Management best practices, but unless we as leaders create the psychological safety for the team to engage in which is basically negative thinking, it is highly unlikely someone is going to speak up about risks they see as the hype train for the project gathers steam.

Typically, a pre-mortem is run in the following fashion, I would keep this to 50-60 minutes in duration:

Gather the team members together. Intentionally exclude senior executives and others who will stifle discussion at the team level.
Level set with the team that you are about to facilitate an exercise meant to identify key risks to the project/program/product, and you’re looking for them to start with a brainstorming activity in which you need everyone’s participation.
Announce to the team that the project/program/product has just failed and they have been brought together to identify the reasons why. [30 mins]
- You must facilitate this discussion – don’t let people interrupt, talk over each other, debate the merits of the idea, etc. The goal of this portion is just to capture the things the team is already worried about but unwilling to bring up.
- Do not end this earlier than planned, especially the first time you run this exercise. Let the team sit in silence or call on people. I also have 2-3 risks ready as part of my prep to help prime the conversation if needed.
Next, ask the team if any of the items are the same, or so related as to be combined. [5 mins]
Next, ask the team to assess how likely the risk is to come to actually occur. You could use a simple High/Medium/Low scale or whatever risk probability rating your organization currently uses (ask one of your Project Managers.) [5-10 mins]
- Depending on the culture of your team you can either debate this openly, use a form of Planning Poker, or have everyone vote with colored stickies.
Lastly, look at the high likelihood risks, and ask the team two questions: [10-15 mins]
- Are there any leading indicators that will warn us that this risk is about to occur?
- Are there any pro-active mitigations we should consider to actively prevent this risk from occurring? (An example might be a risk to product quality that our entire QA team is inexperienced, when our estimate included 2 leads to run QA. A mitigation might be to overstaff that team, or to staff a junior project manager, etc.)
That’s plenty for one session thank the team and let them know you will take some additional time to assess the other risks and discuss with management or the client.

Now the question comes as to what do we do with this information.

First, spend additional time with this list. Put it into a risk register, clean up the way you wrote the risks and mitigations, and identify the impact of the risk occurring (for this you may need to consult specific team members and the project manager if this isn’t you.) After these additional deliberations and discussions you may want to adjust some of the risks, just be sure to communicate to the team along with your rationale or you’ll demand the trust the team has in you.
Present the risks to your management/client and, at least for the high likelihood risks, ask “are you willing to accept the risk of the documented impact, or should we include the proposed mitigation in our estimate” – do not waffle on this. They might proposed a different mitigation, and be open to that being a better option, but don’t frame the discussion in a way where they can refuse the mitigation AND avoid there being clear documentation what the dollar and time impact would be if the risk occurs. (Far too often I have seen clients and management act surprised and demand how we didn’t know about a risk when it was in the project documentation or even the contract from the beginning. This is just a tactic to get the team to eat it, don’t be a sucker.)
Regardless of the outcome of the discussions, document the meeting, the items discussed and the decisions made. Again, use the language “decisions made”, not some inconclusive discussion about hypothetical risks, but decisions made by management or the client on how THEY want to manage the project / program / product risk.
Ideally the risk register is part of your public team documentation, and you can just publish it and let the team know they key points in your next meeting. If not, specifically review the outcome of the discussions with ma

From here you or your Project Manager should manage the risks in accordance with your organization’s risk management practices.

For a robust description of project risk management see this PMI article: Project risk management–another success-boosting tool in a PM’s toolkit

If you have used this technique or something similar in the past, what was your experience? What did you learn?

Photo by Christina @ wocintechchat.com on Unsplash

Five Books to Re-read This Year

Day 5 of the Daily Stoic’s 14 Day Stoic Challenge is to pick 5 books that were impactful in your life and re-read them, with a focus on studying them more deeply than when you last read them. The idea of course being that with each re-read you will get more and different lessons out of them.

I want to elaborate the why behind my selections, and neither the challenge’s Slack channel, nor my remaining social social media channels seem appropriate, so I am putting these here, mainly for myself to be able to come back to after I’ve read each.

Anabasis by Xenophon

Written by the Athenian Xenophon, it details the return trip of a group of 10,000 Greek mercenaries after the defeat of their patron, Cyrus the Younger, in the battle of Cunaxa in 401 BCE, outside Babylon. I originally read this when I was an NCO in the US Army National Guard between deployments to Bosnia and Iraq. I remember being struck by how little has changed in terms of leading people, and human dynamics. Certainly technology has changed, our view of the world has changed, and religious views are quite different, but I remember that the leadership challenges he faced were all too familiar.

I have therefore long considered this to be one of the greatest books on leadership (that you’ve probably never heard of). So I am eager to see how that holds up, and as I served right at the site of Babylon for most of my deployment to Iraq, I am curious to see if re-reading this brings out any other connections.

Tao Te Ching by Lao-tzu

I am using the Stephen Mitchell translation. The Tao Te Ching was the first book I read from a school of belief that was not the Catholic Bible, and it was the start of a reading exploration that ultimately led to me to Stoicism. I remember that I felt like I had found a whole new way to look at the world, and I remember being a little surprised at how much the Tao seemed to have in common with Lucas’s Force. I feel like there is a lot of shared wisdom between Stoicism and the Tao, including the notion that there is no good or bad beyond the value we choose to assign to things. So we will see how that holds up.

The Problems of Philosophy by Bertrand Russell

I remember this book from my first philosophy class in college at the University of Connecticut, and I remember that class being the first time I realized that philosophy was not a stuffy subject for insufferable snobs. That it could both be interesting and a tool for thinking deeply about things we assume, and a way to work on oneself and our beliefs.

Your Money or Your Life by Joe Dominguez and Vicki Robin

I am re-reading my original 1993 version, though I may eventually read the revision that several FIRE thinkers have written about including Mr. Money Mustache, who I read regularly. Reading this set me on the path of my own financial education and led me to take control of all of my own finances, and to buck conventional wisdom on money and investing. I never fully embraced the almost hippy approach of having minimal attachments, no home, travel often, extremely minimalist possession, but it did teach me to value my time carefully and not trade it for things I didn’t need. And I never again took on debt other than a mortgage. I do remember Joe advocating buying 30 years bonds as the means of financial independence, so that part won’t hold up, but I do want to see how much of their thinking remains relevant and how broadly it is reflected in the FIRE community.

*A Short History of Nearly Everything by Bill Bryson

Bill Bryson is simply one of the greatest writers of our time, and I have read nearly everything he has written, but this and A Walk in the Woods are my favorites. This one for the simple fact that it really makes you realize just how much of a miracle just existing really is, for me it was a tonic for being too wrapped up in work and myself. And the stories about the rivalry between scientists and how human they all actually are is just fascinating. (And you have to have some sympathy for someone who has spent their entire professional life invested in something that has turned out to be wrong – you might resist that too.)

I will post back to this as I complete each book and any new observations I have to share.

What will you read?

On leaving Sapient and 3 lessons learnt

A few months ago I left Sapient, the company where I had worked for 15 years.

Whaaaaat? You left Sapient!?!?

That has been the most common response I’ve gotten, and it’s understandable as 15 years is a long time, and being a “Sape” had in many ways become part of my identity. As I wrote my farewell email, it struck me how many people I wanted to thank for the help and support in my career who are no longer at Sapient. So thank you to the innumerable people I have worked with over the years for your advice, support, encouragement and laughs – in ways big and small you made an impact on my career and my life.

As I move on to a new chapter in my career, I took some time to reflect on what I learned, and want to share the 3 I feel are most impactful. These are by no means unique observations about Sapient, nor unique to Sapient. However, in my 20 years of professional experience, including other consultancies, two startups, and dozens of clients, finding a organization with these attributes is rare.

Culture

You cannot talk about Sapient, especially in the early years, without talking about culture. We were obsessed with building a culture that would build a great company. How we chose to define our culture is interesting in itself, and is the subject of an HBS case study. What your culture is should be unique to each company and relate to your business context and purpose. However how you craft, promote, and use your culture is what I want to highlight here. My observation is that corporate culture is either what you get or what you do. Meaning, if your culture is a set of values that hang on the wall, rather than a shared set of expectations and values that you use every day to make decisions and shape behaviour, then you aren’t crafting a culture, and you will simply get the culture that your employees bring in with them. To make a culture a cohesive force I believe you have to use it daily, you have to talk about it with your teams, you have to visibly use it in your decision making. And most difficult of all, you have to, as we used to say, reject non-fits like a virus. Sounds harsh, but time and again I have seen people of great skill and experience who were culturally poisonous retained in organizations well past the point where the damage they were doing was greater than the benefits they brought to company. No doubt this is a hard decision to make, but forcing the conversation is the difference between believing in your culture as an asset versus a slogan.

Openness

Openness means different things to different people, but in the context of Sapient it meant being direct and generous with your feedback to others, and more difficult, open to hearing the generous amount of feedback you were going to get. Every day. I believe this was essential to developing a learning organization, where at our best we were in a state of continuous improvement for years. We would debrief as a team not just at the end of an iteration, but after every client presentation, meeting, or checkpoint. During our intense workshop sessions we would debrief at lunch and the end of day. By debrief, I mean we went around the room and critiqued ourselves not just as a team but each other. Now, some feedback and coaching experts will tell you that constructive feedback should be given one on one, not publicly. And that works for individual coaching, but we were trying to raise the game of the whole team, and it worked. If everyone heard everyone else’s feedback they could learn from each other. It requires a culture of trust at the team level for sure, and it wasn’t for everyone, but if you had “purple in your blood” as we used to say, it was what you expected.

People

Like many companies Sapient certainly focused on hiring bright, talented, ambitious people. And being in Cambridge, MA certainly gave us access to lots of that kind of talent. But it was a focus on people, and in particular people growth, as we used to call it, that I feel accelerated the growth of the company. Almost all companies today say people are there most important asset. But executives and managers at many companies don’t behave that way. At the time, Sapient made a decision to aggressively manage the growth of the entire company. So what does that mean? It meant in our case not just the feedback intensive culture and openness discussed above. It also meant constantly looking at our team, whether it was a project team, an account team, the office or region’s leadership, and actively looking for, or creating, opportunities to push people out of their comfort zones. Because we believed (and we experienced) that is where people grew the most. It was our own take on that old adage that sometimes the role makes the person. And that is so unlike most of corporate America in my experience, where if we need a new leadership role the most likely place to look for it is outside.

What was also really different is we used to talk about it as a whole office, and I remember we’d draw the simple diagram to the right on the board to explain, we are choosing to live right on the edge of growth and failure, because that is how we are all going to grow the most. And just as importantly, when people struggled or failed, that had to okay. It meant we knew where they needed coaching and support, and at that moment, it’s critical to dial it back a little and give them the support to work on those growth areas. Was that perfectly executed? I am sure not, and I may have been lucky in the people who I reported to, but nonetheless, that was definitely my experience for the bulk of my tenure.

So that’s my two cents. Disagree or have something to add, leave a comment.

Sad Truths About Project Rescues

This tweet got me thinking about the many project turn arounds I have seen over the last 20 so years. We’ve all seen the scenario play out time and again. The business pushes for more scope, faster delivery, and lower budgets. The project teams (I’ve seen this with both creative and IT teams) feel tremendous pressure to acquiesce to these demands. Even if the project manager makes a valiant defense of a rationale budget, scope, and timeline eventually they get worn down or overridden by their management and the inevitable happens. Management is promised a project the team knows in their hearts to be unrealistic, and everyone begins slogging away, hoping for a miracle, hoping for some break. Maybe some key elements on the critical path will come in early. Maybe the clients/sponsors will sign off on key deliverables within the planned 2 reviews. Almost never happens. If this is an IT project the odds are even lower, due to the vicious cycle of late and over budget projects which convince business sponsors that they need to dictate tighter budget and timeline constraints, knowing they will be missed, which in fact causes more projects to fall behind if not fail.

Then you have a project in Trouble. A project that is Red. And often, at least in the organizations I’ve worked with, people are brought in to to turn things around. I have had several of these put on my plate over the years, and the formula for success is usually very straight forward: tell the truth around what it is going to take to get the project done, or how much scope needs to come out to hit the time/budget. Yes, there are plenty of other things to do like look at the team structure, review and question the scope, re-vitalize the team, rebuild business confidence, look for efficiencies, etc. But for some reason that must be deeply connected to the human condition, when you first come on to turn something around, people are able to listen to reason. Even when what I am saying and calling for is exactly what the previous manager said, it was only once the project was in real jeopardy that the team was listened to.

And that last bit is exactly what I have found to be the key to success in turn-arounds. Listen to the team. Actually sit down with them, as many one on one as possible, and get them to open up about the project, what’s working, what is not, where they see the risk. For more thoughts on taking on a project in flight, see my previous post on the topic.

As for avoiding the situation, I would love to hear what others have found to be successful. And I would love to hear more pithy quips like the one that got this post started.

5 Rules for Joining a Project Underway

Note: this is content migrated from a blog I no longer maintain “The Grumpy PM” and was originally posted on March 21, 2009

Okay, there’s really nothing simple about joining a project as the PM when the project is already underway. You’re going to need to jump right in and keep the project on track while you ramp up on everything about the project.

However, while you could probably write a small book or a long article on this topic, I have found that five is the magic number as far as the limit of “action items” or feedback points you can give someone and hope that they would retain it. Three is probably better, but I am hoping my readers are brighter than that. [;)

1 – Invest in Relationship Building
Take the time right up front to meet with all your team leads and key stakeholders one on one. Have an agenda going in, but try to keep the meeting informal and ask open ended questions to get people talking: ask each how they feel the project is going, what is working well, and what could be improved. You want to get several things out of this meeting – you need to quickly build rapport and find areas of common interest you can leverage to begin to build relationships with those you haven’t worked with before; you want to see what areas are highlighted for improvement, so you can direct attention to them; perhaps most importantly, you want to try to sense how people are feeling about the previous PM no longer being there, which is probably why you would be joining after the project started. While the urge will be great to bury yourself in the project charter, scope statement, WBS, and project schedule, resist, RESIST!

2 – Get the Up to Speed, ASAP
In direct juxtaposition to the above, you will need to ramp up quickly on the project, but don’t do it at the expense of rule 1 above. Ideally, you can get access to the project repository/library/whatever and gain an understanding of what the project is about, but if you have to do it after hours or on the weekend, it is an investment well made. I usually go for the project charter, scope documents, schedule, and risk register. You need to demonstrate competence and confidence to all the stakeholders you interact with in that first week or two, when everyone will be judging the new PM, and the team will be deciding if they are going to rally around you. As you review, make a list of questions you want to ask of team members and stakeholders as you meet with them.

3 – Trust the People on the Team
It may be the hardest thing to do sometimes, but you are going to have to trust the people already on the project to do the right thing. They have history on the team, they (should) know what they are doing, and you aren’t going to succeed without them. More than this though, you need to show them that you trust them, by word and deed. In relationship to point 2 above, tell the team that you don’t know everything, they are the project experts and you am going to rely on them. When an issue comes up or decision needs to be made facilitate the decision making process, but get the people with the project tribal-knowledge, so to speak, involved. Another thing that seems to work with most people is to ask them to explain aspects of the project they are the expert on.

4 – Do Something to Shake Things Up
I am not a psychologist, so I can’t put this in proper technical terms, however I have found a significant, positive mental burst of energy and motivation can be had from the team by make some changes right away. It can be how meetings are run, how reports are presented, or even something like changing around how people are physically seated. Go for some low hanging fruit that you know will benefit delivery or the project. Certainly, you will be approaching the project with a fresh set of eyes, and you should try to bring enthusiasm with you to the assignment. Share your observations and ideas with the team in an engaging and motivated fashion.

5 – Resist the urge to blame the other guy (or gal)
I can’t remember a single project where I have jumped in after it was started where people on the team didn’t blame issues on the previous project manager. Don’t be that guy, it’s shows a clear lack of accountability for the project you now are responsible for, and it is unprofessional. Be proactive and identify all the deliverables, action items, issues, etc. assigned to your predecessor and put them on your to-do list. Stay classy PMs!