Are you my leader?

If you asked me what I’m good at, I’d say administration. I’m not always the big idea person, but I know how to get big ideas done.

I’m reading this book about leadership, and I’m no where near as comfortable with that moniker. Am I a leader? I lead my team, surely. Why don’t I think of myself as a leader?

I keep coming back to these agile concepts of scrum, and the concept of myself as a scrum master. The facilitator of a self-organizing team. The scrum master isn’t really responsible for setting tasks. They don’t pick who does what. They just facilitate others, they define process and help the team implement those processes.

And then I think about a leader. Someone who sets the task, sets the standard, makes decisions, and is the source of team accountability.

Where do leadership and scrum mastery intersect?

It almost feels like socialism vs democracy. Old testament vs new.

There’s the concept of the ‘servant leader’ as scrum master, which covers this seeming dichotomy. In theory, everyone is accountable to the team, and the scrum master is responsible for maintaining process, but not the implementation methodology of that process. But in my reality, I have to chase after people for time sheets, I have to conduct reviews, and I’m accountable to leadership for standards that may or may not be different than the standards of the team.

I suppose this whole post is just thinking out loud. I am drawn to act in service to the team, and yet there are times I must lead. How do you draw the line? How do you set clear expectations? How do you keep that from sending confusing or mixed signals to the team? Where’s the middle ground – and is middle the right place to be?

Perhaps answers come with time and trial. Onward!

Paperweights and Change

I’m sitting at home, watching these big fat flakes of snow fall, waiting for a call. We’re currently a 1 car household, the other car having just transformed into the world’s largest paperweight in the parking lot of Wegmans. We’ll head back to meet the tow truck driver when he calls to say he’s on the way.

This morning, the forecast said to expect 5-8” of snow. Now it says only 3-5” of snow.

This morning, we had 2 functional cars.

Life is change. It’s an adventure that we can influence, but rarely ever truly control.

As I opened my laptop just now, my browser was open to a conversation in a Project Manager group on LinkedIn about dealing with unauthorized change. The responses are generally insisting that unauthorized changes don’t happen in a properly managed project. That clients present a Scope Change Request, or they go through the Change Control Board, whatever that is. Or to stop all work until the change is authorized, and to punish the offenders swiftly.

The stark contrast between the rampant idealism in this conversation and the reality of projects is stunning.

What a disservice to our peers, to our teams, to our management – to pretend that our influence in the realm of controlling all aspects of a project is complete. We’re not managers. We’re shepherds. We guide, we influence, we provide direction. We attempt to clear the path, to avoid obstacles. But we’re not really in control.

Change is coming.

So is the tow truck. We hope.

A Discourse on No

I’m a member of a few Project Manager-ish type groups on LinkedIN. Recently, there was a big discussion about how to say No to a client. Some of my favorite answers from the discussion:

Just Don’t Say No
Use data and options to deliver the message instead of outright No to the receiver.

Threaten With Dire Consequence!
I find the best approach is to provide the consequences of saying yes to the person, party, group involved. Then asking them if you say yes which consequence are they willing to accept. If there are none then they will come to the same conclusion as you and they will tell themselves ‘No’.

Of course making sure the consequences are substantial is the key.

Make Jerky Assumptions
Unless it’s a true emergency situation, approaching “NO” as if it were a “YES” can usually deflect the request. Just select one of the following approaches.

1) Sure we can do that, what function(s) would you like us to remove so we can remain on budget and schedule?
2) Sure, I’m sure the senior executive won’t mind that we delay the project just for your request
3) Sure, can you give me your departmental charge code so I can start charging time to it.

You get the point.

By that time they will have figured out that the request could wait.

Agree and Back Out Of It Later
It’s quite difficult to say NO to local client however I always say “I will try”. Afterward I will send email explaining why it cannot be done and explain the impact if we still want to do it. It works most of the time for me

Obfuscate!
Start with the findings.

“The combination of factor after due diligence was done…”

And finish with

“Will regrettably lead us to conclude it is not possible/feasible/advisable/… To do what you require/need and hence our position is to cancel and reassess”

It Wasn’t Me!
I generally find a straightforward “no” accompanied by a brief explanation as to why not appeases most people. There will always be the difficult ones who still find it unacceptable, but I can usually pass the buck upstairs when that happens. These people soon learn that the “no” hasn’t come from me personally, but is an informed and calculated business decision backed by our Management Board.

But this guy nails it. If you’re going to say no, then just do it. Clearly, simply, honestly. Being direct and clear builds so much trust. No hiding, no pretending, just real communication.

“No” is an awesome word. It has HUGE impact when stated bluntly, because so many people actually AVOID using it in favour of long, convoluted explanations!

“No, because…” is a good way of getting the message of “No” across, with an element of softening of the impact of the (negative???) word.

We’re all aware of the emotional impact of being told “No”. So, qualifying the “No” with information that is relevant, focused, and of interest to the receiver, retains a lot of the impact of the “No”, while keeping the emotional response controlled (to a degree!)

I’m a big fan of the word no. Even hearing it.

I appreciate it when a supplier tells me “No”, instead of giving me some long explanation as to why a delivery/activity is not going to come in on time. The emotional response of hearing that long explanation (Frustration? Disappointment?) causes me more grief than the shock of a straight “No”. You can get over a No, and put a plan in place quickly.

Dealing with one of these explanations usually turns into a battle of wits, where you, the customer, is trying to tease a blunt “No” out of the supplier anyway!

I could write about this for days…

Ain’t language great?!? 😉

A well-oiled decision making machine

I’m helping a buddy with his site, doing some analysis of the analytics to see what’s working and what isn’t, and to try to identify some places where he could bump up the site’s revenue a bit.

The whole things feels quite luxurious. It’s a side project for him, and I’m just doing it for fun, so there are no timelines, no pressures, just long, leisurely dives into some data.

It feels so decadent, this abundance of time.

It makes me stop and realize just how fast the team really moves some days. How quickly we encounter information, analyze the options, make choices, and then DO. Problem, data, tradeoffs, choice, action. We run through that at light speed, dozens of times a day.

Over time, I think it’s made me and my team incredibly efficient problem solvers. We focus in on exactly what is happening. They bring the technical information, I bring the product and client knowledge. We weigh options, pick, and then DO. Clean and targeted, and ending with action.

We should spend a little more time reviewing our choices and actions, but overall, I’m pretty proud of this little decision making machine we’ve created.

Proactive, not reactive

I keep a little note on my desk at work to remind me of the one thing I need to be above all else:

Proactive – not reactive.

This post was in my feed reader today, and I appreciate the message. Sometimes, we are so busy running around fixing the consequences of problems that we don’t ever get to the solving part of problems. It is stunningly easy to get caught in that mode.

It’s a daily effort, to stop and think – what am I reacting to, that I should be taking the time to solve and keep from happening again?

Get used to being uncomfortable

After going through the Certified Scrum Master class (I am fancy now!), I’ve been re-evaluating how projects are ‘managed’ at work. We are not fully agile, but we’ve been slowly applying some of the agile concepts and structures to our workflows. In an agency environment, where projects are fast, furious, and many at the same time, there is not always the luxury of doing full scrum processes.

In addition, I play both Product Owner and Scrum Master, which is less than ideal. I represent the client’s interests, prioritize backlogs, and also try to help the team organize themselves for delivery, remove their roadblocks, and basically keep them running smoothly. I think I play Product Owner well. But I’ve realized I’m not an awesome Scrum Master right now.

We need to shift towards more team choices where the team decides what to do next – I’m trying to adjust my phrasing and my approach to conversations so that the team feels more empowered to make choices on their own, that they don’t depend on me to tell them what to do. It’s an interesting shift. I feel like I’m forcing them to take more control – and that they don’t always want it!

It’s a good transition, and a necessary one as well. The process is a little bumpy, but we’re getting there. I have this vision of a group of awesome people who can discuss issues, make choices, and perform to their stated expectations all on their own initiative. A group that can control their own environment, and that feels not only empowered to make change, but a group that feels the ability to change and improve is their opportunity and obligation.

We’re gonna get there. Strap in and hunker down. We’re gonna get used to being uncomfortable. It’s a price of change that I’m willing to pay.

Unexpectedly delightful

I walked by our “atta-boy” wall the other day and realized that I hadn’t updated it in a while. I used to be better about pointing out our successes, both as a team and as individuals, and I have let that fall by the wayside.

I do deeply appreciate the staff here. And I need to be more explicit about that.

For all the effort we put into the experience of our products, we aren’t focused on the experience of the staff. What’s the UX of your workplace?

It got me thinking about the unexpectedly delightful. How do you fashion an experience where each person feels appreciated, feels safe, and still experiences moments of delight in the workplace? It’s a challenge, since we are all such individuals. There are some team members who are truly overjoyed by a free burrito lunch. And there are some who feel a long office lunch is an intrusion on their workday, it doesn’t match their style.

There really is no one-size-fits-all answer here, but I feel a solution is worth pursuing. Time to inspect, adapt, and deliver.

Agile delightment FTW!

Shifting expectations

I have a client that we have favored highly over the past few weeks – often at the expense of other clients, or at the expense of my development staff’s sanity. After riding out a wave of unforeseen emergencies, we are now transitioning into a regular maintenance schedule.

It’s difficult, at times, to transition clients to new expectations while still keeping them happy. We generally release to production weekly for our web maintenance clients – but for some people, that just seems too infrequent. On their side, they are not accustomed to planning that far in advance. Or a low priority item suddenly becomes urgent because of the time spent waiting in the backlog.

Therefore, we live in a reactionary state to their lack of planning.

Transitional times like this, I try to focus on my empathy – what is the client feeling now? Why aren’t they thinking ahead? Have they ever done this sort of thing before? What pressures are they feeling, and how can I help them feel more in control?

There is certainly a balance – how much I’m willing to give, how much I need to enforce the rules. And certainly, the more precedent I set of disregarding our process, the more difficult it is to enforce process. In the end, an open mind and an open line of communication, laced with a heavy dose of empathy and understanding, tends to do the trick.

Accountability, responsibility, and trust

One of the fascinating things about agile team structure is the delineation between responsibility and accountability. While I may be in charge of making sure something gets done, I may not actually be the one to perform the work. I am accountable to a task without being responsible for actually doing it.

As a scrum master, I may be accountable for explaining and improving the team’s velocity, but I do not directly impact the velocity – I am not responsible for the work done that creates or alters the velocity. Only the development team can be responsible for the estimation and volume of work that is completed.

It’s an interesting paradigm, to separate who is held to the fire for something from who will actually do that something. That takes a huge amount of trust within the team – to trust the responsible party will do what they say they will do.

And if there is no trust? That’s a huge problem if a team member doesn’t fulfill their responsibilities. Which gets exacerbated if there are no reciprocal dependencies between us – if mutually assured destruction is not an option, albeit a last resort, clearly.

If I am accountable for things that you are responsible for, and you never fulfill your responsibilities, then there is a problem. A foundational breakdown of trust and responsibility, fracturing a team from the inside.

Be on the lookout, team leader, for small breaches that may lead to larger collapses. Defend your team vigilantly against actions that erode trust.

We can’t all possibly be the expert, all the time.

This video has been making the rounds via social media:

It’s painful and hilarious at the same time.

The thought that niggles at the back of my brain is how everyone identifies with the expert – and we can’t all possibly be the expert.  Surely, there are times that we play each role in this little spectacle, to some degree or another.  We aren’t all experts at everything.  We can’t possibly be.  At some point, we must all say something incredibly backwards and painful to real experts, and cause in them the frustration and disbelief portrayed here.

Our reaction as ‘expert’ when we come across these situations is important.  Are we able to gently teach and clarify without making another party feel dumb or – worse – attacked?  Can we speak plainly and communicate well?  That’s such a vital skill. It is well worth our time to focus on developing and nurturing this skill in ourselves, and in our teams.

The cost of what you want

An excellent point:

When you stand and petulantly demand some course of action without regard for the bigger picture, you immediately place yourself into a tiny little box. This person doesn’t understand the full scope of what he is asking, so I can disregard this particular request. Sure, you might know what you are talking about (might even be right in absolution), but the fact that you present your case in isolation makes it less compelling to the person you are trying to influence.

Instead of just taking the free ice cream, try a simple acknowledgment of the associated costs. By placing your request in context, you do a couple of things. First, you demonstrate that you are informed, which lends your position more weight. Second, you highlight that you understand the other person’s position, which helps build rapport. And finally, you open up a conversation about costs and tradeoffs, which is typically the core of the problem in the first place.

via DZone

What are you demanding from others without regard to what it will cost them?  Is that why you’re not getting results?

Who is going to look out for me?

Expanding spiritual capacity requires subordinating our own needs to something beyond our self-interest.  Because we often perceive our own needs as urgent, shifting attention away from them can prompt very primitive survival fears.  If I truly focus my attention on others, we worry, who is going to look out for me?

The Power of Full Engagement, Loehr, Schwartz

And so it goes in team building.  How do you convince a curmudgeonly team member to let go of fiercely protecting their personal needs in favor of the good of the team?  Fear – primitive survival fear – is not to be taken lightly.  What are they missing?  Trust of the team, most certainly.  Trust that their needs will be met.

It’s likely not resistance to new ideas out of a selfish or miserly spirit, but rather an indication of a perceived lack of safety and of trust.  Perhaps empathy is called for – seek first to understand.  Display the qualities you wish to embolden in others, oh fearless leader.