Dec 26
Starting a new job
icon1 Darrell Mozingo | icon2 Uncategorized | icon4 December 26th, 2016| icon3No Comments »

I started a new position with Skyscanner during the summer. It made me realise that over the years of starting new jobs, and of course being on teams when others joined, I’ve made and seen plenty of annoying mistakes that hurt relationships, trust, and respect with colleague  before they even had a change to form. I think this is especially true for senior engineers, where you come in with more experience and opinions, and perhaps more of a desire to “prove” your new role/salary. Here’s some tips that might help both yourself and your new team with on-boarding to the new job:

  1. Humility – You were hired in part because you’re good at your job, having the right set of experience and technical skills that the organisation needs. Don’t let it get to your head though. Remember that you’re going into this organisation in part to learn from some other smart people, and there’s a lot you’re not going to know. Perhaps certain ways of doing things from your last role are done differently & better here. This is particularly important if you were coming from a “big fish small pond” situation as I have a few times. That skill reset towards the bottom is the best way to learn, and I feel staying humble keeps you the most open to it.
  2. Don’t try changing everything day 1 – Sure, fix problems you see and make things better – it’s part of the reason you were hired. Just take a breather and don’t try to fix all the things on day 1! It’s part taking time to understand why things are in their current state or are done a certain way, and part building relationships/trust/respect with your new colleagues before going forward. Coming in on day 1 and trying to change a good chunk of things will put your colleagues on the defensive, making the possibility of introducing change that much harder.
  3. “Lightly” question everything – Similar to above, do question things. Don’t just assume things are already done the best way possible, but ask why they are that way. If you think it can be improved, don’t push back too much right away but take note and come back to it after a bit, when you’re more familiar with the team and system. Don’t push back on the decisions or your opinion too much right off the bat.
  4. Prime Directive – Taking a nod from the retrospective prime directive, I’ve found it the most conductive way to approach new systems/code/processes. It’s best to assume things were done for a valid reason in their given context, not maliciously. Our profession, the new business you’re at, personal skill levels, and most importantly technology itself, are constantly changing. What’s “correct” today in any of those areas are bound to be “incorrect” next week. Even the decisions you’ve made in the past for these areas probably seems like crap to you now. ORMs, WebForms, heavy handed message broker SOA… these were all valid & common decisions at different points in time. Maybe the system you’re coming onto didn’t implement these patterns perfectly, but did we always get it right ourselves? Rather than slag off the code or the anonymous author, try to realise that they were like you right now, trying to make the best decision in their context. Perhaps try to understand what those contexts were, then take it for what it is, and move on with improving things.
Jul 14
Retrospective tips
icon1 Darrell Mozingo | icon2 Uncategorized | icon4 July 14th, 2015| icon32 Comments »

My friend Jeremy wrote an excellent post about spicing up retrospectives. I started writing this up as a comment to post there but it got a little long, so thought I’d break it out as a blog post.

Jeremy’s experiences mirror mine exactly from running and participating in many retros over the years. Actively making sure they’re not getting routine and becoming an after thought is an absolute must. Here’s a few additional tips we use to run, spice up, and management retros:

  • Retro bag: We keep a small bag in the office filled with post-its, sharpies, markers, bluetack, etc, to make retro facilitator’s lives easier – they can just grab and go. We also have a print copy of Jeremy’s linked retr-o-mat in it.
  • Facilitator picker: A small internal app which lets team enter their retro info and randomly select someone to facilitate. It favours those who haven’t done one recently and are available for the needed time span. Sure saves on walking around and asking for a facilitator!
  • Cross-company retros: We’ve gotten great value out of doing larger cross-company retros after big projects. These are larger (upwards of 20 people) representing as many teams involved as possible (developers, systems, product owners, management, sales, client ops, etc). We used the mail box technique Jeremy mentioned and had attendees generate ideas beforehand to get everything in, limiting the retro to 1.5 hours. Making sure everyone knew the prime directive was also a must, as many hadn’t been involved in retro’s before. Actions that came out ended up being for future similar projects, and were assigned to a team to champion. Sure enough they came in very handy a few months later as we embarked on a similarly large project.
  • Retro ideas: (don’t remember were I got these, but they’re not original!)
    1. Only listing 3 of the good things that happened in a given period. At first I didn’t think focusing purely on the good would result in any actionable outcomes, but the perspective brought about some interesting ideas
    2. Making a “treasure map” of the retro time period, with some members adding a “mountain of tech debt”, “bog of infrastructure”, and “sunny beach of automation”. Fun take on the situation to get at new insights
    3. Amazon reviews of the period with a star rating and “customer feedback”
    4. I’m excited to try out story cubes at the next retro I run – sounds good!