Management Signals

I’m catching up on my podcasts and just listened to Seth Godin’s Akimbo episode about honest signals. (Do listen.) It’s about the signals we send that are honest or dishonest and why we might choose one, the other, or both. I started to think about the management signals we send, especially in an Agile transformation.

In From Chaos to Successful Distributed Agile Teams, Mark and I developed this chart to show how Agile approaches change the culture.

Original Link

What Do Agile Leaders Do?

I’ve had this ongoing discussion with a few of my colleagues who say that the term “Agile leader” is an oxymoron — that the ideal organization is a bunch of Scrum Teams and not much else. Even in an ideal world, I disagree, and here’s why in a nutshell: I’ve never seen, and have not even heard of, an organization that was successful in their pursuit of agility who did not have a strong leader guiding the vision for what the organization can become, motivating people to achieve that vision, nurturing the pursuit of that vision, and protecting, when necessary, the people who want that vision from the people who don’t. 

The reason for this is simple and is as old as civilization. As Nicolo Machiavelli observed, 

Original Link

The Effects Of Working With A Lazy Manager

It’s often said that we leave jobs in large part because of the bosses we worked under. There are many things about a bad manager that can prompt our wrath, but perhaps the foremost sin is to be workshy. New research from the University of Exeter highlights just how pernicious working under a lazy manager can be to our well-being and productivity.

The researchers wanted to examine the impact of having a lazy boss on the team working under them, both in terms of their mentality and productivity. The analysis revealed that leaders who regularly procrastinate both in doing tasks and making decisions result in lower commitment levels among employees. More worryingly, it also saw an increase in mendacious behaviors among staff.

Original Link

Solving Impediments as a Team

Solving Impediments as a Team

The main message of the retrospective was clear: there are too many interruptions by stakeholders and the senior management. The interruptions impeded the flow of work through the team. Consequently, achieving the sprint goal had been at risk several times in the past. Moreover, the team missed the sprint goal twice recently. Solving impediments as a team has become a necessity.

Learn more on how to tackle impediments as a team by running experiments and iterating on the solution.

Original Link

Phases of Self-Organized Team

A self-organized team is a utopian state where every Agile Coach or Scrum Masters strives to bring their Agile team. This transformation will not happen in a day or two, but it will require months to years, depending on the organization’s alignment and priority in adopting Agile. It requires constant coaching from the Scrum Masters/Agile Coaches with periodic inspection and adaption into the team. This article is mainly about understanding the changes happening in a team while transforming into a self-organized team. The identification of these phases will enable the Scrum Masters/Agile Coaches to shift their focus areas accordingly.

The transformation happens on a phase-by-phase basis. And below are the identified phases as part of the real-time experience.

Original Link

Women in DevOps: Charity Majors

Charity Majors is the CEO and founder of, a data-driven platform that helps developers debug their applications, software code, and databases. Formerly with Facebook, Parse and Linden Lab, Charity is an outspoken individual looking to encourage leadership skills among diverse groups in the software industry.

What character traits/habits make you successful in DevOps?

Original Link

Women in DevOps: Tanu McCabe

Tanu McCabe’s expertise as a solutions architecture director at Capital One has enabled her to lend invaluable insights about her exciting adventure within the company’s digital journey. Since 2015, Capital One, one of the country’s largest banks, has championed a large-scale tech transformation. During an interview, Tanu reflected on her decision to join Capital One, her hopes for the future direction of the company, and how burnout brought her to a dream job in DevOps.McCabe’s job as a solution architect allows her to provide leadership and guidance that leverages the latest technological developments. As part of her job, Tanu positions the company on the best solution designs, projects, and company-wide initiatives.

How did you decide to come to Capital One?

Original Link

Why Disruption Still Matters and 5 Ways to Deal With It (Part 2)

As I mentioned in my last post, disruption has fallen off many organizations’ radars because it’s “so 2017.” But I don’t believe disruption is behind us. Some industries have yet to be disrupted; others are poised for round two, which will likely be faster and more painful than the last one.

Last week, I covered three of the five ways to stave off disruption. Here are the remaining two for you to consider.

Original Link

Effort vs. Productivity on Software Development

I am sure you have heard that software developers are lazy. They don’t do much most of the time and only actually work a couple of hours over the day.

When you are in an assembly plant, for example, assembling televisions, it’s an issue in that type of work if someone stops doing his task for just a couple of minutes. Those couple of minutes will mean that fewer televisions will be produced and when we convert that to money, it will raise the cost of the product.

Original Link

How Not to Fail an Agile Transformation

It’s all too easy for teams to drop their Agile-related efforts after a little while since their initial training. Don’t we all have a natural tendency to want to go back to how things used to be?

But doing so does, obviously, render all improvement and change efforts useless. What do you do then?

Original Link

Myth: Scrum Master Is an Information Dispenser

I often start my Scrum training classes with this quote:

"The Scrum Master is an enabler not a doer"

Original Link

Leadership Lessons for Creating High-Performing Scrum Teams

This is the last in a series of 3 blogs presenting the result of an interesting research study from Sam Walker.
Walker discovered that the most successful sports teams that ever existed all shared one single element: they all had a team captain with 7 overlapping traits that made them extremely successful. In this blog, we will explore what Agile Leaders can learn from these extremely successful team captains.

6 Lessons to Learn from Elite Team Captains

The Scrum Master role has a lot of overlap with the team captains from Walker’s research.
Another overlap with Walker’s research is the role of the sports coach: the Agile Leader, responsible for the Scrum Teams.

Original Link

DevSecOps and Development: Making the World Safer One Application at a Time

If you have been around software development much at all in the past 5 or 10 years, then you’ve certainly heard of DevOps and know that it is here to stay. And it is very likely that you have also heard the term “DevSecOps” in one form or another. With today’s extensive proliferation of application capabilities being delivered through services – and all the inherent complexity that comes with the delivery systems for them – it’s no wonder that CyberSecurity has moved to the forefront for many companies. In fact, according to research from Stratistics MRC, the current Global Application Security Market is growing at a CAGR of 23.4% and is expected to reach over $10 Billon by 20231

It’s one thing for there to be an interest in Cybersecurity – it’s another thing entirely to implement it well and that is where the conversation gets more interesting. Today, the name of the game in application security is all about bringing the role of the developer into the fold and equipping developers to code, fix and maintain security as part of the software development process. This notion of developer empowerment being a critical aspect to success is gaining momentum. For a great view on it, please see this excellent article from DevOps author and thought leader John Willis. Indeed, this topic was something that I heard again and again at the recent 2018 Black Hat USA Conference, and you can read more about that in this DZone article. But how do you effectively bring developers into the security fold? That is what we will explore in this two-part series.

Original Link

The 8 Qualities of the Emotional Scrum Master

The Scrum Master profession spans a wide variety of skills, knowledge, and experience. Scrum Masters try to create high performing teams and drive organizational change. Although our primary focus and responsibility is the process, it’s people we work with all the time. Surprisingly, our profession focuses predominantly on developing cognitive intelligence (IQ). We need to learn to appreciate the value of emotional intelligence (EQ) in becoming great Scrum Masters.

What Is Emotional Intelligence?

The term emotional intelligence was first created by researchers Peter Salavoy and John Mayer, and popularized by author Daniel Goleman. Emotional intelligence has been defined as, "the ability to recognize, understand, and manage our own emotions, and recognize, understand, and influence the emotions of others."

Original Link

Seven Traits of Elite Team Captains

In my previous blog, I presented the result of an interesting research study from Sam Walker.
Walker discovered that the most successful sports teams that ever existed all shared one single element: they all had a team captain that was the main driver behind this success.

In this blog, we will explore the character traits that separates great team captains (the 16 team "Tier 1" captains from Walker’s study) from the good team captains (106 captains that finished second place).

Original Link

What Makes a Leader vs. a Follower?

The circumstances and personality traits that inspire someone to take on leadership responsibilities are a frequent source of interest among researchers. The latest effort, described in a recent paper from the University of Zurich, suggests that the key is our propensity for responsibility aversion. In other words, our willingness to make decisions that also affect others.

Participants in the study were given the choice of either making a decision themselves or passing it off to the group to make. The researchers made sure to distinguish between decisions that only impacted the individual themselves, and those where there were clear consequences for the entire group. As participants made their ruminations, their brains were being monitored using functional magnetic resonance imaging (fMRI).

Original Link

The Servant Leader and the Illusion of Corporate Empowerment

Last week, I answered a reader question about what Scrum masters are worth, financially speaking. This gave rise to another reader question that I’ll tackle this week, and it has to do with the idea of the so-called servant leader.

Now, I usually follow sort of a FIFO approach for reader questions. But I’m making an exception here because several people asked me the same question in the immediate aftermath of that post.

Original Link

Enablement Over Facilitation: 5 Essentials to Be a Great Scrum Master

“We don’t often get the respect we deserve”, “Folks think our role is not a critical part of delivery”, “It’s a thankless job” – we hear this quite often from our Scrum Masters. While the road to becoming a Scrum Master is short, becoming inclusive isn’t as smooth as one thinks. Gaining respect as a Scrum Master requires a lot of dedication, persistence, and introspection. A valuable Scrum Master always goes beyond doing the “cliched” administrative work and adds value by enabling the team.

Based on our experience, we have listed down 5 essential skills that can help gain inclusiveness and respect as a Scrum Master.

Original Link

First Build Your Foundations for Agile

How many people build a concept house without any foundation, to make sure the real home would be a success? I would venture to say very few. What happens when a builder constructs a house without establishing a proper foundation? Will it crumble on the first day? No, but it will not stand the test of time.  

Many companies approach an Agile Implementation the same way. They are so excited to get something small started with a pilot that they forget the lay the foundation to support the transformation over the long haul. Are pilots in themselves dangerous? Absolutely not. Pilots without the proper foundation to help them are the issue. The context of this article is about what the necessary foundation is that needs to be laid to support most change initiatives like Agile.

Original Link

Time Management: 4 Tips for Remote Teams

Over the past decade, the way we work has changed significantly. With the rise of worldwide internet coverage and increased internet speeds, many employers choose to build remote teams and employ workers who are not geographically tied to the company’s headquarters.

The freelance workforce has seen a significant growth over the past years, and in the U.S. alone, there were 57.3 million people working as freelancers in 2017. The number of full-time remote workers is also on the rise, with managers expecting that 38% of their full-time staff will be working remotely in the next decade.

Original Link

Scaling Business Agility: Three Essential Pillars for Being Vs. Doing Agile

The concepts of Agile, Scaling Agile, and Business Agility have become buzzwords. The crux of being Agile for the customer and people who are building products and services is buried under a focus on conducting ceremonies.

Prior to scaling Agile, let us not forget the manifesto for Agile software development. It’s all about uncovering better ways of developing software that provides value both to the customer and for people who are part of the delivery stream.

Original Link

Bill Gates Revealed His Biggest Weakness (and an Important Truth About Leadership)

You have to hand it to Bill and Melinda Gates. As billionaires, sitting down for an hour-long, unfiltered Q&A session with an auditorium full of debt-burdened college students took some guts.

But sit down they did, and answered even the toughest questions with honesty and authenticity.

Original Link

Agile Leadership Is a Continuous Journey

A company’s leaders must prepare for the selection, achievement, and continuous improvements of Agile delivery. Only the leadership can evolve and continuously grow the environments in which their people function. Moreover, only these mentors can design the atmosphere that promotes high-performing Agile teams to thrive and deliver excellence. Agile leaders, therefore, must show smarter ways of working so that their people will discover from their personal and professional standards, mentorship and intrinsic motivation. The quest to become an Agilest does not need to be hard. Many leaders have to attempt a new method of management. The process will need to prepare, enable, and challenge their people to attain the highest potential through Agile teachings and practices.

What is not so apparent to leaders is that their people’s knowledge of the processes alone won’t be enough. Agile leaders must take an actual role to guide the new way of working. How many times have I heard from leadership that, "You have my support and contact me if you have any questions"? That way of thinking is a recipe for disaster with Agile. Agile leaders need to involve themselves directly on a daily basis. Get out and walk around, attend daily stand-ups, pop in on Sprint Planning sessions and come to the Sprint Reviews. You want your people to see you are involved with and care about the success of the implementation.

Original Link

Announcing Accelerate: State of DevOps 2018: Strategies for a New Economy

2018 marks the fifth year of our research program investigating software delivery performance, how to measure it, what impacts it, and why it matters. You’d think in our fifth year we’d be struggling to find new ground to cover – but this year’s report is the most comprehensive yet, and I’m truly excited by our results. With over 1,800 responses from companies of all types and sizes, we’ve extended our model of software delivery performance to include availability; studied how cloud infrastructure and its implementation impacts performance; examined how leadership and learning affect culture and delivery performance; expanded our investigation of technical practices to include observability, continuous testing, and database practices — and those are just a few of the highlights! You can read the full report here.

Let’s start with performance. As in previous years, we’ve captured measures of both delivery speed and stability and found that teams aren’t trading off one against the other. Instead, we find a high performing group that leads the pack in terms of both speed and stability, a low performing group which delivers much more slowly and has significantly lower stability, and a medium group that is in between on all measures. That result continues to hold true this year – and indeed, our high performing group is larger than in previous years, showing the industry continues to evolve. As with previous years, we find that high performance is possible for all kinds of organizations of all sizes. This year, we extended our model of performance to include availability and found that high performers were over 3.5 times more likely to achieve good availability outcomes too. We call this combined measure of throughput, stability, and availability software delivery and operational performance (SDO performance).

Original Link

Q-and-A With CloudBees CEO Sacha Labourey on the Upcoming DevOps World | Jenkins World (Part 1)

I recently had the opportunity to send a few questions over to Sacha Labourey, CEO of CloudBees, ahead of the upcoming DeOps World | Jenkins World conferences to learn a little bit more about what’s been going on with Cloudbees and what we can expect to see at the show.

Hope you enjoy the interview!

Original Link

Success Means Putting People and Process Above Tech [Video]

"I don’t care about the tech — what I really want to hear is how this product fits in our processes and helps our people get more done."

That was the message my co-founder and I heard from an executive at a major bank last week. For us, it was both a deja vu and a major relief because we’d just presented at the Cablelabs Summer Showcase about the importance of aligning people, process, and technology together. The executive was pleased about how RackN had achieved that balance.

Original Link

It’s Time for Leadership to Own DevOps

DevOps has become more than a trend—it’s a survival imperative for the enterprise. In today’s digital economy, software innovation drives business innovation.  The faster developers can deliver on the next wave of software innovation, the faster the business can deliver customer value, bring new revenue streams online, and respond to market events. DevOps practices across the enterprise can deliver business results at the speed and quality customers expect.  

Many IT organizations start their DevOps journey implementing automation and tools only to quickly face hurdles when trying to scale DevOps practices across the organization.  Their journey starts to take a detour as they struggle with organizational boundaries, unwieldy system-wide processes, and cultural resistance to change. It’s common to blame the people and teams that are not getting on board, but to quote Edward Deming, “People work in the system, management creates the system.”

Original Link

Focus: The Leadership Superpower

My wife is an event organizer, and in her early conferences, juggling a load of must-do items and decisions was a key pain-point as she kept many critical plates spinning. The stress of keeping all of it in her head at the same time filled up the cognitive capacity she had available to actually work on any of it.

We’ve all had people at work who’s answer to "When will that thing be done?" is always countered with "I’m working on it…" And, it never seems to be done. The most helpful people in taking on work are the least helpful in completing it.

Original Link

Continuous Discussions (#c9d9) Podcast, Episode 90: Gene Kim and DOES’18 Speakers [Video]

This morning on our Continuous Discussions (#c9d9) podcast, we had a great discussion with a panel of DevOps Enterprise Summit Las Vegas 2018 speakers and programming committee members to discuss a major theme top of mind for many at the fifth annual USA conference.

This year, "Next Generation Ops and Infrastructure Practices" gets moved under a larger magnifying glass. Targeted specifically at Ops leadership, and the beginning stages of a greater focus on a multi-year roadmap to properly define the problem space, we continued the discussion from DOES18 London here with some of the top minds in DevOps.

Original Link

Are Managers Really as Horrible as We Think They Are?

If you’re like me, every article you’ve ever read about managers vs. leaders bagged on managers while praising leaders. Not surprising, right? People hate being "managed" and nearly everyone fancies themselves as being (or becoming) a leader. 

There may come a time when managers are obsolete, but for now, these are both valuable roles – they’re just different.

Original Link

How To Change Your Organizational Culture

You will learn How to Change Your Organizational Culture. Yes. How to Change Your Culture. It requires effort and focus. And it is possible. I have done it and leaders around the globe have applied this same information to change their culture. What follows below is an outline of the proven steps. I have also included pointers to supporting resources.

1. Desire for Growth

The starting place for culture change is desire — a powerful urge to create change. Nothing less than this will result in success, so that is the starting place. Anyone interested in shifting culture needs to look inside to see what is driving them and make sure they have the motivation to do the work needed.

I used to subscribe to Kotter’s “Sense of Urgency” and even advocated this. I no longer do. It turns out that urgency is linked to fear and a lower level of psychological safety. This inhibits personal and organizational growth. For this key reason, “Desire” is a better choice.

Strong Desire for Growth is Essential

Organizations that have sustained organizational growth over decades see improving as part of everyday work. They invest in growth because it is important. Not because of urgency, but because it’s the right thing to do.

2. Understand the Existing Culture

The next step is to understand your existing culture. But what is Culture? We can define it as what is commonly known as,”How we do things around here.” I have experimented with a lot of culture models and recommend the two that are proven in terms of simplicity and power. You can use them together to diagnose and your culture and orient for growth.

The Sahota Culture Model provides a clear understanding of culture through identification of the interconnected elements that shape culture. It also highlights the need to focus not just on Structures, but also on the Consciousness (or Mindset) of a system. We often fall into the trap of focusing on structures (especially process) rather than focus on the people and how they are working together. This mode reminds us that it’s really about the consciousness (or mindset), the people, not about the structures or process.

The other model that is very powerful is a modified version of the Laloux Culture Model. It may be used to assess where the organization is right now. It also has the tendency to help spark a desire for shifting to a higher performance way of working such as Green or Teal. One key reason to use this model is that it has heaps of case studies and research to support the claims of high performance. It also lines up with many other models and theories of culture and behavior such as McGregor’s Theory X — Theory Y.

3. Create a Star on the Horizon

The next step is to look at case studies and examples of the kind of company that you want to become. There are lots of great resources such as the book, Reinventing Organizations, or “Diverse Paths to High-Performance Organizational Culture.”

It is a good idea to use these for inspiration. The goal is to create a “star on the horizon” that is aligned with the desire for change. Don’t try and copy structures. Copying simply gives you the structures without the shift in culture.

The secret here is to find your own path. Selecting a path is primarily a function of two things: 1. The existing situation in your organization. We can only grow and evolve from the place we are at. 2. The shared desire of people to create a new future. The desire could just be top leadership or they may co-create this with people throughout the organization.

4. Culture Grows Locally

A common misconception is that culture change is for the whole organization. It is important to understand that in most organizations culture varies by team, department, and location. It is as unique as each individual manager. So keep in mind this key point:

Since it is a local phenomenon, it means that it is possible to make changes locally within your part of the organization. The most common way for culture to grow is Culture Bubbles. Of course, when we do this, there will be culture gaps that create tension and challenges.

The key idea for reducing the tension is to Build Culture Adapters. There will be different ways of working and different values inside the bubble and outside the bubble. The adapter idea is to reduce conflict with the rest of the organization by building adapters between the ways of working. It’s a key pattern for creating sustainable culture bubbles.

5. Leaders Go First

Culture is primarily a reflection of Leadership. What happens at the bottom of the organization is a fractal of what happens at the top of the organization (thanks to Glenda Eoyang for this wisdom). It is well-known that the performance of a team is a direct reflection of their manager — this was proven through validated real-world research almost 20 years ago through the Gallup 12 “Engagement” Questions.

The way to change culture is for leaders to change how they interact with people and the organizational system. A key concept here is that Organizational Behavior Follows Leadership Behaviour. A new kind of organizational behavior way of working requires that leaders behave in a new way of working. So successful transformation requires that Leaders Go First!

6. Leadership Growth is Required

A key lesson in my career is that the Leader is the Limit for Growth. I notice that to create high-performance organizational systems, leaders needed to develop themselves as human beings. They needed to grow into the kind of leaders we see in high-performance environments. This means inner work to cultivate trust, safety, and connection. As leaders, we need to get our egos under control so we can develop leaders around us.

This is not for the faint of heart. We are talking about developing ourselves not just as leaders but as human beings. Like you, I am on this journey, too. I created the 4A’s Conscious Leadership Model to capture the step-by-step approach I have been using to grow myself. It’s a powerful tool to help rewire our unconscious behaviors that are preventing us from showing up as the leaders we desire to be. We are so deeply conditioned by society to have behaviors that are contradictory to high-performance. Dedicated focus and effort is required to shift our habits and unconscious behaviors.

A learning organization is a place where everyone grows.

Remember the desire for organizational growth in step 1? This is where you need it. Personal growth requires a strong drive to keep up the effort.

This is the secret of changing the culture: all we need to do is change our behavior and culture will follow.

It’s a Journey

The above steps are sufficient and necessary for culture change in an organization. What is shared here are the key starting elements for culture change. Of course, there are a lot more details on how to do the steps outlined here and even more on supporting the journey.

You Can Do This Regardless of Your Role

Executives, managers, and coaches that I have trained have successfully applied what I am sharing here. We are all leaders. We may be a leader because people report to us or we have more seniority or expertise. And we can also be a leader because of how we choose to show up.

You Can Implement This Immediately

Regardless of your role, you can chose to show up NOW the way a leader of the future organization would. You have full control over your behavior.

You Don’t Need Permission, Budget or Authority

You don’t need permission, budget or authority to start acting in ways that model high-performance behavior. All of us can shift our local culture immediately. The only limit here is your desire and your investment in developing yourself.

It’s a big shift for us as leaders. Sure, we still need to support the development of people around us so that we have leaders at all levels. But this is secondary to growing ourselves to fully model the kind of organizational leader needed for the future organizational culture/organization we wish to create.


So here are the six key steps to change your culture:

  1. Desire for Growth
  2. Understand Existing Culture
  3. Create a Star on the Horizon
  4. Grow Culture Locally
  5. Leaders Go First
  6. Leadership Growth is Required

And here are the important tips to keep in mind:

  • It’s a journey
  • You can do this regardless of your role
  • You can implement this immediately
  • You do not need permission, budget or authority

Original Link

6 Pointers to Get Comfortable in an Uncomfortable Environment

Wow, I just can’t believe it’s been already one year since I took up the new role. It has been a fantastic roller coaster ride and as I retrospect how the year went by, I’ve jotted down some critical elements.

#1: Unlearn and Learn

This is the hardest part. We all have been superstars in our previous roles and it’s always easy to repeat what we have done in the past. Well, it just doesn’t work that way. We are entering a different ecosystem and culture altogether and it’s critical to see them and feel them even before we jump start and ultimately imbibe them.

Believe me, no one likes to hear “In my previous team, we used to this…”. There may be several best practices from our previous organizations, but it is important to learn the objectives, expectations, strengths and improvement areas in our new role.

Eventually, we may end up applying what we did before, but going back to basics by listening-in, spending time to get to know the people, domain, and technology is the first step to win trust and confidence of the team. I can visualize eyebrows raising when I just said about technology. Yes, it’s important not just to know but also to learn the technology we are in irrespective of the role we play.   

#2: 30-60-90-Day Plan

It’s important to have a plan, review with the leadership team and continuously measure to see if we are on the right track. But in today’s workplace, most of the roles demand our contribution from Day 1. While we can focus on our 30-60-90 plan, we need to align and be agile on current changing priorities.

“Right now, right here” is the winning attitude expected from each one of us. Delayed action is missed opportunity!

#3: Be Surrounded by Critics

None of us like criticism, but if we want to be aggressive about our establishment in the new environment, we need to take constant feedback from critics. While the traditional ‘What went well, what can be improved’ type of retrospection helps, the best inputs come from the critics let it be constructive or destructive.

Ignore the negativity, understand the intent and analyze if it is aligned to the objective and helps you in moving forward in the right direction. The intention here is not to satisfy everyone, but ensure we are doing the right thing for the culture & organization.

#4: Show & Lead the Path, but Journey Is Not Just Ours

As leaders, it’s important that we not only show the path, but also lead and walk the talk. But we also need to realize that we are together in the journey with people of diverse expertise, mindsets, and passions.

We can give our best, but unless everyone understands the purpose, gives their best and feels the same way we do, we won’t be able to achieve the desired outcomes as a team. It’s okay ; don’t sweat it. The question we need to ask ourselves is, “Did we create the environment and provide the required guidance and support for our team, and leave the rest to the team so they can succeed?” After all, the individuals own their careers.

#5: The Sky is the Limit

Every role comes with clearly articulated responsibilities. While we need to ensure we are not stepping on others’ toes, we shouldn’t be limiting ourselves to our official job description.

The only way to raise the bar (how can I miss this favorite statement of every leader?) is performing beyond limits and striving towards organizational objectives. Learning, sharing the knowledge, ideation and innovation are some levers to scale us up.

#6: Be Ourselves

We discussed learning and adopting into the new environment, but at the same time, we shouldn’t be compromising our own identity. Our passion, aptitude and attitude got us where we are today and they will take us further by honing them with additional expertise and thought leadership.

To get comfortable in an uncomfortable environment is not as complicated as it sounds as long as we are willing to listen, react and most importantly be an active part of the environment.

Original Link

From Gut Feeling to Informed Decision: Journey of HR Analytics

“Your number one customers are your people. Look after employees first and then customers last.” – Ian Hutchinson, author of People Glue

Rewind to a couple of decades ago. Collecting data to help design and restructure policies to keep employees happy was an uphill task. But, now with technology enabling easy data collection, the task is even tougher to analyze mountains of data and draw actionable insights.

Human Resource analytics is rapidly evolving and opening new opportunities in areas of employee engagement, boosting productivity, recruitment, closer collaboration with other departments, etc.

The operational definition, “Systematic identification and quantification of the people drivers of business outcomes” articulates the power of HR Analytics.

While happy employees turn out to be the backbone of happy customers, “building projects around motivated individuals and giving them the environment and support they need, and trusting them to get the job done should be the mantra.”

While it is agreed that regular pulse conversations, rewards, and recognitions, along with challenging opportunities, play a critical role in employee engagement, it is equally important to understand the intrinsic motivation of employees. Prevention is better than a cure, hence it is vital to forecast attrition and proactively mitigate the risks through various measures.

While HR analytics addresses quite a lot of challenges associated with people, it primarily tackles the below top two questions every organization is interested in:

  • The attrition trend in my organization in next fiscal year
  • Likelihood of key performers leaving my organization

While qualitative assessment is important, the below listed data-driven approach enhances the prediction and helps the organic growth of an organization.


Before we proceed further with our forecasting and prediction, it is important to understand the business problem, data source and critical factors that influence the employee attrition. The article ‘Forecasting the Future: Let’s Rewind to the Basics’ covers the basic aspects to be considered.

Root cause Analysis

Cause-and-effect diagrams always come handy to identify all potential problems for any challenge. It gives a visual representation of all data to be collected for further analysis & analytics:

Fishbone Diagram

Data Collection & Data Engineering

Human Resource departments typically gather a lot of information such as demographics, skill sets, performance, learning, growth, and pay. Based on the cause and above diagram, the data must be aggregated and grouped to be able to do correlation (relationship among various variables) and covariance (variance of random variables).


At times the simple plots and trends are good enough to convey important key takeaways. Hence it is important to represent the data visually prior to applying different models.


Time series helps in addressing the first problem, finding the attrition trend in an organization in next fiscal year. Given an observed sequence based on historical data, time series analysis helps in building a model that can predict what comes next. Though our use case here is on attrition for most of the scenarios where we want to forecast based on historical data, time series analytics comes handy. To learn more about Time Series and implementing it in R, check out one of my favorite little book series.

Time series analysis decomposes the historical attrition data into various components: observed (given data set), trends (long-term progression of the series), cyclical (repeated fluctuations), seasonal (seasonal fluctuations), and random (irregular). Less randomness in time series helps in better forecasting accuracy.


Various models such as Holt-Winters, Auto-Regressive Integrated Moving Average (ARIMA), automated forecasting using exponential model, or Auto ARIMA with simple moving average can be applied and the optimal one can be chosen through minimal forecasting errors (Root Mean Square Error, Mean Absolute Error, Mean Percentage Error, Mean Absolute Scaled Error, to name a few).

The model which we have chosen based on minimal forecasting errors can be applied to predict next data points. In the below example, the data points 1 to 110 are from historical and data points 111 to 118 are predicted outcomes for next 8 periods.



 To solve the next challenge “likelihood of key performers leaving the organization”, we can leverage both explicable models (linear/logistic regression, decision tree, etc.,) or non-explicable models (random forest, neural networks, etc.,). While we may get better accuracy leveraging non-explicable models, the explicable models are suggested to be able to communicate the outcome better.

Like what we did in time series analysis, we need to choose appropriate error metrics before applying the model for better prediction. In our problem, probably the higher sensitivity (when it’s attrition, how often does it predict attrition?) is more important than lower false positive rate (when it’s not an attrition, how often does it predict attrition?).

More than regression, a classifier such as decision tree will be more powerful in building better representation as this will also help in actionable mitigations (better growth opportunities, work environment and rewards and recognition).

In summary, Human Resource analytics, especially attrition forecasting and prediction, helps HRD by providing actionable insights towards strategic decisions and optimizing the business outcomes.

“The time is now for organizations to take the utilization of data to the next level.” – Ayman Sayed, President and CPO, CA Technologies

Original Link

In the Spirit of Business Agility Transformation

“We want to be Agile to fulfill the rapidly changing requirements from customers through self-empowered and motivated employees” as opposed to, “We want our team to do Agile since everyone is doing it” is the true spirit of business agility transformation.

The journey begins with leadership

 While agility sounds like a bottom-up philosophy where individuals in the team are self-disciplined and self-empowered in achieving the common objectives, the journey starts with leadership through trust and leading by example. Leadership needs to understand the dynamics of the team and provide guidance since one size doesn’t fit all. Being transparent about the mission and vision is important to gain the shared commitment.

Optimization at all level

It’s a myth that agility is just for product development and support organization. Every individual in the ecosystem plays a vital role in transformation as we can’t expedite the delivery by optimizing silos. Visualizing and eliminating the waste in the value stream that translates an idea to implementation inclusive of process and people are essence for transformation.


Both qualitative and quantitative measurements are important to understanding the health of business agility. While the organization can choose metrics that work for them, it is vital to measure throughput and cycle time of business outcomes.

Kaizen(Continuous improvement) and Kaikaku (Radical change)

Measure, refine and repeat — continuous and relentless improvements are important aspects to get better on our journey. The entire value stream requires retrospection in a reasonable timeframe to be able to adjust and move forward.

During the journey of transformation, there are a couple of myths to be considered:

Agile is not ad-hoc

In fact, there is a lot of planning and course correction when we adopt Agile but they are incremental and of short intervals. Since wait time is one of the key wastes, everything requires planning but not in detail just to ensure “roughly right.”

One size doesn’t fit all

In the name of Agile, we shouldn’t force fit the methodologies to a team. While Agile is all about incremental and iterative development, every methodology has its own merits and demerits based on the nature of work. For example, Kanban may work better than Scrum in an environment where scope of work changes daily.

Agile requires more discipline than we think

If a team feels there are too many meetings and ceremonies, it’s time to check the fundamentals. Every ceremony requires the purpose, pre-requisites and expected outcome clearly articulated to the participants. Time-boxing plays a critical role in Agile. Agile empowers everyone with a collaborative approach and taking consensus through working agreements, at the same time it expects every team member to adhere to what they committed to. Being proactive in raising the impediments, limiting the unfinished work through teamwork and self-organized are some foundation blocks for agility.

Beyond traditional leadership

The role of leadership becomes more of an enabler in unblocking impediments as well as bringing alignment within and across teams. The leader becomes frontrunner in transformation journey and guides team through continuous learning and mentorship. The leaders in Agile transformation don’t just show the way, they also travel along with the team, remove the hurdles, and enable teams to be successful.


To summarize, before the team embarks on an Agile transformation the leaders need to ensure the vision is communicated effectively for better collaboration and continuous support is provided through relentless improvement. We can be Agile without even following the ceremonies; what matters is how we convert the concept to cash for the customers in minimal predictable cycle time. 

How can we know whether we are successful with Agile transformation? Measuring the flow of business outcomes through cumulative flow diagram (CFD) is the answer, and to read more about CFD, please check this out.

Original Link

Diversity: How Individual Differences Produce Creativity

Image title

A large majority of today’s budding entrepreneurs are setting aside cultural and political differences in the hopes of creating a more diverse team within the workforce. The reason behind this trend? The premise that organizations with a wide variety of members are far more creative than those of teams coming from a similar background.

With a multitude of literature backing up this ideology and the constant encouragement by the public to break down walls, it’s not surprising that a lot of companies are looking to diversify their workplace.

Still, the question remains, just how much can diversity affect the creativity of one team? How does one strengthen them through leadership and inclusion?

The Different Influences

For us to evaluate just how effective it is in enhancing inventiveness, it’s important to know how it influences idea generation and implementation. Viewed as two different scenarios, the diversity of a team dictates just how successful they will be in generating ideas and implementing ideas.

Recent experimental studies have suggested that though heterogeneous team composition seen as an advantage in producing a wider range of original ideas, its benefits ultimately weaken when it’s time to decide which among them will be implemented. A meta-analysis conducted on 108 studies and more than 10,100 teams reports that the enhanced creativity produced by teams with higher diversity is interrupted by deep-rooted social conflict and decision-making dilemmas that are rarely found in homogenous groups.

Though it follows the creative process of free thinking, openness to failure and mind wandering, it should be immediately followed by convergent thinking and effective project management for it to become actual innovations. It takes more than just diversity to implement a company’s wide array of creative ideas.

Strong Leadership

Admittedly, diverse teams are prone to conflicts, and these arguments can only be mitigated if they are lead effectively. It’s not rocket science that strong leadership is a fundamental resource for organizations across industries.

When members set aside their own agendas to corroborate with others for the common benefit of the project, the natural tension between wanting to get ahead of prospect competition and needing to get along with everyone is articulated.

It’s important for homogenous teams to learn how to empathize with their coworkers and to see things from other perspectives. Only when they have learned to manage their own conscious and unconscious biases will they be able to agree on one thing.

Inclusivity and Knowledge Sharing Culture

“Diversity is being invited to the party. Inclusion is being asked to dance” diversity advocate, Verña Myers said. In order for leaders and organizations to truly stick with practicing diversity, it’s important that everyone feels they are included, that their voices matter.

Hence, creating an open knowledge sharing culture is present within the team to truly enhance creativity. Everyone should be encouraged to speak up and leaders need to create an environment wherein it’s safe to share novel ideas. Implementing feedback and sharing credit for team success also aids in promoting inclusivity.

Diversity: A Place for Everyone

Though skeptics would say that diversity may bring more problems and complications than creativity, the rising movement of coworking spaces is proof that diversity and inclusivity could create great results for everyone participating.

Well-known for its diverse community, these shared offices are attracting startups, entrepreneurs, and even large corporations across several industries for the authentic networking it provides to its members. With a culture that promotes inclusivity and interdisciplinary collaborations, coworking allows professionals to experience what its like to work when the walls separating us from one another is diminished.

Creativity isn’t the only thing that businesses can unlock when they create diverse representation and inclusivity in their workforce. Though complicated and intricate, the process is worth it when it leads the team to sustainable growth.

Produce equal opportunities for every member of your team and talk to us today about coworking spaces!

Original Link

4 Ways to Future-Proof Your IT Leadership

The traditional institution of Information Technology is no longer what it used to be. As a leader of innovation in your company, you are most likely aware that the IT landscape is changing. IT is now driving all aspects of business, from building applications to assisting organizational change. IT has been seen as the source of innovation within organizations but with increasing demands for, and new possibilities within, IT, the domain can be seen in a new light. New tools and organizational shifts in business are enabling the means to create solutions, drive business and innovate efficiently and more effectively. No-code application development platforms and the rise of Now is the time to address the long, growing backlogs and IT project failures your organization has been facing so you can move on to your next feat, disrupting competition. The best way to manage your IT function is to stay aware, adapt and move quickly. Citizen developers are transforming the function of IT. The IT domain will be transformed by citizen development as application development will be possible for anyone by 2030.

As your IT team is encountering more challenges and an even longer backlog, they need a few elements of support and your leadership. The CIO of 2030 is expected to organize, structure, lead and align IT with business goals by implementing new talent and technology.

Here are some tips to ensure your IT department is prepared for the future.

Implement a Citizen Development Strategy

Whether your current IT department is aware of it or not, they need citizen developers. The overload of demand on IT is creating a need for more, and more creative, problem-solvers. You may encounter an initial reluctance among your traditional developers, but citizen developers are intended to support IT and ultimately, the business. It is important to get IT on board from the start, to prevent shadow IT and set up a citizen development strategy that involves IT governance.

So who exactly are citizen developers? Citizen developers are platform-users who build applications to facilitate the processes of business operations while following the development guidelines of IT. They want to focus on testing their ideas and developing effective solutions for business.

Provide the Means to Experiment

To consistently innovate and find creative solutions, it is necessary to experiment. But, experiments are inherently an obstacle for organizations due to the risk and fear of failing. The means to experiment not only includes the tools to test and iterate ideas but also the environment for employees to think more creatively.

Citizen developers use tools that enable them to build solutions quickly with ease and efficiency. No-code platforms enable citizen developers to experiment with ideas without risk, and iterate the prototype until a solution is found. With the incremental experimentation process, citizen developers can learn as they build, to make quick changes, rather than learning after an entire project is completed.

Lead, from the Sideline

Yes, you are in charge of innovation and therefore, your team needs your leadership! It can seem like a paradox to be a leader of creative individuals, who work best without restrictive oversight, thrive in an environment that enables open thinking and often works autonomously. Yet, there is a fine balance in IT leadership between governance and fostering creativity to develop solutions and innovate. This involves leading from the sidelines and encouraging the new change-seekers to build solutions on their own but within the needs and structure of the organization. While citizen developers work autonomously, the effectiveness of their work is determined by the influence of their work environment and particularly, the CIO. It is important to enable your team to work independently as the basis so employees have greater autonomy, creativity, and self-management.

As for your IT leadership, by staying ahead of digital trends and incorporating new technology yourself, you can inspire the citizen developers in your organization with your knowledge and expertise about the industry and the steps needed to achieve business goals. If citizen developers are eager to adopt new technology that facilitates their work processes, then provide them with the platform that empowers them to work both autonomously and collaboratively.

Balance Pipeline and People

Communication is undoubtedly an inherent aspect of the workplace but finding the right communication with your citizen developers and IT is an investment that can greatly benefit the team. Fortunately with a no-code application development platform, like Betty Blocks, translating ideas between colleagues is easy and the usual complicating technical jargon can be left out of the conversation. Still, having clear communication about project goals and customer demands is one of the most important aspects of collaboration.

Innovation is a collaborative effort and it requires your whole organization to be on board. Businesses seek technical solutions to produce operational and customer-related improvements, or simply to drive innovation. While IT is actively creating the digital solutions, this domain needs to better accommodate business. It’s important to remember that technology is simply a means to an end. The means to serve the people, who are working in your organization and your customers.

Overall, these changes can help you achieve long-term success. When the market changes or your customers’ preferences further differentiate, you and your innovation team can readily adapt. With Betty Blocks, innovative solutions are built faster while also innovating the organization from within, better preparing you for future changes. To learn more about innovation strategies, sign up for our newsletter below and receive the content directly in your inbox.

Original Link

Want to Know How to Kill Your Team’s Productivity?

“Work gives you meaning and purpose and life is empty without it.”

It was obvious for the late Stephen Hawking and many great achievers in the past, but is it still true for most of us? There must be something in our daily work routines that makes us feel better about ourselves. And it must be a bit more than the trivial fleshpots of Egypt, a self-pleasing ratio of our output to our input, that brings much desired satisfaction and success, and is commonly known as “productivity.” Individual and shared, productivity is essential for all entrepreneurial endeavors, for all businesses big or small.

So what does it take to be productive as a team? Are there ways to control it? In the end of the day it all boils down to good management.

Without a doubt, nothing is given so freely as advice. So for those who enjoy slaying boredom and hate killing time here are some tips on how to kill your employees’ productivity (instead of effectively killing proverbial birds with stones):

Distracting factors help

Open space offices and noise pollution are things we’ve long been living with happily. Free communication and lack of hierarchy are well-achieved when everyone is in the same room, sitting at the desks next to each other. They all can talk about their anxieties and problems and collaborate very loudly, leaving no chance for focused work. Endless phone calls, bursts of sudden laughter, and constant door slams provide brilliant background noise turning your office space into the least comfortable workplace in the world. Who said that your colleague’s messenger signals are annoying?!

Run tons of useless meetings

Meetings are great if you have things to say, or they may be even greater if you don’t. You want to pass around minor plan updates, catch up on certain projects and give instructions to some of the team leads? Bring everyone in the office together and talk about things irrelevant for most, jumping from one topic to another and constantly interrupting everyone. Your employees will soon develop a great distaste for meetings that take a good portion of their work day, suck out their energy and leave less time for actual tasks.

Let chaos reign

Clear workflow — what a joke! Chaos has never harmed anyone; it is order that suppresses talent and creativity. Lack of streamlined work process helps your team do more in less time, given they choose things randomly, guided by their intuition and good spirit. Precise task descriptions are redundant, as they limit employees’ ability to think and express themselves freely. How on earth will they start thinking out of the box if you tell them exactly what they are supposed to do?! Productivity also drops dramatically if the team knows where the project is heading. Lower-level employees don’t need to see the big picture — it kills the thrill before the unknown.

Stop planning time

Time management is old news these days. First of all, it is boring. Besides it does nothing for output growth. Who cares about deadlines and timesheets in rapidly changing environment we find ourselves in? We have to respond to challenges that pop up out of nowhere and make us forget about time estimates once and for all. Don’t even bother getting time-tracking software, tell your team what to do in real-time mode. Forget about delusional time planning that turns exciting tasks into tedious day-to-day routines.

More micromanagement

It is not a secret that micromanagement demonstrates good leadership. Be with your employees, guide them, teach them and lead them, make them fear and respect you. It will, without doubt, benefit their engagement and productivity, will build trust and ambition to succeed. Fear is truly the most powerful motivator known to man; it’s helped great rulers build empires, and it will definitely aid your leadership and will boost performance of your team.

Never praise top performers

Some of your team are more productive than the others? Demotivate them. Control them at every little step, they need their manager’s support more than anyone else — failure awaits at every corner. Never talk to them about their work process, trying to understand how they’ve managed to get ahead of their colleagues. It is unhealthy to differ from the rest of the team. Stop noticing their achievements at once, there is nothing to acknowledge — just give them more tasks!

Say no to “one-on-one” meetings

There is nothing embarrassing in criticizing an employee in public. They all are part of one team and there is nothing to hide. Transparency is the key, not just to democracy, but to healthy working environment in the office. Why would we have open-plan spaces otherwise? Don’t hesitate to tell team members off at their workplace, it is educational for the others and besides you invest your time well. All those talks in private are in the past, peers should learn from each other’s mistakes. No room for awkwardness and hurt feelings.

Sustain the gap

Never try to make friends with your employees. Keep them at arm’s length, at all costs. Make them feel miserable; they need it to work harder. Don’t analyze why some of them are leaving — you cannot tell what goes on in other people’s hearts and minds. Productivity only stems from strong management, detached from personal ties.


As we all know – it is the little things that matter most. Overall productivity levels are fully dependent on such little things. And it is in the hands of good leaders to enable their employees to show best results and more importantly to help them find purpose in life through work. So, don’t kill time, make the right decisions and as Winston Churchill recommended: “If you are going through hell, keep going…”

Original Link

DevOps Starts With Leadership and Culture

DevOps is truly successful when it is more about building a culture of collaboration and continual automation and improvement than it is about expertise in specific toolsets.  No doubt, the tools are important, but DevOps leaders leave a lot of value on the table if the culture does not fit.  It’s up to the DevOps group leaders to build that culture.

One of the first major activities for DevOps leaders is to get buy-in from all the stakeholders and to make DevOps as minimally disruptive as possible.  First, they start showing the value of what DevOps brings to the organization. Then they start looking at the staff levels, and the qualifications of folks involved.  They bring a point of view that good DevOps resources may have strong infrastructure and development skills, but also have to have strong troubleshooting and problem-solving skills. They want people who want to use data as one of the key elements to success so that it’s not just about getting applications to work but to make sure the process gets improved and automated so that the applications work better and require less management.

Designing the Organizational Model

Successful DevOps is not just having DevOps engineers come in and use automation to provision infrastructure. It’s connecting the DevOps activities to what the development engineers and operations folks are doing, and building bridges across all functions and groups. Leadership will break down silos, and in breaking down barriers between those specialties, a powerful organizational structure will emerge.

Leaders will need to recruit and empower architects, managers, and engineers and decide when to expand the team, and how to make changes to what people are doing and maybe broaden or narrow their roles.

They will also have to come up with a timetable and process to mature the tools, standardize on tools, and build automation, orchestration, CICD, and containerization workflows.

Building and Measuring the Process

It helps to be an agile organization to fully embrace what DevOps can bring to an organization’s culture.

Having the right technology, whether it’s where the resources are hosted, or the right toolchain is key achieving DevOps promises. In addition, the teams need to measure what they are doing in order to improve reliability and throughput. For example, leaders often want to have the right metrics in place to be able to show how many builds got revved last week and out of those builds, how many got successfully deployed to production. Even more importantly, they will want business metrics as well. 

For example, they will want to know how a deployment yielded an increase in a number of orders, depending on the feature. Or how it helped cut back on the number of operational elements that cause unreliable systems to fail. Leadership should look at all the different data points, whether it’s systems, development metrics, business metrics, and aggregate them and put them in the KPI. It’s not just about uptime, downtime, what is CPU or storage costs this week or this month. It’s all about whether the application as effective as it could be as measured in business terms.

Picking the Right Tech and Tools

Leadership needs to make sure the tools and engineers are supporting what they’re trying to do.  They need to encourage the engineers not to go off and do their own thing, but bring any required feedback back to the release engineering function, have them buy and build tools, and collaborate, in order for the organization to have the resources available to satisfy the challenges it is running into. Once the DevOps group has created a toolset and deployed and gotten the adoption they want to the DevOps process, a leader makes sure that an engineer married to the program, and they own it for the entire lifecycle of that product.

DevOps engineers with the right skill sets are not inexpensive. For example, leaders want to give the site reliability engineers and the operation folks all the dashboards they need. They want to articulate an understanding of what’s important and what’s noise so that they can effectively bring reliability to the product.  DevOps as a culture ties software engineering functions nicely together because it allows the organization to scale better using the self-service tools.  The individual functions can come together and provide a more holistic solution.

Recruiting and Managing People

When building their organizations, successful DevOps leaders often start by picking people who are more collaborative in mindset along with having the engineering skills to use collaboration tools.

DevOps engineers are no longer just an infrastructure engineer that wants to do development or a developer that wants to do infrastructure. Effective leaders are building teams where many effective DevOps people come from a data background with software engineering.

Many leaders believe that the most effective DevOps engineers have an understanding of not just infrastructure, networking and security, and data, but their knowledgebase includes middleware and applications.

Breaking Barriers, Building Bridges

With DevOps, good leaders know how to break down barriers, and bridge engineering with operations. That’s because the organization wants the DevOps engineer, or the program itself, to have ownership, not just of the features they’re releasing, but how it performs in production.  That makes ownership and accountability a key attribute.

The leader needs to not only communicate with the team but instill that sense of ownership.  If something is constantly going down, it’s their responsibility to make their jobs easier, and make engineering’s job easier, and address those problems.  This way the feedback loop from product back into the engineering becomes very valuable. It’s important, and that’s what the leaders should be looking at and setting up for foundationally.

Original Link

Is Your IT Team in a Downward Spiral?

What Is a “Downward Spiral?”

A downward spiral is an ongoing deteriorating state of work which results in poor software and service quality, unfavorable customer results, and other consequent deplorable outcomes that lead to poor overall IT performance. The cause of this phenomenon is a “constant core conflict” of competing goals between IT operations and development. In this context, the development department of the organization is working on goals and incentives that are contradictory to those of IT operations. This lack of alignment and synergy only compounds to wedge a gap between the two teams and the subsequent downward spiral can seem unrelenting.

Why Should Your IT Team Be Worried?

Today, every business relies on software and IT to move forward, whether this is in the form of growing a profitable business or reaching consumers in new ways. IT is the modern day business enabler. It is entrusted with a significant responsibility to deliver processes and procedures that can help an organization to achieve its goals.

Within a downward spiral, not only is productivity affected, but the work environment and culture can become very negative too. Team members may feel like they are constantly battling a system that only seems to dictate failure and they have no power to effect changes. This powerlessness triggers demotivation, despair, fatigue, and cynicism. This ongoing state is detrimental to daily work in that it engenders a culture of fear of being punished and loss of livelihood.

If your team is in conflict and battling a downward spiral, there is a much greater impact on the overall business too. Your organization is effectively shackled by this restraint from achieving its business goals in a timely and cost-effective manner. This can jeopardize organizational promises like feature availability to customers, customers’ data security, and reliable financial reporting, as well as affect many other components of day-to-day software integral to the business.

Is Your IT Team in a Downward Spiral?

Here are the indicators that your team and you are in a downward spiral.

  • Your team is unable to make remarkable progress. This occurs when your team’s focus is on individual perspectives and goals which are misaligned with organizational operations. The team is out of sync with top management’s goals specifications and regional expectations. Your team is also out of sync with each other in terms of project and team goals too.
  • There are persistent disagreements between IT and the business in terms of deadlines and budgets. Your organization’s finance executive delays team and equipment budget in favor of unachievable IT projects or new initiatives. Such projects create high value for customers but incur vast amounts of pressure on the IT team to deliver. Consistently deferred infrastructure and equipment upgrades can also be demoralizing for teams to deal with.
  • When finance executives resist spending on those projects that they perceive not to connect to their immediate business needs such actions can result in system infrastructure falling out of date, common databases becoming almost obsolete, and the system getting complex. Other impacts include longer delivery time on projects, increasingly higher costs, and more significant risks involved. On top of all this, trust between IT and the business becomes challenged.
  • Sudden and unplanned business requisitions for services, equipment or software. This habit is caused by the rising of ‘urgent new market needs.’ Failure to integrate IT operations and development goals with the organization can cause misalignment with changing market needs. The organization learns about the change in the market when it’s too late and quickly exerts pressure on IT section to effect change.
  • The rise of the blame game among the staff. Organizations may assign blame to the IT team for poor performance as they are seen to be the ones failing to provide IT services. In the face of this opposition, the IT people tend to look at the other members of their team and organization as their ‘enemies’ who are not appreciating or supporting them.
  • Small budgets allocation to IT sector. Technology has been reported to account for two-thirds of productivity growth in an organization. Nevertheless, an organization may see IT sector lightly and allocate a small budget. Failure to offer adequate financial support to IT sector not only causes further poor business performance but also demoralizes the IT staff.
  • It takes a lot of time to complete operations. IT employees are feeling long hours during workdays and also on weekends too. This situation leads to reduced quality of life that extends even to employees families. Mostly when this occurs, you find that an organization begins to lose its best employees and overall staff turnover is uncommonly high.

Get Out of Your Downward Spiral

Here are 7 positive and actionable ways that will help your IT team get out of its downward spiral.

1. Admit Awareness

When an aspect of downward spiral shows out, it’s good to accept that you are in one. Acknowledgment is the first step to overcoming the problem.

2. Set Clear and Realistic Team Goals That Align With Top Management Strategies

An organization can only be successful when all key ingredients work in cohesion. Knowing the organization’s overall direction and goals is crucial for your IT team to achieve business synchronicity. Formulate project and departmental that fit into the organization’s mission and regional goals.

3. Establish a Well-Defined and Well-Communicated Organization Structure

A clear organizational structure is the backbone for development in any business. It outlines reporting lines within an organization. If communication is kept a top priority, the IT team will learn about an organization’s development goals quickly and effectively. The team will be able to formulate policies and processes geared towards overall business productivity. Achieving such productivity will also positively boost the IT team’s attitude.

4. Deploy “Fast Feedback Loops” at Every Process Stage

These feedbacks can are possible through building quick automated tests for every change that is committed. These tests are then run to verify that the changes and the environment work as designed and are in a secure and usable state.

5. Implement DevOps and the Theory of Constraints

DevOps is a cultural and technical methodology that aims to unify software development and operations. Adopting DevOps will enable you to achieve better performance within various functional technological roles and simultaneously improve overall performance. In addition to DevOps, you can seek to identify any constraints that are causing bottlenecks in your process and preventing you from achieving business goals. (Check out our article on Addressing the Theory of Constraints here.)

6. Employ a New Transformational Leadership Style

This leadership style comprises inspirational communication and vision, personal recognition, and supportive leadership. This leadership style inspires your team to work with a DevOps mindset.

Encourage IT team members to become co-owners of the process, it’s a fruitful method of succeeding in business. You allow co-ownership by “asking how to” rather than “showing how to.” Support your team to help them share their insights, skills, and expertise, this can be very rewarding to the organization as a whole. (Check out our article on 5 Steps to Transformational Leadership here.)

7. Take a Step Back to Gain a New Perspective

Take a step back and review the situation from the outside. Attempt to view your processes in an unbiased manner and see where the problems lie. This perspective will enable you to obtain an objectivity about your position that you are struggling to achieve and it can also help you begin to control any negative emotions that are no doubt surrounding the problem you are all involved in.

In conclusion, battle your downward spiral to overcome the harmful impact of affected organization performance and deterioration. The above measures can help recover your team and get your IT department back on the path to ensuring high business performance and team spirit.

Original Link

How To Build A Collaborative Environment With These Easy Tips

Whether if you run a small family business or a large enterprise, to make sure you’re getting the most of your business, build a collaborative spirit among your employees.

According to a study that examined more than 1,100 businesses, the companies that nurtured collaborative environment were up to 5 times more likely to have an extraordinary performance. That being said, it’s obvious how essential it is to switch from an individual to a collaborative mindset, even if you’re business is already highly successful.

This article shares some surprisingly efficient yet easily implemented tips that can help you out in building a team-oriented environment. So, read on and learn how to create collaborative work conditions at the workspace.

#1. Inspire Your Employees

If your team members are not certain about your goals and visions, they may lose motivation and passion for their jobs which can easily affect their efficiency. Accordingly, when trying to achieve the perfect collaborative environment, it’s particularly important to make your employees understand your business purpose.

The more you’re capable of identifying your staff with your brand mission and compelling them with your business story, the more they’ll be motivated to work towards the realization of that idea.

#2. Define Expected Results and Goals

The most important thing you should do as a business leader is to make sure your employees know what your expectations and goals are. Not only should you clearly communicate the business vision but also collective responsibilities and individual assignments.

When your staff knows precisely what they should do to benefit from the final outcome, only then will they be able to invest the most of their capacity. In addition, when everybody’s individual role is well-defined, you’ll decrease the chances of conflicts based on misunderstandings. At the same time, you’ll increase the efficiency of each team member, as they’ll know what part of the final result they are responsible for. Finally, they’ll be more direct to one another and more constructive when combining the results of tasks they’ve worked on into a bigger picture.

#3. Get the Most of Each Team Member

First of all, it’s important to realize that getting the most of your employees doesn’t mean draining their energy until it’s fully exploited. On the contrary, it means that you should only give them responsibilities that best suit their strengths.

One of the most popular ways of determining strengths and weaknesses of team members is letting them take a personality test. That way, you’ll get to know what kind of activities and environment they enjoy the most. Consequently, you’ll be able to assign them the tasks that they are more likely to perform providing extraordinary results.

According to statistics presented a while ago, the most used test for this purpose is the Myers-Briggs Type Indicator (MBTI)– about 80% of Fortune 500 companies rely on it.

#4 Let the Team Members Speak Up

When establishing a collaborative environment, it’s important to put to use the creative energy of each team member. And this means that you should build the setting that will motivate them to speak up, brainstorm, and offer an alternative solution, rather than making them feel shy and insecure.

If you let your employees actively participate in the process of decision-making and give them the freedom of speaking their own mind, they’ll feel like an important part of your organization. To make them feel included and give them the understanding that their opinion matters, it’s essential to break down the barriers between managers and employees.

#5 Don’t Forget About Team Building

As we’ve already mentioned, to create a stimulative and supportive setting that will lead to increased collaboration, you should work on creating a stronger bond between leaders and staff. And there’s no more outgiving way of doing so than organizing frequent and meaningful team buildings.

The co-worker socialization outside the office is a great way of opening communication channels and creating a less formal vibe among the employees. Team buildings are especially productive in terms of nurturing collaborative spirit if they are based on games, quizzes, and challenges in nature.

#6 Facilitate Their Communication

Efficient communication is one of the most important elements of the truly collaborative environment. To keep all the employees on the same page, you should find a good way to let them interact.

While the frequent meetings may be a good way of dealing with daily issues, the introduction of marketing project management software can also be a great help. Not only does it simplify communication when it comes to daily tasks but it also lets the employees keep the track of the entire project progress.

Making the employees interact easily and collaborate on project edits, project management software for marketing additionally increases their efficiency and they provide even better results while at the same time cultivating team cohesion.

Pave Your Way To Collaborative And Purposeful Environment

The creation of a collaborative environment is not a process that lasts a couple of days. It may require a lot of time and effort to make the employees learn from their inefficiencies and become sincerely open to sharing a team spirit.

However, there are several ways in which you can speed up this process and start seeing improvements in the way your team members communicate sooner than you expect. So, if you’re willing to work on improving the collaboration in your team, you should:

  • Share your vision and expectations with your employees making them create a stronger bond with your brand and their tasks and positions;
  • Pay attention to your employees’ qualities and find the ways to get the most of their talents while minimizing their weaknesses;
  • Treat the team members as important stakeholders that can offer new approaches and fresh ideas to your business;
  • Give your staff opportunities to connect with each other by letting them interact outside the office, organizing team buildings, trips, etc.;
  • Provide your teams with the adequate marketing project management software that will facilitate their interaction and let them keep focused on their tasks.

Finally, nurturing collaborative environment may be the best weapon to win the competition. Healthy, stable work setting where co-workers don’t feel threatened but motivated to contribute to business goals can significantly impact your business results, eliminating weak spots and improving interpersonal relations.

Original Link

Top 5 Takeaways From the 2018 Developer Survey [Video]

While the merits of cross-functional workflows are becoming more accepted in the software development space, it still has quite a way to go. In fact, GitLab’s survey of 5,000 software professionals found that only 23 percent of respondents are working with a DevOps workflow.

This is one of five top takeaways from the annual report on software development trends and the impact continuous integration and automation have on the way IT teams work.

What’s in the Webcast?

The discussion kicks off with the differing outlooks managers and developers have on DevOps adoption and the source of bottlenecks in the development process. We move on to highlight the distinctions between high- and low-performing teams and the role open source tools have in software development. The discussion then delves into the way continuous integration helps teams get working code out of the door faster.

Watch the Recording

Top Takeaways

Managers are more optimistic about their DevOps adoption progress than developers.

“Companies tend to look at DevOps as the next transformational methodology that’s going to solve all software delivery problems, and of course there’s a lot of truth in that when done really well. What we’re finding is when you actually go and survey these organizations, managers and the management layer seem to have a more optimistic view of how they are progressing and what they can do with it. And though developers find the promise in it, they tend to agree less with the optimism of management. From our perspective, that makes a lot of sense because developers are in the trenches tooling, retooling, trying to configure, making that CD pipeline work, always kind of running into different roadblocks and trying to solve that all the time. So, although they’re excited, I think their viewpoint is not necessarily as rosy about it when compared to management.”

Developers say most delays in the development process are in the testing phase, while managers say the majority of bottlenecks are attributed to the planning process.

“Everybody acknowledges that there are bottlenecks and delays in this development pipeline. When doing DevOps, you still get stuck. But where they actually encounter these delays and bottlenecks varied from team to team. The majority of this was in testing, the next one was planning. Development, operations, and practitioner teams actually found most of the bottlenecks and delays in their actual phases of work, whether this was testing the plan to production, etcetera. Management was found to be more frustrated and concerned about the planning phase of getting things kick-started.” – Ashish Kuthiala

“Fifty-two percent of people say that testing is where they encounter the most delays. I don’t think that’s a number to be taken lightly. This is why continuous testing, automated testing is such a big piece of the DevOps software development lifecycle. If that’s the single biggest cause for delay and we can automate more of that testing, the time it takes has got to come down.” – Alan Shimel

Open source tools play an integral role in the software development process.

“We’re finding that open source tools are becoming a very critical component that developers choose to help solve their problems. People are starting to look at tools that they can integrate with their stack and modify or contribute to; and they want to be recognized as well. So they’re starting to turn to tools that are malleable, tools that they can use and understand what’s underneath the hood. There’s a good community around open source because as developers face problems, they can ask their peers for help and also help others.” – Ashish Kuthiala

Teams that self-identify as high performing do DevOps well.

“Teams that move fast work on smaller pieces of code and get them out of production quickly, i.e. they do DevOps well and they assess themselves as higher performing teams … For these teams that do well, we found that removing roadblocks in the development process starts with continuous integration. If you are doing continuous integration well and automating that portion of the lifecycle along with others, it makes a huge impact in removing bottlenecks. You have to ship and get the code or the configuration change production ready right away. The more you wait, the more it piles it up and the harder it becomes.” – Ashish Kuthiala

Original Link

An Alternative to the Annual Review

Well, it’s that time again — time for the yearly performance evaluation. The ritual starts with gathering feedback, proceeds to assigning rating/ranking, and drags on through doling out a raise.

Do you enjoy annual performance reviews? Thought not.

This year I think we should all skip it.


Here’s why:

For most teams, each person’s achievement is all intertwined with the other members of the team. Trying to pull out individual performance on project goals is futile. Emphasizing or rating individual performance undermines collaboration.

Individual skills are only part of the performance equation. The quality of management and the environment for success are major factors in individual performance. But most rating and ranking schemes ignore those factors.

Ranking people with different skills sets against each other makes no sense. Yeah, I know lots of companies do it, but the fact that lots of companies do it does not make it a good idea.

Rating on the bell curve is ranking in a different dress. The bell curve isn’t particularly useful in a small population — like the size of a typical workgroup.

Rating and ranking engender competition, not collaboration.

Most people believe they are above average performers. Disabusing them of this notion does not improve morale, nor does it spur people on to greater efforts. Quite the opposite.

And if everyone is doing their job reasonably well (and if managers are doing their jobs, they are, or they’ve moved on…) does it help to tell them they’re at the bottom of the heap? I think not.

Performance reviews aim for objectivity, but in almost all cases, they are, in fact, subjective.

Year-end is a lousy time to tell people how they’re doing. It’s too late — why waste weeks (or months) of inadequate performance? The best time to let people know how they are doing is in the present, as close to the event as feasible.

Here’s what to do instead:

Have a conversation with each person in your group about how the year has gone. Discuss questions like these:

  • What were the major events of the year?
  • What have been the major accomplishments?
  • What new skills have you acquired?
  • What have been your struggles?
  • What contributed to those situations?
  • What insights do you have, looking back on the year?
  • What are you most proud of?
  • How does this inform us going into next year?
  • What do you want to do better?
  • Are there new areas you want to explore?
  • What skills or capabilties will you develop?
  • How can we build developing those capabilities into daily work?
  • How will we tell you’re making progress?

Do not discuss a letter or number rating or ranking. Just talk.

Have a separate conversation about salary increases.

Find out what the salary ranges are for the people in your group. Most companies determine salary rates based on the market. They look at how much people in various jobs are paid within their industry and region, then determine where within the range they will aim to pay — say within 20% of the midpoint salary. Then they have a progression, usually with smaller percent raises as the person reaches the top of the range. From this perspective, salary increases are intended to keep salaries pegged to the market and provide reasonable progression as people become more skilled in their jobs. Use what ever pool you have to keep people aligned within the market rates; don’t try to use the pool for “pay for performance.” The aim is to pay people fairly, not to entice people with monetary rewards (which doesn’t usually work anyway).

Start the new year by meeting regularly (weekly or at very least, every other week) with each person on the team. Talk about the person and the work. Coach and provide feedback. Talk about the goals you set in your year-end conversation.

This article was originally published in 2004.

Original Link

The Death of an Agile Transformation in Four Acts

Friends, I shared this article on LinkedIn earlier this month on transformation failures, and it made me think of a story close to me. This is a tale of a digital traveler: a lean man who had fire in his agile soul, a fire that was nearly drowned out after getting caught in the rush of an unexpected waterfall. This is the story of that dream shattering, his redemption, and a cautionary tale for all the other heroes out there on their own digital transformation quests. Pour yourself your beverage of choice, and settle into your favorite easy chair next to a crackling fire, because I’m about to tell you a tragic story: The Death of an Agile Transformation in Four Acts.

Act One: The Quest to Scale

Our story starts in a large, Midwestern American town, with a bright-eyed young agilist working for a fairly big enterprise company. As the transformation lead, he had a few Scrum teams, a supportive CIO, and a dream. Our hero—we’ll call him Wayne (all names have been changed to protect the innocent)—successfully implemented agile at the team level with the support of an open-minded program manager. Over the course of a year, Wayne cultivated his tiny transformation office and coached several Scrum teams into a steady and regular delivery cadence. The digital transformation was starting; it was taking root like a blackberry vine into a rocky hillside, and starting to bear fruit.

While Wayne was pleased with the initial success, he knew that the time to scale was at hand and it would not be an easy sell to the rest of the organization. This was a 50+ year-old company, and even the CIO himself had a rough time going up against the staunch waterfall, command-and-control mindset that settled into its foundation. Wayne had his work cut out for him. He cracked his knuckles, rolled up his sleeves, and got to work. Tackling the transformation of a traditional PMO would be no easy feat.

Act Two: The Leader Falls, and the Villain Rises

About 2 weeks into his scaled agile implementation planning, Wayne got the email from Mr. CIO announcing his departure—and replacement. Almost at the same moment, a meeting invitation popped into his inbox for a “New CIO Meet and Greet.” Wayne nervously prepared some questions for the new CIO, because with his primary supporter gone, this could mean grave danger for his transformation office.

It was a stormy Thursday when the new CIO brought the Development organization together. “I’m a traditional gal,” the CIO began, “And I like to run my organization in a traditional way. I don’t see the point in burdening teams with decision making when I hire managers who can handle all that. I’m all about making sure we have a plan, and perform exactly to the letter of that plan!” Behind him, Wayne heard a cheer rise up from the old guard, who’d scoffed at his ideas about agility scaling in the enterprise. Head hanging low, he shared a defeated glance with the program manager, and didn’t bother with his questions. His transformation was toast, and he knew it.

Act Three: The Beginning of the End

Several months later, Wayne sat at his desk with his head in his hands just after getting chewed out by Ms. New CIO. “This scaled agile thing is ridiculous. You keep promising me transparency, more predictable delivery, happier customers, more performant teams. It’s exactly the opposite out there. It’s chaos, and that’s on you and this “scaled agile transformation” you keep harping on. I’m having a hard time funding this little science project of yours.” Reflecting on the last two months, he realized all his efforts to engage the hardcore, unmoving waterfallers by introducing bimodality went completely south. His arguments to the CIO fell on deaf ears. Her mind was made up, and Wayne knew it. The company culture was too stuck in this mindset and his transformation was going to get canned.

Act Four: Death of a Transformation

It was a foggy Friday about a week later when the guano hit the fan. “Effective immediately,” the email began, “The Company ‘Transformation Office’ no longer exists. All projects assigned to this office will be spread across the PMO. Any ‘Release Trains’ or projects within the Transformation Office will be shut down. All resources will be re-organized under this office. We appreciate your cooperation.”

Wayne’s agile program manager copied him on her resignation. Several lonely months later, this was followed by a number of key developers and QA engineers who couldn’t work in the slow-paced, out of sync environment. Pretty soon, Wayne’s role was eliminated and he was invited to apply for the position of Project Manager in the PMO. He declined, and as he packed up his desk, he reflected on the positive change that he had been able to make with his transformation success early on. There had to be somewhere he could make the same–or better–difference.

Several months later, I met up with Wayne. I’m happy to tell you all that with his level of dedication and passion for agility in transformation, he landed himself a dream job at a Fortune 1000 company. Right now, he’s implementing scaled agile in an experimental, highly dynamic group, and is happier than a horse with a barrel of apples. His former employer hasn’t done quite so well–profits are falling quarter after quarter, and they are being crushed by their competition.

As with every honest tale, there’s a moral to this story: leaders, listen to the Waynes out there. Digital transformation is no longer optional in any industry, and scaling agile in your enterprise organization is the best path forward. Embrace the change–it could mean the difference between leading your industry, or being left in the dusty paths of the past.

Original Link

Women in DevOps: Laura Frank

In our Women in DevOps blog series, you’ll hear from talented women in DevOps. They will share their experiences in DevOps, their thoughts on leadership, lessons learned and also how we can encourage more women to focus on an IT career. This post is about Laura Frank.

As the Director of Engineering at CloudBees and a Docker Captain, Laura has a deep knowledge of developer tools. She has worked on Codeship, a SaaS CI/CD platform designed to streamline testing and deployment of code, since 2015. Before Codeship, she co-maintained several open source projects to support Docker in the early stages of the project, including Panamax and ImageLayers, and came to work on developer tools and open source by way of OpenStack and HP’s public cloud offering. She is a member of the Moby Project’s Technical Steering Committee and frequent international speaker. She currently lives in Vienna.

Hi Laura! What traits are important for being successful in DevOps?

Perspective and persistence, regardless of whether you’re enabling DevOps practices for your own company, or writing tools for other engineers to use (or both!).

Working in the DevOps world is really rewarding as an engineer, since you have the opportunity to find solutions to problems that you and your team also face when writing your own software. It’s a bit easy to get sucked into the 1s and 0s and kind of lose sight of the problem that you’re solving, because the tech can be so interesting. It’s important to keep a good perspective and be aware of problems other than your own. What are the needs of the teams that might use your tool, or how will this process impact the team you’re consulting with? Are you solving their problem in the best way, or just a novel way? How can other people benefit from your work? Building a feature for a product is rewarding because the consumer of that product will be delighted by it, but I’d argue that enabling DevOps practices in teams is equally as profound and delightful. You have the power to modify people’s days, their work, and ultimately how quickly they can be rewarded by their own successes.

Persistence is important because there’s no single day you’re going to wake up and think “Aw yeah, I am doing all the DevOps and there is no more work to do!” DevOps is a mindset and a methodology, not just one tool. It’s a horizon that you’re always aiming for, but you’ll never get there. That sounds a bit grim, but it’s the truth. The world changes around you, and DevOps practices are continuously evolving. “Continuous Improvement” as a practice is just as important as continuous integration and continuous delivery. By all means, set milestones and make sure your goals are measurable. But don’t expect to ever be “done.”

If you could have given your younger self some advice for the future, what would you tell her?

“Don’t worry, this Docker thing is going to turn out just fine!” In all seriousness though, I’m a very calculated risk taker, and Docker was a big bet. As I mentioned before, I think one of the challenges of working in a fast-evolving world like DevOps is that there always seems to be a new tool or new solution. It’s hard to know what to pay attention to. A lot of times we confuse new tools with new problems, when in fact that problem is well-solved in other ways. Docker was really different though; it was powerful and revolutionized the way teams build and ship software in a profoundly different way than previous solutions.

One other piece of advice I’d offer is that working on new things – tools or practices that are still in the “genesis” or “innovate” phase – is really hard. These things exist in a problem space that doesn’t have a great solution, and expect that you’re going to be running your brain at 110% a lot of the time. Many things you’ll do are going to result in a dead end. When I worked on a R&D team at CenturyLink Labs, we were creating developer tools for Docker long before it was anything other than an image builder and container runtime. We were guinea pigs in a lot of ways, really pushing the boundaries or expected use cases for a lot of features. It was really rewarding to document our investigation via tooling or blog posts to help other developers and teams benefit from the work we were doing.

What set you on the DevOps career path?

I’ve been working on developer tools since early 2012, when I joined HP Cloud, back when there was a public cloud offering based on OpenStack. The idea of DevOps certainly existed then, but it didn’t have as much traction, and the principles certainly weren’t very visible at a large enterprise like HP. However, our team was able to function very autonomously, and we saw the value in adopting DevOps best practices from the start. We were committed to automated testing and CI, and we gradually automated our release process and got into a more frequent cadence for releasing software (once or twice per week vs. once a month). That team from HP went on to do some pretty cool stuff once we parted from the team; Matt Butcher went to Deis and eventually worked on tools like Helm and Brigade, and another handful of engineering (plus me!) moved over to an R&D team at CenturyLink Labs to work on this new whale tool called Docker, which was new and novel and no one quite understood what it could be used for. We joined up with some engineers coming from Pivotal, and worked on developer tools like Panamax and ImageLayers to make it easier to work with Docker. Since then, I’ve been firmly planted in the Docker world, getting very involved in the project and eventually being one of the first people to be appointed a Docker Captain. Though my work at Codeship, I’m often thinking about the ways that technologies like containerization and orchestration can help teams be more productive, and develop and ship their software more frequently, and with more confidence. Now that we’ve joined up with CloudBees, it’s interesting to get a glimpse into some of the DevOps problems that larger, more traditional companies are facing, and help come up with a strategy to help them on their DevOps journey.

What do you look for in a great company/boss/mentor?

I like working with people who are direct, accountable, and focus on getting things right – not being right. But those attitudes also have to be visible at all tiers of the company, from the CEO to individual contributors.

What are some lessons you have learned on your DevOps career journey?

Don’t get caught by the shininess or novelty of a new tool. Think critically about the problem it’s solving, and whether or not it’s truly a problem for you. Better yet, avoid picking a solution before you thoroughly evaluate your problem. I call that “solutioneering” and it can get you into some unfavorable situations with a lot of tech debt and even more bloat in your processes.

Original Link

Women in DevOps: Helen Beal

In our Women in DevOps blog series, you’ll hear from talented women in DevOps. They will share their experiences in DevOps, their thoughts on leadership, lessons learned and also how we can encourage more women to focus on an IT career. This post highlights Helen Beal from Ranger4.Hi Helen! Tell us a little bit about yourself.

I’m Helen and I help people practice DevOps principles in real-world organizations for Ranger4. I describe myself as a DevOpsologist as my main role in my working life is to study the inputs and outputs of the thinking systems that make up DevOps. I am also a product owner and member of the Board of Regents at the DevOps Institute and am a DevOps editor for InfoQ. Outside of DevOps, I am an ecologist and novelist. I once saw a flamingo lay an egg and I have a particular fondness for llamas.

What skills are needed to become a DevOps Leader?

I’m going to answer this question in two parts and first address the characteristics and personality traits needed then move onto the skills and behaviors (and new behaviors can be learned). Firstly, then, the characteristics and personality traits of DevOps leaders: empathy, energy, enthusiasm and passion in the face of obstacles (I love Jon Smart of Barclays’ phrase: “Obstacles are not in the path; they are the path.”), tenacity and the will to overcome those challenges and a problem solving mindset.

In terms of skills and behaviors, the 2017 State of DevOps Report showed the contribution of transformational (as opposed to coercive or transactional) leadership skills to overall organizational performance. Transformational leadership combines vision, inspirational communication, intellectual stimulation, supportiveness and personal recognition (never underestimate how far a simple thank you reaches). A DevOps leader needs to act as a servant leader and a coach. Being an effective coach means having a toolkit of frameworks and techniques that help people to get the right work done right and figure out how to solve problems themselves. A leader must also see him/herself as a learner and make time to find and practice new techniques to help others improve.

Most organizations find the cultural part of DevOps evolution the most challenging, since DevOps begins in the technology parts of an organization where we are not usually practiced in having these ‘softer’ conversations – so DevOps leaders also need to have genuine concern for the wellbeing of the people they serve and the willingness to talk about emotions, feelings, values and behaviors.

What does career success mean to you?

I’m particularly interested in neuroscience and neuroleadership – more research becomes available seemingly daily to help inform us scientifically about the behaviors we experience and observe in our working environments. Having data to provide evidence to support theories and being able to understand how different parts of the brain and chemicals operate is extremely helpful in understanding who we are and why we do what we do. And how we can do it better.

I mention this because one of the works in this field is Your Brain at Work, in which the author, David Rock, posits his theorem that each of us has a primary motivator. He says there are five and describes them in his SCARF acronym: Status, Certainty, Autonomy, Relatedness, and Fairness. I’m an ‘autonomy’. So a primary way in which I frame my success in my career is around how much of the work I do I choose to do. I also highly value mastery and learning continuously. Ultimately, I just try to get up every day and do the best I can and find joy in the people I connect with, the good things that are happening and through working out ways past the more tricky areas.

What set you on the DevOps career path?

I guess an early interest in computing – a ZX81 when I was six years old, writing customer relationship management Access databases for a cat boarding house where I worked as a chalet maid (I know!) for many years in my teens, an English Literature and Language degree with a module on computing focussed on natural language parsing and this emerging thing called HTTP and a job after graduating at IBM were the steps that got me here. My career in technology has been mainly focused on the software development and delivery lifecycle, release and deployment automation and more recently the broader DevOps topic. I love the way in which it’s brought the teams of developers and sysadmins together (and so much more since) and I have relished the opportunity to expand my capabilities to include cultural and organizational change and work across entire business value streams.

What do you love most about being a woman in DevOps?

I’m a bit uncomfortable sometimes about identifying as a woman – having been in IT for so long I’ve got kind of used to being a bit of a rarity and just glossing over it. I guess there is a bit of negative bias and a bit of positive bias from different people and places and times. I do think the fight for equality is strong though and the support I see from the men I work with is hugely helpful. My partner told me last week about a senior female leader in the technology company he works for talking on stage about how it’s going to take around another 200 years for women to have equal pay and he and his colleagues were horrified. It’s good to know that most people get feminism isn’t women against men.

So what do I love most about being a woman in DevOps? It’s not really about being a woman – it’s about DevOps. I love the ground-breaking improvement thinking systems and practices that help the people I work with do work better every day and along with that become happier and more fulfilled people. At Ranger4 we say we are fanatical about making life fantastic and, for me, that’s the core of DevOps.

What are some lessons you have learned on your DevOps career journey?

This is a really hard question to answer (yeah, I know I chose it!) as DevOps is such a learning journey. Once you’ve nailed the foundational elements you can deep dive into topics like DevSecOps and safety culture, agile, continuous delivery and automation, building quality and resilience in, lean and value streams and outcomes, organizational evolution and leadership. Maybe the main lesson then is to always be a learner and alongside that, listening and always having compassion.

Original Link

BlackTech Week Miami Comes to Los Angeles on City Tour

Since BlackTech Week’s inception, the company has convened thousands of tech entrepreneurs, investors, and enthusiasts. Due to the success of BlackTech Week Miami, the team decided to take things on the road, naturally stopping off in the city of Los Angeles. Content revolved around building tech ecosystems, protecting your brand, STEAM educator resources, customer acquisition and growth strategies, and raising capital and was sponsored by Samsung NEXT and the Chan Zuckerberg Initiative.

Day one consisted of a kick-off party at the California African American Museum and by day 2, information was flowing full force at Beat Box Studio LA.

Black Tech Weekend LA Kick-off party at the California African-American Museum (Image: Serbaffo)

Black Tech Weekend LA Kick-off party at the California African American Museum (Image: Serbaffo)

Some of the speakers included: Alicia Garabedian, venture capitalist of Samsung NEXT; Amin Joseph, an actor on FX’s Snowfall + producer; Benoni Tagoe, head of Business Development, Issa Rae ProductionsDarian Harvin, podcast host of “Am I Allowed to Like Anything?” + former curation editor, BuzzFeed News; Jaia Thomas, media, entertainment + intellectual property lawyer; Jasmyn Lawson, Brand Social, Netflix; Johnnie Tangle, regional professionals chairperson for the West Coast, National Society of Black Engineers; Mary Pryor, cannabis entrepreneur; and Tyree Boyd-Pates, history curator, California African American Museum

Co-founder, Black Tech Week Miami, Derick Pearson and Mary Pryor, Cannabis Entrepreneur (Image:  Serbaffo)

Co-founder, Black Tech Week Miami, Derick Pearson and Mary Pryor, Cannabis Entrepreneur (Image: Serbaffo)

The evening finished out strong with a keynote by Bryan Lattimore, director of Narrative Change for the Chan Zuckerberg Initiative who spoke very passionately about social justice.

“What you see on the slide is that there is this huge uptick in the number of people in our prison population—twenty-five percent of the prison population globally is in the United States. We spend $80 billion keeping people there… I’m not gone leave you there. I’m hopeful that we can win.”

“One of the folks within CZI that we study is Tim Gil. He made a lot of money in Silicon Valley, upwards of $400 million. He is known for bankrolling the marriage equality movement. What we can learn from the March to Marriage is powerful master level coordination. One, you bring people into a room. Two, you bring all the other major funders who have similar values and said ‘hey let’s pool our money together.’ Three, he developed a southern strategy, which was actually a coalition of businesses, basically speaking to people’s pockets.”

Bryan Lattimore, Director of Narrative Change for the Chan Zuckerberg Initiative (Image: Serbaffo)

Bryan Lattimore, Director of Narrative Change for the Chan Zuckerberg Initiative (Image: Serbaffo)

Throughout the panels, hosting took place from BlackTech Weekend LA, Emcee & Entrepreneur, Benjamin Carlton, and of course, included brief speeches from BlackTech Week and Code Fever Miami founders, Derick Pearson and Felecia Hatcher.

Co-Founder of Black Tech Week Miami, Felecia Hatcher (Image: Serbaffo)

Co-Founder of Black Tech Week Miami, Felecia Hatcher (Image: Serbaffo)

Next stops for the tour include:

  • May 10th – 12th, Philadelphia, PA
  • May 17th – 19th, NYC
  • May 24th – 26th, DC
  • May 31st – June 2nd, Charlotte, NC
  • Sept 6th – Sept 8th, Houston, TX
  • Sept 13th – Sept 15th, Detroit, MI
  • Sept 20th – 22nd, Kansas City, MS
  • Sept 27th – 29th, Cincinnati, OH

Check out the site for more information.


The post BlackTech Week Miami Comes to Los Angeles on City Tour appeared first on Black Enterprise.

Original Link

BlackTech Week Miami Comes to Los Angeles on City Tour

Since BlackTech Week’s inception, the company has convened thousands of tech entrepreneurs, investors, and enthusiasts. Due to the success of BlackTech Week Miami, the team decided to take things on the road, naturally stopping off in the city of Los Angeles. Content revolved around building tech ecosystems, protecting your brand, STEAM educator resources, customer acquisition and growth strategies, and raising capital and was sponsored by Samsung NEXT and the Chan Zuckerberg Initiative.

Day one consisted of a kick-off party at the California African American Museum and by day 2, information was flowing full force at Beat Box Studio LA.

Black Tech Weekend LA Kick-off party at the California African-American Museum (Image: Serbaffo)

Black Tech Weekend LA Kick-off party at the California African American Museum (Image: Serbaffo)

Some of the speakers included: Alicia Garabedian, venture capitalist of Samsung NEXT; Amin Joseph, an actor on FX’s Snowfall + producer; Benoni Tagoe, head of Business Development, Issa Rae ProductionsDarian Harvin, podcast host of “Am I Allowed to Like Anything?” + former curation editor, BuzzFeed News; Jaia Thomas, media, entertainment + intellectual property lawyer; Jasmyn Lawson, Brand Social, Netflix; Johnnie Tangle, regional professionals chairperson for the West Coast, National Society of Black Engineers; Mary Pryor, cannabis entrepreneur; and Tyree Boyd-Pates, history curator, California African American Museum

Co-founder, Black Tech Week Miami, Derick Pearson and Mary Pryor, Cannabis Entrepreneur (Image:  Serbaffo)

Co-founder, Black Tech Week Miami, Derick Pearson and Mary Pryor, Cannabis Entrepreneur (Image: Serbaffo)

The evening finished out strong with a keynote by Bryan Lattimore, director of Narrative Change for the Chan Zuckerberg Initiative who spoke very passionately about social justice.

“What you see on the slide is that there is this huge uptick in the number of people in our prison population—twenty-five percent of the prison population globally is in the United States. We spend $80 billion keeping people there… I’m not gone leave you there. I’m hopeful that we can win.”

“One of the folks within CZI that we study is Tim Gil. He made a lot of money in Silicon Valley, upwards of $400 million. He is known for bankrolling the marriage equality movement. What we can learn from the March to Marriage is powerful master level coordination. One, you bring people into a room. Two, you bring all the other major funders who have similar values and said ‘hey let’s pool our money together.’ Three, he developed a southern strategy, which was actually a coalition of businesses, basically speaking to people’s pockets.”

Bryan Lattimore, Director of Narrative Change for the Chan Zuckerberg Initiative (Image: Serbaffo)

Bryan Lattimore, Director of Narrative Change for the Chan Zuckerberg Initiative (Image: Serbaffo)

Throughout the panels, hosting took place from BlackTech Weekend LA, Emcee & Entrepreneur, Benjamin Carlton, and of course, included brief speeches from BlackTech Week and Code Fever Miami founders, Derick Pearson and Felecia Hatcher.

Co-Founder of Black Tech Week Miami, Felecia Hatcher (Image: Serbaffo)

Co-Founder of Black Tech Week Miami, Felecia Hatcher (Image: Serbaffo)

Next stops for the tour include:

  • May 10th – 12th, Philadelphia, PA
  • May 17th – 19th, NYC
  • May 24th – 26th, DC
  • May 31st – June 2nd, Charlotte, NC
  • Sept 6th – Sept 8th, Houston, TX
  • Sept 13th – Sept 15th, Detroit, MI
  • Sept 20th – 22nd, Kansas City, MS
  • Sept 27th – 29th, Cincinnati, OH

Check out the site for more information.


The post BlackTech Week Miami Comes to Los Angeles on City Tour appeared first on Black Enterprise.

Original Link

The Time I Wore a Bulls Eye

While working as a consultant early in my career, I was tasked by the corporate division to build a new application which would not only track our billable time, but also feed the ERP system with billing information for the hundreds of consultants located across the United States.

While I took an iterative approach with the development and design, this project pre-dates the implementation of Agile adoption. My product owner was the CIO with C-level directors and vice-presidents acting as stakeholders. All were focused on getting an up-to-date handle on the costs and revenues associated with the professional services division of a large conglomerate.

Within a relatively short time period, a fully functional system was put into place. I worked with a couple of corporate trainers who built a short training program which was used to train the end-users of the system.

Production Deployment

Those who work in professional services report their time so that invoices can be generated for their billable time. In all of my years of being a consultant, the biggest challenge is to keep staff motivated to enter their time promptly. As a result, one of my primary objectives was to make it quick and easy to enter time—on a daily basis. The application had a link which allowed time for the day to be entered within a few mouse clicks and input fields. This functionality was designed for those who worked for the same project day-after-day, which covered about 80% of our professional services at the time.

While I was able to make things easier for the professional services teams, the middle management layer above the consultants, but below the stakeholders, were not completely happy with the new application. The prior time tracking system had several manual processes in place to extract and transform the data for use by that level of the organization. The problem was, the CIO (and other corporate stakeholders) were not aware of this need—nor was I, as a professional consultant working for our list of clientele.

It wasn’t long before their frustrations were directed toward me. A few weeks later, during a time when all the middle managers would be congregating for a meeting, they asked me to join one of their sessions.

Facing a Hostile Situation

Several email messages found their way into my inbox, asking how they would be able to perform their job with the new system in place. I could sense the frustration they were dealing with and figured the meeting is going to be somewhat hostile in nature. Perhaps, not to where my personal safety would be at stake, but where the emotions would be high. After all, a portion of this group’s salary was based upon the success of the professional service teams they managed.

When I relayed this situation back to the CIO, his initial reaction was to push back on meeting their needs. His thought was that the system was designed to benefit the corporation and provide a direct connection to the ERP system for billing purposes. However, after some discussion, he agreed to listen to their needs and figure out what is possible to include in the new system to help meet their needs.

I knew the meeting was going to start off in a tense state, so I felt like I needed a good ice-breaker.

Toy Store Visit

On my way to the meeting, I decided to stop by a toy store that was on my way to the meeting location. While there, I was able to locate a roll of kite string and then I asked for directions to where the bb and pellet guns were located. I wasn’t planning to arm myself. Instead, I found a small package of bulls-eye targets that were big enough to cover my chest area.

When I arrived at the meeting location, I found a hole punch and some clear tape. I removed a target from the packing, added holes into each corner, then used the kite string to make it easy to attach the target over my chest.  My ice-breaker was ready, I would enter the meeting wearing a bulls-eye on my chest.

The Meeting

The best part about the meeting, was that my segment occurred in the last section of the morning session. I waited outside until it was my time to meet with the group of middle managers, which was when the prior presenter left. As she left, I walked into the meeting—wearing the bulls-eye in plain view.

“Hello. My name is John and I developed the new engagement management system.” I announced as I walked to the front of the room. I paused, closed my eyes and acted as if I was the target of an old-fashioned firing squad.

It seemed like forever, but it was probably only about ten seconds before the group started laughing at my ice-breaker. Which seemed to break the tension that I was expecting to face during the meeting.

I started by explaining the reasons behind the new system and the original goals that were being met. From there, I talked about conversations that I had with the CIO which put us into the position to where we can figure out how the needs of middle managers can be met.

I don’t believe the majority of those in attendance knew the backstory for the application. As a result, the session that was likely to be a hostile situation, instantly transformed into a pseudo JAD session, where their needs were being heard and understood.


Conflicting needs can often result in frustrations across different classes of application users. While I knew I was merely the developer of the application—meeting the vision of the product owner—I also realized there was a high level of frustration for a class of users whose needs were no longer being met. 

I found that using the bulls-eye as an ice-breaker, I was able to relieve a bit of the tension, projecting an understanding of their frustrations. This wasn’t the only time I have used an ice-breaker to break the tension, but it was certainly one of my favorite stories to tell.

Have a really great day!

Original Link

Women in DevOps: Jessica Deen

In our Women in DevOps blog series, you’ll hear from talented women in DevOps. They will share their experiences in DevOps, their thoughts on leadership, lessons learned and also how we can encourage more women to focus on an IT career. Today, we hear from Jessica Deen.

Jessica is a cloud developer advocate for Microsoft focusing on Azure, containers, cloud, open source software and, of course, DevOps. Prior to joining Microsoft, she spent over a decade as an IT consultant/systems administrator for various corporate and enterprise environments, catering to end users and IT professionals in the San Francisco Bay Area. Jessica holds two Microsoft Certifications (MCP, MSTS), three CompTIA certifications (A+, Network+ and Security+), four Apple Certifications and is a former four-year Microsoft Most Valuable Professional for Windows and Devices for IT. In 2013, she also achieved her FEMA certification from the U.S Department of Homeland Security, which recognizes her leadership and influence abilities during times of crisis and emergency.

When she’s not doing something geeky, you can find her doing something active, most likely running out of breath at her local CrossFit gym. Yes, she’s one of those! She also enjoys biking (motorcycles and/or bicycles), shooting, eating, reading and hanging with her five-year-old rescue pup.

Hi Jessica! What has your experience been as a woman in the DevOps industry?

As a whole, my experience has been extremely positive. I’ve been in the IT industry for 12+ years and when I started, I was one of the few women I knew in this field. With that said, I have always received support from every company I have worked for. Over the last five years or so, I’ve had the great honor of working with some of the most talented and passionate individuals in this DevOps world; many of those I have worked with throughout my career have been women. The team I’m currently on at Microsoft, the Cloud Developer Advocacy team, is so powerful and inclusive, I don’t even think about gender. We have amazing people – male and female – on our team and everyone is treated equally. More importantly, we are all valued for our skillset and expertise – the fact that so many of us happen to be female is just a bonus.

Since you have worked with so many talented and passionate DevOps Divas, what do you look for in a great company/boss/mentor?

I look for the same qualities in both company and boss/mentor – passion, encouragement and constructive criticism. I want a company and boss who are passionate about me and my professional growth, my career development and on the same hand, I want to be passionate about the company I work for. I want a company who is willing to invest in me, the same way I invest my time, energy and skill into it. I think the best kind of boss, and as I say this, I think of my current manager, is someone who pushes you to be better, do better, empowers you to grow and then gives you the freedom to do so. When I went through the interview process for my current team – The League of Extraordinary Cloud DevOps Advocates – my manager asked me questions about where I want to be in five years, what gets me excited about work, what’s my biggest professional goal and what about my job makes me passionate. When I told him my goal, he responded with, “I will make that happen, and now I want you to think bigger.” Since joining this team, I wake up constantly thinking, “Is this real life? I get to do so many awesome things with so many inspiring people. I can’t believe this is my life, let alone my career.” My current boss tells me all the time, “If you ever wake up and actually believe this IS your life, tell me immediately so I can make your life unbelievable again.” That kind of support and encouragement – that’s what I look for in a company and a boss/mentor.

WOW! And from this place in your life, if you could give your younger self some advice for the future, what would you tell her?

I think the best advice I could give is – keep doing what you’re doing. I don’t want to give any spoilers by providing too much advice. The path I’ve taken to get to where I am today…well it’s been a fun ride. I want my younger self to have just as much fun. She’ll figure it out.

That is great advice. What personality traits or habits would you say make one successful in DevOps?

I think the biggest personality trait I can think of is – be open. Be open to change, be open to growth. I had an IT (Ops) background for so long, but I began working closely with developers when it wasn’t “normal” to do so. DevOps wasn’t really a word used at that time, and I didn’t realize my openness to things like automation and scripting to simplify both the developer’s life and my life was setting me up for a DevOps-centric career. However, again, the fact that I was open to change, open to new ways of doing things, that, I believe, made me successful.

What does career success mean to you?

Career success means waking up every day absolutely excited and passionate for what I have on my plate; if I can inspire others with that passion, I call that a win in my book. If I can wake up every day with joy for what I do, and joy for others in my communities, well, what more could I ask for? I could ask for an unbelievable life where I get to work with incredibly inspiring individuals around the world, but I already have that and that feels like success to me.

Original Link

How to Survive Your First 100 Days as Head of DevOps

You’ve just been given the responsibility to lead a DevOps transformation in your organization. Where do you begin? How will you approach the situation? What will you start or stop doing? What are your goals?

Luckily for you, many people and organizations, both large and small, have already experienced the growing pains associated with this process and have had great success. Now that others have worked through the challenges, there’s a basic playbook for moving your organization toward DevOps principles. It won’t be easy, but it can be done!

Let’s take Target, for example. They are the sixth largest retailer in the U.S., and they spend over $1 billion on technology each year. They rely on strong IT to compete online against competitors like Amazon and Walmart. The DevOps Handbook discusses Target’s transformation in various case studies. A case study on API enablement from 2015 discusses the organization’s shift to DevOps principles during 2012. It took almost a year to deploy new technologies, during which time Target adopted cross-functional teams, continuous integration, and increased automation. As a result of these changes, their digital sales increased by 42% during the 2014 holiday season, and they were able to introduce powerful business capabilities like Ship to Store and Gift Registry. Sounds like their investment in IT paid off, doesn’t it?

In this blog post, we’ll review the best ideas and practices from The DevOps Handbook. This book provides concrete steps that you can take to transform your organization with DevOps. These aren’t pie in the sky ideas either. All of the practices presented in this resource have proven successful in practice and with focused case studies in larger organizations. Together, they provide a playbook for how to build a fast-moving, customer-facing organization.  

Defining Your Objectives

DevOps, like all philosophies, requires adopting new assumptions. The first assumption deals with what your process should be optimized for. Generally speaking, your goal is to pick up the pace in presenting new ideas to your customers. The idea sounds simple enough, but it’s actually quite difficult in practice.

The first step in tackling this pacing objective is measuring your activity using what we call “lead times.” Ultimately, your goal is to shorten lead times, which in technical terms refers to how often production deployments happen. Utilizing this metric is critical. This metric alone tells us a great deal about an organization: how fast they turn business ideas into customer value, how quickly they can recover from bugs or failures, how reliable their deployment process is, etc.

Shortening lead times requires removing bottlenecks in your process — both technical and organizational. According to Dr. Eli Goldratt’s work, which can be found in The DevOps Handbook, “[t]o reduce lead times and increase throughput, we need to continually identify our system’s constraints and improve its work capacity. In Beyond the Goal, Dr. Goldratt states, ‘In any value stream, there is always a direction of flow, and there is always one and only one constraint; any improvement not made at that constraint is an illusion.’”

In essence, he’s saying that it isn’t enough to remove one constraint on a single occasion. You must continually assess and remove constraints from your process. This is the DevOps cycle, in which changes create positive feedback loops. These changes start at the top, which means they start with you.

Crafting Your Organization

Now that you have the power to reshape and direct your organization, you’ll be expected to put it to good use. Well-communicated and easily understood ideas help drive progress. The first order of business is communicating the idea that you’re going to give your customers more changes, more often.

That said, you must measure your lead times and make sure everyone in your organization sees the results. A simple measurement option might be the time from when an issue enters the backlog to the time when it’s verified in production, which captures everything in your process. The metric doesn’t measure all of the individual steps for putting XYZ into production since that’s irrelevant to your customer. What your customer cares about is how quickly they receive your product or service. We recommend that you use this metric to better understand your customers’ and product team’s respective points of view — because they will undoubtedly feel differently.

Your first lead time numbers might be disappointing, but that shouldn’t be a surprise considering that’s the reason why you’re leading this transformation in the first place. To improve your lead time numbers, make sure that everyone in your organization sees the data and sees it often. Track and update it as much as possible. Put it on the screens around your offices. Use it to drive conversations at all stages in your process. Make it part of the daily conversation. Engrain it into your culture.

This is a powerful culture change on multiple fronts. First of all, it provides a simple, objective way to measure progress. Set a goal to drop lead times by X amount. You’ll be shocked at how powerful this direction is. Second, it promotes accountability in organizational processes through measurable metrics. It has a knock-on effect of creating a data-driven feedback loop in new places. Third, it forces your organization to continuously work on locating and fixing bottlenecks. Lastly, it will hopefully become personal for everyone in the organization — including you.

DevOps as a Team Effort

You’re leading this charge, but that doesn’t mean you can’t delegate certain tasks to other team members. Shortening lead times means increasing organizational autonomy. In other words, you need to give teams authority over and responsibility for their bit of the business. This kind of organizational change requires minimizing silos, reorganizing technical workers, and performing process checks.

Your organization needs cross-functional teams to succeed in the new IT landscape. Jeff Bezos did similar things when he reorganized Amazon. He set technical guidelines for how cross-functional teams should interact, and he established expectations for each team. These changes, along with the “you build it, you run it” philosophy, are now deeply embedded in Amazon’s culture, and they continue to drive the organization’s success. You’ll find similar stories from organizations like Target, in addition to some other unlikely IT success stories like Dixons Retail and Nationwide Insurance.

Organization and culture changes like the ones Bezos put in place empower knowledgeable team members to remove bottlenecks and shorten their own lead times. It also creates a technical framework for their activities.

Changing Your Technical Practices

Shortening lead times requires changes in how your organization deploys its software. Your organization should strive for more deployments, so you should track that number continuously. Some DevOps organizations measure deployments per day, while others track deployments per developer per day. This may seem counterintuitive, but it results in fewer bugs and higher quality software. This practice is called continuous delivery (CD). CD is the technical embodiment of DevOps principles. Your goal is to push the organization in that direction. You can do that by requiring that each check-in must be deployable to production.

Adopting Continuous Delivery

This check-in requirement forces your organization to adapt and enhance their existing practices. Generally speaking, this means running an automated test suite against each check-in and automated procedures to deploy each check-in. The automated test suite will ensure that everything works as expected. Automated deployment procedures remove human error and open up the deployments to more people. With automated test suites, your teams can be confident that new features will work correctly without breaking existing features, which is what your customers want.

However, constructing a CD pipeline isn’t straightforward, especially in brownfield projects. There’s probably a mix of manual and automated work. Think back to the quote from earlier. Start by eliminating manual, human effort in the process since these are the most likely bottlenecks. You can then expand outward from there. If the team is unsure of how to proceed, ask them what they can do to deploy more often and with more confidence.

Shorten Lead Times With Smaller Batches

The simple answer to this question might surprise you — work in smaller batches. As we’ve said, DevOps organizations work by shortening lead times. Generally, the two variables in this equation are how long it takes to deploy something and how big it is. If you can’t change the process, change the size. Smaller changes are usually easier to develop, test, deploy, and verify. For example, would you rather ship a major feature along with a banner color change, or just a banner color change? The answer is just a banner color change.

Having your teams work with the smallest possible batches will reduce lead times since less time will be spent on analyzing, reviewing, planning, and executing changes. Don’t assume that working in small batches means providing less value to the customer; it’s quite the opposite. Smaller batches with more, smaller changes get to the customers faster. What if the banner color changes would improve service for visually impaired customers? Why should they wait for other features? We recommend that you combine this practice with continuous integration for the best results.

Breaking up Big Batches Using Feature Flippers

Unfortunately, not everything fits into small, easily delivered batches. Some major business efforts require stages, customer verification, complex technical migrations, etc. This tends to happen with big bang deployments or extremely long release cycles. Deploying this way is unfavorable to say the least, but you’re probably familiar with it.

There is, however, a way around this problem — one that Facebook and many other organizations use. The solution is feature flippers, which are a fantastic alternative to big bang deployments. Using feature flippers, your team can control when certain product features are active. This is useful for beta testing among a preselected group of users or a random percentage of users, and even for disabling features when there are known problems.

Feature flippers provide engineers with more options in constrained environments, too. Maybe your team faces unique problems in production that can’t be replicated elsewhere. Feature flippers let your team test new features in stages rather than all at once. They also allow an “employee” mode so that everyone in the company can see the “next” version — all running in a production environment.


The technical and organizational practices presented in this post from The DevOps Handbook are just the tip of the iceberg. They’re all driven by feedback loops that are set up in code and in the organization itself. Creating these underlying feedback loops is your goal.

In order to succeed in your DevOps transformation, you need to hold everyone accountable to new, customer-facing value standards. Transformation happens in stages. You should consider walling off your DevOps transformation to a small team with complete buy-in. You must sell the ideas in order to be successful. Start small and expand outward when you’ve achieved desirable outcomes.

We recommend that you consider these pieces of advice and delve deeper into The DevOps Handbook for more guidance. Your efforts to shift your organization toward a DevOps transformation will be well worth it. The results of increased productivity and an adjusted culture will speak for themselves.

Original Link

  • 1
  • 2