Doing It Right: A Manager’s Perspective

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…

Trudy PrinsAs 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 Science Papa Team (Image by Kotaku, from Activision)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


2 responses to “Doing It Right: A Manager’s Perspective”

  1. Abby Fichtner Avatar
    Abby Fichtner

    <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>

  2. 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:

Leave a Reply

Your email address will not be published. Required fields are marked *