7 Dev Team Secrets IT Managers Need To Know- Valutrics

In the mind of many managers, the software development group is a black box filled with creatures from myth. You throw in a specification document and after a suitable period of time (usually defined as deadline + r, where r is a random number of troubleshooting days), working software pops out.

It’s a lovely system, as myth-based systems go, but it leaves a lot to be desired when it comes to successfully managing the development process.

Most software development managers know that the software development group is staffed with human beings who respond to the same sort of factors that have an impact on most of us, but the rise of DevOps means that non-software development managers are increasingly called upon to interact with developers and even assist in managing development-based projects.

If you find yourself in that situation, there are several things that you need to know about software development in order to have things go as smoothly as possible. I’m not talking about the inner secrets of agile development or scrum, here. These are the sort of things that you need to know regardless of the particular discipline being used.

How do I know these things? To start with, I’ve been a developer and managed developers. I also spend a lot of time talking with developers and their managers. I also read what developers write. These points are distilled from all of those sources, with a touch of judgment and life experience thrown in for flavor.

I’m willing to admit that there are other things that managers should know before they dive into the deep end of the software development pool, and I’d love to hear your ideas about what those things are.

Here are my items to get you started. Take a look and let me know what you think. Somewhere, a software dev group is waiting.

Developers Need Hardware

In an IT world that is increasingly cloud-based, there are jobs in which the hardware still matters. Software development is one of those jobs. You can start with the monitor. Yes, purchasing can get a super deal on some “good enough” monitors, but developers are staring at screens all day long. What they see and interact with on those screens will have a significant impact on the company. Spend some dollars and get every developer a top-notch monitor or two — even three.

Once you’ve given developers something nice to look at, give them the keyboard they like. It might be loud and clicky, but it will help them be more productive. This is not the place to force everyone onto the same keyboard. Give people a catalog and let them pick a keyboard and a mouse.

Finally, whether the languages they’re developing in are interpreted or compiled, creating running code from typed commands takes some computing horsepower. Don’t cheap out on the platform. Whether it’s a desktop box or a laptop, support spending the money for a solid system. Whatever you pay now will be more than repaid in productivity and lower turnover. Seriously.

Developers Talk … Only Not With You

The image of the lone programmer sitting in solitude while code occasionally appears on the server may not be totally out of date, but it does need serious modification. Software developers are working on teams now, and teams have to communicate. They simply might not communicate in the way that you’re used to talking with your sales, marketing, and operations teams.

Morning scrum meetings might have changed the frequency with which teams get together, but most communication in most dev teams will happen via Slack, or your organization’s group chat client. Now, here’s how to approach the dev team’s Slack group: Join and then shut up. Watch the traffic and listen for a good while before you start talking. Learn the rules of the local community and fit in — it’s the best way to get ahead of the plethora of problems that will arise simply from not communicating.

All Programmers Are Not Created Equal

Here are two related facts: First, there are good programmers and bad programmers. Second, the programmers who make up the development team know who falls into which category. One of the fastest ways for a manager to lose the team’s respect is not knowing which is which — and acting like he or she does know.

When you’re dropping in on a dev group, watch and listen to the interactions. You’ll find that there’s likely to be a trouble-shooter, a creative thinker, an encyclopedia, a peacemaker, and a handful of other leaders. There may also be someone who doesn’t seem to fit in and who has trouble keeping up with the activity. Watch all of these people interact and follow their leads, and you won’t go far wrong when you’re dealing with the team.

Estimates Are Just That

If you haven’t run into a SWAG (a scientific wild-a#%$ guess), then you haven’t spent much time around programmers or engineers. A SWAG is based on more data than a simple guess, and it’s less formal than a true estimate — but everything on the spectrum between the two is speculation. It’s important to remember that fact when you’re basing your plans on what you’re hearing about how long a project will take.

One of the great advantages of the sprint is that the short time horizon limits how far astray any single estimate can go. You don’t want to get into the translation from estimate to “real” that I was taught in my first technology job. (Double the estimate, then go up by one unit of time, e.g. a figure of four days becomes eight weeks.) But you do want to make sure that any dependencies have some wiggle built in — especially if you’re dealing with a team for the first time.

Fast, Cheap, And Good: Pick Two

There’s nothing new about this aphorism. What’s different about the development group is that the variable is generally going to be speed. Do you want a piece of software in about half the time of the initial estimate? Good developers will make it happen, but it won’t be pretty.

The problem is that a lot of managers coming from outside the dev group believe that since software development is almost entirely a mental activity, management can simply will the team to think faster. It doesn’t work that way.

Building individual program modules takes time. Testing those modules properly takes time. Integrating them into a whole takes time. You can probably reduce the time taken up by any one of these steps, but there will be costs in quality and certainty. If you’re going to insist, be sure that you’re willing to pay the price.

Developers Hate Documentation

You know that warm, fuzzy feeling you have when it comes to doing your travel expense reports? That’s pretty much the way the vast majority of programmers feel about documentation. It’s one of the things that managers have fought since the early days of computing and it’s something you must learn to manage if you want to be successful in dealing with developers.

Earlier I wrote about the trade-off between speed and quality. Documentation is often one of the things that programmers will use as a trading card when managers insist on a shortened timeline. Be ready for that, and be aware of what the trade-off means. You’re trading faster turn-around now for more difficult code maintenance and trouble-shooting later.

My recommendation? Unless you’re creating code for a public application (where there can be security reasons to strip the code out before final compilation), go ahead, insist on good documentation within the code, and figure out the schedule. In the long run you’ll be very glad you did.

We’re Talking About People, Here

One of the most persistent myths about programmers is that they’re some sort of alien creatures motivated by things that most human beings don’t care about. The truth is that programmers are human beings. All those things you learned in management training about how to motivate employees and get teams to work together are broadly applicable to programmers, though you’re likely to need to tweak their application just a little.

Programmers tend to work in a culture where status comes from problems solved, challenges met, and artistry that is recognized by your peers. With that said, teams still have to be formed, coached, and managed. Money (or things of value, like vacation days) are still the currency with which a commercial organization shows its appreciation. Don’t give up your management tools when you meet a dev team. Adapt them to the culture.

Above all, remember that most developers are entirely happy to explain what they’re doing and why to non-programmers who ask out of genuine curiosity and respect. Approach this new team the way you’d like to be approached, and the odds are good that the encounter will be a good one for both sides.

Those are my simple tips for approaching a dev team if you’re not a development manager. You don’t necessarily have to know a programming language (although being able to think logically is a plus). You don’t have to possess a particular educational background. You don’t have to come in “speaking the language” of the developer. You do have to treat the team members as human beings and their work as valuable.

What did I leave out? What advice would you give a manager who’s coming into a dev group from outside? I’d love to know. Meet me in the comments.