Clear Communication Leads to Strong Communities
I want to focus on one specific aspect of project to product development from the Open Source First article. Coordinating upstream (publicly licensed) and downstream (private non-licensed) development work. In any organization that is developing and supporting software, there are some number of engineers that work on public projects. It is a common problem that the Development Managers and the Scrum Masters do a poor job of tracking that public work. Let’s assume that the Development Manager is aware and supports the public development work.
What typically happens is that upper management is not aware of what the upstream work purpose is and its importance to supporting the overall development strategy. What likely started as support or even direction from the Development Manager to work on the public project evolves into a fog of light understanding.
Many months later, when performance reviews and head count updates come around, typically the upstream developer gets lets left out, as the public work is not part of what upper management understands. This leads to either dropping the upstream work, alienating one of your likely best developers, and/or the upstream work continues, but with zero Development Manager insight. In some cases all three things happen, in which case, you now have a increasingly separated, forked development effort, with a increasing annoyed developer, that is going to be putting in more and more time into the public projects. Not a good workplace situation for the developer or the manager.
It takes more work, but there is a proven solution. Treat the public projects like another engineering organization. If you are going to work with another engineering team, you expect to have a clear understanding of responsibilities and timelines. You need to have the exact same expections when working with a public project.
Right at the beginning, when the developer has plans to work upstream, set out responsibilities and timelines. This is just as much to protect the developer as is it is the company. Define what the public work deliverable will be and when it will be delivered. Make sure your Product Managers understand how the public work contributes to delivering the product. Make sure the Scrum Master works with the upstream developer just like the rest of the downstream developers. The upstream developer is still part of the team. As the upstream work starts to take shape, get the code into a testable branch on your software pipeline. Make sure you have quality unit and build tests to verify the upstream work, so it can be more easily merged into your code base trunk when the time comes.
Track all your development work and report on progress. Highlight the upstream and downstream work. Update leadership on the upstream progress. Keep up to date with the public projects release schedule and strategy. Publish both your private release schedule along side the public projects release schedule.
This is just the broad strokes. You will need to take this and put in specifics for your implementation. Organization structure and tools vary greatly, but hold to the basic tenants outlined above.
I get nervous before every job interview. Most of us do whatever we can to avoid getting in the situation of having a job interview. That generally means avoiding career planning as well. The messy truth is that we put off uncomfortable activities. I have put together a simple step by step plan that can help you make working on your career a positive experience. We all need some help with learning and growing. Your career is no different.
We are developing your career understanding by creating a plan. This plan is for increasing your personal capabilities to make your career goals happen. To create a truly effective plan, you need to pick a mentor to work with. This mentor can be a wife, boyfriend, mother, co-worker, or boss. The mentor you choose needs to work with you on creating your plan. It is helpful, but not mandatory for your mentor to be in the same career path. You need your mentor to be slightly senior to you skill wise, and be available over the next 3 to 12 months to work with you. I have practiced different forms of these steps below over the years at many companies and situations. As a result, I have a list of ten mentors that I ask for advice and council. You just need one.
Let’s dig into who you are and what you want to develop into. Follow the steps below to get to know your future self.
We have a rough career strategy at this point and a mentor to lean on. You know what you want your future you to be. Congratulations, most people do not get this far.
As you get about halfway through the year, review your career plans. Make adjustments. Start planning your next year of short term goals.
I was invited to speak at one of the TODO meetings, 17 Jan 2017, at the Yahoo Sunnyvale offices. My talk was centered around Open Source First as a strategy using the Open Garden Development and Project to Product concepts.
The primary purpose of the TODO group is to bring together companies who run open source programs. Open source leaders, as a community, do not talk amongst ourselves very often. We deal with lawyers, security, and technology products, so being shy comes as no surprise. Henceforth to combat the lack of communication, the TODO group was formed to help improve the shared knowledge. Generously, the Linux Foundation supports the TODO group as one of the Linux Foundation Collaborative Projects.
My talk highlighted the accomplishments of Walmart as a company and OpenStack as an open source software development community. I want the success of OpenStack as software development community to work at Walmart. Therefore, I have created an strategy for success called Open Source First to work on making this happen. To begin with, we have started with the Open Garden Development and Project to Product parts of the plan. Put simply, we are improving collaboration through better communication and creating a better workflow from feature development to product implementation. For your review, find the talk slides are below for more details. For more information on the Linux TODO group visit http://todogroup.org/.
#UPDATE 08 Feb 2017: I rewrote the first paragraph with better verbiage and added a second paragraph with details on the content of the talk
know that I am more a of engineer than a product guy. Even so, I was hired on to transform the Walmart Platform Products using my engineering and open source experience as the Walmart Platform Product Director. It’s been very interesting so far. Not without some bumps and bruises along the way. I am happy to say that we are in our 5th month running an internal Platform Product Guild, largely based on the success we the OpenStack community have had with the OpenStack Product working group. We have development teams publishing Product Roadmaps that we regularly review across product teams and with customers. We are directing customer and engineering feature requests into our Product Roadmaps and product development cycles. We still a lot of quality to improve on, but we have made great progress so far. I am looking forward into 2017 to include more open source behaviors in the product development processes at Walmart. Stay tuned for more details as I can share them.