(This is going to be long and rambling. Hopefully at some point I'll be
able to distill it into something shorter.)
In preparation for a tech leads retreat tomorrow, several of us at work
were asked to watch Simon Sinek's TED talk,
"How great leaders inspire action".
I'll be honest with you: I hated this talk. Sinek lost me right at the
start by portraying his idea as the point of commonality among great
leaders (don't get me started on survivorship bias; it's a pet peeve) and
then compounded the presentation problem with some dubious biology about
brain structure. So, after watching it, I ranted a bit about how much I
disliked it (to, as it turns out, people who had gotten a lot out of it).
(
Don't do this, btw. It's nearly always
worthwhile to suppress negativity about something someone else enjoyed. I
say this to increase the pool of people who can remind me of what I said
the next time I forget. Which, if my normal pattern holds, will be about
five minutes from now.)
Thankfully, I work with tolerant and forgiving people who kindly pointed
out the things they saw in the video that I missed, and we ended up having
a really good hour and a half discussion, which convinced me that there's
an idea under here that's worth talking about. It also helped clarify for
me just how much I hate the conventional construction of both leadership
and success.
This talk is framed around getting other people to do things, which is one
of the reasons why I had such a negative reaction to it. It's right there
in the title: leaders inspiring action. This feeds into what at least in
the United States is an endemic belief that the world consists of leaders
and followers, and that the key to success in the world (in business, in
politics, in everything else) is to become one of the leaders and
accumulate followers (most frequently as customers, since we have a
capitalist obsession). This is then defined as success. I think this
idea of success is bullshit.
Now, that statement requires an immediate qualification. Saying that the
societal definition of success is bullshit is a statement from privilege.
I have the luxury of saying that
because I am successful; I'm in a
position where I have a lot of control over my own job, I'm not struggling
to make ends meet, and I can spend my time pondering existential questions
like how to define success. If I were a little less lucky, success would
be whatever put food on the table and kept a roof over my head. I'm
making an argument from the top of
Maslow's hierarchy. But that is, in a roundabout way, my point: why is
defining and constructing success still so hard, and why do we do such a
bad job at it, even when we're at the top of the pyramid and able to focus
on self-actualization?
The context of this talk for my group is pre-work for a discussion about,
in Sinek's construction, the "why?" of our group. Why are we here, what
is our purpose, and what do we care about? By the mere fact that we are
able to ask questions like that, you can correctly surmise that we're
already successful. The question, therefore, is what should we do with
that success?
I normally hear one or more of the following answers, all of which I find
unsatisfying or problematic.
-
Do more of the things that made us successful. This is useful
in that not being successful sucks, so one does want to do some amount
of maintenance, but it's also profoundly unsatisfying to me
personally. What's the point in being successful if one can't use
that success to do something more interesting, exciting, or
fulfilling? It feels like an argument from fear: the most important
thing to do with success is to ensure that one stays successful.
-
Use that power to change the world. Now, I want to be very
careful here: there are some people who embrace this approach to
success and do, in fact, change the world for the better. I would
never want to say that this is a bad choice in general.
But the problem I personally have with this approach is that the
failure rate for changing the world is quite high. You are probably
not going to change the world. That doesn't mean don't try; sometimes
you do, and when it happens, it's awesome. But the way my mind works
argues against setting this as an explicit goal for me. Setting
explicit goals that I fail at messes me up: I care too much about not
failing and then I burn out. It works better for me psychologically
to treat this as a possibility and a side effect of another goal.
-
Teach other people how to be successful. Full points for
altruism. But let's face it: most of being successful is basically
luck, and there's that survivorship bias problem again. It's
occasionally possible to do some actual scientific studies and figure
out what leads to success, but most of the time you'll instead make up
good-sounding stories about things that you believe strongly in and
present them as your method for achieving success. I'm sure they're
great stories, and they're probably quite inspiring. But they also
probably don't have much to do with why you're successful.
So, what should I do with success? Or, put another way, since I have the
luxury of figuring out a "why?", what's my "why?"
This question comes at a good time. As I've mentioned the last couple of
days here, I've just come off of two days of the most fun I've had at work
in the last several years. I spent about 25 hours total building a log
parsing infrastructure that I'm quite fond of, and which may even be
useful to other people. And I did that in response to a rather prosaic
request: produce a report of user agents by authenticated unique users,
rather than by hits, so that we can get an idea of what percentage of our
community uses different devices or browsers.
This was a problem that I probably could have solved adequately enough for
the original request in four hours, maybe less, and then moved on to
something else. I spent six times that long on it. That's something I
can do because I'm successful: that's the sort of luxury you get when you
can define how you want to do your job.
So, apparently I have an answer to my question staring me in my face: what
I do with success, when I have it, is use that leeway to produce elegant
and comprehensive solutions to problems in a way that fully engages me,
makes the problem more interesting, and constructs infrastructure that I
can reuse for other problems.
Huh. That sounds like a "why?" response that's quite common among hackers
and software developers. Nothing earth-shattering there... except why is
that so rare in a business context? Why isn't it common to answer
questions like "what is our group mission statement" with answers like
that?
This is what I missed in the TED talk, and what the subsequent discussion
with my co-workers brought to light for me. I think Sinek was getting at
this, but I think he buried the lede. The "why?" should be something that
excites
you. Something that you're passionate about. Something
that you believe in. He says that's because other people will then
believe in it too and will buy it from you. I personally don't care about
(or, to be honest, have active antipathy towards) that particular outcome,
but that's fine; that's not the point. The point is that a "why?" comes
from the heart, from something that actually matters, and it creates a
motivating and limiting principle. It defines both what you want to do
and what you don't want to do.
That gives me a personal answer. My "why?" is that I want to build
elegant solutions to problems and do work that I find engaging and can be
proud of afterwards. I automate common tasks not because I particularly
care about being efficient, but because manually doing common tasks is
mind-numbing and boring, and I don't like being bored. I write reliable
systems not particularly because that helps clients, but primarily because
reliable software is more elegant and beautiful and unreliable software
offends me. (Being more usable and frustrating for clients is also
good; don't get me wrong. It's just not a motive. It's an
outcome.)
What does that mean for a group mission statement, a group "why?"
Usually these exercises produce some sort of distillation of the
collective job responsibilities of the people in the group. Our mission
is to maintain core infrastructure to let people do their work and to
support authentication and authorization services for the university,
yadda yadda yadda... this is all true, in its way, but it's also boring.
One can work oneself up to caring about things like that, but it requires
a lot of effort.
But we all have individual "why?" answers, and I bet they look more like
my answer than they do like traditional mission statements. If we're in a
place where we have the luxury of worrying about self-actualization
questions, what gets us up in the morning, what makes it exciting to go
into work, is probably some variation on doing interesting and engaging
work. But it's probably a
different variation for everyone in the
group.
For example, as you can see from above, I like building things. My
happiest moments are when someone gives me a clearly-defined problem
statement that fills a real need and then goes away and leaves me in peace
to solve it. One thing I've learned is that I'm not very good at coming
up with the problem statements myself; I can do it, but usually I end up
solving some problem that isn't very important to other people. I love it
when my employer can hand me real problems that will make the world better
for people, since often they're a lot more interesting (and meaningful)
than the problems I come up with on my own.
But that's all highly idiosyncratic and is not going to be shared by
everyone in my group. I'm an introvert; the "leave me alone" part of that
is important. Other people are extroverts; what gets them up in the
morning is, in part, engaging with other people. Some people care
passionately about UI design. (I also care passionately about UI design,
but the UI designs that I'm passionate about are the ones that are natural
for my people, who are apparently aliens from another galaxy, so I'm not
the person you want doing UI design for things used by humans.) Others
might be particularly interested in researching new technology, or coming
up with those problem statements, or in smoothly-running production
systems, or in metrics and reporting... I don't really know, but I do know
that there's no one answer that fits everyone. Which means that none of
our individual "why?" responses should become the group "why?".
However, I think that leads to an answer, and it's the answer I'm going to
advocate for in the meeting tomorrow. I believe the "why?" of our team
should be to use the leeway, trust, and credibility that we have because
we're successful to try to create an environment in which every individual
member of the team can follow their own "why?" responses. In other words,
I think the mission of our group should not be about any specific
technology, or about any specific set of services, or outcomes. The way
we should use our success is to let every member of our team work in a way
that lights their fire. That makes them excited to come into work. That
lets each of us have as much fun as I had in the past two days.
We should have as our
goal to create passionate and empowered
employees. Nothing more, but nothing less.
This is totally not how group mission statements are done. They're always
about blending in to some larger overall technological purpose. But I
think that's a mistake, and (despite disliking the presentation), I think
that's what this TED talk does actually get at. The purpose is the what,
or sometimes the how. It's not the why. And the why isn't static;
technology is changing fast, and people are using technology in different
ways. Any mission statement around technology today is going to be
obsolete in short order, and is going to be too narrow. But I think the
flip side is that good technological solutions to the problems of the
larger organization are outcomes that fall out of having passionate and
inspired employees. If people can work in ways that engage and excite
them, they will end up solving problems.
We're all adults; we know that we're paid to do a job and that job needs
to involve solving real problems for the larger organization. All of that
is obvious, and therefore none of that belongs in a mission statement. A
mission statement should state the inobvious. And while some visionary
people can come up with mission statements around technology or around how
people use technology that can be a rallying point for a team or
organization, I think that's much rarer than people like to think it is.
If you stumble across one like that, great, but I think most teams, and
certainly our team, would be better served by having the
team
mission statement be to enable every
individual on the team to be
passionate about their work.
What should our group work on next? Figure out what the university's
problems are, line those needs up with the passions of the members of the
team, ask the people most excited about each problem how they want to
solve that problem, and write down the answers. There's our roadmap and
our strategy, all rolled into one.
Changes:
Better debugging tools can help us understand what's going on with MIME messages. A python scrap i wrote a couple years ago named printmimestructure has been very useful to me, so i thought i'd share it. It reads a message from stdin, and prints a visualisation of its structure, like this: 
Usually I'm monitoring stuff with 
After this 
This post is about the port bootstrap build ordering tool (naming suggestions
welcome) which was started as a 
I moved to Boston in 2005 at the same time that 
ITWire ran a story on the 12th of January entitled "Fedora still has problems with secure boot". It ends up discussing two issues with the author's experience with the Fedora installer - that he can't reclaim any free space on existing drives, and that the installer didn't automatically add entries for Windows to the grub menu. These are certainly legitimate issues, and I don't want to suggest that it's reasonable for people to have to manually alter their configuration in order to support dual boot. But they're not issues with Fedora's support for secure boot, despite the enthusiasm with which certain people have jumped on the story. We've received one credible report of a secure boot related problem with Fedora on a couple of Toshiba laptops, which appears (and I want to stress that we're still working on diagnosing it) to be a firmware bug rather than any kind of problem with Fedora.
I want to like LDAP. Every so often I do interesting things with it, and I start to think I like it, then some software that claims to support LDAP fails to do so properly and I remember I hate it again.
I guess the problem with LDAP is that most people are scared by it, unless you reach a certain level of scale you don't need it. That makes installing it out of the blue a scary prospect, and that means that lots of toy-software applications don't even consider using it until they're mature and large.
When you bolt-on support for LDAP to an existing project you have to make compromises; do you create local entries in your system for these scary-remote-LDAP-users? Do you map group members from LDAP into your own group system? ANd so on.
To be fair to the application developers if the requirements for installation were "Install LDAP" they'd probably have a damn smaller userbase, and so we cannot blame OpenLDAP, or the other servers.
All the same it is a shame.
The very next piece of software I ever write that needs to handle logins will use LDAP and only LDAP. How hard can it be?
In happier news 
In my 
The prototype still need to be improved with longer timeouts, but
is already useful. The database of hardware to package mappings also
need more work. It is currently compatible with the Ubuntu way of
storing such information in the package control file, but could be
changed to use other formats instead or in addition to the current
method. I've dropped the use of discover for this mapping, as the
modalias approach is more flexible and easier to use on Linux as long
as the Linux kernel expose its modalias strings directly.
Update 2013-01-21 16:50: Due to popular demand,
here is the command required to check out and build the source: Use
'svn checkout
svn://svn.debian.org/debian-edu/trunk/src/hw-support-handler/; cd
hw-support-handler; debuild'. If you lack debuild, install the
devscripts package.
Update 2013-01-23 12:00: The project is now
renamed to Isenkram and the source moved from the Debian Edu
subversion repository to a Debian collab-maint git repository. See
