I guess every company wants to have productive and efficient employees that comes up with bright ideas and can execute, track and deliver them. This employee should smile all the time, doesn’t need a lot of attention and works always for the company goals. This is a nice wish, but in reality we need to do more to make sure that every individual developer gets freedom, runs in the right direction and is happy in what he’s doing. These are just 6 random things that will boost the performance of knowledge workers like programmers:
1. Set monthly goals & check frequently
I never understood the thing about annual goals. 2 month after I agreed with my boss on them some were already obsolete and didn’t make sense anymore. Things change too fast nowadays and annual specific goals makes us inflexible. Sure, we should have bigger goals and track the way that leads to them by agreeing on short term goals. I can concentrate better on a goal when it’s smaller and the due date is closer. It’s like running a year long sprint in Scrum. Doesn’t make sense! But: Track also your long running goals (like Epics in Scrum).
Short running goals lead actually to frequent checks with your boss or even better: with your team. You should meet weekly or bi-weekly, discuss the current state of your goals and update them. It worked for some teams to define team goals and personal goals (1:1 with your boss). Try to avoid mixing those.
2. Establish short positive feedback loops
If someone did a great job, you should have an easy mechanism to appreciate that publicly. That way people think feedback isn’t something awkward. We at Atlassian can give Kudos to other team mates just by raising a ticket in JIRA. The talent department sends a small gift with a card to the receiver of the Kudos. Everybody at Atlassian can start this, so it’s very lean and effective.
3. Freedom for developer
All knowledge worker know that innovation doesn’t happen between 9am to 5pm. Give people freedom to work wherever and whenever they feel motivated and productive. Give them the tools they need. Give them time to work on their innovations. At Atlassian we have tools like 20% time and innovation weeks. A special time where our developers are not working for planned features but on own innovations that improves our products or tools that makes us more productive. It motivates the developer to work on their own ideas and show them later to their team mates and maybe integrate them in the core products. There are lot’s of examples at Atlassian where projects from 20% time made it in the product… but also some that didn’t.
4. Don’t overlook the small things
Talking about the performance of developers: It’s not always the smartest to work on a big new feature. There are so many overlooked ‘low hanging’ fruits in most products that will improve the software with less effort. My collogue Benjamin Humphrey has written an excellent blog post about this. But I want to touch on the human side for this one: If the developer fixes two of those small improvements each Sprint the satisfaction level will raise. He will get fast (and hopefully positive) feedback for the small change.
5. Transparency
Let people know what the big company goal really is. Let them know how good or bad sales are performing. Don’t treat devs like small children and hide things from them. It’s so demotivating and costs so much energy to hear and discuss rumours on the hallway or just don’t understand the overall goal. Give people an opportunity to ask questions (not just in big CEO announcement in front of 500 people). At Atlassian our founders are giving us regular updates about goals and performance in a blog post. We can comment on that and ask if we don’t understand a new goal. It’s important that everybody in your organization is on the same page with the companies vision.
6. Forget about specialists
I’ve been working for a company that was hiring specialists. I never understood why. Yes, of course we can all do special things in the team: Someone speaks fluently SQL, the other one is good in presenting and another guy is good in design. That shouldn’t stop us to try out other things. The specialist thing is getting weird when people don’t feel responsible for other peoples specialism. I’ve argued with some people in my career that didn’t feel responsible to do support or getting the requirements from the customer, just because it was someones else’s responsibility. Here is what’s really important:
“Go build awesome shit”
Mike Cannon Brookes (Atlassian Founder)
No more and no less!
Sven Peters 