I get involved in a lot of things around technology, especially with kids in Detroit. I love being able to help these kids not only see a future in technology for themselves, but to help them get there.
I became the Vice Chair of the Information Technology Pathway Advisory Board for Detroit Central High School in December of last year. In that role, I’m helping students at Central indirectly – mostly via finding learning opportunities, funding, and advising on curriculum.
A project the sophomores had from March centered around Autonomous and Electric Vehicles, and pulled in curriculum from Computer Programming, Chemistry, Geometry, Art, and Government. The students, in teams of 4, had a few tasks to complete, with the best team taking home some sweet prizes.

• Computer Programming – Students will assemble, program, and market an Autonomous Vehicle using Lego MindStorm.
• Chemistry – Students will investigate the pros and cons, efficiencies and inefficiencies, of using battery powered vehicles by assembling battery powered motors.
• Geometry and Art – Students will design and build a to scale city for test driving their autonomous vehicles.
• Government – form arguments for/against mock proposals supporting Autonomous and Electric Vehicles

The students had field trips to the M-City autonomous testing location in Ann Arbor and  the GM Battery Lab, and had industry experts join them in the classroom for Q&A.

All of this work culminated in a symposium, held last week. Students presented their work science-fair style, and all of the city blocks they built were placed in the center of the room where the cars were test-driven. Visitors were to go around to each team’s table, hear their arguments and observe their autonomous cars, and vote on who had the best car company, the best designed city block, the most persuasive presentation, and the best overall presentation.

I can’t tell you how impressive this was. These students are pretty amazing! They built the cars, did some programming on the fly, created brands for their cars, stood professionally at their tables and argued their cases. The big winners each got to take home a laptop!

I love working with this school, and feeling like I’m helping to make a difference for them. These students can see, from this symposium, that the community cares about their success, and wants the best for them. I can’t wait to see what we plan for next year!

This slideshow requires JavaScript.

In this video, the students were testing out their vehicles before it was “official” – obviously some reprogramming needed to happen for some! We’ve all been there, though! I reassured some students that I know exactly what it’s like when your code works one minute then it doesn’t as soon as someone else looks over your shoulder 😉

2017 was eventful, to say the least.

I submitted 8 talks to 6 conferences. I was accepted to 5 of those conferences, gave an extra talk at one of them I wasn’t planning on, and was invited to speak at another with a brand new talk. I spoke on life lessons at KalamazooX, making your QA your BFF at CodeStock and Desert Code Camp, and testing RESTful Web Services at CodeStock, Targeting Quality, StarWest, Desert Code Camp, and StarCanada. All of my talks can be found on my Talks page, by the way. I’m open to doing most of them, just ping me 😀

It was a very busy year for speaking, and I haven’t submitted talks to any conferences yet for 2018. I have some goals around talks for this year, including creating a workshop on REST testing and creating a talk worthy of a TestBash.

Late in the year, I changed teams – I went from being a QA Architect across 5 teams, to working directly with a single team as a sort of Software Engineer in Test. Going from architect to hands on is an interesting transition. Putting all of that theory into practice, and taking your own advice – this is another talk I’m thinking of giving soon. Lots of lessons learned, there.

I want to revamp this site, and blog more. I have a goal of blogging at least once per month. May not seem like much, but it’s more than I’m doing now! I mean, I did the HTTP Status Coop series but that wasn’t much blogging as much as creating images lol

I also took kind of a risk late last year when I contributed to the C# Advent Calendar. I had a lot of impostor syndrome about it – being QA and all. But I did it, and feel pretty ok about it! I got zero direct feedback, though lol lots of traffic to the post and the rest of my site, but no comments. I guess that’s better than negative comments!

I got involved in the community more, as well. I was nominated to Co-Chair of the Computer Programming Pathway Advisory Board of Detroit Central High School. In this position I’m working with the teachers in the school, helping them to build a curriculum that will get these students jobs out of high school, or ready for college.

I’m also trying to do more non-work stuff. Enjoying video games again (can’t get enough Goat Simulator and Minecraft right now!), having screen-free time, tinkering with some things. I’m actually participating in my company’s 24-hour hackathon this year, and I’m super excited to build something new and cool with 3D printed components and IoT!

So my goals for 2018:

• Create & submit a REST testing workshop to conferences
• Submit a talk to TestBash
• Do a talk on going from engineer -> architect -> engineer
• Make this site look less shitty
• Blog once a month at minimum
• Take more risks!
• Make a difference in the community
• Take time to recharge (on- and off-line)
• Build something fun

I recently tweeted for suggestions on books about self leadership, and leadership in general – especially books that personally helped people. I wasn’t looking for “I heard this book is great” but rather “this book helped me to become a better leader” etc.

I’m compiling the list here because I got a variety of suggestions in various tweets, and I want to have a definitive list when I go looking for books and not have to troll through my twitter mentions 😛 But also compiling here as it may help others!

Several people suggested Becoming a Technical Leader by Gerald Weinberg, along with Weinberg’s Secrets of Consulting, and Becoming a Change Artist. I should just read all of his books I guess…

One Minute Manager by Kenneth Blanchard and Spencer Johnson (blog post w/ suggestion here: http://qahiccupps.blogspot.co.uk/2014/09/the-sixty-second-team.html)

The Power of Servant Leadership by Robert Greenleaf

Tribal Leadership by David Logan (as well as the TED talk: https://www.ted.com/talks/david_logan_on_tribal_leadership?language=en)

And of course, Jim Holmes’ book The Leadership Journey – I read what he has so far, and am excited for him to finish it (nudge nudge)!

Thanks to @spectacledbear, @qahiccupps, @jessclancaster, @codebully, and @pkirkham for their suggestions!

Storified here: https://storify.com/g33klady/agile-and-beyond-2015-recap

Please forgive the giant image at the top – I can’t find a way to change it 😦

It’s a loooooong post, a couple hundred tweets, so be prepared!

As my CEO has said, it’s ok to fail as long as you learn from it. So I’m analyzing this gigantic failure to try to get as much knowledge from it as possible. I don’t want to fail this hard again…

Let me start from the beginning of this wonderful lesson. I was asked to lead a project team for Ann Arbor GiveCamp. In case you haven’t read all of my posts on GiveCamp, it’s a weekend-long event where technical volunteers come together to help non-profit organizations. Generally the volunteers give just their weekend and walk away from the event with no obligations.

I hadn’t lead a project team before, but someone had to step up so we could help more non-profits. So I stepped up.

Failure 1: I didn’t ask anyone for advice on handling a project at GiveCamp. I know plenty of folks that have run successful projects at past GiveCamps, but I figured “I’ve got this, I’ve done enough GiveCamps.”
Lesson 1: Nope, you don’t “got this”. Ask for advice, ask for lessons learned. Ask folks that have lead teams before what do they wish they had done differently.

I got my project prior to GiveCamp like most leaders, read through what the non-profit wanted, and had a phone meeting with the non-profit rep. I had a good general idea of what needed to be done.
Failure 2: I didn’t get specific enough.
Lesson 2: Get specific details. Get the Trello board set up prior to GiveCamp. Lay out all of the work that needs to be done – Every. Single. Bit of work. Lay out the must-haves and the nice-to-haves and make sure that the non-profit agrees with everything.

I met my team on the first day of GiveCamp. After the opening ceremonies (I was trying to help as an organizer at this point, getting people to the ceremony location, etc.), my team gathered. I had us all say our names, and what we do.
Failure 3: I didn’t know my team well enough. There just isn’t enough time to get to know everyone – their strengths, weaknesses, what they can and can’t do, what they will and won’t do.
Lesson 3: Try to glean as much from each person as you can. Not just what they do for a living, but all of the above – what they can/can’t/will/won’t do. Express the importance of honesty and openness on the team – if you can’t do something (or don’t want to), let us all know so that someone can. Also, understand everyone’s schedule – some folks are only there for the first night, and rather than finding that out just when they’re about to leave and they could have been doing something much more important or helpful, get everyone’s schedule out in the open at the beginning.
Underline the importance of all of the work getting done – no room for laziness. This is for the non-profit, not for your resume.

We had a trello board with a general list of things that needed doing – each card had a checklist on it of the various things that each item needed to be done to make that thing “done”.
Failure 4: Oh man the disorganization. Not everything was on the board. Not everything was in each card. Not everyone was using it properly.
Lesson 4: Definitely need a better way to track work. Getting the board up and populated before GiveCamp would have been helpful here. Rather than having checklists, have a card for *everything* that needed to be done, including testing. And make sure everyone is using it! Check in every hour to see what’s in the Done column, what’s assigned to who, make sure we’re not spinning our wheels. Hell, maybe have a team standup every hour or so.

We find out, late Saturday, that there’s a bug in the checkout page of the store on the site we’re working on.
It’s a critical bug, we can’t go live with it.
Failure 5: It took far too long to find the bug. Why?
Lesson 5: Work, and more importantly testing, wasn’t defined properly. The site was being tested but from a user that was already logged in to WordPress – but most of the end-users of this site won’t be. And that’s where the bug was.
The person who was responsible for it said they were too lazy to set up a PayPal developer account in order to test checkout and donation (or to find out if someone else had one and ask them to test it). I didn’t flip out on this person, smacking them and telling them that if they want to be lazy get the fuck out of GiveCamp, this isn’t for lazy people this is to help a fucking charity, stop being an asshole and help for fuck’s sake. I didn’t flip out on them, but I should have. It’s inexcusable, and as a leader I shouldn’t just roll my eyes and try to pick up the slack, which is what I did. Part of that is my social anxiety/not wanting conflict thing.

We keep getting the rest of the stuff done, still trying to find the cause of the bug and trying to fix it off and on.
Failure 6: We needed a plan B sooner. But we kept spinning our wheels. And subequently, myself and one of the members of the team (who volunteered to do this) kept trying, off and on, to fix it for several weeks after. It was determined that the theme was the cause of the bug, so this other person rebuilt the theme from the ground up. For several more weeks, off and on, we tried to get this new site back to the non profit’s specifications.
Lesson 6: Be more agile – if it’s not working, fucking fix it. Ask for help during the standups. I let it get drawn out for weeks and weeks and weeks. I had suggested we go live with the site without the store, while we try to fix that bug. The non-profit didn’t want to do that. The store was integral.

Finally, months later, the non-profit asks for all of the files we have. They have to pay for someone to finish it, they can’t wait for us anymore. They need the store up and running to generate revenue.
When I get this email, I’m devastated. I knew this was coming – how could it not? We couldn’t keep spinning our wheels forever. I should be relieved, that this isn’t on me anymore. But I’m not. I’m angry with myself for leading the project so poorly. For failing so hard.
I thought that writing this out, walking through all of the lessons I’ve learned in this, would help me to work through the pain of failure. To put a positive spin on it – “hey, look, I’ve gotten better through this!”

I’m not sure that it’s helped me work through the pain of failure, but at least I know what I can do better next time, and how to not fail at GiveCamp again.

Note: I’m not going to address the “QA” terminology thing here – we call our software testers “QA” where I work, but this isn’t about that. Sorry – we can talk about it later 😀

On Tuesday, I started my first day in my new position as an “SQA Architect” at Quicken Loans – moving from an Engineer position. What that means where I work is that my focus is on:

• assisting project teams in determining processes, procedures, and standards around quality
• mentoring and training any team member on testing-related stuff (tools or even the basic “agile testing 101”)
• building the “quality” community

Essentially, that whole “rising tides raise all boats”, and I’m helping to raise the tide of quality.

I’m very lucky to work where I do, because my team leader encouraged me to go after what I wanted. I was willing to compromise a bit, and wait until we had some testing support on the team. I am very thankful to Joe Guadagno for his continued support in being an awesome leader, and good friend. It’s not a rare thing there, and why I think I’ll be there for the long haul – lots of support, and you can really write your own ticket to success.

As our CIO said today at our holiday party, don’t be the thing that’s getting in the way of your own success.

So I’m not! Here’s to an awesome new year ahead with many opportunities to exceed our own expectations!