Day In The Life of a Developer

Every company is developing software. Whether it is external facing applications, or internal applications, or both. Every company wants to be more efficient at developing software, as it has a direct correlation with the company’s success. GitLab is positioned to help every company create better applications by providing capabilities throughout the application delivery process including development, operations and security. In the past, there was not one solution to help companies develop software from idea to deployment. Companies relied on purchasing specific products for specific capabilities, and/or used manual methods such as email, spreadsheets, and documents to keep track of their development.

The purpose of the Day In The Life of a Developer is to understand the company’s current development process, look for opportunities for improvement, and relay those findings back to our stakeholders. These improvement opportunities can then be communicated back in the form of an executive brief where prescriptive guidance can be shared, providing an explanation of where, how, and at what level of effort may be required as we partner with the customer to make those improvements.

A Day In The Life of a Developer is a demonstration by the company that allows for deeper discovery around how the process currently works and where areas can be improved. The demonstration usually can be done within a 90 minute meeting, with appropriate attendees, and active discussion regarding the process.

Process

1. Qualify the Opportunity for a Day In The Life of a Developer
2. Educate potential participants and obtain commitment to the workshop
3. Prepare for the Day In The Life of a Developer
4. Initial customer pitch
5. Plan the Day In The Life of a Developer
6. Day In The Life of a Developer Demonstration
7. Executive Briefing - Summarize the findings
8. Contribute back to this framework

Qualify

Day In The Life of a Developer requires commitment by both the GitLab field teams and our prospects and customers. To ensure the appropriate return on this investment of time, the opportunities should meet the following criteria:

• The account has a total addressable market of at least 100 GitLab users
• The prospect or customer is focused on improving their software delivery performance
• We have a relationship with the economic buyer
• We have identified and established a relationship with the champion
• We suggest pitching a Day In The Life of a Developer prior to a Proof of Value (PoV) to understand bottlenecks and development opportunities important to the company’s stakeholders. This also gives us an opportunity to agree upon success criteria for value drivers if a PoV is required for deal closure.

In case a Day In The Life of a Developer is conducted by a customer success manager (CSM), the following criteria should be met:

• We have identified and established a relationship with the champion
• The account has a total addressable market of at least 100 GitLab users
• The customer has expressed a strong desire to improving their software delivery performance

Key indicators that the opportunity is well-suited include:

• There is a specific initiative to accomplish one or more of the following by a specific date
  • Modernize a specific application or applications
  • Deliver a new critical application to the market
  • Transform or objectively improve their ability to deliver software
  • Modernize their DevOps capabilities
• The customer is currently using some features of GitLab and is interested in how leveraging more of the platform will drive software delivery outcomes
• For customer success, a Day In The Life of a Developer should help uncover opportunities to expand into new use cases or improve current adoption by identifying bottlenecks in the current software delivery process
• An existing customer shows interest in adopting our Day In The Life of a Developer approach to drive software delivery performance

The scope of a Day In The Life of a Developer should always be clearly defined. A clearly defined scope ensures that the correct people are being included in the team and reduces the risk of time lost agreeing what should be focused on. For this reason, the scope of a GitLab facilitated assessment must always be within the DevSecOps space.

Education and Commitment

A successful Day In The Life of a Developer requires a commitment by the software delivery stakeholders and the personnel experienced with the various processes that constitute their development process. Without understanding the assessment process and its value to their organization, key participants will lack the commitment to ensure a successful Day In The Life of a Developer. Educate the prospect or customer on the benefits, process details, and the required commitment.

While a Day In The Life of a Developer is an advanced discovery workshop, it’s expected that initial opportunity discovery and technical discovery have been conducted.

Key Benefits

• Discovery and documentation of the Day In The Life of a Developer or “path to production” currently in place
  • Establish an agreed upon baseline from which to measure the progress of software delivery performance
  • Identify manual configuration touchpoints and handoffs and other bottlenecks
  • Create a process improvement roadmap
  • Understand the return on investment of a value delivery platform
  • Promote collaboration amongst traditionally siloed functions within the DevSecOps lifecycle

After the prospect or customer understands the process and its benefits, confirm commitment from the stakeholders and workshop participants by scheduling the facilitated workshop and/or interviews. Estimate the duration of the assessment and set the expectation that the documented software development process, recommendations, and readout will be delivered.

What is The Required Time Commitment?

Focusing on the goals and benefits listed above, the time required to complete a minimally viable Day In The Life of a Developer will vary from organization to organization. The workshop should NOT require exhaustive discussion and research. Depending on the availability and commitment of the various participants and stakeholders, the practice will take 90 minutes to two hours for a demonstration and discovery to take place.

Prepare

Usually, through discovery, there is some level of knowledge of customer goals and the current development process from a development perspective. The goal of the Day In The Life is to understand the entire development process from idea to deployment to production, and to look for areas of improvement throughout.

Prepare for the Day In The Life of a Developer, by organizing the information we already have about the customer and identifying areas we want to learn more about. This should include GitLab’s goals for the meeting which should already exist in the Technical Close Plan. The Technical Close Plan should have input from the SA, AE, and CSM, with the SA as the DRI.

Prepare questions in advance for the list of things we want to learn. Questions can be drawn from the GitLab Value Framework.

Choose an internal communications medium (ex. Google Doc or Slack) for real-time communication during the workshop. This will help the team with coordinating questions.

Pitch

The initial customer pitch, delivered by the SA, allows us to identify key stakeholders & get their buy in. The customer pitch should include:

• What is a Day In The Life of a Developer?
• What does a Day In The Life of a Developer entail?
• Who are the key participants involved in the Day In The Life of a Developer?
• What are some of the expected outcomes of a Day In The Life of a Developer for them?

During the pitch, the account team should strive to:

• Identify executive sponsor, stakeholders and participants
• Identify business objectives
• Identify an application/project for the Day In The Life demo. This is an important step as it focuses the discovery on a single flow where there is a clear beginning and end that has the potential to be measured for delays. The project should reflect a critical or typical development process, spanning idea to deployment, that the business is looking to improve. This must be completed prior to the start of the Day In The Life meeting

Here are some resources that can be used as starting point for the pitch: Customer pitch deck Internal pitch deck

Planning meeting with customer

Planning a Day In The Life of a Developer can be done within an hour or less, given the right expectation, focus and people involved. Below are aspects to be considered when planning the Day In The Life of a Developer.

Define a Day In The Life Of A Developer

• Who are the members of the team involved in developing an application?
• What application will be demonstrated to highlight development from idea to deployment?
• What context or conditions are being considered?
• What triggering event initiates the work flowing through the development process?

Day In The Life of a Developer Demonstration

• People
• Process
• Tools
• Workflows
• Questions

People

In order to help facilitate a Day In The Life of a Developer, a number of GitLab team members will be required to take part. The roles of these members generally fall into the following:

• Facilitator - A team member fully versed in the software development process who is responsible for leading the session; ensuring that discussion is staying on-topic, at the right level and at the required pace.
• Account Leader - The account leader’s responsibility is to ensure that the long term strategic vision for the customer/prospect is considered when discussing desired future state and they can also provide additional context to the current state.
• Scribe - A team member who’s primary purpose is to document the session, capture key metrics as they emerge which will later be used to create a current state schematic diagram.

Process

The process which we will go through, at a high level, is as follows:

1. Why we are here? (champion led)
2. Re-iterate expectations set in the planning meeting
   1. Start and end points for the Day In The Life of a Developer
3. Current state
   1. Initial process “walk-through” for the prospect or customer to demonstrate - A best practice is to share a current state diagram based on our (possibly limited) understanding of the customer’s environment to facilitate the Day in the Life discussion
      1. Capture people, processes and technology
   2. Analyze and identify bottlenecks and improvement areas.
      1. Time is limited - Use the list of discovery questions selected during prep and focus/“double click” on the areas where GitLab can help - avoid delving deep into areas that GitLab cannot affect
4. Design future state
   1. Review the expectations, to align the team on the target they are aiming to create
   2. Determine “right work” (which processes and steps are required for the future state to be optimal)
      1. Remove processes and process steps when they are truely unnecessary
      2. Add processes and process steps when they can optimize overall process time and lead time
   3. Creating an optimized work flow
      1. Aim to reduce the lead time (LT), process time (PT) and achieve a higher percent complete and accurate (%C&A) for every process block where prossible
      2. Utilize and leverage GitLab capabilities to improve the development process where applicable
      3. Use Lean countermeasures and improvement tools
   4. Ask the customer to prioritize what we’ve learned and ask if there’s anything we’ve missed
5. Develop transformation plan (likely completed async)
   1. At the end of the Day In The Life session, be ready to provide a date for the review of the draft output but avoid committing to a date for the final readout. Honoring timelines is important to maintain momentum in the opportunity and for the credibility of our champion. In some cases, feedback received from the customer has led to a complete rethink of the readout which can take longer than originally planned.
   2. Create a day In The Life Readout to present to the customer. The readout will include a review of their current development process and suggestions for how their process can be improved.
   3. For each process block transformation, capture the measurable target, proposed countermeasures, execution method, owner and timeline (later, status as well)

Tools

• Remote:
  • Zoom, MS Teams, or Google Meet
  • Diagramming tools
  • FigJam or LucidChart for Current State and Future State visualization
    • FigJam is not yet connected to Okta. Login using your Google account. Make sure you have a Full FigJam license with read-write access. (if you’re in read-only mode, you need to request a full license)
    • LucidChart is an IT-managed application. If you are unsure if you have LucidChart access, go to the Okta interface in your browser, then select “Search Your Apps” and see if LucidChart SSO is available. If yes, LucidChart has been assigned to you and you can launch it from Okta and collaborate on any LucidChart Documents your team has shared with you. If no, then LucidChart SSO has not been assigned to you yet.
    • If you do not have LucidChart SSO assigned to you in Okta, please navigate to the “access-requests” Project and submit an Issue requesting “Lucid Chart”. Assign the Issue to your Manager and add the IT::to do label. See example Access Request Issue.
    • If your Access Request is urgent, paste the link to your Access Request Issue into the #it_help Slack channel and @ mention it-help with a note on why it is urgent.
• Onsite:
  • Stickies
  • Pens
  • Large whiteboard

Example Workflows

1. Idea to Production
2. Response to Production Incident
3. Toolchain Upgrading and Maintenance

Idea to Production

Response to Production Incident

Toolchain Upgrading and Maintenance

Executive Briefing - Summarize the Findings

The final meeting as part of the Day in the Life of a Developer process is the findings and next steps presentation (though it’s called an executive presentation, it’s expected to be a two-way discussion). The high level topics of this meeting are:

1. Summary of planning outcomes; what process was to be mapped and what target goals were created
2. Summary of the current state mapping
3. Summary of the proposed future state mapping
4. Highlight the key differences, expected process and business benefits
5. Walkthrough of recommendations
6. Walkthrough and gain agreement for the transformation plan. The transformation plan should be built in conjunction with professional services to yield best results. Please read how to position professional services in an opportunity here
7. Define next steps and suggest a review date

Example template of the executive briefing can be found here. Please modify accordingly to suit your customer’s need.

It is recommended to review the executive briefing with your champion, key stakeholder before the final meeting to collect additional feedback. The goal is to then deliver it jointly to the broader team to gain agreement.

FAQs from customers/prospects

1. What’s in it for me - the customer?

   • Free, hands-on consultative analysis of their software delivery lifecycle, including their current state, future state, and areas of improvements.
   • Competitive analysis of where they are compared to their peers in the industry. This report contains the most recent benchmark values for the four DORA metrics (widely regarded as good measures of DevOps performance) State of DevOps Report 2021.
   • Recommendations on how to overcome visible or invisible challenges with a strategic plan to help them reach their future state.

2. What are typical outcomes for a customer?

   • TBD

3. Which teams are typically involved?

   • We start with application development team, quality engineering team, application security, then operations.

4. What’s the best place to start?

   • Pick the most business critical application or a representative application that has faster time to market requirement.

5. That’s a lot of time investment from our teams Or Our teams are busy with other projects.

   • It takes approximately 1.5 hrs demonstration to do a focused discovery for a Day In The Life Of A Developer.

Training and Enablement

How to Contribute

In the spirit of collaboration and iteration, please help to continuously improve this framework. Ways to contribute include:

• Create a merge request to improve this page
• Share your experiences in the #customer-success and #solutions-architects slack channels
• Provide feedback and/or updates to the pitch deck or provide links to your own variations
• Provide links to your facilitation recordings, summary documentation, and/or other artifacts to this page
• Collaborate in the #value-stream-discovery slack channel