The Three Rs
No, I'm not talking about reading, writing, and 'rithmitic, I'm
talking about the three Rs that are critical in creating and keeping a
software organization strong.
The three Rs in this case are Rigor, Resources, and Raison
d'etre. Let's take a look at each of these in turn.
Resources
I begin with resources because when push comes to shove
this is one of the most important factors in making your team a
success.
Am I saying that you can't build an incredible team with nothing but
the sheer will to bring your idea to fruition? Hell no. I'm saying
that good will only goes so far. After a while you will need to pay
your people what they're worth, and be able to hire enough help that
individual contributors don't feel like they're being exploited and
suffering from burn out.
This is a mistake I'm seeing more and more companies make over time.
Modern development techniques are increasing our overall
productivity dramatically, but they are not a substitute for having
enough man power to do the job you need done in the time frame the
business demands.
You can't substitute creature comforts for this either. No amount of
free snacks, soda, coffee or snuggles will make an engineer who's
working night and day with no time to take care of themselves
happy. These things are nice add-one and can make employees feel
valued, but only when they're in addition to an environment that gets
the basics right.
There are other aspects to being properly resourced. Be sure you can
afford the equipment you need. If your business demands that you run a
data center, do it right! If you don't, you will increase the
frustration your employees have to deal with day to day to get their
jobs done, and that will seep into overall job satisfaction very
quickly.
There's more to say on this - good office work environments including
sit/stand desks, keyboard trays or whatever else your employees need
to be productive without harming themselves. Don't skimp on this
stuff, it's super important, and your employees will thank you for it.
Rigor
I wrestled with myself a bit as to whether this should come
first or second, but anyway, Here we go. We all know that having
rigorous processes as individual contributors and organizations is
important. It's what enables us to deliver quality software in a
timely fashion and bring value to our customers.
However a lot of people, including some very experienced engineers,
seem to think that how we get there is some kind of magical journey to
another dimension, only attainable by the assistance of some wizard or
ascetic.
But the cold, hard, in-sexy truth is that it's all about
discipline. Doing precisely the same set of things over and over again
until they become second nature, "baked in" whatever you want to call
it.
Let's take code reviews as an example. I can't even begin to tell you
the difference I've seen between strong organizations and weak ones,
and almost inevitably, how teams handle code review is the canary in
the coal mine.
I'm not suggesting that code reviews in and of themselves are some
kind of magical panacea that will make your organization great, but
chances are good that if you're doing regular code reviews with every
merge, you're also doing testing. If you're doing comprehensive
testing, you're probably also taking the time to write good
documentation. The list goes on and on.
Everybody knows these are good things, but why are so many
organizations slow to adopt them? Well, as usual with such things,
It's Complicated. One contributing factor is definitely team size
versus work load, as outlined in the section on Resources.
Individual contributors who are working straight out all the time
aren't going to take the time to do proper code reviews, and chances
are good that in such organizations, their managers won't be pushing
for them either. It's a kind of myopia that cripples teams and
actually hurts the business both short term and long. Some people are
beginning to see that, but it's something we should all be aware of
and actively promoting within our organizations wherever we are on the
discipline curve.
Raison d'etre
This is about vision. I know, we've all had that
word misused, abused, and generally beaten to death so much over the
course of our careers that most of us cringe when we hear it. However
no other word embodies what I'm trying to get at in quite the same
way.
In order to form a cohesive unit - something we all agree is critical
to success, we all have to know where we're going. What precisely are
we trying to build, and why? Where's the value for our customers, and
where do we see our product going in the future?
I've encountered many organizations where this isn't clear at all, and
when that happens, a sort of spiritual malaise sets in. It's like a
disease, spreading up through the ranks and sapping job satisfaction
and pride in workmanship.
Fixing things once your organization has gone this way is hard. I
mean, really hard, because regaining the trust of your team is not
something you can do over night. You'll need to overcome years of hard
earned scar tissue before people will be able to have the confidence
in you and your product that are necessary for success. There are no
clear cut prescriptions to make here, because each organization's path
to healing will depend on the nature and scale of the wounds.
Much easier to start on the right foot and stay that way. Doing so is
actually straight forward. The key is having a clear vision yourself,
and communicating that with your team.
I realize our business is a harm scarum one and that changes in
direction are not only inevitable but desirable to meet changing
conditions in the field, but how those changes are handled and the
frequency with which they occur can mean the difference between an
organization that thrives and a cadre of walking wounded, shambling
from one death march to the next until they take too much damage and
decide to ply their trade elsewhere.
Hiring and layoffs are another aspect of employee trust whose import
should not be underestimated. When you hire, hire for the long haul
or be crystal clear about what your expectations are "We're trying
this risky new thing and you're here to make that happen. If it
doesn't work out, we may need to go our separate ways." I can't
imagine anyone who wouldn't appreciate knowing that up front, and if
they have even a tiny amount of character and maturity, if that's the
way it plays out when the time comes, you can walk away friends. It's
a booming industry out there and there are no shortage of jobs.
If they must happen, layoffs should be handled quickly and
professionally. You need to be crystal clear with both the people
being laid off and the people left behind as to why this is happening
from the perspective of the business. The people who are left will be
nervous and unsettled, and they'll be able to recover much more
quickly if everything is handled in an above board way.
Again, don't lie. If you need to lay people off, and you have a
flexible schedule in your office, by all means do send out mail
saying "mandatory meeting at X time" to be sure everyone will be in
the office, but don't tell those being laid off that it's a meeting
about something else entirely. They will resent you for it.
Crystal clear, honest communication and clear vision will result in
enthusiastic employees who are excited at the prospect making their
company a raging success.
Comments