devopsy.kinsta.cloud

Tag: managers

Managing Remotely: 6 Ways to Support Engineers

Managing remote engineers effectively comes with a host of considerations. Here are six to keep in mind

Dear 2020, we’d like our deep work back.

Our shift to remote work in 2020 moved the majority of face-to-face interactions into screens. Although initially we assumed this shift was a temporary adjustment, most of us now realize it’s just the opposite. Twitter, Facebook, Shopify, Slack, Box and more have publicly declared remote work is here to stay and they are not alone—84% of businesses now report they will increase remote work post-COVID-19 pandemic.

With our new reality came next-level distractions—homeschoolers, playful pets, social unrest and, oh yes, a scary global pandemic. Moreover, the lockdowns rewired our collaboration habits, stretched our bandwidth, and threatened our ability to focus on our best work.

As a result, managers—the forgotten middle of the workforce—are emerging as quiet heroes fighting to protect team effectiveness. At Uplevel, we’ve worked with engineers nationwide and have learned the top ways that managers can help their engineers empower their best work:

Mind the Meetings

Engineers want their managers to protect their time for deep work. They are constantly bombarded with changing priorities that require endless meetings, crushing their ability to dive in, solve problems and innovate. How bad is it? Of the 250 engineers and managers we interviewed, 50% of individual contributors reported that more than twice a week they don’t have enough time to do their work, with 19% of engineers reporting it’s an issue every day. Bottom line: If a meeting “coulda been an email,” make it so.

Say No to Micromanagement

Nobody likes the helicopter parents of work. The constant hover erodes trust, destroys morale and slows down otherwise efficient, effective people. Top performers will tell you, autonomy contributes to their overall happiness at work, and research continually tells us that happy employees are more productive and they stick around longer. Instead of spinning on the minutia, make it your mission to block distractions and tackle bottlenecks for them so they are empowered and available to do their best work. More than one-third—39%—of engineers are blocked on issues they can’t unblock themselves at least once a week. That’s a weekly chance to free your team to do their best work.

Embrace Flexibility

For the sake of protecting “the flow,” it’s a good time to go with the flow, too. Overly structured, old-school project management must give way to the fluid, flexible tools empowering us to get work done anytime, anywhere. Embrace a project management style that is as fluid as your team’s changing priorities and consider light-touch micro check-ins that leave room to revisit the game plan weekly.

More Comms, Not Less

Right now, it’s easy for individual contributors to feel both socially and professionally isolated. As a result, their confidence waivers and paranoid flares as they question whether their contributions make an impact or get noticed at all. Now is not the time to back off of communications. Don’t confuse this with “respecting personal boundaries.” If you’re worried that communicating will somehow exert unintended pressure, simply establish clear expectations and model them by example. A simple way to lean into communications is to make them more frequent, much shorter and less formal. By acting more like a coach than a manager, you’ll not only keep the team focused on the right tasks but you’ll also show them you care about their well-being beyond “the work.”

Lead By Example

The quickest way to zap trust and kill morale is by ignoring your own rules. Engineers want their managers to lead by example and consistently exhibit the same behaviors they expect from their teams. If it’s respecting work/life balance (and refraining from midnight emails), don’t hit the send button until it’s time. If it’s a commitment to stay present during group meetings, stop multitasking. If it’s a promise to wear pants on Zoom calls, put your pants on. You get the point: Don’t create rules for remote teams that you’re unwilling to follow yourself.

Create Opportunities To Connect

You’ve heard it time and again since March: We’re in this together. It’s true. No one rolled into the pandemic with a playbook; managers and their teams are winging it. Forced isolation is not a normal human state and it shows. Across the country, doctors report more cases of depression, domestic violence and substance abuse. In fact, a poll by the Kaiser Family Foundation shows the pandemic is taking its toll—45% of adults say this pandemic has affected their mental health. Another study by mental health provider Ginger found 69% of employees admit this pandemic has been the most stressful time of their career. How can you help? Use this collective behavioral beta test as an opportunity to show empathy and connect. Are team happy hours gone? Replace them with the dogs and cats of Zoom at the beginning of your weekly meeting. Are team lunches no longer doable? Have virtual outdoor picnics and encourage your team to get some fresh air. Be creative—it’s a great time to rally around the things that connect us as humans, not just teammates.

Thanks to the COVID pandemic, 64% of us now commute from our beds to our home office (or the kitchen table, or sofa). That’s a ninefold increase in four months. As it turns out, many of us don’t mind the change. A full 60% of us would actually prefer to keep it this way. If our engineering teams stay virtual, it’s our job to empower them so that remote work can still bring about their best work. As we embrace this ever-changing world, now is the time to tap into our empathy and communication and leverage the data and technology available to us to ensure we turn hardship into innovation.

August 26, 2020
How Much QA is Enough in Software Development?
People working in quality assurance as testers, managers or engineers know what it’s like having to justify their existence; it’s been part of the job for many years. QA experts have had to fight the perception that what they do is a bottleneck, overkill and it slows everyone down.

Finally, however, QA is getting the attention that it deserves. Companies are gradually investing more in QA skills and tools. This began with the onset of Agile and DevOps—methodologies which have now infiltrated mainstream software development practices everywhere. Since those practices focus on speed, efficiency and quality, engineering leaders have grown to understand that great products are not achievable without adequate QA checks and balances. Another risk is the unflinching nature of high user expectations: Thanks to social media, one user complaint can quickly escalate into others across the web, creating an uncomfortable perception problem for the software provider.

Robust testing practices can prevent egregious flaws in the software that result in poor user experience and performance—or, worse, a breach. True, testing can sometimes get in the way of speed. Yet no matter how fast you release a product, if it doesn’t work well, no one’s going to buy it, much less use it.

Nevertheless, we can continually improve the QA practice to fit into modern development teams’ workflow. Testers need to work with developers and master automated testing, while developers need to sometimes engage in testing; everyone should think about the appropriate level and amount of testing. You can have too much of a good thing.

The Right QA Balance

The below ideas can help your organization reduce conflict between QA aficionados and those who would rather code and release as fast as possible.

1: Assess, analyze and report. Developers and testers alike are highly technical; they like numbers. Therefore, the more that the QA team can quantify the risk of an application, provide evidence as to the effectiveness of current QA practices and use metrics to show the need for more QA resources when warranted, the faster that everyone will get on board.

There are plenty of tools that can deliver common quality metrics such as total number of defects, defect leakage, test coverage, test pass/fail rates, test completion rates, code coverage and application uptime. It’s important to share and discuss these metrics throughout the development team and with product and business managers. What constitutes high quality for the development team may not be the case with executives who are closer to the end user/customer.

2: The gut check. After metrics, take into consideration the comfort level of your team and company concerning product flaws. In regulated spaces, or for applications that collect sensitive private data, the tolerance for bad code and security gaps is usually low. Gather feedback from different perspectives and roles in the organization for a balanced perspective on the QA practice and areas for improvement.

3: Get people involved. Quality assurance is no longer a separate activity from development; especially when you are practicing Agile and DevOps, the responsibility for quality is shared. Therefore, developers, business analysts and operations managers all should be doing their work with an eye to quality, delivering feedback regularly to the QA team. Provide opportunities and incentives for any team member to attend events and training related to software quality.

4: Streamline testing. Test automation tools are helping product teams be more comprehensive in testing, by automating low-risk test cases so that testers can focus their exploratory and manual methods on high-risk or new features. This is a positive development, although testers must take time to learn how to use the tools. Some other ways that can help teams be more efficient in testing include:
- Conducting more testing early in the sprint. This avoids the 11^th hour disaster of finding a major flaw right before the release deadline.
- Per Agile methods, dividing development tasks into smaller chunks with team members from different disciplines to ensure testing is being done all the time and with visibility by all.
- Using test driven development (TDD) or behavioral driven development (BDD), which requires that QA, developers and business stakeholders meet at the beginning of a project to agree upon requirements and test cases. Developers then write code against the test, until it passes. New tools are helping bridge the gap by writing requirements and user stories in plain English.
- Outsourcing part of the testing load during a major project, which can help increase coverage and reduce stress on your team. However, understand that too much outsourcing will undermine any efforts to develop QA as an internal best practice and “mindset” for software teams.
If your team is committed to QA as a best practice, not an afterthought, those at the top will need to invest properly in the right tools, training and people to get results. Misconceptions about QA still exist; contrary to the view of some DevOps experts, we can’t (and shouldn’t) automate every test. As well, even though developers are now testing the code they write, you still need experienced testers on your team. With the pace of innovation and the high stakes in the marketplace, organizations need more—not fewer—people engaged in testing.

For testers who love their job, as many of them do, it’s an exciting time to be in the field. Companies increasingly are seeing the value of QA and testers continually are gaining more tools and tactics to excel at helping their organizations produce really great software.

About the Author / Kyle McMeekin

Kyle McMeekin is Senior Sales Engineer at QASymphony. Prior to QASymphony, he was a programmer analyst at Cognizant Technology Solutions. Connect with him on LinkedIn.
May 8, 2017
An Unanticipated Obstacle to Full Automation

I’ve been concerned about the impact of automation on human employment for a while. My research activity started after November 2016, when I decided I needed to learn whether the much-touted phrase, “We’re bringing back the jobs,” was valid or not.

While it is true that some jobs in the United States have been exported to other countries, a study coming out of Ball State University in Indiana asserts that 88 percent of the jobs lost by U.S. workers is due to automation. Combine this study with the one published in 2013 by Frey and Osborne out of Oxford University that says that 47 percent of the jobs in the United States are risk, then things don’t look so rosy. Martin Ford, in his book, “Rise of the Robots,” goes so far as to say that every occupation is at risk, not just low wage workers who are paid to do repetitive tasks that are easy to learn. Not only will we have machines flipping burgers, they’ll also be perusing volumes of legal documents during discovery processes, which is the type of work that now is done by paralegals and newly hired law school graduates.

Machines are getting smarter all the time and they are getting cheaper. You can buy Baxter, a full fledged factory robot, for $22,000. Baxter can work 24/7 and is not subject to OSHA laws or workers’ compensation coverage.

Software? That’s getting cheaper, too. Every day, another open-source project is made available on GitHub that allows anybody with a computer and connection to the internet to take advantage of the power of artificial intelligence and machine learning. You want Swift code for artificial intelligence? No problem. It’s on GitHub and available to all for free! Want to convert your English ReadMe into Japanese? Simple, just use an API such as Microsoft Translator or Google Cloud Translate.

Given the current trends in technology, it’s not hard to imagine that within the next 15 years to 20 years we’re going to have a world in which fewer people are employed. This future scenario worries me.

About a week ago I was sharing my concerns with Chris Surdak at Surdak and Company. Chris works with large corporations implementing robotic process automation (RPA). He is also on the board of the Institute for Robotic Process Automation and Artificial Intelligence. Chris is at the front lines of using robotics and artificial intelligence to increase commercial efficiency. He and I share a concern about the wave of worker displacement we see on the employment horizon. However, Chris has an interesting take: While he agrees that automation is going to cause significant displace of human workers, he sees an obstacle.

Imagine you are an executive in a corporation and you have 5000 people under you. One day someone like me tells you that you can replace 80 percent of your workers, 4000 people, by streamlining your work processes using robotics and artificial intelligence. You should be ecstatic, right? That is a significant cost savings that is going to directly affect your bottom line.

But, it doesn’t work that way because that is not how many corporate managers think. They want to keep their jobs and in order to do so they need two things: headcount and budget. So, if I come along and tell them that I can create an efficiency that is effectively going to cost them power (less employees and a smaller budget to manage) and maybe their jobs, do you think they are going to jump on board right away? Nope. In fact, they are going to do everything that can to slow down my work until they retire.

Chris’s statement was a revelation to me. Previously, I thought corporations in their continual quest to seek greater profits will do whatever is required to reduce costs and increase efficiency. Most of us who do tech, particularly in DevOps, have embraced this notion. Automation is our friend. We’re lazy. We want the code and machines to do the heavy lifting. And, we’ve created environment where automation is necessary, For example, large-scale container deployment alone went beyond the capabilities of human management a long time ago.

There is a good argument to be made that the factory floor has not had problems using machine automation to improve efficiency. Factories have looked for improved efficiency via tooling since before industrial textile mills used water wheels to power their looms. But, there are other industries that are risk-averse and slow to change; insurance, for instance. The virtue of an industry such as insurance is that it’s ingrained in its culture to manage risk and to be measured when considering change. After all, would you want your retirement annuity to be subject to the whims of a day trader? No. You want your money well-protected by a cautious steward. However, with such safety comes inertia. Thus, there is an intrinsic resistance to change in general and automation in particular. Add in a culture of self preservation on the part of management and … well, you get the picture.

So there are industries that will be resistant—for a while, anyway. Then one of two things will happen. The companies that are not resistant to automation will enjoy the efficiencies the technologies bring. They will gain market share by providing a better product at lower cost and they will trample out the competition—think Uber and the taxi industry. Or, those resistant corporations will realize that to survive, managers who manage by “saving my job” will be given a golden parachute after revealing all the tribal knowledge hidden in their work groups. (Undocumented rules and processes are the bane of process engineers when implementing automation.) Either way, the march of automation will continue and workers will be displaced.

Given the increasing rate at which jobs are being replaced by automation, will these displaced workers find other jobs? This question I leave to you to answer.

— Bob Reselman

April 21, 2017
‘Not My Problem’: A Big Problem for DevOps Teams

Not my problem (NMP) – (n)
1.    a statement, or position, of apathy expressed by those who perceive they are external and unaffected by a negative predicament. While sometimes warranted, it is typically uttered by those who perceive themselves as powerless; can’t be bothered; are too lazy, or are selfish non-contributing leeches. See also “complete cop out”
2.    an attitude that will stymie attempts to implement DevOps in your organization and will thwart success
3.    (archaic) Actually not your problem

While perhaps it’s become more frequent in our culture of relative indifference, some of our oldest stories bear witness to how timeless the phenomenon “not my problem” is. For example, in the the biblical story of Cain murdering Abel, God asks Cain afterward, “Hey Cain, I can’t find Able. Do you know where he is?” Cain responds famously, “Am I my brother’s keeper? (NMP)” It crosses country borders and language barriers, too: A transliteration of the same sentiment in Polish is, “Not my circus, not my monkeys.”

And we’ve all been guilty of thinking it at work: “That’s not in my job description,” “I’ve got to focus on my own projects rather than bail that person out,” “That’s the Sales team’s role.” These thoughts pass uncharitably through most of our minds, despite most of our unwillingness to say something so callous to a person we witness being affected by our indifference.

It would be naïve to think that this cultural indifference was held at bay by DevOps teams, all united under the same goal of turning out quality product in the most efficient ways. Unfortunately, the NMP problem can pervade even the most motivated and scrappy teams, and it has a unique power to dismantle attempts at positive culture-building on those teams, which are necessarily built on the core values of sharing and learning.

To have DevOps teams that embody these fundamental characteristics, we have to shift the individual and team perceptions of the ownership of success and failure. It can no longer be an Ops or Dev or QA or InfoSec issue. It has to be OUR issue.

Here are some key items that I have found fundamental to combating NMP in my teams:

1.    Change Starts with You

If you don’t want to see NMP present in your team, you need to ensure you are not a contributing source. Before ending your day, dedicate at least a few minutes of reflection to the day’s interactions. Did you actively seek out and identify areas where you can be of assistance? Upon reflection, did you miss an obvious chance to help someone on your team? Keep a daily journal and try to list these things. This will help instill the behavior into your normal regimen.

2.    Culture is What You Tolerate, not What You Mandate

We have all been a part of “hoorah” speeches where we hear the “we are a team” speech; perhaps we have given them ourselves. We have also walked away from said speeches with a cynical demeanor, knowing that they are just words and everyone is out for themselves. While words are important, words without action are just noise. As a leader, you need to communicate your “No NMP” policy, and you need to act upon it. If you are the manager of a team, you must be willing to take corrective actions against people who continue to exhibit a NMP attitude. If you are a member of a team, you must be willing to hold your teammates accountable. Apathy kills. It takes time and patience to repair NMP behavior; sometimes, however, you might need to part ways with the source of NMP. As a manager this may mean letting someone go, or as a team member it can mean letting your team go.

3.    Everyone’s a Leader

As readers of my blog know, I do not equate leaders to managers. I am sure that most of my readers have lived that experience firsthand. But having a non-NMP team requires us all to be leaders, even if your manager is not. We must actively try to identify areas of weakness and and areas of improvement and seek out ways to address them and turn them into areas of strength. Sometimes that even means mentoring your manager. Yes, I know this can be tricky, but good managers will be receptive and open to constructive feedback. If you manager is not and is instead a source of NMP, see No. 2, above.

Many companies and teams have been eaten up with the cancer of NMP. There aren’t enough team-building events and “trust falls” to counteract a culture where some people break for the door while others work to resolve an issue. Because it is this behavior that causes the whole culture to collapse. It can’t be “All for One, and One for All (except Bob, because he’s a selfish jerk).”

It’s incumbent upon all of us, as team members and as managers, to fight the NMP battle. The culture of our teams most certainly is our problem.

About the Author / Adam Bowen

Adam is a technology leader with over 15 years of experience in technical, sales, and senior leadership roles. As the senior member of the Office of the CTO at Delphix, Adam works with other thought leaders executives of the Global F100 to eliminate key business constraints through innovative new processes, offerings and technologies. Adam serves as an evangelist on behalf of Delphix to communicate the company’s vision, values, and ideas with customers.

April 5, 2017
Transition to a new human ecology? We still need managers

Recently I replied to an article “DevOps Cuts Out The Middleman” that excoriated Middle Managers as a cancer. I commented that I disagreed. Nicely, I was invited to make further comment as the loyal opposition. I guess that makes me a sanctioned Troll. Hopefully I am informed enough to make a useful comment. FYI, I have developed software since the time of using x86 assembly gotoxy to move the cursor location on an amber screen. I consider MVC wonderful, but trivial. I have seen many, many projects, much good, much bad, some serious ugly and I have patiently watched like a Troll does. Worse than any Troll, I recently published a book on Philosophy, so asking me a question is generally contraindicated. Sew, you say Middle Mangers are an evil waste of time. May I politely disagree… and go down hill from there. The entire vision is deeply flawed and note they were described as “cancer”. How emotive. From strength comes weakness. From weakness comes strength. Know your weaknesses so they don’t bite you in the byte.

In a perfect world, no, we would have no use for Middle Mangers. The philosophy behind that critique of them was based on that. It is not a perfect world though and managers provide critical, useful leadership.

The description of a DevOps team in the article was the description of a machine. Why not? Machines are notoriously efficient and who is to argue with that? Except that we are humans and on deep levels trying to imitate a machine is something to be very cautious about. In the long run, it is a disaster. Machines are different. Machines are static, humans are not. Humans are far more random, so the system itself has built in risks. Face it, we’re developers and we are often best at imitating machines, which has its own liabilities, but we are not machines and even machines have problems. Human systems have problems sooner than machines, especially when acting like machines and trying to provide the performance of one. Managers are the repairman and lubricants of human based machines. They do the Configuration and Release Management for the team. They are the long term employees that know what is going on and how to handle the unexpected. Their job is providing continuity that only they can. They have the breadth of view that we lose at our keyboards. They smooth things over when a shock to the company comes like loss of a critical system or employee. Someone has to take responsibility. Who do you want it to be… Oh, stake holders. Yah right, they never did before they were called stake holders and still usually don’t. Another thing middle management can do (and I have seen this repeatedly) is when upper management makes a mistake (and they do), it is only the middle managers that can compensate. I won’t mention training and entry level, but obviously there is no consideration of that no matter how critical it is in the real world.

I will just refer to a Middle Manager as a manager, because in this day and age, you have management that are financial planners and you have management that produce a product, whether you call them managers, middle managers, project leaders or what not. That kind of manager provides many functions, hopefully. Think of it this way. Their importance is illustrated by the disaster that ensues when they fail. We all dread that. Leadership is a great skill and of great value.

The article assumed that everyone was proficient at their task. No, that is not the case. Skills and knowledge vary. I used the predecessor to .Net, the C++ Builder, but I am still learning C# now (await). Always a manager’s job is to get the job done with the resources they have. You may not have a team made of master developers. I have always appreciated a good manager, defined as one who gives me direction. A great manager is one that makes me more than I am. A good manager can make very good use of a weak employee and if the employee has the potential, a good manager can make them a strong strong, valuable asset. I know, Brian did that for me.

Developers are not known for our people skills. Those are the skills of a manager. Managers must be psychologists. Developers are smart and most know how to cooperate, but don’t tell me ego problems don’t arise. You can’t even get in the same room with some of the Prima Dona egos I have worked with. In any decent team, you likely have one Aspergers and likely a couple people with a problem dealing with it. Is it possible that anyone is immature? So, do you have someone who refuses to go to meetings? By the arguments of the article, meetings are very like Middle Managers. Then there are team members who need to catch the 4PM bus in Mumbai as well as the one who may not even speak English. Software development is like science. People think it isn’t personal, but it is. Someone has to manage the personal. Managers are a lubricant and without it, the gears of the machine are very likely to rub and grind. They can make a team succeed that could not operate without them.

A manager is a brain. Most team members are necessarily working on the details. Even the designer is swamped. The Scrum Master, besides being a Middle Manager anyway, has varying degrees of authority. An enforcer is needed. Someone has to tell people what the standards are … and enforce them. Someone has to decide how exceptions will be handled consistently. It provides its own efficiency. Chaos is never efficient. The manager provides the focus and order. That is their function. They must provide a focus that no one else on a team can provide. Systems help, but like there are no perfect laws, there are no perfect systems. Who enforces code reviews? Don’t tell me they just happen. I’ve been on great teams that were not under pressure and sorry, they were lax. How many times have I heard “we didn’t need to go down that rabbit hole”. A manager is like a judge that interjects the essential human element to a non-human system. A good project manager makes sure that the project is delivered. That is the preview of all team members, but just as we all have our special strengths, A good project manager will be the one that keeps the project focused and is going to deliver it come what may. We all know just how common a skill among developers it is to be able to interface with senior, non-technical management. Sure, anyone can do it or would you rather have someone with the skills.

OK, I’m a troll, so in respect for the thorough job I always do, it’s time for the mandatory ad homin attack. Lemme get to trashing the author of this article, Tony Bradly. Definite ignoramus. So he authored a few … well maybe a few dozen books. That means nothing! Decades of Security, Communications, Compliance and Systems Administrations leadership. Dum Dum Dum! Consults on systems for a bunch of Fortune … err … Fortune Rarefied companies. So what! Founded the Bradley Strategy Group. Anyone could do that. TV and Radio. A Celeb! Celebs always have opinions. So where does he get off thinking he needs to speak up? Actually, that’s not so funny. The guy is genius in a group of some of the brightest. Have you ever met anyone like him? I haven’t and I’ve worked on many teams and I remember a few truly incredible people, but not in that class. The article makes the assumption that the members of the team are all extremely competent, but that the manager is necessarily not. I don’t get it… or maybe I do. I reviewed the article to make sure I knew what it said. Odd, it said little. It did say middle managers were lazy, useless and a cancer. How very emotive. Ah yes, it looks like ideology. I recognise that flavor. That is a philosophy descended from Ayn Rand. I hear it is popular in Silicon Valley and much of IT culture. This is a model of a team of perfect individuals in a perfect world operating in a specific time frame. It is mostly illusionary, risky in the short run and self destructive in the long run by its static nature. The real flaw of the concept underlying the article is philosophically very deep. I know where this originates. Just remember the end of Ayn Rand’s story. They kept their ideological purity, but it resulted in the fall of darkness. This concept is based on a static illusion and like the story, there is no room for imperfection. I bet Tony has little need for managers or leadership, but he is one. Sorry, but most humans are imperfect and it works better to work with that than live an illusion that ends up fraught with danger.

About the author

Michael Breeden is a software engineer with over 15 years of demonstrated success providing a wide range of software solutions including the complete software application life cycle, relational database development, business objects and business support. He can be contacted at a1swdeveloper@yahoo.com or visit his website at http://a1swdeveloper.com/

August 21, 2014