Don’t Lead by Example
medium.com
medium.com
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.
Lead by example in character.
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!
"dispelling a common leadership myth: that you should lead by example.”
Setting expectations is obviously important, but the article does nothing explain how this was done. For example do they use OKRs at Dropbox? Overall I'm disappointed that so many people have "waved" (liked) the post on Medium and feel like it deserves a counter-article to set the record straight.
This may be true but obviously, in sport more generally, there are many instances of great older coaches who couldn't do half of what their players can do, and in some instances were never as good as their players even when they were young.
The author agrees with you in that you should actually do the work (you're a tech lead not a PM or purely management) but also actually tell your team what is expected and enforce it, not just assume they'll see what you're doing and copy it.
Actually the most important example is to own up to one’s mistakes and shortcomings.
And choosing subordinates who are better than you.
The opposite of leading by example is leading by hypocrisy, which is less than exceptional.
Leading by example sets a performance standard. In addition to leading by example never assign work you aren't willing to do yourself. Strong leaders are occasionally willing to get their hands dirty. It keeps the complaints low about how hard life is since the leader is willing to do the grunt work if the team member isn't and therefore doesn't need that team member.
[0] https://getlighthouse.com/blog/management-concept/ [1] https://www.goodreads.com/book/show/324750.High_Output_Manag...
The point of this article, as I see it, is that sometimes you need to say what you feel like goes without saying. That's a lesson that not everybody needs. But those who do need it, need it phrased in exactly this way. Just because this article doesn't vibe with you personally doesn't mean it won't deliver a TON of value to someone who's struggling with this situation.
There's a really critical difference between handling something with a junior riding shotgun / doing a write up vs just doing the work yourself. He didn't touch on this, but you don't propagate any knowledge just doing it yourself, and I think that's one of the problems with his version of "leadership by example".
I usually check out the comments to see if it's worth the annoyance, and if there's strongly positive feedback, I will read it.
I'm at about 2733 auto-closed popups so far.
Don't expect too much. I did this in 3 hours out of frustration :).
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.
You were leading them into Hero Ops behavior when you should be leading by creating solutions and processes that made Hero Ops less necessary.
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".
Such a dark-patterned mess.
- 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-.... 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.
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.