devopsy.kinsta.cloud

Tag: devops culture

Nurturing a Developer-Centric Culture
The tech world is constantly, rapidly changing and many tech companies are growing up. They are adding to their product portfolios, increasing the number of employees, servicing more users, expanding global reach and more. Typically, when an organization grows up, it doesn’t happen overnight. It takes a lot of hard work, onboarding new talent and a collaborative culture to bring business ideas to fruition. This growth often involves integrating new roles, methodologies and cultures to help a business succeed. One of these new cultures to emerge was DevOps.

DevOps evolved from the need to take a new approach to how developers work. As technology advanced, developers sought new ways to approach their strategies and DevOps emerged as a way to explain this process. It stems from the concept of shortening the systems development life cycle and focusing on continuous delivery with high software quality. This approach empowers developers to perform end-to-end tasks—from development through testing to deployment and operations in production. Many now recognize that DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) and what eventually evolved is a culture that supports developers in the ability to fulfill the jobs at hand.

Built on the foundation of engineering culture and dedicated to empowering engineers, the DevOps culture is intertwined with the concept of continuous delivery and gives developers the responsibility and ability to deploy their products end-to-end. This means developers can move fast and work independently. While DevOps usually refers to the operational aspects of a software development life cycle, it can be beneficial to take it a step further. In a truly developer-centric culture, the engineer is involved in the entire life cycle of software from inception, product, QA all the way to operating it in production. For example, an engineer who is working on their product can progress quickly because they can operate as though they are within their own startup. Engineers can release a feature in a few minutes once they develop it. However, to thrive, this culture needs an entire organization’s support.

Being involved does not necessarily mean being fully responsible. Product managers, for example, are responsible for the product, but it’s essential that the engineers are involved in the product definition. This goes for all aspects of the product development life cycle, where engineers need to be involved in everything.

There are effective ways leadership can support a developer-centric culture. The more this culture is embraced, the more successful a company’s and the industry’s engineers will be. There are a number of ways organizations can effectively support DevOps and build and sustain a developer-centric culture.
1. Understand developer-centric. Without understanding what DevOps is, it’s hard to nurture its growth. It’s important to keep in mind that it’s a concept of empowering developers to seamlessly work through the SDLC. Many view DevOps as a role or a job description with a specific set of responsibilities, but it’s much bigger than that. It’s a culture.
2. Set guidelines, not rules. Developer-centric cannot and will not fit into a box. Most companies create checklists of to-do’s for processes but those ultimately fail. Instead, companies should focus on creating guidelines to encourage creativity and critical thinking so engineers can effectively plan, assess and reflect on every portion of their contribution to the final product and the process. It’s key to have engineers that are proud of their work and proud of what they’re working towards.
3. Nurture engineers to take ownership and responsibility. Involve engineers at every step of the product life cycle, starting from product inception. C-level leadership and other managers need to trust the team to think proactively and execute effectively. The team was hired with a purpose; don’t micromanage and accept that some developers might do things differently than others—there’s not necessarily only one “right way.”
4. Foster a collaborative environment. Collaboration between engineers—as well as between engineers and other departments—can spark creativity and solutions to problems or create new products entirely. Furthermore, hearing and respecting different viewpoints can inspire positive change throughout the entire organization.
5. Embrace mistakes and encourage continuous improvement. There’s no right or wrong way to do things, so it’s important to empower engineers to be creative and have the flexibility to make mistakes. Their mistakes can lead to insights and knowledge that might not have been discovered otherwise. Pain equals growth. Making mistakes and taking risks make individuals, departments and an organization better.
6. Empower engineers both inside and outside the organization. As companies grow, their responsibility to the tech community grows, too. The term “empowering engineers” should be seen as a responsibility both inside and outside an organization. The stronger and more empowered engineers are, the stronger and more successful the industry will be as a whole.
In conclusion, as companies grow up, it’s important to be fluid with the roles and cultures that morph to accomplish goals and objectives. Developer-centric is an example of when culture evolves to accommodate and tackle a new demand within a business. If you think of a process of software development at an assembly line, we take the assembly line and make it a circle so that developers that write the software are responsible for the whole life cycle from writing it to operating it. It’s a dev-centric culture. Now that dev-centric is here, it needs to be nurtured and supported by leadership, both inside and outside the company to thrive.
April 18, 2022
Shifting Engineering Priorities for 2022

Nearly every aspect of the software development process is accelerating, from the increasing speed of programming languages to the expectation of faster delivery. This has resulted in the misconception that speed and efficiency should be a DevOps team’s or engineer’s top priority. Though agile transformations have been a central strategy for most organizations in recent years, investing in team culture while undergoing an agile overhaul is paramount to overall success.

For many workers, the pandemic caused a shift in priorities, so much so that as we begin to emerge from the events of the last two years, almost a quarter of UK workers are planning job changes and businesses are tackling the so-called Great Resignation. A desire to improve work-life balance and enjoy better benefits like flexible working has made employees more likely to leave a job. As such, maintaining employee satisfaction and protecting team mental health should be a top priority for companies wanting to keep retention rates high.

This starts with leadership, and engineering and DevOps leaders must have full transparency into their teams, with an understanding of exactly what motivates them. With this in mind, here are three top priorities for engineering and DevOps leaders in 2022.

1. Prioritize Team Culture

The tech sector is notorious for a high employee turnover rate, with a LinkedIn report putting it at 13.2%, far above other industries. For engineers especially, the increased pressure to deliver at lightning speed has created an unsustainable “churn and burn” culture.

Simultaneously, engineers have no shortage of options when it comes to job prospects as demand is booming. In fact, this particular sector in England and Wales advertised more job vacancies in 2021 than all British businesses across 2020.

To avoid any leavers, it’s important for engineering leaders to establish a unique and engaging culture within their teams, and actively and continuously examine it to ensure that engineers feel supported and valued.

However, there are a few key principles shared across world-class engineering teams. Allowing engineers to work on projects that excite them and allow them to explore their creativity is crucial. This may involve giving them dedicated time to work on developing their skills and pursuing innovative projects. In addition, leaders should cultivate a culture for their engineering teams that is built around appreciation, collaboration and psychological safety. Weaving open and honest career discussion and satisfaction check-ins into one-on-one meetings will help employees feel listened to and motivated by their personal progression.

2. Use Data as Your Gut Check

Ensuring decisions are data-driven is also incredibly important. The best leaders are often those who use concrete evidence to strengthen their teams. Engineering leaders must use data and metrics to gauge the health of their teams in the current jobs landscape.

Even for engineering leaders, a team’s day-to-day programming can sometimes seem like a black box, so finding clear insights about the development process is imperative. With an engineering metrics solution, it is possible to obtain better visibility into your team’s workflow. This not only helps ensure efficiency and quality, but it can also help to gauge employee success and morale.

Continuous health monitoring using a robust set of metrics will provide leaders with early identification and help to resolve any friction. A data-driven platform to ensure that individuals’ contributions are ‘seen’ is fundamental. Monitoring a teams’ daily workflow helps to identify standout employees that may otherwise fly under the radar, as well as flagging those who may be struggling. It’s important to pay particular attention to metrics that drive employees toward their professional goals and help to remove bottlenecks across teams.

Prioritizing constructive feedback and one-on-one conversations with employees is crucial to employee success and retention. The focus must be on frequent check-ins with engineers to ensure that they are thriving personally and professionally.

3. Focus on People First, Rather Than Performance

Nothing will ever be as important within a team as the people. Only the engineering and DevOps leaders who prioritize people through a variety of tools and techniques will reap the rewards and stay ahead of the competition.

Recent research has shown that happy employees are up to 12% more productive.

An engineering team will deliver their best work when they feel encouraged by leaders, have the space and autonomy to work in a meaningful way and have accomplishments acknowledged and celebrated.

As leaders, it is critical to remember to check in with team members as people, before checking in with them as workers.

Engineering leaders will likely be battling for in-demand talent in 2022 and beyond as they continue to contend with the Great Resignation. In the face of this, there is a real opportunity for leaders to distinguish teams through their engineering culture. Whether you are cognizant of it or not, a team has a culture. It’s incumbent upon engineering leaders to make having a people-first culture the top priority in 2022.

March 1, 2022
The DevOps Journey: Continuous Mindset Starts With Cultural Change
DevOps is not just about technology. In many ways, the technology aspect of DevOps is finite but the people, organizational and cultural aspects are infinite. We see many clients get so focused on the tools and technology that they forget about the impact beyond the technology. An important part of building a world-class DevOps process is understanding the cultural and organizational changes that are required to be successful and making those a priority, as well.

Many organizations have still either not started their DevOps journey or are in the first generation of DevOps, which is creating a greater gap between elite and low performers. The business changes and delivery cycles are coming faster than ever, making it critical to use world-class DevOps. Pushing toward continuous flow requires technical, process, people and cultural evolution to keep pace. To achieve continuous flow, we need a continuous mindset. A continuous mindset requires new skills, new ways of thinking, new cultural norms and new responsibilities.

Continuous Mindset, Continuous Flow

Most companies don’t realize the cultural impact a fully automated pipeline and continuous flow will have on development and operations (and beyond). Change can be difficult and organizations are often met with FUD: Fear (automation brings fear that jobs will be automated away), uncertainty (the unknown creates anxiety) and doubt (needing to employ new skills and new ways of thinking can create doubt about whether resources can adjust).

The rapid pace of business change requires more nimble, flexible and lean approaches to DevOps to meet tomorrow’s demands. This requires changes to structures, interactions, control, processes and expectations. All of these impact the culture and connections within the organization.

Let’s start by defining a few terms:

Continuous integration: The practice of merging all developers’ working copies to a shared mainline several times a day. Grady Booch first proposed the term in 1991, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day—perhaps as many as 10 or more times per day. Common continuous integration practices include maintaining a code repository, automating the build, making the build self-testing, testing in a clone of the production environment and more.

Continuous Delivery: The official definition is, “A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing and releasing software with greater speed and frequency. The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.”

Continuous Deployment: A strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users. The logical next step after continuous delivery: Automatically deploy the product into production whenever it passes required validations.

Continuous mindset is intertwined throughout all three of the above approaches. To reach the maximum value in each area, a continuous mindset needs to be enabled, matured and applied to disciplines in other DevOps areas. The changes are across people, processes, technology and culture. Like DevOps, gaining a continuous mindset is a journey that will take time, many steps and constant learning.
Continuous mindset changes the way people achieve outcomes for your business. This requires an emphasis on changing the way people think at every level of the organization, the way people are connected and the way they work. Achieving true continuous mindset ROI requires significant cultural adoption and collaboration. A key component is leveraging strong organizational change management (OCM). Six OCM steps to achieving the cultural shift to a continuous mindset include:

Change management and readiness: Share with internal stakeholders where we are going and how we are going to get there. Set expectations.

Sponsorship: Create clear alignment and engagement at the executive level.

Stakeholder engagement: Get everyone on board. Identify who is impacted as well as who is responsible and accountable. Understand reactions and resistance and provide support.

Communication: Get the right information to the right people at the right time. Move stakeholders from awareness to buy-in, commitment and readiness. Communicate messages to multiple levels of the organization.

Capability development: Provide the education and training needed to be successful in the new culture.

Organizational alignment: Align roles, structure, processes, policies and systems with changes and desired business outcomes.
Shifting Responsibilities

Ultimately, a continuous mindset changes the organizational engagement model and requires organizations to align on how and when they will work together. This requires shifting responsibilities and empowering teams/individuals to contribute to the improvement of DevOps capabilities. Learning and knowledge transition is an important element to enabling the team long-term.

The organization will need coaching as they begin to understand the concepts and adjust the way they work. Different approaches can be used depending on the overall needs. This purposeful DevOps learning approach will provide DevOps coaches to engage with teams along with DevOps subject matter experts to provide input in the preparation activities. Another option is to provide less formal DevOps coaching to engage with targeted teams. This approach is less structured and primarily relies on direct engagement with less focus on the training and scaling project approach.

Transparency is Fundamental to a Continuous Mindset

Part of creating a continuous mindset involves an environment where transparency is fundamental; where everyone feels committed to the results takes ownership and responsibility for improving them. Successful DevOps transformation requires a holistic approach that includes people, processes, technology and culture. Working in cross-functional agile teams; working with small batches; working in sprints; communicating and collaborating all provide the strong foundation necessary to create a solid continuous mindset. If done correctly, breaking cultural changes down into smaller changes can ensure a certain level of quality in the long term.
February 14, 2022
EEEWW—Green iMessage Bubbles | ‘Great Resignation’ Redux | Faster Firefox 96

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: iMessage lock-in lessons, attrition-rate fixes, and more on Mozilla.

1. ‘Never Date a Green Texter’

First up this week: The weekend story getting the technorati chattering was about how Apple iMessage denizens pour scorn on Android users—identifying them by their “icky” green chat bubbles. An iPhone user’s message gets a “proper” blue background, y’see.

Amusing though the story was, the writer seemed to be hell-bent on proving some sort of Apple C-suite-led “conspiracy to lock in.” The reality is far more mundane—but it teaches important lessons for DevOps.

Analysis: Unintended consequences FTW

Could your DevOps team make a trivial engineering decision that pays unexpected dividends? While lock-in might be distasteful, seemingly irrelevant design or technical choices can have huge ramifications with users.

Tim Higgins: Why Apple’s iMessage Is Winning

[The] pressure to be a part of the blue text group is the product of decisions by Apple executives starting years ago that have … helped to cement the iPhone’s dominance among young smartphone users. [It] encourages people to pay the premium … and remain loyal to its brand.
…
Teens and college students said they dread the ostracism that comes with a green text. The social pressure is palpable. … Jeremy Cangiano, who just finished up his MBA, … tried to cash in on it last year by selling his own merchandise that touted, “Never Date a Green Texter.”
…
The blue iMessage bubble was born out of a simple engineering need, according to Justin Santamaria, a former Apple engineer who worked on the original feature. … The idea that it would keep users locked in to using Apple devices wasn’t even part of the conversation at the time, he said.

And then the other shoe dropped—via Ron Amadeo:

Google took to Twitter this weekend to complain that iMessage is just too darn influential with today’s kids. … The company is hoping this public-shaming campaign will get Apple to change its mind. [But it] probably has the least credibility of any tech company [because it] has released 13 half-hearted messaging products since iMessage launched in 2011.
…
Google … seems to have learned nothing from its years of messaging failure. Today … the situation is an incredible mess, and no single Google product is as good as Hangouts was in 2015.

Ouch. With a sociological perspective, here’s Christina “filmgirlcw” Warren:

iMessage is incredibly popular with certain demographics. … It’s an in-group signifier—the way teens have always had in-group signifiers (when I was in high school, it was AIM, a Nokia, and wearing Abercrombie). … It’s always fascinating for me to go to other countries and see a ton of iPhone users not using iMessage but something else because that app has become the in-group signifier. … Every teen I know uses Discord more than they use almost anything else.
…
It isn’t about lock-in or regulation or technology. It’s about fashion.

2. How’s your Attrition Rate?

A study published this week says DevOps orgs and other internet companies rank third for attrition in the 38 industries surveyed. And if you lump that category together with “enterprise software,” it would be in clear first place.

Analysis: We’re #1! Oh, wait …

But some companies get this right—how can you be one of them? Culture, innovation, recognition and remote work. It’s definitely not only about pay.

Donald Sull, Charles Sull and Ben Zweig report their fascinating study: Toxic Culture Is Driving the Great Resignation

Between April and September 2021, more than 24 million American employees left their jobs. [But] while resignation rates are high on average, they are not uniform … from less than 2% to more than 30%. … More-innovative companies … are experiencing higher attrition rates than their more staid competitors.
…
Pay has only a moderate impact on employee turnover. … A toxic corporate culture is by far the strongest predictor of … attrition and is 10 times more important than compensation. … Job insecurity and reorganizations are important predictors of how employees rate a company’s overall culture. … But it is surprising that … the more positively employees talked about innovation at their company, the more likely they were to quit. … Employees are more likely to leave companies that fail to distinguish between high performers and laggards [or] that tolerate underperformance.
…
Our analysis identified … actions that managers can take … to reduce attrition. … Lateral career opportunities are 12 times more predictive of employee retention than promotions [and] 2.5 times more powerful [than] compensation. … Company-organized social events, including happy hours, team-building excursions [and] potluck dinners … are a key element of a healthy corporate culture. … Unsurprisingly, when employees discussed remote work options in more positive terms, they were less likely to quit.

And the flipside of resignation? Hiring replacements. Let’s turn to the equilibrium of Nash Reilly:

It’s only gotten harder in recent months [and] I think I know why. … You need to offer engineers some combination of these three things to pique their interest: Cool stuff to work on, smart people to work with [and] some degree of repeatability.
…
You can’t really prove to an engineer that you can give them things like good management, minimal churn, and decision making authority [so] let them talk to your employees. … Also, figure out a way to let your team “backchannel” to the candidate. [If] your product is not that cool … play up the things you can offer them: smart coworkers, and a stable working environment. … You can afford to be honest about what it is that you do offer to a candidate, [so] pitch them the truth: that you want to do good work, sustainably, for as long as you can—ideally with them on your team.

Perhaps the smart money is already skating to where the puck will be? Here’s echelon:

Engineering salaries are … one of the biggest expenses. … Companies love that they can now hire remotely and pay adjusted cost of living. They’ll hire as many workers in middle America as they can, and once enough of the workforce is concentrated outside of expensive cities, you’ll see them stop hiring in SF and NY entirely. [And] startup capital is already beginning to shift to … emerging markets. Employment will eventually head there too.
…
Make your money now while the iron is still hot.

3. Say Something Nice About Firefox

After accusing Mozilla of jumping the shark last week, perhaps I owe the Firefox folks a positive inclusion this time? The release notes for Firefox 96 certainly sound good.

Analysis: Improved sound; better perf; stronger anti-CSRF

Outside the Apple walled garden, Firefox is about the only non-Chromium browser. A browser monoculture can’t be a good thing for anyone—not DevOps nor users.

Michael Gariffo: Firefox 96 update focuses on noise improvements, main thread efficiency

On the desktop side of things, Mozilla’s latest release made “significant improvements” to the browser’s built-in [sound] noise suppression and auto-gain-control features. These improvements are aimed at web-based video chat users.
…
The second tentpole feature in version 96 focuses on reducing main-thread load, which should help the browser function better on older, slower, or congested systems. [And] a new enforcement setting for cookies … will, by default, apply the “Same-Site=lax” policy. Mozilla claims this will help better defend users against Cross-Site Request Forgery (CSRF) attacks.
…
Mozilla also acknowledged that it is working on correcting the performance of detached videos being played in full screen on macOS devices. … No timeframe was mentioned for when it might be available again.

Okay. Sounds good. But not to Tetch:

Never mind all that fancy stuff. … Any reduction in crashes?
…
FF crashes for me several times a month. … I always take the trouble to fill in the “What were you doing immediately before the crash?” section of the crash submission dialog, and never hear another thing.

But more efficiency on the main thread? Tell me more. ksec:

Such an important detail that deserves at least few more sentences of marketing message or explanation. But the whole release note just feels like they couldn’t be bothered anymore.

The Moral of the Story: A weasel wishing Happy New Year to a chicken harbors no good intention.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Moritz Knöringer (via Unsplash)

January 13, 2022
When, How and Why to Build a Developer Relations Team

The developer role is changing. More and more often they are being rightfully viewed as key stakeholders who aid in setting company direction in this product-led world that we live in. For many technology vendors, earning the trust of developers is critical to their short-term and long-term success, but this presents a challenge. Developers have more than a full plate of work and traditional marketing tactics can fail to gain their attention. A new, more authentic approach was needed. This has led to the emergence of developer relations (DevRel), a term that can mean a lot of different things to different people.

I view the role of DevRel as being responsible for creating good mutual relationships between a technology company, its product and external developers. Mature DevRel programs typically sit at the intersection of the marketing, engineering and product teams, as it is common to have developers in each of those groups. As such, DevRel teams consist of a unique group of people who fall somewhere in between the developer world and the marketing world. However, DevRel isn’t a one-size-fits-all idea. For early-stage startups, the makeup of a DevRel team tends to be more organic.

When Should an Early-Stage Company Build a DevRel Team?

Creating a DevRel team too early can be a mistake for many early-stage companies. It can be exciting for an early-stage company to want to invest in DevRel from the get-go, but the truth is, putting together this team too early (and before knowing if the product is even a fit in the market) can be money wasted. Developers have long memories, and bringing a flawed or unfinished product to them could create long-term damage to your brand.

You need to first prove your worth in the market and experience growth before investing in DevRel. This way, you can ensure that your hypothesis was correct and your products have proven value. Once you’ve proven your hypothesis and have tested your products thoroughly, the next step is establishing short-term and long-term goals for the DevRel team you want to create. Know your market and have a plan of execution ready.

What Does an Early DevRel Team Look Like?

In the early stages of Algolia, for example, our DevRel team wasn’t even a formal DevRel team. It was a blend of DevRel and customer support. Our first priority was to create the best possible developer experience (DX). We, as developers, took the initiative to interact with the market. We were personally engaging with people that signed up with the service to offer our help.

When your customers are developers, they can find it frustrating to speak to those who don’t understand code; therefore, it can be helpful to embrace a developer-to-developer connection when handling one-on-one support. This is invaluable for helping understand customers’ pain points and iterate very quickly with regards to the product. Imagine hearing about a bug and being able to fix it near-real-time!

The advice I would give to anyone starting an early DevRel team is that your first evangelists should always be your core developers—they know your product inside and out. However, make sure that your core developers are using your product—”Eat your own dog food!” This is a very good way to make sure that your core developers have empathy with external developers. In fact, even today we ask core developers to do support a couple of days per month. As we approached the 150-employee mark, only then did we create a fully dedicated DevRel team. It was only then that we could expand into specialized skill sets to push activities at a larger scale.

How to Engage Your Own Developers to Be Evangelists

Once a strong developer experience is established, DevRel should focus on maximizing inbound activity, not specifically revenue. This can be in the form of free users, trials, student interest, etc. It’s a long-term growth investment. Trying to treat DevRel as a sales strategy and having the goal of impacting revenue is a recipe for failure. You want the developers on your DevRel team to be authentic. They aren’t salespeople; they shouldn’t be salespeople and if they try to be salespeople, it won’t be authentic.

Your developers don’t necessarily need to be overly social or extroverted to embrace DevRel, either—that’s a common myth. They can stay true to themselves and genuinely try to help in ways that play to their strengths. Providing content is a great example of this. Have developers complete documentation for the features they build. View documentation as a core part of the product. For too many people, documentation is an afterthought when, in fact, it is one of the most important aspects of a product. Documentation can then be used as a jumping-off point for other content—blogs, whitepapers, etc.

That said, if your developers are genuinely interested in the more social aspects of DevRel, offer public speaking and training tools for them. Developers with these skills can become the face of the company on webinars and panel discussions, attend events on the company’s behalf and more.

The best DevRel programs understand the developer community, what types of tech they are using and then go where developers are to make connections. DevRel should amplify what the developer community is doing by showcasing use cases and solutions to problems. It should give a voice to your community of users by being the glue between developers and product teams.

Why Do Companies Need DevRel?

The API economy is making the role of developers and DevRel even more important than it already was. The competition for the attention of developers is already fierce; it is only going to increase as more organizations recognize that developers need a seat at the table when strategic decisions are made.

Many companies are going to view DevRel programs through the traditional marketing lens with big-budget bets made on general awareness that isn’t personalized. This is going to fail. Instead, companies that have an authentic and measurable DevRel program in place, built around making meaningful connections, will be the most successful. Early-stage companies that embrace this thinking will gain an edge on larger competitors that are stuck in the old school way of thinking.

December 16, 2021
Bridging the Developer Experience (DevX) Gap

They say our past experiences have an impact on how we view life and our general outlook. Routine behaviours and patterns become a program that we follow day in, day out. We stop using our minds to their fullest potential and become trapped in unquestioning, continual cycles of process and emotion.

The same could be said of our experiences in the present—our worlds shaped by the environments around us. The people, practices, tools and culture. Only by challenging these accepted patterns can we start to think about changing our mindsets.

DevOps is a mindset; a way of forming an agile relationship between development and operations teams to speed up delivery of software to support business operations and improve customer experience. By and large, it has been successful. Companies react to change more effectively; software is developed and deployed swiftly. It has become a necessity across most organizations.

There are challenges, as we all know, however. The State of DevOps Report 2021 found that 83% of organizations are implementing DevOps practices, but most are still failing to scale adoption. It’s a situation that hasn’t changed for four years. Why? Among other things, the report states there are too many silos, not enough skilled people, a saturated market with too many tools—and a culture that prohibits scale.

Given that the end goal of DevOps is to generate untrammelled innovation across an organization, getting the culture right is critical. Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

Above all, it’s about creating the best possible developer experience (DevX) in which to thrive.

The Developer Experience Gap

Stephen O’Grady at Red Monk, the developer-focused analyst firm, originally wrote about a DevX (developer experience) gap in this post back in October 2020.

Stephen likened the experience you get from an iPhone to the expectations of developers. The iPhone’s closed SDK created an environment that allows all developers to work in a consistent way. Functions are tightly integrated so that, for example, it would be easy to ensure the music volume lowers when you receive a call. A basic function, but one that we expect to work seamlessly with any app we install.

Since then, developers have been served a vast array of tools and services with more and more software arriving on a daily basis. The challenge is that, where the phone and music player teams were controlled in a way that would make them work well together, modern development infrastructure doesn’t have that capability. In most cases, the toolchain is a “patchwork quilt” of products and services from different suppliers. And it is up to developers to build and maintain that quilt.

This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

Delivering the DevX Factor

Attracting the best people is about showing that the experience they will have in your organization is both rewarding and liberating, so expecting developers to spend the bulk of their time not developing is clearly not an optimal experience. Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

Where to start? Well, contrary to popular belief, you don’t need an army of DevOps engineers to reach your goals. Instead, you need to empower your existing teams to reach their full DevOps potential, supporting their progress with the right tools and training for their experience and role.

As with any work culture (remote or hybrid), the importance of knowing where to find what you need and how to collaborate with other teams has never been so important. Tooling is a good place to start. DevX is affected by the tools they use, so organizing them in a way that helps with the culture is a step forward. In a multi-cloud, multi-vendor environment, there isn’t going to be one tool that does it all so the key is to allow teams to use the tools they love and automate as much as possible to remove the repetitive tasks.

Automation is also a critical element in the race to reduce time-to-market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on developers. Having access to testing automation in a consistent way will improve the overall experience for DevOps teams.

And finally, think about starting your DevX journey by using a self-service platform, where information, tooling and automation can be centralized and made available to developers on demand. For overworked specialists, access to a platform that connects to any tool and creates an on demand environment that automates much of the repetitive work will create more time for them to do what they were originally employed to do: Develop.

December 2, 2021
Bridging Departmental Divides for Successful Automation Projects
For too long, IT has been largely isolated from an organization’s core business. Any division between IT and lines-of-business (LOB) is even more detrimental when speed is not just a competitive advantage but an existential necessity in today’s accelerating digital economy.

As business leaders streamline and turbocharge every facet of their operations, savvy organizations are rushing to eliminate inefficient and damaging gaps between departments by putting more software tools in the hands of more employees. Analysts predict 80% of technology products and services will be built by those who are not technology professionals by trade by 2024.

This hits home amidst the booming trend toward robotic process automation (RPA), low-code/no-code and other automated solutions, which have only continued to grow as more businesses realize the vast benefits of automation: Accelerating operations while also reducing costs; elevating customer experiences and shifting employees to higher-value positions and laying the foundation for new data-driven revenue streams.

Squandering Automation’s Advantages

But these advantages are quickly squandered if there’s a turf battle between the business unit looking to optimize processes and the IT department responsible for deploying the tools to make that happen.

When there isn’t collaboration and plenty of trust on both sides, automation initiatives are more prone to disappointments and delays.

This may happen if the IT department comes across as too smart for their own good, putting less value on feedback from their LOB colleagues and rushing to implement software with a focus on speed rather than outcomes. On the LOB side, leaders may assume their IT counterparts are too technical and don’t understand business objectives and choose to override important IT input about which vendors are best qualified when it comes to support, integration and security.

The problem here is not the technology; hundreds of thousands of businesses across the world have successfully deployed process automation solutions. It’s the execution.

When an automation initiative fails, there’s almost always blame to be shared on both sides of any divide. Likewise, success typically boils down to people across IT and every business department working better together to achieve a common goal.

To embrace a collaborative mindset and set up your automation projects for success from day one, I encourage you to follow these clear steps:
1. Reinforce a shared mission: Whether it’s automating the customer onboarding process or deploying RPA bots to automate a repetitive, time-consuming process, communicating a shared mission is the crucial first step to pulling off a successful project. On the IT side, that involves talking with the LOB about their goals, objectives and business strategy. LOB leaders, meanwhile, can emphasize that IT is an equal business partner that has valuable insights and expertise to contribute.
1. Establish visibility and transparency: Armed with a full understanding of business objectives, IT leaders can now evaluate tools built to give all stakeholders a full view of the processes that will be affected. By documenting and mapping out each process within an organization, leaders can better understand current processes and gain insight into areas that are ripe for standardization and automation.
1. Tailor solutions that match the problem: With heightened visibility across the organization, LOB and IT teams can then determine the scope of each problem and tailor solutions accordingly. Some processes can be kept and optimized; some can be tweaked with automation. Other processes may need to be reconfigured significantly before automating or shut down entirely because they are outdated or unnecessary.
A great example of this collaborative approach comes from Coca-Cola Beverages Florida, LLC (Coke Florida): Encumbered with a legacy process repository — a collection of PDFs, videos, pictures and spreadsheets outlining more than 600 processes — Coke Florida standardized and leveraged visual process mapping software to establish an easily accessible document repository that provides visibility and control over key processes, encourages collaboration and increases accountability.

Coke Florida continued an organization-wide initiative to digitize and automate its business processes with digital workflows, forms and RPA software, driving further efficiencies across its entire organization. As the company discovered firsthand, shared goals result in shared success.

When speed and high-quality outcomes become the norm, companies master the essential arts of urgency, resilience, visibility and collaboration. By bridging the divide between departments, organizations not only drive internal efficiencies but also gain a competitive advantage that is indispensable in today’s burgeoning digital economy.
October 22, 2021
Trust in Cloud Providers is a Developer Issue
Earlier this summer, we worked with ClearPath Strategies to ask developers about the level of trust they have in their various cloud service providers. What we learned spoke volumes: While developers’ familiarity and comfort with Amazon, Microsoft and Google position these well-known cloud providers as market frontrunners, developers often do not agree with the companies’ values.

The research project gathered insights from more than 800 developers at small and mid-sized businesses, those with less than 500 full-time employees, across a wide variety of industries and geographies worldwide. You can download the summary report here (no signup required).

In ClearPath Strategies’ report, senior analyst Stephanie Fairchild said that “approximately 20% of developers believe that the big three hyperscalers will engage in behaviors that include leveraging their brands to stifle competition, focusing on shareholders more than customer needs, hosting or working with customers that developers find morally objectionable, monetizing user data for their own use and locking them in with proprietary tools. Criteria such as security and performance clearly take priority over these trust issues for developers, but it’s interesting to note that a sizable portion of developers are thinking about how their values align with those of their service providers.”
- Trust plays an important role in developers’ choice of a cloud hosting provider, but needs take precedence; when prioritizing needs or values, developers report they prioritize needs over their values 73% of the time.
- The top three reasons cited for developers’ preference of their chosen third-party cloud provider: Security, trust and quality of service.
- Survey respondents indicated that both hyperscale and alternative cloud providers deliver equally effective performance and security.
The report cited three top criteria for choosing a third-party cloud provider: Security, trust and quality of service. Survey respondents felt that hyperscale and alternative cloud providers deliver equally effective performance and security. Interestingly, although 73% of respondents said they prioritize needs over values when making a purchasing decision, approximately 20% said they don’t trust the big three providers (AWS, GCP and Azure) in what could be considered key moral areas.

It’s no secret that the extensive functionality and brand awareness of hyperscalers make them popular choices for developers, but an alternative cloud provider like Linode, DigitalOcean, OVHcloud or Hetzner can be a more trustworthy partner for innovative upstarts—one that likely offers better pricing and doesn’t threaten or compete with their business. And when an alternative cloud provider meets a developer’s functional needs—which is nearly always the case—developers can have the best of both worlds: A provider they can trust to meet their needs and one that shares their values.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021
October 15, 2021
Decentralized Autonomous Organizations (DAOs): Org-as-Code
We are all familiar with ‘everything-as-code’—a pattern that started with infrastructure-as-code and has now extended to other areas such as architecture-as-code, security-as-code and more. However, all the incarnations we have seen so far have been less than ambitious! The dawn of cryptocurrencies and the underlying blockchain technology is moving us firmly toward organization-as-code. Org-as-code is the most disruptive evolution we have seen so far. The crypto world uses a different term for it: decentralized autonomous organization (DAO).

Before you freak out because, “OMG crypto!” let me assure you that I am not trying to sell you any of the 9,000 (at last count) cryptocurrencies. Undoubtedly, crypto has polarized public opinion. There are crypto maximalists who believe that crypto is the solution to everything. You often hear, “Bitcoin solves it!” Then, there are the crypto skeptics who dismiss the movement as simply digital tulips—a Ponzi scheme at scale for the internet age. Only time will tell if they are right.

Now, my opinion falls in the gray area in between, where some groundbreaking new ways of working are evolving. People across the globe are collaborating in decentralized, efficient, democratic and non-hierarchical ways in the world of crypto. Radical new constructs for the internet age are being piloted—DAOs, smart contracts, pseudonymous identities, tokenomics, etc. just to name a few.

This post is firmly focused on DAOs.

So, What is a DAO?

A DAO is a way to work with like-minded folks around the globe where the business (the org) is owned and managed by its members in a democratic way.

“In traditional organisations, people are at the core and automation is at the edge; whereas in DAOs, automation is the core and people are at the edge.” – Vitalik Buterin

As opposed to traditional organizations that are structured in a top-down hierarchy, with many layers of management and bureaucratic coordination, DAOs provide an operating model for people and institutions that do not know nor trust each other, who might live in different geographical areas, speak different languages and, therefore, are subject to different jurisdictions. Instead of legal contracts managing the relationships between people, computer code enforces the rules.

Some of the key features of a DAO are:
1. An organizational setup based on rules and policies that are encoded as computer code.
2. The rules are transparent and controlled by members, not a central authority; usually, on a public blockchain.
3. Rules are executed by a set of smart contracts independent of human (not even the creators!) involvement.
4. Built-in treasury that no one has the authority to access without the approval of the group/community.
5. Decisions and ideas are governed and funded by proposals that are voted on and managed through voting by token holders.
Colony.io is one startup that helps set up DAOs. A screenshot below from their site gives you an idea of the elements of organizational design that can be (re)defined in the radical new DAO world.

Do We Really Need DAOs ?

Here are a few challenges that DAO attempts to resolve that you often see in conventional centralized organizations:
- Good ideas struggle to reach the top.
- The system incentivizes authoritarian leadership.
- Failure to tap into the wisdom of the crowd.
- There is a higher probability of spectacular failures driven by the greed of a few, as evident from examples such as Enron or the 2008 financial crisis.
- There is usually a lack of transparency in decision-making.
- Good policies exist—usually on paper or hidden away in by-laws—but are not executable.
- Single points of failure are natural due to the asymmetry in organizational structure.
Examples of DAOs

Before you dismiss this as utopian and unrealistic, here are a few real-world of examples of DAOs in play
1. Nexus Mutual—A decentralized ‘people-powered’ alternative to insurance which operates as a DAO. It is run entirely by its members. Only members can decide which claims are valid. All member decisions are recorded and enforced by smart contracts on the Ethereum public blockchain.
2. DAI and MKR—A stable decentralized currency (DAI) and platform for decentralized finance apps (with a market cap of about $5 billion).
3. The DAO ( Đ)—A form of venture capital that started as a crowd-funded token sale. There was no conventional management structure or board of directors. But it got hacked in 2016, and a third of funds were siphoned off. (This is a key example to remind ourselves that if the org is code, then security issues can be near-fatal.)
4. DASH —A digital cryptocurrency. A DAO run by a subset of users called masternodes, which perform standard node functions like hosting a copy of the blockchain, relaying messages and validating transactions on the network, and which, in addition, act as shareholders, voting on proposals for improving DASH’s ecosystem.
5. Flamingo DAO—A DAO that deals in digital art via NFTs. NFTs are non-fungible tokens, not non-functional testing!
6. Gitcoin —Uses DAO to fund digital public good projects ( $24 million funded so far using a quadratic funding model)
These are just a few examples. Adoption is exploding, and stretching into areas like charities, freelancer networks, venture funds, investment clubs and more.

DAOs are still emerging, and there are many aspects that are yet to be fully explored, especially around legal status, regulatory frameworks and compliance. It is, however, only a matter of time before the DAO way of working becomes mainstream.

In my view, it is not a binary question between DAOs and conventional organizations. Adopting many of the practices of DAOs will strengthen traditional organizations and reduce some of the weaknesses we touched on earlier.
July 9, 2021
How to Build a People-First Engineering Team
When we think about successful technology teams, there is a tendency to primarily focus on the technology being created rather than the people who are creating it. While both approaches can lead to successful products, a technology-first approach is often the default when software engineers become managers without necessarily having the right tools to manage effectively. Becoming an engineering manager requires an entirely new skill set that involves different communication styles, time management, organization, tools and software, scoping work, learning how to effectively delegate and identifying the right people to complete the team.

As a CTO, and having gone through this transition, I have noticed that the more a manager is able to be in sync with the people on their team, the less burnout they experience, the higher the employee retention rates and the better work their employees will do.

While most people won’t be entirely people- or technology-focused, here is a quick overview of the differences:
- A team-oriented manager knows the personal and professional struggles their people are experiencing, and there’s a sense that the team they run is all working together on a mission toward the same goal. When you talk to this type of manager, they will naturally gravitate towards giving status updates on the wellbeing of individuals.
- Managers who tend to see the team through a more technical lens will instead identify parts of the project or technological or strategic roadblocks that are impacting the team.
The same issues will be dealt with very differently by these different types of managers. It can be beneficial to record yourself when you are talking about your team to identify where your focus is, and evaluate if that feels right for you.

Building Effective 1:1 Communication with Team Members

An individual contributor is normally accustomed to arriving at weekly 1:1s and working with their manager to solve any problems they may have. When they become a manager, it becomes their role to coach team members to solve their own problems, in addition to building trust. This role change takes preparation, and, if you are unsure how to do it well, you may find it helpful to draft out an agenda that you can follow if needed. You can also gain knowledge about this process by talking to more experienced managers.

What do you talk about in your 1:1 meetings? Even if you are more a technology-oriented person, 1:1 meetings with your team should be less about the status of projects and more about how the person you are speaking to is doing and how you, as a manager, can help. Having started as a software engineer myself, and now as a CTO, I have found the below questions to be helpful as I navigate how best to help my team thrive in their roles.
1. “How are you doing?” If you are speaking with a team manager, another great question is, “How is your team doing?” You want to genuinely understand the status of the individual outside of the technical aspects of the job.
2. “Do you have any feedback for me?”
  I always ask for feedback. For a while, they may not have any; but I often find they start with a small one like “Better options for snacks.” This is an excellent opportunity to build trust by improving the work experience. The next time, they will probably share more until you receive really important feedback, while also improving the relationship. The important thing to remember, here, is to respond to the feedback.
3. “On a scale of zero to 10, how much fun are you having at work?”
  I really want people to have fun at work. You can ask them to give you a number between zero and ten. When they respond with a number, say, six, a great follow-up question can be to ask what is needed to change the situation so that number becomes a seven. How can you help get them there? I have heard a wide spectrum of answers to this question, ranging from easy to complex; from things like permission to be unresponsive for an hour a day to the desire to learn the skills needed to do a different type of job.
4. “Where do you see yourself in the next two years and 10 years?”
  Helping your team define both long and short term goals is a really important part of being a manager. Specifically for engineers, it is a great idea to think about if you want to continue moving up in an engineering role, or if making the switch to a managerial role is a better fit.
5. “How can I help you get to the next level in your career?”
  It is common to get sidetracked when balancing your day-to-day work with your personal life. You can also use 1:1 meetings to help your team members identify what they can do to hit their short- and long-term goals, and how to maintain a better work-life balance.
Supporting Colleagues

This last year has been tough for most people, to varying degrees, which has solidified the idea that we need to be there for team members during difficult times; this goes beyond the pandemic. That can mean sending their favorite meal via delivery, sending a care package or simply making it very clear that when someone on your team needs to step out or take time off, that is fine – no questions asked. To be able to be offline and not need to do a long handoff is so important when you are going through a hard time.

During this move to remote work, as in many leadership teams, my company has gone against the cultural norm of keeping life and work separate. We have acknowledged that it is too difficult to do that right now, and very publicly recognized that everyone is going through something. It has felt like mental bandwidth is filled up with things going on outside of work, so as team members, it is good to make sure work doesn’t add to that pressure.

In a way, this pandemic period has broken down barriers between work and “life” that has made it almost obligatory to focus on people first. From my perspective, this has been a breakthrough in how we can do business moving forward. By thinking about each individual on your team, everyone can be uplifted and heard, which can be the impetus to more innovation. If you are operating at your max with no slack in your system and little support from managers and teammates, you lose creativity. As innovative teams, this experience has been a reminder to build people-first principles into our cultures to promote a healthy work-life balance that lends itself to innovative solutions and better results.
June 2, 2021