Technical Evangelist – A Developer in Marketing

After more than 2.5 years working as an evangelist for Atlassian it’s time to look back on why the job rocks but also about the shadow sides. I guess every company have slightly different expectations when they hire for the evangelist role. At Atlassian we want raise awareness for our products and the company in general. We are creating products to help everybody that is involved in the software development process to work happily together. An ambassador at Atlassian has a strong development background and is not shy to talk to developers or jump on stage and talk about development in general. So it’s natural that a developer should fill that role.

ambassador

My job is awesome

Speaking to developer
peopleWhen I started I was a normal Java developer nobody knew. I started with going to conferences, was accepted to do some talks, met some other speaker, got invited to do some presentations and then got asked to do some keynotes! I really enjoy staying on stage and the more you do it, the less nervous you get. I say less, because I’m still nervous even speaking in front of a 10-20 people. I love putting ideas in peoples heads where they can grow. If I just can help 2-3 people start thinking more about improving their software development I’m a happy evangelist.

The community is great and people that I was looking up to when being a normal developer are now my friends. This job has open the gates for me to exchange ideas with thought leaders of this industry and believe me: They are also just humans 😉

Travelling
planeBeing an evangelist involves a lot of travelling in my case it’s about 30%. You hang around on airports, train stations and hotel rooms. Sometimes my travel schedule is so tight that I don’t see anything from the great places you’re speaking. Sometimes I just have to force myself to take a later plane and walk around the city I’m visiting. I’ve seen great places in the last year like Moscow, Kiev (before the situation escalated), Sydney, San Francisco, Atlanta and many more. A great thing is also that I meet Atlassian’s everywhere. We have people from local offices or that work remote in that region staffing a booth, so they can talk to the local customers and learn how our products got used in the field. It’s great to catch up with so many different colleagues.

Self starting
rocketI got the privilege to decide for myself what I want to speak about, what article I would like to write or new ideas for t-shirts that we should create for trade shows. It’s a very creative job where you have to come up with new ideas and new concepts all the time. What will developer like to hear, what is currently hot in software development, what is Atlassian doing? It’s so great if a create stuff in my home office in my little town in Germany and than the marketing in San Francisco want to reuse it for their global campaigns. This is also what this job is about: I’m the guy on the ground, I talk to many customers, I talk to thought leaders, I talk to developers. From all this information I can maybe create a more appealing angle of the story we want to tell our customers.

And if I think it’s time for me to get my hands dirty I’ll start coding for a while, not creating a product but just to do some small things improving my day to day work.

My job sucks sometimes

When working for a while at home I’m starting to miss colleagues. People that I can talk to each day. HipChat video can help but it’s not the same than meeting them in person. We’re trying to do team meetings at least 3-4 times a year in Amsterdam and San Francisco. The switch to not creating a sustainable software that people use each day was kind of hard for me. I now got used that marketing is a much faster business and collateral you created last month is old stuff and not used anymore. Also traveling makes me feel lonely sometimes. Sitting on an airport or in a hotel room, just myself, my iPhone and my MacBook.

Most of the people I’m collaborating with are sitting in San Francisco. We’re trying to coordinate our meetings that they happen early morning in San Francisco / early evening in Germany. So it’s sometimes not easy to meet friends in pubs, bringing my daughter to bed or taking my wife out to the movies, but it gives me on the other hand the opportunity to bring my daughter to the football training in the afternoon or pick her up from school for going swimming with her.

So what?

In the end I must say that I have the best job in the world. You have to be passionate about your products, your culture and the community you engage with. This makes me jump up each day in the morning. I’m looking forward to open the eyes of people to see that they don’t have to suck in software development and that they can be happy developers by changing the way they think about this profession. I’m so pumped to tell people that we have an amazing job: We can be creative, we’re helping people to be more effective and we work with cool stuff. You just have to realize that this industry is dynamic and it changes fast and so do we as developers need to change constantly.

Help me not feeling so lonely!

IMG_2619We’re looking for a team mate for me in France and the UK! Do you want to hang around with me in old hotel bars, spend the night in front of a screen doing a video conference call with people in San Francisco, or just pissing in your pants before going on stage at a developer conference? Sounds great? JOIN US!

Code Reviews, just better

“Code Reviews Are More Important Than TDD”

Dr. Venkat Subramaniam

Bildschirmfoto 2014-01-06 um 15.42.40Don’t get me wrong: Test Driven Development is great and it helps with a lot of things: Good quality, maintainable functionality, repeatable tests and much more. We did a survey at conferences that showed us that around 70% of all developer teams are practicing some kind of TDD but just 30% are doing regularly code reviews. Why is that? Here are some explanations why test automation is so much more common:

  • It’s automated: Developers love to automate things. You can use a fancy build server and show that your code is running.
  • It’s an easy to follow process: You write tests, you write the code, you run the tests. Easy to follow for each individual programmer.
  • You do it on your own: There are no dependencies: Developer don’t have to wait for other developers to write tests, no social interaction is needed, the machine tells you if your code works or not.

The benefits of Test Driven Development are obvious, but here is why I think code reviews are more important:

  • Better code quality: Reviewing the code by a team member can maybe not catch all functional bugs but it can catch obvious mistakes, correct bad variable, method and class naming and it improves the readability of the code (and we all know that we read code way more often than we write it).
  • Learning: When reviewing code developer can learn from each other to write better code. Even intern can give senior devs a new perspective. This is also recommended practice for book writers: Read! But it also helps to understand the whole code base and not only the parts you are normally working with. You will review code from other parts of the system that you maybe were afraid to touch yet.
  • Feeling better: Having another developer looking over your code before it goes into production can make you feel better. You don’t feel that you’re the only one responsible for a potential bug. There are others that haven’t seen it either!

Code Reviews with less meetings & better tools

So what’s the problem with code reviews? Why are not all teams doing them? First we should all agree that the time reviewing code is well spend! Some teams practicing a meeting every week to look at the code written the last 5 days or at a special feature. These can be a painful sessions for various reasons.

Make reviews less painful with tools.

Closeup of human hands pointing towards business manWhen we discuss code in front of the whole team it can be hard for the author: Everybody is staring at his code and give comments. I’m not saying that it can’t work, but here we have the same social problems as we see with Pair Programming (and there’s just one guy looking at your code). I’ve seen people not showing up or coming with stomach problems to work because his/her code was on the schedule for the code review meeting that day.

A tool like Gerrit, GitHub, Bitbucket, Stash or Crucible can help because the author has more time to about the feedback and don’t feel like going into defense mode right away. In code review tools authors can invite other developers to participate in the online review. You see the code changes and add comments to the code. Developers with strong opinions won’t take over the review in tools that easily and others that may be a bit more shy have a lower barrier to participate in the review. But the same rules apply also for online reviews: Be gentle!

Make the review part of your process.

stash1.3_threadCom_WhatsNew288Don’t make code reviews an end-of-the-project event. Reviews can get long and boring. Keep them small. For people that already uses Git with feature branches this one is easy: If you want to merge changes back to the main branch you can create a Pull Request. Git tools like Bitbucket, Github or Stash have a visual interface to make comments. No change will touch the main branch without a review (if you want). Just make it a natural part of your process: If you have a change, it needs to be reviewed. Keep changes small so people are not afraid of reviews. A task is not done if the connected code review is still open.

Some tools also offer the ability to see the code changes in context. What’s the problem these changes should solve? Most code review tools let you connect to an issue tracker to be able to jump from the review directly to the issue.

If you still prefer review meetings do them regularly, so people get used to them. I think once a day would be best but at least two days a week. Never cancel the meeting because of too much work and try to review every change. If you can’t run through all changes split the group and rotate the group members.

Review code when it fits into your schedule.

2339687721_67d1d5146eThat’s a problem with another meeting on our schedule: They never fit into our personal flow. If you do code reviews in tools you can do them whenever you got time: In between programming tasks, first thing in the morning or after the lunch break; independent from team mates and their schedule. Also: Don’t expect every reviewer to finish review your code. Someone will always not make it within one or two days or gets sick. Have a rule that you invite maybe 4 people and mark the review as finished when 2 people have approved the review. Just make sure that it’s not always the same people that are not reviewing the code.

Here you can find more tips for code reviews from Mattias Karlsson.

Photo Credit: Simone Lovati via Compfight cc
Photo Credit: Giorgio Montersino via Compfight cc

Starting a Collaboration Revolution

Products these days are complex. If you think about how many people are involved to gather requirements, to discuss priorities, to write the software, maybe create hardware, to test each feature, to come up with a great design and to operate or distribute the products… not talking about marketing, finance  & controlling here… Building great things is a team effort nowadays and communication is the key for success:

40% of creative teams productivity is directly explained by the amount of communication they have with others to discover, gather, and internalize information. [source]

How does information flow? Another statistic tells us that 70% of the information exchange is driven by the team lead and only 30% inside the team. The boss is a bottleneck: Information should flow freely inside the team. How can we change this situation and foster more collaboration inside and in between teams? Here are my thoughts for a collaboration revolution:

Problem: Physical isolation

A lot of workspaces are not designed for collaboration: A hallway with some doors left and right… How should information flow here? Open space offices foster collaboration. You can see who is there and start a direct conversation. Putting up open workspaces with couches, arm chairs or bean bags  are great  to work somewhere else but at your desk and have spontaneous  discussions. When I’m in the Atlassian office in San Francisco I use these places to show that I’m not working on a very intense task that need all my concentration but be ready to be disturbed. On the other hand you should have mechanisms to show people that you don’t want to be disturbed because it will destroy your current flow of work. Some teams are indicating that by using headphones, even though they’re not necessarily listen to music or having a dedicated person on the team that is answering  questions for the whole team (doing kind of support).

atlassian_office

There is also a need not to isolate specialist. We know that cross functional teams are a great idea. Having a designer in the team when working on the new user interface is making decisions  fast and understandable.

Problem: Communication barriers

Three communication barriers are making communication hard: Places, people and timing.

Places: It’s hard to get the right information when you work in a remote team, in a coffee bar or at home. But if you want great people, you probably won’t find them in your town and it’s hard to move them because the competition are already offer them working remotely (do you hear me Marissa Mayer?).

People: Employees keeping information on their hard disks, in Emails or in their own heads. Information are exchanged on hallways not accessible for all employees.

Timing: Meetings are a killer for individual productivity. They have to fit in everybody’s schedule. We also don’t work synchronized anymore! When someone is doing a coffee break another one just works on a great idea she just had at the same time.

We use our collaboration platform Confluence for tearing down the communication barriers. We once had a post on Confluence where our support expressed their feelings how unhappy they are with the work load and conditions. Independent of place, role and time zone other employees from Atlassian were commenting on that post adding arguments and trying to find solutions. After one week we put together a program for better work conditions in our support. We wouldn’t have accomplished the same results by inviting stakeholders to a local meeting.

Also chat is helping a lot when hitting a timing or place barrier. One team can start a conversation in a chat room during day time on this side of the globe and another team on the other side can join the conversation 12 hours later during their day time.

Problem: Foggy goals

If goals are not clear, how can we work as a team? I’ve been working with yearly goals that were obsolete after 3 month. But there was no mechanism to redefine those. Also I was missing a frequent check if I’m on a good way reaching my goals or on changing tactics how to reach those . I’m now doing a bi-weekly check on my 3 month goals that reflects our yearly team goals. Goals can be changed easily if the company focus changes.

Goals should also be transparent. What’s the reason that I don’t have the possibility to find out the goals of other team mates and other departments? It’s so important to align your goals to those other teams have.

Problem: Impersonal environments

HubSpot-Face-Wall

Definitely the most important part of the collaboration revolution. If we have a good personal relationship to our team mates we know our strength and weaknesses and how to effectively get the work done! But more important: If you have friends at work it’s so much more fun. So what can we do? First have a good onboarding system. At Atlassian everybody needs to write an introduction blog post in their first week. People can make comments on it and learn some personal things about the new employee.

When your organization is growing it’s hard to know everybody. Hubspot is trying to solve this problem with an electronic wallboard in the hallway, showing faces of people and their name. Watch the video and grab the source code.

The presentation

A few weeks ago I did a presentation on this topic. Here are the slides and a video on German.

Five Word Tech Horrors

The last 48 hours people were tweeting their tech horror stories in five words. This really made my day… but the scariest thing is: I’ve heard most of this quotes in real life! These are my Top 20 tweets:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

6 Ways to Boost Developers Performance

rocket

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

goalI 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

feedbackIf 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

arrowsAll 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

magnifyTalking 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

talkLet 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

championI’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!

Innovation Moments

5568499672_92e14b97aeIdeas drive our businesses. We all know that it’s important for our products to fill them with innovation so the users love to use them and we differentiate us from our competitors. But we as knowledge workers also have some small ideas. How often did it happen to me, that I was thinking hard about a solution for a problem at work, went home and had the answer somewhere between leaving my desk and entering the office the next morning.
So let’s face it:

You can’t plan for really good ideas

Where ideas happen

I’ve just been on vacation for a few weeks. Before that I had so much work stuff in my head that I couldn’t focus on new blog posts… But just by sitting at the pool for a few hours opened my mind and I had lot’s of ideas for new posts or talks. I think everybody has experienced this kind of innovation boost. I’ve spoken to a lot of people and this are my TOP 3 places for innovation:

Under the shower
I don’t know what it is? But all people I was talking to agreed with this one.

In the gym
I use to listen to technical podcasts or watching presentation while running on the treadmill. My mind fades sometimes away from what people are saying and create it’s own innovation path.

On vacation
No matter if I just sit at the pool, the ocean, the river, drinking wine at a nice spot or just lay a little bit longer in the bed: I come up with new ideas that I want to try out when returning to work.

Those are not magic places where a fairy appears and whispers you the innovational idea into your ear. I’m normally starting thinking about a problem I have and float with my ideas.

But: Did you recognize something here? None of these place is really where I get my work done. It’s most of time when I’m away from work.

Innovation doesn’t happen between 9 & 5

So here is what you might do if you want your employees to come up with new awesome ideas:
– send them on vacation
– give them the freedom to work whenever they want
– maybe encourage them to do some work out

BUT: THERE IS ONE BIG PROBLEM WITH THIS APPROACH: How do you capture the idea?

Capturing ideas

It happens so often to me… I have a great idea in the gym but when I return home I’ve already forgotten it. I used to carry a notebook around with me but now I capture my ideas quickly with Evernote. I have it on my phone (for the gym and vacation) and on my laptop to look through my ideas later. But I guess any online synching note program will do the job. I don’t know how to solve the shower situation…

Make your ideas social

It’s just my idea… Is it good?
What looks to you like a brilliant idea might look very stupid for others. At Atlassian we use the blog functionality of Confluence to share our ideas with the whole company. We have a very collaborative culture, so people write lot’s of comments to your post. In about 24 hours I can get so much feedback for my idea (especially if I was totally wrong).

The path to good ideas

  1. Find your innovation places (It’s not your desk)
  2. Start thinking about a problem or possible solution
  3. Write it down
  4. Spread your idea and get feedback

See you this autumn

So it’s September and the conference season starts again. I actually wanted to do a little bit less travelling this autumn, but looking at my schedule for the next months I can forget that. So if you want to meet me here are the places I will be:

kick-ass

10th – 12th September: Oslo at JavaZone and Atlassian User Group

I will do an user group meeting at the 10th and talk about news from Atlassian. A day later I will present different Git Workflows at JavaZone.

 

25th September: Berlin at Berlin DoSE

At Berlin DoSE I’m gonna do the closing keynote about “Kick-Ass Software Development (TM)”.  After the talk we gonna throw some drinks for the attendees.

1st – 3rd October: San Francisco Atlassian Summit

That’s very exciting for me, because I’m gonna speak for the first time at Atlassian’s own customer conference about ‘How to make good teams great’.

19th October: Kiev at Javaday

The Javaday in Kiev is a community event and I’m gonna try to Kick-Ass there with my presentation.

21st – 23rd October, Zurich at Jazoon and Atlassian User Group

I will be at a user group meeting on the 21st and talk at Jazoon about how to do better software development by kicking ass one day later.

7th November: Wiesbaden at Tools4AgileTeams

I will talk about how teams can use Git for better development workflows at Tools4AgileTeams.

11th – 15th November: Antwerp at Devoxx

I guess Devoxx is Europe’s largest software development conference and I will do 2 presentations this years. One on Kick-Ass Software Development (TM) and another short talk about not using Git!

21st November: Frankfurt JIRA & Confluence Community Day

I’m gonna do the keynote at the Community Day about the Collaboration Revolution in companies.

Plus more:

I still have some options out there and I will probably do some Drink Ups in some of these cities to meet with customers. Contact me if you would like to meet. See you somewhere this Autumn!

Writing killer submissions for conferences

speaking-handandmicI was recently asked to join the program committee for a medium size conference in Switzerland named Jazoon. I had to review around 30 submissions and found out, that this is a really tough job. I learned so much about helping the program committee to decide if your talk should be accepted for the conference program. So here’s what I learned (and have to apply to my own submissions in the future):

Picking a topic

  • topiclook around what is currently hot at conferences
  • the program committee is trying to find new and unique topics like “functional programming”. Older and not so funky topics like OSGI or SOAP are more likely to be rejected
  • check the tracks and themes of the conference. Your submission should fit into those… the more the better
  • be focused but not too focused – the topic shouldn’t be so broad like “Agile Development in practice” but also not like “Agile Development for left handed build managers” (I know this is a stupid example, sorry for that)

The title

titleAttendees just often read the titel and decide if they should continue reading the abstract. So nail your title:

  • should be interesting like “The dark side of project management” – there are so many talk submission (Jazoon had over 200 submissions for 50 slots) and compelling titles stick in the mind of the committee and the attendees
  • the title should contain the information what your talk is about. Don’t shy away from buzz words like Agile, Scala Testing… so you don’t leave people totally in the dark just to sound cool (like “Huston, we have a problem”)
  • a “list talk” is always great like “10 things: How to write a killer submission for conferences”

The abstract

abstractThe abstract is the hardest thing and the the most important thing for the program committee. Always think about what the audience needs for deciding if they should go to your talk or not. So here are things that your abstract should contain:

  • what is the problem you’re trying to solve
  • why is your solution interesting?
  • tell a little bit about your solution – This is the most common problem I faced when reviewing submissions. The program committee has to decide whether your solution is interesting and new for the attendees or if you will tell already known things.
  • don’t tell everything about your solution; You need also to surprise people in your talk 😉
  • don’t make it sound like a product demo
  • try to close with why you think people should come like… “We will present tools and teaching material that you can take directly into a school or programming club to get kids to start coding.”
  • Be concise: Your abstract should be maximum 250 words
  • check the grammar: Show your abstract to someone else, especially if you’re not a native speaker like me!
  • 1-3 paragraphs

Speaker information

  • speaker infohave a look around on conference pages and adopt one you like

IMPORTANT

If you’ve already have spoken at one or more conferences tell this fact to the program committee. There is often a field you can fill out like “message to the committee”. If not: consider to add it to your bio. Sounds lame? Maybe, but the committee knows that you’re able to do a presentation and other conferences have already excepted you in the past. If there are videos of your talks, send the links!

If you don’t have experience in public speaking, take a video cam and shoot a 5 minute video of you presenting. Add the link to your submission!

And Now: Good luck and see you on the next speakers dinner 😉

Power to the Developers

fistI never understod why companies are building a strong management driven culture and destroy the creativity of the developers. We need freedom to build awesome software with great quality fast. That’s why some people see us as the prima donnas in a company. When our management gives us the freedom of choosing our own tools and processes we have to turn that trust into productivity and quality. We have to find a great development culture that we live and breathe every day. Culture is so important:

“Culture eats strategy for breakfast”

Peter Ducker

These are my 7 points how to build a great development culture and give the power back to the developers. It may not be complete but things can’t go really bad if you can follow these things:

1. Find a way to deal with customers

png-4Customers suck! They find all the bugs and call you in the middle of a great pair programming session and destroy your mojo. It’s not a good solution to let just the support or some product managers deal with customers. Try to send developers to your users. Let them see how the tool is used that they are creating day in and day out. It’s not easy to find the right balance between “Getting things done” and learning the needs of the business. But your culture should make this absolutely clear: Everybody has to be at the front line and know what’s going on in the real world. Do daily stand ups and discuss customer requests. Meet customers frequently. This gives us the power to build the best software from a technical and a usability stand point.

2. Don’t be evil to your software (and don’t let other people tell you to be)

png-1We all had this situation: Your boss or your customer asks you to do a quick hack. Just a small change that will drain your quality or it will just look bad. We want to please the people that are responsible for our payment. BUT: We have standards. We have to deal later with the technical dept. We have problems with scaling the software. Stay true to your principles. Say: NO! ..and at the same time try to educate your boss or your customer why this is a bad idea and why it’s important to hold your software development values high.

3.  Show people why they are important

pngWhy do people go to work every day? Yes, to earn money. But this kind of motivation is losing more and more traction nowadays. If you earn a certain amount of money, rewards doesn’t motivate you to be more productive in the long term. People want to get appreciated by humans for what they are doing. Not just once a year when you have your yearly conversation with your manager. Do it whenever you think: “Cool, that was great”. I had a great experience when I’ve send one guy from the team to the customer just to see how they use our software. He came back and said: “They really are productive using our stuff. They love it”.

4. Do your own thing

png-6There are so many good ideas out there in the world. Don’t follow all of them. You should just pick those, that makes sense for your team. Don’t try to implement Scrum by the books. See what works, what doesn’t, get your own ideas and try them out! Don’t follow blindly another Guru that is trying to teach you the right way.
Developers should have the right to decide what works best for the team. But we’ve been studying for years, we fix problems every day and can’t decide how we work best? Developers should be treated like grown ups, not like 13 year old school boys. If we think a tool makes us more productive, let’s buy it!

5. Learning is everybody’s own responsibility

png-3The company can send you to conferences or workshops and they can buy you books. But lets face it: You won’t learn anything from a 45 minute talk or if a book is just laying in the shelf. You have to take action! Nobody can help you with that, it’s your own responsibility. And we have to learn if we want to know what’s going on. Yes, there are some things to do together like coding katas or brown bags. But also here: It’s still the decision of each employee to take that power and use it for something good.

6. Change is the only constant

png-2Do I have to say more? Think constantly about what sucks in your software development and change it! Don’t be afraid of new things or to pull the plugs on things, that have just currently been implemented but really doesn’t work out. Change and improve constantly.

7. Focus on quality and dev speed

png-5Depending on the product you’re developing one or the other is a little bit more important. It’s sometimes hard to find the balance: If you  put too much effort in quality, your deliver speed will slow down. If you’re delivering like a maniac, your quality will drain from that (you will see it in the long run). It is really important to always keep thinking about these two factors and to talk about them in your development team.

Credits for the pictures:
Couple designed by Jens Tärning from The Noun Project
Electrical Shock Warning designed by Travis Yunis from The Noun Project
Blindfold designed by Luis Prado from The Noun Project
Approve from The Noun Project
Interchange designed by Laurent Patain from The Noun Project
Speedometer designed by Olivier Guin from The Noun Project

Being an Evangelist

I just got reminded, that I work now for almost 2 years for Atlassian as an Ambassador. First I was very concerned working for the dark side (the Marketing departement) from a developers view. But it turned out that it’s pretty cool to be a bridge between the 2 worlds. Even though I would love to do more coding I enjoy the job so much! I know that a picture says more than 1,000 words so I created a video with a lot of pictures… what would be worth a 100,000 words. So here is my life the last 2 years in 3 minutes.

I learned a lot the last 2 years, more than I can put in a blog post. But here are some things I discovered to be important.

5 tips for becoming a kick-ass evangelist

1. Create slides that rock

Yes, your presentation style and your message is the most important think for a talk…. but a lot of people look at your slides and watch them later on slideshare. (6,600 developers saw them on a screen, 30,000 on slideshare). I discovered that creating great slides is my thing and I can spend hours working on just the details.

2. Practice, practice practice

…and if you think you are good and are sick of trying your presentation again: It’s time to practice more! Yes it takes one hour to do a total test… but if you speak in front of let’s say 300 people you better be really good prepared and don’t waste 300 developer hours!

3. Prepare your travels

Travelling is sucking your performance. Use time in buses, planes and train stations. I prepare my travel by downloading everything I need to get the job done on my laptop. Internet sucks normally everywhere, but at home or in the office. I normally do translation stuff, blog posts and abstracts for talks during travelling.

4. Make connections

Instead of waiting for the Internet to work at a conference, use the time to talk to people. Hang out in the speakers or attendees lounge, go to the speakers dinner and attend conference parties. I met so many awesome people everywhere I go, it’s amazing. The conference world is small and you will definitely meet people elsewhere. Try not to be shy to talk to your idol…

5. Use the power of social

I was amazed how a message can spread when I wrote my most popular blog post “Don’t use git” (20,000 views in one week). I don’t know which channel was the most successful or which retweet started the domino effect. I just post a new blog on LinkedIn, Xing, Google+, Twitter you name it. And I guess I’m missing also some opportunities, because I’m not aware of them.

Some statistics

Here are some statistisc from the last 2 years:

  • I created 28 different slide decks
  • I delivered 40 presentations
  • I spoke in person in front of 6,600 developers (incl. 2 conference keynotes)
  • I reached 4,000 online video views
  • and 30,000 on slideshare
  • I wrote 3,000 tweets
  • I did 115 personal blog posts
  • I had 70 flights

Thanks Atlassian for creating my dream job and my kick-ass team for helping me becoming a better ambassador!