Why software teams deliver
behind schedule & above budget
We have selected reasons and solutions from working with enterprise leaders in DACH. We discuss why these rarely get brought up by the teams, what indicators to look for and, what objections to expect.
Everything at a glance
Learn how other companies overcome cultural challenges associated with modernizing their IT.
Talent bottlenecks
Brick-and-mortar companies face talent bottlenecks as they struggle to attract and retain DevOps engineers. High hiring costs, turnover, and lengthy onboarding due to complex systems limit ROI. Engineers seek modern technologies, but legacy systems create barriers.
Indicators
Talent Bottlenecks are one of the easier problems to identify, usually characterized by these problems
Engineering positions remain unfilled for >6 months
Motivated & skilled employees wear out in <3 years
Hires lack specific skills and autonomy
36%
of software teams had adopted a DevOps approach in 2021
21%
of developers would like to acquire DevOps skills
36%
of developers would like to acquire DevOps skills
Potential objections
Companies are dynamic environments with many different interests in the mix. There will be objections
Fear of job loss
Existing bottleneck contributors might object for fear of losing their high leverage positions
Flawed incentives
Highly skilled individuals may prefer (unrealistic) skill-up programs across the company over simplification by tools because they lose their mentoring appeal
“Codesphere simplifies shipping software from writing and building code, to deploying and hosting.”
Peter Bissinger
Head of Department for Product Design and Partner Management @ Hausbank München eG
via Product Hunt
Inefficient workflows
Non-agile, inconsistent deployment workflows slow development as engineers wait for DevOps support. Lack of standardization leads to fragmented processes, and slow iteration cycles prevent delivered software from meeting business objectives.
Indicators
Inefficient workflows occur in many different places and can be identified by the following indicators
Agile development process with release cycles of >3 weeks >6 months
Software teams constantly delivering behind schedule or above budget
Developers pointing towards operations for delays and vice versa
Broken feedback cycles: Software does not satisfy requirements (and the team worked on it for more than 2 weeks)
There is another way
The above issues are the result of an inflated reliance on DevOps. What if there was another way that relied on 3 core principles?
Standardized workflows
Instead of having a fragmented landscape of workflow that don’t fit together, workflows can be standardized and streamlined.
Developer self service
Oftentimes, developers have to rely on operations for supportive activities. With a self-service approach, this dependence is eliminated.
End over-the-wall mentality
Ending ops & dev only focussing on their specific tasks without understanding the other fosters collaboration and faster processes.
Potential objections
Companies are dynamic environments with many different interests in the mix. There will be objections
Best practices already implemented
Existing workflows already constitute “best practices” → not true if any of the indicators apply
Strict quality control
Requirements for quality control do not allow more agile feedback cycles→ often more of a cover your back argumentl
“The platform's ease of use, collaboration tools, productivity features, and flexibility have impressed me, and I am personally convinced that companies looking to improve their development process should try it. I'm looking forward to everything we try and build with Codesphere and the team.”
Individual preferences unaligned with organization
Enterprise architects and engineers often resist major changes due to attachment bias, sunk learning investments, and perceived stability risks. Resistance to limiting customizability and prioritization of technologies that boost individual career prospects create misaligned incentives, hindering organizational progress.
Indicators
Typically these misaligned preferences can be spotted by these responses
Suggested changes are met with scepticism per default
Simplification is not welcomed but objected as “introducing limitations"
Let’s paint a picture
These issues are the result of an inflated reliance on DevOps. What if there was another way? Let’s paint a picture.
Simplification to increase developer experience
Simplification enhances developer experience, but internal opposition remains strong. A guided proof-of-value workshop can help demonstrate the benefits and loosen resistance to change.
Streamlined workflows
Misconceptions around opinionated best practices create resistance, despite their ability to streamline workflows and enable greater experimentation without imposing real limitations.
Potential objections
Companies are dynamic environments with many different interests in the mix. There will be objections
Loss of leverage
Existing DevOps cornerstone contributors might object because they loose leverage -> reaffirm them that they will be needed in a coaching capacity
Salary increases
Work experience with complex technologies (i.e. Kubernetes) rewards future salary premium → individually rational but not for the whole organization
