
Don’t Lead by Example - theBashShell
https://medium.com/@jamesacowling/dont-lead-by-example-4f86b1174e64
======
sixhobbits
Strong disagree. Doing all the work is not leading by example. Leading by
Example would be handling the first emergency with a more junior engineer
following along, or doing a write up of how you handled it and then asking
someone else to handle next time.

Not leading by example would be expecting your reports to deal with shit that
you don't know how to and getting annoyed when they can't.

~~~
nelsonic
So glad that the _top_ comment on this thread is people _disagreeing_ with
this post! Leading by example is _fundamental_ to success in _any_ capacity.

We _cannot_ expect people we are attempting to lead/coach to do a task if we
do not demonstrate that we know how to do it. It's like having a personal
trainer who is a couch potato, it simply makes no sense!

I _really_ hope that other "tech leads" are not following this example! Put in
the hours you expect others to work. Document your work the way expect others
to. Write tested, maintainable & performant code as you wish others to. This
is _all_ leading by example!

~~~
Foxcoditrad54
You are actually in agreement with the author.

~~~
soneca
But the author chose a click-baity controversial-sounding title to actually
make the argument for a much less controversial point: don't do all the work
yourself thinking you are "leading by example".

------
clusmore
Off-topic, I'm sorry but I just can't help it, the aggressive modal that pops
up instantly when you view Medium enough as a non-signed in user drives me
away instantly. I can't imagine continuing to post content on a platform that
treats my readers so poorly.

~~~
taneq
Ugh, I hate this. If a web site nags me like this, the one thing I will NOT do
is whatever the popup wants.

~~~
alasdair_
"Don't every close this page without subscribing!"

------
jaabe
Doesn’t everyone lead by example, even if they don’t mean to? It’s anecdotal
of course, but I’ve always been affected by how my manager behaves.

That doesn’t mean you only lead by example though. Maybe I’m not reading it
right, but the author seems to think that leading by example and setting clear
expectations are mutually exclusive, and I don’t see why that would ever be
the case.

Management is a trade though, I’ve had technical managers and I’ve had manager
managers, and I typically prefer the latter because it’s really hard to be a
good X while you’re also a good manager.

Tech lead positions where you make technical decisions but aren’t meant to
actually manage people, motivation or finances are a little different, but I
don’t see how you get out of setting a good example in those either.

------
gtirloni
Should be titled "Don't Lead by Bad Example".

You were leading them into Hero Ops behavior when you should be leading by
creating solutions and processes that made Hero Ops less necessary.

------
laythea
"you’re a member of a team not the boss of the team."

Surely the boss is still a member of the team, otherwise he is chilling,
collecting pay checks for nothing.

I don't like the ring fenced sub-team mentality that this comment allows.

Bosses that are not a member of the team, are not proper bosses.

Maybe "figureheads".

------
camel_gopher
You can lead by example without crowding others out. Set the example, then
make room for others to execute on that. This is often the role of a coach.

------
qznc
In other aspects a tech lead must lead by example. If the tech lead reviews
pull requests in a sloppy way then the juniors will surely do so too. It does
not mean that the tech lead should review all pull requests, of course.

------
watwut
They seen his example, concluded that "this is ineffective" and did not
emulated.

------
pnw_hazor
The first rule of leadership is to never post articles on medium.com

Such a dark-patterned mess.

------
jldugger
Leadership by example is only one tool in the leadership toolbox, and if it's
all you know you have, everything looks like a nail. But there's also times
where it can be useful. In engineering orgs where senior engineers are treated
as non-managerial technical leads, role power may not be available for holding
people accountable to expectations. A brief set of scenarios for tech leads:

\- asking questions in public spaces. Many people avoid asking questions for
fear of looking 'dumb' for not knowing the answer already, and when they do
they ask questions of the narrowest set of people possible via email or DM.
Having senior people modeling the behavior with genuine humility goes some way
towards eliminating junior team member's fear of asking the questions to get
the information they need to actually do their job.

\- actually documenting your Pull Requests. Plenty of senior technical folk
pull this thing where they submit PRs with no description, either because they
feel the code is obvious, because documentation is a waste of time, or because
they discussed it with an office colleague who they expect to merge without
comment. I've nudged my team towards documenting why a PR is valuable and how
it accomplishes that, both through leadership by example --crafting well
explained pull requests -- and by introducing PR templates:
[https://help.github.com/en/articles/creating-a-pull-
request-...](https://help.github.com/en/articles/creating-a-pull-request-
template-for-your-repository). Which was itself introduced via a well
explained PR =)

\- Apologizing to coworkers and customers. Generally speaking, apologies are
free, and over my career I've learned a template for them: accept fault,
apologize, and commit to do better. Emphatically, do not lie about things or
make up mitigating circumstances. This is a recipe for repeat failure, and
subsequent loss of trust amongst coworkers and customers. If you blame a
process failure on a hardware failure, there is no expectation that you will
make an investment in fixing the process!

Leadership by example is a soft power, but still a power any leader should
have access to, on a limited basis. Of course, nuance is unsuitable for
headlines.

> jumping on every pager alert immediately, being the first one to respond to
> team emails, constantly fielding questions on chat.

Thoughts on this:

\- It's unclear this is behavior you expect of others, versus impose upon
yourself. In particular, the competitive framing of showing up on the scene
first is not immediately obvious to outside observers. It's not even
internally consistent, you can't logically have ten _first_ responders.

\- When leadership views things as a competition, it's not clear who is
'supposed' to handle things. When I see people like James rushing to work on
tasks X, Y, and Z, I imagine they like the task, and/or are ignoring equally
non-urgent but important tasks A, B and C, and focus on those. For urgent
tasks, leadership should serve as a backstop to an SLO, and make it clear
who's job it is to meet that SLO.

\- Additionally, it's not clear to me that leadership by example was bad here
so much as the destination they were being led towards was bad. Knowledge work
often requires uninterrupted concentration, and spinning up a dozen engineers
every page is a solid way to destroy their sprint's deliverables. I generally
disable Slack notifications, shunt listservs to folders (and mark a good chunk
as read) and silence most iMessage threads.

------
tsumnia
"I was working 16 hour days and struggling to get the team on board, while
instead just going overboard."

I think this is the key takeaway. The author was leading by a BAD example.

More time on task can lead to more productivity... but at the cost of your
sanity. I think it's a common tactic in younger developers because they
haven't really obtained that level of "ideal worker" they're striving for.

------
blazespin
I think he meant to say don’t lead by setting an unrealistic example.

------
craftinator
Attention seeking headline, made up the article to fit.

