Anna Filina

My partner and I often help projects where developers get caught in technical challenges for which they don’t have enough skills. They sometimes get caught for months in fancy architectures that they are unable to make work. We get these projects back on track, that is, we get them out of the forest to the road and point them in the direction of the city. We seldom accompany developers all the way, because that’s inefficient and is just a waste of our client’s money. The surgeon only does the surgery. Taking care of the patient in the following weeks is the nurse’s job.

We have seen a number of cases where the team would go back into the forest and get lost again. Most of these simply need a little more guidance to avoid slipping. There are, however, some cases where developers constantly require assistance even after the project is back on schedule and adequate tools were provided to finish the job. In our business, project rescue is a short burst to get it back on track and is not meant to be sustained. There are less expensive support services for those who need extra help to keep things under control.

What about you? As managers, you must be able to recognize when a developer is unable to work unless held by the hand like a child. Whether it’s due to lack of skill or confidence, you must remedy to the situation immediately to protect the investment in the project. You could reassign them to easier tasks, invest in coaching or mentorship services, or let them go.

As colleagues or contractors, signal the situation to your superiors. Spending all your time helping other developers will get you behind on your own objectives and you will be the one in trouble. Don’t expect those whom you helped to stand behind you when heads begin to roll. Contractors should also be aware that there is no benefit in doing extra work “in good faith” for which you are not paid. That is a polite term for “we busted our budget but can persuade this one to do the rest for free”.

Remember, some people will always need help. Don’t sink with them. You have your own life to enjoy.

The idea of self-directed teams is not new. It has been used for decades. Why would anyone want this? Does this work for everyone? How is it implemented? Is the traditional hierarchical model bad?

Hierarchical model

The desire to have self-directed teams come from various frustrations that the traditional model generates. Employees do not like to be micro-managed. If they see a more efficient or pleasant way to accomplish the exact same result, they do not want a supervisor to tell them that it’s wrong and that they should do exactly as they’re told. The traditional model breaks a process down into individual steps and assigns isolated tasks to team members, preventing any sense of accomplishment. This creates silos, repetitiveness and boredom. As a consequence, motivation goes down along with efficiency and loyalty. This in turn infuriates the management that seeks to increase control even further. But that cycle can be broken.

Self-directed model

This model has both advantages and disadvantages. Because the team no longer has somebody managing them each day, members have freedom of methodology as long as they can deliver the promised results. They can now organize their own time. This means more empowerment and motivation. Management not only benefits from increased efficiency, but also the team can now solve its own problems without exterior involvement.

On the other hand, these teams are hard to establish. Team members require a strong commitment to the company or this will not work. You will also have to invest in initial and ongoing training. Team members will have to learn management, decision making and problem solving skills. They must also understand the job of other members. Not everybody has the capacity or experience to make tough decisions. Not everybody can have a business perspective. Not everybody is willing to be held accountable for results or mistakes. Conflict resolution can be difficult in such teams and it is important to have exterior support in such situations.

The best of both

Interdependence and accountability are characteristics that are shared with light teams, also called agile. But these teams are not necessarily self-directed. In reality, the problems in all teams arise from applying any model without applying common sense. You want your people to be motivated and efficient? That’s easy.

They have to be result-driven. As a project manager, stop worrying about methodology, control or silly timesheets. Focus on results. You can’t ask your people to be pragmatic if you are not, and if you’re watching and judging their every step. Make sure that everyone understands the job of other team members and report to each other rather than reporting only to you. Don’t split tasks with strict boundaries because you want interdependence and accountability to flourish. Above all, apply your common sense rather than following a work methodology religiously. See what works best for your team and build on these strengths.

This presentation was recorded at the Montreal.rb user group. I gave a number of tips to investigate the performance of database queries and to speed them up.

When developers are not motivated, progress is slow and quality is low. This ultimately affects company revenues and can lead to reduced opportunities for all employees. Motivation leads in the opposite direction: wealth and happiness. The first thing to understand about motivation is that it’s internal. We can’t force someone to become motivated, but we can still have a strong influence. Here are my top three picks to increase motivation from my presentation at IPC 2013 in Berlin.

Goals

Motivation is our reason to act towards a goal. There are two common ways to express that reason. We can say that we will go to work because it’s 8am or in order to finish building a game that improves the logic of pre-school kids. The first one is reactive. Someone or something else is in control of our life, and it’s unpleasant. The second justification has purpose. When we identify ourselves with that purpose, you can feel pride and pleasure from your work. Great quality and productivity naturally ensue.

Small wins

A goal may seem far away and if we can’t achieve it quickly, we lose interest. The idea is to cut our work into smaller pieces. To become a Karate grandmaster takes much time, but getting a new belt shows progress and gives a sense of achievement. Software is similar. We can stabilize our code for demos more often. It’s not as fast as a straight path, but remember that we’ll stay in the game longer if we can see tangible progress rather than abstract percentages.

Use of talent

No developer enjoys doing repetitive tasks and staying in one place. Developers want to use their full range of talents as much as possible and gain new talents. Don’t give tasks too difficult for one’s skills, but just difficult enough to provide a challenge. Another way that we can help them improve is by sending them to conferences and workshops. Not only will the come back more motivated, but will also have increased productivity from all the new techniques that they learned!

There is no such thing as a perfect employee match in programming. If you write a list of technologies in the job description and expect to find a candidate with the all right experiences, you will be strongly disappointed. You could spend months or years searching, while overlooking very good candidates just because they lack one or two skills.

New technologies are coming out each hour and it’s impossible to keep up with absolutely everything. Developers make choices based on what they think will become a trend in the near future or based on what seems most useful. They are also exposed to some technologies regardless of whether it’s a good or a bad choice, because they are often not the ones making these decisions in a project. Since each person’s journey is different, the permutations of skills are incalculable.

IT projects require a multitude of technologies. A project can require experience in a specific framework, ORM, CMS, caching tool, automated testing tool, database, continuous integration, deployment, messaging protocol, etc. Also, multiple programming languages are sometimes required. Now multiply languages by the number of language-specific tools. A developer is often expected to have over 20 skills. The possibility of a perfect match is virtually inexistant.

I’ll give you some examples from my own journey. I was once hired to work with the Flex framework. I worked with ActionScript once, language on which the framework was built. I had no direct experience with Flex, the main skill required. I was hired regardless, because there were simply no developers experienced with Flex in the entire province at the time. I read the documentation in two days, I built the software and my employer was happy with his investment.

A scenario like this happened to me over and over again. I did not need direct experience with any technology, because all programming languages are pretty much the same except for syntax and minor philosophical differences. All frameworks and tools follow pretty much the same principles. At the end of the day, you just need logic and willingness to work with new tools.

So what is the solution? Don’t try to hire developers based on a keyword match. That’s just silly. Humans are much more flexible and adaptable than this. Hire them based on their logic, which you can evaluate by discussing anything technical or even non-technical. Hire them based on feedback from past clients or employers. Hire them based on enthusiasm and attitude in general. Hire them because they can think.