I’m not your cool uncle

I find that playing the “I’m the leader, this is the decision, go forth and do it” card is not fun and almost always wrought with unintended consequences.

A notable exception is teams that fall back to working in their own specialized lanes1 and throwing things over the wall. Really, the issue is throwing things over the wall, working in your lane isn’t inherently harmful2. Playing the leader card and insisting folks work across specialization in their lane or closely with a teammate whose skills complement their own has fixed more things than it complicated. More specifically, the complications were the kind of difficulties a high-functioning team would face anyway, i.e., “high-quality problems”.

Now I wonder what other scenarios justify playing the power dynamic or “I’m not your cool uncle” card to escape an unproductive local maximum.

  1. e.g. back-end, front-end, mobile, etc. ↩
  2. Assuming you’re adept at communicating progress and avoiding rabbit holes ↩

I got better at estimating projects with intentional practice

I like the idea of practicing1, in the musical or athletic sense, at professional skills to rapidly improve my performance and reduce my error rate. When I was a music major2, I spent hours practicing ahead of rehearsals, lessons, and performance. Until recently, I was unable to conceive of how I might do the same for leadership.

Three meditations on wins

Leaders (and managers) are successful to the extent that their teams and peers notch wins. Former Intel CEO Andy Grove calls this the “output” of a manager, and wrote the book on it1.

Easier said than done! What is it for a lead to create wins (aka output)?

1. Choose games that are winnable

Only play games you can win.

  • Warren Buffett or the Beastie Boys (probably)

Our time is highly constrained. Saying “no” is an underrated and under-discussed leadership skill. Saying no on behalf of my team, peers, or organization, I’ve created focus on a (potentially) winning effort.

Some great reasons not to play a game2:

  • The opportunity, as presented, is not yet small enough in scope to notch a win in the time available to work the opportunity. Find a smaller win in the presented opportunity that will give you a hint as to the real potential of the bigger project.
  • The calendar time necessary to run the project or ongoing effort to completion (notch the win) is dominated by process, coordination, and bureaucracy. That is, try again when there is a way to realize the impact with less overhead/organizational drag.
  • There’s a gap between the desired/supposed outcome and the project(s) that could realize that outcome. The immediate win is to research/brainstorm/write your way to connecting outcome with action(s).

Pro-tip: provide feedback on not-yet-winnable games in the form of “I don’t yet know how to win that game, let’s start by fixing that”. No one likes pessimism, cynicism, or shutting down all the project ideas. That said, it’s fair to provide constructive feedback that will improve the idea or bring it closer to action/win-ability.

2. What counts as a win?

Once something is out in the world, it’s a win. Publishing an article, releasing a feature to your customers – those are definitely wins.

Getting something out of your team or head, that’s a sort of win. Rolling out a new process or tool is some kind of win. Worth sharing! But it doesn’t directly improve what customers are paying for, so focusing entirely on this kind of win doesn’t count.

Wins have to change your company’s world in some tangible way. The change need not be objective or quantitative; a subjective/qualitative survey is enough!

If what you’re recognizing as little wins doesn’t yield bigger wins, then it’s time to reflect on what you’re encouraging.

3. Avoid short-term thinking, build momentum with little wins, build big wins

A culture of thoughtfulness about outcomes, potential, impact, and trade-offs makes 1 and 2 happen.

Loud voices may try to convince you that un-winnable games have lots of promise. Urgent voices might tell you counting something as a win and moving on is the right move.

Moving the goal-line closer, so you can recognize a win, is expedient and productive, occasionally. Other times, moving the goal-line is self-defeating.

It is often difficult to stick with long-term projects. There is so much other stuff to work on, all of it intriguing. Other folks in the organization will want to know how much of “all of it” we could produce in the current and next quarters.

The challenge is to stay the course, believe in the purpose, and stack all those little wins, every week, until the big win takes shape. Tell your colleagues about the big win’s emergence…

In short

  1. Choosing what to work on (or not) is of crucial importance.
  2. Recognizing the right kinds of progress makes it easier to stack little wins on the way to big wins.
  3. Exercising the discipline to stack meaningful progress (wins) is the engine for generating big outcomes.
  1. High Output Management. See also, GitLab’s notes on the same. ↩
  2. Would a whole post on indicators of losing/un-winnable games come off as too cynical? ↩

Improving when you can’t rinse and repeat

You can’t practice at some things. Putting the cat back in the bag or the toothpaste back in the tube. The undoable, the things that you can’t unsay. The measure twice cut once stuff.

In those cases, a little preparation and reflection go a long way. I think about what's important to say or verify before I say/do the undoable. Afterward, I reflect on how things went, if I learned anything surprising, and how I can improve the process next time. Ideally, I write all this down, so I don't lose any wisdom for the next time I'm faced with a similar challenge.

I'd normally say rinse and repeat here. But the point here is there is no rinse! There is only setting myself up for success when I find myself facing a one-way door.

Focus in a time of distraction

That is, some notes on helping junior developers focus on execution when they are surrounded by the twin distractions of novelty and outright broken things. With apologies to Love in the Time of Cholera1.

Faced with a junior developer who finds themselves stuck, what questions could you ask them to help them get back on the happy path without all the distractions that junior developers face:

The trick for juniors, is they’re always learning more than one thing at a time, often on accident. They want to build a feature, but it requires a new library, and it requires learning the library. They went to start up my development server, but then something weird happens with Unix. It’s the essential challenge of being a junior – they’re just getting started, so they’re always learning a couple of things at a time2.

Is this a side quest?

Compared to senior developers, juniors often find themselves down the wrong rabbit hole. Senior developers have a better sense of when they are chasing the right lead. Over the course of months and years, they develop a sense of when we’re looking at a red herring. More so, they learn to recognize issues caused by development environment rot, bad data, unrelated bugs, and other sorts of non-essential annoyances.

In those situations, it’s helpful to ask junior developers if they’re pursuing the essential problem or if they’re on a side-quest. If it’s a side-quest, write it down and get back to the essential issue. If it’s the essential problem, then…

What do you need to know to focus or make progress?

At all experience levels, software developers face the frustration of “it just doesn’t work”. Occasionally, this is down to outright broken software. Often it’s not knowing about or misunderstanding a crucial detail of how the sub-systems work together.

It’s extremely tempting to skip ahead, tell a junior developer what they need to know, and move along. That’s how it works on the internet2. It’s time efficient. The ability to swoop in with an answer feels wizardly, and that’s pretty fun.

Unfortunately, that’s the “give a man a fish, you feed them for a day” approach. Junior devs are a source of endless questions, sometimes excellent and sometimes not. Answering one question, no matter how decisively, is unlikely to change the shape of the ‘questions per hour’ graph.

Better questions, better information

Better to teach junior developers to generate better questions. Nudge them to lead with what they know about the non-working situation. Encourage them to steer clear of trying magical solutions3 and whack-a-mole troubleshooting4.

This teaches a junior developer two things:

  1. They probably know more than they think.
  2. They’re more likely to find their answer by answering questions than by fixating on what doesn’t work

Which questions can you answer right now?

Now that our junior developer is armed with better questions, it’s time to answer them. Given all the questions that might help them make progress, they should start from the ones we know how to answer right now. Sometimes luck strikes and the problem is solved. Other times, the issue and the tricky questions remain.

This is the scenario where senior developers5 can help a junior developer the most and teach them to fish, so to speak. Senior developers are often more adept at using REPLs, debuggers, automated tests, documentation, static code reading, inspecting data, or observing runtime behavior to turn good questions into answers. In one session, a mentor can show an apprentice how to use an unfamiliar tool, think about problem-solving, and solve the original question. The mentor will probably learn something too!

Luck happens

There is a bit of chance in solving problems. Recall what you already know. Pattern match on the (correct) factors that likely won’t bring you closer to a solution. Ask answerable questions that narrow the issue space. If you make a mis-step at any of these, you could end up confusing yourself even more!

Stick with it. Maybe step away if you’re already drained, or it’s getting late in the day. But stick with it. Persistence beats luck and chance, most of the time6.

Thanks to Wade Winningham and Henrik Nyh for sharing ideas on this topic via ruby.social.

  1. Which I have not read but is a pretty snappy title. ↩
  2. e.g. Stack Overflow and its ilk ↩
  3. e.g. restart the computer, reinstall something ↩
  4. Trying random changes, repeating one test in hopes of seeing a different result, blindly applying suggestions from similar problems posted on the internet. ↩
  5. Senior developers appear to have the superpower of seeing circumstances and going directly to the root cause. That usually happens by quickly enumerating what they know about the problem and pattern matching on the circumstances to reduce the problem space to a few possibilities worth eliminating or verifying.
    This happens via answering enough questions that the problem or behavior of the system becomes obvious. It’s a bit of crafting a theory until you trip over the actual situation. ↩
  6. Casinos and rigged games are notable exceptions. ↩