Posted by: Jeff Timmins | December 2, 2016

Join my Release Management team


Looking for a job, experienced or interested in Release Management? I’m building a team to spread Release Management process across Donnelley Financial Solutions.

Currently my team of off-shore Release Managers support 4 different Solutions but we are expanding to support about 40 Solutions! For that effort I have 3 to 4 openings for Releases Managers in multiple US locations. Those locations are


Here is the Job Description

Be part of the Release Management team as it grows to become the central part of managing Releases for Donnelley Financial Solutions (DFS). Responsible for successful deployments, documentation, risk mitigation & communication for Releases as well as Incident Management for the same solution. Responsibilities may cover one major solution, a group of related solutions, or helping our global team with multiple solutions. Most Releases are code related but some also include infrastructure changes.


  • Participate in reviews of current Release Process to find and implement improvement as needed
  • Build & foster relationships with Development, QA, Product Management, Business Owners, Product Support and Executives
  • Work with the Development System of Record (typically TFS) and Change Management ticketing system (ServiceNow) to plan, document, communicate Release details as well as prove Release readiness. In addition, provide transparency and visibility throughout the release process.
  • Track & Manage Software releases through Pre-Production environments to Production
  • Manage risks and resolve issues that affect release scope, schedule and quality
  • Conduct release readiness reviews, milestone reviews and business go/no-go meetings while at the same time understanding system and application dependencies
  • Lead work-hours and/or off-hours Production deployments
  • Troubleshoot deployment related issues as needed
  • Perform other related duties and participate in special projects as assigned

Required Skills

The duties and responsibilities described above are the essential functions of the job.  The qualifications below are representative of the knowledge, skills, and/or abilities required.  Reasonable accommodations may be made to enable individuals with disabilities to perform the essential functions.

  • Bachelor degree and with 2-5 years of relevant work experience OR demonstrated ability to meet the job requirements through a comparable number of years of applicable work experience.
  • Experience with System of Record ticketing products, preferring Microsoft TFS & ServiceNow.
  • Experience working with Development and QA teams.
  • Experience working within Waterfall, Lean and/or Agile SDLC processes.
  • Experience working with Build process is preferred.
  • Able to apply broad work experience and knowledge to the Release process.
  • Excellent communication skills with ability to state messages in a clear manner by using language that is easy for others to understand. Able to explain programs policies and procedures in language that is understood by others.
  • Able to apply excellent functional computer knowledge in utilizing Microsoft Windows, MAC, or other technical tools in completing assignments. Able to apply expertise in all the tools or applications used to complete work assignments.
  • Able to modify communication style both formal and informal to match the appropriate level of the audience targeted. Requires strong understanding of the impact of a message on the organization or customer. Able to write with the clarity and precision necessary for the work being performed.



Posted by: Jeff Timmins | November 30, 2016

What to call that Release?

A Release is a Release is a Release? G. Stein (revised)

Are names of Releases important? Should the Software/Service Industry care what we call it Internally or Externally?

From my memory of the shrink-wrap days of Microsoft, they put out regular Releases, Service Packs and Hotfixes (KBs). The today’s Cloud World we see fun names for Releases “Winter ’17” or “Serengeti” but Service Packs and Hotfixes are not well published. When you see a version like “” you get the hint that this is not the original Release but it doesn’t scream “I’m a Hotfix”. Customers of SaaS vendors that throw around Hotfix too many time typically move on to another solution.

Why should we are about Release names anyway? Why can’t we just call each Release brucesBruce? I mean we could call everything Bruce and while that would be fun and easy to remember it might be confusing for normal people. But I digress.

Release names are important! They help us understand and easily discuss what change happened + it sometimes helps understand why the Release was important. Great but what about “fixes” to the main Release – should they have distinguishing names as well? My vote is “Yes please!” for the same reason that Release name or number should be unique – I’d like to know what Major Release that fix was associated with. This comes in handy during Support calls (what version are you using?) or building a Non-Production environment (I need version X in Staging please) or discussing past or upcoming Releases with Staff (Release Y for Project Llama on Saturday, Release 1 for Project Sam on Tuesday).

Great, names are important but what about the term “Hotfix”, is that necessary to use anymore? I have to admit I have used it many times over the years as an Internal label but I’m being challenged to stop that practice. Why was it important to use before? Because I wanted to track problematic Releases and look for trends that caused it. (Due to tracking I was encouraged to decrease my Release schedule in late December and early January, when I did Release quality increased!) That said, my tracking needs don’t require the label “Hotfix” to be shared with 400 Internal Customers. When it is shared, those Internal Customers could start to develop a poor attitude towards the creators of the code. As long as I have a build number or use a label like “update 1” I can track the Releases and keep track of which “update” was planned and which one requires a Root Cause Analysis (RCA).


Going forward I’m dropping the Hotfix label when communicating Release names – how about you?

Posted by: Jeff Timmins | June 30, 2016

Release Management because no one is perfect

To really show imperfect I am I’m going to finish this blog Friday

Posted by: Jeff Timmins | May 30, 2016

Invisible Release Management

Can you see your Release Manager? Is “No News” the same as “Good News”?

The other day I was part of a meeting where Managers gave “shout-outs” for a job well done. Maybe I’m a little too self-confident but I kept waiting for someone to mention my name.

Not surprisingly that comment never came. Then I remembered … I’m the invisible man … no wait, I’m the Invisible Release Manager!

I use the term “invisible” because the Release Manager role is not even noticed if the job is done right. Because of that I really shouldn’t think that anyone would notice. In my first Blog entry titled RM Charter #1 I wrote about the same concept but honestly it has been awhile since I thought about it:

“In addition, RM done well is an invisible process to the customer and to the company as a whole.  This goal is definitely applicable to SaaS (customer focused) and thus easily transferable to a SaaS company.”

I love doing my job well and I have to admit I would love it someone actually too the time to notice and provide positive feedback in a group of my peers but I shouldn’t expect it. Hopefully your management or other leaders are giving you positive reviews of your work – if not I encourage you to find a group of peers that will.


Posted by: Jeff Timmins | April 30, 2016

Life can be humbling

Life can be a humbling experience. All around us are examples of things we don’t know as well as we would like. This is a reminder that Release Management is no exception to that rule. The key is to understand this is part of the process of adding value to your organization.

I purchased a car needing more work than originally thought (an example of a humbling CVJointconversation with my wife … create idea for another blog … maybe) so I’ve asked my neighbor for help with some of the repairs. I need lots of help as I have troubles changing my own oil! Per a Auto repair shop’s report I tell my neighbor the CV Boot needs to be replaced (example pictured here) and he starts going on about re-manufactured this, consider the source of the re-manufacturing, where to look for it here and my head starts spinning. After two more conversations and multiple internet searches I am finally able to have a conversation about how to make the correct purchase. Cannot wait for the learning experiences related to the actual repair!

Being a Release Manager can be very humbling as well. As an RM I believe it is important to understand at least the basics of the Solution you support. If you don’t then your value to the organization is diminished (important difference between Release Management and Release Coordination – RMs provide more value). Each time I start a new job I have to learn a new the Architecture and process flow. The task of learning can take a few months and my only advice is to be patient and take great notes – in time you will be comfortable.

Lately I’ve been adding more Solutions to my Release Management responsibilities while hiring other Release Managers to back-fill the Solutions I’ve mastered. Because of that I find myself learning a new set of Solutions (i.e. being humbled again). I find it especially challenging to be an expert in one part of the Organization and someone learning from scratch in another part of the Organization. In time I’ll add the value I want but for now I have to be patient and humble.


Posted by: Jeff Timmins | February 26, 2016

Why Release Management is important

I heard a story the other day about a SaaS provider (disclaimer – I have no connection to this company) that I thought should be shared. This is a great example of why Release Management is an important part of an SDLC and why I think my job is important.

Here is the story [with comments], names removed to hide the guilty.

The users at “Company A” use a solution from “SaaS Provider B”. The users at Company A reported that they were unaware that SaaS Provider B performed a software update [Strike #1 and Rule #1 – inform thy users!]. Sadly SaaS Provider B also introduced a new bug into Production during the software update that Company A didn’t know about [Strike #2 – not good!].

The impact of the newly introduced bug was that the program didn’t actually save all the important/critical changes when users selected the save function [Strike #3 – I’d call that a Sev 1 Bug]. On top of that, Company A then used the SaaS solution to submit their very important paperwork, thinking their important/critical updates were actually included [yikes!].
In the end Company A had to re-submit their paperwork [embarrassing, costly, etc.]. In addition they decided to look for another SaaS provider. 

Regardless if this is true or not (I’m fairly sure it is), it is a good reminder of why it is a good idea to employ a Release Manager on your team.
Posted by: Jeff Timmins | February 19, 2016

DevOps communication done well

Recently I saw a great example inside my company of DevOps communication done well. It was related to a minor update to our On-Prem instance of TFS 2015. This time I’m one of the customers and it was very nice to see that someone took the time to share “inside Release information” with me & the rest of the team.

This was is what the email communication looked like regarding the schedule:

Having not heard any concerns from anyone about the time window for this upgrade, we will be proceeding to update TFS from: Friday, March Xth 23:00 ET to Saturday, March Xth 07:00 ET.  Scrum Masters, please let your teams know that TFS will be completely unavailable during this time period.

This was is what the email communication looked like regarding the changes:

Update includes new features in Backlog


  • Improvements on the web portal: commit details summary is easier to read, and an improved experience for cloning Git repositories.
  • Backlogs: multi-select on all backlogs, drag any item to an iteration from anywhere, Add panel to the iteration backlog, line on the burndown indicates actual capacity, configure settings directly, add/remove users in the sprint plan, and multiple activities per team member in planning capacity for a sprint.
  • Kanban boards: query on columns, card coloring, tag coloring, inline renaming of columns and swimlanes, reorder cards when changing columns, configure settings directly, and hide empty fields on cards.
  • Work items and tasks: tasks as checklist, link to branches and pull requests in work items, task board card coloring, and limit values shown for Work Item type in queries.
  • Build: improved access control for resources, improved source control integration, usability fixes in Build Explorer, and parity with XAML builds for label sources and client-side workspace mappings.
  • Testing: export test outcome for manual tests and test result retention policy improvements.
  • Dashboards: 100% customizable with new widgets and multiple dashboards.
  • Version control: use Git and Team Foundation Version Control in the same project, history and getting started
  • Extending: Service Hooks tab available on-premises

More  detailed  information can be found in Release Notes : Update is installed to non-production environment so you can try it here:


Posted by: Jeff Timmins | February 9, 2016

Loving the Salesforce Trust

Something I’ve always loved about Salesforce is their Trust site. They have made it SF_Calendaravailable for years and it has been my favorite examples of SaaS customer communication done well. They basically say to their customers “we have nothing to hide.”

When I looked at it again the other day I found two features that were new to me. One is the Calendar section and the other is Performance section. Check it out and try to do it for your customer facing solution!

Posted by: Jeff Timmins | January 27, 2016

Ensuring quality

Review, review, review. Verify, verify, verify. Review & verify some more. Such is the life of a Release Manager but is the motivation of a lack of trust or something else?


In the world of political correctness, throwing around the term “lack of trust” is not that popular. Sadly, sometimes it feels like trust is an issue for a Release Manager but maybe there are more socially acceptable words to use?

While thinking of this I noticed something in my email that was very helpful. Since my resume is in a few databases I see a number of RM openings via email. I don’t typically pay much attention but an opening from Exeter, NH caught my eye (I love that corner of the world!). When reading it the following (highlighted) from the Responsibilities section stood out to me:

  • Responsible for Release quality control within Change Management procedures, including the review of pre-Change testing, …
  • Ensures the highest level of quality in technology implementation/releases via thorough analysis of submitted releases …
  • … ensure a repeatable and traceable approach to release processes and procedures.
  • Anticipates release/deployment problems and opportunities and initiates corrective action and/or enhancements when needed.

Bingo! – great terms and phrases for a Release Manager to use to communicate the task of “Ensuring quality.” In particular:

  • Responsible for Release quality control – the need to check & verify details is because the RM has to answer for the Release quality.
  • Ensures .. via thorough analysis – part of the quality control is to dig through the details to confirm the needed information is presented as well as correct.
  • Ensures a repeatable and traceable approach – part of the requirements for most Change Management processes + needed to guarantee deployment success.
  • Anticipates … problems … initiates corrective action and/or enhancements – not only is the RM responsible for review but to make or request corrections as needed.

When asked, a Release Manager could say that they require Release information because they don’t trust the rest of the team. Another option, and probably an easier way to win friends and influence, is to refer to state that the information you require is to ensure overall Release quality and to fulfill the requirements of the Change Management process.

Bingo, issue resolve!


Posted by: Jeff Timmins | October 31, 2015

Making the Release Process better

Not everyone values Process. Not sure why, guess they would rather “shoot from the hip” (a.k.a. do whatever comes to your mind at the time). That doesn’t work for me. I love Process. I want a task to be done the same way each time. Reasons are numerous but mostly because a followed Process stands up to any Audit and internal customers deserve to know what success looks like.

make-it-better-mobileAdditionally, an important part of a Release Management Process is to continually review it for possible improvements. For that I suggest a yearly review of your Processes and if possible a review each six months. This is helpful because parts of the RM Process could be confusing or completed incorrectly or no longer needed because of technology improvements. In the end, you can usually do something to Make It Better.

Here are the steps to follow to complete a Release Management Process review:

  • Review the current Process, noting parts that you (as the owner of the Process) think needs revising.
  • Interview your internal customers (Product Owners, Scrum Masters, Dev & Test leadership, IT Operations, Support, etc.) asking them what is working, what is not working and what suggestions they may have to improve the Process.
  • Interview your manager and their manager asking them the same questions as above + their thoughts on your success implementing the Process.
  • Now with feedback from others, review the current Process again, noting other parts that need revising and parts that need minor revising to become more acceptable to others.
  • Create a Draft of the revised Process.
  • Share the Draft with a few trusted reviewers and edit the Draft as needed.
  • Now send out out the revised Process to all internal customers for a final review.
  • Publish finalized version after making the last minor edits from the final review.

This will take some time but it is time well spent.



« Newer Posts - Older Posts »