Leader’s Pulse: What Is The Value Of A Manager’s Role In Modern Tech Organizations?

Do managers even matter? That’s a good question. 

This is the question some MBA students asked for a research project at Google. They called the research, data gathered, findings, implementation, and follow-up “Project Oxygen.” It focused on gathering data regarding what qualities staff perceived would make a “good manager.” The results were not surprising. But, before we examine the results, let’s talk about knowledge workers and what makes them unique.  

Anyone who leads, manages, or supervises knowledge workers  must accept a few stark realities of leading knowledge workers if you have any hope of being successful; these include:

  1. Disdain for paperwork and process
  2. Contempt for managers, often in technical knowledge, but especially in the realities of how work gets done
  3. A much more fluid workforce. Tech workers can change jobs more easily than most of the workforce

In regards to point 3, a technology worker’s job mobility–especially in high tech hubs–has always been high. Anyone with the right technical job skills can move from job to job, placing loyalty to technology above loyalty to a company. This has led technology leaders to adjust their management style to be softer, more people-focused, and more supportive in comparison to other managers as a means of attracting and retaining good workers for their projects. 

These 3 realities are just the tip of the iceberg–it can get complicated! Other commonalities include no micromanagement (obviously) and good communication on the leader’s behalf. Salary is not a big motivator but you need to keep intelligent people focused in order to innovate and take chances. We (tech workers) want a vision, we want a big picture, and we need to know our value and place in achieving strategic company goals. 

Managing technology workers is different than managing and leading other employees. What the Google project did was, instead of taking even the best ideas or someone else’s “best practices” to implement, it went directly to staff and asked, “What do you want your manager here at Google to do?” 

The complexity of leading a team doesn’t just stop at leading individuals; managers need to take into account a variety of other aspects, like collaboration, tools, work location, time zones, languages, interpersonal dynamics, and emotional intelligence. You may need to foster collaboration across time zones and continents with people you’ve never met face-to-face, and you need to make sure that the work continues humming along at speed. So, to answer my original question: Of course managers matter! But you cannot allow yourself to get a reputation as a paper-pushing, process-driven authoritarian. And it has to be authentic-you have to believe in people-focused, servant leadership at your core. If you come across as being fake, you are done. Being a leader is hard! Let’s just acknowledge that.

The Evolution of Leadership

As this 4-year Leaders Pulse series draws to a close, I reflect back on the initial need for this series:

  1. Leading technology/knowledge workers is different
  2. Old management techniques don’t work
  3. Teams today are more complicated than ever

These leadership changes are no longer confined only to knowledge workers. These ideas that started to surface in the knowledge-worker world in the 1960s have become ingrained across other generations and work categories. I took my first cues on these topics from the groundbreaking work published by Peter Drucker in the 1970s and the Leading Geeks by Paul Glen In 2002. After years of managing and leading tech teams, I am thankful for those books even more!

For me, the summary of leading knowledge workers is a flip from command-and-control supervisor to servant leader. Command and control leadership is authoritative in nature and takes a top-down approach; here, executives/management make all the decisions and workers floor instruction, power is reserved to management. Innovation is absent.  In contrast, servant leadership is a leadership philosophy in which the leader’s main goal is to serve their team; servant leaders share their power and measure success with growth and development as opposed to outcomes. Also referred to as being a people-centered leader, their main job is supporting the team, clearing obstacles, working for the team, and giving them visibility and clarity on the company or product vision in order to keep them focused and productive.

I see this fundamental flip from top-down, command-and-control manager to servant leader has already happened in tech companies. I do sometimes see that there are issues in other industries when dealing with their knowledge workers. For example, how banks manage bankers is different from how the bank needs to manage a software development team. It is often a work-in-progress and just-in-time design and often not well understood. 

What we know is:

  1. We need to better understand today’s tech worker’s needs.
  2. To be relevant as a servant-leader, you need to meet your team’s needs, not have them be subjects of our process. 
  3. Leading teams is different from leading individuals. Knowledge workers demand autonomy. Tech organizations are in constant need of innovation, which requires smart, creative, and motivated teams who understand and buy into the vision, and have the psychological safety to experiment or simply try things without worrying about judgment or criticism. 

Now, back to the Google Projects and their findings. 

How Data Makes This Study Unique

Google’s study is unique. We have a study from a tech giant in the heart of Silicon Valley that is based on data. And that’s what makes this study so different: it’s data-driven; it’s a large research and data investigation project.

From Googe’s study, their data-driven approach for management is based on 3 parts:

  1. Take on status quo
    •  Compare highly rated managers against low rated managers.
    •  What did they do well? What did they do poorly?
  2. Change
    • Change feedback. Training. Work with managers
  3. Institutionalize the good practices

And then socialize the findings.

Google claims to be unique, and rightfully so. But, so is your company. So it is my company. Every company is unique! This uniquity is exactly why the idea of best practices is a sticky one. Some people live by the idea of best practices, but many people do not. I am on the “Not” side, as is this Google research. The strict idea of best practices is taking someone else’s ideas–no matter how good, bad, old, or new they are-and trying to implement them at your organization. You can see what the issue at hand is: What worked for their organization might not work for your organization despite being labeled a best practice.

The modern approach to best practices derives from the Lean Principle of Amplify Learning or continuous learning. We need to continuously learn, always improve, and look for innovation. Perhaps you take an idea developed by someone else (i.e. best practice) and try to implement it at your organization. Do it, see how it goes, and take feedback. See what worked and what didn’t work, and then tweak it to make it work better for your organization. It also aligns with the Agile cultural idea of Fail Fast: Try something, and if it works, great! If it doesn’t work, quickly figure out why and get rid of it to try something else. This modern approach is about constant learning, fine-tuning, and innovating.

What I’m getting at here is that there are no absolute answers and everything is context-driven. When reading about Google’s Project Oxygen, it regularly stresses the value of data and how unique their environment is. The whole environment for people working on a software development team at Google is different than for example, a regulated financial service company, a medical device (hardware/software), or medical record (software) product company.  As well as, we all know, it’s different working in software development at a startup. Google, being the tech giant they are, understood that their work environment was very different than many companies. For as much as every company wishes that their software development team was Lean and had an entrepreneurial, aggressive, startup mentality, that rarely works across large organizations with large product portfolios.

This all sounds good, being a modern and adaptive leader. But, at the same time, there is the example of SCRUM. The inventors, Jeff Sutherland and Ken Schwaber can be pretty particular about their framework (don’t call it a process!). You either do it or you don’t. SCRUM is not pick-and-choose what you want to do or not do. There are lots of ScrumButts and AgileFalls teams suffering under bad implementations of a great framework. They may not use the phrase best-practice, but you implement the practices or you don’t.    

Be careful trying to fit a square peg in a round hole. Don’t take cookie-cutter *best practices* and impose them on tech workers. That will never work. Your organization is unique, believe it or not. It may share some characteristics and behaviors with other companies, but in the end, your implementation will need to be customized and unique.

Google’s Findings

After conducting the project, Google found that these are the 10 Oxygen behaviors of Google’s best managers (behaviors 3 and 6 have been updated and behaviors 9 and 10 are new:

  1. Is a good coach
  2. Empowers team and does not micromanage
  3. Creates an inclusive team environment, showing concern for success and well-being
  4. Is productive and results-oriented
  5. Is a good communicator — listens and shares information
  6. Supports career development and discusses performance
  7. Has a clear vision/strategy for the team
  8. Has key technical skills to help advise the team
  9. Collaborates across Google
  10. Is a strong decision-maker

In addition to Project Oxygen, Google also conducted Project Aristotle, which aimed at finding what set successful teams at Google apart from the others. They learned that there are five key dynamics that set successful teams apart from other teams at Google:

  1. Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
  2. Dependability: Can we count on each other to do high-quality work on time?
  3. Structure & clarity: Are goals, roles, and execution plans on our team clear?
  4. Meaning of work: Are we working on something that is personally important for each of us?
  5. Impact of work: Do we fundamentally believe that the work we’re doing matters?

Interpreting Google’s Findings

The 5 keys to a successful Google team are the most interesting findings to me. This may be because the 10 behaviors of “good managers” are similar to Drucker’s recommendation for managing knowledge workers, as well as Paul Glen’s Leading Geeks-none of these were new to me, and I actually take some issue with a few. But, the 5 keys for teams are more difficult. They take more risk and more investment from leaders and managers. Take, for example, just the first dynamic-Creating a work environment, communication, team dynamic, collaboration where it is psychologically safe for individuals or the team to work and innovate and get things wrong. Smart people getting things wrong in the name of speed and innovation (which are absolute key ingredients for today’s tech workers) and dealing with potential fallout, criticism, coaching and the rest of the team’s reaction could be a book unto itself. These 5 keys are ideals. They are goals for me as a leader. They are ideas everyone can start today. I have been doing them (or at least, trying to) for a long time, and I always find that I have more work to do. It always needs more time, effort, tuning, support. I am still learning how to get better at it, for example, in a 100% work from home team-which is a stark reality of 2020!  

Making Your Own ‘Project Oxygen’

Every organization is unique. It is with this idea some folks at Google did research and implemented change. They talked to staff through manager reviews and found out what they liked, disliked, wanted, and did not want about their managers. Then, this team put it all together to get their findings.

If you are thinking of making some changes, you need to get data. To take someone else’s findings from a unique organization and implement them at your unique organization may not work. You need a project. Do interviews, surveys, and assessments. Figure out what the staff needs and wants. Try to keep opinions out until the facts come in. This is a large part of the consulting work that I normally do: getting to the bottom of what problems really are.

If you are looking to implement some of these ideas from Google Project Oxygen or any of the ideas from the vast array of leaders post articles I’ve written over the years- good for you! That’s why I bring them up. But you also have to look at the underlying dynamics or situation as to why this change is necessary you can’t come and put a Band-Aid on top of a shattered wrist without fixing the broken-bone problem down below. This is a fact-finding and fact-facing process.

If there are issues with managers or leaders in your company and you want to start an improvement project,. good! Just know that it can be difficult and a lot of work.  Also, some organizations may not want to look very deeply into team dynamics and team job satisfaction because they normally unearth some other problems.

The one main unique Contribution from Google’s whole project oxygen is its reliance on data. Not guesses. Good for them!

Go for it! Get help but go for it

Summary

Managing tech workers and leading tech teams is quite unique in comparison to other types of workers–and even other knowledge workers! I have been writing this column for 4 years now in order to relay my experience as a tech manager, as well as recommendations to help. My experience managing and leading teams in software development have been heavily influenced by Peter Drucker and Paul Glen’s landmark work in Leading Geeks. The well-publicized Google Project Oxygen and Project Aristotle are unique in their application of, in my opinion, the work of Drucker and Glen in that their findings and implementation are based on research and data specific to their unique work environment and the staff it attracts. For them, it’s not theory–it’s data. Tackling a research staff project and discussing new or renewed leadership ideals and goals is absolutely essential on so many levels, especially today, due to new generations of knowledge workers who are both the same and different from Drucker’s knowledge workers of the 1970s and 1980s. Furthermore, after the shock of COVID-19 and the potential new normal of working from home (WFH) for everyone, managers need to know exactly how to communicate effectively and efficiently with their teams in order to achieve their organization’s goals. 

I have been conducting research for companies on teams, practices, individuals, and processes for a few decades: It can be rewarding, fulfilling, frustrating, and political. People may be all in favor of “process improvement” and “modern management thinking”–until it gets to how they can improve themselves as a leader. If you plan to attempt a “Project Oxygen” or ”Project Aristotle” at your unique company, my advice to you is to get help. It’s a major undertaking. But, the results and changes stemming from the project can be extremely valuable. After all, Google seems pretty successful.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

LogiGear Magazine – February 2012 – The Training Issue If you’re having trouble viewing the PDF in your browser, right-click on the link above and select “Save Link As”. The PDF will then be downloaded as a file viewable in Adobe Acrobat.
Emotional Intelligence is largely seen as being more important than IQ when it comes to being a great leader. Explore the ways EI can affect both leaders and team dynamics in this first part of a 2 part series. Part 1 of a 2 – Part Installment “If you show people you don’t care, they’ll ...
One of the difficulties of being a Software Tester is that when you’re doing your job really well, it’s unnoticeable! Unlike Software Developers, who are creating a product that will then be seen by management, Software Testers create tests that will help validate that the product is working correctly. When we do a great job, ...
HR issues will negatively impact team dynamics. HR can send shivers down the spine of many Tech Team Leaders. They are a complicated set of topics, especially for people and technology. Geeks have always posed unique issues and many small tech companies and start-ups do not have a strong centralized HR team but continue to distribute ...
Michael Hackett   Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ...
Michael Hackett   Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ...
The ownership of quality has evolved, don’t get left behind Welcome to our new feature in LogiGear Magazine! We will be doing a column in each issue on current topics and how to manage, deal with, and support your team through them. This first installment of Leader’s Pulse is about making the move to DevOps. This ...
  Karen N. Johnson is a longtime active contributor to the software testing community. Her work is often centered on helping organizations at an enterprise level. Karen’s work is often focused on helping teams and organizations improve quality overall. Her professional activities include speaking at conferences both in the US and internationally. Karen is a contributing author ...
HR issues can be detrimental to a work teams productivity. So it’s important to have HR knowledge and a resource to help you navigate these waters. Handling “HR issues” well may in fact save your life and build your career. I have a friend who works at a Silicon Valley Tech/Media company. No, not a ...
Michael Hackett   Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ...
From vague user stories to differences in personal styles, learning how to deal with ambiguity is important for tech leaders. My first Manager in Testing was the famous author, Cem Kaner. He taught me many things that still impact my work decades later. One quote from him that has always stuck with me is: “Software projects ...
One of the most common challenges faced by business leaders is the lack of visibility into QA activities. QA leaders have a tough time communicating the impact, value, and ROI of testing to the executives in a way that they can understand. Traditional reporting practices often fail to paint the full picture and do not ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe