Posted by: Jeff Timmins | May 3, 2018

Directions are key for a Release Manager


Making Ice Cream is my latest hobby. I love cooking and I’ve always loved Ice Cream so it seemed like a great thing to do with my free-time. I also decided to apply my hobby as a dessert for my family’s 2017 Christmas celebration.

When cooking at home I like to experiment with different ingredients and amounts but I don’t always take notes, thus making it challenging to every repeat a success (or non-repeating a failure). Because I’m new to “cooking” Ice Cream and because the ingredients are expensive I decided I’d document everything I did. The benefit of documenting & tracking my work became evident right away (i.e. mostly because of my failures!). Looking through my notes I also saw how this directly related to my work as a Release Manager.

An example of the benefit of documenting my Ice Cream recipes was finally finding a great Vanilla. I tested multiple versions of recipes for Vanilla and when I found the right one when testing in September (Pre-Production) I knew exactly which recipe I would use for Christmas in December (Production). This turned out just like my motto for people when talking about Changes – “write the directions so anyone could reproduce the Change in 3 months.”

The same concept applies for Changes to computer systems – directions should be tested, perfected and finalized in Pre-Production and then those exact directions are used for your Production Change.

Directions do matter.

As a Release Manager your job is, among other things, to make sure the Change you are managing is reproducible. Next time you eat Ice Cream ask yourself if you are expecting to taste the same thing you experienced last time you purchased it or if you are wanting to taste experimental Ice Cream.

Posted by: Jeff Timmins | April 30, 2018

Program Release Management

I love commonly used labels because it reduces the amount of time required for a discussion. That is why I love Release version numbers – “the change for Acme 7.4 E2 is exactly like Acme 7.3 E3 we did last year.”

Program Release Management is a subset of Release Management that deserves a separate label for the simple fact that it unique enough as well as popular enough in our Technical world.

This idea is prompted by recent discussions with people on how to best apply the Release Non-TaskManagement discipline with a limited staff. In particular, how to take a traditionally Tasked based process and make it Non-Task based – i.e. getting out of the weeds of a normal Release process. Since I’ve been an “in the weeds” type of guy, this idea initially was a bit foreign but has grown to something very powerful as I’ve considered the idea.

Program Release Manager (PRM) – or Non-Task based Release Management – is a process for a single Release Manager that has responsibilities over multiple Release Trains or Streams that doesn’t have time to directly monitor each “Task” of the process. To solve this problem the PRM would focus on creating a process for others to follow and then manage and/or confirm the process is followed.

The management of this process can be done via a combination of spot checking, focusing on reviewing the most critical changes, monitoring the readiness or factors of success AND AUTOMATION. Your mileage may vary but a Task based RM will be able to manage changes from 1 to 3 Development teams at a time (roughly 8 changes to Production per month) while a PRM could manage at least 100 changes per month.

The obvious question is … what Tasks do you give up in a Non-Task process? As a review, these are the keys for Task based Release Management:

The basic functions of Release Management

  1. Facilitate Release Planning in order to reduce change collisions, dependencies are managed and align resources as needed.
  2. Communicate the right amount of Release related information to the right people at the right time so they can be successful in their roles (i.e. No Surprises) as well as Function as a liaison between Development Groups and Operations, Governance, Help Desk & others.
  3. Manually confirm Release Readiness (i.e. build verification, code quality & documentation) throughout the various Stages of the change, especially before deployed to Production.
  4. Ensure that Production deployments meet compliance requirements set by Governance, includes fulfilling the Change ticket requirements.
  5. Manage the Production change event to confirm deployment steps are completed successfully.
  6. Monitor Post-Release status to report on any related issues from the change.

Overall goals of Release Management

  1. Change is implemented into Production as planned.
  2. Stakeholders and Customers are aware of the change.
  3. No Post-Release issues in the Production environment (i.e. no performance, security or stability issues, no need for rollback, no customer impact, no related Sev1 or Sev2 issues).

For the PRM the Overall goals are the same – after all it is Release Management. The key to the differences for the PRM are in the functions. Here are some high-level thoughts on an easy way to make it work (with the additional thought to AUTOMATE the heck out of each).

The basic functions of Program Release Management (Non-Task based)

  1. Incorporate Release Planning as part of the Release Readiness process.
  2. Monitor automated Release communications.
  3. Monitor automated confirmation of Release Readiness.
  4. Monitor automated Change Management process.
  5. Monitor the success of the automated Production change event.
  6. Ensure change(s) can be supported by Operational staff.
  7. Monitor the success of the change after completed.
  8. Create exception process for deployments that don’t meet automation standards.

Please stay tuned for more on this topic.


  • Scott Ambler‘s talk on Disciplined Agile Release Management: Going Beyond Agile Release Trains (available on Slideshare & Youtube)
  • Thanks to Stephanie, Julia & Terri for talking through the requirements of this process.
  • Those on LinkedIn with the title of or similar to Program Release Manager


Posted by: Jeff Timmins | April 17, 2018

Research – managing multiple Production deploys per day

Research for an upcoming blog on Release Management responsibilities when managing multiple Production deploys per day.

Currently I’m aware of the concept but have yet to work for an organization that uses it. traffic-lights-in-motion-blur-stock-images__k5516756Because you should always been prepared for the unknown I want to create a framework for Release Management process that will fit multiple deploys per day. To do so I need to understand what are considered best practices by others, thus the need for research. Because I will not be able to share all my research in my upcoming blog I thought I’d share my raw research as well.

Currently there probably are not a lot of companies supporting multiple deploys per day nevertheless I should have been more prepared.

Questions to ask/things to think about …

  1. What do you intend to accomplish? For example are you wanting to create a process for multiple deploys per day, the ability to deploy at anytime or to deploy multiple times per week?
  2. The philosophy of “I have a process for what the Dev team can support, nothing else is needed” is a bit of an excuse – I should know I’ve used it a few times! Any process leader should be ready for what is needed to today and be prepared for what may come tomorrow.
  3. Decide which definition of DevOps you will live with … and then accept that others will use the same term to mean slightly different things.
  4. Who owns the Production environment? i.e. who is responsible for a) being aware of issues in Production and b) fixing those Production issues?
  5. Not everyone in the Software world are practicing multiple deploys per day (I only found a few in my research) so it is not a simple task, nor is the philosophy shared by all. That said, buy-in and/or acceptance from executive management is a key part of the success for those who practice this philosophy.
  6. How would this impact Change Management approval process? Does a company that practices this use Change Management?

Helpful links found during my research …

Interesting discussions on this topic

  1. Very interesting article titled “Test, deploy, release … repeat” which doesn’t provide all the answers but raises a number of interesting questions and solutions that would be great to dialog about.
  2. Interesting view of what RM is today and how it needs to change for CI/CD in article “Release management in the age of CD: Are you ready for the responsibility?“.  This shows that every organization is different and because of that has to decide on their own what responsibilities to give to the role of Release Management. 

Examples and thoughts on the topic

  1. As of a year ago TechBeacon was reporting that 10 companies were “killing it” in the area “DevOps” (includes increasing deployment frequency, see this other TechBeacon link on DevOps for the full story but think of it as “Software done well”). I’m sure others have been doing the same thing very well for longer but were just not noticed. Regardless, this provides a good starting point for examples of deploying multiple times per day.
  2. For this discussion I’ll be using DevOps Zone‘s definition of “DevOps”

    DevOps is a practice that gives organizations the ability to develop and deploy software faster and more efficiently, enabled by automated processes such as continuous delivery.

    and will focus on multiple deploys per day, not having dedicated QA team and owning the Production system.

  3. Some good information on Etsy‘s deployment process.
  4. High-level information on how Netflix deploys multiple times per day.
  5. A current (August 2017) in-depth look at the code update process at Facebook, includes a separate process for their Mobile client.
  6. More about Facebook – long paper on how CI/CD is done at Facebook and OANDA. This includes Devs writing their own automated test tools/cases and being responsible for supporting the change. Parts of the paper that I found especially interesting …
    a) They use Release Engineers to preform additional tests after code is built and to ensure there are no issues with dependencies.
    b) Their rollback strategy wasn’t clear but looked like they were more willing to fix issues found during Production deployment than to rollback and try again after the cause of the issue was found. (I believe that during multiple deploys per day an organization should have hard rules on rollback right away when an issue is found or turnoff the new feature/change)
    c) “Changes spanning multiple teams are more difficult to coordinate without agreed upon procedure” (I believe they missed the traditional RM role)
    d) “One tenant of continuous deployment is clear accountability between code in production and the engineer who created it. A testing group dilutes this accountability, especially during times of system failure” (interesting as I believe that having another set of eyes on the validation would be a good thing)
  7. Agile Release Management White Paper, similar to the long paper, includes nice ways of saying mostly the same as the links above but from a Vendor’s prospective.
  8. Interesting “state of the union” on CI/CD from a Release Manager’s prospective at Jama. Towards the end the conclusion is that Jama Software is not yet ready for Continuous Deployment to Production. In addition when they ready the belief is that RM is still needed but that the role might change a bit. The best part of this blog is it provides a checklist for what is needed to move to CD to Prod.
  9. A good blog entry that covers basic points that Release Managers should know about. It is titled “Release Management Done Right” but note that it uses the term “Release” as “Getting Code to Production” and it could be subtitled “Understanding the whole process”.

Thoughts on Change Management

  1. Slightly dated (from 2013) but a good discussion on ITIL Change and Continuous Delivery from I like their general conclusion statement – “Continuous delivery and the deployment pipeline allow you to make effective use of the lightweight mechanisms ITIL provides for change management. However this in turn relies on building up trust between the delivery team and the people who are accountable for approving changes on the CAB.” – but not sure if their methods to get their would be successful.
  2. The article “Is the DevOps Movement Making Change Management Obsolete?” comes across a bit too negative towards Change Management but makes some good points. In particular I liked this quote – “This process will enable gates by which an application team can demonstrate DevOps best practices. Application teams will have to prove that automation, curation, and process ownership exists, and that continuous or automated build/test/deploy capabilities can be certified and categorized as standard or pre-approved changes that do not require the diligence and oversight of traditional change management processes.
  3. From the best practice firm Axelos comes the article “Is it time to change Change Management?“. Their article goes in depth but in short I believe the crux of the argument for DevOps is “trust me because I’m responsible for the outcomes,” something that doesn’t align completely with the foundations of ITIL Change Management.
  4. The approach taken by TechBeacon in their article “Want continuous delivery? Get Agile Change Management” is my favorite so far. I like their approach on responsibilities (seems fair to all) and that the author raises good questions to think through regarding the need to change the Change Management process (also can be used as “check-list” type of document).


I used to think I was the originator of Release Process for a group that had never had a Release Manager before. After I thought about that statement I realized that wasn’t completely true. WestVan_LighthouseParkV1Before I arrived to create the worlds best Release Process for that particular group they actually had a Process to get code Deployed to Production … it just wasn’t the best process for that group (i.e. roots growing on stone). (Yes, I am of the opinion that a Release Process created by a skilled Release Manager is typically better than a Release Process created by someone else – call me confident, an RM believer or someone that can add value, I’m okay with that).

Please know that my confidence or whatever you want to call it doesn’t mean I should never investigate the currently used Process. After all there could be very good reasons for the steps that are followed before I showed up. The key is to understand a) what those steps are, b) why they are done and c) how the people in the group feel about how it works. It is very possible that the answers could be “here is what we do, we are done what we are told by Bob, we think it could be better” or maybe “the steps we follow today are not that great but we have no other choices and please help!” Could be that they would like the tree roots to grow somewhere else as well. I’m not sure about you but I’ve been on the other side when new people say “your RM process sucks” to which I reply “get it, that is what the previous Dev leaders agreed to and another team is blocking me from doing anything else.

Once you have all the details about the current Process then the skilled Release Manager can get to work, creating a Release Process that works smoothly as well as makes everyone happy.



Posted by: Jeff Timmins | January 31, 2018

If Release Manager scares you something is wrong

If you don’t want to invite your Release Manager to a planning meeting on most important Release of the year for your project something must be wrong.ScaryBeachPersonHead They are involved to help so why not include them?

Sure, if the person pictured here is your Release Manager they might scare you but are we not supposed to treat everyone equally?

Sorry, got off topic … right … back to the subject, what is the problem that is causing the Development team not to want to include a Release Manager to a discussion about a Release?

Is someone trying to hide something? Are they not interested in explaining their thoughts about the Release to someone else? Are they not interested in someone else having an opinion about the Release? Do they not want other person reviewing the test results? Maybe they are not interested in someone else providing input regarding the best timing or date for a Production deployment?

If anyone thinks that a set of changes are ready to be deployed to Production then it is also ready for scrutiny. Production changes should be an open book, to be reviewed by anyone. It is the Release Manager’s task to provide an environment that fosters open communication, inviting questions and comments as needed. Driving away the RM during the review period only hinders the end product – it doesn’t make it easier.




Posted by: Jeff Timmins | December 31, 2017

Making Progress with Release Management KPIs

In the past I’ve written about KPIs – RM Charter #2 (ITIL based) and Tackling the KPI problem – and I’m happy to report that I have update. Below I wanted to share what data I’m collecting, what I’m measuring as KPIs and what I’m in the process of evaluating for KPIs. I’m also working on KPIs related to change requests but that will be part of a future post.

Data collecting outside of the Change Management System of Record (e.g. ServiceNow)

  • Date of deploymentwebsite-kpis-seo-success
  • Type of deployment and if Code related version of Release
  • Was change request an Emergency?
  • Was change request reset before being approved? (agreed, challenging data to collect but trying for now)
  • Does deployment include downtime?
  • Change request number and Release ticket number (from Development system of record, e.g. Microsoft TFS)
  • Planned and Actual Start time
  • Planned and Actual deployment completed time
  • Actual Validation completed time
  • Planned Rollback time
  • Planned and Actual End time

Data & percentages tracking but are not considered KPIs

  • Count of Code Related Releases (with and without Downtime)
    • Count of Regular or Planned Code Releases
    • Count of Hotfixes or Unplanned Code Releases
  • Count of Code Rollbacks required
  • Count of Maintenance or Non-Code Related Releases (with and without Downtime)
  • % All deployments including Downtime
  • % Deployments including Code

KPIs I’m tracking

  • % Deployments including Hotfixes (i.e. unplanned work) -> Goal >5%
  • % Emergency deployments (i.e. fixing customer impact) -> Goal >3%
  • % Regular Code deployments requiring at least one Hotfix -> Goal >10%
  • % All Code Deployments (Regular or Hotfix) requiring Rollbacks during Deployment window -> Goal >10%

Still developing as KPIs

  • Calculation of Planned Outage vs. Actual Outage
  • Calculation of Planned and Actual complete deployment window time
  • Difference between Planned and Actual Start time
  • Difference between Planned deployment window and Actual time spent
  • Did the deployment window exceed the rollback time without a rollback?
  • Count of Code Releases implemented late (contrary to originally scheduled timeline – includes last Pre-Production & Production deployments)
  • Number of failed deployments (Operations needing assistance/escalating to Development to complete deployment)
  • Number of change related incidents per deployment (Parent Support Cases related to implementation)
  • How successful was the Release? (i.e. how closely did it follow the original plan?)


Posted by: Jeff Timmins | August 31, 2017

Why Release Management

TellMeWhyAfter writing Foundations of RM I found that it doesn’t really answer the question of “Why we do or need Release Release Management?” Here is that answer.

Why Release Management is important

  1. Assists in the Change Management process – creating tickets + collecting details that are required by Change Management in order to simply approvals & easily pass audits as needed. In addition, this also includes representing & advocating for the Development Team when Change Management is reviewing changes with overlapping dates. This is a benefit to the Company as a whole.
  2. Provides or confirms standardized communication of Release information during the pre-planning phase, announcing the Release, during the Release Window and afterwards as needed. This makes sure that everyone who needs to know is informed of the status of the Release.
  3. Confirms details are shared between Operations and the Development Team and that they are understood. This benefits all parties involved.
  4. Provides central point of contact for Release related information in standardized format. Typically this includes future Release schedule information & previous Release performance. This benefits Upper and Executive management.


The postings on this site are my own and do not necessarily reflect the views of

Donnelley Financial Solutions.
Posted by: Jeff Timmins | August 31, 2017

Where should RM be placed in an Org?

From time to time I get comments or questions regarding which the part of the Organization my Release Management group should be included in. Many companies are different because they grow differently so RM can easily land in a different place than others. Also RM is still a growing discipline, which makes it even easier to have different results for different companies.

My experience has mainly been within IT, reporting directly to the main IT Operations Manager. Today I report to the VP of Operations which reports to the CIO.

What do you think? Examples of where I’ve seen Release Management are Development, QA, Product Management, Governance and of course IT. Please leave comments of where you think RM should live.



The postings on this site are my own and do not necessarily reflect the views of

Donnelley Financial Solutions.
Posted by: Jeff Timmins | June 30, 2017

Foundations of Release Management

Goals, Success & Details that every Release process should include


The purpose of the following information is to provide the reader with a better understanding of the motivations and thoughts behind my general Release Management process. With different cultures and histories behind the Development groups around the world, a process that works for one team may not work for another (i.e. one size doesn’t fit all).

In addition I firmly believe that the Release Management process should not be forced on a Development group but should be tailored or fitted to enhance the model that the team provides.

Because of these beliefs I felt it important to share what I call the Foundations of Release Management, a common fabric that to be used for each set of custom designed Release Processes.      

Goals for Release Management

  1. Help Development groups get their changes to Production efficiently and successfully
  2. Ensure controlled, systematic and documented Software Releases
  3. Use readiness checklists based on agreed to standards instead of emotion based Go/No-Go meetings
  4. Communicate details related to Releases so everyone who needs to know is informed
  5. As needed function as a liaison between Development Groups and Operations, Governance, Help Desk & others

What is Success for Release Management

  1. Work with all individuals gracefully and in a respectful manner because everyone is an Internal Customer
  2. Production deployments meet compliance requirements set by Governance
  3. Releases deployed to Production in a timely manner without the need for rollback or causing customer impact (i.e. Production deployment should Do No Harm or Production environment should be as stable or more stable than before the change)
  4. Communicate the right amount of Release related information to the right people at the right time so they can be successful in their roles (i.e. No Surprises)
  5. Limited or no Post-Release issues found in Production

The common fabric of all Release Management Processes

  1. Introductory planning with Development groups (one-time tasks)
    1. Team make-up
      1. Waterfall, Kanban or Agile
      2. Desired Production Release schedule
      3. Review Tools to be used by Development groups, standards for change tickets, source control and Code repository for builds
      4. What to expect for versioning of packages & Releases
    2. Environments
      1. Confirm which environments to be used for Non-Production, Production, Training & DR
      2. Confirm management of deployment schedules for last Non-Production environment (considered Staging), Production, DR and Training
    3. Validations
      1. Confirm validation teams for each Environment, including agreement on usage of non-Development groups
      2. If possible, establish standard validation times and validation processes for each Environment
      3. Establish Release Gates for critical environments (typically covering pre-Stage, Staging & Production), see below for more details
    4. Communication
      1. Main Development group member(s) that Release Management should communicate with
      2. Establish Communication Group that works for particular Application. This could include any combination of Business Owners, Stakeholders, Development group, Help Desk or Internal User group.
      3. Establish information portal to be used for Release Management information
    5. Monitoring & Reporting tools
      1. Understand what is currently Monitored & what type of monitoring available (typically made available via Operations Group, used to confirm Release success & acceptable Deployment windows)
      2. Understand available Alerting (used to confirm Release success) 
    6. Document above agreements
  2. Desired Development group activities participation (in order to collect needed Release information)
    1. Scrum ceremonies as makes sense (as a Chicken)
    2. Scrum of Scrum meetings
    3. WaterFall planning and other update/planning meetings
  3. Release related Communication
    1. Weekly update of upcoming/future deployments to Application Communication Group
    2. Help with communication related to unplanned events or issues
    3. Confirm deployment impact notification is communicated to customers
    4. For deployments – specific notifications related for Application Communication Group
      1. Deployment coming soon
      2. Deployment started
      3. (as applies) Issue with Deployment
      4. Deployment complete
    5. Post-Deployment report providing details of success or failover of the deployment
  4. Release Planning
    1. Regularly scheduled meeting with Development group, providing opportunity:
      1. For Development group to request future deployments not yet known by RM
      2. To review to-do items for already scheduled deployments
      3. To review lessons learned from previous Releases
    2. Documentation of Release details
      1. Key dates for each Release added to a shared Calendar
      2. Add details for each Release to Release information portal
    3. Production Deployment window planning
      1. Analyzing customer impact for each deployment
      2. Creating estimated deploy window timing
      3. Identify which team members need to be involved in Production deployment (see Appendix below for examples)
    4. Leading Development group & Ops deployment planning meetings
    5. Managing Change tickets for environments that RM manages schedule
      1. Create Change ticket 
      2. Requesting needed approval(s) outside of Governance
      3. Requesting approval for Change ticket in a timely manner (i.e. within Governance requirements)
      4. Representing Change ticket at weekly Governance (i.e. CAB or Change Advisory Board) meeting
  5. Managing Release Gates
    1. The output of the Release Gates is a checklist to be used by the Development groups to identify the status or completion of a stage of the Release (i.e. Release is ready to proceed to next environment)
    2. RM tasks during testing in environment before Staging
      1. Identify Release ticket for Release
      2. Confirm Staging in and out schedules as well as Feature Freeze & Code Freeze schedules
      3. Confirm Directions for deployment are available and reviewed by Development group & Operations and request updates as needed
    3. Development group tasks to complete before Release packages deployed to Staging
      1. Confirm Directions for deployment are finalized
      2. Confirm list of change tickets for the Release are linked/associated to the Release ticket
      3. All change tickets and their related sub tasks are compliant and closed
      4. All agreed to Code Testing has passed to agreed to standards (e.g. X% passed, no Sev2/Pri2 or higher bugs introduced)
      5. All agreed to Performance & Security Testing has passed to agreed to standards
      6. If applies, packages are moved to shared Code repository for deployment needs & future reference   
      7. Verify/Confirm contents of build – verify or confirm the code build/package includes all changes expected in the Release (i.e. all code commits from tickets linked to Release ticket are included in the build)
    4. RM tasks before entering Staging environment
      1. Creates Non-Production Change ticket
      2. Creates Draft version of Production Change ticket
    5. Development group tasks to complete before Release packages deployed to Production
      1. List of Known Issues of the Release provided
      2. Rollback procedure has been validated (can be done in Staging or before)
      3. All agreed to Code Testing has passed to agreed to standards (e.g. X% passed, no Sev2/Pri2 or higher bugs introduced)
      4. All agreed to Performance & Security Testing has passed to agreed to standards
    6. RM tasks before entering Production environment
      1. Confirm Code repository is locked down to eliminate additional modification to Release packages
      2. Confirms Production Change ticket is approved
    7. Confirming health and stability Post-Release
      1. Monitor Post-Release Incidents created, identify which are caused by my recent change
      2. Be aware of site impacting issues related to the Solution, typically by having visibility to health checks and/or system monitors & alerts.  
    8. Continually reviewing the Release Gates with Quality teams and Environment team on for possible improvements
  6. Managing Production Deployment window
    1. Create meeting invite before deployment
    2. Lead the deployment call, confirm starting & stopping times of various tasks and status during the deployment window
    3. Confirms Change is completed and dismisses the team
    4. As needed, schedule Post-deployment meeting & documentation
      1. Retrospective of deployment
      2. Update post-deployment details document
      3. Update information portal


  1. List of possible groups that would be part of the Production deployment window
    1. Development group members
    2. Operation team members
    3. Validation team members
    4. Support team members
    5. Product Owners, Business Owners and any other group of people that need to be invited (note that providing optional invites is helpful for some people for extra awareness of the deployment)
Posted by: Jeff Timmins | February 28, 2017

Release Management feels like UPS sometimes

When I think about Release Management I try to ways to communicate to others at work so they better understand why I do what I do. Sometimes “Safe & Successfully Production deployments” just doesn’t do it. Then I started thinking … yeah, I’m like a UPS driver!

ups-tracking_35 I makes total sense if you think about it, right? The way I think about it, if I’m a driver I shouldn’t be thinking or caring that much what is in a package, I should just care that it going to the right place, in the time promised … and that the package will not kill me! Really, I mean if the package is radioactive then I’d say the UPS driver would care about it being in his truck (I’m guessing they have Mr. Yuck stickers but I’m not sure). Same thing with some phone batteries and other live animals. Anyway, I see safety like a code change passing test in Pre-Production – if it passes testing before being deployed to Production it is safe.

And about the address, can you image if dispatch said “Just ask Joe where to delivery this package, he knows and then Sally about the big brown one” and then the driver runs around looking for Joe and Sally to see if they remember. This feels like directions to me – you cannot say “deploy the fix, Fred knows it” and hope to have an environment that allows people to go on vacation.

Then when I think about repeat customers all stories I’ve heard about stores doing nice things for the UPS drivers that take care of them I think of how a Release Manager cares for (i.e. protects) the Operations team.

Like all analogies this one breaks down at a certain point but I think get the idea.


Older Posts »