Home » 2013 » April


One thing I’ve learned in my years as a developer is that I am more eager to go to work, and am more invested in doing the best job I can, when I feel an emotional connection to my team and my employers.

That connection can take the form of friendship, or loyalty, or empathy, but if it’s there, I do better.

Knowing this about myself, I’ve always made an effort to build that connection to my team and to people in other teams throughout my company. I’m naturally a gregarious, goofy guy (sometimes to excess) and I try to use those tendencies to make friends. I also get to understand the business, what it’s doing, how all the pieces fit together and how each team contributes to the goal. And then for me, doing my part becomes more important because I know how what I do impacts everyone else.

I also know that I’ve worked for people at some of my jobs that have encouraged and facilitated this, either deliberately, opportunistically, or instinctively, because they understand that value.

Being in the lead role, it’s important I understand that I, now, also should take the time to foster that connection in my team. I don’t know if it’s in me to inspire loyalty, but even if it’s not, I think I’m not too bad at building a little friendship and empathy amongst my team. But beyond that, it’s important for me to help the people on my team get a grasp of the things that leads like myself have to get to understand implicitly, namely, the various parts of the company and how they work togther, how the work of our team impacts all those other teams, and how those teams impact our own.

By encouraging my own team to build those emotional connections, I encourage them to become more invested in their jobs. And if I succeed, I reap the twin rewards of lower turnover and greater productivity — as well as making some friends along the way.

The counterpoint to all this is an experience I’ve had many times as well — a company where those connections are not encouraged and are not valued. We’ve all been there, whether it takes the form of a boss who’s all stick and no carrot, a team that is every-man-for-himself, or a team so isolated from the rest of the company that they don’t care about anything that doesn’t directly impact them. Think on your experiences in places like this. Did you work harder, or not? Did you have an easier or harder time getting out of bed in the morning? Were you more or less willing to stay late to get the job done?

Yeah, me too.

So it’s really a no-brainer which kind of culture I want to foster in my team. So it’s just a matter of learning how.


Some people seem to think that by impressing a sense of sufficient urgency that the impossible can be made possible.

Let’s consider the hypothetical scenario where you’re at home, and you live a 30 minute drive from work when traffic is good. Today, traffic is not good.

Your boss calls you in a panic and says you have to be at work in 15 minutes. You tell him you’ll head out immediately but it’s really unlikely you’ll be there in less than 30.

Your boss tells you that you need to be at work in 15 minutes or the company will lose its most important client. You tell him you’re already on your way, but it’ll still be 30 minutes, even if you speed and weave through traffic.

Your boss tells you that you need to be at work in 15 minutes or the company will go under, and it will be all your fault. You’re upset, and angry, but you tell him there’s no way you can be there in time.

So you break several traffic laws and finally rush into work 25 minutes later, your boss blames you for failing to come to work on time and causing the demise of the company. And you’re silently plotting how to murder your boss without leaving any forensic evidence.

The entire scenario is absurd, of course, yet this is an all too common scenario of software development: The business owner sets a development schedule that’s laughably unrealistic, and when the development lead pushes back, the business owner behaves as if he believes he can make the project complete on schedule by imparting a sufficient sense of urgency to the development team.

It won’t work, of course; the dev team may, of course, work in panic mode for the duration of the project and try in futility to make the deadline, and then when they fail they will be so exhausted and burned out that they will be useless as developers for weeks afterwards, but that means the project fails and the company has a completely demoralized dev team that’s probably been updating their resumes.

Project owners need to listen to their development teams when they say that the project deadline is far too soon. Instead of trying to crack the whip, project owners need to work with the development lead and project manager to figure out the alternative. That alternative may be a reduced list of features, a revised deadline, the addition of resources, or some combination of the three.

But setting an arbitrary deadline and offering only urgency and consequences to the development team for failing to meet it, apart from violating the Fourth Rule of Development, can seriously damage the morale, and by extension the value and effectivenes, of the development team.

It’s about the team

First, a note:

I’ve been rethinking, due to feedback from friends and family, how I present the content of this trifle of a blog. I’ve been writing directly about my experiences while keeping the name of my company, and the names of my coworkers, obfuscated using nicknames and euphemisms. However, that isn’t really obfuscated enough to keep me out of trouble should this blog ever get connected to me by the wrong people. So, henceforth, I shall talk about my learnings without directly relating my experiences at work, so there will be no issue. You can make up your own story about what experiences I had which led me to be taught or reminded of whatever I’m imparting with my blog entries. Experiences outside of work, well, those I may continue to discuss directly as discretion permits.


Now then.

One quality of a development team, or indeed any team working together, that is often undervalued is how well the members of the team interact on a personal level. Teams which are comprised of even exceptionally talented people who do not have any affinity for one another will not work exceptionally well together. Teams of much more modest talent who have a strong affinity for one another will become more than the sum of their parts. It’s not hard to imagine circumstances where a less talented team with more mutual affinity will be more productive with better results than a more talented but less cohesive team.

A lot of employers understand that personal affinity is important; they interview for new hires by evaluating technical skill but also how well they believe the candidate’s personality will integrate with the team and/or the company. They call this ‘cultural fit’ usually, but I think they often don’t consider the full implications of how well personalities fit one another, and in particular the magic that can happen where a team comes together comprised of people who develop strong professional and personal bonds with one another.

Here’s a question: How many times have you seen a candidate for a job show strong technical qualifications, but is iffy culturally, and get hired despite misgivings over the cultural fit? Here’s another: How many times have you seen a candidate for a job who presents a superb cultural fit, but is more iffy in technical qualifications, and get hired anyway?

I bet most people in the development world would answer these questions somewhere between “occasionally” and “frequently”, and somewhere between “never” and “almost never” respectively. For me it’s “occasionally” and “never”. But let’s think about this, and consider that this is exactly the opposite of the way things should be.

Skills can be taught. Someone entering a job with some technical deficiencies can be trained to grow into the job. Anyone with development experience has witnessed this — most of us, in fact, have lived it. We learn, adapt, and grow to meet the needs of our jobs even if we don’t start with the necessary skills. If we can’t do that, we’re probably not in the right line of work. We can also learn ‘soft skills’ – leadership skills, communication skills, organization, etc. But we can’t learn to have a different personality.

Oh, sure, we can learn to fake it; learn to pretend that the Nerf gun war that breaks out among the development team isn’t an annoyance and is fun; learn to have detailed conversations about international cuisine like it’s interesting; learn to geek out about the latest episode of Doctor Who or The Walking Dead as if we are interested in either — but if you don’t love shooting your buddies with foam darts, if you don’t relish new dining experiences, or if you don’t giggle inside at the phrase ‘wibbly wobbly, timey wimey’, you aren’t going to change. And fundamentally, you’re never going to build that connection to people who geek out in ways that you don’t.

So why is it that hiring decisions are often made on the principle that trainable qualifications are more valuable than untrainable qualifications?

In the area where I live, positions available for highly skilled developers are much more numerous than developers are available to fill those positions. My friend and colleague Red, whom I’m now calling Mojo (because she prefers Mojo) has said that the best solution is to find a strong cultural fit who’s below the desired skill level, hire that candidate, and invest in that developer through mentoring and training. This course of action makes even greater sense in light of the above.

So with all that in mind, imagine that rare confluence of a great group of developers, designers, project people and leadership who have developed that strong affinity, mutual respect, and friendship with one another. This is a group of people who not only want to be successful as individuals but who want to see each other succeed as well. They look forward to seeing one another and collaborating together.

How much harder and with how much more dedication will this group of people work on a given project when they have that mutual bond motivating them? And what will they be able to accomplish together?

I’d sure as hell like to find out.