Best Companies to Work For, Part 2

As I mentioned in an earlier post, at the end of June I was very pleased to learn that Construx Software (my company) had been recognized as the Best Small Company to Work For in Washington state. Getting the outside validation was gratifying, but what does the inside view look like? What do Construx's employees think makes Construx a good company to work for? We held an all company lunch discussion in July to talk about that question, and here's what people said.

Participatory Decision Making. We don't make very many decisions behind closed doors, or at least not without getting input from some, most, or all employees. We survey employees regularly. We do a big employee satisfaction survey once a year. We survey on other issues as needed, on topics like when we should hold our holiday dinner, which new benefits employees would value more, and so on. The Washington CEO article also commented on the degree to which we involved employees during our rocky period in 2001-2002, which our employees brought up again during our lunch discussion.

Make Your Own Job. Our technical service providers (TSPs) essentially define their own jobs within three broad parameters. First, their work needs to support our mission (Advancing the art and science of commercial software engineering). Second, they need to hit their billable revenue target (which isn't a problem since most of our TSPs beat their target at least 50%). Third, their work needs to meet our service quality targets -- we reserve the right to pull the plug on offerings that aren't delighting our clients. As long as the work they want to do meets those criteria, each TSP has a lot of latitude. A TSP can develop a new course more or less according to his/her interests. A TSP can work on a new consulting offering, spend time blogging, write a book, etc. The people who like this approach, love it. A couple people have seemed to want more direction. In any case, the decision about what to work on is made collaborative (see point #1, above), so people who want more direction get that, and people who have a strong feeling about a direction they want to pursue normally get that, too.

The flip side of this is that employees become highly responsible for service quality. This is fine for us as we want to hire people who seek out responsibility.

Lack of Competitiveness/Helping Each Other. Our environment is very cooperative. TSPs help each other; sales personnel help each other; TSPs help sales staff, and sales staff helps the TSPs. We’ve worked hard to replace “us vs. them” thinking with “we” thinking, and I think that’s pretty deeply engrained in our culture at this point. We understand that we’re all in this together, and people act accordingly.

This can go to fairly extreme degrees, with one TSP pitching in and teaching a class in a remote city to help out another TSP.

Flexibility. We offer a lot of flexibility in terms of hours and days worked, subject to the three criteria mentioned at the top of the post.

Profitability. We believe strongly that we can be good to our employees and still be profitable – furthermore, that being good to our employees will actually help profitability in the long run.

Easy going culture. There isn’t much yelling here. It’s pretty relaxed. We wear business casual clothing (even on the casual side of “business casual”), including shorts in the summer. If we have client meetings we expect people to dress appropriate for the client. In the software business, that’s usually business casual, but probably not shorts and t-shirts for most of our clients.

Treating Employees as Humans First, Employees Second. We had a rough patch this spring during which we had 3 employees lose parents in a 60-day period. Losing a parent is a major life event, and work needs to take a back seat for awhile when that happens. Our employees were appreciative that we recognized that. I have to admit that I am surprised that people appreciate this, mostly because I simply can’t imagine a manager being so heartless as to not recognize the significance of that kind of major event.

At a more day-to-day level, we’re also pretty understanding of people needing to leave to pick up their kids from daycare, attend school plays, ball games, etc. Sometimes work has to take precedence, but usually work life and home life can be kept in balance.

Overall. Our lunch discussion didn’t turn out to be a very comprehensive or systematic discussion. I think we mostly just hit points that the Washington CEO writeup missed, or that seemed underemphasized in that article.

I’ll write up what I think makes us a best company to work for in a future blog entry.

Jacob said:

August 7, 2007 9:18:AM

Thanks for putting into practice the things you write about. When the tech market gets tight like it is right now, companies reflexively compete for competent workers with salary. After a basic watermark, though, salary just doesn't motivate the way simple company policies like the ones you outline here do. Well, just because they are simple doesn't mean they are easy. It takes a lot of institutional fortitude to do all this, but the payoffs are very gratifying (for both the employer and employee).

Nate Kohari said:

August 8, 2007 11:02:AM

Very interesting approach. I'm particularly intrigued by the "make your own job" description. How do you keep people from gravitating towards the most profitable projects in order to maximize their "free" time while still meeting their profitability goal? It seems like that sort of situation would cause employees to move towards the projects with the highest hourly rates. Or do you measure the billable hours goal in hours and not dollars?

> How do you keep people from gravitating towards the most profitable projects in order to maximize

> their "free" time while still meeting their profitability goal?

We don't! We want people to gravitate toward the work that produces the most revenue for least time invested. If we were see someone doing this in a short-sighted way (i.e., they were sacrificing long-term revenue for short-term revenue), we would try to change that, but considering the orientation of the people we hire, that hasn't been a problem -- everyone on our staff has a strong focus on doing high quality work that will pay off in the long term.

After rereading your comment, I see you said "gravitating toward *projects*". In our environment, we don't have "projects" in a traditional software sense. We have a mix of training and consulting assignments which range in duration from a few days to a few weeks. Most people work on a mix of higher margin and lower margin assignments. People tend to be directed more by what they're qualified to work on and by what work is available than by cherry picking higher margin assignments. For the cherry picking to be a concern, we would need to have an excess of assignments available -- without an excess, people basically just work on whatever is available. Since a big part of our culture is not burning people out (at least not on a continuing basis), we haven't had a problem with employees wanting to cherry pick.

Maksym Shostak said:

August 9, 2007 4:56:AM

I know that there are two ways of management (pedagogics):

- First is from position of power and keeping employees in fear;

- Second is from position of mutual respect.

The second is better than first - what has been proved by Construx.

Post a Comment:

Steve McConnell is CEO and Chief Software Engineer at Construx
Software where he consults to a broad range of industries, teaches seminars,
and oversees Construx’s software development practices. In 1998, readers of
Software Development magazine named Steve one of the three most
influential people in the software industry along with Bill Gates and Linus
Torvalds.

Steve is the author of Software Estimation: Demystifying
the Black Art (2006), Code Complete (1993, 2004), Rapid
Development (1996), Software Project Survival Guide (1998), and
Professional Software Development (2004). His books twice won Software
Development magazine's Jolt Excellence award for outstanding software
development book of the year.

Steve has served as Editor in Chief of
IEEE Software magazine, on the Panel of Experts of the SWEBOK project,
and as Chair of the IEEE Computer Society’s Professional Practices Committee.