Thoughts from Away Day

Topic: “Thoughts from Away Day”

Example ideas:

• What was your favorite presentation?
• What do you think the purpose of Away Day is?
• What will you take to your project?
• What do you think you/we can do to make active change on SIP issue [X]?)

Alyssa Nabors

2013 Away Day was my first experience EVER with ThoughtWorks outside of the interview process. It blew me away then, and it did the same this year! I really enjoy the opportunity to get in touch with ThoughtWorkers I haven’t seen for a while and get the chance to meet more, old hands and brand new! I couldn’t stop talking about how brilliant the selfie quest app was- gamification of networking, with a picture dictionary of the ThoughtWorkers you met!

(gif source: http://i1138.photobucket.com/albums/n527/The44thHour/DWBrilliant.gif)

As someone who has had the opportunity to engage in multiple roles on different projects, I had quite a time deciding with breakout sessions to attend. I ended up choosing mostly sessions that contributed to my pet-project-necessitated skills: UI design. However, I also made time to attend an informal Crucial Conversations workshop, as I am always striving to improve my consultant-specific toolset. One session actually bled into both areas: a talk on rational design, which touched on how we become attached to our ideas very quickly and can lose sight of what the actual best solution might be. A book that was recommended to me by the speaker if I really wanted to “geek out on the subject”: Harry Potter and the Methods of Rationality

One thing I really want to see come back next year is the Haymarket book table. Everyone who saw me at Away Day knows they got quite a bit of my money. And with good reason! With books like No One Is Illegal, Men Explain Things to Me, and Brazil’s Dance with the Devil, there were plenty of ways to read up on many of the issues we touch on in our P3 endeavors.

Aubrey Chipman

I had a number of take aways from Away Day.  Here are some of them:

• I need to watch/ hear more of the speeches of Civil Rights Activists.  The ones we saw were full of force and determination, and I want more. 
• Websites are not built for people with screen readers.  Either we need to make a better web interface, or we need to make better screen readers.  Possibly both.
• I met so many people!  Taking selfies with others worked wonderfully as a way to run rampant with taking photos, a way to get close to people you haven’t made friends with yet (and then you have!), and a way to encourage a little competitive spirit in the get together.  
• I want to make a responsive site starting with mobile-device display size first, to allow for growth of content according to viewing size.  This seems like an under-utilized, good design pattern to follow. Check it out.
• We can all become better story-tellers.  I wish the workshop on this was longer, as it was applicable to all of us as positive-change-driving consultants.  

Linda Goldstein

#NAAwayDay is too nuanced an experience to describe to completion, but here is some stuff...

1. My favorite part was seeing all the great people I’ve worked with. I think that Away Days get more meaningful the more of them you attend.
2. I think that the "Selfie App" was a brilliant idea, well executed. I saw many ThoughtWorkers using it as an icebreaker for interacting with our thought leaders like Martin Fowler and Rebecca Parsons. It was an engagement enhancer for many TWers, it produced some hilarious collateral, and it made great memories. There was even a Beryllium selfie onstage! It is one of my favorite tweets from the #NAAwayDay twitter stream.
3. ThoughtWorks TechOps ran a flawless remote keynote (with remote Q&A!) This is a communications achievement that many of our projects arrive at inconsistently and with great effort. I am very impressed.
4. What can ThoughtWorkers do about these causes we have heard about? We are told - you can read this book. Buy this t-shirt. It is a drop in the bucket, and there are a lot of buckets. It is not fulfilling to put one drop in these one or two buckets. Which drop? Which bucket? I think that you have to pick a cause that “speaks to you” and put most of your drops in that bucket.
5. TW is not perfect at internal communication, or at living up to every one of our ideals all of the time. I think that Away Day helps us unify and become more aware of where we are not internally ligned with ourselves.

How do you make a project comfortable?

Prompt: How do you make a project 'comfortable' for women/HDA/everyone? 

• What are ways in which allies can ensure that they give the appropriate space on projects?
• What makes projects less comfortable? 
• Gender, gender expression, Historically Discriminated Against (HDA) perspectives

Abby Bangser

I think that being self aware is very important. There are ways to watch your language, proximity and activity suggestions to make interactions easier and more welcoming. In addition, the people that have made me feel most welcome are the ones that are aware of others interactions as well. The teammate that comes over after a particularly male dominated conversation to discreetly ask if that went too far, or the supervisor who notices, and chooses to address, the fact that I may excuse myself from certain gatherings are the people who can make a change.

The term "ally" is used in the prompt to ask what actions that person can take. Beyond personal action, general awareness and empathy can go a really long way in opening lines of communication.

Alexandra Price

One thing that many people brought up is the feeling that you’ll say something in a meeting (either formal or informal) and be ignored or shot down, just to have someone (usually a guy, especially if they are more senior) say the same thing thirty seconds later and have everyone agree. One of the things that can really help is if whoever does get listened to can act as an ally, and make of point of saying something like “I agree with what Alexandra just said” rather than repeating the point. Once this happens a few times, people will usually start listening better in the first place. Of course, the best thing would be to start every meeting by reminding yourself to give credit to everyone’s ideas. If people feel they won’t be listened to, they will just stop contributing--and that hurts the entire team and project.

Alyssa Nabors

I didn't realize until I started my first at-the-client-site project, but ThoughtWorks is a bit of an idealized version of a diverse workplace. I was almost never the only woman in the room, no matter what room I was in or why! Starting my first project was a little bit of a shock, being one of two women on the team for nearly two months. I don't think that anyone on the team has ever said anything that could be remotely interpreted to be about my gender, except for a compliment on my engagement ring or congratulations on my recent marriage. Even in times of great stress, feedback has been framed around making the team more effective and being a better consultant. However, if I didn't have Kim with me on this team, I likely wouldn't have confided in anyone until our team grew and more women rolled on to the project. There are certain things that I struggle with that feel, to me, like something that could be interpreted as signs of weakness, or, in a less supportive environment, attributed to my gender rather than a stage of personal growth. There are certain judgements that I'm concerned men coworkers would make where I feel another woman would be able to empathize. Even if I had been the only woman on the project, I know I would've been able to at least confide in my coach. I know that she can understand what I'm going through, and give objective advice. Knowing that I can reach out to her for a fresh perspective and absolute support. She's a she though; I know I wouldn't have the same level of trust in a man coach. Maybe this is unfair to the majority of male-identifying ThoughtWorkers, but I've been burned before and my comfort zone is firmly established in this regard. You want to make everyone comfortable on a team? Make sure they have someone with whom they feel they can communicate with openly and safely. Maybe for other Historically Discriminated Against groups, or even other women, this may not mean "someone with the same background as me". Maybe it just means someone they have established a relationship with. Whatever it means, I think it's worth making sure that everyone has that resource.

Aubrey Chipman

A more comfortable experience is one that is inclusive.  For example: having team lunch/ dinners at locations that everyone gets a chance to pick, and will respect people who have dietary restrictions; team outings that are broadcasted to the entire team, not just select individuals who can become a clique.  As well, staffing on a project will have a large effect on comfort levels: it is good to staff at least two of any underrepresented group.  As a woman developer, this has the largest noticeable effect that helps me relax in a work setting: I am not alone.

As for what makes a project uncomfortable: a lack of discussion when people have different styles of disagreement.  In a team setting, it is inevitable to have disagreement, and frequently these styles will not match up.  When there is one party that consistently falls to silence or one party that consistently ‘wins’, the team room gets awkward.  And then it gets worse.  

Lily Lambda

1. I want my gender respected, just like everyone else. I don’t see any reason why teammates should fumble between “she” and “he” for the first few weeks. They need to practice that on their own damn time. Complaining that it’s difficult because they’re not used to it is unacceptable. To me that translates as “I’m exploding with cis privilege, don’t view you as a woman, and don’t really care to self-examine. It’s your job to educate me, and my prerogative whether to listen or not.” Being misgendered is downright traumatic and can derail my entire day. It’s dehumanizing. I can’t describe a lower level of “safety” than fearing I’ll be addressed as a man.
2. I don’t think anyone should ever label themselves an ally, nor do I believe a man should ever call himself a feminist. It’s a fig leaf and an appropriation of a marginalized identity. Act like an ally. Don’t call yourself an ally.
3. Unless I explicitly invite feedback on my outfits (and admittedly, as a femme with exhibitionist tendencies I sometimes do …) I don’t think it’s an appropriate topic for conversation. I know how the game works: people think they’re just giving compliments. But the flip side to compliments is withholding compliments. I get loads of compliments when I dress more cisnormatively, heteronormatively, feminine, and mainstream, but receive very few otherwise. Translation: “we don’t like it when you look trans, gay, masculine, or reflective of your culture.” Ouch! The same goes with “helpful suggestions”. They amount to “here’s how you can look more cis, straight, feminine, and culturally mainstream, because those are best.”
4. I’m unnerved by brogrammer culture: shouting, pseudo-intellectual posturing, interrupting, arguing, mansplaining, etc. Teammates should not do that, even if they’re coming from a startup culture where it was accepted.
   
5. Teammates should calibrate their speaking styles to one another. In practice I think this means male developers need to speak less often, less loudly, and with less authority/certainty. As the dominant group, I believe the onus is on them. Others can benefit from speaking more frequently, more loudly, and with more authority/certainty, but as the marginalized group the onus is not on them. This should not start an “arms race”.

Linda Goldstein

To me, body language is important in team interactions. Having a fellow teammate slowly inch closer to you over the course of a conversation is hard to address verbally without sounding irrational. I usually use the phrase "Could you please move over. I like to have a lot of personal space."

I think that a characteristic of a team which is likely to be pleasant to be on is that if there is a meeting between several different physical locations, all team members make a point of speaking to the phone and actively involving remote members in the conversation.

Reflect upon starting at ThoughtWorks

Prompt: Take a look back and reflect upon starting at ThoughtWorks. What were some things that enhanced your experience and what left you with more questions? Were there unexpected turns, and did you see yourself change with them?

Rebecca Lau

I recall coming in on my first day at Thoughtworks, and being floored that sitting around the table with me were more females than males (each with a different personality, as I later found out). It was just an observation at the time, but as I work and compare my experience as a CS major in school, versus learning at Thoughtworks, I find that this diversity has made an enormous difference in how I feel on a day-to-day basis. Why? Perhaps I cannot, or should not, point at a singular reason.

Still, I can remember sitting in a CS class, thinking over all my questions thrice in order to make sure they weren’t stupid so people wouldn’t judge me (and somehow, judge all the other people who shared my gender but weren’t in the room). A lot of the time I ended up not asking the question, or I would save it for later, when I could send an impersonal e-mail or meet the professor one-on-one in office hours (but only if I had previously developed a good relationship with the professor in the first place).

While I’ve been at Thoughtworks, I think about what I want to say- but I am no longer afraid to seem ignorant, and this has helped me fill in the gaps in my knowledge base. I cannot point to anything that caused me to consistently feel this way at school. But I also cannot deny that it was there, and now it isn’t. Have I changed, or is it just the environment around me that has changed? It may be impossible for me to tell, but at the very least, I am more confident in my opinions and words today.

Ariel Flaggs

When I first started at TW I was not really sure what I had even signed up for, but I was ready to give it my best. That was easier said than done. Although, I was putting in the effort I did not know what I was doing. Going through the TW101 course work I felt I was missing the mark. My learning coach always offered steps for improvement, which helped to put my mind at ease some. However, when the week ended before heading off to India I was starting to doubt myself. I beat myself up that I was not learning fast enough. I was not used to struggling to grasp concepts and ideas and I did not like this feeling. I went off to TWU with the mindset that it is ok to fail. I am not sure I fully believed this, but I went with it. Once at TWU that’s exactly what I did. Not failed necessarily, well I hope not, but saw each opportunity as a learning experience. In time I beat myself up less and less. I am now much more comfortable with not knowing and learning as I go. Quieting the negative voice in your head can be hard, but has reduced the amount of stress I feel on a daily basis and allowed me to take it one step at a time.

Alyssa Nabors

Going into my first few weeks at ThoughtWorks, I felt like I was reliving my freshman year of college in a lot of ways. It was expected that I would go wrong in some ways, and there were people in place to implement course corrections. The people around me were just as new as I was, and so even though our knowledge and experience levels were hugely different, we were able to face our new experiences with a wonderfully comforting sense of camaraderie. Especially considering that many of us were new to Chicago, and that we’d be the only people we knew going to India, we were able to form friendships quickly.

I’ve been really grateful for those friendships as we worked through TWU and the weeks since. It’s a lot easier to ask friends for help, and to trust friends to give you honest feedback with the motivation of helping you improve rather than from a place of spite or malice. Friends make coming to work a happier thing, even on bad days. The biggest problem for me is that despite this collegiate atmosphere and these new and close relationships, ThoughtWorks is still my job. It’s a job that I love, but it is sometimes difficult to know where the good balance between professionalism and the typical TW casual attitude is until you’ve tipped too far one way or the other.

Best practices in feedback when someone feels unsafe

Prompt: "I think that someone on my team doesn't feel safe giving me feedback. What do I do?"

Linda Goldstein

It depends, but I would ask them face-to-face that I'd like to set up a feedback time with them the next day, and then use have a safe corner of the cafeteria or a huddle room or something. They will be stressed but hopefully it will make the point that you are open to feedback.

Start the feedback session with some small talk if you think it would be good, or go straight to "I've noticed that we've had some tension lately and I'd like to get your feedback on what has been happening".

Have some questions ready during the session, like "how do you think our interactions could be improved?" or "What do you think I could do differently?" Sometimes their answers to "What have I been doing well?" are also very revealing about what could be improved.

During the feedback session, don't reply or explain; don't say "I did that because X" or "that was because Y". This is their time to say what they have noticed, not your time to explain why those things happened.

Only explain during a feedback session if they ask- and even if they do, try to keep it very short, like "I did it because I thought I needed to because Bill said that it was important, and I didn't understand that Bob disagreed.", no more.

Also think very carefully about why they don't feel safe giving you feedback. Try hard to change this thing on your end, even if it is something that you think that they also need to change.

Mindy Or

Recruit a third party to aid in creating a safe space. This might be a coach/sponsor or it might be a sensitive manager. You can volunteer this person (or they can volunteer themselves) as an ear that will keep their feedback confidential.

Aubrey Chipman

I would want to talk to this person soon to clear up the air.  To this effect, I would ask them to choose a time to get together so that we can talk.  

For this whole process, I would keep in mind that this person I’m meeting is probably usually an awesome person, and I really want us to get along together.  Even if I feel safe, it doesn’t mean that this other person does, and I need to be careful and set the stage towards increasing a sense of security with this person.

For the meeting itself, a technique to increase safety in a conversation that I’ve heard about is to mirror the person speaking.  One person will begin, and the second person will repeat back what they have heard.  This second person is not to speak otherwise, or to voice other opinions until the roles are reversed.  The idea here is that any miscommunications can be spotted more easily and come to the forefront to be addressed.  

In this meeting, I would also mention that feedback is ideally a net positive experience so that the recipient can grow from past hits or misses; when no feedback is given, it’s difficult to know what has gone correctly or needs adjustment.  

Favorite Technical Presentation and What Made It Great

Prompt: Favorite Technical Presentation and What Made It Great

Aubrey Chipman:

When I think back to my favorite presentation, I always go back to a specific one which excelled in the following areas: content, delivery, interaction level, and audience captivation.  The topic for the presentation was to solve a single problem in four languages, beginning in an object oriented style and terminating using functional programming.  

To begin, we were given a sample problem and told to solve it in Java, which we were all familiar with.  Easy.  One pair then displayed their solution on a projector, and the group discussed the merits of the solution.  Following this, we were presented with information about the programming language Guava (which most people had not used before), and we used this new knowledge to complete the same problem again, but using this new language, which used a different style.  After viewing a team’s solution and discussing it, we went on to continue this pattern for the languages Groovy and Scala.  At which point, we were no longer in the land of object oriented programming, but had wandered over to functional programming.  

The reason I so love this presentation was because it took a novel approach to introducing a new technical topic.  As a group, we were interested, and the presenter kept us engaged by focusing on what we could create, and when we were stuck, by delving into more details pertinent to solving the problem.  Finally, this presentation made good use of the materials at hand: a projector, a presentation with useful content, and the -often forgotten- audience itself.  

Linda Goldstein:

The most recent excellently memorable presentation memory is of an impromptu discussion of threading in the JVM, especially as it applies to Scala. We started with the question "describe how threading works" and the presenter took us through the various layers, from the kernel to processes (one of which is the JVM) to "threads" in the JVM, to java.nio and java.util.concurrent, to Actor and Future, and finally to stuff like STM, agents, and continuations. (See diagram)

The presentation was great because the speaker knew the topic very thoroughly and had opinions about the subject matter, (i.e. how each layer should be used and manipulated by developers). Also developer jokes are great. Example: "As we all know, the best process to run is the JVM!"

Using the whiteboard, especially for a technical discussion of this nature, is very helpful. Even more important to the audience than seeing the finished diagram is to see it take shape as it is live drawn. It is possible to achieve a similar (but more limited) effect by showing pre-prepared incremental slides.

Abby Bangser:

As a Quality Analyst "technical" can be a very diverse word to me. I am frustrated by people who assume technical means that code examples are included in the presentation. I believe that a technical talk is one which helps my productivity and quality of deliverable improve in a measurable and calculated way. I have sat in some amazing talks ranging from story splitting to CSS code to database types comparisons. In each of the memorable talks there was one common thread, they drove me to keep learning long after the powerpoint was shut down.

This desire to learn more could easily be attributed to my initial interest in the topic or in an immediate need for the information. This would, however, diminish the value the speaker added to these topics. In each of the most memorable presentation, the speakers put obvious effort into selecting both applicable and exciting aspects of their topics, presented them in an immediately usable way, and most importantly provided an avenue to growing in the future. Talks that brain dump all the possible permutations of a topic can be hard to parse. Presentations that brag about a specific (albeit amazing) application of a technology or practice result in the "I wish I could, but..." syndrom. And those that only provide tools/books/links end up being one long bookmarks list which never gets opened. That is why the presentations which inform me while also leaving me at the start of an interesting rabbit hole for future research are the ones I am always in awe of.

Onboarding

Prompt: Onboarding new teammates/myself 

Amanda Snyder: 

I’ve seen onboarding be most effective when everyone on the team helps to reach out. It’s too easy for a single person to forget to mention something, or for that person to become very busy and not have a time for an onboarding at the moment. When each team member takes a small part in helping out, then no single person gets labeled as ‘In Charge’ or ‘The Person to Ask’. This is important, because it sets the stage for teams where everyone does what needs to get done, and nobody waits for someone else to step up. It easier then one may think to get into the bad habits of ignoring easy wins because it’s ‘not our responsibility’, or ‘but so-and-so always handles that’. Onboarding should be approached the same way any part of the project is. If one person knows how to do everything and handles all the responsibility, the team won’t move forward if something should happen to them or if they get tied up. However, if the knowledge is a shared knowledge, and each person on the team is able to contribute to the onboarding, then smooth transitions are easy to make at any time. 

 

I’d be the first to admit that I have been guilty of this in the past. It is sometimes easier to just step and take care of everything that needs to be done in one fell swoop. However, I have also felt the pain of later on assuming that if I were not around, then others would pick up most of the onboarding efforts. It does not work this way. I didn’t put in the effort to spread the knowledge and create the expectation that everyone was to help in the onboarding. It’s just as important that no one team member take too much charge, as it is for everyone to step up and help. Watch yourself to see if you are always the one to introduce someone to a project, and if so, make sure to ask others to help out while you can support the learning. Don’t wait till schedules fill up, time pressure increases, or you’re rolling off, and assume that others will know what needs to be done.  

Linda Goldstein:

I believe that the most essential onboarding step is to immediately be introduced to every one of your new teammates; it is easy to accidentally ignore and offend even the most kindly and professional new teammates while you’re still gaping at this new space which you will be spending so much time in. 

One of the most essential early onboarding steps is to get the new teammate all of the user access credentials that are needed to check email, push code, deploy, view+edit cards, etc. Forgetting or postponing this makes everything else into a ridiculous nuisance.

On the projects that I have been on, the same few steps always apply to solo developer onboarding. This is the stuff that I personally have to do before I can really “get” the code. Usually it is best to do this after hours or in gap time when you are not pairing.

• In 1-2 sentences, what does the project do, and why? Be able to explain this from memory.
• Clone the codebase as early as possible to a computer that you have access to after hours.
• Look thoroughly at the build script: what artifacts does it create? Can it generate a database, upload artifacts, deploy? Where does it get its dependencies from?
• Start from the main() (or index.html, or equivalent) of the codebase- follow one possible usage path all the way from the UI down to the lowest code layer you can find. (Repeat this several times)
• (If there is a database) Connect to the database. Look at every table. Look at the dependencies between tables. If you find any stored procedures, look up where they are called in the code. 
• Fun activity: find a well-tested class. Delete the class and re-implement it using only the tests as a guide. When all the tests pass, compare your code to the original.

Aubrey:

 

To introduce people to the new domain, I’ve seen a mix of personal browsing-the-code, guided walk-throughs, and general overview sessions take place.  In the last two cases, I think this has been most effective when the person being onboarded has contact and explanations from more than one source.  Just as each person has a certain learning style, each teacher has a certain style in conveying important information, and will focus on different aspects, even when giving a general overview.  

As far as resources to help onboarding, use of collaborative online tools to hold logins/ credentials, relevant documents to peruse, and contact information for talking to people with specific knowledge is great.  The tools I am most fond of, however, include Trello, a collaborative card-wall system I use to track things I’ve learned, problems I faced and may face again, tools I want to use that I’ve seen others using, and handy things I should remember.  As well, my very favorite tool that I think helps most with onboarding is literally a map of the land, a layout of how everything connects.  With the whole project structure laid out, it is easier to understand how each part interfaces with the whole, and domain-specific knowledge becomes easier to apply.  

Nikki:

I worked with a TWer that rolled on to our project and complained that we had not onboarded him thoroughly enough. Then when we got new people later on, he was very good at making sure that he took them through the system quite thoroughly so that they were in a better position than he had been. I was grateful that he improved the system, however my thoughts from this were (1) maybe he should have been asking more questions and (2) I don’t think that he ever succeeded in communicating about the culture - this could only be learned over time by just hanging around with the project members.

When I rolled on to my last project I paired with other BAs to test their stories, follow the steps that they had written in the acceptance criteria, and follow the steps in the automated tests. These things got me up to speed extremely quickly; it was a useful feedback for the stories as we discovered some things that had been missed; and I got to know the culture and the style of analysis that the team was following. BA pairing is good!

I would ask everyone to be able to quote the elevator pitch. Which means that we would have to have one in the first place. It would be nice if this was placed in the good news about delivery emails too!

Sarah:

So far the most effective onboarding I have seen is a quick introduction to the purpose of the project (elevator pitch style) and then introductions to everyone on the team along with what they do. After that, for devs, jumping in and pairing with people has worked out well. Although, so far the difference between whether or not they should be rotated or stay on the same story seems to have some contention. Thus far I would argue that rotating them through all the devs is a bonus since they see the system from many points of views as well as how their new team members work. By rotating them on to different stories, they should also be exposed to other team members’ work (BAs and QAs). Team activities during this initial period are also a huge boost for a good introduction to the team’s culture.

This all said, I believe the most important part is the quick explanation as to why the team is there. The rest can be picked up from being around and asking questions, but if the team as a whole does not have the same idea of purpose, it is easy to come off with the wrong impression.

Rebecca Sliter:

My thought process tends to mimic concentric circles, so I'll start with a microexample before expanding on the process :)

"What's your experience with [technology X]?" is  the best thing I've learned to ask my pairs. On my first long-running project, I considered myself such a n00b that I figured whoever I was pairing with had more experience with the task at hand than I. Not so. It's always good to figure out where your pair's coming from.

Asking, "what would you most like to improve?" and, of yourself, "what should *I* improve?" are questions I've been using lately. It gives the askee (a teammate or yourself) ownership of the improvement. Generally speaking, we do better work when we're personally motivated to do so.

I often try to gain confidence by understanding a single part of my project, be it a functional area of the codebase or the team dynamic. Once I've ramped myself up to that I can onboard others as well. Pay it forward!

The ability to teach the team something is a great indicator of onboarding progress. Sometimes this means speaking up during a retrospective to solve an issue on the team. Other times this could be holding a lunch and learn, driving a refactoring, or helping the team get up to speed with a new tool.

These are vague, less-technical suggestions, mostly because I've realized that learning how to learn is the most difficult part of starting a project, a new language, or a workflow. The strategies I've mentioned help me to focus my approach to self-learning and/or onboarding a teammate.

Mangalam Nandakumar:

Joining a team as a new member especially when the rest of the team has been working together for a while, can be quite challenging !! For a business analyst this can be a little more challenging having to understand the depth and breadth of a project in a rather short time, and with limited opportunity to pair !! 

The first thing I tell myself when joining a team is to not feel left out, and to try to not be daunted by all the jargons and friendly banter that the rest of team shares ! I keep reminding myself that it takes time to fit in (particularly if you are an introvert) and to just wait it out ! 

The next thing I do is to set realistic expectations for myself - if this is a long running project that I have just joined - I don't expect to be up and running in a week's time ! So I have conversations with the project manager, client principal (or anyone who sets expectations with the client about when I can  be billable) to set this straight and to get an idea of what the landscape looks like. 

As a business analyst probably replacing a BA already on the team, these conversations become very important - since they set the pace for how the transition and onboarding happen. 

All things being sorted out, I usually start by testing what has already been developed. This gives me a good wide perspective of what the project does, gives me time to try and play with some functionality, make notes and observations, and maybe even uncover some defects ! 

I take this as a foundation for further conversations and delve into an 'inquiry based learning' mode where I quickly gather information about what I need to know rather than learning everything about the project - and that speeds up my learning curve! 

The next best thing to testing, is to pair with the BA on writing some stories - I would like to jump into this as early as possible - since this helps me learn about what processes are followed on the team - how is the story structured? How involved is the client during this phase? Who in the team is involved in story kick-offs, etc. This again helps me ease into the team, and build relationships ! 

But there will be always be that one day, when teammates and the client will begin to trust you !!! That is the day you know you have been ‘immersed’ ! :) 

Abby Bangser:

While I do not think that there is a definitive best way to onboard, there are two topics that I have identified so far as important.

The first is to set expectations. While you may know that the new person coming on is supposed to be rewriting your build pipeline by week 2, they may not realize that expectation. Similarly if you are the person rolling on and you know that this is a new technology you are working with, try to identify timelines with your team for when you will be self-sufficient. This can get tricky if you are rolling on in a leadership position, but it if its possible it would allow a lot more free communication.

The second topic is that of fitting in quickly. This can be as small as following the trends for lunch or being assigned a desk, but can be as big as getting access to the code base and actually throwing points during an estimation. Often times people will delay getting code access since there is pairing anyways, or hold off on estimations because they do not yet know the process and standards. This is valid, but can also set up an even bigger hurdle to onboarding. The more time spent on explicit “onboarding” through paperwork and presentations the harder it is to explain why someone is still unfamiliar with the file structure of the project when they are one month in.

Finally, while the concept of “I don't know what I don’t know” is real, the person onboarding is the only one that can know their learning style. Speak up about what it is you need so that you can contribute, and ask for it!

Benefits of group blogging

Prompt: Does group blogging benefit you? Does it benefit your company? If so, how?

Rose:

Group blogging provides a forum that I find valuable. Having a somewhat regular prompt or a question to think about not only stimulates my brain to reflect, it also provides the opportunity to connect, converse, and empathize with others who respond to the same prompt. I think it’s a particularly useful way of staying in touch; the nature of our jobs at ThoughtWorks means at any given time we’re strewn across the country (sometimes the world), but having the blog keeps us united in a small but meaningful way. Cheesy but true!

Abby:

My biggest fear on being a part of a blog is whether or not anyone cares about what I have to say, and I can’t say this will ever get completely quelled. However, I find more and more that it is not about the many people who won’t find it valuable, but instead about the personal value I gain from the thought that goes into writing a post. I find both the personal reflection and the group conversations a chance to learn a lot about a new topic and my relation to it. I do obviously hope that some who read these posts find value in whatever way they qualify that, but even if its just that they formulate their own answer to the prompt in contrast to all of ours, that can round out the full reason for my participating in this blog.

Linda:

I think of the written word as a reference point, and enumerating ours externally improves the technology ecosystem in which we work by enriching the perspectives available to others' inquiry in our field. Also, as the people who spend a lot of time in the thick of things, our insights are fascinating and valuable to people who are concerned with this business, but not yet or not currently on-site.

Technical/industry blogging gives your admirers (and project managers, and yearly review participants) something to point at when saying "this person is awesome". It's an easily linkable, skimmable, and quotable source of brag and usefulness.

When I blog alone, I am a tiny voice with unfounded opinions in an uncaring wilderness. When we blog as a group, we're having a public discussion on interesting topic, with each of our posts adding value to the whole, and encouraging each other to meet our group post goals.

Bill K:

The reasons I show people the Agilistas blog are several. The obvious one is how great it is for a group of women to have a public presence in an overwhelmingly male industry. There is more to it, though. I know the authors. I watched the first wave of Agilistas join TW, and I know what adversity they had, how they bonded and supported one another, and how they did great work for our clients. To me it's a lot more than countering the image of the predominantly male industry. I'm proud to know them all and look forward to the day when they run the company!

I'm also proud that this first generation has passed the torch to another generation. Maybe that's not even the right way to say it. The current Agilista bloggers didn't need any prompting and took the initiative on their own.

I have shared this blog many times over the last few years. I know that other women in our company are happy to see it. It is still not common to have a group of women working together and blogging. Every time I've shared this link, people have responded to me by saying how happy they were to have received it.

I hope I haven't embarrassed any of you too much, but I am very proud to know you all and have you all in TW. You have made it a much better place.

Sarah:

Group blogging provides a regular forum of expression which is valuable. By providing a prompt, it gives a both a goal and a start of thought. These prompts may or may not be answered in a personal self-reflection irrespective of their value simply due to the chance one may not even think of it or believe it is a valuable thought.

It benefits the company by providing a place for people to have an exchange of thought which others can hopefully derive value from.