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

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-template-for-your-repository 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.