11/04/2014
At the beginning of July 2014 we hired a new team member, Krisztina. The OutSystems Academy team went from three to four members. Hurray! The release of OutSystems Platform 9 was scheduled for September 15. So even before we hired her, we knew that she would have a trial by fire: do her ramp-up while we were running towards a milestone.
In hindsight this was good. It provided her and us with lots of opportunities to learn. And there is no better way to get to know someone than in times of great stress.
Since I’m a fan of post-mortems and retrospectives, this post is a kind of retrospective on what I think worked and what didn’t. It'll serve as reference for the future me, if we need to hire new team members. And also I'm sharing this with you so that you can learn with our mistakes and avoid making them yourself.
Before going into detail about what we did to ramp-up Kris, it's worth sharing what we had planned for her ramp-up. This way you'll understand how we deviated from what we had originally planned, and the impact it had on the team's output.
Since OutSystems Platform is a huge product, when you join us, you spend the first week learning the product. We designed this training to be hands-on and allow you to at least get acquainted with the tools our customers use and love. The goal is not to make you proficient, is just so that you get a glimpse of what you'll help building. It's also a way for us to eat our own dog food.
Once you finish that part of the training, you take the associate developer certification exam. This is only for self assessment, no one looks to the exam result.
After the platform training, our goal was to get Kris acquainted with some of the tools and processes we use.
Some tools need training, like subversion. Others are easy enough that you can learn them only when need them.
Some processes like the daily stand-up meetings are easy to jump start. You join us in the first few days and are a bit clueless on what should you say. But by the end of the first week you’ll get the hang of it.
After learning about the platform the tools used internally, our plan was for Kris to start contributing with documentation. We would assign her some close-ended tasks that required few context to solve.
The idea was to make Kris learn the assets we have, where you can find them, and learn more about the platform. All this while contributing with valuable effort, solving tasks that needed to be done before the version was out.
A good thing of working on close-ended tasks is that it's easy for senior members to give actionable feedback. So the plan was for the team members to give feedback to Kris, without directly editing her work. This would provide her feedback early enough so that she could iterate without losing much time. It would also allow her to compare her proposals with the team revision. This is a better way of learning than reading someone else's work, and also makes her accountable for her own work.
As Kris learned more about the platform, the culture and the writing style, the plan was to make her work on increasingly open-ended tasks. This would make her autonomous, and if she failed, she would fail fast. We would be there to review her work.
Open-ended problems are more difficult to solve, because you can solve them in infinite ways. So at this stage we would focus on ensuring Kris work was consistent with the existing learning resources. Basically we would serve as editors, since we don't have one.
It also would force Kris to challenge the status quo. Most new hires for our team assume that everything that what development teams do is right, and cannot be changed. So we would show her that its OK to challenge the development teams, and that it can lead to improvements on the product and documentation.
The first two weeks went as planned. Kris completed the standard R&D training and learnt how OutSystems Platform works.
During the first two weeks the only sync point between her and us were our daily stand-ups, and some time we took when she was blocked. Since this part of the training was mostly done on self service it was easy for everyone on the team to follow-up on her progress. Maybe for her it was a bit boring since she had few interactions with the team. I'm not sure how we could improve this part of the ramp-up.
On the third week we briefly went over some tools and processes. It was really a lightweight training, since it's difficult to memorize everything at first. Yes, it's easy to forget how many things you've got to memorize to contribute to the documentation: - How we structure the documentation on subversion; - Where is a document, since we use svn, network drives, google drive, and dropbox; - How we use our issues tracking software to keep track of the work; - Lot's of other details that would bore you.
Some processes and tools like how to use subversion are not so straightforward to teach. So we set up some time aside for Kris to do hands-on training and have demos from the team members. I ended up making a small presentation about how we use subversion and where to find relevant documents. This allow her to learn it on her own, with minimal interruptions for everyone.
This was important for two reasons. When she joined us we where already under pressure. This way we only had to help her with some questions, instead of demonstrating all the process. And also because that presentation can be used in the future by other new hires, or just for reference.
After that third week things got messy fast. Since we were on a tight schedule we started to give her some close-ended problems. She changed the system requirements several times. She improved the documentation for the built-in functions. She even cleaned-up the documentation on how to test your own database queries.
Also, on release 9 we replaced a feature to perform queries to the database (Simple Queries). So she went ahead and removed from the documentation everything related to that feature. This was no small feat for someone that just joined the team. There were references to this feature all over the documentation. Removing it required lots of work and paying attention to the details.
As time went on, and we got close to the deadline, we started handing more and more open tasks. Another new feature was consuming REST APIs. Kris documented how to handle REST exceptions - when you receive an HTTP error from the service.
Another open ended task was writing most of the documentation for the new feature to fetch data from the database in a visual way. I gathered the use cases and wrote the foundation for the help topics. Then Kris went ahead and completed that documentation. She added screenshots and GIFs to ensure you wouldn’t even need to read the documentation to learn the feature. How awesome it that?
Since the schedule was tight, there were some changes that weren't reviewed by anyone. And I think this shouldn't really happen. It's not a trust issue, it's just ensuring that we perform some quality assurance on what we do. That and trying to keep the docs consistent.
Lesson #1 - add enough time for review to the plan.
Since we all noticed that we really needed to stop and review the documentation, we scheduled a morning to review everyone's work. Here's how it went:
The session was tough for everyone, but it went great. It ensured everyone knew what was being done, and major issues were all identified. The only thing that went wrong, was that we planned it for a morning, and it took almost a day.
Lesson #2 - (again) add enough time for review to the plan.
We really need some lightweight review cycles within the team, or someone to play the role of a release manager/editor. Someone that takes time out from producing content, review everyone’s work and provide feedback. I’m sure this will be much more productive than creating style guides. Even good style guides leave lots of room for interpretation. But if someone acts as an editor, they can have a birds eye view on how the documentation is changing and try to guide the team on keeping it uniform.
Lesson #3 - with proper mentorship processes, you don't need style guides.
I tried to play this role myself for one or two weeks, but it was difficult to accumulate this role with all existing work. I had to stop because work kept accumulating. But during that time I found and fixed several documentation bugs.
At one time, I detected something that was incorrect but was unable to fix it since so many work had accumulated. Three weeks after the release that bite us in the ass. A customer read the documentation and submitted an issue through support. For me this meant that one customer had a bad experience with our product, and that support had wasted time solving an issue that could have been prevented. So I clearly see value in having a senior member making lightweight reviews to all new documentation created.
Lesson #4 - if you find something wrong, go fix it. It can bite you in the ass later on.
When we released OutSystems Platform 9 on September 15th, Kris was pretty autonomous. For sure there are tasks she didn’t had the opportunity to do, but I’m sure they will come up on a near future.
But hey, only two months after she joined us, she was already installing the OutSystems Platform with a MySQL database. Aweeeeesome! She even found and reported bugs that would most certainly impact our customers. So yes, she seems to be autonomous.
Lesson #5 - when hiring keep the bar high. Even if it takes you lots of time interviewing, it'll pay off in the future.