But as with any product team, you have limited resources and the need to balance both business and engineering objectives. So many stakeholders inform your developer experience roadmap that it can be difficult to prioritize.

Yes, you need a roadmap 

The biggest thing that distinguishes platform engineering from the top-down platforms of tech days of yore? Nobody has to use it. 

When you’re building any developer experience tooling — whether it’s an internal developer platform or portal or just a directory or better documentation — you have to build something that your engineers actually want to use. Your platform strategy — sometimes called a developer experience or DevEx strategy — should make developer lives so much easier that they need a really good reason to go off that golden path. 

Platform engineering requires a Platform-as-a-Product mindset, packed with user-centric design, prototypes and demo days. Your colleagues become your customers.

You not only need an internal product roadmap, you need to actively publish it within your organization. This way not only are you making commitments to solve your developer-customer’s problems, you are closing that feedback loop, so your platform team knows early and often if you’re building something that they even want or need.

Know your stakeholders

Perhaps even more than when you are working with external users, a platform team, as stewards of the developer experience, is beholden to many stakeholders. 

As Sergiu Petean from Allianz Direct pointed out, a common anti-pattern for platform teams is only addressing the single stakeholder of the software engineer. The larger the enterprise, the more regulated your industry, the more stakeholders you have to consider from Day One. 

At the insurance giant, his team initially highlighted eight different stakeholders that all bring different demands:

• End users
• Quality
• Security 
• Software delivery 
• Data
• Sustainability
• Incident management
• Compliance 

Later they realized the platform has the capacity to interact with even more teams. 

Work to build a relationship with each of your technical and business stakeholders. Learn what part of the software development lifecycle matters most to them. And then bring them into your feedback loops that impact your platform engineering product roadmap.

Learn to prioritize

The more stakeholders you identify, the even more feature requests you’ll receive. Yet, according to research by DX, the average team focused on developer experience is a fraction of the whole engineering org. That can seem overwhelming, but a platform engineering strategy is all about centralizing and solving frustrations at scale.

How can you possibly balance so many conflicting demands? HashiCorp’s platform engineering lead Michael Galloway recommends looking to remove the pebble in their shoe.

The biggest points of friction will be an ongoing process, but, as he said, “A lot of times, engineers have been at a place for long enough where they’ve developed workarounds or become used to problems. It’s become a known experience. So we have to look at their workflow to see what the pebbles are and then remove them.”

Successful platform teams pair program with their customers regularly. It’s an effective way to build empathy.

Another thing to prioritize is asking: Is this affecting just one or two really vocal teams or is it something systemic across the organization? You’re never going to please everyone, but your job in platform engineering is to build solutions that about 80% of your developers would be happy to adopt. 

Go for the low-hanging fruit

Another way that platform engineering differs from the behemoth legacy platforms is that it’s not a giant one-off implementation. In fact, Team Topologies has the concept of Thinnest Viable Platform. You start with something small but sturdy that you can build your platform strategy on top of.

For most companies, the biggest time-waster is finding things. Your first TVP is often either a directory of who owns what or better documentation. 

But don’t trust that instinct — ask first. Running a developer productivity survey will let you know what the biggest frustrations are for your developers. Ask targeted questions, not open-ended ones. You can get started inquiring about the 25 drivers of developer productivity — which socio-technically range from incident response and on-call experience through to requirements gathering and realistic deadlines. 

Mix this with informal conversations and pair programming with your devs to uncover big and small problems that need solutions.

As startup advisor Lenny Rachitsky suggests, you can rate each idea from 1 to 5 across the X of how impactful it’ll be to solve a problem and Y of how much effort it’ll take. Just make sure anything that shows up on that “guesstimation graph” meets the requirement that it solves a problem for a majority of your developers — because a platform team should never work for just one dev team.

Don’t forget to value quick fixes to help ease some pain. Following the agile practice of “walking the board,” prioritize features closest to Done. This allows for early wins to foster platform advocates, which can go a long way to increase adoption. 

Be open to changes

As CTO of Carta Will Larson put it, “If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.” 

Your roadmap is just that, a map — there’s always more than one way to go. You need to be ready to deviate and change your priorities. This could be a global pandemic or an urgent vulnerability patch. It could be the need to adopt a new developer technology because it will help you work with a big-name integration partner. 

Especially in a well-regulated industry, your cybersecurity and compliance stakeholders can influence a lot of change. Just because platform engineering is opt-in, doesn’t mean it can’t facilitate some mandatory changes too.

No matter what the reason, it’s important that you communicate any fluctuations to your internal customers, explaining why the roadmap priorities have changed.

Continuously measure

Engineering is a science, so we know you can’t improve what you don’t measure. This “metrics-backed intuition” as Diogo Correia, developer experience product manager at Pipedrive, calls it, fosters continuous improvement, not just for your platform strategy but for your developers too.

His team uses DX for quarterly developer surveys. Then it developed and open sourced a one-hour developer experience workshop to help dev teams not only surface their own struggles but to set individual team focus areas for the next Q. 

“It has an immediate impact in terms of the sentiment and priorities that they report in the next quarter,” he said. For example, a lot of developers complain about technical debt, but almost no devs want to spend time fixing it. This knowledge has fed into Pipedrive’s rotation of teams focusing on paying down that debt versus releasing new features.

“The workshops help by identifying the concrete services or libraries that any given team owns that most developers in the team are feeling pain with,” Correia continued. This helps the team prioritize and plan to refactor, “instead of suffering through it for years on end, as before.”

In the end, the most important measurement of any developer experience strategy is if your internal dev customers are adopting and using it. Work to tighten that internal feedback loop to make sure you are building what they want. Only then will you achieve measurable, long-term success.

The post Prioritizing your developer experience roadmap appeared first on SD Times.

“At Harness, we’re building the next generation of intelligent tools and automation to supercharge developer productivity and reduce developer toil,” said Jyoti Bansal, CEO and co-founder of Harness. “This funding enables our company to continue innovating at a record pace, transforming the software delivery lifecycle for today’s modern enterprises. Every year, developers waste more than $1 trillion by spending 40%+ of their time working on mundane, non-code-producing work. Our platform empowers software teams to achieve excellence in velocity, quality, efficiency, and governance.”

This investment comes on the heels of a groundbreaking FY2024, which included expanding our executive team with top-tier talent, achieving strong revenue growth, and significantly enhancing our platform. Key milestones include:

• Experienced rapid Annual Recurring Revenue (ARR) growth, going from $1M to more than $100M over the past five years.

• Customers executed more than 44 million code deployments with the Harness platform in 2023, more than double the number of deployments completed in 2022.

• Broadened and evolved product offerings by adding 2,800+ new features and enhancements across the Harness platform.

• Introduced AIDA, a new generative AI assistant integrated directly into all aspects of the Software Delivery Lifecycle.

• Launched four new product modules: Code Repository, Internal Developer Portal, Infrastructure as Code Management, and Software Supply Chain Assurance. These new modules join the existing eight offerings to deliver a powerful, seamlessly integrated software delivery platform. Each module is a best-in-class offering that can be tailored to an organization’s specific use case and business needs.

• Added new enterprise customers, including Nike, NetApp, MorningStar, and Icelandair.

• Welcomed Carlos Delatorre as Chief Revenue Officer and Gleb Brichko as SVP of Marketing.

Visit www.harness.io to learn more.

The post Harness Raises $150 Million in New Financing appeared first on SD Times.

The addition of CodeSee’s code insights capabilities will enable GitKraken to help developers understand “even the most complex parts of their code base,” according to the company announcement.

“The launch of GitKraken’s DevEx platform is a major milestone in our mission to make developers’ code – and their lives – materially better,” GitKraken CEO Matt Johnston said in the statement. “And with the acquisition of CodeSee, we’re raising the bar for developer experience, making code visibility, better PR reviews, and workflow automation available to 30 million devs around the world.”

GitKraken today also announced support for Google Gemini, formerly Bard, which uses AI to help developers generate code from natural language prompts, analyze code for errors or vulnerabilities, suggest code completions, and more. This support builds on the company’s extant support of OpenAI and Anthropic models, the company said.

Over the past decade, GitKraken has become synonymous with intuitive visualizations that help developers harness the full power of Git. In the past two years, it expanded to include GitLens for VS Code (JetBrains and Visual Studio slated for later this year), GitKraken CLI, and GitKraken.dev, all designed to seamlessly integrate Git workflows across developer environments.

GitKraken’s DevEx platform supports multiple Git hosts, Bitbucket and Azure DevOps, and integrates with Jira, Trello and other workflow and issue-tracking systems, according to the company. New features include Code Suggest, which speeds the pull request review process; a LaunchPad developer hub for managing WIP, issues and pull requests; and GitKraken.dev, a website that provides desktop and mobile access to features that help developers stay connected to projects and teams when they need to be.

The post GitKraken Acquires CodeSee; Launches New DevEx Platform appeared first on SD Times.

The first update is the ability to connect Compass components to Jira Software. This provides developers better visibility into health and performance metrics of their applications without needing to switch tools. 

It provides visibility into things like health scorecard status, compliance with standards, information on ownership, documentation, and CI/CD events. 

The company believes that by allowing Compass components to be accessed from within Jira, it will reduce context switching for developers. 

“According to the latest Stack Overflow Developer Survey, more than a quarter of developers spend an hour or more each day searching for answers or solutions to problems. That not only means less time shipping great software but also breaking the flow state where developers do their best work,” Atlassian wrote in a blog post.  

Next, Jira Software has introduced Jira Work Suggestions, which identifies bottlenecks that developers face when transitioning from task to task and is another way the company plans to ease the burden of context switching.

According to the company, developers may plan their work in Jira, but then they get sidetracked when other unexpected tasks — like pull request reviews, build fixes, or security vulnerabilities to address — come up that are managed by other tools. 

Now, Jira provides visibility into those tasks that are managed by other tools, providing a central place to look to determine what needs working on. 

Finally, custom merge checks were added to Bitbucket, enabling developers to easily ensure that their code merges are meeting company policies. 

Normally, Bitbucket’s checks are a static list, but the new custom checks will allow developers to adjust them based on their company’s specific policies. For instance, it could be updated to require specific security scans to be run, require that code can’t be merged after hours when no on-call staff are available, or require a minimum level of test coverage. 

“Together, these improvements across Jira, Compass, and Bitbucket help development teams streamline information and bring teams together, to improve experience and focus on the work that matters most,” the company wrote. 

The post Atlassian hopes to improve developer experience in latest Jira, Compass, and Bitbucket updates appeared first on SD Times.

Developer Experience (DevEx) is the combination of the interactions and feelings that each of your developers encounters when they’re working towards a goal. Developer experience encompasses every area of your organization that developers interact with – architecture, tools, processes, and culture – and all the positive and negative experiences with these elements. Unfortunately, organizations often miss the mark on prioritizing developer experience (and overall happiness). They instead end up prioritizing hiring, responding to the increased attrition caused by unhappy developers.

We see the issue in this. The more turnover your company experiences, the more time spent working and reworking processes. I worked with a company that mentioned on average it takes them 4-6 months from initial onboarding of a developer to getting them productive. Your developers find themselves training new team members, rather than focusing their time to grow and innovate as an organization.

Not to mention the challenge of finding talent in today’s environment.

“Senior executives report that the lack of developer talent is one of the biggest potential threats to their businesses. In fact, they now worry about access to developers more than they worry about access to capital, immigration concerns, and other challenges.” – Stripe’s Developer Coefficient report

The same report estimates that the Global GDP loss from developer efficiency is $300B and the efficiency loss for developers is 31.6%. Think about it – almost 1/3 of your developers’ time is lost today.

This masks the anger and frustration that developers feel as their day is lost. To improve developer experience, organizations need to understand what day-to-day struggles for their developers look like, and simply figure out ways to combat these roadblocks. 

Elements of Successful Developer Experience

Perhaps it is no surprise that 96% of upper management is looking to increase the productivity of developers. Thus prioritization of developer experience is a large factor in determining whether companies can meet their aspirations.

Developers spend close to 35 hours of a 41-hour workweek grappling with bad code, debugging, technical debt, and more. Their delivery pipeline defines their developer experience. It makes sense that organizations are focusing on being more data-informed, looking at their pipeline to drive developer happiness.

Software engineering teams focused on improving developer experience are already reforming areas of their pipeline to be data-driven that affect developer productivity and overall happiness. Here we identify the top three advancements teams are incorporating for sustainable and successful developer experience.

In a TechStrong report, 66% of responders noted plans to use AI/ML in their DevOps pipeline in the next 1-3 years.

Using AI and ML for Testing Process Advancement

Testing is one of the largest bottlenecks for development teams. Within DevOps, it has continued to be the least prioritized phase for advancement, yet it can cause the most trouble for developers. There are two common scenarios that which teams can lean on AI and ML for improving processes: having too few or too many tests.

• AI/ML for Too Few Tests: Not enough tests lead to developers flying blindly, unable to catch errors quickly enough. If bugs get passed downstream, errors have a higher likelihood of compounding making them even more of a hassle to deal with when found. Your best bet at this point is to get more tests into the system. This is where AI test-generating tools like Mabl and Mesmer come in – focusing on adding more quality tests, rather than buffing up testing programs with tests that don’t provide meaningful results.
• AI/ML for Too Many Tests: It’s all too common to see organizations facing bloated testing pipelines. Performing unnecessary tests during each commit takes time and increases the possibility of false positives/negatives. To combat this, teams are using ML to support testing at scale, collecting data to identify the necessary tests to run.

Noise Reduction in Development Pipeline

How many notifications are your developers getting every day? There is a common battle between the oversaturation of notifications and feedback exhaustion that developers face with their pipelines. Tampering the level of unnecessary feedback and getting the right signals to the right people drastically improves the developer experience. But where can you truly cut down on noise?

A major contributor to this noise is flaky tests, often a result of tests being written wrong or of the environment. The strain on timelines compounded with test mistrust drains developer resources leading to distrust of tests in general while adding unnecessary noise to pipelines. 

Organizations are minimizing flaky tests with new models and automation. Spotify’s test flakiness system and Dropbox’s “automated build health management system” focus on understanding the significant impact of flaky tests and finding a solution that works for their teams.

Focusing on Quality Over Quantity of Data

It’s important for organizations to realize that data for data’s sake doesn’t lead to better pipelines. Developers are producing a tsunami of data on the regular. But that data doesn’t hold value just from the sheer amount of it. An overabundance of data can negatively impact developer experience if it is not effectively used.

“Data users can spend between 30 to 40 percent of their time searching for data and 20 to 30 percent on cleansing it. The result is often a kind of data drunkenness where companies chase after different ideas in an uncoordinated and disjointed fashion. In effect, they’re trying to manage the scale rather than extract the value.” – McKinsey

Organizations focusing on the quality, rather than quantity of data, are finding the most success with using data to make pipelines smarter and improve developer happiness. More than 60 percent of tech leaders say they are planning to scale data, analytics, and AI. Perhaps surprisingly, this is more than any other tech initiative. 

Modern Data-Driven Pipelines Foster Happier Developers

Fostering happier developers is less about reinventing the wheel, and more about actively improving your existing pipelines to become data-driven.

The maturation of software engineering teams should inevitably result in a focus on developer experience. Establishing a team to lead this charge – whether named specifically for Developer Experience or within a Developer Excellence or Health initiative – should have a universal vision that will focus on keeping engineers working. The overall goal of these teams should be to not reinvent the wheel and lean on established truly Developer Experience Platforms and Tools for long-term developer happiness.

Your organization doesn’t need to pioneer creating a better developer experience. Successful organizations are already out there adopting solutions for improving the developer experience. It’s just about finding the best tools, methods, and solution partners for your organization’s needs.

The post Data-driven pipelines are the bedrock to improving developer experience appeared first on SD Times.

According to Tim Kadlec, performance engineering fellow for WebPageTest with Catchpoint, the role of the DevEx engineer stemmed from recognizing developers as customers. “I think it goes back to the realization that any tool or any product that is aimed at a developer audience, that is your customer,” he said. “So if you’re trying to reach that audience and get them excited about the project and trying to make sure that they enjoy using it, it is going to have to come through the entire experience from their first contact with the company all the way to when they’re actually using it.” Examining every aspect of the developer’s experience with a certain product or process can lead to less friction throughout the development life cycle.

As this new role gains popularity, its importance within different organizations is becoming more apparent. “I think the Dev Experience role is important because it’s not traditional marketing, it’s not traditional sales, it’s not a traditional funnel in any way,” Kadlec said, “It’s about how we make sure there is as little friction as possible when developers want to use and engage with different tools and products.” When organizations focus on a developer’s experience with certain tools early in the development process, it can end up saving time later, as a positive developer experience will undoubtedly lead to a more efficient outcome. 

According to Jeena James, GM at WebPageTest and leader of its developer team, what makes the DevEx engineer role effective in her organization is the feedback from the end user. “The users themselves, the developers, also get to see certain areas that they can actually help improve for themselves and have this ability to kind of contribute back,” James said. Having a specific role in place focusing on developer experience gives the developers a place to go with constructive feedback as they work through issues.

Kadlec explained that a role that exclusively focuses on developer experience is no longer a luxury for organizations, but a necessity. “The developer experience engineer,” he said, “they’re the stand-in for the developers who are actually going to be either writing the code internally or using whatever tool… it’s their job to sort of take a lot of that feedback that we’re getting from the community and constantly keep that in mind as we’re looking at things like what features we should build or what gets prioritized and what doesn’t. This is where the developer experience engineer role becomes really important.” Kadlec explained that the DevEx engineer is also oftentimes the one who helps to keep the team on track with where priorities should and should not lie because they are speaking on behalf of the developer community. “Not even just features and stuff like that but the entire structure of a product and the commercial offering as well, making sure that all of that is fine-tuned in a way that is going to be appealing and convenient for developers,” Kadlec said.

Different approaches to DevEx 

There are several different ways in which an organization can utilize the DevEx engineer role. Kadlec and James explained that, in their experience, the most effective method is to take a dual approach, “The way we do it here is by treating the role as a split, so maybe half of their time is spent doing traditional engineering. In the case of WebPageTest, that means that half the time our developer experience engineers are building features, fixing bugs, maintaining the actual code base and then the other half of the time is spent on more traditional developer relations activities. That can be things like content production in the form of videos or blog posts or documentation or going out there and giving talks or writing sample code, things like that,” Kadlec said. He went on to explain that this split method is important because it ensures that DevEx engineers have a deep understanding of the product itself as well as the needs of the developers working with it. 

Another aspect of the role that makes these engineers essential is the relationship they can build with the end user. James said, “When you’re speaking to that audience, to your user who is a developer who can actually fix some of the things that are being asked.. It’s good to have a developer talking to another developer to say ‘I get what you are trying to solve and here’s how I would fix it’.” Having a developer on your team as the DevEx engineer serves to make the developers feel seen and heard within the organization. 

DevEx is a team sport

While having a role central to developer experience in place is crucial, Kadlec also stressed the importance of the rest of the team in ensuring a positive experience for developers. “It’s important to note that the developer experience role does not operate well as an island. If you have a couple of people in the developer experience engineer role but they’re kind of working detached from these other components of the business and/or they’re not receiving support from the rest of the team, it’s going to fall flat on its face,” he said. Kadlec went on to say that if the whole organization is not working with the DevEx engineer and offering their support and services where needed, the role is essentially useless. Typically, roles within a business are not meant to exist in a vacuum, but rather as an integral part of the organization at large, and the DevEx engineer role is no different. 

One role with a dual purpose

Laura Thomson, VP of engineering at cloud computing services provider Fastly, said that she believes there are two aspects that make developer experience as important as it is. “One is that developer experience is an accelerant for the people that you have in your team already. We all know that it is hard to hire engineers, but developer experience is something you can use to make the engineers you already have more productive. The second part of it is that people who have worked somewhere that has a really good developer experience, will always rave about it… People who work there will say ‘I have all of these great tools at work, I have a great build system, I have great continuous integration tooling, I have great tools to help me do my job better’ and it makes people loyal,” she explained. 

In terms of the role of the DevEx engineer, Thomson believes that the need increases with company growth. “As you get to be a certain size as a company, you really do need a team in this area… and sometimes it’s got a different name, sometimes someone who works in this area isn’t going to be called ‘developer experience’ or ‘developer productivity’, they might be called a ‘release engineer’ or a ‘build engineer’ but all of those are sort of parts of the same thing,” she said.

According to Lei Zhang, head of developer experience at Bloomberg Engineering, while it is important to have the whole organization working with the DevEx engineer, having too much input can sometimes become a hindrance. “I think it’s a fine balance, sometimes you have a very specific problem and we go deep into that problem, but at the same time we always need to have a global view of what the developer needs to do to get a job done and have a really good experience,” he said. Zhang explained that he sees the recipe for a successful team as having the right balance of people focusing on the specific, in-depth problems and people focusing more on the big picture and having that “global view.”

 Zhang believes that the DevEx engineer role, and other positions with the same goal, have become more important in recent years due to the large amount of growth the technology industry is seeing. “I think the tech industry has been growing so massively and there is a specialization in skills and I think developer experience is at the core for developer productivity. Oftentimes, at an organizational level, it is almost the most important thing in order for an organization to have long term sustainable success.” 

Zhang said that although developer productivity has always been widely talked about, the shift to developer experience is due largely in part to an increase of this specialization of skills. With this shift to developer experience, organizations find themselves faced with new challenges to overcome. Zhang divides these challenges into two common themes, “The first one is the balance between individual or team creativity, and efficiency and sustainability at the organizational level… The second one is when and how we should do tech renovation. I think that successful organizations are likely to have solutions that are highly optimized with the technologies when they were built,” he said. 

Tools and technologies

Both of these challenges play a large role in developer experience because they affect the kind of tools and technologies that developers will be interacting with on a daily basis. Zhang believes that devising a plan to tackle these challenges is incredibly important when it comes to maintaining a positive experience for developers as well as sustaining the overall growth of the company. 

With this, Zhang also mentioned the issue of inherent bias that may come up as a DevEx engineer. “As a developer we tend to always like the tools we use, we think that our tools are the best and that everyone should be using our tools,” he said, “but the reality is that developers have different preferences.” This bias among the developer community can lead to issues with supporting the team while also maintaining organizational consistency. It is the job of the DevEx engineer to mitigate this issue while keeping their own biases in check. Once challenges like these are resolved, the DevEx engineer role will provide organizations with several benefits.

Rob Zuber, CTO at CircleCI, said that one of the key functions of the DevEx engineer is that they enable the developer to focus all of their effort on the task at hand. This keeps developers happy and will, in turn, create and sustain developer loyalty within an organization. “If I come to a job and find that I’m spending 5% of my time on that thing that I’m really excited about and 95% navigating the organization, dealing with coordination and project status, meetings, and change management… I’m not going to stick around that long,” he said. Zuber explained that as a developer, an environment like that would not be fulfilling. He said, “[in that environment] I’m not growing in the area that I want to grow in… you want to be working on the thing that you’re excited about… and so, when my company makes those investments, that gives me the signal that they care about what it is that I’m trying to do and where I’m trying to grow.”

Zuber went on to explain what the life cycle of work might look like for a DevEx engineer, “It would start with understanding where folks are being taken away from the most valuable things they can do, and then looking for those patterns across the organization,” he said. Looking for these patterns helps to tackle the problems that affect the majority of the organization, rather than focusing on only a small percentage of developers. “If only one team has a particular problem, then having a second team build a solution to that problem isn’t particularly high leverage because it’s just getting used by that one team, whereas all of your teams quite likely have the issue of building and deploying software, for example, so you’re going to focus more energy there… it’s not just about identifying problems, but identifying problems that are most pervasive across the organization, and then helping to solve those,” he explained. 

According to Zuber, another benefit of a role like the DevEx engineer is creating an easier process for onboarding new developers. “Developer environment setup is probably a pretty classic problem… If I am a new engineer in this organization, how do I get up and running and understand what I need to understand and have the tools on my laptop to start contributing effectively,” he said. Zuber went on to explain that in a smaller organization this issue would become something of a “labor of love” that would be solved by each individual new developer, but in a larger company, this would be something that would fall to the developer experience team, making solving this issue much easier. “How do I just show up and my laptop is ready to go and day one I’m coding instead of day one I’m trying to figure out the 57 pieces that I need to install to start building,” he said. 

While it is not impossible for an organization to get by without a role like the DevEx engineer, it has certainly become incredibly advantageous to invest in this position. Zuber said, “I mean, you can totally get by without it… but then you would sort of be burning some goodwill by having engineers who are excited about building products and solving customer problems, invest a bunch of time in just trying to get things to work.”

The post To maximize productivity and deliver value to customers more quickly, organizations are creating a new role: Developer Experience Engineer appeared first on SD Times.