How to Run an On-Site DevOps Discovery Week, Step by Step

An on-site DevOps discovery week is one of the most valuable things a transformation programme can do, and one of the most frequently skipped. Many engagements begin with a questionnaire, a few video calls and a stack of architecture diagrams. Those inputs are useful, but they are second-hand: they describe how people believe work flows, not how it actually flows on a Thursday afternoon when a release is late. Sitting with the teams, watching a deployment happen, and joining the conversations that never make it into documents produces a different and more reliable picture. What follows is a sequenced method for planning and running a discovery week that rests on first-hand observation and hands-on participation.

Why go in person at all?

Remote discovery is cheaper and faster to schedule, so the case for travelling needs to be clear. Three things are very hard to capture from a distance. The first is informal flow: the hallway question that unblocks a build, the spreadsheet a release manager keeps on a second monitor, the approval that happens by shoulder tap. The second is friction you can feel: waiting for an environment, hunting for credentials, rerunning a flaky job. Engineers often stop noticing these because they are routine. The third is trust. People speak more candidly to someone who has sat beside them for a day than to a face in a video grid.

Being physically present also changes the consultant. Watching an engineer spend a frustrating stretch on a manual step is far more persuasive, to you and later to leadership, than reading that “deployments involve some manual work”.

Step 1: Agree the purpose and the boundaries

Before anyone books travel, write a one-page charter with the client sponsor. State what the week is for (understanding the path from code change to running service), what it is not for (assessing individuals or ranking teams), and what will be shared afterwards. Circulate it to every team you plan to visit. A discovery week that feels like an inspection will produce polite, guarded behaviour, which defeats the point.

Step 2: Choose a representative slice

You cannot observe everything. Pick a small number of teams that together represent the organisation’s real variety: one that ships often, one that ships rarely, one that owns a legacy system, and one that sits on a critical shared platform. Ask each team to nominate a typical piece of work in progress that you can follow from start to finish during the week.

Step 3: Prepare, but lightly

Read the existing diagrams and process documents, then deliberately hold your conclusions loosely. Prepare a short list of open questions rather than a checklist to tick. Arrange practical access in advance: building passes, read-only access to the CI system and ticket tracker, and a quiet space where you can write up notes each evening.

Step 4: Shadow real work, not demonstrations

This is the core of the week. Sit with an engineer while they pick up a ticket, write and test a change, open a pull request and take it through to production. Do not ask for a demo; demos are rehearsed and skip the waiting. Instead, ask to observe whatever they would be doing anyway.

As you watch, record facts rather than judgements:

• Every handoff, with who it went to and how long it waited.
• Every manual step, including copying values between systems.
• Every point where the engineer had to ask someone for permission or information.
• Every rerun, retry or workaround, and the reason given for it.

If you are invited into an on-call handover, a release meeting or a post-incident discussion, accept. These rituals reveal more about how teams coordinate than any interview.

Step 5: Get your hands on the system

Observation is powerful, but participation is better. Where the client agrees, try to make a small, safe change yourself, guided by a team member: update a configuration value, add a log line, push it through the pipeline. Doing it with your own hands exposes friction that is invisible from the observer’s chair, such as the undocumented environment variable, the approval form nobody mentioned, or the test suite that only passes on a particular machine.

Pairing in this way also flips the dynamic. Instead of a consultant asking questions, there are two people solving a small problem together, and engineers often volunteer insights they would never offer in an interview.

Step 6: Run a short hands-on workshop mid-week

Around the middle of the week, bring a mixed group together for a working session rather than a presentation. A practical format is to map one recent change on a whiteboard, from idea to production, using the facts gathered during shadowing. Participants correct the map, add the steps they know about, and mark where time was lost. Because people are physically in the room with markers in hand, the map becomes a shared artefact rather than a consultant’s opinion.

The patterns that emerge here often confirm what you have seen in the field. For more on spotting where work stalls, our guide to finding delivery bottlenecks before and after an engagement offers a complementary lens.

Step 7: Write up daily, with evidence

Each evening, convert notes into short observations backed by what you saw. “A database schema change required sign-off from three groups and waited across two days” is far more useful than “governance is slow”. Share a draft summary with each team before the week ends so they can correct misunderstandings. This keeps findings accurate and maintains the trust you have built.

Common pitfalls to avoid

A few mistakes recur often enough to name. Spending the week in meeting rooms with managers, rather than at desks with engineers, produces a tidy but unreliable picture. Arriving with a favourite toolchain in mind tempts you to notice only the evidence that supports it. Over-scheduling leaves no slack for the unplanned conversation at the coffee machine, which is frequently where the most candid information surfaces. Finally, leaving without a clear readout date makes teams wonder whether anything they shared will be used. Guard against each of these deliberately and the week will be far more productive.

Step 8: Close the week with a joint readout

End with a session attended by the teams you shadowed and the sponsor. Present observations, not verdicts, and invite the people who did the work to explain the context. Then agree a very small set of first experiments, owned by the teams themselves. Improvements that come out of a shared, first-hand understanding tend to stick far better than recommendations delivered from outside. Our article on bringing development and operations closer through consulting practice covers how to keep that collaboration going once the visit is over.

Practical considerations

Distributed teams. If teams are spread across cities, prioritise visiting the locations where the most handoffs occur, and supplement with remote shadowing for the rest.

Security and confidentiality. Agree in writing what you may see and record. Never photograph screens without explicit permission.

Your own learning. Consultants who stay close to hands-on work tend to run better discovery. Attending live workshops, lab sessions and developer meetups keeps your skills current and reminds you what practitioners actually wrestle with. In Bengaluru, listings on Bangalore Orbit, a city guide to workshops and tech meetups, are one easy way to find such sessions between engagements.

Conclusion

Questionnaires and diagrams tell you how an organisation describes its delivery. A week of sitting beside engineers, making a change yourself and mapping the flow together in a room tells you how delivery really happens. That first-hand understanding makes every later recommendation more accurate, more credible and more likely to be adopted, which is ultimately what a transformation engagement is for.

Kabir Malhotra