Theres a popular show on CBS called “Undercover Boss” where the owner or manager of a business disguises themselves to be a new employee in a mid-level or lower-level position in the company, where its likely the employees won’t recognize them. The manager then learns the day to day activities and insider tips pertaining to the employees actual work, to learn what its like to walk a mile in their shoes. At the end of the episode, the boss reveals herself and hilarity ensues – especially if these employees had been bad mouthing the boss. Oops! Other times the boss gives the employee a bonus because they feel bad about how hard their job is which seems to be the point of the series.
A couple months ago I decided to quit my job as a Senior Product Manager at GovDelivery and go full time head first into freelance mobile development. What was I thinking?
First off, I had no illusions this transition would be easy. One does not simply… become a good developer by watching videos and completing tutorials. I knew from the beginning, in order to really become a developer I had to prove it. Prove it by building, fixing, breaking, and testing as many applications and projects I could find. Also, publishing an app built from scratch would certainly appease hiring managers and recruiters.
Transitioning would accomplish two of my goals. To gain a deeper understanding of the technical aspects of software development from an Agile PM/BA/QA perspective, and I aspired to build and fix software. I craved to be more hands on with technology in these amazing and exciting times we live in.
The final project for a Thinkful course I took involved creating a mobile app from scratch. This meant completing the entire development lifecycle from ideation to wireframing to implementing to testing to publishing. It was right up my alley of experience, I wrote up stories on sticky notes, posted them to my dining room wall and organized them by importance and epics. I took a picture I was so proud of my wall. (and because in about 10 minutes they’d all fall down)
Then came the hard part – estimating. I didn’t have a good idea how long some of these user stories would take. I had always worked with highly productive developers, and so the effort and time to complete value of a story point or an hourly estimate of a task generally worked out. But now I had to give myself a reliable estimate, and I didn’t have much faith I would give a good one. Oh well, onward to development!
As I posted these stories to my dev office Kanban (wall) to plan my first sprint, I began to realize what it was going to take to consider them “done”. I imagined having daily standups where I’d have to tell myself what I had completed yesterday, was going to do today, and figure out what impediments I had.
Unfortunately it became clear my report during each daily standup would be the same for awhile. “Still working on getting x to do y…” Should I go back and modify the scope or change the user stories to be smaller (project manager)? Should I take some away and determine MVP (product owner)? How important was it my estimate be fine detailed accurate (developer)? I got to act out all the parts in this play.
In the end, I didn’t change the number of user stories, or even change what was on them. I wanted all this functionality and just had to realize because I was pretty new at these languages and frameworks (Java, Ruby, Rails, Angular, Ionic) it was gonna take some time, and when you’re freelancing that time costs money. Ah the ol’ “fast or cheap or good, pick two” mandate. But having weighed the time and cost for the result I chose to stay the course.
Because I knew more about the actual effort and time involved in completing these user stories from a personal perspective (because I was going to have to do them), it impacted my perspective on the entire project. I began to think about my frustrations in previous planning sessions and meetings with developers and QA. The frustration wasn’t about how long something was estimated to take, it was a frustration with myself and a lack of clarity in explaining what the final outcome should be.
When I viewed my list of stories with the understanding I would have to DO them, it completely changed my perspective and the level of detail required for a “good” a user story. It changed my approach to deciding their relative importance and business value because if something was in fact “harder” (for me!) to do, was the business value produced from doing it really worth it?
In a way I went undercover and got some serious insight into today’s software development process and I found even more inspiration to continue down the path of becoming a great developer. And I didn’t have to wear a disguise.