How birding made me a better technical leader
you spend 5 years of your career thinking you're a heads down developer, and then one day you're like "damn that's a communication anti-pattern I observed in Slack just now"
A while back, I suffered with the stereotype of birders as being passive, maybe a little past-their-prime, out-of-touch in a way in which the sound of a Hoary Puffleg or a Bustard was enough to get them addled away from everything else going on around them, distracted to the point of slapstick. It was an unfortunate stereotype, and, in terms of age-stereotypes, wrong.
Then I woke up one day and was, like, “damn is that a yellow-rumped warbler”?
*
The transformation to birder was stark, but it didn’t distract from life: it added to life. I was still going on the same hikes, but they were treks with a layer added to them and no layers removed. I sincerely wish I had noticed this added layer for the years I had been hiking before my new awareness.
And, in a significant set of ways, I found birding feeding back and making me more alert as a technical leader.
Here’s how:
Inspiring others
When I’m on a trail observing a Cooper’s Hawk seated on a branch while angry House Finches try to startle it away, I want to ask people passing by if they see it, and give them a chance, if they have time, to hear more about what differentiates the Cooper’s Hawk from the Red-Tailed Hawk.
I’m polite. A surprising number of people are so in their heads on hikes, or listening to podcasts, that they miss the impressive raptor preening itself on a bare branch 10 feet over their heads. I let them go without bothering them.
But some people ask: what are you looking at? Or they stop to try to see. That’s when I share my enthusiasm with them.
As a tech leader, your job is to share enthusiasm with people who might not be enthusiastic, meeting them at their level to inspire them. They don’t care about the relative size difference between the Cooper’s and the Red-Tailed Hawks? Maybe they’re interested in the spectacle of the remnants of the Cooper’s Hawk’s last meal dangling from its talons. Maybe they just want to see they’re not alone on that trail.
My job as tech leader is to inspire people to think above the drudgery of 9-5 work. As someone who was the son of two public school teacher parents and who taught himself through college, I love inspiring people to learn new things and think about what they’re doing differently, more mindfully, seeing the things they otherwise might have missed.
System Thinking
It is helpful to know the month that yellow-rumped warblers appear, and which trees they favor. Going to look for them in November is a waste of time, same as trying to track them in a coniferous forest. It is important to know the overall system.
The same thinking applies to teams and to the overall tech system [stack, software design, architecture].
Instead of “yellow rumped warbler”, substitute “race condition” or “sql injection vulnerability” or “data clumps” or “single point of failure”, and you’ll see how knowing where to look in systems and at what time makes a big difference.
But tech leadership isn’t just about guiding people to see tech systems failures, but the bigger system failures: knowledge hoarding, team imbalances, bad change management, missing communication protocols.
Teamwork
When I go out, I am often with someone who has practically memorized the Birds of Massachusetts Field Guide. She can tell the difference between a Hairy and a Downy woodpecker. I can’t, yet.
But I’m expert at spotting. I can see a particular flight pattern across the river she’d miss. When we hear a birdsong, I’m great at echolocating the bird, narrowing down the focus to a patch of trees, a couple of trees, a tree, the top half, top quarter, or “That branch over there”.
We make a team. By working together, we can remove single points of failure [I can learn how to identify birds better], and she can look for the movements she might otherwise miss. The goal of the team is to start out with specialization, but improve each other so we bridge our areas of specialization better, or remove those specializations if it helps us both.
This is the same for an engineering team.
TLDR example :) skip ahead if you’d like
I once managed a team of remote engineers on the other half of the world. Call them A and B and C.
A was upset that B was working on the wrong things, doing work and not reporting it in the handoff, not taking care of timesheets.
B was upset that A wasn’t the best engineer in the world and that he didn’t have any leadership in his time zone when I was asleep. He looked forward to my minding the admin stuff with him when I clocked in.
C was fresh out of college, and bewildered: he needed mentoring, not observing quibbling.
The resolution? A aspired to be a manager. B never wanted to do admin or management stuff. C needed A and B to be at the top of their game and able to share knowledge.
I appointed A as point person for that team, reduced his dev work, gave him limited authority not only over B but also a junior dev, C.
A didn’t escape development altogether, but he took up the stuff B didn’t like to do— and A loved it.
B meanwhile appreciated A’s leadership of B and C.
C got a model for how teams balance delivery and harmony.
The summary?
Credit is assigned to individuals, but work is accomplished by well-balanced teams. I could ask A to balance the workload between B and C, and it would be done. Make sure B & C aren’t hoarding knowledge? Done. I’d check results during my 1:1s and provide additional value-add guidance, but it took a lot of pressure off of me and the alphabets. No more working with B on administrative stuff which now was handled in his time zone!
Communication
When birding as a team, it is useless to say: “I see a Viriole. Don’t you see it?” What is effective is: “Viriole! See the red oak? Look on the right hand side, 1/3 of the way down, the branch with blue sky behind it and few leaves. The Viriole is at the end of the branch, grooming itself.”
The same thing with engineers on Slack. Every instruction must pass some tests: is it clear, is it concise, does it talk to the audience at the right level, and does it point the audience in the right direction as quickly as possible?
Each communication channel has its best usage, and if you treat it right: you will get better results. Birding helps remind me to envision the situation, the result I want, and turn it into short, clear, and unambiguous statements/requests.
Focus
“You spent a half an hour driving to the hike, and you’re twenty minutes in. There’s a pair of nesting Great Horned Owls somewhere around here. Are you going to let the outcome of a SonarQube static analysis run make you miss them?”
One key thing I’ve learned about birding is that thinking about a performance optimization will cause me just to go for a walk, not see birds. I’ll totally miss that osprey in the tree across the river if I’m thinking about which load balancer algorithm to use.
In my case, I’m generally okay walking around without tripping when considering system architecture. But I’m going to miss the Orchard Oriole. And the Orchard Oriole is why I’m in a narrow path in a thicket. I spent time and effort getting here. I need to be here.
The fact is: humans aren’t great at multitasking. Birding is a great time to remind myself of that. My reminder to myself is “one thing at a time.” I make a mental (or app) note of my engineering thought, let it pass, then look for the nest of fledgeling cardinals I hear cheeping.
The best way for me as a technical leader to appear to be everywhere at once [multitasking] is to do one thing at a time with absolute focus, executing it mindfully and with efficiency, then moving on to the next thing. Trust me: you don’t want me thinking about how red hawks kettle when I’m leading a code review, so I won’t do it. Instead, apply concurrency, except with much larger time slices than a machine [no fewer than about 10 minutes is my my rule].
Using a focus-only-on-one-thing-to-appear-like-I’m-capable-of-multitasking is an optical illusion, but it prevents me from tripping over a root, from wasting time I could be frame-shifting from algorithm complexity to microservices, or to that request for help from a junior dev.
Planning
Knowing the system allows me to plan. For example, I want to see Barred Owls. So I look for hiking with water and with pine groves. I plan to go at a particular time of year to see them nesting, and I go at a particular time of day if I want to hear their hoot or watch them hunt. I have a playbook: I need binoculars, a reasonable camera, and enough time. I want to know the trails so I don’t get lost, and so I arrive at the grove. Maybe I’ve used iNaturalist or another API data source to perform some data engineering to discover where recent sightings have occurred. In short, I use an organized approach so that I expend only the amount of energy I want in the trek.
The same thing applies to tech leadership: When given some lead time, I show up at discussions with a draft idea, a starting place, a playbook which worked somewhere else in the past. Even without lead time, my experience has me [ahem, this blog] equipped with starting places all over, each one ready to be adapted to the issue at hand. I don’t expect to show up at a meeting and voila! a Barred Owl is right there. Part of getting the right result is being prepared for the right result. Go to that meeting with a director, a customer, and a sales-rep, but you’ve forgotten your binoculars? You won’t see the owl. Prep for everything, and you’ll increase your odds of having the experience you set out to have.
Patience/perseverance
Some of the best advice I got about birding was: let the brown thrasher come to you.
Instructions:
Find where the brown thrasher has been observed, as specific as possible.
Go to that location.
Be still and quiet.
Wait, enjoy your surroundings.
The amateur will do steps 1 and 2, then go tromping around, even off the trail, to find the brown thrasher and will give up.
Why the amateur approach doesn’t work:
Tromping around makes noise, which disturbs observations. See observer effect.
The brown thrasher is not on your timetable. You are on its.
The amateur is missing the goldfinch who would appear while waiting for the brown thrasher.
How this relates to tech leadership and management:
That tech debt doesn’t go away in one day, nor does the junior developer become a unit testing wizard in a day, and the management who insists on your using post-it notes to keep track of what they’re asking you to do [despite having a good jira instance and your background as a jira administrator?] because of politics? That doesn’t get resolved in a day, either. But the right times can arrive, if you make room for them.
Tech debt? Sell the problem with tech debt to your stakeholders and bargain for more time each sprint to get rid of it. Over time, maybe you get an entire sprint free of customer business just to make process improvements and resolve tech debt. It has happened.
The junior dev and unit testing? You’ve heard the expression: a watched pot never boils? Do your job as manager: reinforce the right values during 1:1s, apply timely feedback, apply them at code review, be transparent about risk/reward. Don’t hover, but check in. One day, hopefully before you have to apply official notice to the dev— certainly with regular prodding which is not micromanagement, you’re going to get suites of excellent unit tests. Being angry today doesn’t make it better. Threats and lording over the dev all the time don’t make it better.
Management stuck in the 1950’s? When a ticketing issue causes delivery issues, remind them there is a better way. Educate them. Again, provide cost/benefit analysis and use cases and show them how it is working in other departments [yes, even with politics]. Show how connecting departments works for the team. Then wait. Having angry calls doesn’t help management come to the table: giving them info, negotiating, and letting them decide works, even when your management is guided by irrational opposition. Maybe even more-so: irrational management seldom loves for you to point it out, but they love to get credit when they arrive at rationality.
Keep being assertive, diligent, persistent. But add to that perseverance and patience when needed. Making a ruckus won’t make the brown thrasher appear, but silence and quiet and positioning yourself correctly will.
Level switching
Sometimes you’ll miss the broad expanse of turkey vulture wingspan if you’re distracted by birdsong in a poplar. You’ve got to let your eyes lose focus a bit and keep your gaze in the sky to see the vulture, maybe noting its pass overhead when you see its shadow on the ground.
Similarly, if you’re scanning the sky above you, you won’t see the osprey perched in tree canopy in front of you, ready to cannonball talons-first into the lake to grab a fish.
An engineering manager needs to know how and when to level switch: from people process to system architecture to code and back. This is a kind of vertical movement the engineering manager needs to perfect. Be at the right level at the right time. Otherwise you’ll miss something important.
Prioritization
The horizontal equivalent is prioritization. Suppose you’re eyeing wood ducks on a pond’s surface. It’s a pair of parents with their ducklings. Great! But there’s a tree swallow emerging from a hole in a dead tree. Prioritization says the wood ducks will be there in a few minutes, but the swallow will not. Focus is needed on the swallow, then it can return to the ducks.
Similarly an engineering manager needs to be able to prioritize focus: yes, helping refactor legacy code demands attention, but if a junior dev is telling you a system alert popped up in Grafana and that she needs your help finding the root cause: it is better to swap focus, frame shift, and then return to the slower-moving legacy code.
There’s more that engaging in birding has contributed to my tech leadership and management, but that’s it for this post. Glad to share more remotely or in person—hopefully, on a hike somewhere with a healthy ecosystem and interesting observations.