devopsy.kinsta.cloud

Tag: employee engagement

Should You Measure Developer Productivity?
A recent McKinsey article entitled ‘Yes, you can measure software developer productivity‘ has got the software developer community talking. And the general consensus is they’re not happy.

Most software developers are not enthusiastic about the prospect of having their individual performance metrics monitored. “Anyone who attempts to measure software in some sort of scientific way is just doing the wrong thing,” said YouTube personality ThePrimeTime. Dave Farley of Continuous Delivery even goes as far as to call the McKinsey report “harmful dribble.”

This debate arises as developer productivity engineering (DPE) is gaining traction as a means to improve developer performances and, perhaps, in response to employment landscape shifts like the Great Resignation, which saw developers and DevOps pros leaving their roles. Companies like Spotify, LinkedIn, Netflix and others are also investing in internal developer platforms (IDPs) to increase developer productivity and satisfaction amid a limited talent supply.

Alongside these ambitions, much has been written about how managers can measure developer productivity in terms of qualitative metrics, like developer satisfaction, as well as quantitative metrics, like number of commits or story points, deployment frequency or failure rates. But can tracking such metrics deliver tangible results? Or do they go too far?

Below, we’ll consider whether you can actually measure software developer productivity. But more than that, we’ll evaluate whether this is a meaningful tactic with desirable outcomes.

Ways to Measure Development Productivity: DORA

First, let’s look at some of the standard techniques to measure development productivity. The DORA metrics, produced by the DevOps Research and Assessment (DORA) team at Google after years of research, identified four key metrics:
1. Deployment frequency: How often you ship changes.
2. Lead time for changes: The time between a commit and it reaching production.
3. Change failure rate: The percent of releases that fail; downtime, worsened service or rollbacks.
4. Time to restore service: The average time it takes to respond to an issue, also known as mean-time-to-recovery.
These metrics could be helpful indicators of a software development team’s overall agility and health. They can signal bottlenecks in the CI/CD process or highlight where too much time is spent remediating issues, encouraging positive changes. Solving these root causes could all improve a team’s productivity.

Going Beyond DORA: SPACE

DORA also added reliability to the list. That’s understandable, given the interest in building reliable systems. But things start to get a little more complex when SPACE enters the equation.

Proposed in a 2021 paper by GitHub researchers, SPACE augments DORA with the following attributes:
- Satisfaction and well-being
- Performance
- Activity
- Communication and collaboration
- Efficiency and flow
Metrics like satisfaction or communication and collaboration are pretty subjective. Plus, it can be challenging to gather this data and encourage engineers to speak honestly in surveys. Measuring the activity of individual members, like the number of issued closed or pull requests made, isn’t exactly tied to end value and could even produce a negative psychological effect.

“Consequently, teams can become fixated on them, as seemingly positive changes are relatively easy to achieve,” wrote James Walker. He adds that SPACE still doesn’t tell you why measurements have value—furthermore, it lacks actionable information and might be tricky to implement, given developer pushback against performance analysis systems.

Opportunity-Focused Metrics

The McKinsey report adds to the mix what it calls “opportunity-focused productivity metrics,” which include inner/outer loop time spent, a Developer Velocity Index benchmark, contribution analysis and a talent capability score. (It’s not totally clear how these metrics can be computed). It then organizes all these metrics into a framework that further segments measurements into system, team and individual levels.

While some believe in the framework’s legitimacy, many commentators don’t see the practicality of implementing such a framework in practice. “Introducing the kind of framework that McKinsey is proposing is wrong-headed and certain to backfire,” wrote the PragmaticEngineer.com. “The report is so absurd and naive that it makes no sense to critique it in detail,” wrote Ken Beck.

Things to Avoid With Developer Productivity Metrics

Apparently, developers are very weary of being measured. And given the recent backlash, it seems like overreliance on productivity metrics could negatively impact the engineering culture. So, engineering leadership should be careful when implementing these sorts of tactics. Here are some anti-patterns to consider.

Don’t make it about individual performances. Metrics like DORA have become standards for measuring the efficiency of software teams, but they shouldn’t be applied at the individual level. “Measuring software development in terms of individual developer productivity is a terrible idea,” said Dave Farley. Technology development is more of a collaborative process; performance metrics should reflect how the team operates.

Don’t measure developer productivity in isolation. On that note, performance metrics shouldn’t be judged in isolation. Issues with failures, for example, often depend on contexts outside of an individual developer’s control. At the same time, it can be hard to correlate individual developer contributions to end customer satisfaction.

Don’t create an opportunity to gamify productivity systems. Leadership shouldn’t directly tie a developer’s salary, reputation or position to whether or not they hit certain metrics. If productivity systems carry this much weight, they could become gamefied.

Don’t put in more effort than it’s worth. In tech, where there’s hype, there’s money to be made—and a host of vendors ready to hawk monitoring tools. What’s more, to enact these productivity measurement enhancements, McKinsey noted that “most companies’ tech stacks will require potentially extensive reconfiguration.” Devoting many engineering resources to monitor engineers just seems like a big pill to swallow.

Don’t put too much faith in metrics. Lastly, metrics only show one side of the picture. They are only data points and can’t always depict what it’s really like on the ground. Furthermore, qualitative responses also might be skewed due to reluctance to speak up.

Remember Goodhart’s Law and Focus On Quality

Personally, I believe that measuring things like developer productivity, efficiency, experience and satisfaction does have some merit for some businesses. Most teams are now working asynchronously, and metrics help leaders take the pulse of a team’s performance, even if they are all remote workers.

It’s also nothing new. Leadership has been attempting to measure developer productivity for years. But, these metrics often lack context and come with many caveats to consider. Thus, they shouldn’t be given a huge seat at the table.

I like this ‘law’ from British economist Charles Goodhart, which is colloquially summarized as “when a measure becomes a target, it ceases to be a good measure.” In other words, when you start working for the metrics, the engineering culture and overall code quality might decline. This matters, since a separate study found that increases in code quality tend to be followed by an increase in developer productivity.

So, focus first on establishing code quality and, hopefully, productivity will flow.
September 18, 2023
6 Ways To Empower Developers and Increase Productivity

A big goal of DevOps is to increase productivity. Yet many organizations still struggle with the efficiency of their software release processes. In fact, 54% of engineers stated they have too many manual steps within their deployment process, according to an Armory survey. And with the pervasiveness of multi-cloud, developers now face an escalating number of deployment environments, each carrying their own nuances.

Development teams want to move as quickly as possible without barriers. Yet, there are often hurdles to seamless deployments. For example, the code might be 100% ready to deploy, yet someone still must validate it before it reaches production. Manual bottlenecks like this in the CI/CD process can make developers feel like their code isn’t worthy of deploying and may even amplify feelings of burnout.

I recently met with Anna Daugherty, senior product marketing manager at Armory, to see what technology leaders can do to remove barriers within their software release cycles and increase productivity. According to Daugherty, many of these strategies boil down to having empathy for developers and their needs. “Developers aren’t machines; they’re people, and people deserve to have a quality of life when they’re doing their jobs.” Below, we’ll highlight tips and tricks to keep in mind to improve release fluidity.

1. Identify Where Your Manual Checks Are

The first step to speeding up CI/CD is identifying where manual steps exist within the development workflow. The DevOps life cycle, often visually depicted as an infinity loop, includes many states, such as design, build, test, deploy, assess and monitor. But if each step has one or more manual steps, you accrue a lot of manual debt, said Daugherty.

Therefore, engineering leads should seek to remove manual checks whenever possible. Of course, this may not be realistic within certain situations, such as financial institutions that require manual approvals at the last mile. However, everything should be smoothed out and automated up to that point, said Daughtery.

2. Shift From Continuous Delivery to Deployment

Depending on who you ask, the ‘CD’ in ‘CI/CD’ may stand for continuous delivery or continuous deployment. As part of reducing friction in the software release process, Daughtery encourages teams to begin to embrace the latter whenever possible. If deployment remains inhibited by unnecessary manual steps, it can decrease scalability and interoperability.

3. Increase Confidence With Testing

Of course, if we introduce more automation into the CI/CD pipeline, we must ensure the software is rigorously tested for errors and vulnerabilities. Daugherty encourages development to embrace automated, continuous testing approaches at every juncture, whether pre-production, inter-production, or throughout the application lifecycle. There are also advanced deployment strategies to consider, such as canary testing, which rolls out new changes only to a small subset of users or blue-green deployment can deploy to different places at different times.

These deployment strategies can help build confidence while reducing the risk of disrupting a majority of your user base with untested production updates. “The more you can integrate testing into your process, the more confident your process will become,” said Daughtery.

4. Chose The Right Toolsets

So, how do we implement more automation into the DevOps cycle? And what sort of tools should we look for? According to Daugherty, when scouting for DevOps tools, technology leaders should prioritize open solutions that aren’t closed-off environments. Instead, they should offer flexibility and the ability to integrate with the tools you already use every day. “You can have all the tools in the world, but if they don’t fit together, that can drag down the process.”

5. Consider Open Source Software (OSS)

On that note, consider open source software (OSS) where possible. OSS like Argo or Spinnaker has the potential to empower developers and bridge gaps in the CI/CD process. Other projects from the Cloud-Native Cloud Native Computing Foundation (CNCF) and Continuous Delivery Foundation (CDF) are mature with proven stable adoptions.

And although there is some weariness around OSS, particularly around unknown vulnerabilities and project maintenance concerns, “you can still be successful, secure, and scalable with open source,” said Daugherty. Open source also delivers community benefits and helps engineers feel like they are part of a bigger picture. “[OSS] is the opposite of burnout. It brings people together. It’s a community builder.”

6. Become Developer-First

Transitioning into a developer-first organization is another way to increase developer satisfaction and efficiency. But to become a developer-first organization, developers will need more say in the processes—this will involve balancing top-down requirements with total developer control. For example, leaders should suggest tools to enhance productivity but accept feedback on an ongoing basis to see what works best.

To support these efforts, the concept of developer experience (DX) has entered the lexicon in recent years. Building with developer empathy can result in more usable, frictionless software that increases productivity. DX is crucial within the burgeoning area of platform engineering, as the goal is to create reusable, internal self-service platforms for developers to leverage.

Interestingly, Netflix extolls what it calls full-cycle development, in which a developer oversees the building and operational aspects of a single component throughout its entire life cycle. “It’s an interesting way of addressing burnout because you feel more connected to what you create,” said Daugherty.

Final Thoughts: DevOps Isn’t Dead

Above, we’ve highlighted some potential strategies to increase developer productivity. By replacing manual bottlenecks with more automation, you can increase deployment fluidity. Considering how tools are acquired and iterating upon feedback from engineers can also help improve consistency while retaining quality talent.

Looking to the future, Daughtery hopes that similar roles such as DevOps, site reliability engineering and platform engineering can come together and join forces. Because, at the end of the day, they share many goals. And contrary to some grabby headlines, DevOps is far from becoming obsolete. DevOps is not dead. It’s very much alive and increasingly important.

January 20, 2023
Majority of Open Source Devs Open to Change Jobs in 2022

Open source is the foundation of most modern software applications. Now more than ever, retaining developers with experience working on and with open source projects is critical to maintaining software development agility. Yet amid the Great Resignation, it can be challenging to keep talent happy—organizations must demonstrate a commitment to employee benefits, mentorship and cutting-edge technologies to remain competitive.

The EDB Open Source Talent Survey 2022 surveyed over 1,400 developers and DevOps professionals working on open source projects. Below, we’ll highlight the key takeaways about their volume of work, the quality of on-the-job training and top motivators that could influence workers to take a job elsewhere.

The Great Resignation Persists

It’s not news that IT is under mounting pressure to deliver new features and applications to meet surging digital demands. As a result, the amount of work has increased across the board. The report found that 67% of respondents said their volume of assigned work has increased in the past 12 months.

Employer favorability has also declined slightly—28% have a less favorable view of their employer over the last 12 months. Although 46% are satisfied with their current job, 44% are satisfied but would be open to new opportunities. And 10% said they were not satisfied with their current position. Taken together, that means 54% are open to or actively looking for new roles.

Mentoring: An Enticing Benefit

So, what are the main drivers that would influence IT workers to change jobs? It’s no surprise that increased pay and benefits are a top reason behind most resignations. However, salary is not the only factor—43% say improved career opportunities influence a job shift, a steep rise from 21% in 2021.

On-the-job mentorship and training are also becoming more desirable. A little over a third (38%) said that better access to mentorship would make them consider another job opportunity. This was followed by working with more cutting-edge technologies (32%), greater access to training and certifications (30%) and allotting more time for open source projects (19%).

Interestingly, one-fifth of responders who said they were satisfied with their current employer said their organization introduced a mentoring program in the past year. This indicates that investment in employee career advancement helps increase morale and retain skilled workers.

Career Advancement And Training

Out of the above reasons developers are open to switching jobs, one factor in particular is increasingly important: Working with cutting-edge technologies. This figure doubled in the last year, rising from 16% to 32%. Most engineers prefer not to work with cumbersome legacy technologies or manage rising technical debt. And if an organization isn’t evolving its software infrastructure, employee skillsets become stale.

Working with new open source or cloud-native technologies can help retain workers, but will likely require training. In terms of specific categories, 41% said that training in emerging technologies, like cloud, is a favorable factor in considering another job opportunity.

From a security perspective, ongoing training is also vital to staying on top of emerging exploits. As a result, 43% said security training is an interesting perk when considering a job shift. These areas are followed by training on core technologies like database and infrastructure (38%) and training on compliance (37%).

Final Thoughts

Open source software is pervasive and at the heart of today’s digital innovation. Nearly all applications depend on some form of open source software, but it’s no less prevalent in the DevOps sphere, where open source projects are used in continuous delivery, container orchestration, observability and a multitude of other stages of the software life cycle.

Supporting the needs of skilled labor will be necessary to leverage the benefits of open source projects. As such, organizations will require not only competitive wages but also relevant training and investment into cutting-edge technologies to retain such developers.

Another factor that could drive workers away is unnecessary toil, which can negatively affect morale. A company’s environmental, social and governance (ESG) initiatives can also affect its talent pool. Furthermore, a commitment to high-quality developer experience can ensure the needs of developers are heard and respected.

The EDB Open Source Talent Survey 2022 surveyed over 1,400 application developers and IT professionals from around the world. It targeted open source technology users, specifically those holding application development, information technology and operations titles. For additional insights, you can read the full report here.

July 29, 2022
How Visibility Helps Devs Focus on Innovation

As software engineering leaders adjust to a future defined by remote and hybrid work models, they are shifting priorities in the organization of work to compensate for the lack of in-person collaboration. According to a recent study conducted by Jellyfish, the top priority for engineering leaders is ensuring that each member of their team is focused on the highest-priority work for as much time as possible. To achieve this goal, these leaders are using real-time visibility and data-driven decision-making to guide more effective management.

Earlier this year, Jellyfish analyzed the work of more than 23,000 engineers and surveyed hundreds of leaders to better understand the current state of engineering management. The research revealed that engineering leaders are shifting resources away from reactive work—such as responding to customer-reported bugs—to the type of work that directly impacts top-line revenue. Additionally, engineering teams are emphasizing growth and innovation, developing the type of infrastructure that will enable their teams and their software to scale long-term.

Prioritizing Visibility

To shift from reactive to proactive work, engineering leaders must first have visibility into what their teams are doing. How can you allocate your time and resources more effectively if you don’t know how they’re being allocated today? Before work can be prioritized effectively, leaders must understand how much bandwidth their teams have to take on new projects. Additionally, they need data-backed insights in order to align the priorities of the engineering team with those of the company at large.

Visibility is also key to avoiding work that wasn’t part of the plan. According to the study, teams spent 22% of their time on unplanned work in 2021, a 15% increase year-over-year. This trend indicates that engineering leaders may not realize when certain types of work are taking attention away from mission-critical initiatives. When asked to name their biggest challenge heading into 2022, 45% of leaders (by far the largest group) selected “making sure everyone is focused on the highest priority work.”

To gain visibility into their operations, some engineering teams are doubling down on data aggregation and analysis. According to the report, while all organizations tend to devote similar amounts of time to “keeping the lights on” and customer support activities, those that invest in a more robust data organization are able to spend 29% more time on innovation and 48% less time on unplanned work.

Building Through Data and Metrics

The report also found that engineering leaders who’ve embraced data-driven decision-making are seeing more productive, healthy and focused teams. These organizations tend to release code more quickly and foster higher collaboration than their peers. Conversely, organizations that don’t prioritize data-driven decision-making are more likely to experience burnout, decreased productivity and less focus on innovative work.

Here again, the difference between embracing data and ignoring data comes down to technology. Aggregating data and metrics manually can be tedious and challenging. However, emerging tools are able to automatically collect, measure and analyze data to offer insights on what teams are prioritizing. As a result, leaders can more easily align engineering work with business priorities, ensure more predictable development cycles, increase financial responsibility and continuously improve operations.

For every engineering leader, nailing this approach to data will be essential for maintaining efficiency as teams expand. More than 79% of engineering leaders expect to grow the size of their teams in 2022, and respondents named employee onboarding ramp time, virtual onboarding and hiring among the most significant challenges they face.

Despite the numerous challenges engineering teams have endured in the past two years, the industry has adapted and become more collaborative as remote and hybrid work models multiply. For leaders who seek to increase data-driven decision-making, new tools and approaches will result in more intentional engineering work and improved visibility and operations.

June 10, 2022
Turnover, Documentation and Missing Links

When employee turnover spikes, IT in general and DevOps teams in particular need to be prepared.

At the time of this writing, the stock market is roiling, and DevOps compensation is bouncing up. This has an impact on turnover because many in DevOps (and nearly all senior positions) have compensation that includes stock—stock that may be down significantly or that is currently at high risk of going down. This causes two types of movement—those leaving an organization to avoid further loss in their compensation and those who are leaving their current gig to join an organization whose stock is down. Combined with those who leave for a role with a larger base salary, there are those who are leaving to earn more and those who are leaving to avoid more loss. IT budgets ballooned during the pandemic but those, too, are deflating, so while we have a worker, not a position shortage, there will be pressure from both sides.

So, why is this geek going on about employment, compensation and available positions?

Simple: Because DevOps is not any better at documentation than any other flavor of IT. In tightly-run shops, documentation is available and maintained. In most shops, it is spotty at best. In some, it is downright nonexistent. This has forever been true in IT and, if anything, it is more true because the early stages of DevOps implementation result in a massive amount of change.

People leaving in an environment with less-than-stellar documentation can be a problem. What tools are used? Where are they located? What’s the login for these SaaS tools? Etc., etc., etc. If turnover means you’re losing entire DevOps teams in relatively short order, this can become a nightmare relatively quickly. And that nightmare is very real for everyone left behind and those that are coming in. Someone has to go figure it out; IT management has to let the rest of the business know that retention issues are causing backlogs. Everyone not tasked with figuring it out has to pick up slack for those who are … you get the picture.

Take the hour or four and document what you have. It doesn’t have to be comprehensive, it just has to list what tools, where they are, who at the organization is responsible for credentials at any SaaS vendors and under what circumstances the tools are used. If each team documents their own stuff, even in a shared toolchain environment, comparing the documents will uncover little details one missed that another did not.

Let’s face it, we have—for better or worse—moved largely to a world where loyalty is based on compensation. Much like mercenaries, most IT employees are always listening for a better offer. So the organization, while acknowledging this fact, needs to take steps to minimize the negative impacts of turnover. New ideas and suggestions to change things are all good and you don’t want to interfere with that aspect of turnover. But anything that impedes the organization’s ability to deliver should be addressed beforehand. And that means documentation so remaining and new employees can get up to speed quickly and take ownership rapidly and with confidence.

And keep rocking it. Whether you are looking for a new gig or not, keep the apps you are responsible for running—and document them. You’ve contributed to the success of your organization; don’t slack off while moving along. And don’t hate those that are moving along. Not all of us base our loyalty on compensation, but we do all allow compensation to influence our decisions (unless you are working for free and I missed it?) Keep rocking, no matter your status. And don’t hesitate to tell interviewers that you helped your last organization achieve success.

March 23, 2022
3 Ways to Prevent Developer Burnout

Without developers, software companies wouldn’t exist—and yet, the experience of these experts can be far from ideal. A recent report from Haystack found that nearly 80% of developers report being burned out and the pandemic isn’t even one of the primary factors. Despite similar job requirements, the experience of developers significantly varies across the industry, adding complexity to an already challenging job. Conflicting coding styles, communication styles and requirements from different teams conspire to make the development process inefficient and difficult and leave developers feeling overwhelmed. Between different organizations and even teams within the same organization, the differences in team culture and educational opportunities can lead to radically different job experiences for the same job title. To retain talented developers in the workforce and maximize their potential, the collective developer experience needs to be improved through a developer-first and inclusive culture and better access to professional development for developers at every level.

Build a Strong Culture of Documentation, Communication and Knowledge Sharing

One of the biggest challenges team leaders encounter is how to communicate key information between team members. Many developers are incredibly skilled at their trade but aren’t properly trained or given the time to work on sharing that information with either colleagues or end users. Having skilled technical writers means that the team can provide consistent, clear information about the software—and this is crucial for company success. Having technical writers on the team improves communication and efficiency and enables developers to more quickly and easily locate the resources and support that they need to perform their tasks

The developer’s goal is to innovate and build successful and maintainable systems. Achieving this requires good team processes and a solid system of documentation. Without user-facing documentation, adoption will suffer as users struggle to get things done with the system. Similarly, without documentation of the individual components, knowledge cannot be shared between teams and so the teams working on the application cannot collaborate effectively. A positive culture around documentation and investment in best practices by all contributors, including developers, makes a huge difference in how successful an organization can be.

Welcome Employees with Comprehensive and Constructive Onboarding

Strong communication is especially vital during the onboarding process; it’s one of the most important periods for developers early in their careers. Getting developers up to speed in a new team quickly is crucial—and streamlining education beginning during onboarding can make a big difference. Onboarding is a golden opportunity to bring new developers into the cultural fold and enable them to contribute to the team quickly. Doing so also reduces the risk of losing developers from the team.

Prioritize an Inclusive and Supportive Culture at all Levels

The experience of software developers is greatly influenced by the culture of the company they work for. The values of a company and the way that departments interact make a big impact on developers—and it’s not always a positive one. Opportunities for career development, promotions, mentorship programs and training are critical for all employees, but especially those in fields with the potential for high turnover or burnout like developers. Providing developers with resources to further their own understanding and mastery of the job—such as access to a budget for attending conferences and further study—is a critical investment for their success. Organizations both large and small must take initiative to ensure developers see a path forward for themselves at their current company and within the industry—or risk losing their talented developers entirely.

While developers’ experiences vary across the industry, between departments and even smaller internal teams, there is inherent value in improving communication, investment and culture on a micro and macro scale. To attract and retain highly skilled and innovative developers and ensure success for teams and companies as a whole, executive leadership must work with their developers to find a cohesive system and create an experience that works for everyone. Like any other specialized professional in a complex trade, developers are invaluable to their teams and community; advocating for the improvement of their work experience throughout their careers is the best way for tech companies to keep developers creating software that improves our world.

September 16, 2021
Real-Life BDD: Getting the Best Out of Dev Teams
If we want our software to have value, we need to improve it every day, rather than wait three months for the next release. If someone finds a bug and we know how to fix it, we want to deliver the fix that day. The challenge is deploying to production many times a day.

If the developer is coding right now, we want to see their work in production today. However, when you increase the speed of delivery, you need to be sure that the code you deploy works. To increase speed and quality at the same time, you need a safety net and a lot of automation.

Sometimes we need to change the mindset of developers. This affects interactions between the developers and product management. It also changes the way developers code and how they approach their work.

Break It Down

Behavior-driven development (BDD) helps all of my teams. My mature teams use the three stages of BDD: discovery, formulation and automation. To increase speed and quality in a team that isn’t as mature (not much test automation, a lot of manual testing), one of our challenges is to develop small pieces of code they can deliver.

When we groom an item in the backlog, the product owner (PO) explains what’s needed, but sometimes when the developers start working, they find other stories that may take two weeks each. With BDD discovery, the PO and developers can reach a shared understanding of what’s needed before coding starts. If the story is too large, example mapping helps them split it. They need to obtain stories that will take less than three days.

More Ideas, More Examples, More Agile

To simplify collaboration between the engineering and business units, the product team needs to understand the size of the ask for the developer. You can improve communication by showing all the different cases that exist for this feature and by using example mapping.

Here’s an example of how this works in practice: the product team asks for a feature and explains it in about 10 minutes. The developers say this will take two to three weeks. However, after the developers completed user story mapping and example mapping and began to split the big features into smaller stories with examples, they realized it would take much longer. There were simply too many things the product team hadn’t known about.

The product team had lots of ideas, but ideas take time to implement. Now that they had more examples, they could make better decisions about what was mandatory and what would be great but was not essential. Working in this way allows us to be more agile.

The particular aspect of BDD that helps here is discovery with example mapping. I like to use user story mapping to see different versions of the same feature to understand the value brought by the feature’s different potential iterations.

Whenever Possible, Push Live Code

I’ve transformed the way my team works to help them to release more often. The key is to add a continuous integration server with the first automated test and a staging environment where the code is deployed many times per day. This allows us to automate the process from the code, so when a developer pushes the code, we have the beginning of a safety net. When the safety net says everything is okay, deployment is triggered to a staging production environment. The production can be a staging production, but it’s better when it’s live. When it’s not possible to deploy directly in production, then you should at least deploy in a staging environment.

From the developer’s point of view, when they push the code, there’s an impact on production, even if it’s just within a staging production environment. For the next step, they need to create the first unit test each time they have to add code. In other words, every time you write code, you need to have an automated test at the same time. These tests should be run by the continuous integration server.

Once you have that, the next question is about the size of the code you push. If you wait a few days to push or use another branch, you won’t have the value to see the increment of the code you’ll push.

Developers Should Own Quality

Quality has traditionally been the responsibility of the QA team, but it should be owned by the developers. As a developer, you can’t wait for someone else to read your code and tell you it’s okay and then talk to the QA team to make sure you didn’t introduce a bug. If more unit tests are needed, you should write them and you should be using test-driven development (TDD) and BDD. You also need a lot of feedback. You need to be the owner of quality, and help your team achieve it.

To summarize, here are my top three tips:
- Automate the process of deployment with continuous integration/continuous delivery
- Create examples with all the stakeholders of the project together—product, development and testers
- Create small stories that you can deliver in less than three days
August 12, 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
Best Practices for Building Next-Gen Software Teams

Technology is moving faster than ever before. The pandemic has accelerated digital transformation across every organization in every industry. Creating new remote working environments or developing new digital revenue channels has taken place at lightning speed over the past year.

At this time of rapid change, software development teams are continuing to help organizations adapt to our new environment and stay ahead of changing consumer habits. They also have to deal with their own personal situations and shifting organizational priorities – from new COVID-19 protocols to virtual offices.

As 2021 progresses, what are the elements that can help business leaders stay ahead of the latest innovations and build resilient, forward-looking teams? Here are three tips I believe will help build next-generation software development teams.

Put Your People First

Finding the right people is never an easy task. Hiring for the skills you need to fill a role is important, but it’s also necessary to look beyond those requirements. Having the right technology skills is not always the be-all-end-all when it comes to hiring. Is this candidate a good fit from a cultural standpoint? Will they be engaged and motivated? Are they interested in learning and growing their own skill sets? Do they have different experiences and perspectives than your existing team members? Each team member brings something special to the table, and treating each person as an individual and as an essential part of your larger operation is crucial. Everyone should feel valued and connected to the company. This is especially true during the pandemic. Managing with a sense of empathy, understanding, and caring helps team members feel a sense of belonging and as though their job matters – because it does. When employees feel that their role is undervalued or unnecessary, they can easily become detached and uninterested. Hiring for the person and caring for your people during and after work hours builds better teams and keeps them connected to the business and mission.

Allow Software Teams to Experiment

Staying ahead of the latest trends and technologies is critical for delivering advanced software. Experimenting and allowing your teams to try new things can go a long way to drive innovation. It gives them opportunities to learn new applications and ways to deploy new technologies. Continuous training is a key part of the experimentation process. Our teams, for example, actively participate in more than 20 events per month. We also invite clients to join and participate, adding another layer of value for our clients. These events come in different forms and settings. They are virtual, gamified and often employee-led. The idea is to create space for open-minded discussions, team-building exercises and knowledge sharing. For example, our head of digital security leads regular sessions to educate our people on evolving security threats and effective security strategies to defend against them. Adapting to new ideas and building expertise in new technologies require a “no fear” mindset. Having the freedom to experiment and learn from each other provides the framework to keep teams ahead of the latest digital trends.

Empower Your People

Giving team members a certain degree of autonomy and responsibility for decision-making in their daily work improves innovation and productivity. When you empower employees to make their own decisions and decide their own path to success, you create a better workplace culture. At Cinq, for example, all one thousand of our developers know what projects we are engaged with across the company. Not only are they aware of what’s happening, they know the project goals, objectives and KPIs of every client engagement. Team members can request to be added to certain projects and teams at any given time. They may be interested in the client’s business, want experience with a new application or have an idea or suggestion to help us achieve our goals. We also give them the tools and resources needed to successfully manage or lead their own projects, which can lead to massive innovations inside our own business. Empowered employees are loyal, committed and more productive. When employees are given opportunities to work toward their goals and drive their own careers, the benefits are enormous.

Staying ahead of new technologies and applications can be a challenge for even the most tech-savvy organizations. Recruiting motivated learners, empowering your employees to move across teams, and creating opportunities for experimentation are critical elements to building next-generation software development teams.

May 19, 2021
Cooperative Gaming: Software Teams’ Secret to Success?
Trust falls and team backpacking trips are out — cooperative gaming is in. Don’t think embarking on group Minecraft missions could help deliver great software products? Think again. A 2019 BYU study found a 20% increase in office productivity after just 45 minutes of gaming.

Software engineering is a mentally taxing endeavor, and many developers are under mounting pressure to deliver. To destress, many software teams use gaming to unwind during work hours. Gaming, it turns out, has added benefits of improved morale, increased productivity and lowered ego around unofficial hierarchies within the office. Setting aside time to recharge with collaborative gaming could increase a workplace’s health and help software teams work together to deliver products more efficiently.

I recently spoke with Max de Lavenne, founder and CEO of Buildable, ally to the workplace gamer, to see why he embraces gaming as a regular part of his software developer team’s weekly regimen. Buildable adopted gaming and saw a notable impact; de Lavenne shared how other teams could similarly introduce gaming to improve performance.

Gaming in the Workplace

Traditional business environments don’t typically embrace fun activities on the clock — there is a clear separation between work and life. But at Buildable, gaming is integrated into the weekly routine. The Buildable engineers set aside about 45 minutes mid-week for collaborative gaming, typically on Wednesday or Thursday. The Buildable team, made up of about 20 software engineers, favors Rocket League and a modded version of Minecraft.

According to de Lavenne, gaming is a great way to foster collaboration and intuitive group thinking. “Getting recharged is really important,” he said. He encourages the team to adopt cooperative multiplayer games; no solo play. He also discourages violent and aggressive RPGs, like first-person shooters.

Workplace gaming isn’t unique, in and of itself — many teams at other companies will often play Haxball during coffee breaks or get into a Call of Duty: Warzone match from time to time. Yet, few leaders have the stomach to sanction gaming as integral to the developer’s workflow and overall team dynamic.

“Engineers collaborate best when they respect each other and have confidence in each other’s skillsets,” said de Lavenne. “They are individuals, but there’s a lot of groupthink in teams.”

Benefits of Gaming

Gaming has proven benefits. In fact, researchers at Kansas State University found that employees who spent one or two minutes during breaks in their day playing games such as Candy Crush on their phones reported being happier than their peers. Similarly, de Lavenne noticed improved mood and other positive outcomes from collaborative gaming at Buildable, including:
- Better team morale: Having scheduled gaming breaks to look forward to each week keeps attitudes positive. Software engineering can cause fatigue, which managers need to monitor carefully. “People get tired, and there’s only so much the brain can do,” de Lavenne said .
- More fluid communication: Collaborative gaming focuses a team’s effort on a collective activity free from monetary incentives, bonuses or other hidden agendas. Afterward, de Lavenne said he’s noticed more fluid communication emerge among the team.
- Increased collaboration: There’s satisfaction in doing something together, and de Lavenne reports that gaming has redefined collaboration for his team in unique ways. Employees take the cooperative, creative attitude fostered from gaming experiences and apply it to more structured, scrum-type environments.
- Increased productivity: Dedicating one hour for gaming per week equates to about a 2% loss of labor time. However, de Lavenne reported that the productivity gains afterward surpass that lost time and more.
- Reduction of ego: In work environments, unspoken hierarchies inevitably exist. Interestingly, collaborative gaming can completely reverse those social dynamics. Seeing senior engineers at the bottom of a gaming leaderboard can be humorous and boost confidence for younger engineers.
- Combating isolation: Throughout the pandemic, remote work has left many of us feeling lonely. For young engineers without families, a big chunk of social interaction may occur in the workplace. Games can help maintain good spirits by bringing teams together virtually.
Tips for Encouraging a Healthy Gaming Culture

The overall goal is to promote enjoyable, freeform shared experiences. To enable this, de Lavenne shared a few tips on integrating games into developer team workflows.

First off, gaming should not be mandatory, as making it a required activity would somewhat defeat the purpose. Instead, gaming should be fun and completely voluntary. If people would rather get in some physical exercise or check Instagram, they should feel just as free to do so.

Also, as much fun as gaming with the team could be, it’s helpful having the CEO removed from this activity, de Lavenne advised. This is important so that players don’t feel they’re constantly monitored. Yet, leaders may want to have a say in the type of game, as well as when it’s played.

Furthermore, the game doesn’t need to be an immersive RPG — it could be as simple and accessible as Jackbox. Cooperative board games like Dungeons & Dragons or Gloomhaven could have just the same effect as digital games.

Outside of encouraging collaborative gaming, leaders can take other actions to boost morale and productivity. One such action is leaving chat channels unmonitored, so that team members can engage with each other on whatever subject they want without oversight. Another way to affect morale is location, noted de Lavenne. As I’ve written previously, hiring interest is expanding outside of traditional tech hubs. Buildable, for instance, chose to headquarter in suburban McMinnville, Oregon, for its walkability, greenery and better work-life balance than in larger cities.

Gaming Is Where It All Began

Multiplayer video games, LARPing, and AR/VR environments not only offer an escapist retreat — they represent nostalgia. For many programmers, video games were a doorway to the computer science field in general.

“I’ve rarely met a software engineer that never gamed,” de Lavenne added. Gamers often seek out the highest-performing machines. And chances are, those kids with limited resources built their rigs from scratch. “This inspires you to learn about hardware, and you start to care about speed, compile and software activities,” said de Lavenne.

From Atari to Minecraft, gaming has been a shared passion among generations of programmers. Recognizing this affinity can unite a team. Because at the end of the day, “building good software is all about people,” said de Lavenne.

Of course, software development takes extreme diligence, planning, and structure to deliver bug-free, user-centric products. But under intense pressure to perform and meet new digital innovation demands, software developers could get burned out without a bit of distraction. With gaming, “the team really comes alive,” de Lavenne said.

So, when things get slow, check out what’s hot on Steam. You may, ironically, just find your next productivity breakthrough.
March 23, 2021