A
big part of leading is communicating so, for example, when my first attempts at writing the
full and official rules of Eclipse development failed, I switched to the more
concise and humorous
Three Laws of Eclipse
(
"a committer may not, through action or inaction...")
and
The
Eclipse Intellectual Property Rules in Eight
Cartoons (with a nod to
xkcd).
I
find that developers are happier to conform to rules if the rules are explained and
justified, i.e.,
open processes: like open source but so much more so. So
when
Ward Cunningham and I created a
workflow solution for
the Eclipse community, we designed a test-driven development
framework for developer productivity that also uses those same tests to
provide self-documenting process transparency for our community. So it's both
a floor wax and a dessert topping: test-first development that automatically
provides open processes.
Hiring
is perhaps the most important thing a manager can do, and over
the years I've had the opportunity to hire a fair number of people.
On the whole, my win-loss ratio is quite good and I'm always working on
improving it. Lately I've been mentoring a few new managers on the topic, so I
wrote up a few of my
interviewing best
practices.
The
right people are a major factor in team productivity, but so are best
practices. One way that I've motivated teams to adopt best practices is
through ambient status - for example, I've installed genuine traffic lights
connected to the continuous builds. I carefully chose a
traffic light because of its societal implications of green is good and red is
"stop everything"! I experimented with other devices (more lights,
fewer lights, flashing lights, graphs) but none had the visceral
impact of the glowing green or the fearsome red.
(I note that while I've been doing this for a decade,
there is now at
least
one company
selling similar ambient information devices).
Another
way that I've encouraged the spread of best practices is through
gingerbread tools - tools that are more inviting to use than the alternative,
but at the same time enforce a particular best practice. Thus developers
voluntarily adopt the tools and, at the same time, the best practices. I've
found this to be a much better technique for creating change than "thou shalt"
directives from management.
As
a project manager, I practice the art of under-promising and over-delivering.
At
OTI, we
were early adopters of
discard features to meet the
schedule agile
engineering, a practice I have continued and promoted since. I'm pleased to
see that contemporary management tools (e.g.,
evidence based
scheduling) have caught up with techniques I was utilizing more than a
decade ago.
Part
of ensuring a consistent organizational culture is reinforcing that culture.
In the past, companies have used
motivational posters and big company meetings. I prefer the more gentle
reminder of a thousand raindrops:
a blog... I write on a
number of topics, but I deliberately return again and again to a small number
of major themes:
Communication
technology evolves (mobiles, blogs, wikis, im, twitter, ...) but in the end
communication is still about people talking to people. I'm very pleased with my decade-plus of technical conferences (
OOPSLA
through
EclipseCon). Officially,
conferences are about the technical sessions, but really conferences are about
establishing and maintaining social networks. Developers are mostly introverts
so I take great pride in creating social situations that break the ice,
dissolve the cliques, and encourage those hallway conversations that are the
real backbone of a developer community.
I
do a little consulting around software engineering best practices through my nameplate "
Predictable
Software". I also fly
my little
airplane around the pacific northwest, taking pictures of
clouds, mountains
and
beaches.
bjorn@bjornfreemanbenson.com
* this page of cool things is obviously biased towards the more recent ones
November 19, 2007
