Course info
Jun 17, 2015
2h 36m

If you're having a tough time connecting with the developers on your team, this course can help. This course is targeted at experienced software development managers, developers interested in management opportunities, and non-technical managers leading development teams. The unique perspective of developers, along with the way they think and solve problems, is explored in an easy-to-view narrative.

About the author
About the author

Kevin is a lifelong learner with over 30 years in the IT industry. He works on web and mobile applications as well as the databases and web services to support them. With a gift for learning new languages, he is able to rapidly apply his broad experience in new environments.

More from the author
Making Work from Home Work for You
2h 27m
Oct 12, 2015
More courses by Kevin Murray
Section Introduction Transcripts
Section Introduction Transcripts

Developers Think Differently
Not all developers think the same, of course. There are some very common responses that developers have to certain situations, however. As I said earlier, it's not possible to paint any group of people with a broad brush. No two people, no matter how alike they seem, are the same. You can't expect your team to all respond the same way, just because they are all developers. That's the first takeaway that you can gain from this course. Do not assume that your team will respond with a unified voice to new situations. Your team is made of people with their own goals, agendas, motivations, and limitations. Each may appear to be in agreement, but that may just be for your benefit. I'll give you some ideas of how to elicit more meaningful responses. I'll also show some examples of common reactions developers have that are contrary to their outward appearances. Developers often identify themselves with their primary tool. You'll hear things like, I'm a Java developer, or, I'm a. NET developer. You may not be aware of just how limiting this habit is for your team, and for you. It can sometimes be a real challenge to understand what a developer is trying to say. Even if you understand the words, it's possible that you aren't really grasping the meaning. Computers don't have agendas, people do. Developers will try to figure out where you're coming from if your communication is unclear or contrary to your normal behavior.

The perspective developers have, often differs from the perspective of others in the company. It's time to bridge the gap between your perspective of the developer and the perspective they have of them self. While we're at it, we need to work on the perspective the company has of them too. This module is all about perspective, both from the developer, as well as of the developer. The difference in perception can cause a serious disconnect in how the developer's valued and how the the developer reacts to projects. Let's be blunt, developers can come across as arrogant and condescending, right? There are arrogant developers, I won't deny that, but often what is perceived as arrogance is something else entirely. Just because the development team isn't a profit center doesn't mean they aren't contributing to the bottom line. Instead of being labeled as a pure cost center, there is room for a middle ground that I like to call a productivity center. Part of your job is to educate upper management about the value your team provides to the company. You should be ready to inform executives of the successes your team has at any time. Seasoned developers bring a big picture perspective to programming tasks. To them it's more than just writing a new function, it's also about integrating that function into the existing process. Often, the developer will have more knowledge of an existing business process than anyone else in the company, even the end user. This knowledge gives them a unique perspective on upgrades and new projects. We'll wrap up with a case study about outsourcing. It's a common occurrence that many development mangers have to face.

Personal Connection
Establishing a personal connection with your team is one of the most important aspects of your job. With a team of developers, it can also be one of the hardest. Everyone knows developers are socially awkward, right? Let's not buy-in to the stereotypes. As we looked at earlier, they just think differently and have a different perspective on things. It's not as hard as you may think to make a connection with your team. It's just going to take an effort. More than likely, the developers on your team will not make the first gesture to build a personal connection. It will be up to you to find a way to make the connection, so if it's up to you, what can you do? I'll cover a few ideas in this module. The first is, manage by walking around. This isn't the latest exercise craze; it's a real strategy for connecting with your team. We'll talk about the benefits of the one-on-one meeting. It's more powerful than you probably think. Team-building activities can foster personal connections among the team, as well as with you. Finally, learn what they do. That sounds absurd, doesn't it? Of course you know what the team does, or do you? Our case study will demonstrate the power of the one-on-one meeting for creating a personal connection.

Rewards and Recognition
Many of you skipped right to this module first, right? Come on, I know what you're thinking. What's this guy going to say about paying developers? If this is your first module, thanks for watching. I encourage you to watch the rest of the course as well. I'll remove some of the drama right away. Rewards and recognition is not about money. While money is nice to have, it's not the primary motivator for most developers. Don't get me wrong. I've never met someone that said I'll work for less money. That's not how developers think. I've also never met anyone that said they would work harder because of a bonus or a raise. That's also not how developers think. A developer's salary is not part of a reward or recognition package. I'll explain what I mean by this in a moment. Rewards and recognition are all about showing value. Sometimes it takes a little creative thinking to do this. Before you can recognize your team, you must be aware of what they do. This builds upon the last aspect of the previous module entitled Learn What They Do. Developers like to be recognized. Often the attempt to recognize them ends up causing more harm than good. The salary part is what everyone tuned in for. I'll finally explain what a developer's salary means to them beyond paying the bills, of course. A bonus, or at least a true bonus, is a great tool to reward an employee. There are times when a bonus is actually harmful to productivity, however. For the case study, I'll show some unique ways to reward and recognize each of your team members without needing a dedicated budget to do so.