Monthly Archives: October 2016

Make room to be messy!

by

I attended the SmartBrief STEM Pathways event on Thursday, October 20th. The format at the event was speakers, followed by smaller group discussions on STEM versus STEAM, student motivation, teacher retention & pathways. As we were recapping the event and having final questions & answer, I was thinking about how far we have come in education & business from early childhood learning. Learning new things is inherently messy. Learning to ride a bike often involves falling, as does climbing trees, or the monkey bars. Cooking or baking involves making messes and even making things that don’t taste good. Even earlier activities like attempting to put shapes in the correct shaped holes, or stacking blocks result in “stuck” toys or toppling towers. But learning in our classrooms as children, or our work environment as adults are expected to be orderly. We are expected to sit quietly, raise our hands & follow the established systems.

https://www.buzzfeed.com/rachelysanders/epic-pinterest-food-fails-2013?utm_term=.tu4o91nxW#.ylaPX3aY2

baking-fail

Are we doing ourselves and the next generation a disadvantage by limiting the time we have to get messy? Conversations in education reform are heavily focused around “STEM education”, but what does that really mean? If you consider STEM as a mindset, and our path to critical thinking and active curiosity, then it is more about giving our teachers the resources they need to target every kid, leveraging whatever it is that helps them engage in the process. Our focus on standardized testing and grades dampers the desire to try new things. The fear of any sort of failing, or movement away from the orderly, causes a discomfort. At the end of last year, my younger daughter was recommended fro Algebra 1 for her 8th grade math class. She also set herself a goal of making the all A honor roll all 4 quarters. Unfortunately, this was cause for a bit of a meltdown this week as her current math grade was a C, and she had a math test, and the end of the semester is approaching. She was putting so much pressure on herself for this next test, because she wanted to meet her goal. She was neglecting the fact that she was taking an advanced class, that was bound to be harder but she would not have been referred into the class, had her former teacher (and her parents) not believed she could do it.

In the same vane, there a quite a few conversations going on in organizational behavior about the fear of failure. The recent news about Wells Fargo and falsified accounts being created by sales people as a result of the unrealistic, intense goals set out by the organization is just another manifestation of the same stories behind Enron, wall street banks, etc. We have put such constraints around our employees and ourselves, that we lose that desire to challenge and be messy. We reinforce that sense of order initiated when we are told we need to start coloring inside the line, or it’s too old for you to still play with dolls.

There is a role for organization & cleanliness, but I encourage you all to make room for some messiness. It doesn’t matter whether it’s in the form of learning to cook something new, or taking on a new hobby or pushing the limits professionally. Give yourself that leeway, and make sure you give that same leeway to your employees.

 

Don’t Apologize…

by

for being anyone other than yourself!!!! I’ve participated in multiple conversations over the last week that reminded me of this.

Apologies-dot-mean-anything-if-you-keep-doing-what-youre-sorry-forOn Sunday, I got to represent STEM for HER at the She’s the First American University Chapter “Day of the Girl Summit” on their Women in STEM panel. During the event, one of the other speakers shared their experience with convincing themselves to speak up in meetings and make sure their voice was heard. Another panelist identified the problem as one of keeping women in STEM, rather than focus on it as a pipeline problem. Throughout my career, I’ve made it a point of always speak up. Even at my shyest I felt it was important to have my voice heard. This might not have always won me any favors, but it’s part of my principles. I pride myself on my honesty and loyalty. This means that the people I work with and for can trust me to tell them the truth as I see it. If I’m granted respect and trust in return, I can be very loyal. This same comfortableness has guided my decisions to find my own way when I wasn’t getting what I needed from different jobs.

A second conversation occurred with a former employee of mine. He is still at the company where I left him, and is doing quite well as a technical operations manager. He was expressing his thoughts and considerations about bailing out of technology to do something manual like build fences. When he asked how things were going and whether I enjoyed what I’m doing, I talked about consulting being a place where I fit in well. People hire me because they know me and know what I will accomplish. This gives me the forum and format for sharing my expertise, giving my opinions and getting the job done.

I don’t apologize for who I am. Years ago my brother said that “I needed to learn to play office politics and get along with people.” The implication was that if I didn’t do those things, I would be un-hireable. It took me many years, but in some ways he was right. If playing office politics and getting along with people means that I’m trying to withhold my opinions or manipulate the situation to get what I need, then I’d rather not participate. I want to work with places and people who encourage and support me for what I bring to the table…my honesty, loyalty and ability to get the job done.

Each of us needs to look critically at ourselves and figure out who we want to be and what we need to be successful. Once you’ve determined that, it’s a lot easier to figure out if your current situation fulfills you. If not, it’s your responsibility to fix what’s broken or find something else.

 

Whose job is QA?

by
not-my-problem-meme

Tribute to Gene Wilder as Willy Wonka – it’s not my problem meme

developer.com defines the QA (quality assurance) role as “the role responsible for guaranteeing a level of quality for the end client. It’s about contributing to the quality of the final product.” I really like this definition as it does 3 critical things. First, it highlights the importance of the client. A product that works as designs, but doesn’t solve the customer problem fails to address the crux of software development, giving people an application they need or want. Second, it directly states that the QA role contributes to the quality of the final product. Just as developers contribute to the building of the product, and project managers contribute to getting the project done. Last, this definition removes the perception that QA is the responsibility of a single person. And this, my friends, is the topic of today’s post.

Our job as the project team is to build a solution that solves a customer problem or need. I agree that sometimes you are building a solution that customers don’t know they need yet, but unless that need or problem exists, there’s no point in building it. From the very beginning of development, we should all be working with this goal in mind. And if everyone is focused on the same goal, are we then inherently focused on QA? I think so.

My role as project manager puts me directly in front of the customer. This means that I need to be familiar with the solution, in order to speak intelligibly to customers. I tend to do the “final test” of replicating the steps provided by the customer and using the output as proof that the issue is resolved. Unfortunately, there have been too many times where I’m delivered a solution that doesn’t solve the problem or clearly doesn’t yield the “correct” results. Or, if I report a more general issue about performance, I get very tactical response, rather than considering the customer experience.

So what happens? Why does the solution I’m provided not solve the customer problem? Is it because the developer didn’t understand? didn’t care? More likely, it is the developer did some initial investigation and solved what they thought was the problem but didn’t walk through the steps to see it from the customer perspective and therefore missed a critical step.

I’m not advocating for or implying that I wouldn’t or shouldn’t still have the final sign off not the solution, before delivering it to the customer. I’m suggesting that each person who has touched the solution before getting to me should understand the problem we are trying to solve, and be focused on delivering a quality solution. Each developer should be incorporating regular quality checks into their own development. I never want to hear that “my team doesn’t have a QA person” or “it passed my acceptance test.” If the team members understand the goal, and view QA as a part of their job, the customer solution is bound to be better.