A Hacker Chick Guest post by Trudy Prins, a wonderfully passionate software development manager at RIPE NCC in The Netherlands. I asked if she might share what she believes makes a successful software team. I hope you enjoy her answer and this glimpse into how she leads her teams as much as I do...
As a Software Engineering Manager, I believe a successful engineering team is a happy team. Happiness boosts productivity, creates an environment for excellence, and offers fertile ground for growth on both a company and a personal level.
So, what makes a happy team?
Frequent knowledge transfers. Team members should have the opportunity to schedule presentations in front of their peers, engage in discussions, follow trends, try out new solutions, have spikes on all kind of topics, go to conferences together and whatever they find suited to share their knowledge & enthusiasm.
Immediate feedback on their performance. I tell them constantly, clearly, and on the fly what I think they did good, great, or not good at all, without making a big fuss about it or waiting a year until their performance review is up. Their annual review shouldn't hold any big surprises.
Team-spark, cooperation, concentration and energy. A general feeling of friendship and focus is in the air -- this is an intuition and experience thingy, I just know this. I feel it when it's there and I notice when there's trouble and friction. Of course, I share the same room with them! Otherwise, you miss out on these very important signals and you can't identify your team-specific energy signature. Or trouble-thermometer.
Be proud of accomplishments. Do frequent deployments and sprint demos. The team can show off their accomplishments -- their work, which they are proud of. Stakeholders can provide them feedback and pay them compliments when deserved and challenge them when needed. Make process improvements like delivered business value, rising velocity, better code coverage and decreasing bug counts visible to all.
Good company! This is something you need to be very aware of when hiring people -- make sure they add to the team cohesion. No lone wolves! If someone is technically brilliant but their social skills are lacking, I never hire the guy/girl. Has to be both, 50-50. Great coder and communicator, otherwise it's not going to work.
Apply the big 3: test driven development, requirement driven test cases, and agile methodology.
Keep it simple, keep it clear. It always works. No super complex architecture, ideas from Mars, tools from outer space or far-fetched solutions. Simple and clear is always the best choice.
Pair programming. A great way for the team to interact, learn from one another, review each other's code in real-time, help each other to overcome obstacles, share brain waves, cooperate!
A short anecdote -- when I interviewed one of my current engineers, we asked him if he cloned himself 10 times to create a team of 10 of him, what would go well and what would go wrong? For the latter, he thought for a bit, and when 
he spoke he said, "Well, in the end, I guess, everything could go wrong. You are always thinking in a certain direction, and when you don't get a second or third perspective, it's inevitable that you're eventually going to reach a dead end. It may take a long time to happen, but in the end you will fail". Isn't that brilliant? Of course I hired the guy :)
Empowerment. Engineers should be empowered to implement any solutions they think fit the requirements, within the high level framework decided up-front. It's useless to interfere or try to micromanage this. Don't interrupt their flow when they are doing fine.
Experiment with roles. I give them specialties to show their greatness in, but also leave them room to experiment with new roles they find appealing (ScrumMaster, product owner, UI designer). Keep on learning!
Don't demand elaborate reports and documentation solely for the fact that you then possess this information. Knowledge is power? No way -- it means nothing out of context. Reporting & documentation should always satisfy a direct business need -- I don't believe in knowing for the sole purpose of knowing.
Treat them right. Make sure they know you care for their well-being. Buy them cake, call them when they are miserable, make sure they get better chairs and monitors when they need them. Be sensitive to their needs and show empathy. They are great people and deserve your care and respect, right?
Stimulate them to explore their limits. Go further. Dig deeper. Boldly go where no-one has gone before. :) Show us something spectacular!
Let them take the glory of their successes. I won't snitch it away from them. My team presents their own ideas and implementations to senior management and clients and takes full credit for them!
Provide them with everything they need to succeed. Buy them shiny new MacBook Pros that they love to work with (it will pay itself back, no worries ;) ), provide them with a nice, light, spacious and quite room with lots of white boards where they can all sit together and be happy, let them buy stuff when they need it: books, licenses, whatever they think is needed to match our expectations.
-- Trudy Prins, fellow hacker chick
See how we're connected
14 comments:
Great post, having moved from a traditional Waterfall devlopment team to now managing an Agile team i would say the key benefits of the approach are these:
With the use of Paired programming the solutions developed are the result of the analysis and discussion of two minds rather than one mind working in isolation.
The use of TDD means that any changes to live systems are always tested prior to deployment and and issues that do arise can be re-run through the unit tests to a reporduce the issue and also confirm resolution.
Continuous integration prevents the dreaded 'integration' bottleneck, where a large number of minor changes are released at once causing unforseen interaction problems.
To make the most of these elemnets you need a team who get on with each other, understand the goals and above all feel they efforts are appreciated and valued. A team that is demotivated by a lack of scope for creativity, a lack of support from their manager and a lack of recognition is not going to work for you.
Great summary. Two that seem key to me are feedback - the quicker the better - and respect. There's nothing more demoralizing than being treated without respect, or not feeling safe to raise issues, ask questions or make suggestions.
Thanks, Lisa Crispin! :) (It seems to be comment confusion day, sorry your name didn't come through!).
I so agree! And what I think is so cool is that even though Trudy only says the word "respect" once - and it's way down into the article - it still comes through loud and clear that she does respect her team, doesn't it?
Thank you, Nicholas!
I'm so encouraged by hearing people recognize that it really does require more than just the technology (a team who get on with each other...). And very cool to hear the benefits you're getting out of the practices - thank you for sharing!
Great post. Just having people work in a team environment seems to improve their happiness considerably. I strongly agree with the immediate feedback. This is a critical learning step for everyone. If you've ever worked with a trainer or taken private lessons you will have experienced this first hand.
@BillyGarnet
Thanks, Billy! I just checked and it looks like under "Add another site" you can select "My site" and enter your own URL... which I just msged you... but using this as a test to see if it gets my blog's url in my link
Thanks for the feedback.
I added the site as suggested. Change my name in Google to Billy Garnet but Bryan Beecham still showing.
Ahh technology...I think I have a love/hate relationship with it.
<span><span style="color: #808000;">Interesting post Trudy. Thanks.</span></span>
<span><span style="color: #808000;"></span>
<span style="color: #808000;">As someone who's chafed at being managed, </span><span style="color: #808000;">Provide them with everything they need to succeed is at the top of my queue. If a manager clears roadblocks and advocates for productivity by fighting the battles for better tools, then I feel they're worth the overhead. A sense of humor helps too.</span></span>
<span><span style="color: #808000;"></span>
<span style="color: #808000;">One of the most important contributions of Agile is its humanity - everyone is invited to the table and everyone is accountable to deliver. So, in some ways, to maintain relevance, managers must adapt to a limited role that boils down to clearing roadblocks and advocating for the team.</span></span>
<span>Thanks for you comments, Guest :)
I sense that you haven't been very lucky with your manager(s) so far...
I think that a manager can be more then 'just' a facilitator, clearing roadblocks & bringing cookies, although this is a very important part, as is the sense of humor ;)
Like the Scrummaster, but at a different level and with a somewhat different perspective, a manager is a leader <span style="text-decoration: underline;">and</span> facilitator.
I think the leadership should show in:-
1) Unifying the team -- actively work on their compatibility to make a single strong team, every day, the task is not finished by simply hiring the right people. Solve conflicts of all different kinds.
2) Define a vision and a strategy to get there -- give clear direction and develop a plan for development & deliverance that serves 3 purposes: company, departmental & personal growth. Actively fight for buy-in from stakeholders.
3) Exercise the Product Owner role -- my department exists of 2/3 scrum teams, that handle 4/5 projects simultaneously (plus bugs/maintenance.) I started as the only PO, but by now I have installed 3 POs in my team, every sprint I define the goals and divide story points over the projects. POs come up with the stories, refine and prioritize. I also act as backup of any of the POs when unavailable -- I am the Chief PO so to speak.
And yes, Agile gives room to humanity, agreed. But it doesn't create it, it facilitates it. I would like to think that good managers are always driven by this, in everything they do. After all, they manage people in the first place. </span>
This is all great advice and, as an engineering manager, I try to follow it all (and mostly succeed, I believe). I've also found that even though you may not be able to provide the best chairs or fanciest monitors (due to budget constraints), as long as you do your best to support everyone in other ways and show that you really care, that ends up counting for quite a lot.
;ted
Hey, Ted - thanks for stopping by and commenting!
And yes! As someone who is managed, I agree whole heartedly. I also believe it really comes through when the manager cares about the team, even if they don't have a great budget.
You make good points and your techniques are valuable, but i think you have it the wrong way round, productive people are happy people, and they are happy because they are productive. the best thing you can do as an engineering manager is to run interference, ie make sure nothing stops people from doing their job well and quickly. praise them and make sure their achievements are notced as widely as possible.
Most of the techniques you metion are all geared to this anyway, but not all work all the time with all people. There are culture specifc issues - eg I know engineers who detest pair programming; So be sensitive to thier particualar norms, and especially cultural norms outside you nationsl group if working globally (as i do).
The productivity / happiness cycle becomes a self-reinforcing one. People are proud of themselve and their achivements, they feel useful and respected, they are happier, they produce more they are happier etc.
<span style="">The productivity / happiness cycle becomes a self-reinforcing one. People are proud of themselve and their achivements, they feel useful and respected, they are happier, they produce more they are happier etc.</span>
I love it! Not horribly crabby of you... but, I likes this productivity-happiness cycle (very Flow/<span style="">Mihaly Csikszentmihalyi-like)<span style=""> , thanks for commenting!</span></span>
Hi crabby dog :)
Well, yes, there's definitely a relation between productiveness and happiness -- chicken and egg thingy I guess...
However, don't think productive teams are _always_ happy team, have a look at this article from Dave Nicolette, when success = failure:
http://tinyurl.com/yhphfej
What do YOU think?