Features Hub Opinion

Engineers have asked for more autonomy: now we need to prove why

Mon 21 Jan 2019 | Jatil Damania

To ensure modern development practices are maintained in large organisations and we don’t loop back to overly-detailed three-year Gantt charts, engineers need to prove their value to customers, writes Jatil Damania, director of delivery at Contino

As more organisations 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 three-year programs.

Traditional companies are now allowing engineering teams more autonomy and freedom. They have made this shift to ‘engineering first’ on the back of promises of higher ROI and value proposition.

But to ensure this model is maintained, engineering teams need to demonstrate that this model does work better and provides its customers the benefits they’ve been promised. If they don’t, these models may disappear from large organisations and we may revert back to overly-detailed three-year Gantt charts

But what are the steps engineering teams can take to start delivering on those promises that spurred this autonomy-shift?

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 recognised in the longer term are the ones that are thinking about the overall solution, not just the part they are coding.

“The teams that shine and get recognised in the longer term are the ones that are thinking about the overall solution”

When focusing only on a small part, developers often miss a dependency or key user interaction. This creates rework and results in the produce owners losing faith.

Watch the customer use what you’ve built

How many times has a feature been released, but then a week later a high-priority functionality is found that needs to be implemented? That’s often because the app will work from one user perspective, or even from a theoretical perspective, but then the actual customer jumps in and uses it differently.

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 be an enabler not a blocker.

Demo, demo, demo

Similar to the last point, the best way to know you’re actually building what the customer wants is to demo 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.

“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”

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 the team that is discovering and understanding bugs, you should talk more thoroughly with the product teams on why certain fixes need to be prioritised. 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 organisations and we don’t loop back to overly-detailed three-year Gantt charts, let’s prove to our customers that this way is better.

Experts featured:

Jatil Damania

Director of Delivery
Contino

Tags:

Agile DevOps digital transformation software development
Send us a correction Send us a news tip



Do NOT follow this link or you will be banned from the site!