Hard problems that need to be fixed

Companies need to get their problems fixed. When you are a software development agency you need skilled developers that can turn your requirements into code. And when do you need them most? When you are in trouble, when your business is upside-down, when your biggest client complains that what you deliver is full of bugs. That’s when you start believing that your developers are incapable idiots, that’s when you start to convince yourself that an “expert” would make it better.

And the good news is: You’re wrong.

Why should an expert want to work for you?

Experts are people that know their field of work really well. Why do they do that? Because they are self-motivated to explore areas they don’t know well enough in depth. Because they are interested in continuously making things better, find out how they can improve previous or existing solutions. Why can they afford to do that? They don’t ask for permission. They don’t need to ask for permission. They just do it, because they’re driven by instinct. They are perfectionists (with or without deadlines).

Now, you have an environment full of problems. An expert could fix that, acknowledged. An expert can go into a mudhole and turn it into a shiny chrome sink—as long as you don’t interfere. This is the critical part of the story. If you have customers that threaten you with cancelling a contract, will you be willing to lean back relaxed and wait for your expert to fix “the problem”? Remember, she knows it better than you. You’d better be quiet and not disturb her while she’s busy fixing your mess. — Do you think you can do that?

Suppose the unlikely happens and you manage to control yourself despite all the threats you’re used to address in your utterly managerial fashion. When new projects come along and are prepared the same way the former “problematic project” was, do you expect your expert to jump into the mudhole again? She won’t. At least not without complaining. Because experts hate to solve the same problem twice. And you don’t want to be told what needs to be done in that other team or department, “which would fix this once and forever”. That’s none of the expert’s business, right? — Inevitably, dismissing such expert recommendations (repeatably) will create an uncomfortable situation. For you and your expert.

Get your problems fixed first

Experts won’t stay in an environment that can’t appreciate their efforts to make things better. The whole purpose of our existence is being recognized as a valuable member of our community, the people surrounding us. If you can’t offer this you better create an environment first that is worth staying in. It could go like this:

• Fix your project management problems (e.g. practice a top-down test-driven approach involving everyone, starting with your client).
• Align your sales efforts with your project management and development processes (e.g. sell agile fix-price projects consistently).
• Build a self-learning environment. (When you make a mistake the “environment” should give you feedback, forgivingly. As often as you need.)
• Make your developers become experts, by themselves. Teach them the principles, educate them. The feedback from your CI server should do the rest.

Allow your developers to become experts themselves. Even more than that, make your developers become experts, together. Create an environment of learning, of knowledge sharing. Make it fun to create high-quality software!

• Create a continuous delivery pipeline that gives continuous feedback. (Developers contributing code changes that lower code health should get a notification with suggestions about what to make better; code changes that increase code health should be answered with serious cheering.)
• Encourage tech talks, short in-house knowledge sharing sessions. They allow your developers to showcase their expertise, and before that they seriously invest in deepening their knowledge, you wont’t have to tell them. (If all goes well you can send them to developer conferences one day to give a talk; that’s a much better investment than just sending them to participate passively.)

If you practice Agile (Scrum, Kanban) and you don’t do that already then you’re probably not doing Agile right, anyway.

Hire smart and social people — willing to learn and share

You don’t need to hire expert developers, because that doesn’t make sense. What you need are developers that are smart and social. Developers that are willing to learn and willing to share. Smart enough to acquire new knowledge, and social enough to share it among themselves, among everyone in your organization.

When you hire people your whole organization should profit, not just your wretched customer projects. Your organization should be able to grow, “grow” in the sense of “raising a child”. And for raising a child you need a healthy environment that children can grow in, to get better at stuff, better than you, one day. It’s your job, though, to provide this environment. Not the one of your employee.

---

photo:	Banner Of course I talk to myself by ComicalShirt at Bonanza, used by permission of the author
photo:	Photo “The Computer Expert” by Arteaux Art & Design, used by permission of the author
cartoon:	Cartoon Pipeline feedback by Geek&Poke, used by permission of the author (CC-BY)