About Me

Some History

I happened across software testing as a happy little accident. That led to 4.5 years of work that I very much enjoyed. My teams shipped products that were transformative in healthcare (for patient/doctor relationships and for sanitation of equipment), self storage, and cyber security assessments. I spent the last 1.5 years prioritizing work for internal tools for developers; during that span engineering employee satisfaction spiked to world-class highs. While the engineers enjoyed their work, I begrudged mine. I want to get back to the world of testing and system analysis.

Before moving to software I spent 7.5 years in school, resulting in an MS in Mechanical Engineering and an MBA. These degrees are evidence that I stick with learning until I reach a milestone and that I can evaluate a wide range of systems effectively.

What I Am

I am a system analyst.

This means I consume big data, evaluate it in context, and then make intentional choices about what will be most valuable to my teams. Below, you’ll find more details about what each of those three steps entails. A feedback process is also crucial to making sure my analysis stays aligned with what the business and my teams need most at any given time.

And a leader.

Throughout this site you’ll see the living list of principles that guide my work, the hard and soft skills I’m working on, and the resources I use to improve.

What I Do

Consume Big Data

Software development ecosystems are complex systems. Probing is the most effective method for problem solving in complex environments. I leverage my 13.5 years of experience and training to pull data that is likely to yield valuable insights.

Evaluate That Data, In Context

Literature on the software development lifecycle (SDLC) defines it like this:

TODO

The actual SDLC looks like this:

TODO

Depending on the market pressures (at any given time), our product positioning (at any given time), and our executive sponsorship (at any given time), different parts of the SDLC will be most valuable to the organization.

Make Intentional Decisions About What To Share, And When

Understanding the nuances of our environment, its the analyst’s responsibility to present the right info at the right time to the right decision maker so that the business can achieve its goals.

The map above is one way to contextualize findings. Another is a tool I call “Players/Actions/What Could Go Wrong.” System swimlanes and architectural diagrams represent two more tools we can use to draw meaning from our findings.

Establish Feedback Loops To Stay On Track

Do we push our findings or allow them to be pulled? Do people in the organization know what we can empower them to do? Is what we’re focused on the right thing for the business right now?

The answers to these questions will change over time. Above, I described how an analyst becomes effective. This step is how an analyst stays effective. We must get feedback from our audiences and stakeholders and have the courage to fold that feedback into our work.