Stop the Engineering Tug of War with an Open Source Office

What is an Open Source Office

Every commerical company has a engineering organization. Commerical engineering standard practice is to develop everything in private. However, times have changed and every company has some open source use and/or development going on. The use of open source without formal engineering support causes an unnecessary tug of war for resources. The solution is a group called the Open Source Office, dedicated to supporting the company’s open source work. An Open Source Office within a commercial organization, establishes the open source engineering support. A typical engineering organization focuses on vendors, operations, and possibility software development. Instead, the Open Source Office activities are focused on mitigating risks and supporting developers.

The detailed breakdown of the Open Source Office is into five components:

  1. Legal Oversight of Software
  2. Security Oversight of Software
  3. Commercial Support of Open Source Governance Organizations
  4. Sponsoring Open Source Projects and Tools
  5. Direct Support of Engineering Contributions to Open Source Projects

1. Legal Oversight of Software

Oversight is about risk mitigation. Every company has risk when using licensed software. Contracts determine how a company can use vendor privately licensed software. Open source licensed software requires a company’s legal department to set the standards of use. These standards of use are set by software license types.

Create a process for developers and managers to request a license be approved for use. Hire at least a part-time Open Source Legal Manager reporting directly to the Open Source Office, to respond to requests and own the process. Use a simple form with some basic questions of how, why, where, and when. Jira, SurveyMonkey, or Google Forms all work very well. Once a license is approved, publish the details where any developer can easily find it. is a good place.

So called permissive licenses like Apache 2.0 and MIT allow the software to be used with a minimum of restrictions and thus are favored. Other projects are using so called copy-left licenses that require more complicated rules. The benefit of the software will need to be balanced with the rules of use. You will need to work with your legal minds to figure out the software benefit risk balance for your company.

I recommend using the OSI and TODO organizations as resources. The Open Source Initiative (OSI) has an excellent reference plus mailing list discussions. The Linux Foundation TODO group has a legal workgroup that regularly discusses open source licensing. However, to participate in the TODO group, Linux Foundation membership is required.

Along with the approved open source software licenses, your developers need a clear process for joining, contributing, and creating open source projects. It is common practice to call using an existing open source based software project as Incoming (to your company) and contributing or creating a software project as Outgoing (to your company.) I recommend that once a license has been approved, that any contributions to open source project using the license be blanket approved by legal. You want to remove complexity and overhead.

Clearly document your Inbound and Outbound open source use policies at I recommend my simple open source IO policies below:

Inbound Open Source Software policy

  1. Working with a manager, find an open source project you want to use for company related work
  2. Verify that the software license is approved by legal here
  3. If the license if not approved or disapproved, request approval through the new license request at Legal will respond within a few days and start working with you on your request.
  4. If the software license is approved, review the use restrictions, if any. For questions, request answers through Legal will respond within a few days and start working with you on your request.
  5. Join or create your open source project to the software index at Developers, users, and managers will use this information for training, mentoring, and hiring.

Outbound Open Source Software policy

  1. Based on your own interests or working with a manager, find an open source project you want to contribute to. You can use as a guide for existing users and contributors within the company. These people can help you with training and mentoring.
  2. Once you find the open source project you want to contribute to, follow the contribution guidelines at OR
  3. If the project doesn’t yet exist at, then you need to verify or request the open source software license is approved here Once the open source software license is approved, then add the project to

2. Security Oversight of Software

Your legal department sets the software license standards of use. Your security department is tasked with enforcing compliance of those standards. Where it comes to using software, security also wants to reduce the risk of introducing software vulnerabilities. Security covers this for privately licensed software through contract language and penalties. For open source licensed software, your security department needs a software scanner to verify license compliance, viruses, and other security risks are identified before use.

Many organizations use Checkmarx, AppScan, or Blackduck by manually scanning a code repository for security and license compliance. While this accomplishes a one time need to verify the code is compliant, it ignores any ongoing risk. It is a better practice to include the scanning activity as part of your software pipeline (also called Continuous Integration). By adding the software scanning to the software pipeline, any problems can be triaged by the developers during the development cycle, rather than waiting until the last minute. You will need at least a part-time Open Source Security Manager reporting to the Open Source Office, to manage the process and to respond to requests.

Well documented and understood legal, security policies and processes is good governance. Knowing the rules through good governance makes for happy employees

3. Commercial Support of Open Source Governance Organizations

Open source does have overhead. Since open source projects are a public activity, not directly managed by business needs, you need some good governance to help organize and collaborate. Companies using open source need to support the organizations that support the open source community as a whole. These include OSI, OIN, Linux Foundation, OSCON, and OCP to name a few. Supporting these organizations with sponsorships allow volunteers like myself support open source public policy initiatives and mentor new open source leaders on best practices. Hire an VP Open Source to manage the office, personnel, and the governance relationships. It is important that the Open Source Office leader is at a senior level so the policies the resulting policies are followed.

On a side note, commercial open source is a term that has been applied to organizations like OpenStack that are a mostly corporate funded development. This term still works here as I am using it, as I am applying to the need of commercial open source support beyond just the developement projects, but also to the governance organizations that support those development projects. We as open source leaders, need to do a better job of highlighting the requirement of proper governance for success.

4. Sponsoring Open Source Projects and Tools

Beyond developer code contributions, your company needs to sponsor your open source project events as well. As your company supports open source governance through organizations like the Linux Foundation, your public development projects need a similar type of support. At least each open source project will need to get its contributors face-to-face around release time. Planning for the next release is critical to get be completed very close to the release of the current development work.

These events need to be planned, organized, and executed. Events with more than a handful of people over a few days, becomes a complicated, expensive enterprise. To fully support an open source project, you’re contributing company needs to source developers and event sponsorships. Hire at least a part-time Events Manager to be responsible for these activities. A person with marketing experience for the role of Events Manager is a likely fit. Make sure that the Events Manager works closely with the development community, so the events meet the developer’s needs.

Public facing tools require support and management just like the projects. GitHub and other components of the public project Continuous Integration need continuous management and contributions to keep the project development momentum going strong. What is often missed, is the administrative function of keeping the public repositories managed. All too often, an organization’s public GitHub repositories become littered with stale projects that are no longer under active development or supported. This hurts the company reputation, making other public project participation more difficult.

The Open Source Office should not only take administrative ownership of the GitHub organizations your company owns, but take an active role in curating the projects there. If a project is stale, then update the root readme to say the project is not under active development. A GitHub organization that holds stale projects, if there are many, can help as well. The project can always be moved again if it becomes active. Hire a Community Manager to administer the public GitHub organization(s).

5. Direct Support of Engineering Contributions to Open Source Projects

In addition to GitHub, there are many Continuous Integration tools such as Jenkins and Gerrit that can used by public projects. For your public projects, whatever the Continuous Integration tools are, support them as strongly as GitHub. By relying on others to support the infrastructure that make the public project successful, you are outsourcing a critical function. Get involved at least part-time in the project CI infrastructure to ensure no surprises. Your Community Manager will monitor the state of your public project momentum through the project CI infrastructure. As problems arise, the Community Manager will jump in and work to fix the problem or gather people to fix the problem.

Project Data Analytics

As your team contributes, your engineering leadership needs information for scrum retrospectives and employee reviews. Code commits only tell a small part of the project story. Project data analytics fills in the gaps of project activities like patch review quality, time spent on contributions, and patch set history. Understanding these types of developer analytics are critical for any project. Developer analytics on public projects are essential. Development tools like Jira and Aha have some basic reports, but are missing the detailed analysis that can help mentor a junior developer or highlight feature development momentum. There are tools that can fill this gap. I know of three so far, Stackalytics, Biterga and GitPrime Biterga and GitPrime can work on public and private repositories. I have been using Stackalytics for years, which is specific to OpenStack projects. It doesn’t have everything I would want. Stackalytics does allow for browsing patch review quality and filtered release contributions. Developer analytics has been a very important tool supporting open source projects.

Open Source Developers as Part of your Company Sprints

We have explained all the overhead for open source projects, except the most overlooked and arguably, the most important. Expand your developer support by supporting the public project development process within your internal development teams. To make this happen, your Open Source Office leadership needs to have authority over the product and project management. Dotted line management can work, while making sure open source is part of the annual reviews.

Day-to-day, week to week involvement with your internal engineering teams is critical for open source developers well being. Their public upstream work needs to be part of the internal sprint backlogs. Sprint retrospectives need to review the open source work along side the internal private project work. I have expanded on what is necessary here

Lastly, the most important part of your open source effort are your developers. They will be the beneficiaries the Open Source Office support. Your upstream open source developers will be productive contributing members of your commercial enterprise. Assign open source developers to public projects no differently than to private downstream projects. Do not forget the critical  part of a developer’s well being is good, clear leadership. You will need to have those developers at least dotted line to the Open Source Office leadership. This ensures that come annual reviews, your open source developer will get the proper attention and rewards for their hard work.

Remember that part-time work on multiple projects is possible for someone very senior.  Expect that junior to mid-level developers will need to work on one internal or external project at a time. I have many more details on upstream open source developer productivity here and here

The Open Source Office

In conclusion, the Open Source Office establishes the necessary engineering support structure for a commercial company to be successful. The Open Source Office mitigates risk and supports the developers. The Open Source Office responsibilities can be further described as legal and security risk mitigation, supporting open source governance, projects, and their developers. Stop the tug of war for engineering resources within your company and formally recognize your use open source software, by establishing an Open Source Office.

Volunteering at the 2017 SFBay ACT-W conference

What Was This

I had the privilege of volunteering for the Open Source Initiative (OSI) table at the ACT-W conference at Galvanize, San Francisco this last Saturday with Erich Clauer and Zachariah Sherzad. It was an event focused on giving women the best information on advancing in technical careers. Keynotes and talks sounded excellent on paper, but I missed out on them, as I was in the career fair part of the event for the day. There were many volunteering tables set up in the career area. OSI was one of them. Pyladies, Chicktech, Docusign, among others were there to support technical women. I answered questions about OSI and open source. There was a mix of experience levels, but most were just starting their technical careers.

What Was Happening

Everyone was networking, which is always a good practice. The energy was positive and welcoming. I was able to talk with many women on what OSI stands for and what I could help them with. Describing the benefits of open source is very enjoyable. Especially relevant there were a lot of opportunities to engage people directly. I felt my mentoring on how to join public open source teams was good and valuable information. However, I wasn’t helping with the most important need of all, a paying job.

How To Improve

I should have had a list of open source positions from all the OSI affiliates. Through the ACT-W organizers, I should have asked for digital resumes and LinkedIn URLs before the event started. As people came forward, I could have looked up their resume and matched them with possible openings. Then I could counsel them on their experience and plans.
So, I am going start working with OSI to figure out how we can add these and additional services.


10 Steps for the Boss to Understand Your Upstream Project

Previous articles on Open Source First  have been more strategy than recipe. You need a clear, easy to understand plan for making the case for an upstream project to your manager. To help you with your boss, I have rewritten the How to use Public Projects to Build Products article into a list of ten steps. These steps are comprehensive, covering strategy to implementation. A motivated Developer, Development Manager, or Open Source Director should lead these organizational changes over the many months it will take to implement them. I wish you success on your journey to better, stronger organization.

10 Steps to Supporting Upstream Projects

  1. Strategy: When you set out your strategy and objectives for the year, highlight the open source projects you will be working with. This is important for recognizing the risks, dependencies, and commitments you are making working with the external engineering team that is the open source project.
  2. Partners: Treat a public open source project like another engineering organization. If you are going to work with another engineering team, you expect to have a clear understanding of their responsibilities and timelines. You need to have the exact same expectations when working with a public open source project.
  3. Individual Contributors: Often, a developer will step forward with the desire to work on an open source project that is not part of the organization “plan.” This is exactly what the organization needs. Self motivated engineers are developing leadership skills . Allow the developer to allocate some of her/his time. Set responsibilities and timelines. This is just as much to protect the developer as is it is the company. Encourage open source contributions as technical social good efforts.
  4. Fully Support What You Start: Middle management needs make upper management aware of what the upstream open source work purpose is and its importance to supporting the overall development strategy. Never commit to an open source project that your organization is not willing to fully support.
  5. Reviews: Annual developer performance reviews and headcount updates must include the upstream open source projects. This means that the Development Managers are ready to defend their open source developers with the facts of their work. Developers that excel at working with downstream and upstream development projects are the people who you want to recognize and promote. These developers are very often your best people and likely team leaders.
  6. Products: Make sure your Product Managers understand how the public open source work contributes to delivering the product. In your private Project Management tool, establish an epic for each upstream open source project. Create stories for each upstream feature that is being worked on. Link each upstream feature to a product epic or story that a Product Manager is responsible for. The upstream developer needs to work with the Product Manager at least month to month, so as the upstream work progresses, there is a tight understanding of how that work will go into the Product Manager’s product. A developer advocate like an Open Source Director or Development Manager can be an alternative to work with the Product Manager.
  7. Projects: Make sure the Scrum Master works with the upstream developer just like the rest of the downstream developers. The upstream stories need to be in the backlog along with the rest of the development work. It is likely the upstream schedule of delivering features is different from your downstream product. Adjust your stories for your backlog to match your downstream scrum schedule. Meaning, if your downstream team is on a two-week sprint, then make sure your upstream stories can be delivered in that two-week sprint. Treat all of your developers equally for equal results.
  8. Test, Build, Test, Repeat: 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. Get members of your team to comment and help with the CI effort. As interest in what you are working on gets more help and visibility, you probably will get some public commits from your downstream development team.
  9. Report: Track all your development work and report on progress. Highlight the upstream and downstream work as separate, but equal. Update leadership on the upstream project progress as much as the private development. Approach this as updating on the progress of a valued engineering partner.
  10. Schedule: Keep up to date with the public projects release schedule and strategy. Internally, publish both your private release schedule alongside the public projects release schedule. Alignment of schedules is critical for success.

Using Transparency for Building Strong Organizations

I have broken down below a simple six part outline of what a technology platform organization is and how to run it. The platform organization is the bottom of the technology stack. The top of the stack will differ from the platform, in that, it will have external customers and more focus on product design and the user interface. However, this outline can still largely apply. This plan is built up over 20 years of working in an around technology organizations. You will find my ideas on Open Source First is the rallying cry of how to run a better platform organization. All the steps that follow have the Open Source First behavior mixed in. Coming from my Open Source First post, transparency is the key thread throughout this outline.

1. What Are You?

A platform organization can be defined as all the underlying functions required to build and / or support customer facing software applications. That includes the data center, server, network, load balancer, firewall, storage, datastore, service bus, service registry, data search, data analysis, data visualization, application server services, monitoring, and alerting (did I miss anything?) in all their various forms and sizes. All that follows is how to run a platform organization with transparency, not what technology to utilize.

2. Know What You Support


Each platform organization supports various services. I loosely call services as something that is listening for requests from a client that the customer is using. There are a variety of service support levels. A Network Operations Center (NOC) is a form of a service. The NOC is listening and waiting for requests. A Service Bus that is implemented at each data center and supported by a centralized team is a service. Each implementation of the Service Bus is listening for and relaying messages.


The new sexy is Functions as a Service (FaaS) or Serverless. These are still services. The main point of the new names is that you are building software utilizing well defined cloud based services that are always available. By the services being considered Microservices, you can assume that they are fully portable with the same functionality and that they can be spawned and destroyed for specific short term implementations. Susan Fowler wrote a book on the subject.


The software developer creates a software product. A product can utilize services as outlined above. A service can be defined as a product as well. A software product is versioned with specific features and bugs. A product has customers with expectations. A service that is also a product will have similar customer expectations. The critical attribute of a product is the customer. A product has a customer. For example, when you acquire a product and your expectation is that it will continue to function as is for a year. When the product fails after a month, you expect to have it replaced or be compensated. A product has transparently communicated iterations of increasing functionality or also called versions. Each product version has advertised, expected functionality. Product bugs happen, but are expected to be corrected in a reasonable period of time.


So the point here is from a platform leadership perspective, you always have customers. Therefore you manage products for your customers. You have services as part of your product(s) functionality. If you were to only focus on the services, then you miss the customer aspect of your responsibilities. You have products that you stand behind and guarantee of level of service delivery to your customers.

Now Define What Products You Support

Make their versions, service levels, end of life, outstanding customer requests, support, documentation, current features, and features to be implemented transparent to everyone. Being transparent means starting with everything being public information. 

3. Know Your Customers

So often, we rush through designing and implementing a great product that has little to no customer interest. You must understand and personally know your customers. Schedule recurring meetings with your customers and key product managers. Hold those meetings on time no matter what. Delivering bad news in person is just as important as good news. Remember that the platform organization exists to serve its customers. And that your platform customers are the people that make the profit in the P&L.

4. Define your Roles

Every organization needs well defined roles with responsibilities. I have used the RACI model to help describe the roles. I have outlined below the most critical roles for a platform organization with a few of their most important responsibilities.


transparent platform
transparent platform leadership roles
Image 1: Platform Organization Hierarchy


In my definition of the platform organization, everyone reports up through the Platform SVP. There are four Development VP positions for Services, PaaS, IaaS, and Hardware, one Product VP position, and one Operations VP position. Six VPs report to the SVP. The Network Operations Center with the first and second level operations engineers report up through the Operations VP. The Development VP positions oversee their slice of the platform technology and are accountable for the third level operations engineering. The Product VP oversees the Product Managers, Scrum Masters, and Release Managers. The Product Managers report directly into the Product VP, while the Scrum Masters and Release Managers for each technology slice can be dotted line to the Product VP.  This allows the Scrum Masters and the Release Masters to be closer to the developers that they support. As long as there is accountability, it should not matter who reports direct to whom.


Each and every person in the organization is expected to be involved in development and operations practices through CI / CD. That means everyone practices DevOps and the resulting agile behaviors.


Platform SVP role

  • Responsible for the annual strategy derived from the CTO strategy
  • Accountable for leading the organization
  • Accountable for hiring practices of the organization
  • Responsible for the organization budget
  • Accountable for the platform products
  • Accountable for on-boarding new customers through platform operations
  • Recognize the the buck stops here with the SVP. The SVP delegates responsibility to the chain of command.

Development VP role

  • Responsible for the annual strategy for their slice of the technology organization
  • Accountable for quarterly objectives
  • Responsible for leading their slice of the organization
  • Accountable for hiring in their slice of the organization
  • Accountable for their part of the organization budget
  • Responsible for their technology slice platform products
  • Accountable for layer three operations engineering support

Development Manager role

  • Very similar to the Development VP role, except they are responsible for the capabilities of the VP in their slice of the organization

Product VP role

  • Accountable for quarterly objectives
  • Responsible for the Platform Product Managers and Scrum Masters
  • Accountable for regular meetings to determine the status of the release schedule
  • Accountable for planning and organizing the product roadmaps, releases, and reporting
  • Responsible for the Product Management retrospective and Product Management roadmap review scoring processes
  • Accountable for the platform products schedule
  • Responsible for coordinating product release schedules and product milestones across the entire organization
  • Consults with Security, Operations, Open Source, Legal, and other horizontal teams on requirements and assistance

Product Manager role

  • Very similar to the Product VP role, except they are responsible for the capabilities of the VP in their slice of the organization
  • Responsible for prioritizing the Product Roadmap(s) features while working directly with the Scrum Master and Development Manager
  • Responsible for product backlog scoring used during scrum retrospectives
  • Collaborates with other Product Managers on Product Roadmap risks and dependencies
  • Responsible for demonstrations, roadshows, and product showcasing
  • Accountable for engaging with customers through Customer Advocacy meetings
  • Responsible for marketing the product for customer adoption and on-boarding new customers
  • Responsible for accepting or rejecting product delivery from the development team for a release based on product reviews and quality

Operations VP

  • Accountable for quarterly objectives
  • Accountable for general operations support (layer one and two) including the Network Operations Center
  • Responsible for managing alerting and monitoring services
  • Responsible for managing the CI / CD infrastructure
  • Accountable for the Data Center Operations. This includes public (AWS, GCE, Rackspace, Azure) and private (owned, leased, colo) based infrastructure
  • Responsible for on-boarding new customers into the platform organization

Release Manager role

  • Responsible for their own personal quarterly objectives
  • Accountable for software pipeline quality
  • Responsible for tracking unit and build test application. Are the tests doing anything useful? Do the tests get set to noop during the push for release?
  • Responsible to work with the Development Manager(s) on how testing can be improved. Are the same tests being run for gate and build? Can some of the tests be run pre patch submission by the developer? Are there some project teams that are having problems with test implementation?
  • Responsible to work with developers and/or the Infrastructure Manager reviewing software pipeline logs for information and errors.
  • Responsible to work with the Infrastructure Manager on maintaining the software pipeline. Especial focus on keeping the software pipeline functional towards the end of a product release cycle when there will be heavier than usual load.
  • Responsible to work with the Product Manager and Development Manager on the product release cycle.

Scrum Master role

  • Responsible for their own personal quarterly objectives
  • Accountable for managing scrum or kanban boards for measuring progress against the roadmap
  • Accountable for holding scrum or project retrospectives
  • Responsible for working closely with the Product Manager and Development Manager on backlog prioritization
  • Responsible for working with the Product Manager on the product release
  • Accountable for managing appropriate engineers’ time management during sprints
  • Consulted by the Development Manager on feedback around engineers’ performance, productivity, and quality
  • Responsible for identifying and removing risks and dependencies in coordination with the Product Manager

Developer role

  • Responsible for their own personal quarterly objectives
  • Accountable for completing work assigned by the Scrum Master
  • Responsible working within the DevOps software pipeline(s)
  • Accountable for personal technical capabilities
  • Responsible for mentoring junior engineers
  • Responsible for practicing transparency and collaboration

5. Communicate on a Well Defined Schedule

Communication milestones that your customers can come expect is critical to gaining trust. Most importantly these milestones provide transparency to the product development process for customers and collaborators. If delivering on these milestones becomes difficult, consider moving the Scrum Master and Release Manager roles under the Product VP for more accountability for the product management process.


Bi-weekly communication to the platform organization

  • Progress on features
  • More in-depth information from blog posts

Monthly communication to the company

  • New product updates
  • Few blog posts to highlight

Weekly to bi-weekly project retrospectives

  • Backlog progress scoring based on backlog reviews by the Product Manager
  • Project epics are created and updated by the Development Manager, Product Manager, and Scrum Master. Then the epics are kept up to date throughout the quarter

Monthly Product Roadmap reviews

  • Each Product Manager updates their published roadmap monthly
  • Each Product Manager publishes a Product Roadmap quality score for each product they are responsible for. The roadmap quality score is based on: are all the roadmap details available, is the roadmap published on-time, and the quality of the roadmap details.

Monthly updates on product, project status based on Product Roadmaps and Releases

  • Report published with last quarter product releases, scoring metrics, progress on features, status of risks, dependencies, and the status of customer requests
  • Updated, published annual product release schedule

Quarterly product roadmap reviews

  • Features, bugs, risks, and dependencies
  • References to epics for cross-project discussions

Quarterly Headcount and Finance review

  • Travel, equipment, events, sponsorships
  • Headcount adjustments by project, product, and roles
  • Fine tuning from the annual review

Quarterly Customer Advocacy meetings

  • Each functional group of products holds quarterly Customer Advocacy meetings
  • These customer meetings can happen as often as required, but with the Product Manager(s) attending, representing the product

6. Create a Culture Based on Transparency

Every organization needs a strategy. But very few organizations have a strategy that makes sense to the organization. That is because most people start with blue sky planning. That is a mistake. This is not a company you are running, rather a team that supports an existing company with a strategy and goals of their own.


After putting the platform organization together around products and customers, you have a solid baseline for what your strategy and goals need to be. Before you would have wasted your time. Now you can be clear and spend the minimum time planning.


Using that baseline, along with the CTO strategy mixed in, the Platform SVP maintains no more than 5 annual goals, created two months before the new year starts. Those annual goals are the strategy for the organization. The strategy must be clear and timely, so everyone can reference their part in delivering the strategy. The platform leadership, Platform VPs, will need use the annual goals to plan out their annual year products and headcount.


To publish and communicate the strategy, use the method of OKRs. My best OKR experience was when each employee started with a blank gdoc indexed to the organization structure. Transparency of everyone’s goals, starting with senior leadership, builds organizational trust and confidence. OKRs can be a key tool for organization change. Transparency of leadership’s goals is an important aspect of open source behavior derived from Open Source First. Once the Platform SVP publishes the annual goals as OKRs, everyone can read, write, discuss, and debate the annual strategy.


The organization then updates their OKRs quarterly. Senior leadership should take no longer than a week to create and publish their OKRs. Senior leadership and the rest of the organization publishes their OKRs for the next quarter 2/3’s of the way through the previous quarter. Take no more than a couple of weeks following the first round of OKR publishing, to debate and revise any major inconsistencies. That means timing wise, the whole organization will have their OKRs completed for the next quarter, weeks before that quarter starts.


Do not be tempted to create a hierarchy of OKRs from leadership on down. I have never seen it work well. If your leadership understands your products and customers, then their goals will be very similar to the rest of the organization. Senior leadership cannot understand all the details of the working parts of the organization. Additionally, if everyone waits for the leadership goals, before starting their own, it will cause delays of weeks to months. It is better to get 80% accuracy in your quarterly goals while publishing them on time. Think quarterly OKR train release.


Points to highlight:
  • Each person maintains 3-5 OKRs each quarter. OKRs should be their priorities only.
  • OKRs are not meant to be a project or product management system
  • Transparency of everyone’s goals to improve collaboration
  • Each manager holds their directs responsible for their OKRs. Use your directs OKRs as part of their leadership mentoring.
  • Each person rates the success of their OKRs. 60-80% OKR success rate is what you want. You can also call this stretch goals.

Let Transparency Take Hold

In conclusion, take this outline as just that, the broad strokes. This outline is focused on the process steps that can allow development teams to independently create their own way of running their teams within the platform organization. When you have a well structured organization with milestones, transparency, and good communication, it encourages merit based work from everyone. And that is a place, I want to work at.

Clear Communication is the Key

I  joined the Linux Foundation and many other open source professionals at the Open Source Leadership Summit OSLS in Squaw Valley this week. It was full of great and interesting people who make the open source community live and thrive. I can’t mention everyone, so I will just call out two of the exceptional people, Sarah Novotny and Jono Bacon. Both Sarah and Jono have a track record of consistent community leadership. Both of them spoke at the OSLS. I would like to re-emphasize a common open source community theme they hit on.

Clear Communication Leads to Strong Communities

The community supporting the projects needs to understand where they are headed. The practice of “extreme clarity” in all aspects of the community activities, builds strong communities. For example, as commercial products are relying on the projects for feature development and bug fixes, clear communication on the product strategy helps everyone considerably. Transparency and good communication between project and product teams leads to successful outcomes. This obviously makes sense in the private development of products. When combining upstream and downstream work, it is even more critical.


Failures are a common occurrence. When missing a development deadlines, how is it handled? The community must meet the challenge head on and discuss the problem transparently and publicly. Not communicating well or ignoring the problem leads to distrust of the release schedule and project strategy. Not every problem needs a full debate, but the process of discussion, resolution, and documentation, leads to broad acceptance of outcomes.


The community processes themselves must not be taken for granted. The people involved in the projects, governance, and products with evolve over time. By holding consistent, transparent reviews of the community processes, the communication will continue to be strong. It is often taken for granted how the community functions. It shouldn’t be. New contributors need to understand why and how the community mechanics work. They need to be able to debate their views on how to improve the process of contribution.


To conclude my point here, clear communication is a key attribute of successful communities. Consistent contribution, as Linus Torvalds spoke about at OSLS, is critical for successful projects. But without clear communication, consistent contribution cannot be maintained.

Lead with empathy while focusing on results. I practice meritocracy. Intelligent things found here.