loading...
Cover image for "work smarter not harder" requires us to say no

"work smarter not harder" requires us to say no

zachlamb profile image Zachary Lamb (He, Him, His) Updated on ・2 min read

"Our web app has to support a browser. We know it usually takes a month, but can you do it in two weeks." This was the paraphrased message I received after I returned from a much-needed vacation. I had dealt with my fair share of stressful situations before as an ex-fast food worker(shoutout to all service industry workers!) This request had my team and I working long nights and weekends however causing burnout and unnecessary stress while also creating a lot of tech debt. Even worse, this caused my organization to miss our financial goals for the year.

I blamed myself for this unfortunate outcome. After sitting with my thoughts and confiding with my mentor, my boss , and a few close colleagues, I realized I was asking the wrong questions and looking at this situation from the wrong angle.

Newer devs such as myself are not taught the business side of tech in college. Nor are we taught to hone our emotional or communication skills. These are skills that I have had to learn on the job (quite painfully I might add). From this situation, I learned how to manage unattainable requirements and avoid disaster. These are the steps I use now when I get new requirements in project,and maybe they will be helpful to other young devs

1) I ask any and every question about what is required. I do not take anything for granted , and I ask any question no matter how silly or simple it might be. There are sometimes silly questions, but I would rather ask a silly question then work nights and weekends.

2) I ask about the feature's value. "What is the value of this feature to the client and how does it further our team's/org's goals as well?" "Why is this valuable?"

3) Saying "no" outright has not worked out in my favor in the past which is why this is the last point. Asking questions and learning as much information I can, helps lead my team and me to logical and concrete steps as to how feasible a feature is and what the ramifications to adding it to our sprint are.

Thanks for reading my first blog post ever! My goal for blogging is to mainly keep track of what I am learning in my, measure my growth, and connect with other devs/product owners/designers/teach people in the community. Feel free to send feedback, comment, or add anything that contributes to this topic.

Discussion

pic
Editor guide
Collapse
rosejcday profile image
Rose Day

Interesting read, thanks for posting. I do agree, the soft skills that aid in the business side of tech are sometimes overlooked in college. I found it very helpful to take up public speaking and join Toastmasters when I was still in college to get feedback on how to communicate different types of information effectively.

Collapse
zachlamb profile image
Zachary Lamb (He, Him, His) Author

I have not thought about joining Toastmasters for that reason, but I will look into it! Thank you for reading my post and giving me feedback! :)

Collapse
rosejcday profile image
Rose Day

Toastmasters is was great when I was working to get better at communicating technical work to a majority non-technical crowd. I had a few engineers in my local group, but most were not. They gave great feedback into what was hard to understand vs. what was explained very well.