(This post was also featured on Techerati.)

As more organizations are moving towards modern development practices, they are mirroring established engineering models of fast-moving companies like Netflix & Spotify. This is a big shift in practices for traditional companies who used to operate in command-and-control policies with project plans and 3 year programs; they are now allowing engineering teams more autonomy and freedom. However, to ensure this model is maintained, engineering teams need to demonstrate that this model does work better, and ensure their customers get the benefits they’ve been promised.

But what are the steps engineering teams can take to start delivering on the promises that have enabled the shift to autonomy?

Understand the end service, not just your task

I’ve worked with many teams where some engineers are laser-focused on their task. The teams that shine and get recognized in the longer term are the ones that are thinking about the overall solution, not just the part you are coding. When focusing only on a small part, developers often miss a dependency, or a key user interaction. This creates rework, and loses faith from the product owners.

Watch the customer use what you’ve built

How many times has a feature been released, the engineering team celebrates, but then a week later, there is high-priority functionality that needs to be implemented? That’s often because the app will work from one user perspective, or from a theoretical perspective, but not how the actual customer will use it. Actually watching the customer talk about how they interact with your application and what they would like to do in the next release will help the success of the feature as well as reduce re-work.

Release early and often

The longer a team is working on a feature or functionality without customer feedback, the less likely it will be that it’s what the customer is looking for. On one of my previous projects, my team kept pushing back the release because we wanted the perfect landing zone for applications. As a result, what we released was feature-heavy in monitoring and security, but feature-light in the developer experience. The mismatch led to long hours to remediate the issues, and this could have been avoided if we’d done incremental releases.

Note: If tools are preventing you from releasing often - raise that up the chain or make the case for creating your own. With the tools available in the market, technology should not be a blocker.

Demo, demo, demo

Similar to the last point, the best way to know what you’re building is what the customer wants is by demoing your work. The last mile always takes the longest, so demo your product in increments. If you explain to the audience what’s ready, what is not, and what you are seeking feedback on, they will appreciate the opportunity to provide input. They will also have visibility into the progress, so together you can identify if the overall project deadlines are on track.

Go on call

If you’re scared to support your own feature, that probably means you don’t have confidence that it will work. Having bug fixes as someone else’s problem will give you less visibility into the pain points and will result in work coming in from ‘problem management’. If you are part of discovering and understanding bugs, you can talk more thoroughly with the product teams on why certain fixes needs to be prioritized. This will help your team get more ownership, and start eradicating dreaded technical debt as you can fix it from the customer perspective.

Companies are making the shift to ‘engineering first’ on the basis of the promise of ROI and value proposition. We’ve heard the reasons: faster time-to-market, customer-centricity, less downtime. But to ensure these models are maintained in large organizations and we don’t loop back to overly-detailed 3-year Gantt charts, let’s prove to our customers that this way is better!



DevOps Insights Directly to Your Inbox!

Join thousands of your peers and subscribe to our best content, news, services and events.

Jatil Damania

Director of Delivery

Jatil is driven by helping organizations support their people to get the best from technology across both startup and enterprise organizations. Having worked in various roles internationally, Jatil is always keen to explore new practices and methods that help take the industry forward. He is currently the Director of Delivery at Contino - supporting companies in adopting modern software practices to enable faster time to market and greater customer satisfaction.