If there's one thing that you can say about LinkedIn, it's that people are overly confident. Not a lot of, "I don't really know" happening there. And that kind of makes sense, because everyone is selling something, even if it's themselves. I see frequent posts around software development that present "simple" solutions to common problems. "This process makes it easy and obvious!" Sometimes I wonder if that isn't a level of disconnect to some degree, judging by the titles some folks put by their name. The problem is that sometimes you can't just check boxes in a playbook and collect your bonus.
In thinking about how I may approach the talk I'm doing for Orlando Code Camp in the spring, about developers who want to be managers, it occurs to me that there are aspects to leadership work that do not conform to a playbook or system or process. The ability to provide wisdom, enablement and decision making is the process. For example, I saw a guy declare that a particular metric was the only way to achieve a certain outcome for code quality. But the truth is that there are a great many levers that can affect that outcome, most of which require experienced people to call out quality problems. There are no silver bullets, but there are great people who can lean on their skills to guide others toward better outcomes.
If I seem skeptical of frameworks and systems and checklists, that's because they devalue the people who can steer you in the right direction. So much of what we do is contextual. A metric or a standard assumes that a very Type-A defined condition can accommodate a very contextual and nuanced situation, and I find that's rarely the case. Sometimes, when you look at these standards, they're more about control and in-the-weeds stuff, not about the larger outcomes. As the Agile Manifesto says, "Individuals and interactions over processes and tools." We tend to forget that.
No comments yet.