Gunnar's blog - Leadership

Protect Yourself like the FBI — with Memos

Learn how to use the same techniques to protect yourself as a programmer

Lots of paper

Donald Trump has been in the news a lot lately. Especially concerning FBI investigations and memos. It seems like everyone in Washington is fighting with memos - Comey, McCabe, Nunes - the list goes on and on.

Clearly memos are important, but they also seem distant and removed from programming. You programmers reading this article aren't in a fight with the president or the FBI1, so why should you care about memos?

Tools of Bureaucracy

Printing out memos

You should care about memos because we work in a fundamentally bureaucratic society run by managers2. It's likely that you work for an organization that is large enough to have its own bureaucracy - most programmers do.

If you aren't sure whether you work in a bureaucracy, here's a quick test:

  • Is there a process for getting hired?
  • Is here a process for leaving the company?
  • Is there a process for getting fired?
  • Is there a process for getting a promotion?
  • Does your boss have a boss?

If you answered yes to more than two of them, congratulations! You are a programmer and part-time bureaucrat.

What is a Memo?

Write things in a notebook

It's common for programmers to understand memos in Office Space terms. They are something supervisors do, and they really need TPS coversheets. While this is true3, it is a limiting conception of what a memo is.

Memo is short for "memorandum" which is from the Latin phrase memorandum est, "It must be remembered that..." A memo is some kind of documentation that jogs your memory. Of course, there are many different kinds memos in the modern world - policy memos, memorandum of understandings, meeting minutes, the list goes on.

From day-to-day programmer, the most important kind of memo is the memo-to-file. A memo-to-file is something you write after a conversation or an action that describes what happened. It isn't addressed to anyone, it's not trying to persuade anyone of anything. A memo-to-file simply records an event as you understood it at a certain point in time.

Put another way, a memo-to-file is a note with a date on it.

You should know that memos are being created about you. Your manager, coworkers, and stakeholders are all probably writing things down, about stuff you did!

Hold off on the panic attack. They probably aren't writing down bad things - the vast majority of memos are neutral. "Met with so-and-so, discussed project. Committed to reviewing Jira issues"

For the most part, these memos go unused. Written once, read never. They do, however, come in handy in a variety of situations, usually after something has gone wrong.

Concrete Examples

Filing cabinets full of memos

On the Road to a Job Hunt

Let's start right off the bat with the grim example. Your boss is not happy with your performance and thinks they may have to fire you. In bureaucratic organizations, there is a process connected with firing, and it typically starts with a performance improvement plan4.

Firing is expensive, and it is important to document a repeated pattern of behavior5. Because firing is expensive, many bureaucratic organizations recommend supervisors take actions to head off people getting even a performance improvement plan - mentoring meetings, feedback meetings, checkins, etc.

Supervisors document these informal actions with memos-to-file. "Counseled so-and-so that they need to inform stakeholders of a blown deadline before said deadline is blown." These notes build a case of a repeated pattern of behavior that supports the action they take down the road.

Reviewing What Went Wrong

A less grim occurrence is the post mortem, or after action report. A system failed, and the team wants to figure out what happened and why it failed. Keeping notes about who asked you to do what can be helpful when establishing a timeline. For example, "Chief stakeholder Jane wanted the big feature rolled out next week, so she asked me to do an unscheduled deploy on Friday."

They can also help establish mindset before a system failure - the best post mortems assume everyone is trying their professional best, so knowing why a person thought the action that caused the failure was a good idea is helpful, and memos-to-file can be a useful resource to determine the "why's".

Day-to-Day Disagreements

The most common (and least grim) place that memos-to-file can help a programmer out, is mild disagreement with stakeholders about feature requests and bug fixes. It's common to walk out of a meeting feeling like you have a shared understanding about what to do next, only to find a week or a month later that you did not.

A contemporaneous memo of what you understood as you left the meeting is useful, because it can help you figure out where the disagreement started. They can be useful in figuring out who was 'wrong' but this is of limited usefulness when everyone is on the same team working towards shared goals in a supportive fashion.

In the event that you are working on a contentious team, this type of memo can be useful protection - "See, I did what they said! It's not my fault they changed their mind." Hopefully you are not on a team like this, but even the best teams sometimes veer unexpectedly towards blame and contention.

End of the Year Writeups

Everyone with a boss must, from time to time, say what they did and why it was good for the company. This often comes in the form of an annual performance review with a short write up about what you did and a quick meeting with your boss. These meetings have a high impact on your promotion and bonus potential. It is in your best interest to have a good summary of your accomplishments at hand.

A good collection of memos documenting the people you talked to and the actions you took, as well as the motivations and results, makes quick work of writing end of the year accomplishments.

Be Prepared

A hall of filing cabinets

Write memos, not with the intention of needing them, but with the knowledge that you might need them as circumstances change. "Be Prepared" is an excellent motto, whether you are a scout, a backup-conscientious admin or a programmer-bureaucrat. What is a happy situation today, may turn tomorrow. Memos-to-file can help bail you out when things turn sour.

Happy writing!

Credits

Thank you Kiran Foster for the picture of a filing cabinet Thank you mcfarlandmo for the picture of many filing cabinets Thank you Florian Hufsky for the picture of a notebook Thank you Orin Zebest for the picture of a paper cliff Thank you No More Plains for the picture of a printer

Footnotes

1: Unless you are in a fight with the president and/or the FBI - in that case, I'm interested and want to hear more; dish! 2: Say what you will about James Burnham and The Managerial Revolution, I think there is something to the description of society there 3: Not really. 4: Your organization may call these something else, but the idea is a last chance plan before they show you the door 5: For liability and unemployment insurance reasons both

Newb Valley


There comes a point when you are good at what you do. If you're like me, you've been pretty good at things for a long time - pretty good at school, pretty good at work, pretty good at structured environments that provide a path and use skills you already know. This is a very comfortable place to inhabit. It comes with respect, both self respect, and respect from your peers and colleagues.

As long as you stay in your structured environment, on the path that uses/improves your existing skills, getting better feels easy - or at least, predictable. You put in effort, your skills improve in a (more or less) linear fashion.

Sooner or later, you may have the desire to learn something outside of your existing expert skillset. If you're like me, you are surprised when this hurts. Suddenly, you are not good at what you are trying to do. The shock of a drop in your skill level is disconcerting, and the temptation to retreat back to the comfort of your old groove is strong.

To pick a concrete example, you may be a talented developer. You can pick up new languages, or build new systems. If there is something programming-related you don't know, you have a good idea how long it will take to learn it, and how you should go about learning it.

But one day you become a lead developer, or transition into the management. Suddenly, you need skills that you haven't practiced for years and don't have a clear path from where you are.

Welcome to Newb Valley!

It's the difference between your hoped for path and your actual path that causes a lot of pain. There are a couple things you can do to reduce your pain and power through Newb Valley

  1. Know it is coming
  2. Have a plan to bridge the gap
  3. Forgive yourself for mistakes

Know it is Coming

This is an easy, but critical step. If your new found lack of competence surprises you, the impulse to pack it in and retreat to comfort may prove overwhelming. Instead, lean in to your newb-ness. Embrace your lack of competence - after all, if you knew what to do, you wouldn't be learning.

Developing a level of comfort with uncomfortable situations will go far.

Have a Plan

One way of developing and keeping comfort in the face of uncomfortable situations is to have a plan to lean on. You know you're in for an uphill struggle, so figure out in advance how you want to climb that hill. Give yourself some smaller goals and ways to check on your progress.

Forgive Yourself

You will be less competent for some amount of time.

That means you'll make mistakes. You'll blow deadlines. You'll deliver less scope than you had planned. Your plan to progress to the next level will be wrong.

Take a breath, re-evaluate, learn a lesson and move on.

You'll climb out of Newb Valley before you know it

Credits

Thank you Sandy Brown Jensen for the picture of the mountain climbers

3 Phases for Building a Culture of Learning


I attended Joseph Matsey's talk on building a culture of learning at Abstraction's last year. I really enjoyed the talk, and have been thinking about and implementing ideas from it over the past year. Here's a summary of my takeaway for the 3 different phases of culture building (with a bonus 4th phase, of "you have a culture")

Guerilla Learning

This is where a lot of places start - there isn't really any particular culture of learning, but some learning exercises and activities are supported

  • High resistance to taking time from shipping
  • Ad hoc learning
  • Onboarding by oral tradition
  • Few folks driving learning
  • Approach
    • Think opportunistically
    • Improve team members primary roles
    • Seek fast returns with low investment
    • Examples
      • Workshops
      • Meetups
      • Build a team library
      • New hire buddies
        • Try cross-team buddies
    • Dangers
      • Buy in never starts
      • Stay stuck in guerilla learning forever

Buy in Starts

This is a dangerous intermediate phase, where some culture building has happened, but it's not baked in or fully supported by management

  • New hires have some kind of organized learning
  • Team members want more, but aren't empowered
  • Approach
    • Leverage internal experts (workshops, talks)
    • Seed good role models (and shame everyone else)
    • Mentor mentors (mentorship is an orthogonal skillset to what you do at work)
    • Examples
      • Weekly talks, 4 15 minute talks
      • Project updates
      • Tech approaches
      • Senior leadership talks
      • Ops talks
    • Dangers
      • Key folks leaving
      • "Takes too much time" payout not obvious, track and figure out how to measure returns
      • Mentor burnout

Making it Stick

This is the final phase, that takes management buy in, re-programming existing employees and enculturating new hires

  • Boringly normal
    • From "workshops are amazing" to "oh god a workshop"
  • Approach
    • Momentum to sustain effort
    • Sustained learning
    • Make people forget the old way
    • Examples
      • Learning/teaching as a KIP
      • Apprenticeships
      • 3 part onboarding
        • Teach skills
        • Teach processes, history and context
        • Personal development
      • 20% time
    • Dangers
      • Payoffs hard to measure
      • No one is responsible
      • Losing the habit

Self Sustaining

At some critical mass point, it continues lurching forward. This point is when you have a durable culture of learning

Credits

Thank you Mat the W for the photo of Hammerschlag

Meetings for Developers


As a developer advances in their career, they attend many, many meetings. "Too many meetings," most developers would say. Paul Graham talks about the "maker schedule" which is a model that rings true for me. A single meeting, especially a poorly run meeting, in the middle of a morning or afternoon, ruins half a day.

boring meeting

Thank you Ville Säävuori

Yet, meetings are valuable. A good meeting can help a team reach consensus, or pitch a new idea to management or create that elusive "synergy" between coworkers.

Part of the trouble for developers is that they are often not the meeting maker. Many people don't know how to run a good meeting.

Understanding Different Types of Meetings

Sometimes, meeting discontent comes from a lack of clarity about the purpose of the meeting. There are only a handful of constructive meeting types. Getting stuck in a meeting that doesn't match one of the following patterns is generally unpleasant and unproductive.

Meeting Types, Arranged by Purpose

  • Inform
  • This type of meeting is easy to set up and often easy to attend. These are just presentations to a group of people
  • Consult
  • Decision makers hold these meetings to gather input. What they do with the input is not part of the meeting, but these meetings offer the chance to speak up
  • Discuss
  • Discussion meetings bridge the gap between a consultation meeting and a collaboration meeting. There is back and forth, but a decision is not necessarily the product of the meeting. These aim to create something like a 'meeting of the minds'
  • Collaborate
  • This type of meeting is tough to run. The goal is to have the participants discuss and collectively decide something.

Be the Change You Want in the World

empty meeting room

Thank you Thoroughly Reviewed

Somewhere around mid-career, developers start hosting their own meetings. Make the world a better place by only hosting meetings that you would want to attend.

The key to hosting a good, productive meeting is to understand what the intent of the meeting is before meeting. The developer should decide what kind of meeting they are hosting before they host the meeting. Once the goal is realized, plan the meeting so that everything bends toward that goal.

Write an agenda - there is no such thing as a good meeting without an agenda. The act of writing the agenda, and assigning time estimates to each section of the meeting will make it clear if the meeting can be short or if the meeting will be too long.

Do not take notes at a meeting you host.

Do not take notes at a meeting you most.

Do not take notes at a meeting you host.

Get someone (not you) to take notes during the meeting. A designated note taker will leave you free to lead the meeting, present your material and guide discussion. Note takers can also provide feedback on your meeting performance afterwards. A record of what happened during the meeting is extremely useful to send to meeting participants.

Encouraging meeting makers to behave

If you are invited to a meeting without an agenda, ask the meeting organizer when they will send out the agenda. Be sure to ask far enough in advance for them to write the agenda.

If no one is taking notes for the meeting, offer to take notes. This will help ensure everyone ends up on the same page. You also have the option to frame the discussion.

If the meeting scheduled is lengthy, request to break it into smaller meetings, or that you get invited only to the part relevant to you. This doesn't always work - sometimes a person must develop an iron butt.

Conclusion

large meeting

Thank you Ricter Frank-Jurgen

Meetings are inescapable. As with all things that can't be changed, embrace them and make them your own to lessen your pain. Meetings don't have to suck - run your meetings so they don't suck, and gently encourage others to improve their meetings.

Remember, a meeting is a communication tool, just like email, Slack or JIRA. Use meetings well and lots of good can happen. Use them poorly, and suffer.

Managing By Whiteboard


Team lead is a different job than developer and requires a slightly different skillset.

While developers need to get along with others and coordinate their work, a team lead needs to coordinate lots of people's work - developers, stakeholders, users and their own. A team lead also needs to encourage and enable others to coordinate amongst themselves.

One simple technique is using the whiteboard as a tool to provoke discussion, make sure everyone is on the same page and to teach without appearing to teach.

The short explanation is that when a team member is explaining something complicated, asking a question or is making a decision as part of a group, stand up a start drawing what they say. Any mistakes will quickly be pointed out and everyone is working off the same information.

Whiteboarding to Learn

Credit jemimus @ Flickr

Often one of my teammates will have an idea that I don't understand. Or we'll want to do something neither of us understands.

To the whiteboard!

The process I typically follow is a teammate begins explaining something complex in a meeting. As soon as they summarize the concept that I don't understand, or suspect others don't understand, I'll politely ask if I can draw what I think they meant. I make it clear that I want to check my understanding. I then make my best attempt to draw what they just described.

Typically during drawing the team will have suggestions about naming things, or where to put lines. I listen to them all and draw what the collective will wants.

Whiteboarding to Teach

Teaching with a whiteboard

Credit juhansonin @ Flickr

Everyone has had to explain a concept to their team or a member of their team. You can try email, or talking, but for fast, quality results:

To the whiteboard!

This technique works best with advanced preparation, or at least a deep understanding of the topic. Starting with an overall block and arrow drawing to discuss and the drawing concepts as it becomes clear more explanation is needed is the basic outline of what to do.

A key technique, when teaching with the whiteboard, is to not monopolize drawing. The teacher should draw the initial concepts, but after that is done they should pass the marker to the student and encourage them to draw what they understand.

This has the added benefit that the teacher can see what they are not explaining well.

Whiteboarding to Communicate

Communicating with a whiteboard

Credit jm3 @ Flickr

Meetings are a vital part of a team lead's role. Meetings with stakeholders, meetings with supervisors, meetings with peers, meetings with team members, meetings with executives, even meetings with the public.

Meetings!

In many cases, Powerpoint is overkill or actively harmful.

To the whiteboard!

Whiteboards are light, adaptable and can be pre-prepared for your presentation. They also encourage audience participation, which enhances retention of information.

Whiteboards Everywhere

Use whiteboards as a tool to learn, to teach and to communicate. Don't just draw on them. Actively using a whiteboard and passing it around between participants ticks off two different learning style boxes - auditory and kinesthetic. The more learning styles you use, the more likely information is retained.

And remember - whiteboards can be transitory, but if you need to retain what you've drawn, take a picture.

Whiteboard everyday!

Problem Behavior Correction Flowchart


A few months back I took the Coast Guard Senior Leadership Principles and Skills class, which combines The Leadership Challenge with some Coast Guard specifics. I enjoyed the class a great deal - the instructors (Charlie Coiro and Cdr Scott Jones) were outstanding.

One resource they provided is the technique the Coast Guard uses to address problem behavior with its staff. This was something of a revelation for me, because while I had some vague sense of how to encourage people having problems, I lacked a structured way of intervening.

The technique the Coast Guard uses provides a structure that I like, because it separates the problem behavior from the employee themself. The trainers say that problems are seldom intentional and usually result from a misunderstanding or shortcoming of ability.

This matches my experience - essentially everybody I work with is a dedicated professional working toward the same goal, and problems arise not because of willingness but out of confusion.

Behavior Correction Flowchart, click for bigger

This chart is supposed to guide how a leader responds to a problem with one of their charges. The leader is supposed to correct problem behaviors by stating the standard vs the behavior, listening and then diagnosing why there is problem behavior. Depending on the underlying reason for the problem behavior, different approaches are advised.

The intent of this methodology is to emphasize that most problem behaviors are the result of misunderstanding, circumstance or under training and not any hostile intention. It further emphasizes not applying the flow chart beyond the point where the problem behavior ceases. It separates the behavior from the employee.

The example they gave at the training is a chronically late employee.

Example Dialog

Supervisor: I see you came in at 9:30 today. Our doors open at 9, and we expect staff to be here by then.

Role Clarity Example

Employee: I thought we had core hours between 10:00 and 2:00 and that if I were here during them and work the full 8 hours my starting/stopping time didn't matter?

Supervisor: That's an option at some offices, but we haven't started that program here. The customer service component of our job requires that we're all here to answer the phone at 9 promptly.

-or-

Supervisor: You're right, my mistake

Ability Example

Employee: I know, but I have such a hard time getting up. I've tried alarms, light timers and I just don't know what to do.

Supervisor: -Brainstorm ways to wake up here-

Supervisor: Try some new methods of getting up on time. It's important to be here at 9, so let's check in again in a month and see how things are working out

Willingness Example

Employee: I get in when I get in. You know I bust my ass all the time.

Supervisor: -Stop when argument gets through to employee-

Supervisor: I know you work really hard, and I appreciate that, but part of your job is providing customer service. If our customers are here at 9 and you aren't here to help them, it puts them in a tough spot. Your co-workers have to cover for you, and it isn't fair to them to double up their duties just for your convenience. I get rated on this unit's customer service performance and I like to be able to say that we are not just meeting all our guidelines and helping as best we can, but exceeding them. If this continues, we'll have to put you on a performance improvement plan, and that's one foot out the door.

Emergent Problem Example

Employee: -in tears- My car keeps breaking down and I don't have any money to fix it because my daughter has cancer and the chemo takes every extra cent I have*

Page 1 / 1