When you find out that what you’ve shared into the world, something you’ve poured your heart into, is not recognized by those who you thought will be thankful for it, it isn’t really worthwhile to antagonize them. You’re just crying over spilled milk. Sure, cry, but please ask why you made the thing in the first place and give yourself an honest answer. Why was the thing important? Is it truly for your audience or for yourself? Did they actually tell you to create the thing, or was it an initiative? Why aren’t you satisfied with what you’ve done? Was it a requirement that they use the thing you’ve built too? Is it necessary to be recognized? Isn’t it enough to know that you made something of value at least for yourself?
And if you’ve made the thing you did for consumption and it wasn’t consumed by the people you think would, maybe the thing isn’t as valuable as you think it is. Listen to your audience, to their comments, and, perhaps, to their silence. Understand their wants and needs. Talk to them. Maybe something significant is missing.
Everyday, prepare a very specific question (or a task) interesting enough to warrant research for an answer within several hours without distraction. Sometimes for learning, sometimes for fun, hopefully most days for both. Everyday there must be an adventure to immerse in, albeit small, something to be curious for.
Having received a handful of calls these past few weeks, I’ve realized that I’m thinking more about learning opportunities now than only looking at an offer’s compensation package. Salary still matters of course but there’s more to a day job than just allocating money for expenses and savings. Work wouldn’t be fun when there’s only menial work to do. What would I learn if I took an offer in exchange for my services? Will I be doing something I’ve never done or tried before? Is this work meaningful, both for our customers and for me as an individual?
And some more questions to recruiting employers on the top of my head:
- How does the existing software development and testing process work in the organization?
- Are testers embedded into software teams? Or do they work in silos, away from the developers?
- What does a software team look like and compose of?
- What does the day-to-day work look like for the software tester?
- How many testers are there currently in the organization? And what’s the existing ratio of developers to testers?
- What technologies do the organization currently use for testing? Are there automated checks? Is there an existing CI system?
- Does the organization use containers? Visual testing? Machine learning?
- Who are the organization’s actual clients? Which lives are we trying to improve on a daily basis?
- How do the software teams get feedback from the people who use their applications?
I have always thought of myself as a good listener. That’s what I believe to be particularly the reason why I have thrived working with both programmers and product owners, a software tester in the midst of all sorts of people. It’s a fundamental skill I have learned to be proficient in.
What’s not my strong suit at though is asking people for what I want or need. Of course asking for little things or asking probing/clarifying questions isn’t that difficult; what’s tough is inviting people to join you on a quest, asking friends to do something interesting together, or asking a fascinating lady out to lunch. It’s a fear which doesn’t get any easier even if I actually know the problem. And the solution is the same as with all skills: practice. It has been and always will be a struggle, so I need to continuously remind myself to be brave.
To find out that the programmers in the team are seeking out product owners, stakeholders, and teammates on their own to ask clarifications and start meaningful discussions is a positive thing for me, to notice them initiate communication to whomever they need to talk to is always a major confidence booster about their ability to work on problems on their own. They never need my authority or permission to do what they think is best, they manage their own tasks, they own the responsibility to do the right thing as they see fit. I’m just there to help them perform the best work they can, in the form of suggestions and testing.
That’s why it’s bewildering to see someone get disappointed over a behavior that I deem to be on the plus side. Why would letting developers talk directly to stakeholders make you feel overstepped, if they think it supports better work? It seems to be, at least for me, a shallow use of a leadership position, a certain level of being clingy to power that’s not serving the team mission. It’s an upsetting, controlling reaction that I feel does not do any good.
Focus on empowering the team.
What does our team actually want to accomplish this particular sprint?
Do I know my teammates well enough?
Does everyone in the team feel safe working together with each other?
Can I rely on everybody in the team?
What does a user story mean to us?
Do we even need tickets in order to perform our best work?
Do we truly need this specific document to move forward?
How can I help a teammate feel good with the work he/she is doing?
What’s the minimum amount of input do we need in order to start?
What’s the 20% of activities that contribute to 80% of outputs we desire?
Do we believe in what we are building?
Which rules, in reality, help us become the best versions of ourselves? Which don’t?
BPI (Bank of the Philippine Islands) suffered some account balance inconsistencies on their online channels for a few days last week. This stirred widespread panic and disappointment in their services during that time, forcing their customers to go manual. Everything’s back to normal now, but it is undeniable that the banking organization was hurt by what had transpired.
- Banking software, and any software which deals with money and investments, are very sensitive, because people care a lot about their hard-earned cash. Such software need to be precise, secure, on schedule, resilient, and performant, probably much more than what other categories of software are expected to be. People will complain loudly if the software is slow, customers will be scared out of their wits if they are unable to log in on their accounts, and panic will ensure if suspicious transactions are found even if they’re only bugs.
- Software that’s stable today might not be tomorrow. Systems can break, sometimes for trivial reasons, and what’s important is what an organization and it’s people do when bad things happen.
- It might be a good idea to open accounts in other banks, to diversify.