Book Reflection - Hack Your Bureaucracy

Hack Your Bureaucracy - Marina Nitze and Nick Sinai

I added this book to my to-read list after hearing Marina do an interview about it on the You are Not So Smart podcast.  I could hear in Marina’s voice that she is passionate about her work and getting things done, and she had a few stories of where she creatively solved problems.  One of those people who seems like a good professional influence.  

The authors both worked in federal US government tech, but they clarify at the beginning that “bureaucracy’ doesn’t necessarily mean something that’s intended to be bulky or onerous, or even something that is as large as a government bureaucracy.  It can be any process of documentation or approvals.  And not all bureaucracies need to be hacked. 

The book is put together as a series of tactics to consider as you think about how things get done in your organization  Major themes include: 

Seek to Understand and Don’t Be a Know it All - The first set is basically about understanding why things are the way they are.  Ask questions in a curious and non-judgmental way.  If you walk into an organization and things just seem messy, don’t assume your new coworkers are idiots.  Don’t ask why don’t you “just” simplify things?  (“Just” has been one of my long standing pet peeves).  Don’t assume every process is stupid - sometimes they have been set up for legitimate reasons we don’t know yet. 

Act in Good Faith - If you decide that your organization is unnecessarily resistant to implementing a good idea, be careful how to proceed.  It’s not about winning, it’s about gaining support and buy-in for a future.  Show the journey, demonstrate the benefits. Once the vision is there, you may have sponsors help you navigate that you didn’t have before.   

Initiative Goes a Long Way - When crises like a global pandemic arise, old rules may clearly not apply any longer.  The risk equations may be different, or other assumptions may no longer be valid.  In these cases, you can use your creativity and expertise to suggest new optimized processes or introduce new tools.  Once it sounds like “oh, we’re going to need a policy for this” - offer to write the first draft yourself to raise the bar for adding unnecessary clauses 

 I felt really validated by this book. I’m a geek about processes, both setting them up and continually evaluating their usefulness.  I get passionate about ideas I’d like to try implementing and I get intensely frustrated at times when I can’t make them happen immediately.  This passion is not a character flaw and I’m not alone in having it.  But I do have a choice in the battles I fight and how to channel this energy to maximize the likelihood of success.

Book Reflection - Four Thousand Weeks: Time Management for Mortals

 I just finished a book - Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman.  It was time well spent - see what I did there?

I related to it quite a bit - it largely assumed an audience of people who are averse to being idle.  People trying to optimize their way to self-worth and counting their days and hours by what still remains on the to-do list that includes such meaty goals as  “save democracy” and “learn all the programming languages”.   Those of us who never feel like they’ve “earned” a break, who only slow down when they have a documented illness and only then because they don’t want to do something silly like get hospitalized where you REALLY couldn’t get anything done. 

My main takeaways from the book are: 

1.  We can’t do everything.  As the title suggests, we will die.  Instead of trying to fit it all in, just work on accepting this.  Of course, this is something I’ve known forever with my brain but doesn’t seem to be absorbed by all of my cells as truth.   So I’ve been trying to work on this, mostly in the case of places to visit, things to learn, or hobbies to start.  I grieve each thing as I consider it and know that probably won’t be able to do it.  I sit with the thought, appreciate the fact that I appreciate that it’s something cool, grieve a little bit that one day I will die and then try to settle my mind back to a shorter list of equally cool things rather than continue in the grief/disappointment space.

2. Don’t spend too much time choosing - don’t let the perfect be the enemy of the good.  A short note you actually send telling someone you think they do awesome work is better than the perfect letter you never write.  This is, again, true because one day we will die.  Or the other person will die. 

3. Be mindful of how we are spending our time - Make sure you are making conscious choices and not continually scrolling on our phones, especially about things that bum us out and sap us of the energy that we could be using to do the things that actually could make the world less of a bummer.   The sum of our individual moments of attention will eventually be our life lived.  

The book was humbling and comforting and empowering.  I gave it 5 stars on Goodreads and will likely think of it often.  

Three Voices, Four Lessons, Fifteen Years

I wrote down a few “lessons learned” a few months ago when I hit my 15 year anniversary with the Statistica product (working for companies StatSoft, Dell, Quest, and TIBCO along the way).

I put off finishing it and publishing it because a voice in my head said there are more important things going on in the world than navel-gazing about my career. But then a competing voice says "You can't be a thought leader unless you have thoughts, and you know, tell them to people". Fair point, says Voice 1. Voice 3 says "What's all this 'thought leader' business? What happened to you?" Voice 1 and 2 do a jaunty PowerPoint about building our personal brand.  Voice 3 rolls her darkly lined eyes and hits "Publish"

***********************************

Takeaways from 15 Years of Working with Statistica

You have to create your own boundaries.  Unlike a restaurant when you go home when the dishes are clean and the floors are swept, software development work is literally never done.  Know when you’ve done enough for the day.  Make sure you’re taking care of yourself.  Burning out helps no one.  

Sometimes you can create your own opportunities - No one has more incentive to make sure you’re doing what you want to do than you do.  If you see a way you can add value in a different department that’s more interesting to you, have a couple of conversations and make a plan.  Chances are, they’ll want to keep you, even in a different capacity, rather than lose you to a competitor. 

Keep an eye on the market.  I’ve seen many amazing people let go just because the business is changing directions.  Even if you are in love with your current job, periodically choose a “next best alternative” that you would pursue if your job went away.  Skill up in these areas.  

Keep in touch with people - Your coworkers are a little like siblings.  You spent time under the same roof (or virtual roof these days), living through events, sometimes traumatic, sometimes hilarious.  They knew you when you were young and inexperienced and did their best to protect you and support you through your awkward phases. They watched wistfully as you became the teacher buddy to new hires, the way they had done for you what seemed like yesterday.   They looked up to you, while you hope that they don’t see the terror that you still have no idea what you’re doing, except that you do, but you also know the depths of what you don’t know.   With every interaction, we shape one another into the professionals we become years down the line.  They’re as much family as anyone you eat Thanksgiving dinner with. 

I don’t have a witty conclusion planned, as I am still very much in the process of learning more lessons.

We Can Stop Producing Bad Apples

"There are a few bad apples" - We hear over and over again from people in power.  It's said with the intention of ending the conversation and not going deeper.

Where is our pride?  Where is our curiosity?  Where is the drive and challenge to make things better instead of justifying how things are?

If Honda Odysseys exploded every now and then at a steady rate, would we say, oh wow, those are a few bad Odysseys out there. Shrug. 

No.  We would be mad as hell. 

Manufacturers know we would be mad as hell. That's why they deal with their processes in a reflective manner - if something goes wrong...they can drill down and solve it. 

Bad apples are a symptom, not an inevitable outcome. 

We attempt to solve "bad apple production" in business -- process analysis, lean manufacturing, five-whys, "shifting left" in software/application production.   Judging by the number of conferences I get invited to and the amount of marketing material I receive, this is a huge industry. 

Essentially the idea is to study problems, patterns, and prevention.  What inputs are causing the bad apples?  Is there an interaction of factors most likely to produce the bad apples?  How long can bad apples be out in the world being bad apples before they are realized as bad?  What happens when we suspect an apple is bad?   What can we change to keep bad apples far away from hurting people? 

The goal is continuous improvement.  Reflection, learning, adjustment. 

There's nothing in these methods about digging in your heels, defending the processes that were optimized for one outcome (protection of White people) when it turns out we need to optimize on a different outcome (protection for All)....Nothing about shrugging and accepting your high bad apple production rate. 

So why are we seeing this behavior in public policy matters?  What's the difference?  

So far, enough of us haven't been mad as hell. My hope is that we are getting there. 

Get mad.  Stay mad. 

Purpose Brainstorming

I hadn't researched Dan Buettner's Ted Talk to figure out whether he was appropriating or appropriately celebrating the Japanese concept of "ikigai" - basically a reason to get up in the morning - an overlapping of where your interests and talents intersect with the world's needs. Until today, when I searched and saw some evidence that it was an oversimplification of a complex concept...of course.

But I'll link to it anyway, since I found it to be a useful construct to inspire thinking.

Time has flown.  Y2K seems very recent and it was freaking 20 years ago. I was a sophomore in college.  Taking interesting courses in public policy, economics, psychology.  Serving in Student Congress.  Working in a psychology lab.  It was a busy time, but also one filled with hope and possibility.

But soon, I would become more realistic/pessimistic/jaded....or maybe it was lazy.

I was so burned out on school, that I didn't want to go to grad school until I felt called to do a specific something.  My interests were and have continually been so varied that focusing on anything in particular seemed like a waste.

I worked in DC for a summer - I enjoyed the experience but learned how much governing was a team sport - you picked your Republican or Democrat side and modified your thinking and behavior accordingly.

City planning/economic development/government seemed the same in many ways - you compete with other cities for limited resources, luring companies into your town, where it may or may not be the best thing for the residents.

If I were in college today, what would my plans be?  Hard to say that I would have done anything different, besides adding computer science and more math into the mix.

As I reflect toward the end of the year, because it takes a certain amount of calm and rest to think about the higher rungs of the hierarchy of needs, I have been thinking about purpose.

What I Like

• Mostly listed above - social sciences, ethics, philosophy 
• Technology and math, not for its own sake but for advancing something else that I care about 
• Watching something work that I made
• Standing up for others who aren't being listened to 
• Writing 

What I'm Good At

• Problem solving/isolation - experimental design 
• Thinking of things that can go wrong 
• Moving things forward
• Chaos minimization
• Googling and trial and error 
• Learning from the past 
• Writing

What I Can Get Paid For

• It's irritating that the best-paid jobs are largely BS and that the jobs that have the greatest positive impact on people are lower-paid.

What the World Needs

• Critical thinking
• Recognition of patterns
• Civic engagement
• Willingness to take a stand for principles 
• Connection 
• Engaging education 
• Hope 

No real common themes here, but perhaps I am blind. 

• Writing about unintended consequences for public policies? 
• Work on technology that makes education more engaging or otherwise promotes a healthy democracy? 
• Run for office for the sole purpose of saying the things that need to be said, drawing from history? 
• Organize some small groups for people who need connection?
• Work on technology and the underlying organization that helps people get resources they need to make their lives better - mental health services, in-home care, etc - any process that's difficult to navigate? 

Routine: Living resiliently

I love routine.  I have a system that keeps me sane. Much of my work and home life is structured by Yanado tasks linked with my work and personal Google accounts.  Things I need to do all go there. Things I want to do go there too.

My personal list of tasks helps me keep in touch with my friends, keep my dogs correctly medicated, keeps me learning, keeps me volunteering, keeps me exercising.  My work list of tasks does the same thing - it reminds me of the commitments I've made to others on the team, keeps long term goals in my view, and helps me respond to emails in an order reflecting their importance.

And then things happen to throw off the routine.  We get sick...we get a new puppy who requires newborn baby levels of attention...we get in a car accident and have to take it easy and find time to buy a new car, we get an emergency high-priority issue at work.

While my routine was thrown off over Christmas, I had extra time to read. I read Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal .  It had some useful leadership lessons and also introduced me to a distinction I hadn't been consciously aware of - robustness vs. resilience.  Robustness is strength to withstand obstacles...Resilience is the ability to adapt as obstacles arise and evolve.

This year, I've seen a change in vocabulary around New Year's Eve -- Intentions rather than Resolutions.  The thought being that once you've broken a resolution (e.g. I resolve to floss every night) then it's done; there's no point in continuing.  You can always return to an intention (I intend to floss more this year).  Perhaps a more resilient approach to behavior change.

Watching my mom, who is now retired, go about her new life is inspiring.  She's playing piano and spending a lot of time with genealogy. It led to the table topic style question when I visited this weekend - "what would I do with unlimited time/money"

Photo credit: Taylor Maley

Piano.  Singing.  Auditing university classes. Dancing.  Scanning all the photos I have only hard copies of.  Ping pong.  Bowling. Writing. Reading.  Cross-stitching.  Run for office and use it as a public forum for ranting Network-style if it becomes clear I won't win, steer philosophical discussions on the role of AI in our daily lives.


I'm not going to be able to do all this at once. And that doesn't make me a failure.  I can use tools to keep my family/spiritual/social/professional/physical goals in front of me.  Eliminate junk.  Use Facebook just enough to keep up with the big news of my real-life friends.  Don't overthink; pick something that's fine and stick with it.  Don't get sucked into drama.  Re-route myself to a goal/intention that I've found to be important. 

At the moment, these goals/intentions are growth (learning skills or facts/concepts that grow new neural pathways), connection with fellow humans (and dogs, I suppose), and reduction of blood pressure. 

Happy 2019!

Tulsa Techfest 2018 - DevOps and Drive Thrus

On July 20, Tulsa TechFest was held at OSU-Tulsa.

There were 16 different tracks of and four different session plus a keynote plus lunch.  Not bad for a free conference in town.

The themes of the day seemed to be C#, Agile, Feature Flags, and AI.

Image Credit: Marc Carlson

The keynote was given by Donovan Brown, DevOps guru at Microsoft.  It was inspiring, despite the fact that he was super excited about their move to fire / transfer to other areas within Microsoft their manual QA team for their VSTS project.  However he did clarify that it was a special case, that the team itself was both a subject matter expert on the product and acting as end users before doing a controlled rollout to concentric circles of customers, who are presumably more and more risk averse as you move outward.

He spoke about automating all of the things, focusing on the most offensive bottlenecks first, letting developers bear the burden of whatever bad code they write, both by being responsible for automating their own tests and taking the 3am phone calls when something blows up in production.

It resembled heavily the recent discussions on Modern Testing, specifically the reduction of using QA as a safety net to enable less-than-careful behavior from developers and identification/removal of bottlenecks. 

My top takeaways now that I've had a day to process.

1) Ed Eckenstein had the same experience I had with someone cutting them off at the McDonald's double drive through.  Though, as he's done a lot of work with coaching on mindfulness, connection, and gratitude since his survival of the Oklahoma City bombing, he had a better spin on his drive-through experience.  "What is the kindest interpretation of this behavior?" -- which is an interesting thought exercise.  I bet his McDonald's opponent didn't get out of their car and start cursing at him with two children in earshot...so my grudge-holding doesn't seem quite so petty.  Though his point was indeed well taken for all non-fast food related matters.

2) Even if developers write the highest-quality code to the best of their ability, QA provides value acting as subject matter experts.  Donovan Brown said if his team were writing software for truckers, they would for sure still have some manual QA around.

3) I don't like the term "manual QA", which seems to me to be the label for anyone whose eyes see the software without the sole purpose of creating a script --   What's a better term that doesn't make us sound like early primates happily clicking their keyboards randomly...Subject Matter Engineers?  Air Traffic Control? Pre-Crime Investigators?

4) Continuous improvement is a team effort.  We have to support one another, both to promote a connected, low-stress working environment and to encourage experimentation. Getting better doesn't always work out on the first try.

30 Days of Automation in Testing - #1 & #2

Organized by the Ministry of Testing.

1 Look up some definitions for ʻAutomationʼ, compare them against definitions for ʻTest Automationʼ.

I googled a bit and found a nice rant that is probably not completely relevant here since it has to do with the testing vs. checking distinction.  I found the regression testing as a form of version control point interesting.  Regression testing is table stakes - it needs to be done, it's boring and time consuming.  Automate it.

Call it a check if the person you're talking with cares about the distinction. Call it a check if the acceptance criteria of creating an automated regression check is a clear programming task and it doesn't need a tester mindset to ensure that it was created correctly.  Once it's coded and checks what it's supposed to check, then and only then shall we call it a check.  But ensuring that the check checks what it's supposed to check, either with clear acceptance criteria or by double checking the check....that's a testing activity.

My thoughts on automation in general are to use whatever makes your job easier or less boring.  Don't turn off your brain just yet though.  You have to know what your automation is DOING.

The tool may be making pretty graphs and tables of load test results, but don't trust the numbers unless you know that it's really timing what you intend it to be timing.

Know whether your checks are passing because your software is still awesome or because the logic of your test code is always "everything's fine!"

2 Begin reading an automation related book and share something youʼve learnt by day 30.

I have a work project going on related to JMeter, so why not Performance Testing with JMeter 3 - Third Edition?  I'm an ACM member with benefits to use the OReilly/Safari/Packt collection of books, so I won't lose any money at least :-)

Stop Your Bottlenecking!

Management is probably the biggest challenge I've ever experienced.  I feel like I'm responsible for so many things but in direct control of almost nothing.  I have so many ideas that I sometimes wake up in an energetic frenzy in the middle of the night, but sadly not a lot of time to move them forward.  There are times when I feel like my team's work is stuck, and I'm the reason why. 

Some ideas to address this:

Image Credit: Ralf Steinberger, Flickr Creative Commons Attribution License

Being honest with myself about how much work I can do.  We use JIRA to plan our development-related work as an engineering team.  I can do about ten points of non-management work in a two-week sprint. But I want to do more than ten points worth of stuff.  So I think I have been underestimating point values in an effort to enable myself to take ownership of more tasks than I should - e.g. referring to what should truly be a 3 point task as a 1 point task. Saying I can do 10 points of stuff that's really more like 20 or 25 has contributed to taking too much on and unfairly inhibiting people who are dependent on these tasks getting done. 

Being honest with my team about how much work I can do:  I confessed on a project slack channel that I was a bottleneck.  I said if we wanted the project to move faster than I was moving it that I would need to have help with some specific tasks. And now we have a hack-hour scheduled next week where we'll attack the problem together. 

Being less responsive Several times a week, someone posts to our slack channel a quirky problem with the software or with our internal infrastructure that I want to help them figure out.  I love troubleshooting and problem-solving.  But it can also be a distraction from larger goals that I need to be spending my time on instead.  If it's an important thing that really needs to be figured out, making a note to revisit the question in an hour or so is probably a good approach.  Chances are that in that hour, someone else has probably jumped in to help without my having to spend time on it.  I've given someone else the opportunity to experience the thrill of helping to solve a problem, and spent that time on a less urgent but equally important team goal.

Is it really that bad?  I have notoriously high expectations of myself and if there's any way I can judge myself as not being good enough, that will be my takeaway.  I am probably doing at least an average job, even when I think I suck.  A concrete list of things that do get done can help me see this more objectively.

Defining Expectations

Asking for what I want has never been easy.  More accurately, defining and articulating what I want TO MYSELF has never been easy.  Which, as a manager, is problematic.

As I reflect, I see this as a two-pronged problem to examine. 

• Combining my knowledge and skills and creativity with my team's knowledge, skills, and creativity to come up with a vision and priorities, and breaking these down to general goals for experienced team members, and helping break the goals down even further for newer team members (Defining what to do) 
• General behaviors/attitudes that I see as useful in many situations (Defining how to be) 

What To Do 

It seems the ideal I need to work toward is to know when to give someone a lump of clay and the time to make a statue...or when to give someone a more paint-by-numbers task.  I don't want to rob someone capable of grand things of the opportunity to be creative, nor do I want to overwhelm a new team member who is still developing their skills and intuition.  This will vary person to person and task to task. 

How to Be

This blog post was inspired by thinking about this observation -- that what I expect and value in my team members is largely the same as what I value in my friendships.  And these expectations are largely invisible to me, and even more so to those I interact with.  Some of them are merely personal preferences rather than universal goods, which, sadly puts me on a better footing as a default with those who are most similar to me in background. 

As a first step I want to inventory the personal traits and behaviors that I value. The next step will be recognizing where there are different but equally valuable ways of behaving  & approaching work and being able to evaluate what I'm seeing in this light 

• Initiative - I value when people are able to see or anticipate and problem and take the next logical steps to solving it, as their experience allows.  They feel ownership of the product or the situation and take action without having to be asked. 
• Independence - I value when people try to do things on their own first (via experimentation or Googling) but, wait, wait, wait...DON'T go overboard.  Ask for help if your own research is coming up short or it is a time critical task.  
• Curiosity and drive -- I value the compulsive need to dig deeper to find the root cause of an issue or to explore an area of the software that seems "off" to them that day....but, wait, wait, wait, DON'T go overboard focusing on details that don't matter. 
• Flexibility - I value when people are able to change course and refocus their attention when circumstances require it

I am sure there are more, but this is a good starting point.  I can already see evidence of some rigidity in my thinking (even though I supposedly value Flexibility) that I can start working on being more mindful of increasing my range of comfort in others' behavior. 

Four Days Left to Totally Crush 2017

As I gaze beyond my laptop at work, Skeletor looks at me and says "Progress, not perfection".

There are only so many hours in the day and there are many things I care about.  I can't be perfect at all of them or any of them.

Our "free" time is a reflection of our values.  Our time at work can be too, depending on how much autonomy we are allowed.

Image credit: jcsullivan24

I'm the type of person who appreciates the heck out of a sunset, sunrise, moonset, moonrises, pretty cloud formations, bright red trees in the fall.  I'll just go and stare at the sky like an idiot, but that's who I am.  My dog Paddy is almost 17, and yeah, you bet she's getting a belly rub or ear rub if she asks for it no matter what else is going on.

Make time to read.  Make time to sleep.  Make time to just sit on the couch under a blanket with your kid.  Put down your phone and listen when your spouse is talking about something that's important to them.  Make time to learn.  Make time to write.  Make time to check in with friends.  Make time to keep your heart and lungs healthy.  Make time to take care of your surroundings if the clutter is a distraction.   Buy time if you can - pay a neighbor kid to mow your lawn...order your groceries online instead of meandering through aisles (unless grocery shopping to you is like a breathtaking moonrise for me -- whatever works).  Dispose of traditions that don't matter to you.  Reframe that stressful wait in traffic into an opportunity to listen to a podcast or audiobook.

To whatever extent we can control our time, we can approach it with the goal of making progress toward being a better whatever-role-is-important-to-us-right-now.

Takeaways from Presenting at my First Career Fair

I responded to a generic Facebook call for people who were interested in sharing their careers with Booker T. Washington High School students.  Let me know if you need anybody to cover areas related to software, statistics, and/or management, I said.  

So that's how I came to be one of three computer science panelists for a few dozen students who selected that career area. 

There were a few prepared questions that I had thought about over the course of the week leading up to the career fair.  I reflected on my career so far, which started out less as a plan and more as a series of things that just kind of happened.  I like these Economics courses, I'll keep taking them.  There's a job opportunity in Tulsa working for people I already know and like, sure.  

Image Credit: Yixler

If I didn't like where things were going I'd make adjustments to change course.  I didn't want to appraise or analyze the commercial real estate market forever, so I took some night classes in programming.  I didn't want to answer tech support questions forever, so I made my preference for being a full time QA person known to the right people in the company.  

So I spoke less of "follow your dreams" and more of  "stay open to your dream changing".  Always keep learning and adjusting based on how the world changes and how you feel about it. 

I brought what I think was a different perspective.  My two fellow panelists were, what I would call, "traditional" computer science people.  Males who had been tinkering with electronics since they could remember and who spend all of their waking hours either programming at work or programming for fun.   Nothing negative meant by this; they seem happy, and there appeared to be a cohort of young men in the classroom already playing out this role and eager to take the next steps of pursuing computer-related careers professionally.  

But I wore a bright pink shirt.  I said I entered college knowing I was vaguely interested in numbers and setting up web pages and how the world worked in general. I leave work at 5:15pm so I can make pickup at my daughter's aftercare, and I engage with my family or other parts of the world or yes, maybe keep working on computer-related problems if I feel like it that day.  I took a public policy angle on technology, saying that the field needs people who care *where* technology is going- summarizing the takeaways of a book I recently read, Life 3.0: Being Human in the Age of Artificial Intelligence by Max Tegmark.  People who think about ethics and how we can make sure that technology is working for us and with us humans instead of against us.  I talked with expressiveness and passion for all types of knowledge.  

Retroactively, one could assume my goal was to reach analytical, passionate people who had missed the "tinkering since toddlerhood" window or to whom programming 24/7 forever doesn't appeal and encouraging them to seek out a spot at the table anyway.  Reassuring them that I'll be there in the crowded cafeteria with my bright pink shirt, waving them over to the geeks' table, pointing out the free chair. 

Show up and Engage

Photo Credit: Jacob Earl: https://flic.kr/p/Tuasqx

The podcast DecodeDC had an episode about the success of the National Rifle Association.  Essentially, it comes down to their membership showing up and being engaged. Regardless of what you think of how they use their power, it was a good reminder of the value of loud, consistent voices no matter the number.  

They pay attention and are willing to raise a fuss.  It works. 

It's easy, and in fact tempting, to be apathetic.  "The legislature is never going to change...My vote doesn't matter...They've already chosen the actress for the lead role...Those people are so much smarter than I am, why even show up?"

We have to anyway.  Once we give up on the idea that improvement in our lives, workplaces, communities, and society is impossible, then the light that makes life worth living dims and fades to black.  

So continue to talk about what is important to you.  Research ways to work around or erode obstacles. Gather with others to discuss what the ideal future looks like.  Learn about people and history and economics and technology.  Learn how to be an effective communicator and advocate.   Show up, full of energy, ready to make the next step forward, even if it's small.  Or even to stand, strong and resolute with pride, to prevent further losses.  Because if you don't continually show up and remind everyone of what's important, then over time, people may start to forget that it *is* important. 

More on the Future of Testing

"As service providers we are adapting to the reality of our teams, and this means a number of different things. For example:
– I see that testers are doing a lot more automation and in different levels within their projects. We are writing all sort of scripts to help the development process, working with multiple automation technologies, and using automation to help us do our tasks faster.
– I also see many more testers going deeper into the technical work of their teams. This is further than automation, going into the logs of the product and sometimes even reviewing the actual code while looking for issues.
– In some cases, and in some organizations, I am seeing how testers are doing more work with production environments, doing A/B testing in live features and becoming data scientist and DevOps alchemists within their teams." - Joel Montvelisky

In addition to "ninja" and "scrappy"..."alchemist" is a good descriptor to aim for professionally.

Future-Proofing Your Career

As an experienced software tester and a naturally anxious person, I frequently don't feel safe unless I've thought through all of the potential disasters that can occur and mitigate risks of those occurring to the extent possible.

One such disaster would be job loss.  The mitigation for this is to prepare for the job I'd want to get if I had to get a new one.  This is a tough question for me, since I love literally about 95% of my current job. 

But thinking ahead, what are my skills, what do I *like* to do, what does the world need more of from an ethical/moral perspective, where is there going to be a good availability of jobs but not an overabundance of people training for them already?   

Unfortunately, I don't see a lot of growth in the role of software testing as a full time career path, although testing as an activity/mindset will still be needed.  In the six-year-old linked video, James Whittaker points out many demoralizing but logical reasons that we should not be too comfortable with our current skills and approaches.  We need to stay hungry....change or die. 

So what's next? I see a lot of "Should testers learn to code?" discussions out there -- I absolutely don't see why that's a question.  When there's a choice between learning a thing and not learning a thing...always learn the thing!  

I like programming and LOVE the addictive thrill of solving a problem with code.  Though counting on it as a career move, I am not sure how to jump my perception of a chasm between learning the basics and becoming a competent, ready-to-employ developer.  It seems like everyone currently employed as a developer has knowledge of optimization, the ins and outs of multithreading, all the tools, and thorough knowledge of the past and future of computers. It may also be my perception that others are more competent than they actually are...Or I'm actually more competent than I perceive myself.

Additionally, I love isolating problems and breaking them down to core components, experimental design, thinking about thinking, juggling multiple priorities, seeing multiple steps ahead. 

I have PLENTY to learn as a manager. My biggest strength as a manager is awareness of how much I have to learn, such as delegating and teaching and knowing whether to "help" or back off.

Luckily, identifying and enhancing the skills that would help me get a NEW job if I needed one may also assist in keeping me employed in a role that is evolving into something new, and dare I say, exciting. 

Burnout: Turning down the flames

The best advice I've read about working extra hours is to "Be a volunteer, not a victim" from Lessons Learned in Software Testing.

I thought I was doing that. But apparently working is a lot like eating; you can only prevent a bad outcome if you stop BEFORE you think you should.

I have experience with burnout; ten years ago, oh man...that was quite a project.  So many long days and weekends, all for an impossible goal.  The lesson learned from it was that no one is going to stop by and pat me on the head and tell me to go home.  I have to take charge of my schedule and life.

Therefore even though it was a project of similar importance, I had actually been treating myself pretty kindly, only working when I had nothing better to do.  I didn't miss any school events for my kid, and I was generally there for my family when it mattered.

But in reality, I was working instead of exercising.  Working instead of *finding* something better to do.

Then when earlier this week, one...two...then three things don't go to plan...I lacked the reserve of patience & understanding to respond proportionately.

So, even more lessons learned.  During crunch times, go home or log off after 9 or 10 hours even when I'm enjoying my work.  Hit the treadmill even when I'm lost in thought.  Don't commit to work I can't do in 40 hours, even though if it doesn't feel like I'll mind.  Extra hours can generally be for catching up on surprise work only instead of surprise work *plus* what may be described as "I'm going to be a hero and try to do everything!" work. 

I can continue getting plenty of things done while ensuring that I have enough bandwidth to be flexible to changes in plans.

Move to Management

I had an unexpected shift in career trajectory resulting from my former manager's retirement at the end of February 2017.

I hadn't really seen myself in management...I'd always preferred the alternative of focusing on my own work as an individual contributor, getting closer to the guts of our program under test, Statistica.  But when presented with the opportunity, it seemed like the right course of action.

A few random realizations from 2.5 weeks:

• None of us is an individual contributor.  We get where we are based on learning from others early in our career and first few years of tenure at a particular job.  And once we're the senior people on the team, we have a responsibility to be the teachers and guides.  The circle of professional life.  
• Caring about your team gets you pretty far.  I've already had a few moments where I didn't know what to do, and I half-expected someone responsible to show up and take the decision out of my hands.  But alas, I was the person responsible.   I had a similar feeling about becoming a parent.  You try to prepare yourself, you learn what you can, you care intensely, you do your best, you admit your mistakes and learn from them. 
• I can't do everything I feel like I could write a Dr. Seuss-like book "Oh the balls you will drop!" I'm such a people-pleaser and I've been described as "helpful to a fault".  I have to get over this! Sometimes things are going to sit as low-priority tasks for a while, and I will have to deal with the feeling that I'm letting someone down.  Sometimes I'm going to hurt feelings or not be strong enough in my email replies since I didn't read over it an obsessive number of times, scanning for alternative interpretations or hedging words.  

Obviously I have a lot to learn, but my team is amazing and I'm getting a lot of support from other managers, so I think everything will be okay :-) 

Gorilla Suit Testing

When I hear talk of testing in terms of requirements, I think of the Gorilla Experiment, which is cited in pretty much every book I've read in the past ten years.


Counting the passes is testing the requirements. Which are indeed important. According to the video's instructions, you had one job, so yeah, you'd better get that right.

But our customers aren't getting a copy of the requirements.  All they see is the video without the instructions, as an analogy.  And when you're not focused on the requirements, gorilla-level issues are pretty obvious.

So, you have to test your product with multiple goals and using various levels of magnification.  Once you've counted the basketballs, watch the video again and take in the big picture with no particular goals, just letting the gorillas make themselves seen.  Watch it again and see if there's anything weird going on with the team wearing black.  Watch it again, why are they in a garage in front of elevators?  Why are there S's on the wall?  Does the basketball ever change into a beach ball?

Once you've tested your requirements, congratulations, but your job is not yet finished.

Remembering Our "Why": Lessons from the Challenger explosion

Photo Credit: NASA Goddard Space Flight Center

I always remember the anniversary of the Challenger explosion.

It has stuck with me as a sad day, not just because of the deaths of those on board and the reminder of the darker side of being an adventurous species.  But because there was evidence that they shouldn't be launching at all in weather that cold.

This evidence was presented prior to launch by an engineer, Roger Boisjoly, who worked for a NASA contractor Thiokol.  NPR released an article almost five years ago, shortly after Roger Boisjoly's death.  He and other engineers forcefully argued on January 27, 1986 to delay the launch, but NASA was "appalled" by the recommendation and the Thiokol management overruled the engineers apparently under the pressure from NASA. The launch proceeded as scheduled the next morning.

"Then, a few seconds later, the shuttle blew up. And we all knew exactly what happened."

 A few takeaways from this awful series of events that have impacted my career:

• Find a place to work where management behaves with integrity
• Find a place to work where management trusts the expertise of its engineers and will defer to their reasonable recommendations and predictions concerning this expertise
• We need to be attuned to pieces/features that are subject to failure and creatively think about the conditions under which they are likely to fail, especially when they're similar to conditions that the end user will be experiencing
• Communicate with my management and other internal stakeholders clearly about risks I see and speak with as much emphasis as I feel the risk is worth.  I do my best to let things go that ultimately don't matter so that I'm more likely to get their attention when it does.  
• I have never needed them and I don't foresee needing them in my current position, but I have a few extra levels of freakout in reserve for "this could kill people" or "this will likely kill people", where I imagine myself trying to change the minds of those in charge of a NASA launch/no launch type of decision at various temperatures. 

I hope that customers, management, and engineers keep the lessons that can be learned from the Challenger explosion in mind as our work becomes more prevalent in life vs. death situations like driving and medical diagnoses.

A "Post-Agile" Post: "If it works, do it. If it doesn't, don't".

I like simple rules of thumb. I found an article this morning with a very simple approach to the software development life cycle: "If it works, do it.  If it doesn't, don't".

Of course, it's not exactly that simple.  What does "works" mean?

I would define "works" as delivering products that people want to pay money for at a high enough quality to meet the business value of the customer and the ethical standards we should value as technical professionals.

Underlying that is customers are paying enough money in relation to what the software company is paying its workers.  So on the revenue side, we need

• Good market research people.  
• Good sales and good marketing people.  
• Good customer service folks. 

All are making sure that we understand the problems customers are facing and that the customers are and feel valued and heard.
Also underlying the simple approach is we are efficient at delivering the software on the cost side. 

• Development/QA and product management work super closely together so that there is no question what the customer wants and why. 
• We only deliver what the customer needs or have strong evidence that they want.  
• Developers are all focused on current customer needs, paying down any technical debt that's accrued in the past that threatens the current value of the product, or researching future technological trends -- what customers don't need now but will in 1-5 years.  
• QA is empowered to ask questions from the beginning and in a position to find issues quickly after they're introduced.  This prevents Development/QA from having to spend time identifying, fixing, patching, and retesting issues after the initial release.  
• Nothing is done without the customer in mind.  No documentation that doesn't directly serve a customer or promote good understanding of the product within the company.

We still need continual, honest assessment of what we're doing that's "working" and what is "not working".  But by taking the simple approach we focus less on blindly following and enforcing specifics of a process (even an Agile process) and more on the understanding and internalizing of what "works", particularly how each of our roles and interactions contribute to the value of the product.