devopsy.kinsta.cloud

Tag: development teams

Hybrid Software Development: Benefits and Challenges
Fortunately, companies do not always have to choose between in-house vs outsourcing. Instead they can adopt a hybrid development strategy, which combines the capacities of internal and external IT teams. This approach allows companies to capitalize on the strengths of both traditional software development models, while offsetting their respective limitations, thereby streamlining project execution. However, to leverage a hybrid model successfully, companies must be prepared to tackle the operational complexities that arise when internal and external teams work together.

This article explores why companies adopt a hybrid development model, outlines its key challenges, and provides recommendations to address them.

Why Businesses Choose a Hybrid Software Development Model

Even proficient internal development teams can face challenges delivering new software projects end-to-end. For instance, a team can have sufficient proficiency to handle the majority of frontend and backend development activities but lack skills in specialized areas such as data science or machine learning. Or a team can possess all the required skills, but simply be too busy with existing routine tasks to take on additional work and engage in a new software project. In such cases, a hybrid model can help prevent project delays by combining the capacity of internal teams with the specialized expertise of external partners.

For example, a company can temporarily augment its existing development team with third-party specialists, who will take instructions directly from internal managers, use corporate tooling, and attend daily stand-ups similarly to regular employees. Alternatively, a company can assign its internal IT team product ownership responsibilities, including defining software requirements, feature priorities, and a project roadmap, and delegate development-focused tasks to dedicated external teams. Beyond handing over all development activities to a third party, a company can also share them between internal and external teams, with both groups collaborating on the same codebase under a co-managed delivery model.

Traditional outsourcing is associated with various risks that can compromise the success of a project, with provider lock-in being among the common concerns. In short, if a company fully relies on an external partner to develop or maintain software, it can later become incredibly difficult to switch to another outsourcing provider or continue developing and maintaining software in-house. Since outsourcing involves sharing software specifications, source code, and proprietary algorithms with a third party, it is also associated with a higher risk of intellectual property exposure, which can cause severe reputational, financial, and legal damage.

A hybrid software development model can help companies mitigate both types of risk. When an in-house team remains actively involved in a project, it retains the contextual understanding needed to onboard a new partner without starting from scratch and can maintain software independently if necessary. Additionally, because an outsourcing partner is responsible for only a part of all project activities, it does not require access to the full scope of a company’s proprietary technology, which reduces the risk of intellectual property exposure and minimizes its potential negative impact.

Challenges of a Hybrid Software Development Model

While a hybrid development strategy can be highly advantageous in many business scenarios, it still cannot be considered a silver bullet, as efficient coordination of internal and external teams requires careful management. This complexity arises from diverse factors, including the following:

1. Project Vision Misalignment

Unlike in-house employees, outsourced teams typically have a less comprehensive understanding of a company’s project vision and long-term goals, which can lead to delivering outputs that do not meet stakeholder expectations.

2. Location and Time Zone Differences

In many cases, in-house and outsourced specialists operate across different locations and time zones, which can hinder real-time collaboration, complicate issue resolution, and slow project delivery.

3. Methodology and Tooling Discrepancies

To collaborate effectively, internal and external teams should follow compatible development methodologies and use shared tools. Differences in methodologies and tooling can cause inconsistencies in delivery cycles and make it more difficult to track project progress.

To ensure smoother adoption of a hybrid development strategy, companies should proactively address these challenges through the following practices:
- At the start of the project, create a comprehensive Statement of Work document detailing project goals, software requirements, and user flows, and then ensure outsourced developers review it during onboarding.
- Schedule regular joint meetings – either weekly or sprint-based – during overlapping working hours to discuss project updates and gather feedback from diverse teams involved in a project.
- Implement a shared backlog and keep it visible and updated, as it can help align in-house and outsourced developers on project goals, feature definitions, and feature priorities.
- Require all teams to use shared development environments, code repositories, communication tools, and project trackers to prevent tool fragmentation among teams.
Final Thoughts

Combining the capabilities of internal and external teams has become an increasingly popular software development model. This is not surprising, as a hybrid model enables companies to scale their engineering capacity according to project needs without traditional hiring and onboarding processes, while still maintaining control over intellectual property and minimizing dependency on third-party providers.
September 14, 2026
Building and Leading Product Teams in Uncertain Times
The world seems to be changing faster than ever, and there’s no reason to believe it will slow down anytime soon. The pandemic has compounded this sense of constant flux, with customer priorities shifting overnight. Against this backdrop, product teams need to constantly evolve their development work without losing focus or feeling they need to react to every small change in the market.

This requires team leads to throw out their old playbooks and develop a new strategy that allows them to deliver continuous innovation without creating chaos for their teams or losing sight of their north star. Road maps are shrinking from years to months, and are now being created with the understanding that they may become outdated or redundant at any time.

Building and maintaining an organization that can not only survive but thrive in these conditions is a daunting task. It requires a structured, programmatic approach that also supports agility and adaptability. Those requirements may feel at odds, but they actually are not. Here are five tactics to help your product strategy evolve with the times.

Keep That “Day One” Mentality

It’s important to keep the soul of your product top of mind. It helps to retain a “day one” mentality which means constantly reminding yourself why you started in the first place and what problem you set out to solve. That founding problem statement should serve as your guiding light, especially through times of rapid growth and change.

Customer requests are, of course, a high priority and should always be thoughtfully considered. But ask yourself if the request is aligned with that day one problem you set out to solve. If it’s not, work with the customer to identify the underlying issue they’re really trying to solve for versus focusing on the symptom they’re experiencing.

Cultivate a Culture That Thrives on Change Without Succumbing to Chaos

It takes a combination of strong organizational capability and the right culture to build a team that can thrive on ambiguity. Strong organizational capability is achieved through talent, architecture and execution skills.

Great product teams build an architecture that supports iteration and are able to execute toward their north star in small, rapid steps. Team leaders should build a culture that takes failure in stride and learns from it to improve each subsequent iteration in the product journey.

Change is inevitable, but chaos is avoidable. Leaders must create an environment that feels psychologically safe and supportive, so that team members feel confident in changing priorities and making rapid decisions.

Build an “Innovation Factory” or a System that Reduces the Potential for Chaos

Innovation and agility require well-planned foundational resources. Following are the key steps that can help put these building blocks in place.
- Think of velocity as a part of your product. Teams should be broken into small groups to autonomously drive the product forward, but in such a way that the overall experience feels seamless to end users.
- Democratize the product concept phase by creating conditions for a large number of ideas. Everyone involved should be inspired to contribute, including employees, partners and customers.
- Create a system for product development excellence. Fully automate your product development life cycle by approaching developer infrastructure as if it were a service, with clear service-level objectives within a CI/CD framework. Digitize each step in the product concept, development and deployment journey, with a focus on measurement, learning and iteration in every phase. Ask who and how many people are building versus approving at each stage and ruthlessly optimize and automate where possible.
Bring a Service Mindset to Everything you Do

If you’re building a SaaS product, as many startups today are, you’re no longer delivering a product in the traditional sense. You’re delivering a service, and you’re responsible for the entire experience from start to finish. This means you’re in full control over when to release new features and how you measure user engagement. You can see where the friction points are, and where customers are delighted. We have a philosophy at my company of “less input, more output”—simplicity is the name of the game, where the output and value your service creates for customers is the only measure that matters.

The outcomes required may change as customer priorities evolve and new requirements flow in, but adapting quickly and effectively should just be a matter of (re)connecting well-built services within your platform to prioritize and address those changes. Leverage the cloud ecosystem in a way that allows you to safely bet on other players and partners who are moving as quickly as you are. Focus on making sure your foundation is strong; one that can provide a service at scale even as the outcomes customers want change over time. This allows you to stay laser-focused on the task at hand: Maximizing value for users.

Incorporate Users in the Product Development Cycle and Learn as you Go

The cloud has transformed the way organizations build products and integrate feedback. The entire life cycle is digitized and measured. Product teams can move at a much higher velocity and in smaller increments, with the ability to make near-real-time adjustments along the way. But the greatest advantage a cloud environment offers is that we can now include users in the entire product life cycle, every step of the way. It gives us the ability to measure outcomes quickly and take action on the information that immediately benefits customers.

It sounds counterintuitive, but product teams can prepare for the unknown. There’s no way to see what’s over the horizon, but with the right people, processes and tools in place, there’s no reason that uncertainty should derail you. There has never been a more exciting time to be an innovator or a builder. Meet the uncertainty ahead with open arms and a strategic eye.
November 12, 2021
DevOps Practices: How to Make Valuable Changes to Your Teams
DevOps has become a buzzword within the software development industry, promising rapid turnaround times for requested changes. As for developers, DevOps promises to increase productivity while reducing the risk of production failures. The book “The Unicorn Project” by Gene Kim describes this process for developers as The Five Ideals.

In this article, we’ll focus on only two of them:
- The Third Ideal — Improvement of daily work
- The Fourth Ideal — Psychological safety
Psychological safety and improvement of daily work make it easier for developers to create changes for their teams, and the work to implement these ideals is not difficult. From automated testing to production monitoring, there are many great things that even junior developers can help bring to their teams that will help their entire team make safer changes to their code.

So, what are these easy changes that can be made? Below is a list of tasks that can be done to improve the projects you are assigned to, with most taking less than four hours to complete.
1. Set up a continuous integration server for your project, such as Jenkins or Team City. This will allow for automated jobs to be run for your code.
2. Create jobs to run testing for pull requests as well as testing jobs to run overnight. This will show the current state of your project’s tests on a nightly basis and will allow for the number of failing tests to be monitored over time.
3. Add a code coverage tool to your automated tests. This will show what is being tested in your code and what is not being tested, creating opportunities to help shore up your teams testing suite as well as confirm that your changes will be covered by existing tests.
4. Create an automated deployment job on your CI server. This will convert the manual deployment process in a one click job, allowing the code to be deployed on command.
5. Modify your project to extract metrics of the project, allowing your code to easily be monitored for faults in production.
The tasks highlighted above will quickly add value to your team while helping protect you for making dangerous changes to your team’s code base. I recently changed teams and have moved to a new web project. The project runs fine on my local, but it is hard to track what is affected by my changes. The team already has a CI server to build their code, but there is no point in setting up any testing jobs as the project has fewer tests than I have fingers.

Instead, I created a monitoring tool that captures all requests to the website and records their results. With the tooling in place, my team can now see how long it takes for each part of the website to load, as well as how many errors are being produced. Now, when I make any changes, I can check these metrics to see if my change is causing issues to the site, increasing my confidence in my code.

If you are interested in learning more about DevOps and how to take advantage of it, here are a few good reading resources to look into:
- “The Unicorn Project,” by Gene Kim.
- “The Phoenix Project,” by Gene Kim, Kevin Behr and George Spafford.
- “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations,” by Gene Kim, Patrick Debois, Jez Humble and John Willis.
April 28, 2020
Data: The Fabric of Developers’ Lives

We’re living in the golden age of application development. Developers can tap into more resources and enjoy greater flexibility than ever before. Multi-cloud environments offer them the freedom to pick and choose from a wide range of services based on the strengths and offerings of different cloud providers. They have unparalleled opportunities to achieve their development goals.

In this environment, developers must build applications to work across different hosted providers, each with their own unique administrators and requirements. The easiest way to deal with this is to forget about storage, at least in the traditional sense. Instead, developers and the organizations they work for should deploy an underlying data fabric that supports everything they’re trying to do, and every cloud provider they need to do it with.

What Is a Data Fabric?

Put simply, a data fabric is an underlying, cloud-agnostic infrastructure that can enable developers to more easily port data between different clouds. An ideal data fabric is highly scalable—supporting an organization’s big data needs—and reliable.

For a visual representation, think of a big Thanksgiving when you invite a bunch of different people over and you need to pull two dining tables of different shapes and sizes together. You spread a tablecloth over the two tables to make them become one. That’s kind of what a data fabric achieves; it brings two different things together to create a single platform.

Why Is this Important?

Storage-as-a-Service—we hardly knew about it. Thanks in large part to containers, which offer exceptional scalability, simplicity and high availability, the speed of application development has increased dramatically. Developers need to be able to quickly provision their own data, in just the right amounts, to match that velocity. And, like containers, that data needs to be portable.

Provisioning quickly means no more going through storage administrators to get the services they need, which can be a cumbersome and time-consuming process. Solutions like Kubernetes’ on-demand clusters enable developers to procure the data they need when they need it.

The abstraction layer provided by a data fabric can empower developers even further. They can write their own APIs, provision data services as needed and move that data between clouds with ease.

This is particularly important when dealing with cloud providers that offer different services. Sometimes a developer may need a service that exists in one cloud but not another. It’s critical to have an underlying storage infrastructure that enables applications and their data to be transferred as needs require.

What Does this Mean for the Role of Developers?

Today, developers must be IT versatilists and wear many hats. They have to manage storage, understand their businesses’ goals—and, of course, they have to develop. That’s a lot to juggle, so it’s understandable why developers would want something that helps simplify things.

Indeed, having a standardized data fabric can make all of this a bit easier. Developers don’t have to bother their storage administrators with requests; they can quite easily provision storage themselves.

Everyone wins in this scenario. Developers save time, become more empowered and have the freedom to create applications and datasets and more easily apply them to different clouds. Storage administrators can focus less on provisioning and more on other value-added projects. Organizations as a whole can also benefit, since developers will be able to create applications more quickly, allowing companies to bring services to market at a faster pace.

Speaking of the Bottom Line — What Is It?

Deploying a standard infrastructure for data services is critical not just to developers but to enterprises themselves. It supports organizations’ initiatives for scalability, flexibility and agility—all of the reasons that companies are doing containerized application development in the first place. For developers working in multi-cloud or hybrid cloud environments, it makes perfect sense.

April 23, 2020
Tips For Managing Development Teams Remotely During Coronavirus

Thanks to the global coronavirus pandemic, around a third of the world’s population is on lockdown in their homes, which means a huge number of businesses are currently trying to navigate remote working solutions. Trying to collaborate on software development is difficult at the best of times when your team is all in the same office, but with your team split across various home offices communication and collaboration is made all the more difficult.

Remote development work is an altogether different challenge, one that needs careful thought and new solutions. Luckily, there are ways to get around it, and they don’t all require huge investment or innovation. Just tweaking the way you think and work will help you continue to deliver on your development goals.

Spread Knowledge

Many teams run into problems with their remote workforce when they realize knowledge is not equally distributed amongst team members. I don’t mean the company log-in details (though you might have that problem too), but that the company’s vision and culture have not been effectively communicated. In an office setting this isn’t too much of a problem, as developers can be sent off on projects and the team can come together to implement them with one voice at the end, but when the whole team is divided it’s a lot harder to achieve this final cohesion.

To avoid having to piece your projects together like a jigsaw puzzle, make sure all of your developers are clear on what goals the company wants to achieve as a whole, and what culture and tone the company is wishing to promote. That way any development decisions made in private working sessions are still geared toward the overall company aim, and individual projects will slot in well together.

Communicate

To spread knowledge effectively, you also need a major focus on communication. You won’t realize how much the office dynamic contributes to communication until it’s gone. Working from home eliminates many of the little interactive scenarios in which team members can discuss ideas and clarify details.

To counteract this, you need to communicate far more than you previously did. Send more emails for clarification and have more regular meetings (over video chat) than you otherwise would. This might seem annoying or even counterproductive at first, but having a clear flow of information across the whole team is important for accountability.

Take Note

Related to communication, you may find it really helps to note more things down. You’d be surprised how much information is transmitted from being physically in the same space as someone, so a lot of workers find it a lot harder to pay attention to video of audio meetings and can easily forget details. Whether it’s minutes of a Zoom meeting or a brief one-on-one phone conversation, jot down a note of important tasks or details to remember, and circulate them throughout your team.

Be Humble And Accept Feedback

If you’re managing a development team that’s just gone full remote, accept the fact that you might not have all the answers. This might be as new to you as everyone else, and even if you have experience of remote working before it probably wasn’t during a global pandemic. By all means, show a strong sense of leadership and implement a solid plan of action, but be humble enough to accept that it might not be a perfect plan.

Show your humility by being open to feedback from your team members. They are having to adjust to a new lifestyle that may require new strategies to deal with. You might consider flexible working hours, or reassessing your tools or communications strategy. Figure this out as a team and you’re much more likely to keep morale up and not sacrifice any productivity.

Embrace The New Normal

Most importantly, don’t spend your time waiting for things to go back to normal. Treating this period as a brief interruption to your normal working schedule will stop you from fully committing to new strategies and tools to help you produce good work right now. It will show in your products, and if your remote working period lasts longer than you’d expected it will mess up your production schedule. For now, this is the new normal: embrace that and start with your best foot forward.

April 17, 2020
Launchable Aims To Improve Delivery Velocity, With Kohsuke Kawaguchi and Harpreet Singh

A new company, Launchable, aims to improve your delivery velocity by helping you be much smarter about which tests you run and when. By applying machine learning (ML) and better use of the data output by your software development work, the two co-founders think they can make a meaningful impact on development efforts.

Sure, you say, lots of developers say they can change the world. But in this case, the co-founders have some very impressive résumés to give you confidence they just may do it. The dynamic duo is none other than Harpreet Singh, former GM of Atlassian BitBucket and VP of Product and Design at CloudBees, and the one and only Kohsuke Kawaguchi, founder of Jenkins and CloudBees Chief Scientist, most recently.

Wait a second, you may be asking, you’re saying KK from Jenkins/CloudBees has started a new company? Yes, that’s what I am saying. In a podcast that will be available very soon, KK and Harpreet talk with us about Launchable’s why—and why now. Stay tuned for that.

It’s worth noting that KK has been at CloudBees for 10 years and working on Jenkins for 15 years. In the tech business, that is nearly a lifetime. During our podcast, KK said he felt that with Jenkins being passed to the Continuous Delivery Foundation (CDF), coupled with a healthy group of leaders within the Jenkins community, now was a good time to move on to the next adventure.

Beyond Jenkins, CloudBees has grown into its own next phase, with lots of exciting developments announced and more coming. The scientist in KK has led him to explore solutions to problems he sees in the way so many companies are doing development. His longtime friendship with Harpreet, dating back to their days at Sun, has energized them both to once again work together and tackle the real problems that development teams are facing.

What will come out of Launchable? I don’t know. But the company has already attracted some blue-chip VC investment, as well as an impressive list of angels including Sacha Labourey, CEO and founder of CloudBees.

They (like everyone else, it seems) are hiring development engineers and data scientists. So if working with KK is something that appeals to you, head over to the Launchable site and check out the Careers section.

I am sure we will be hearing more about Launchable in the days, weeks and months ahead. In the meantime, best of luck to Harpreet and KK, and many thanks for a job well done with Jenkins.

— Alan Shimel

January 23, 2020
Best of 2019: Critical Skills Developers Need to Avoid Getting Left Behind

As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the second in our weeklong series of the Best of 2019.

Burnout is a recurring theme at DevOpsDays events around the world. The modern developer faces constantly and rapidly-evolving challenges: the agile movement reducing the development lifespan, the DevOps movement shifting production operational responsibilities into development processes and the complexity of cloud offering new architectures from SaaS through to FaaS, as well as microservices.

As these shifts occur, often ignored are the operational skills needed to support an application running in production. Developers expect to support production and be on call 24/7, but are IT leaders giving them the necessary tools and training? More and more, we need developers to be prepared and able to seamlessly oscillate between focused specialist and broad generalist. This article highlights a few key areas where software engineers need to bolster their skill sets to remain agile and effective in building applications.

DevOps and SRE Assume Broader Skills

Non-developers may interpret agile computing as developers creating a world where they get to code rather than document, follow process or deliver to plan. In reality, agile took the lengthy cycle of waterfall releases and replaced it with the frenetic continuous delivery of valuable software. DevOps was born from the need to deliver application updates rapidly and regularly.

The monitor phase of the DevOps infinite loop originally focused on ensuring application problem detection and diagnosis was possible. Moving from detection to prevention, DevOps practitioners had to shift their testing and quality processes. Developers were asked to code the application, while also creating the testing systems to validate their code and building the production executables. Progress here led to additional responsibilities. As development moved to agile and DevOps, infrastructure transformed into software defined infrastructure (SDI).

The separation of the operating system from the server hardware through virtual machines started the journey to SDI. Application containers removed the OS requirement and added cross-server mobility. Kubernetes and Docker Swarm allowed developers to encode application requirements in the recursively titled YAML. After containers, microservices is a further refinement that isolates an action into a separate piece of code—which is well suited for workload-based pricing of cloud environments. SDI’s capabilities bring us to where infrastructure definitions require a software development lifecycle (SDLC) of their own.

The outcome of all this is a massive increase in complexity that developers must consider as they code components of an application. It requires additional considerations of the infrastructure and business environment the application will run in. Developers can define the best YAML definition of needs for their new application, but does not mean the production infrastructure will be able to provide a matching environment.

Skills Developers Must Enhance

Here are some key areas where developers would benefit from honing their skills in order to stay relevant amid growing complexities mentioned above.

Networking

The single purpose of computer networking is to move data from the memory of one computer into the memory of a different computer. With TCP/IP protocols as the default network stack, the flexibility needed to survive a nuclear attack comes with a lot of variability in configuration. At the basic level, network components must be configured to identify how many bits of an address to use when searching for another network entity via Classless Inter Domain Routing (CIDR).

Software engineers need networking skills to understand how their software definitions may conflict with the eventual production network infrastructure. For instance, network definitions in the YAML descriptors for Kubernetes/Docker are generally set with a /nn configuration (e.g. /16). Conflicts arise when you overlap the pod addresses with physical server addresses or have a mismatch between development pods and production pods. If your pods-per-node count differs between pre-prod and prod environments, it is possible the CIDR settings will differ as well—as a colleague regrettably learned when using /8 rather than /16, leading to the largest production outage in their career.

In addition to these basics of network addressing, there are concepts such as micro-segmentation needing definitions of performance and connection requirements that span across containers, virtual machines and bare metal servers.

Security and Segmentation

Historically, applications have relied on production infrastructures with their firewalls and DMZs for protection from the outside world. That castle moat approach is insufficient for today’s threat landscape where applications live everywhere. Not only do enterprises need to protect against outside connections and attacks, they also need to prevent accidental connections from production applications to development, QA and testing environments. Crossing the streams can cause exposure of production data in test environments and, even worse, corruption of production data.

Ensuring that application components only communicate to specific services in specific environments is addressed with micro-segmentation and its ability to manage and monitor secure code-to-code communication. Control with this detail comes with its own challenges as incorrect or insufficient definitions could leave a production application unable to communicate with needed API’s or microservices. Making diagnosis in micro-segmented environments harder is the possibility that traffic for other transactions or applications may be successfully crossing the same environment. This is when you may hear the classic “it is working fine in test” response.

Micro-segmentation offers significant security benefits yet requires developers to clearly identify the required connections and components of any communication. The best time to note this is while coding, making this an important skill for the modern developer.

Dev and Ops Synchronicity

The synchronous arrival of DevOps and SDI provides a mutual opportunity for developer and operations teams. While developers need to learn production on-call skills and operations teams need to learn SDLC skills, both teams also need to remain current in security concepts. Some organizations tackle DevOps by creating merged teams, though members may continue to stay in their lane. Whether merging teams, or maintaining separation, it is beneficial to hold brown bag sessions to share information and help educate each other. Ask your operations peers to talk about their three most common production issues and the three most popular tools they use.

An important aspect of the application on-call generalist is having the right tool supporting them to effectively diagnose production outages and slowdowns. Whether developed as an in-house solution (with incumbent technical debt) or selected as a product, you will need something that can see from end-to-end and allow the code-centric software engineer to drill into databases, storage, networks and code components from an application point of view without having to learn siloed management and monitoring tools for each aspect of infrastructure.

While individuals come into a DevOps transformation with I-shaped specialists, they must leave as T-shaped engineers, thus enhancing their value to current employers and helping their career.

— Marco Coulter

December 27, 2019
Three Ways Developers Can Worry Less About Security

Over the past 10 years, developers have risen in organizational importance. They’ve acquired more tools, power, responsibility and autonomy. As part of that evolution, many developers today want to touch all of the layers of code and have their hands in every tool that’s being built. Known as “mechanical sympathy,” developers are taking increased initiative in areas they simply haven’t before–like installing security systems or being in charge of their team’s application security lifecycle.

While pride of ownership is never a bad thing, in today’s complex IT environments, where organizations are adopting hybrid cloud solutions, microservices and containers–and are required to push applications and software into production as quickly as possible–this simply isn’t scalable. Pursuing mechanical sympathy in this case can be too costly and ultimately become counterproductive–especially when it comes to security, where an attacker only needs to find one vulnerability to gain a foothold in the system.

Rather than relying on developers to become security experts, organizations should empower them to dig deep on the tasks that matter to them (development) and leverage the expertise of other specialists (security). That way, everyone can focus on their own productivity and deliver the most value to the business.

Here are three ways developers can let go of their need for mechanical sympathy.

Consider the Implications of Being Responsible for Security

Taking on security means abiding by security best practices, like adopting multi-factor authentication and implementing privileged access security for secrets management. None of this is in the typical wheelhouse of the developer, and in fact, developers could actually be increasing risk if they intend on being responsible for security.

Developers should think of it this way: Imagine something goes wrong with the application you put into production, such as leaking sensitive data based on a mistake in the source code or a design flaw. Do you really want to be the team who’s called? The answer is probably no.

By focusing on core developer strengths and allowing security teams to handle an organization’s security strategy, developers are able to collectively ship applications that are functionally sound, as well as secure.

Don’t Solve for Already-Solved Problems

When it comes to DevOps methodology, there are an increasing number of tools now available that automate time-consuming security tasks–such as automated secrets management, encryption and vaulting solutions–which remove those burdens from developers and allow them to work at true velocity.

With these tools available, there’s no need to reinvent the wheel. Developers should leverage these assets to their advantage and abstract away complexity to the security team, who should be governing and provisioning security tools so developers can get back to delivering applications to market as efficiently as possible.

Prioritize the Value Stream

The aforementioned tools provide a great benefit to developers–freeing them up to focus on more impactful work–but it can be easy for the opposite effect to take hold if developers get mired down in the weeds with them. Instead of trying to specialize in tools such as Kubernetes or OpenShift, which have manufactured obsolescence to begin with, developers should be encouraged to think about the big picture–creating a high-performance, automated pipeline that accelerates software delivery from code to production.

By focusing on the health of the pipeline, rather than the specific tools within, developers establish a real-time feedback loop that enables them to anticipate the future and see the amazing projects that are truly possible. It positions them as drivers of innovation and increases their sphere of influence across the organization.

Developers play a critical role in bringing applications and software to market with speed and stability, but when organizations default to letting them own everything from the nuts to bolts, they may end up introducing security issues that could otherwise be avoided.

The best way to ensure security in the development process, however, is to start with a strong security foundation. Organizations that understand developers and the development process are savvier when it comes to the vulnerabilities that could be inadvertently introduced and are in a better position to secure them with minimal impact on velocity.

In such a complex and powerful world of cloud, CI/CD and more, when developers are empowered to let go, organizations can better manage and mitigate risk, and deliver higher quality applications that drive true business impact.

— Brian Kelly

November 12, 2019
Harnessing the Power of Developers

In our fast-moving digital economy, organizations across just about every industry are faced with a stark reality: to remain competitive and deliver the best possible customer experience, they must evolve continuously. The fintech industry is a great example of this–the sector’s growth and focus on excellent customer experience has been driven by external developers rather than incumbent players.

For many companies, particularly in the service industry, improving customer experience now means developing new apps and services that will maximize the customer journey, engender deeper trust and secure customer relationships for the future.

The aim is to continuously produce innovations that create delightful customer experiences, which in turn will drive ROI. In its 2019 Technology Industry Outlook, Deloitte highlighted the fact that the “democratization of innovation” is set to be a key strategic factor in the coming years. As cloud infrastructure makes it easier to innovate at speed, “medium and small enterprises can harness powerful capabilities once limited to a select few.”

That might be a new SaaS application, for example, or the implementation of emerging tech such as AI or VR–anything that helps the company provide a more efficient or accurate customer service. A simple example could be integrating complementary, adjacent solutions to add additional value to end customers.

Companies need to innovate in order to create unexpected functions and capabilities that will delight. But how do companies go about making that a reality? In a nutshell, there are two groups that can help you innovate: your own developers and the wider developer community. Having the right people involved and the right programs in place for both of these channels will allow you to scale and deepen your innovation more effectively–and ultimately create experiences that your customers cannot live without.

The more you engage with developers inside and outside your organization, the faster you can accelerate your time-to-market for new innovations and, crucially, ensure that those innovations meet real customer needs.

In-House Developers

Building an effective in-house development team to meet customer needs is about more than just hiring the right computer skills. Companies need to aim for a fearless, fail-fast culture that lets teams go above and beyond in answering customer needs. This need not apply to all developers–there will be some focused on refining the core product set, for whom fail-fast may not be the ideal working model. However, in the pursuit of unexpected offerings that will delight customers, a healthy attitude to both fail-fast and conventional development is essential.

Often, organizations are held back from being the best they can be by ingrained, deep-rooted cultures. The power of “the way we do things ‘round here” can be hard to crack, but good leaders must help staff buy into change as an ongoing process that will help them and the business to succeed in the long run.

That’s where the concept of experimentation and fail fast comes into play. In these environments, developer teams are given permission to try things out without having to go through multiple rounds of approvals and senior buy-in. That means they can go from an initial idea to a fully testable concept in, say, weeks rather than months or years. It also means they can run their blue-sky ideas through a crash course of reality, bumping up against unforeseen problems–what some people might consider failures, but I think of more as learnings–without being penalized for it.

When developers are given this permission to get ideas off the ground quickly, the benefits to the organization are obvious. Improved access to innovation; a greater chance of discovering more effective ways of working; and a supportive, forward-looking culture that helps to enthuse non-technical staff as much as developers themselves. The same is true for customers–they will benefit from innovations that improve their experience, surprising and delighting them with the idea they didn’t know they needed, but which exactly addresses their needs.

Practical Considerations

There are other key issues to address, particularly senior buy-in and customer-centricity. First, it’s essential that developers know their work is valued by senior leadership. Senior leaders need to trust their experts and not just allow but also champion the fail-fast model if the company is to benefit from the successful innovations that come out of it.

Second, developers need to work in close communication with customer-facing teams to ensure their efforts are directed toward innovations that will translate into improved customer experiences. In other words, it’s important developer teams innovate with the company’s core goals in mind–not just for the sake of it, however tempting that might be.

There are also pragmatic issues to be addressed, such as ensuring your APIs or SDKs are well developed, and there are good documentation/guides to help use these APIs. This is required for both in-house and external developers.

External Developer Networks

Having a wide network of development partners can also help rapidly scale innovation and deliver solutions that exceed customer expectations with speed. By building a community of great minds around the mutual benefit of market-ready innovation, organizations can unlock far more valuable projects, with positive effects for them, their customers and their partners.

An effective developer partnership works on the basis that there is a symbiotic relationship where each side has something to offer to the other. For example, the developer partner may come from a smaller company who has specific expertise and can benefit from the financial support and expertise of the larger organizations. While both sized organizations can benefit from the diverse thinking, agility and challenger mindset of the developer partnership. Whether you’re a large company looking to fast-track customer-centric innovation or a small company with a great customer-centric idea that needs a boost onto the next rung, a healthy developer network can be highly beneficial.

As an example, the accounting industry is currently undergoing a major cultural change, with accountants increasingly seeking to provide customers with value-add strategic services to maintain their competitive advantage. Technology is driving a consultancy-first service model. Accountants have access to more data than ever before, and as a result they can help clients to make effective business decisions based on new analytical insights.

However, making the jump to effective consultancy requires new tools and innovations to turn raw information into usable insights. By working in partnership with a network of cutting-edge developers, accounting software providers can help to conceive, road-test and launch user-friendly solutions.

The value of developer networks is also evident as you look at domain specific needs that might span a particular industry or a particular region. One company may not have the expertise or bandwidth to do it all–but by building effective communities of developers, an organization can expand their reach to tap into niche areas of expertise. It also gives the company the ability to deliver innovations more rapidly. Every company has a limited set of resources, and additional developer networks can help scale this innovation. For the developers, the value lies in reaching markets and customers they may not previously had access to.

Taking Innovation Out of the Lab and into the Market

Whether your company uses in-house developers or a partner network (or both) the core goal should be to hone ideas into realities through collaborative working practices. When developers and customer-facing teams understand one another, they can achieve great things.

It’s an exciting time in the industry. Technology is evolving faster every day, solving more problems and opening up new possibilities. For businesses of all varieties, harnessing the power of developers should be a core priority. It’s not a question of pursuing innovation for the sake of it–it’s about taking practical steps to ensure you maximize the positive impact of tech on your customer experience.

— Shivani Govil

October 31, 2019
5 Key Skills Developers Need to Master in Order to Thrive

The promise of the cloud, in its essence, allows the IT department to focus on generating business value rather than spinning cycles fixing and managing infrastructure. However, the cloud is not a one-size-fits-all proposition, and many early adopters are finding it challenging to move to the cloud. There are well-documented cases of huge budget overruns, far in excess of prior on-premises costs, making estimating costs in the cloud versus the status quo a key skill of any C-level IT executive nowadays.

This has ushered in an era of microservices and cloud-native applications. The symbiotic relationship between the two has enabled new architectural patterns such as microservices, while the cloud itself has enabled cheap experimentation and throwaway infrastructure. This means developers today can focus less on the infrastructure itself and more on dedicating additional resources, time and skills to iterating and deploying new code, which was traditionally only available to big organizations with limitless budgets. In addition, this evolution has created opportunities for a crop of new developers who come from non-traditional IT backgrounds to supplement the tech skills gap that’s currently crippling the industry.

Here are five invaluable skills I believe every developer, whether just entering the workforce or currently in it, should cultivate.

Adaptability Is Key

This goes without saying, but developers today must be polyglots. Ten years ago, a developer would only have to reason about one process, in one language, connecting to a database. Today, with the advent of microservices, there are many different stores of data and many applications, written in many languages, that all need to coordinate with each other over the network.

Different development teams are generally responsible for their own microservices, which in turn interact with other teams’ microservices. Careful thought is required when designing APIs through which they interact. Backward compatibility, availability and graceful failure all become crucial design decisions.

More than ever, adaptability is a key skill. In the past, developers might only have needed to learn one language and one database, and chances are that skill set would have been all they needed throughout their entire career. Today’s developer will know Java (which is still by far the most popular back-end language), but the rise in newcomers such as Go is driving the development of a new wave of cloud-native software, such as Kubernetes and Docker. It’s critical that developers keep up with new languages and database technologies.

Communication Is Critical

Communication is vital. Traditionally, developers have not been known for their communication skills, but with distributed teams and developers working from home becoming more common, working in isolation is no longer an option.

Because of these changes, it’s easy for a developer to become overwhelmed, which is why it’s also important to learn how to schedule time and how to be able to look after oneself physically. Taking breaks, sleeping well and exercising regularly is vital to preventing burnouts.

Always Look for Ways to Improve Your Technical Skills

It’s now easier than ever to improve your technical skills. The most important technologies are open source, meaning you can download everything you need and learn at your own pace. Many online videos and other materials can be leveraged as well; you no longer have to wait for your employer to approve funding for training.

But crucially, the easiest way to pick up technical skills is to practice them in a business setting. This may mean moving jobs to find the right fit. Another way to become familiar with how distributed teams work is to contribute to an open source project. You can contribute to these projects in many different areas, not just coding. Contributing to documentation, for example, is an area that offers a low barrier to entry.

Success in Humility

There are certain traits I always look for when building development teams. First and foremost, I always look for people who are able to clearly express ideas and cooperate with other members of the team.

Humility is a key requirement, because teams that cannot come to a consensus are doomed to failure. It is no use having an intransigent individual who will insist his or her ideas are best; you will waste many hours coming to conclusions with such people. Quite often, hiring a rocket scientist into your team can upset the entire balance.

Don’t Be Afraid to Ask Questions

One particular incident very early on in my career demonstrated another key skill: Never be afraid to ask questions, even if it is the same question you’ve asked previously. At the time, I was working as a mainframe operator for a book sales company. All of the day’s orders were stored in volatile memory; at the end of the day, they would be applied to a batch process that would calculate stock, print invoices and send instructions to the warehouse for customer book deliveries. This was in the time before the internet, so orders were entered manually by the data entry team who worked through order forms sent in the mail. Approximately five people entered these orders, and they usually totaled around 100-200 a day.

I was working on overseeing the batch process that night and was a few weeks into the job. There was an initial step in the batch where manual input was required to start it. However, I encountered an error message and it offered a number of options with increasingly cryptic descriptions. I had no idea which option to choose. Rather than ask the senior person working with me, I simply made a guess. The option I chose ended up wiping the volatile memory holding all the day’s orders. While this caused the company to lose a significant amount of money, I learned a vital lesson: Never, ever guess and always ask for help.

Developers are today’s innovators. With the advent of the cloud, concerns around infrastructure are minimized. In most cases, platforms to run an organization’s business software will already be available. The days of a developer having to worry about selecting a database and working out sizes of servers will be gone. Instead, a developer’s key skill will be in writing the business software and identifying which cloud platforms to use in order to deliver it. Armed with that knowledge and the desire to keep learning, today’s new wave of developers will only become more adept at delivering value over existing business processes.

— David Brimley

September 20, 2019