I’ve been to the mountain top…and there are definitely more mountains!
Part 2 of 3 of “Neither an Alpha Wolf nor an Omega”
I definitely don’t want to be glib comparing my journey to the one Martin Luther King depicts in his momentous “I Have a Dream” speech that was replayed last month. Listening to it once again and thinking about what I have experienced starting to gig out development work I could not help feel the same type of hope. All of a sudden, I can see beyond the first mountain top…even if it just revealed a whole mountain range.
Every week that was passing, I got a little better at Python, building JSON dictionaries, and configuring cloud services…maybe, not really. I had accomplished building a few functions, but nothing resembling a functioning system or even a basic application. It definitely wasn’t progress enough to keep going deeper down the rabbit hole to learn the skills to do this on my own. Even seeking help, there simply isn’t time to indulge in garage/basement/coffee shop development fantasies where I emerge with my MVP in a few months.
After several weeks of working through the code for a key subsystem, I drew a line and decided it was time for help. The job would not be a major challenge for an experienced developer, but it is a significant milestone for me and the requirements are not trivial. Someone else could turn my meager function it into executable functions and packages and containerize them into a working subsystem. More importantly, someone can do it so that I can keep the other work streams moving forward.
Over the past several weeks, I have started to take advantage of freelancing platforms for development and other research activities essential to my MLP, “Most Lovable Product” (thank you, Brian, for sharing that). Last week I finished development of crucial first milestone to create a foundational capability of my application working with a developer I found on Upwork. It almost seems like a miracle to go from wandering in the woods where I could not see through the trees, to standing on the mountaintop looking down along a path into the valley and having line of sight to my first release.
The whole experience has been pivotal because I have learned how I can create a resilient and cost-effective development capability under lean circumstances. The lessons include:
- Communicate requirements and scope with a clear document
- Bracket your budget
- Maintain stable and secure development environment
- Adopt a good messaging platform
Communicate requirements and scope with a clear document
“Duh,” said the bemused business analyst…but never underestimate the downstream value of comprehensive communication upfront. Clearly documented requirements eliminate misunderstandings and poor quality outcomes.
They even lead to better outcomes in that it recognizes and respects the professionalism of the partner you select. The well-defined requirement enable the respondents to consider my request and propose what they thought would be effective. Although I had a logical application architecture approach, the individual I chose was a qualified and experienced developer who offered alternative approaches that are better suited for my requirement and the cloud environment in which I am developing.
There are a few must-haves in the request:
Overview to offer context. The task may be discreet, but people are professionals and they produce better quality when they understand what they are working towards. Good context may include a narrative, process flow, and diagrams or illustrations.
Explicitly defined deliverables is non-negotiable. As simple as the work may be, you are entering a contract. Everyone involved needs a clear expectation and common understanding of what will be delivered. I usually give each deliverable a name and describe them based on component parts, each with discrete and objective characteristics.
My schedule is fluid and I don’t have hard milestones, but be clear about timeline. When do you expect the work to be completed, as well as the interim milestones? This discrete piece of work is part of part of larger project. Even if your partner recommends a schedule, agree to one and manage to it.
Generously offer assumptions and guidance. Stuff always makes sense in our heads…why doesn’t everyone else get it?! …or see it exactly as I do?!?! Once the work is underway, your partner will be working at level of detail that you may not be used to and this will naturally raise questions. Tools may introduce constraints that require trade-offs. Everyone is learning throughout the process-even you. As much as you can, anticipate these types of scenarios and offer some guidelines for dealing with them. Collaboration and discussions will be required throughout, but help your partner to work autonomously and productively so they can deliver their best…and I guarantee that you will understand your product better.
Bracket the budget
As a consultant accustomed to expensive billable rates, this is an area where I have a lot to learn. As it was my first “large” job on Upwork, I probably set my budget too high…like a bright porch light on a summer night. In the end, I had some strong developers offer proposals, but I probably could have saved a few hundred dollars. Over a few jobs I will bracket the budget to find the sweet spot to maximize access to the best skills while minimizing the amount I pay. Also, make sure you understand how the charging works. What is the platform fee and how is it applied? How are milestone payments structured and how can you control them?
Maintain a stable and secure technical environment
The cautionary side of the ability to accelerate development and even having development partners with solid architecture purview is that the environment risks accelerating past my ability to manage it. Even when there is a limited set of serverless components in the barnyard of a reputable cloud farm, I still need to be able to understand how the equipment works and keep the animals from escaping the barn.
Do not forget to protect yourself by putting in place some foundational practices. First, provide access to the cloud environment based on a rationalized set of roles and privileges. Also, even when it’s only two or three of us, simple and defined DevOp protocols for assimilating developed components is important. I go back to a saying I had about use cases: they are never the wrong thing to do, but it’s about how you adopt them. It’s better to develop good habits early and learn to grow into increasingly more complex delivery scenarios.
Adopt a good messaging platform
It is astonishing, but my development partner and I did not exchange a single verbal word for six weeks until we did a handover. Accessible and “integrated” messaging is essential for anything beyond the simplest transactional scope. Messaging keeps the communication flowing and even creates a more collegial environment beyond email and building on the foundation of strongly defined requirements. We used the Upwork messaging feature, but also a combination Slack and Google Docs for more extensive collaboration. Based on the trust that has developed, I believe we will continue to work together and I am comfortable opening my Confluence and Jira sites to my partner.
And now for something completely unexpected…
A nice byproduct of these interactions is meeting new people. These interactions are fit for purpose and I’m not trying to project my own ideas of who these people are just to feel good about them. I’m not going to say that we have developed lasting relationships, but it has created an opportunity to make a connection with other humans…in China, Pakistan, and Ukraine. I do have a sense of gratitude towards them for helping me at key moments and it’s nice to know just a little bit about them.
At this stage, I am not actively building an organization in the traditional sense, but I do believe that some in this loose community could become colleagues regardless of distance. That said, there is a third scenario where I do need to eliminate distance and have a trusted and capable person to work with.
