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

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

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.

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

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

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.

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

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

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!

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.

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*