Homework #1 – Management has Consequences

It’s not a lot to say one is a fan of podcasts, so with the homework series we can travel together though some of my favorite podcasts and perhaps from this we can leave a trail of something novel on the internet.

The first assignment is to look into Reply All’s episode on Bon Appetite.  The podcast is #172 The Test Kitchen.

When I first heard this it hit close to home, here is a set of white guys at the top of an org with little to no appreciation for the turbulence they were causing in their org due to them not appreciating the effects their role power and biases were causing.

Today I am responsible for 40 engineers, and their performance impacts the performance of quite a few additional people and customers.  I have often found myself leading the team astray or causing issues because of mistakes, misunderstandings, and poor assumptions on my part. 

In fact I developed one of my most important principles: Nate doesn’t change the plan in standup, as a remediation for my behavior in the past. We’ll have to revisit this in a later article, but the short version is that the blinking sign above my head as a manager can often accidentally be used to redirect a train that was humming along just fine without me butting in. Back to the podcast.

What’s profound about this podcast, is not only did it try to highlight this issue with management at the magazine, it uncovered this same behavior within the Reply All podcast team itself. So, now we have not only a case study of this magazine, but in real time we can learn from an organization coming to appreciate how hurtful and disruptive this behavior can be in any organization if we are not actively examining our impact.

Your homework, should you choose to accept it, is to listen to this case study (this will take a few podcasts) and see how you as a leader are perpetuating these same issues within your org.  Then take it one step further and see if you can illicit from your team honest feedback about where you are leading the team towards this same cliff. 

Just be aware as we (managers) ask for feedback, take our time and know that if we haven’t laid the groundwork of trust and felt safety, we will get nothing.  If we get nothing, it’s unlikely that is because nothing is wrong.  Further, it is not our team’s responsibility to give us feedback, traditionally feedback rolls downhill, we have to use our relational power to dim the blinking manager sign above our heads.  And ask with a penitent heart for the opportunity to help grow together as a team.

10 2-hour blocks per week

Individual Contributors in an organization need time to get work done.

This feels axiomatic, yet it is often the case that any number of meetings can gather on an individual’s calendar such that there actually isn’t enough time to sit quietly and think the deep thoughts one needs to deliver business value. Today is not the day to wax nostalgic about how terrible meetings are and how we should have no meeting Wednesdays. Meetings are not intrinsically bad and neither is their absence.

However, as a leader it is my job to ensure my team has time to think. To do this, I ask them to look at their schedule at the start of the week and before standup every day and ensure there are at least 2 – 2 hour blocks every day and 10 – 2 hour blocks each week that are unallocated. This can seem like a pretty low bar in an eight hour day, but I would suggest that this is a place to start that is measurable and actionable.

So, on any given day that an IC doesn’t have these two free windows of time. That counts as a blocker in standup. This is really what standups are for; status updates are great but removing blockers is the real money maker. As the manager on the team you just had a person tell you they cannot get their work done. And perhaps even with enough time for you to act

Now it’s time for the manager to step in. Can some meetings be skipped or rescheduled? Or are we writing off this day as one lacking full productivity assigned to the in progress work. It will almost always be a hard decision, but if you don’t know about it. If there is no stake in the ground, you cannot hope to train your team to help them help you identify this concern.

Bonus points: This can be systematically measured. Outlook and Gmail both have APIs that can help you query your team members calendars so that a metric can be built around what percentage of your team has unblocked time. 

Lastly, not all Specialties in an engineering organization get the same amount of free time. As a team lead one might only get 4-6 free blocks a week depending on how much planning is happening. A manager or director could have 2-5. So, as you are digging into your directs and skip level calendars be cognizant of their particular role and how focused on coordination it is. (See High Output Management where Andy Grove talks specifically about how he is in meetings all day, because he is their to coordinate and scaffold decision making)

Take care,

Nathan

See also:

Twitter link for discussion

Empowerment through process change

I spent quite a long time in my career hating processes and actively fighting against it. This is a fairly acceptable approach with a small team and as someone who likes talking and saying the same thing over and over again. This is me. I love to hear my own voice and I used this as an opportunity to engage with my team members. 

This worked great until two things happened: 1. my organization grew to three teams and 2. I was lucky enough to have a boss that said I can only enact processes that I wrote down. I fought this pretty hard until I realized my team wasn’t getting a single message and I was engendering conflict as different people received different messages from me. 

It is extremely frustrating to find out I was the cause of contention in the org I’m trying so hard to build into a caring, constructive, high performing team.

So, here’s my suggestion for building a more sustainable, empowered, and better aligned culture through writing.

Let’s take a detour to empowerment through process. One issue I’ve fought with process changes is the feeling it is handed down from on high with nary a consideration of the lowly individual contributor whose life is actually impacted by this change. This too needs to be addressed.

Step 1: Write down the change you want to make before you take it anywhere near your team. I don’t mean to preclude brainstorming and musing. But keep it away from a wider audience until you can get your thoughts formed enough to write down. Spend the time here to think through the language and grammar of this change. This is a chance to model the behavior we are building to throughout the organization.

Bonus points if your process includes some measurable metric that can tell you whether or not this was actually a good idea. This can be harder than it seems, so don’t make it gating.

Now we test how empowered a culture you are a part of.

Step 2: Put the doc in a place that is visible and editable by your team and prefix the doc and title with ‘Proposal:’ Make sure everybody knows the doc is at the rough draft portion of this endeavor.

Bonus point: Did you detail how you roll out this process change? What day does this start, what docs will be updated? When will employees be expected to conform?

For me that’s putting the doc confluence and dropping it into a chat room #squad-process-changes

Using a wiki or slack is really just tactics. The key is there is one source of truth that can be commented on publicly and even changed by those who are affected. So, give the team a few days, coach them that they should raise any concerns (give a timeline for feedback) and ask for sign off. A manager’s output is only the sum of the team they run so getting buy-in is powerful.

So, in a perfect world, you’ve got a process written down, vetted by your team and it’ll either now be the new way the world works or you will know without a doubt that implementing this is going to be an uphill battle.

All of this is much better than a surprise email your team receives from you about another crazy change they didn’t get a vote on. Oh, and the next time you find your team members arguing about the process they can point at a doc and even change it if it’s due to ambiguity. (But that’s another process change)

Some further reading:

Discussion

A little about me

I am a few things of note for the purposes of this site:

  • A manager of software development teams
  • A person with a passion to care for the people who work for me

Hopefully, you’ll find something here of note that will help you as this has helped me.