2 Productivity-Boosting Mental Jumpstarters

Photo by Fernando Jorge on Unsplash (modified)

Thoughts to think when you feel stuck

I’ve been living in leadership books these past few months, and they’ve given me all kinds of wonderful insights and fresh perspectives. Each one seems to be more enjoyable than the last.

Every day seems to be rife with opportunities to apply what I’ve learned, too. I feel like a leadership book version of Russell Crowe as John Nash in A Beautiful Mind, witnessing manifestations of these sacred texts’ teachings in the air around me.

There’s no doubt, these books have made me a better, more thoughtful leader, but there’s a pair of statements that have lingered in my brain that have had a profound positive impact on my own productivity. I don’t think of myself as much of a mantra person, but I’m hit with situations daily that trigger these affirmations to playback in my head — and they help.

Image from The Hangover via meme-arsenal

In addition to improving my own personal productivity, they’ve also been useful tools for mentoring and coaching. We all get stuck, we all need a little motivation sometimes, and we all feel frustrated about things happening — or not happening — around us.

Best served with an eyes-closed cleansing breath, these mantras will help you fight through those moments of stagnation, find a goal, and push to make it happen.

One important thing each day

I can’t remember what I did yesterday, and I’m not sure what I’ll do today.

We’ve all given that update, right? You know, when you show up to your team’s daily status meeting a little underprepared and struggle to articulate what meaningful progress you made or what you plan to do next. I’ve certainly been in that boat — more times than I care to admit.

That’s what I love about this first mantra. It addresses both parts of the feelsbad daily status report.

It’s inspired by the book A Sense of Urgency by John P. Kotter. Kotter explains that having a sense of urgency doesn’t mean you’re always running around creating a flurry of activity. Rather, it’s having a goal and making consistent progress toward achieving it without the stressful, frantic flurry. He writes the following:

With an attitude of true urgency, you try to accomplish something important each day, never leaving yourself with a heart-attack-producing task of running one thousand miles in the last week of the race.

This is my go-to self-talk when I catch myself spinning on tasks but accomplishing nothing, like when I’m flipping between email and Slack, searching for something new begging for my attention. That’s not a productive way to work. It’s entirely reactive and, at best, keeping up. It’s certainly not a mode that will lead to much progress.

In those moments, I take a breath and think, “One important thing each day. What’s something important I can do?”

This helps me pause, take inventory of everything that needs to be done, and determine what’s actionable. When done at the beginning of my day, it pushes me to prioritize and set immediate-term goals. It can also help with personal or team roadblocks by shedding light on instances where the most important thing can’t be done.

Completing a meaningful task each day gives you a place to hang your hat. No matter what else happens, you accomplished that one important thing. You set a goal and achieved it, and you’ll remember it when it’s time to give your update in the team’s daily status meeting.

Be the leader you wish you had

Toward the end of last year, I watched Simon Sinek lecture about his then-upcoming book Leaders Eat Last. During Q&A at the end of the lecture, a woman asked, “If you find yourself in a place that you consider unsafe, is your best strategy to exit?”

This was his response:

Absolutely not. The best strategy is to step up. The best strategy is to be the leader you wish you had. The best strategy is to find someone you trust and say, “We have each other; let’s look after each other, but let’s also commit to looking after everybody else.”

He explains how toxic leaders use isolation and fear to control groups, but it’s always the group that ultimately holds power. The group controls the leader.

Sinek speaks about it in the context of toppling a dictator, but I find it to be applicable in many non-authoritarian situations, too. It’s easy for friends and colleagues to complain about what’s swirling around them, and it’s in those moments when the line creeps into my head: be the leader you wish you had.

When I think of these words, I feel empowered to do the right thing. I’m permitting myself to step outside the bounds of my role for the good of myself, my team, or my company. Energy spent on complaining is redirected toward solving. Instead of being frustrated about what isn’t happening, I take actions to help make it the way I believe it should be.

Think about this when you find yourself frustrated. Who could make it better? What do you wish they’d do? What would happen if you did that thing? What else can you do to address it yourself? Be the leader you wish you had.

Put ’em together, what d’ya have?

These two mantras are both pretty good when used independently, but they get really powerful when combined. Like, power-level-over-9000 powerful. It’s setting them up and knocking them down. It’s taking names and kicking ass.

“One important thing each day” forces you to lock-in on a target, and “be the leader you wish you had” permits you to do whatever it takes to make it happen.

It’s taking solution-oriented to the next level because you’re not just coming up with solutions; you’re implementing them. You’re making problems go away. (Hey! Common sense here. Make sure you keep the people that matter in the loop in your decision-making. Feeling empowered is good; recklessly creating controversy isn’t. You’re trying to be productive, not stage a coup. Usually.)

Put yourself in your boss’s shoes, or think about what your team will say. Nobody’s going to complain about how you do important things, like, every day. They won’t be disappointed that you identify solutions and work through roadblocks instead of sitting on problems until the next team meeting.

In fact, it’s going to be the opposite. Your boss will be very excited about that level of proactivity, and the team’s going to notice when you show up every day with tales of glory and meaty contribution.

Recognize when you’re unproductive and lack direction. One important thing each day.

Don’t wait when you know the answer, and don’t be penalized for others’ inactions. Be the leader you wish you had.

This article was originally published on ILLUMINATION on February 16, 2021.

Interested in learning more? Be sure to give the books mentioned in this article a read! Note that I use affiliate links when linking to products on Amazon. Thank you for your support!

A Sense of Urgency by John P. Kotter
Leaders Eat Last by Simon Sinek

The Grass is Brown Everywhere

Photo by Trevor Littlewood via Geograph

Don’t sacrifice what you have in pursuit of what you don’t

You should switch jobs. Life would be better at a different company.

I mean, they’ve got better perks, better teams, better brand, better mission, better everything, and with none of the problems of your current company. Things would be so good over there. Right?

The reality is, there’s a pretty good chance the new company won’t be much better than the one you’re with now — but maybe that’s actually good news.

Two traps like to catch us all. First, there’s the “grass is greener” syndrome, where we fantasize about all the things we don’t have. The other is good old-fashioned pessimism, which makes everything look unfixable and hopeless.

When these forces collide, the desire to opt-out becomes incredibly strong. That’s when we start looking for a new job or become susceptible to those pokes from recruiters.

Now, it very well could be true that it’s time for you to move on, that it’s time for a change. The truth is, though, that every company has its own set of problems; the grass is brown everywhere. The secret to satisfaction is realizing what’s important to you, finding a place that checks enough boxes, and embracing it for what it provides.

How do you know when enough is enough, and how do you take inventory of what matters most? Let’s start by digging deeper into why the next might not be better than ex.

The company you work for doesn’t matter

Lie number one in the book Nine Lies About Work is that the company you work for matters, i.e., it doesn’t.

Authors Marcus Buckingham & Ashley Goodall explain that significant research has determined what makes happy, productive employees. The way this is done, they say, is by asking lots of questions to lots of teams. Then, you take responses from the highest performing teams and compare them to responses from average & low-performing teams, and look for the trends.

Through this process, the ADP Research Institute has determined that the following eight specifically-worded aspects are strong indicators of a high-performing team:

1. I am really enthusiastic about the mission of my company.
2. At work, I clearly understand what is expected of me.
3. In my team, I am surrounded by people who share my values.
4. I have the chance to use my strengths every day at work.
5. My teammates have my back.
6. I know I will be recognized for excellent work.
7. I have great confidence in my company’s future.
8. In my work, I am always challenged to grow.

These “pulse statements” are genius. It’s not obvious at first glance, but they aim to measure an employee’s sense of self (even numbers) and team (odd numbers) in each of four different categories: purpose (1 & 2), excellence (3 & 4), support (5 & 6), and future (7 & 8).

High marks indicate someone who feels good about themself, their team, and their company. Given the reliability of these indicators, one would assume the best companies have higher scores than bad companies.

But that’s not what Buckingham & Goodall found.

Instead, they discovered that companies good & bad alike tended to have the same distribution of responses. There was more variance between teams within the same company than between different companies. In other words, your team matters; the company doesn’t.

But what about all the articles and research that goes into those “best places to work” lists? Buckingham & Goodall tell us these are important influencers of why we join a company. The culture and perks are there to sell future candidates on the promise of lush, green pastures.

However, those coveted perks like 20% time, gym memberships, and free lunches lose their luster quickly, and then you’re back to the reality of being mostly at the mercy of your team. Their research supports this, too. They found that members of a good team at a bad company will stay longer than those on a bad team of a good company.

Taking inventory

Okay, so it’s the team that matters. That doesn’t change the fact that things might not feel super rosy where you’re at. How do you know when enough’s enough?

That’s a very personal question — one that’s going to be very different for everybody since we’re all at different stages in our lives & careers and have different needs & values.

Indeed, a great place to start is by self-reflecting on your own responses to the eight pulse statements above. If you’re feeling bad on most of ’em, that’s a red flag. It doesn’t mean there’s no hope, but it’s not great for your long-term outlook. (If you’re in that boat, my suggestion is to have a conversation with your boss. Tell them about ADP’s research and your responses. Consider a similar conversation with the team.)

Photo by Marc-Olivier Jodoin on Unsplash

I also love this article by Jessica Donahue, PHR. She describes a coaching conversation she had with her boss where her boss asked her to “take stock of what’s important to you at work and put those things through a force-rank.” Her boss asked her to consider things like the people she works with, growth opportunities, job flexibility, and how much money she made.How to Help Your Team Figure Out What They Value Most in a Job
Because no job or company is perfect all the time.medium.com

In other words, find what matters most.

And in her case, she determined that her company’s lack of profitability — the thing that had her questioning if it was time to move on — wasn’t as important as the things her job did provide. Her top 3 needs were being met really well. That realization helped her to overcome, in her words, a piss-poor attitude. She ultimately stayed with the company through bankruptcy and liquidation.

Conclusion

Every career is going to have its ups and downs. We’re all going to have moments where things feel less than great. It’s impossible not to look out the window and dream about what could be.

Consider what you’re leaving behind before you jump ship, though. Acknowledge that no matter how careful you are — no matter how much research and diligence you pour into searching — you’re about to enter into a game of team roulette that will ultimately decide your satisfaction.

The team matters most, and leaving a great team for a lesser one isn’t easily undone. Make sure you’re not already sitting on a great thing before being lured away by another company’s shinies. Know what’s important to you, and discuss your needs that aren’t being met. You might find it’s easier to unlock happiness by fixing your everything-except situation than it is to throw everything in the air and hope for something better. Fixing it benefits everyone.

Finally, if you go through all this — your engagement scores from the pulse statements are low, you’ve determined your most important needs aren’t being met, and you’ve had conversations with your boss to no avail— then maybe it’s time for a change. Part of the gamble is that you might end up in a better place, right? Take solace in knowing that you’ve exiting for the right reasons, and find that better something.

This article was originally published on ILLUMINATION on February 15, 2021.

Thirsty for more? Try the book mentioned in the article, Nine Lies About Work: A Freethinking Leader’s Guide to the Real World. Note that I use affiliate links when linking to products on Amazon. Thank you for your support!

Why Asking for Help Is the Most Important Behavior for Your Team

Photo by Rakicevic Nenad from Pexels

The ultimate trust-builder and collaboration-enhancer

We’ve all known that person. You like them. They’re friendly and smart. But you hesitate to let them take difficult tasks. You’d rather they stick to things you know they can handle — the kinds of assignments they’ve been successful with in the past.

We’ve all got someone at the other end of the spectrum, too. The person that, no matter what it is, you know they’ll be successful. They’ll find a way, figure it out, and produce great results every time.

It hasn’t been a matter of intelligence or competency for the people in my life that have fallen into these buckets. It’s been entirely about trust. One group lacks it; the other has it.

Like a stretchy waistband

What is it about those folks we trust so much? How can we be so sure they’ll do a great job with new and difficult assignments?

It’s rooted in past performance. They’ve demonstrated an ability to figure things out and succeed. More importantly, though, is that we’re confident they have the right safeguards in place. We know they’ll do the right things to keep us comfortable as they work through challenges and arrive at a solution.

They’ll discuss the plan beforehand, solicit feedback as they go, review when they’re done, and speak up if they get stuck along the way. These are all ways of asking for help — and they all build trust.

The number one thing that earns trust

Brené Brown uses a great metaphor for trust: the marble jar. The concept is borrowed from her daughter’s classroom system for promoting good behavior. When the class does something good, a marble is earned. When bad things happen, marbles are removed.

It’s the same with trust. When you do something trustworthy, you earn a marble. Damage trust, however, and risk losing a handful.

So, what’s the best way to fill the jar? In her book Dare to Lead, Brown shares the following observation from her research:

We asked a thousand leaders to list marble-earning behaviors — what do your team members do that earns your trust? The most common answer: asking for help. When it comes to people who do not habitually ask for help, the leaders we polled explained that they would not delegate important work to them because the leaders did not trust that they would raise their hands and ask for help.

It makes sense, right? If someone is doing something unfamiliar — something they’ve maybe never done before — and we don’t think they’ll seek guidance or check-in as they go, it’s natural to worry about the outcome. How could you not be concerned?

Everyone gets a marble

Think about the marble jar for this person that you’re uncomfortable with, that you don’t quite trust. How full is it? Probably not very.

Luckily, the solution to an empty jar is simple: start adding marbles.

When you don’t trust someone, part of the challenge is that they need to be the ones to earn marbles. Don’t worry, though, because there’s a wonderful, marble-earning solution for that, too! Ask them for help.

It takes courage and vulnerability to acknowledge a lack of trust in a relationship, particularly with someone you’ve known for a long time. It doesn’t need to be awkward, though. You don’t need to say, “I don’t trust you,” which can be harsh, ambiguous, and defense-triggering.

Instead, focus on promoting specific, trust-building behaviors. Suggest reviewing a plan before getting started. Tell them you’re happy to provide feedback at any point. Ask them to report on the status and offer help if they’re stuck. Give them space, but let them know you’re in it with them. Supporting a colleague in these ways is sure to earn you a lot of marbles.

The ultimate trust-builder

Asking for help is an underrated and insanely powerful tool. Look beyond the obvious, immediate benefits like getting your question answered. When you review a plan and get input before starting, mistakes are prevented before they occur. Soliciting feedback and double-checking your thinking improves quality and creates opportunity.

And, all the while, you’re creating a trusting, collaborative environment.

The benefits don’t end there, though. Asking questions demonstrates vulnerability and humility. It’s a signal of self-awareness, an admission that you don’t know everything. It signals to others that it’s okay to ask questions. People will be less afraid of judgment and less likely to judge themselves.

Trust is important, and asking for help is an easy, straightforward way to develop a lot. Don’t save it as a last resort. Instead, think of it as an opportunity to fill your jar. Cite specific ask-for-help behaviors missing in your interactions with others. Make asking for help habitual, so it comes naturally when help is needed most — when stakes are high and mistakes costly.

A team that trusts deeply and actively supports itself is capable of incredible things — and all it takes is for members to buy in on asking for help.

This article was originally published on The Startup on January 21, 2021.

Interested in learning more? This article was inspired by Dare to Lead by Brené Brown. Check it out! Note that I use affiliate links when linking to products on Amazon.

How I Learned to Be More Decisive and Stop Trying to Please Everyone

Photo by Victoriano Izquierdo on Unsplash

CONFESSIONS OF A CONSENSUS-SEEKER

I used to think my ability to get everybody to agree was a strength. I have strong opinions, I’m competitive, and it’s not enough to have my opponent concede when debating a topic. I need them to agree with me — to believe what I believe. This served me well early in my career, and my fiery conviction and the resulting success allowed me to rise into leadership positions.

Honestly, even as a team lead this approach worked pretty well. Looking back, I think the turning point was when I became the manager of two teams. That’s when I no longer had the capacity to be “in it” with the team on every assignment. That’s when I hit a wall with my consensus-seeking.

The Deadliest Slide at the Playground

As a team lead, I did the best I could. Of course, I didn’t really know what I was doing and was mostly making it up as I went. That’s not to say I didn’t try or that I did a bad job. It’s just that I’m a learn-by-doing sort of person, so even though I’d read and done research on what it meant to be a good boss, it took some time and experience for concepts to set in.

The pattern continued as I moved into management. I wanted to be a “manager of the people” — to empower the team, and to give them a voice and sense of ownership. But they didn’t always agree among themselves about what needed to be done or how to do it. (Who’da guessed?) On top of that, I had my own opinions about what was best. This is where consensus-seeking started to be a problem.

The team would go on and on about a problem and then, just as they’d be coming to a conclusion, I’d weigh in with my 2 cents and reset the whole conversation. You know the big slide in the board game Chutes and Ladders? The one right toward the end that basically takes you back to the beginning? It was kinda like that.

And, because I needed that consensus, I’d keep the debate going as long as people continued to disagree. I just felt like, if we could all understand each other’s perspectives, we could find a solution we all agreed on.

I knew it was a problem. I could feel the team spinning, and we were spending more time coming up with plans than it would take to execute them. Feedback from the team provided clear supporting evidence in my performance reviews, too.

Could be more decisive. It’s good to listen, but sometimes the team just needs someone to choose. (paraphrasing)

Message received. I wasn’t surprised, though. I knew it was coming, but it still stung a little to be forced to acknowledge my shortcoming in a more official way.

Melancholy and the Infinite Debate

Analysis paralysis was certainly a key problem caused by my consensus-seeking. We’d talk and talk and talk about a topic or design, then reserve ourselves to continue the discussion in the next meeting. It was exhausting.

But, having no decision and pressure to make progress, the team would soldier on, with fatigue from the endless debate taking its toll. Even if it was my idea that “won,” it didn’t feel like winning. My effort to make everybody happy had done the opposite — everyone was miserable!

That gave way to the second major issue: lack of commitment. With so much discussion, people would lose track of what we were even trying to accomplish. Or, worse, they’d stop caring. I was mentally beating them into submission, and they just wanted it to end.

Team members would shake their heads and ask, “So, what are we doing?” They had no energy and just wanted to get on with it. It’s a real feelsbad moment to look into the defeated eyes of your team and explain that you’re just going to do the thing that you all talked about so long ago.

Can we all agree that consensus is horrible?

My a-ha moment came while reading Patrick Lencioni’s book The Five Dysfunctions of a Team. The main character, Kathryn, is speaking and says the following:

“Consensus is horrible. I mean, if everyone really agrees on something and consensus comes about quickly and naturally, well that’s terrific. But that isn’t how it usually works, and so consensus becomes an attempt to please everyone.”

It feels dumb and obvious, but I literally stopped and thought, Oh no. That was it, that was my problem. I continued reading.

“…some teams get paralyzed by their need for complete agreement, and their inability to move beyond debate.”

Yep, that was us. I was worried that people would be upset by not having their idea picked, so instead, I chose to pummel them into having the same idea. Reading about my own behavior in the context of the book was reassuring, to know that the bad thing I was doing was prolific enough to be addressed in a novel about the bad things we do. Still, not a great feeling to know that I had stepped into a common pitfall.

I always tell my teams that I’d rather have a problem we know the solution to than one we don’t, though, and this was one of those cases.

In the same chapter, another character speaks up about “disagree and commit” which is a popular idea that’s been written and talked about by many people, including Jeff Bezos. The concept is simple: it’s okay to disagree, but once the decision is made, everyone commits to it.

Certainly, that’s the philosophy I need to embrace, I thought. The hard part about decision-making was the fear of being wrong. I needed consensus because, if we all agreed and were wrong, we’d be wrong together. I didn’t want to force my decision on the team to have it rubbed in my face later by bitter and spiteful colleagues.

Because they’d be bitter and spiteful… Right?

A Breathtaking Detour

Making decisions requires a constructive environment filled with trust and communication, and my consensus-seeking didn’t provide that. I felt like we needed to talk things through because people would be upset if we didn’t do it their way. And it wore them down. Instead of looking for the best solution, they were looking for a way out.

However, it turns people don’t need to get their way to be happy. They need to feel heard. Having a voice makes us feel safe, like we’re in control. We want to know that if we call out danger, the team will steer away from it. Similarly, if we know a safe path, the whole team benefits from taking it.

Imagine you have plans for dinner at a restaurant with a friend. You and your friend have many choices for how to get there. You can take highways or backroads. You can drive yourselves or take public transportation. You can go separately or together. There are a few tradeoffs with each decision, but for the most part, they’re inconsequential.

Now, let’s say you know about some construction on one of the roads. You tell your friend to avoid that route because of significant delays, but they take it anyway and show up super late. You’d probably be upset, right?

Conversely, if they show up on time, you probably don’t care which specific path they took to get there. Maybe the same construction takes them through a scenic part of town, so your friend left early to enjoy it. You wouldn’t mind that they ignored your advice. It wouldn’t prevent you from enjoying each other’s company and having a good time — it might even give you something to talk about!

It’s the same with most team decisions. If you can agree on what you’re trying to accomplish, listen to everybody’s input, and make a reasonable decision, it doesn’t usually matter which specific path is chosen. What matters is that you get to where you’re going.

The Destination vs. The Journey

We’ve all heard the popular adage about road trips: it’s about the journey, not the destination. The idea is that the experiences you’ll have on the way to your destination will outweigh the ones you’ll have once you arrive. The point of these sorts of trips is usually to have experiences, and the journey is long and thus provides many experiences, so there’s truth to the statement.

When you have several options to choose from, you’ll often find yourself in one of two buckets. Choices will be equal or have tradeoffs. When all things are equal, it’s like meeting your friend at a restaurant. It probably doesn’t matter. Pick and move on. Most decisions have tradeoffs with multiple factors being influenced to different degrees, though, and that’s what makes them so tricky.

The reason they’re difficult is that people have different values. The best decision for me is different than the best decision for someone else, and neither of us is wrong — we just have different values. For example, one of us may value speed to market whereas the other values robustness of features. This is sort of a destination-vs-journeyquestion all in itself! Is it better to reach your destination quickly to benefit from more time or go a bit slower and arrive more prepared?

The question to ask yourself is, what are you trying to accomplish? This is why it’s so important for leaders and stakeholders to set goals and priorities: to enable the team to make decisions.

But, even if all that fails, there’s some good news. In the absence of a clear winner, you’re somewhat back to the all-things-equal scenario. There is no right or wrong when the deciding factor is subjectivity, so choose and move on.

The only losing move is not to choose.

As a former consensus-seeker, I hope I’ve said enough to convince you — to make you believe — that consensus-seeking is bad.

The two major problems with consensus-seeking are time lost and lack of commitment. You sacrifice time with endless discussion, and with no decision, there’s nothing to commit to.

For that reason, any decision is better than no decision, even if it proves to be the wrong choice. Being wrong is often more efficient than trying to ensure you’re right, and conducting marathon debates won’t save you from mistakes, anyway.

Consensus is painful, and you don’t need it. What you do need is commitment. Seeking consensus will drain energy and morale whereas listening and incorporating feedback will build trust. When the team trusts you, they’ll support your decisions, and that’s how you get commitment.

Energy saved by skipping analysis paralysis now gets applied toward the commitment, and a positive cycle begins. Commitment and energy lead to results. Results earn trust and influence, which then get applied to the next round of decisions.

Making decisions is more important than the decisions themselves. Know what you’re trying to achieve, listen to your team, and make a decision. Everyone will be happier and more productive for it.

This article was originally published in The Ascent on January 5, 2021.

The Fault In Our Loyalties

Photo by Thomas Evans on Unsplash

Having the wrong “first team” may be driving intergroup conflict throughout your company

Regardless of your position in a company, you’re probably a part of multiple teams. You have an immediate team — the people you work with every day. There’s another team made up of everybody in your department, and you might also be on a team with peers from other departments. And within those teams, there might be even more virtual teams that you belong to.

The point is, you’ve got a lot of teams beyond the one you’re assigned to on the org chart.

But, all those teams have a common goal. They all want the company to grow and succeed and be an awesome place to work. If everybody and every team wants the same thing, what’s the problem? Why do you need to know your “first team” and prioritize your allegiance?

The plan is nothing, strategery is everything

For most of my life, commitment & accountability have gone hand-in-hand as the formula for success. Set a goal, commit, and get it done. So, as I’ve landed in leadership roles, it’s something I’ve emphasized a lot with my teams.

That’s not bad, per se, but I was encouraging commitment at the wrong level. I wanted team members to commit to completing an assignment within a certain timeframe, then hold themselves accountable to get it done. However, that sort of commitment has proven to be too low-level and individual-focused.

You can’t emphasize execution without buy-in on strategy.

What I’ve come to realize is that commitment is much more effective when used to obtain buy-in from the team on a particular strategy. In other words, it’s really powerful when the team can agree, “We’re going to accomplish X by doing A, B, & C,” and commit to the approach. You can’t emphasize execution without buy-in on strategy. I’d been looking for people to commit to A, B, & C without understanding or agreement on what we were trying to accomplish.

I was doing everything I could to make execution of assignments go as smoothly as possibly — and being marginally successful — but it wasn’t until I read The Five Dysfunctions of a Team by Patrick Lencioni that I came to see I was prioritizing my teams incorrectly and creating unnecessary turbulence as a result.

In the book, members of a fictional executive team learn to prioritize shared objectives above the goals of their individual departments so the company can succeed. They prioritize themselves as a team and align on strategy. Departments begin working together to achieve common goals rather than competing for resources, and they experience success as an organization rather than as disconnected teams. It’s beautiful.

Overarching goal, all the way across the sky

Every team will have an opinion on what’s most important and how to achieve success. The sales team will tell you sales are the key: “Great product doesn’t mean anything if nobody buys it, and revenue is our lifeblood.” The product team notes, however, that this is why investing in the product is so crucial. “If you have a superior product, selling is easier!” Finance might say sales and product mean nothing if you spend irresponsibly and manage money poorly.

The thing is, each of these teams is right. Their perspectives are valid and true. What’s most essential, though, is to have an overarching goal— an objective that all the teams can get behind and rally around. Something to unite the clans.

“If everything is important, then nothing is.”

An overarching goal is important because, as CEO Kathryn notes in The Five Dysfunctions of a Team, “If everything is important, then nothing is.” The goals of individual teams are certainly important, but the leadership of those teams needs to commit to a greater objective. Without agreement at the top, conflict will trickle down through the ranks and become more severe at it seeps deeper in the company.

The whole is greater than some of its parts. Or whatever.

In order for the company to be truly successful, all teams need to achieve some level of success. No single team can carry all the others, but one failing hard enough could lead to disaster. It doesn’t matter if your team hits its numbers if everything else burns to ash.

I’m a competitive person. I want my team to be the best and most successful. It’s easy to look at peer teams and think, “Not my problem. We’re doing our part.” There’s even a certain amount of pride in that, right? To know that you’re winning by out-pacing the others? But I also know that my team’s only part of the puzzle, and our performance won’t mean as much without the other teams succeeding.

For the company to succeed, all teams need to work together to maximize strengths, mitigate weaknesses, and understand how they’re doing collectively so they can adapt and win. This is where the concept of your first team becomes so important. You shouldn’t just listen to your peers explain what’s happening on their respective teams. You should be invested in it. You should be on the same page about what you’re trying to accomplish together— the overarching goal — and be willing to adapt as a group in order meet your objective, because that will make the company successful.

The concentric safety dance

One of key themes in Simon Sinek’s book Leaders Eat Last is the importance of the circle of safety. The idea is that when a group trusts each other and doesn’t need to worry about internal threats, it can focus all of its energy externally which allows the group to succeed.

Imagine an organization where all the leaders are in the middle of circles that represent their departments, divisions, or teams of direct reports. The individual teams are united and working together well, but they’re treating other teams within the organization as external threats. That makes for a tremendous amount of energy wasted on intergroup conflict.

Now let’s adjust the picture so that the leadership team forms their own circle of safety in the middle. When this group trusts itself and has a shared vision, its energy can all be focused outward to the next layer of team. When all teams are being directed toward common objectives, they can also learn to trust each other eventually form their own greater circle of safety.

Come down from the mountain

Deciding that you’re more committed to one team than another doesn’t mean the other team is unimportant or somehow less valuable. Those other teams, especially the one made of your direct reports or day-to-day peers, are extremely important. It’s critical to invest heavily in those teams and relationships, but prioritizing your allegiance will improve the efficiency of all your teams immensely.

Google research has shown that psychological safety is the number one most important factor for effective teams. When leadership agrees on an overarching goal and strategy for achieving it, it leads to commitment. Commitment within leadership translates to clearer messages around what needs to be accomplished by their teams — the commitment travels down and across the organization. Cross-team alignment means less conflict and less internal threat, which in turn allows teams to focus more of their energy outward and toward achieving the common goals. A tidal wave of commitment can wash over the entire organization.

It starts with leaders prioritizing themselves as a team and putting the interests of the company ahead of those of their specific departments.

Ask yourself, who is your first team? What’s the overarching goal that the team is trying to achieve, and what’s the strategy for achieving it? How is the team progressing, and how can it use its collective resources to adapt?

Work together as a leadership team. Set an overarching goal, commit to a strategy, and hold each other accountable to execute your parts. With clarity and commitment, all teams can contribute and support each other in helping the company achieve its goals, and the company will grow, succeed, and be an awesome place to work.

Want to learn more? Check out these books! Note that I use affiliate links when linking to products on Amazon.

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni
Leaders Eat Last: Why Some Teams Pull Together and Others Don’t by Simon Sinek

This article was originally published in ILLUMINATION on December 23, 2020.

Conference Call Less, Smile More

How to keep engaged with your team when you can’t stomach another #$@!ing conference call

It’s 2021. The offices are closed, and you’re working from home. It’s 8:59 am, and in 1 minute, your next day of conference calls begins. And you just don’t want to do it. <expletive>.

It’s okay. We’ve all been there, so much so that the idea of “no meeting days/weeks” is gaining in popularity. If you can get your team and boss to buy-in, that’s probably the best way to give everyone a much-needed break. That’s not always an option, though, and even if it is, it’s something that needs to be scheduled and coordinated with the team. What if you need relief today?

The bad news is that you can’t ditch your team entirely; you need them, and they need you. However, take it from me — a grizzled work-from-home vet — there are ways to isolate yourself and fight call fatigue without completely ghosting your coworkers.

That last point’s worth repeating: don’t just disappear. When you go dark, your boss and teammates start to question your contributions and effort, and the more you do it, the worse it gets. Before you know it, you’re on the downward spiral of broken trust and poor performance. It’s much better to wrestle this beast out in the open, where everybody can see, and leave no question about your commitment and dedication — but, just, for the love of god, not on a video call.

Know thy tools

The first thing you need to do is assess what’s available in your toolkit. How does your team communicate? Most teams have a few different ways. Mine, for example, uses Slack and Teams in addition to everyone’s good friend, email.

In addition to those pure communication tools, you’ve probably got some collaborative tools, too, like Jira or SharePoint or Miro or Asana. You know, the apps you use to actually get things done? Yea, those. The reason these apps are so popular is because they make sharing & collaboration easy.

Here’s the secret with these tools, though. If you’re going to use them in lieu of actually talking to the people you work with, you need to use ‘em, like, extra. Catching up on email? Post a message. Writing a report? Share it. Taking a bathroom break? Okay, keep that one to yourself… But, updating those revenue projections? Shout it out! It doesn’t need to be every 5 minutes, but it should be enough so that there’s no question about whether or not you’re there or what you’re working on.

Maintaining this level of visibility isn’t just so people know you’re working — it also lets the team know you’re available for them. That’s half of what makes all these calls and meetings necessary. You know things! And people need to suck those things that you know out of your brain in order to do their jobs. You might be loving life and having the most productive solo day you’ve ever had, but if three people are stuck on a call trying to figure out what they know you know because they think you’re unavailable, it’s not going to reflect well on you.

Honor your commitments

We were on a break.
— Ross Geller

Just because you’re on a break doesn’t mean you get to do whatever you want. Making all that noise about the things you’re doing won’t mean much to your team if you don’t deliver. You’re exhausted. You don’t want to talk. That’s okay, but it’s going to take a little extra work on your part to get the same results.

A critical part of honoring commitments is having some commitments. This goes hand-in-hand with my previous point of over-communicating and keeping visibility high, but it requires a little planning and forethought. Lay out the next few things you plan on doing so the team can coordinate and avoid duplicate effort.

Don’t be afraid to be a little ambitious with your goals, too. You’re on a team that’s trying to accomplish important things. Don’t phone it in while you’re… not phoning in — sign up for something meaningful.

With a few commitments in hand, it’s time to demonstrate your worth. I’ve got no problem with anybody on my team working whatever hours they want when they get their work done — so get your work done. And you better double and triple check it, too, because you lose some some quality safety nets when you fly solo. The goal is to make sure nobody has anything to complain about, so you need to make sure you catch the problems that would’ve been caught by doing the same work collaboratively with the folks you don’t want to talk to.

The key word here is “dependability.” You want the team to know that when you take an assignment into your bunker, they don’t need to worry. They can check it off the list. They’ve called in the closer, and you’ll find a way to get it done.

End of day wrap-up

Before you sign off for the day, send a status update to the team. You’ve been keeping your visibility high, so everybody knows what you’ve been up to, and you’ve put a little extra elbow grease on your deliverables to make sure quality is top-notch. Now it’s time to wrap-up all that ass you’ve kicked with a big, beautiful bow on top.

The end-of-day update is important and valuable for several reasons. The team knows you’ve been active but stating what you’ve completed shows them that you actually achieved things, too. It’s a chance for you to punctuate your effort and commitment. Those meaningful things you signed up for earlier? Yea, they’re done.

The status update sends the message that you worked hard to accomplish things for the team. It took you a little longer, but you got it done — and then you cared enough to summarize the journey. This is a great chance to showcase some leadership skills and sense of urgency, too. What needs to happen next? Who’s responsible? Make some callouts to help ensure that none of the momentum you’ve created will be lost.

Conclusion

Being on conference calls all day, every day is just plain exhausting. We all need a break, but the collaboration that pushes us to keep having them is important and valuable — it can’t be ignored. The answer to call fatigue is not less communication but different communication.

These “tips” are great advice for anybody that wants to be more effective, whether you’re dodging your co-workers in meetings and conference calls or not. Similarly, if you don’t do these things, it will ruin your team. People won’t trust you to complete your work. They won’t try to collaborate because it’s easier not to. They’ll resent you for not pulling your weight.

The stakes are a little higher when you’re working asynchronously, though, because you’re not “in the room” to defend yourself against misperception. You can’t explain why something took 3x longer than everyone thought it would or that you didn’t get to one thing because another, more important task cropped up.

None of this is hard, though; it just requires thoughtfulness and awareness. Communication and collaboration. Visibility and transparency. You can follow the same basic formula that’s often prescribed for presentations and writing: say what you’re going to do, do it, then say what you did. This keeps you highly-visible and transparent while also being present and available for the team. Commitment and accountability ensure that you produce results, and the end-of-day report is the cherry on top, helping everyone to build on your success.

This article was originally published in ILLUMINATION on November 25, 2020.

10 Behaviors to Make Your Team Great

Is your team greater than the sum of its parts?

My team was in a bit of a rut. There was no trust and poor communication. People weren’t collaborating, and there was no transparency into anyone’s days. Updates in our daily standup meetings were vague and non-committal. Morale was low. Things just weren’t getting done.

I knew it wasn’t a people problem. I’d been with most of the team for years, and everybody was smart and talented. No — this was definitely a behaviors problem.

But, while I could feel the problems, I didn’t know how to articulate them. Before I could address the issues, I needed a better understanding of what they were, and I needed to establish a vocabulary with the team to facilitate a discussion. Only then, with awareness and buy-in, could we begin to implement change to improve our effectiveness.

Good Behaviors, Bad Behaviors

I was discussing the team’s underperformance and collaboration problems with a colleague, and they joking-not-jokingly proposed doing a Five Dysfunctions of a Team exercise. (Disclosure: as an Amazon Associate I earn from qualifying purchases.)

It had been a while since the five dysfunctions had been front of mind, and I had to look them up for a refresher. “Let’s see what we’ve got here,” I thought as I clicked through some search results.

Absence of trust — check.
Fear of conflict — yup.
Lack of commitment — oh yea.
Avoidance of accountability — definitely.
Inattention to results — mhmm.

Wow. We had ’em all. People on the team didn’t trust each other to complete assignments. Rather than confront the lack of trust, they preferred to work alone on whatever they felt was most important. Updates in standups would be, “I worked on some things and will figure out what’s next,” and people would leave for a coffee and disappear for the rest of the afternoon. Meanwhile, user stories would drag on for days and weeks with no sense of urgency. Yikes!

The five dysfunctions also reminded me of Project Aristotle. This Google Research project attempts to answer the question, “What makes a team great?” One of their key findings was that effectiveness depended more on how the team worked together than who was on the team. In other words, team dynamics and behaviors matter more than people and individual performance.

…what really mattered was less about who is on the team, and more about how the team worked together

Google’s “five effectiveness pillars” go with the five dysfunctions like peanut butter goes with jelly, combining to create a gooey smattering of team efficiency — and they gave me exactly what I was missing most: a vocabulary for talking about the areas we needed to improve and ways to communicate the importance & impact.

The Actions in Action

I had the concepts. Now I needed to deliver the message. I decided to put together two hypothetical situations based on our very real problems to illustrate the impact of these behavioral patterns & anti-patterns.

Example One. In standup, a dev says, “I’m going to work on implementing the Thingamabob. I’m going to try to complete tasks A, B, & C today, then we can test and close it out tomorrow.” In the afternoon, they say, “Something came up and I need to leave for a few hours, but I’ll be back to finish up. I completed task A and am almost done with B.” They come back later when everyone else is offline, complete task B, and leave a note before signing off: “Completing task B took longer than expected, but I got it done. I wasn’t able to get to task C. I’ll pick it up first thing in the morning.”

Example Two. In standup, a dev says, “Not sure what I’m doing today. I might start working on implementing the Thingamabob.” They start working on the story to implement the Thingamabob and complete task A plus part of task B. They need to leave for a few hours, but they don’t say anything. They come back later when everyone else is offline and complete task B.

In both examples, the person might’ve been equally productive, written brilliant code, and completed the same tasks. In both cases, the person had to leave for several hours, and in both cases they didn’t complete the (stated or unstated) goal of finishing task C.

However, the first example demonstrates all of Google’s dynamics of great teams.

Psychological safety. The dev wasn’t afraid to share status or go away because of other responsibilities; they felt safe to let the team know they didn’t complete their stated goal.
Dependability: The developer made commitments in standup and was transparent about progress and effort.
Structure and clarity: They communicated status so the team had awareness, which allows the team to adjust its actions and priorities. (For example, this could allow someone else to jump in on completing task B while the developer was away, and upon returning they could complete task C versus only completing task B.)
Meaning: The developer appreciates having a job that allows them the flexibility to take care of other responsibilities during the day.
Impact: Ensuring progress and helping the team achieve its goals feels good.

Conversely, the second example exhibits symptoms of all five dysfunctions.

Absence of trust: Low visibility and poor communication lead the team to wonder what the developer is working on.
Fear of conflict: Sporadic availability makes it hard to collaborate; team members become exasperated and prefer to work alone.
Lack of commitment: The developer was non-committal in standup, and the team has no expectations or ability to coordinate.
Avoidance of accountability: No commitments and poor visibility & availability; the dev does nothing to demonstrate their effort.
Inattention to results: Individual behavior prevents the team from achieving its goals.

All this is to say that, in order to be an effective team, individuals must focus on their behavior and interactions with teammates more than just being productive themselves.

Staging the Intervention

Okay, I had my ideas to share, and I had my plan of how I wanted to roll my message out to the team — it was time to put the wheels into motion.

The first thing I did was to send an email using the examples above. My messaging (paraphrasing) was, “Hey, team — I’ve been thinking that we haven’t been as productive lately as we’ve been in the past. I think we’re exhibiting some of the Five Dysfunctions of a Team, and we’ve lost some of Google’s pillars of effectiveness that we had previously. Consider these examples.” I also shared my analysis about how the examples were illustrative of the five dysfunctions and effectiveness pillars.

I didn’t really get feedback on the email, but there was a mention here & there in standups and retrospectives. I feel like the email did a fine job of planting the seed and helping to establish a vocabulary for the conversation. Mission accomplished there, I’d say.

Step two was to solicit feedback in one-on-ones. I’d ask people what they thought about the email and how they felt about the team in that context. These conversations were helpful because it confirmed my feelings and demonstrated that others were experiencing similar frustrations. This also helped to establish that we were all on the same page and had similar perceptions of our team strengths and weaknesses.

Finally, I decided to bring it up in the team’s sprint retrospective. I was blunt with them. I said, “I don’t think the team is doing enough to demonstrate commitment & accountability.” It took some courage, but I had to trust the team and not fear conflict — to practice what I was about to preach. The groundwork I’d laid proved valuable. People referenced the email I’d sent, and we’d all had miniature versions of the discussion in one-on-ones. It was a really productive conversation and a catalyst for positive change.

Things didn’t fix themselves overnight, but we began trending positively in just a week or two. People started giving updates like, “My goal for today is …” and leaving messages at the end of the day to highlight what they did and didn’t accomplish.

If your team can buy-in on the importance of these dynamics and be self-reflective & honest, it can lead to some pretty incredible growth — even on a team that’s already high-performing and seemingly happy. Awareness of these dynamics can turn things around on an underperforming team or protect a happy, productive team from growing pains and evolution.

My team isn’t perfect, but we’re getting better every day. The next step was to continue the momentum. We planned a recurring team meeting to focus on these behaviors and team growth to increase introspection and awareness, but the best way to keep improving is by walking the walk. Psychological safety, trust, commitment, accountability, and no fear of conflict allow us to continue having productive conversations and ensure that we stay on track to accomplish great things together.

Resources:

Originally published at The Innovation on November 20, 2020.

Scope Like Goldilocks

How to control scope and navigate the spectrum of engineering excellence versus business needs

Photo by Toa Heftiba Şinca from Pexels

There is no single right answer to any non-trivial problem in software engineering. So, if multiple correct solutions exist, how do you decide which is best? It’s difficult to determine which is best because “best” is highly subjective and deeply personal — your opinion is formed from your individual collection of experiences, strengths & weaknesses, and values on related aspects like simplicity, maintainability, & scalability.

It’s these internal values that make all of this so tricky. Imagine a spectrum with engineering excellence at one end and business needs at the other. Both elements are required for a project to be successful, and operating at either extreme can be detrimental to the other. As an example, making too many quick-twitch fixes to address urgent business needs can have significant long-term impact on the quality of the code base or system maintainability; conversely, focusing too deeply on engineering excellence can lead to over-investment in areas or competitive disadvantages from being slow to market.

Understanding this spectrum — and having awareness of where you and your colleagues lie on it — can help your team to be more pragmatic.

Awareness of this spectrum alone isn’t going to do you any favors in resolving conflict from perceived disconnects between you and co-workers, though. I’ve found myself in design/requirements stalemates many times, and I’ve used the spectrum as a way to visualize my frustration.

“You see, I live over here on one end of the spectrum,” I’d say, “and my colleague operates here, at the other end. We can’t agree on scope, and we aren’t getting started or making any progress as a result.”

The problem with the visualization as a tool for conflict resolution is those pesky personal values. Neither of us thinks we’re advocating for a solution that would be in the unhealthy extremes of the spectrum. The person in the engineering excellence camp just believes that business value is generated by following all the best engineering principles and creating scalable, high-performing, resilient applications whereas business needs nation wants quick delivery and maximum responsiveness to meet the ever-changing needs of its customers.

So, how do you find compromise when the source of conflict is so visceral?

Let’s see if we can steal a page from the Goldilocks playbook. She’s got a knack for identifying the undesirable ends of a spectrum before settling into a satisfying sweet spot. If you and your team or colleague(s) can’t agree on the scope of a solution, can you agree on what it shouldn’t be?

What’s a reasonable solution that everybody agrees is over-engineered, and what’s the fastest, but perhaps short-sighted, thing you could do? What’s the effort required for each approach, and what are the risks or consequences?

Just to be clear, I’m not suggesting to simply compare different proposals by plotting them on the spectrum— that probably won’t get you anywhere. Instead, work collaboratively to come up with bad solutions that lean too far in both directions. Find agreement by identifying undesirable characteristics of these options in the unhealthy parts of the spectrum.

Still not able to find compromise? It’s probably time to bring in a 3rd party, preferably a stakeholder. Show them your spectrum and explain the tradeoffs that exist at the opposite ends, then present the “real” options that are on the table and allow the stakeholder to decide.

The whole activity is an exercise in pragmatism. How can two parties with equal but conflicting opinions find common ground? The key is to calibrate and remove as much subjectivity as you can. By acknowledging the necessity of both aspects — engineering excellence and needs of the business — and agreeing on the “bounds” of the spectrum, you create a framework for identifying the region for compromise. That’s your sweet spot. That’s likely where your “best” solution should be.

Originally published at The Startup on September 21, 2020.

What RPGs Have Taught Me About Effective Software Development Teams

I grew up as a computer kid in the 80s and 90s and, consequently, spent a lot of time in video games. Now I manage two software engineering teams, and it’s time to prove to Mom that all those hours spent in Final Fantasy were actually valuable career development.

I’m primarily thinking about two video game genres: party-based RPGs and MMORPGs. The formula for these is pretty simple. You have a cast of characters with various capabilities, and they work together to accomplish amazing things. In order to succeed, you must be aware of your characters’ strengths & weaknesses, understand what skills are required to complete a challenge, and combine characters in a way that allows them to achieve the goal.

Well, that doesn’t sound so different from a software development team, does it? You’ve got a group of people with different abilities and aptitudes; you have a backlog of stories to complete; and the team must collaborate to achieve goals and accomplish amazing things. It’s, like, the same thing!

Given these undeniable parallels, what lessons from RPGs can be applied to software development teams?

It’s Dangerous To Go Alone

When you adventure alone in a video game, bad things don’t happen most of the time — but there’s risk. The same is true in software development, especially if individuals on your team are all working on separate things. The primary risks of soloing a software development project are consistency, quality, and knowledge-sharing.

Working alone on projects offers short-term risk due to the fact that quality and completion time are largely dependent on who does the work. Someone who’s very experienced and understands the subject area well will probably get by fine, but a developer with less familiarity will take longer and be more likely to make mistakes that require re-work. Peer code reviews are slower and less effective because reviewers need to context-switch and focus deeply to understand decision-making and what’s been done. Individual stories are completed less efficiently because everyone has their own assignments and agenda, and other people’s work becomes a secondary objective.

Knowledge-sharing and information silos are the long-term threat. It’s easy for people to become specialized as certain types of work gravitate toward them. If an individual is the only one that worked on a specific project, guess who gets tapped when it needs attention later? Future work can also be bottlenecked when the person with all the knowledge isn’t available, and the situation gets worse when that same person is the bottleneck for multiple workstreams or when personnel changes occur.

In the video game world, the risks and consequences of soloing are typically limited to just you. People choose to solo because it’s convenient — they don’t want to wait or look for other players — or because they enjoy the challenge. Sometimes it feels easier to go it alone in software, too. However, software development is a team game, and you’re not typically looking for extra challenge just for the fun of it.

Ensuring you have multiple people working on a project mitigates the risk. One person doesn’t go down a bad path by themselves, and at least two people should know how things work and why decisions were made. Pair or group programming is inherently review-as-you-go which leads to better initial code quality, and that in-turn helps with completing stories efficiently due to less feedback cycles and re-work.

You don’t want everybody acting alone, but it’s equally important to make sure you don’t have too many resources focusing on a task. In other words…

Bring the Right Group

Quests in RPGs require a certain set of skills to complete. Easy quests are achievable by smaller, less experienced groups, but hard ones require more people, specific skills, or other special assistance. In games, it may seem more efficient to clear easier, low-level content with powerful, advanced characters, but if the strongest characters are focused on easy things, it means they aren’t working on more challenging, higher-reward objectives.

Software development is an exercise in efficiency. You have a backlog filled with user stories. Some are easy and some are difficult. You want to complete them all, though, and the faster you can do it, the better. The trick is for the team to determine the optimal way to complete as much as it can as possible as quickly as possible.

How would you do that in a game? First, you’d decide which quests are most important and what skills they require. Next, you’d look at which characters are available and what skills they possess. Then you can optimize who can do what. Perhaps one small group could tackle three easy quests while another group works on a single complicated one.

This same strategy can be applied to sprint planning. You’ve got stories in a prioritized backlog and a team of people to complete them. Which people have specific skills or knowledge required to complete the highest-value stories? Assign those folks first. Who’s left, and what’s the best way to utilize them? Make sure everybody is assigned, and balance the groups.

You may find that you don’t have enough people with the right skills to succeed with all the most important things. Luckily, RPGs give us a solution for that, too!

Level-up All You Characters

Characters in RPGs progress by completing tasks that reward experience. Once you’ve accumulated enough experience, you level-up and become stronger or gain powerful new abilities. In order to have a well-balanced team, you must use all your characters so they all gain experience. If you have a weaker, low-level character, you can grow them most quickly by leaning on them as heavily as possible in content that’s within their reach. Sometimes that can be painful, if you need to return to a low-level area and perform low-value activities, but the investment pays off with time. Once those characters “catch up” they provide valuable versatility to the team.

On a software team, this means ensuring that everybody’s getting reps with the most important skills. People won’t suddenly gain project management skills by not managing projects. Instead, acknowledge it: “I want you to manage this project so you can develop these skills.” You want someone to be a better decision-maker? Ask them to make decisions. Similarly, just because someone can do a thing in 15 minutes doesn’t mean they should do it simply because it would take someone else 2 hours. Instead, invest that 2 hours. The experience is as valuable as the time saved, and it contributes to both the growth of the individual and the strength of the team.

To be a successful team, there are multiple roles that need to be filled. As employees gain experience, they typically focus on a single role. For example, “I’m a developer, and this is what I do as a developer.” Often times, that’s enough to do a good job, but a great team member understands all the roles within the team and has the ability to recognize and step in when a role isn’t being fulfilled.

How do you develop that level of situational awareness?

Learn the Mechanics

Often times, games have encounters with mechanics that need to executed in order to succeed. You can win by knowing enough to go through the motions, but the best players don’t just know what to do — the know why they’re doing it. That also means understanding the consequence for not doing a particular mechanic and being able to adjust on the fly when things start to go sideways.

Software teams have a process designed to help the team succeed or — more pessimistically — prevent it from failing. Individual contributors can be successful by adhering to the rules and following the process. Great teammates will understand the underlying reasons for the process, though, and be able to make decisions around when it’s time to deviate.

Much like in games, a great way to become more familiar with the intricacies of your process is to learn it one role at a time from people who are already proficient. How does your team gather requirements and translate them into actionable work? What’s the best way to do a peer code review? What tests need to be run to verify there are no regressions? With better understanding, you can help improve these processes. Don’t just learn how to do things; learn why to do them.

These lessons from RPGs aren’t necessarily special or specific to software development; they’re just general best practices for teamwork and growth.

Recognize the strengths and weaknesses of individuals on the team, and utilize them in a way that makes sense — just like you wouldn’t have your squishy wizards standing in front of heavily-armored knights in a game.

Use the right number of people based on the task. There are both short and long term risks associated with using too few people but possibility for reduced efficiency & throughput with too many. It’s also important that the group have the right set of skills to accomplish the goal. Don’t poke the dragon alone, don’t bring the entire village to feed the horses, and don’t send a small group of adventurers into the dark cave without a torch.

Build your team by ensuring that people have the opportunity to grow. Acknowledge that having somebody less skilled perform a task pays dividends as they gain competency. If you don’t give people the chance to improve, they won’t. Having more people at level cap lets you tackle a wider array of challenges or accomplish more things at once.

Invest in helping team members understand the big pictures. What’s the greater purpose behind your team? Why do your processes exist? Encourage people to learn new roles and step outside the bounds of their specific job. The increased awareness and versatility differentiates good teammates from great ones. In an epic RPG boss fight, you can still win if somebody knows how to kite when the tank dies.

Know the team, grow the team. Use the right skills to get the kills, and collect that sweet, sweet loot.

Originally published at https://adamprescott.medium.com on October 5, 2020.

Transitioning from Developer to Manager

It’s not uncommon for successful software developers to find themselves in leadership positions. There are many possible leadership trajectories, one of which is management. Moving into management was scary for me, and over the years I’ve talked to a number of people at that point in their careers experiencing a similar dilemma. This is the story of my experience, why I made the decision I did, what I’ve learned along the way, and how it’s turned out.

The pre-management era

Let’s start with a little about my background, eh? I started my career as a junior developer and worked my way into a senior role, eventually becoming an architect. As an architect, I served as the technical lead for my team and worked closely with managers to make various leadership decisions. I wore many hats in order to best address whatever I felt my team needed most at the time.

After nearly 10 years with my first company, I left to join a former co-worker at a startup. At the time, this new company was small enough that we didn’t have much of an organizational hierarchy. We were a group of senior developers that all had decision-making authority with freedom to work on what we felt was most important. We still collaborated, of course, but we weren’t all chipping away at a common product backlog.

The loose structure worked great for us as a small team, but it doesn’t scale. As we added more people to the team and new products to our catalog, we needed more structure. We divided into product-specific teams with narrower focus and dedicated backlogs. That was our no/low-management tipping point, and that’s where my journey into management begins.

My boss was suffering the consequences of our very flat organization, and they needed people willing to take on some of these managerial responsibilities. I felt like I was being forced to commit: did I want to be a manager or not? I wasn’t given an ultimatum; in fact, my boss was very clear that there was no wrong choice, and my career would continue to grow regardless. That was comforting, but I still had the decision to make.

The management path was scary for a variety of reasons. I had a proven track record as a developer. I was good at coding and troubleshooting. I knew how to solve software problems. Managers take on an entirely different set of problems that require a different skills — skills I wasn’t sure I’d have. Managing a team when things are going well didn’t seem so bad, but it’s the whole “dealing with people” thing that had me worried. Did I really want to give up coding — the thing I enjoyed and had built a successful career doing — to be a manager and have to deal with people?

Making the decision

I ended up lingering at this juncture for a while. Depending on the day, I might’ve leaned one way or the other, but for the most part I remained undecided and non-committal. In my free moments, I’d research what made a good manager and read stories like this one to understand other people’s experiences. There were a few nuggets of wisdom that helped me make my choice.

Skills can be learned. It feels obvious to say, but hearing this was reassuring because I always considered “learning new skills” to be one of my strengths. It gave me confidence to know that I could supplement applicable existing skills with new, learned skills. For example, I know how to troubleshoot an application by stepping through code until I find a problem, then come up with a solution and implement it to fix the issue. The same critical thinking can be used to identify problems with a team, but I may need to do research on agile processes or collaboration techniques to come up with the solution.

You can nerd out on management. As a developer, there are always new things to learn and play with: languages and language features, tools, technologies, and techniques. I remember learning about something like Microsoft Azure for the first time and being so excited to have a reason to use it. The same kinds of continuous innovation exist for managers, too, but you need some awareness of manager & team problems in order for the solutions to make sense — just like you need context for those new things in software development. How can you automate team processes to reduce toil? What things cause the most friction or prevent work from getting done? How can you make 1:1s more effective? How can you maximize the team’s impact on company goals? How can you improve individual accountability? These are all super valuable areas to focus on, and they’re ripe for fresh ideas and innovation.

There is no “point of no return.” I was worried I’d go from awesome dev to mediocre manager, be unhappy, lose my edge, and feel trapped. It was reassuring to hear that I could go back and that my development skills wouldn’t disappear after being less active for a bit. I’m less involved in daily development tasks now and there are a lot of pull requests doing thing that I don’t understand, but when I do get back into the code, it all comes back.

As you may have guessed, I decided that moving into a manager role was the right move for me, and I’ve been at it for a few years now. It hasn’t always been fun or easy, but the more I do it, the more proficient I become. This has a cyclical effect, too, because increased proficiency leads to more engagement which brings more enjoyment and satisfaction.

Learning to manage

The most difficult thing about becoming a manager for me was the self doubt. (See imposter syndrome.) I felt like I was less valuable to the team “managing” than if I was a developer focused on getting things done. I wasn’t sure if I was spending my time on the right things, and the things I was spending my time on were different than that of my peers/other managers. I was failing to adequately help team members that weren’t meeting expectations. I was doing the best I could, and my boss was supporting and encouraging me — but I didn’t feel like I was doing a good job. It was tough.

Looking back, I think there were two key mistakes I made as a new manager. The first was not being direct with people. I was trying to focus on positive behaviors and encouragement and not being explicit about areas that needed improvement. The second mistake was that I didn’t think about the strengths and weaknesses of individuals on the team and strategize how to use them most effectively. (More on that, here!) You can imagine how these two mistakes can create problems: praise for strengths versus less feedback & higher expectations for weaknesses. It’s no surprise that situations didn’t improve!

The single most important advice I have for new managers is to lead with empathy. Get to know your team, and treat them like people. Give them positive and negative feedback. You’d want your boss to tell you if did something wrong, right? But, it would start to feel bad if they only talked to you about the things you did poorly, too. Learn details about their lives outside of work. It would get annoying if you had to re-explain every week why you had to be late to the same meeting for same reason. The better you can understand your team — professionally and personally — the more effectively you can manage.

The best way to get to know your team is through one-on-ones. One-on-ones are a pretty common “most important thing” for new managers, but the thing it took me a while to learn was how to prepare for one-on-ones. This is very hand-in-hand with leading with empathy. Being prepared for these intimate meetings is the best way to demonstrate that you care. Come up with questions and topics that are specific to the person you’re talking to. What do they like or not like about their job? What are their goals, and are there things you can do to help ensure they’re progressing toward them? What are things they did well or poorly? What do they think they did well or poorly? It’s also a chance to solicit feedback from them about you. Be sure to take notes! They’ll help ensure you don’t miss important follow-ups and make preparing for the next meeting easier.

The next steps

Managing with empathy and preparing for & conducting one-on-ones are things you can implement immediately regardless of experience. The next steps take some time and depend on your team. The most important things will be to establish behaviors that will maximize effectiveness and define a clear vision and purpose. These are no easy feats, though. They require thoughtfulness, focus, strategy, and persistence & dedication. You must monitor progress and be wary of regression, and advocate for the right amount of change to keep things trending positively. And, you need to do all this in addition to whatever your team needs to keep things going operationally!

This is a good summary of what my day-to-day looks like now. I’ve got meetings and operational concerns, and then extra time goes into reflection and solutioning for these bigger, longer-term items. There are still ups & downs; still days where I feel like I’m doing a bad job; and still days where I wish I could just write some code. It’s been a rewarding experience, though. It’s been amazing to watch the team adapt & succeed and to help people grow. I love when we can take on an ambitious goal and achieve it.

Making the transition to manager was a scary decision. I had to learn new skills to solve new types of problems, and I had to battle through some self-doubt. I don’t regret my choice, though. I’m not perfect, I make mistakes & bad decisions, and I’m still learning as I go. But, I love my teams, and I love the problem space that I get to live in.

Have you made this transition yourself? What things have helped you succeed? Are you faced with the decision now — what worries you? I’d love to hear from you!

Originally published at The Innovation on November 7, 2020.

Thoughts to think when you feel stuck

One important thing each day

Be the leader you wish you had

Put ’em together, what d’ya have?

Share this:

Like this:

Don’t sacrifice what you have in pursuit of what you don’t

The company you work for doesn’t matter

Taking inventory

Conclusion

Share this:

Like this:

The ultimate trust-builder and collaboration-enhancer

Like a stretchy waistband

The number one thing that earns trust

Everyone gets a marble

The ultimate trust-builder

Share this:

Like this:

CONFESSIONS OF A CONSENSUS-SEEKER

The Deadliest Slide at the Playground

Melancholy and the Infinite Debate

Can we all agree that consensus is horrible?

A Breathtaking Detour

The Destination vs. The Journey

The only losing move is not to choose.

Share this:

Like this:

Having the wrong “first team” may be driving intergroup conflict throughout your company

The plan is nothing, strategery is everything

Overarching goal, all the way across the sky

The whole is greater than some of its parts. Or whatever.

The concentric safety dance

Come down from the mountain

Share this:

Like this:

How to keep engaged with your team when you can’t stomach another #$@!ing conference call

Know thy tools

Honor your commitments

End of day wrap-up

Conclusion

Share this:

Like this:

Is your team greater than the sum of its parts?

Good Behaviors, Bad Behaviors

The Actions in Action

Staging the Intervention

Share this:

Like this:

How to control scope and navigate the spectrum of engineering excellence versus business needs

Share this:

Like this:

It’s Dangerous To Go Alone

Bring the Right Group

Level-up All You Characters

Learn the Mechanics

Share this:

Like this:

The pre-management era

Making the decision

Learning to manage

The next steps

Share this:

Like this: