Disclaimer: in no way were any developers harmed in the process of researching this article.

Some days they are trying to squeeze ridiculous amounts of money out of you. Other days, they are your older, protective siblings solving your problems selflessly. Treat them fairly and they might even be willing to put in free work for you. They’re an interesting breed, and for any technology company, they’re an indispensable one. So how do you hire and subsequently work with developers?

 

My Own Foray into Development

I originally learned bits and pieces of software development as an interest in technology, but it morphed into an interest in the people who engage in development, too. Just as well, because the time I spent learning to code has paid big dividends in my ability to communicate between the business side and technical side of the company. At CityFALCON, we’ve been fortunate to have a down-to-earth team of developers who were also willing to open the street to two-way communication, and my initial ability to start conversation with a clear idea of how developers think probably contributed significantly to that opening of communication.

 

The Demands of the Developer

During the hiring process, entrepreneurs will get their first taste of the species. For those who have never worked in technology and don’t know the culture in software development, it might come as a bit of a shock. But for those who have read this article, the shock should be blunted. There will be some variation across generations, but it probably won’t be as pronounced as the generational divide in some other professions.

Common conditions observed through repeated experimentation during the hiring process: No overtime. No on-site working. No set hours. No hard deadlines. Yes high pay. Yes flexible holiday time. Yes a choice of projects. Yes high autonomy.

These are some sample demands you might run into as the hiring agent. Yes, as the hiring agent, in the interview, you might be asked whether your company will be providing these benefits. Sometimes the no-overtime-high-pay requirement can be a sticking point. For the best developers, they know they can demand this, so if you have someone sitting in front of you, very confidently demanding these conditions, you probably have a good developer within reach.

This may be a shock, as it is likely slightly different from the demands of other employees, who usually ask for high salaries, maybe some vacation time, and fringe benefits, like gym memberships and free coffee. Of course, the developers would probably like those perks, too, but they have their reasons for demanding what they demand.

Interestingly, once the specimen integrates into the group, and especially at companies with tight-knit cultures, they become like family. This is when many of those demands (temporarily) go out the window, and the developer becomes like the older sibling helping you out no matter the cost to them. Of course, if you push too hard too long, they’ll just jump ship to the next (and possibly better) company.

 

The Motivations of the Developer

The demands stated in the section above originate from the particular motivations of the developer. Of course, just like any human worker – we make a point here to exclude robot workers who tend to not demand anything at all except oil, electricity, and the occasional software update – the developer wants a nice life, social acceptance, interesting work, and so on.

While many people are simply looking for money to buy into consumer culture, developers tend to be more interested in intellectual progress and achievement. It makes sense and follows naturally from their work, since their chosen field is one big knowledge-intensive endeavour.

Obviously they demand money, too, because they need to live. But after a certain point, the money is less important than other factors, like a work culture and management that understands them.

Other motivations include:

Learning – they don’t really want to be the smartest people in the room, because then they couldn’t learn and improve themselves. Honestly speaking, most devs revel in knowing a lot about their area of expertise and will flaunt it when it comes up, but they’ll also listen intently when people with knowledge in other areas speak so they can learn about those areas. Like a brain-sponge soaking up information for later conquest.

Be Taken Seriously – if they make a suggestion, they want to be taken seriously by management. This is a basic employee motivation, but for some reason, when developers voice their suggestions, a lot of managers write it off as “just a techie thing”. Not much makes a developer’s blood boil like a non-technical person stating “it’s just a techie thing”. Surprising to no one, the vast majority of businesses run on at least some tech these days, in effect making every business at least somewhat  “a techie thing”

Understood – they want to be understood, too. Similarly to being taken seriously, this is also a basic employee desire. And again, developers tend to be less understood than customer-facing or partner-facing teams. The latter works with humans and human interactions all day while devs work with systems. Sometimes it takes a little extra effort to understand devs over human-centric roles, but it’s worth the effort.

 

Interacting with the Species

Now that you’ve caught a developer (presumably by hiring and not by bear trap), you will need to know how to handle interactions. Obviously they won’t rip your face off like a trapped bear, but several bad interactions and you could see slower websites and lowered productivity – who wants to work at a place with an oppressive culture?

 

Giving and Receiving Advice

One area where a lot of issues pop up is during giving and receiving advice. Employees who are not on the tech side of the business may believe something is perfectly easy to do, but it may not be. They tend to give advice like “oh, just do X and it will work”. Sure, that might work from the user’s perspective, but doing X breaks three things on the backend and brings down an integral system that users don’t see but utterly rely upon.

There is also the problem of condescension. One might say “it shouldn’t be that hard…” But if the developer is saying it is hard, it probably is hard. Tech is not a magic device, and developers are not magicians. They cannot make things happen if they cannot make things happen, and using language like “it shouldn’t be that hard” is a surefire way to cause roadblocks.

For these reasons, developers often don’t take advice from anyone except other developers. In a way, it makes sense: the only people who possess deep knowledge about the systems are other developers. Experts give other experts advice, precisely because that’s where their expertise lies. Laypeople usually don’t bring much to the table. You wouldn’t want your plumber telling your cardiothoracic surgeon how to do heart surgery, just because both work with pipes and valves, would you?

Similarly, developers might push for certain solutions that are not operationally or public relationally feasible. Have a solution to automate 75% of the jobs away but it only hits 81% accuracy? Well, it might be a technical marvel, but it just won’t work from a business and customer service perspective. Let alone the PR nightmare of firing three quarters of the workforce. For this analogy, you wouldn’t want your heart surgeon repairing your burst pipe in an emergency if he’s never experienced 80 PSI water pressure emergencies before.

 

Managing Expectations

Those on the frontlines of the business will have visions, but too often they believe developers are wizards. They’re not. They may be smart, they may be able to work some conjuring tricks, but everything is based in physics and computer science. That means there is no wizardry, and not every business vision can feasibly be implemented. Or perhaps it is possible, but the IT department is only allotted a certain budget, and the vision would be way too expensive in computational resources.

The worst way to manage expectations is to bring developers into the conversation in the later stages of development. Don’t do this. If you want something to be developed, you should bring the developer in early. That will ensure it is actually technically feasible.

Devs aren’t brainless automatons, either. They’re interactive, as long as you speak to them, and they (usually) speak back. They will tell you what is possible, and they will even work to find solutions if they think they exist. They’ll probably also help guide the development process with a technical angle. You don’t want your entire project built on a single assumption to only find out, after 3 months of planning, that your assumption isn’t possible based on the company’s computing resources.

 

Promotion and Responsibilities

Developers want to code and design systems. That’s the reason they got into this line of work in the first place. Many do not want to follow the traditional career progression path, either. Developers (and many other technical workers) are often made into managers, but a lot of them don’t really want the extra responsibilities nor the human management aspect of it. Humans are complex and often illogical, unlike computer systems. That can be extremely frustrating for people used to working with logical systems. One also cannot completely scrap a human and rebuild it in a virtual environment, so there’s that, too.

On the other hand, some developers actually would like to be managers. Or they are open enough to new ideas to at least give it a try. If they don’t like it, make sure to have a way to transition them back to less managerial roles after a short while. If you don’t, they might jump ship. Tech-only dev jobs are plentiful and pay very well.

 

Alone Time and Sociability

There’s a stereotype of developers as server-room dwellers, sitting in the cold and dark, never speaking to anyone except through chat programs, never leaving the room except to go home, and any interruption is entirely unwelcome. This is only partially true.

Developers, just like anyone, really, want uninterrupted time to work on their projects. Frequently developers must juggle various parts of a system in their heads and try to integrate new ideas into them without breaking any of the other parts. Human memory isn’t as reliable as computer memory, and interruptions can quickly cause that act to collapse. It takes a lot of energy to get the juggling started again, and that is the reason why devs don’t like to be interrupted.

However, they are just as social as anyone else in the group. Try to include them in your outings or your office antics (you can leave out office politics, though). Just make sure not to do it right before a big release. Instead, do it right after and congratulate them on their work. They’ll appreciate it, you’ll ingratiate yourself to them, and you might even learn a thing or two about your tech systems along the way.

 

The Issue of Deadlines

This one is always touchy. Missed deadlines are rough, but they happen with unnerving frequency in software development. Devs want to release top-notch products, but there are plenty of issues that could pop up. They also don’t want to be responsible if the whole thing crashes down, nor do they want to fix five security holes on the production server if they can fix them before the product is released.

One common source of an unexpected problem is third party code. Lots of systems rely on third party code, and sometimes that code doesn’t play well with other third-party code. That conflict might not be discovered until late in a project, and then the deadline must be pushed forward by a month while either proprietary code is written to accommodate the issue or new third-party code is found and integrated. Another common source of deadline overshoot is a major bug in the foundations of the system causing issues for new code, meaning more than one project must be revised before release.

Since systems can quickly become so complex no single person knows how the whole thing works, deadlines are often missed. Such is the life of software development. You can set deadlines, but make sure your tech people know that a solid product is more important than an arbitrary deadline. Actually, if you don’t connect the deadline to an important event, devs might just ignore it all together.

So, issue deadlines, but ground them in real world consequences, like your competitor will be first to market and your entire business will go under. That will help the development team prioritise. Be flexible, because deadlines will be missed. And make sure to manage your expectations, otherwise your deadlines won’t be aligned with the capabilities of the devs, and they’ll be missed.

Finally, if a dev says don’t release the software, don’t release it. There is nothing worse for customer relations than a software update that breaks or creates a security hole. Missing a deadline by a few days is infinitely better than losing a few days of revenue because of buggy code and the reputational hit that will cause.

 

Concluding Remarks

Just like any good (non)scientific article, we want to end with a short summary and conclusion.

Throughout the article, we spoke of developers as a species, almost foreign to people managers. But developers are just humans, too, and they should be handled as such. If you have some time, as an entrepreneur who is looking for a development team, I strongly suggest you learn at least a little bit of coding, how your systems work, and what your team is doing. It will go a long way in communicating smoothly and might even score you a couple older, protective siblings.

Knowing the limitations of your systems and your team will ensure everyone is on the same page and no blow ups or burn outs happen. It propels the team forward like a well-orchestrated rowing team instead of a floundering one that makes everyone unhappy. And developers are in just as high demand as ever, so continually pushing the wrong buttons will make this species look to greener pastures. Company loyalty is only dead for disloyal companies, so don’t fall victim to losing a great dev and potentially your entire technical infrastructure.

 

We had only one brave soul willing to put his face out there as one of the topical species, so here is that brave soul (he’s our DBA and infrastructure guy):

And since no one else volunteered (devs can be a little shy and introverted sometimes), here’s a photo of part of our team. To be honest, they’re hard to get in one place at one time; the remote working culture of devs really infects a whole startup, even those who aren’t developers.

And everyone in the office, not just the software developers, kind of seems to be doing this all the time (staring at computers)