As a leader, whether within a technical team, or a technology expert leading a customer, the use of language is very important. It’s a soft skill that’s lacking in a lot of developers and non-developers. I try to be cautious about my use of language, partly because I’ve had mentors who treat imprecision or careless word choice as a bug, and partly because I’ve been in enough situations, as the speaker or the listener, where language has been the primary reason for conflict. I’ve also taken creative writing courses where ambiguity is expressly allowed, and brevity is actively celebrated. When your words are limited, you have to choose them carefully.
I’ve got a few posts coming up around this, with some links to interesting articles if you want to dig deeper into this, but I’m interested to hear your thoughts too.
Manager vs leader
A manager tells you what to do and monitors you to make sure you do it. A leader sets priorities and trusts you to get on with it, and clears the path to let you do it. A manager puts the team in a box and reflects it to the outside world. A leader puts the rest of the world in a box and reflects it to the team.
Not everyone with the title fits the mould, but there’s an attitude that the title gives you about your role in the team, and the expectations of what you should be doing.
Perfect vs perfect
Rackspace has a nice blog about perfect as a process rather than a destination. Quality is what we want as a team, but every release we do, every code we touch, can be refined, adapted to new practices as we learn where the weaknesses are. We hone our skills, and our code, removing weaknesses and rough edges, but we accept there is always more to do.
Nothing is ever going to be “as good as we can make it”, but it can be “good enough”. Software that hasn’t shipped is a project, not a product. Make products, ships them, get feedback. If you strive for perfection, feedback is an opportunity to improve, if you believe your product is perfect, feedback is dismissed as noise.