Many people think that as long as you are happy at work, all the rest will follow. The rest being interesting and engaging work, professional growth, tons of money, groupies, etc. They are wrong.
Those are the top 3 items from my manager cheat sheet:
- Ship a product.
- Build a group that can deliver.
- Grow up my team members.
What is missing? The H-word. Yep, no happiness is involved. Working and delivering, being warm and cozy did not make the list.
If you are on my team, my job is to make you a better developer (here and below freely replace "developer" with QA, support, fill in your position). How do I do that? There are few simple ways.
First way is to assign challenging tasks. The goal is to stretch your abilities by being on a boundary of your abilities under assumption that this will extend your boundaries. Usually it involves doing stuff you've never done before. I especially like giving tasks that involve a completely unknown technology to the person. This is the usual exchange:
- (victim) I have to learn it first! It will take a few weeks!
- (me) We don't have weeks for learning. Take a week, learn enough to make some rough, first version. Then come back and lets talk on how to continue.
The developer then walks away calling me names (not in my face, usually). However, after a week, the first version is ready and it is better than everyone has expected. As a bonus, I don't hear complains about the new technology anymore. It is not new anymore.
My other favorite way is vague requirements. Especially when they are coming from end-customer, but anything outside a comfort zone is great. Here, victims usually complain about other folks that were supposed to supply better requirements. They could be, product managers not doing their job, marketing and sales folks selling non-existing or impossible features, customers that do not know what they want. Once I've asked: "Do you want them to define everything?" However, after getting "yes" a couple of times, I have changed the pitch to "This is a great opportunity to understand a product from end-2-end perspective."
This method also begins with a developer being angry at me, other people and at the world in general. However, in the end it all works (with a little help). The results of this approach are less obvious and take longer than in the previous method. It take longer because there is no tutorial on how to deal with vague requirements. It takes time for the developers to understand a bigger picture, understand the customer, see the bigger picture and generally, have all the puzzle pieces to fall in place. However, once they do, the developers make better decisions that support business cases, they take more responsibilities, they move away from being code monkey.
Longer and less obvious, sometimes after my second glass of wine, I look back and say: "yeah, it all started there!"
Yet another method is to take risks. Most of developers are afraid of taking risks because they might loose. However, taking risk is also a win to big wins!
As opposite to assigning tasks, this method is usually more subtle as you cannot just say: "Take more risks." I usually lead by example in 3 simple steps.
- I say aloud that I am going to take a risk in a specific issue. I outline a strategy for risk taking, i.e. what are the risks, when and what are the checkpoints, if and when do we bail to a safe road. It is important to announce the risk taking ahead of the decision for two reasons. First, so everybody knows that risk taking was deliberate and not ad hoc. Second, it teaches planning in risk taking process.
- Execute on a risky path. This includes checking the progress, passing or failing the checkpoints, deciding on the future course of actions, etc.
- Retrospect and summarize. Face the decision and the outcome. See if you were right or wrong. Learn from it and continue. This is a very important step in saying "Its ok to take risks." Retrospect is critical especially when the risk didn't pay off.
Somewhat related to the risk taking is being wrong method. Young folks want to earn appreciation and think that not being wrong will get them there. Senior developers are afraid to be wrong because they think they are supposed to know everything. Well, both of them are already wrong:)
It is ok to be wrong. It is ok not to know things. If I do not know something, I can learn it. However, if I afraid to admit it, I will never learn it. I used to look for "I don't know" in a hiring process. A person that can admit her boundaries, usually is humble enough on one hand and confident enough to admit it on the other hand. Those people are joy to work with.
So, how to teach this attitude? I do it in two ways. First, I use myself as an example. Luckily, there are plenty of things I'm wrong about or things that I don't know, so I talk about them. I expose my flaws in public without excuses to show that it is fine. Second, I drill with questions until getting to "I don't know" or to "My mistake." Then I immediately say that this is ok and act to give the developer a feeling that this is indeed ok. Thins (supposedly) trains the developer in being wrong and making himself right.
Extended ownership method. Give a developer more responsibility than she usually gets (or wants). Then add some more. Let her take the calls in decision points (with my backup of course), let her present the project, talk with other groups, oversee testing and documentation, etc. This method is the best, because it also means less work for me in the long run :) The catch here is to set the developer for success by providing a safety net that is safe enough for the developer not to fall and on the other hand, it should not be too tight to allow the feeling of ownership. This is a hard thing to do and sometimes I screw up in that. The good things is that I admit my mistakes and try to fix them the next time.
Once a developer owns the project, it is all worth it. You can actually see her becoming a better developer.
Those are the 5 major methods I use to grow my team members whether they want them or not. The common theme for all of them is that none of them is easy for the developer. None of them makes the developers happy in the process. It is ok. I am not here to make you happy. I am here to make you better. I do aim to make you Eventually Happy. Which means that I do hope that some time in the future, you will look back and say that this was the period that you've learnt a lot and was worthwhile all the challenges.
