Executive Summary

Any leader in any field who has been around a while has seen what happens when “The Boss” only hires people who think exactly like them, agree with them, never question them, and yet are extremely loyal. You end up with a highly dysfunctional team, which does not cultivate the best and brightest ideas, and instead relies heavily on whatever “The Boss” thinks about a topic, strategy, goal, etc. And all of the key leaders and the rest of the organization fall in line, in a “Groupthink” mentality, otherwise they are quickly forced out of the organization.

The alternative approach is to create an environment where it is Safe for the individual to put forth their own ideas or suggestions on how to approach a particular problem, or if they have a concern about a specific direction. Likewise it is important for individuals to come at a problem or strategy from different perspectives, as this takes the diamond in the rough and polishes it into a true jewel. In this article we will discuss several common mistakes to avoid, things to encourage, and methods you can use to get the best out of your team.

‍

The Trap: Technology Leaders who Hire People who know Less than they Do

As Software Developers, Architects, DBA’s, System Administrators, QA Engineers, etc. our power is based on our technical knowledge and technical experience. As such, we want to know as much as we can about a specific area, programming language, architectural method, etc. And then not unlike other areas within the organization, we will promote (or hire) someone into a position as an IT manager for the first time.

The “Trap” is that as a Manager your Power Base needs to be broader and cover other Talents and Attributes, instead of being solely focused on your own Technical Knowledge. Things like Team Building, Performance Evaluations, Hiring & Disciplinary Actions, Budgets, Contracts, Motivating Others, Solving Problems the team has, etc.

But new IT Managers often don’t realize this and some never learn this lesson. So, they frequently will hire new resources who actually know LESS than they do about a particular Technical Topic. And by doing so, creates an enormous drag of the performance, productivity, and quality of work that the Team produces. They are doing this, because they want to protect their Power Base, and what they’ve been known for up until this point in their career.

As seasoned Leaders, we need to coach new IT Managers, and sometimes even override their hiring preferences to ensure that they don’t fall into this Trap.  As a Leader, we know that we want to hire individuals who know more about a particular Technical topic than we do. We want them to bring up new ideas and concepts that we weren’t aware of, or don’t know all of the details.

By doing so, we can develop and build World Class Teams.

‍

Role Perspectives

Every Role has a different perspective on the Team. And to come up with the best ideas, concepts, and a high quality solution, it is important to constantly encourage everyone on the team to present their perspective. On every Technical Team you may have any combination of the following Roles:

IT Executive (CIO/CTO), Director or Manager

• Business Strategy.
• How does this Project or Initiative support the Business.
• Ensuring that the Business is Sponsoring this Project / Initiative.
• Gaining approval from the Steering Committee or Board.
• Evaluating Build vs. Buy Decisions.
• Negotiating Contracts.
• Evaluating the Technical Capabilities of any Vendor.
• Tracking the overall status of the Project.

‍

Project Manager or Scrum Master

• Team Facilitator.
• Planning all of the Details for the Project.
• Solving Impediments as they come up.
• Constantly measuring, monitoring, and reporting progress.
• Identify and mitigate any risks.
• Ensure that the Team is moving forward.
  

One other aspect of their Role is to know when to “Pull the Plug” and recommend ending a Project, if it is not physically doable given the constraints (resources, time, technology, or scope). This is an extremely important part of their Role, as it can mean the difference between taking a $100,000 loss or a $7,000,000 loss.

The former is, “I’m glad you caught this early,” moment. The latter is, “You should probably start updating your resume, as this is going to the Board.”

‍

Business Analyst or Product Owner

• The “Voice of the Customer.”  Whether that is an internal or external customer.
• They are the Translator between the Business and the Technical Team.
• How is the best way for me to gather the information from the Business using a variety of techniques?
• And how is the best way to explain, document, and diagram this to the Technical Team, so that it can be turned into actionable information they can work with?
• This is an extremely CRITICAL Role and perspective on the team, and is normally a fairly senior individual.
• Communication (verbal & written) and approachability is very critical in this Role, as they will be working with everyone at some point.

‍

Technical Lead

This is your key Technical Architect, who has the difficult task of “Herding Cats”, as every Developer and Engineer has their own perspective on what is the best approach, design pattern, table structure, etc. They will have to sift through all of the noise, to make the best or most optimal decision based on numerous factors - many of which are not purely technical in nature.

They have to strike the right balance between having an ideal technical architecture and getting the Project / Product done on time and with the resources one has.  It is possible to over engineer something, so you need to watch for this.

‍

User Interface / User Experience Designers

• The “Voice of the User”.
• What User Persona’s are there?
• What does each Persona do within the Application?
• How are they going to use it?
• What information are they going to input?
• And what information are they trying to get out of it?
• What devices are they going to use?
• What color schemas, fonts, font styles, background images, logos, etc. are going to be used?

‍

Front-End Software Developers

• Based on the UI requirements, what is the best way to implement the User Interface, the various controls, action bars, menus, etc.?
• What devices and form factors does the UI need to support.
• How can we reuse or leverage any of the UI constructs, so we don’t have to build them from scratch each and every time?
• What tools and libraries can we use or leverage, so we don’t need to build them in the first place?
• What data input validation rules are there?
• How do we display error conditions or failures?
• How do we handle Session State and do we need to?
• For actions and events, what service Endpoints or processes do we need to call?

‍

Back-End Software Developers

• Are we designing a Micro-Services layer with various End-Points?
• How is the best way for us to reuse these Micro-Services?
• How is the Application going to interact with the Database and Storage layer?
• Are we going to use a Service Bus / Message Queue, or an Orchestration Engine?
• How are we going to integrate with other Applications and/or 3rd Parties?
• How are we handling Security and authentication Tokens?
• What information needs to be encrypted?
• How do we handle Error Handling and Failures?  Where are we logging this information?

‍

Quality Assurance Engineers

• How am I going to test the Application and the various Requirements?
• Can I automate any of the testing?
• What is the “Happy Path?”
• What are the most common negative Use Cases?
• What “Edge Cases” might we encounter, even if we decide not to Test for them?
• What are the expected results and acceptance criteria for every Test Plan / Requirement / User Story?
• How are we going to conduct Regression Testing?
• What test data needs to be obfuscated during Testing?
• How do I create a realistic Data Sample for Testing?
• Are we going to conduct Internal or External Beta Testing?

‍

Data Analyst / Database Designers

• What types of Database and Storage platforms are we using for the System?
• Is this a traditional normalized Relational Database? A No-SQL Database?  A Mainframe flat hierarchy structure?
• Where are Reports being run against?  Are we using an Operational Data Store, a Data Mart, a Data Warehouse, something else?
• What standard processes do I need to perform - daily, weekly, monthly?
• What standard “Jobs” are normally run?  Are they optimized for the database structure we are using?
• Are the Developers following best practices in their SQL Code?  Can it be optimized?
• What information needs to be encrypted?

‍

DevOps / System Administrators

• Cloud Hosted Systems‍
• Which Environments are in the Cloud (Dev, QA, Stage, Prod)?
• Are we using Containers or a collection of all of the virtual components for a given Environment?
• How do I access it (Credentials), and who has Root Access to the Overall Cloud Infrastructure?
• Are we using a Load Balancer to quickly scale the Prod Environment, if we need to?
• What are we using as a Firewall / Intrusion Detection?

• System Processes‍
• How do I maintain and support the whole Application every day?
• What standard processes do I need to perform - daily, weekly, monthly?
• Where are the areas where the Application can break, and how do I repair it?

• Deployments‍
• What is the process for deploying new Patches or Releases?
• How do I roll-back a Patch or Release, if it fails?

• System Monitoring & Recovery‍
• Are there any automated tools that I can leverage to proactively detect problems or instability and fix it before it causes a failure?
• What SLA’s do I need to maintain with my Clients (internal or external)?
• What are my backup and recovery procedures?

‍

‍Tier-II Support Engineers

• What common problems might Users encounter?
• What data errors can occur?
• What processing issues can occur?
• How difficult is the application going to be to support?
• Another “Voice of the User”.

‍

Encouraging Women in IT

This is extremely important for several reasons:

1. Women and men do think differently, and we have different perspectives.
2. Encouraging diversity, brings with it new ideas, thoughts, concepts, and solutions.
3. On average, women will make up around 50% of your actual users, so knowing what they like and don’t like in a product can make or break your future release.
4. And we often forget that in the early days of Software Development, that women made up a large portion of software developers.
   

Meet US Navy Rear-Admiral Grace Hopper:

Here are a few of her accomplishments:

• 1944 - Worked on the Mark-I Mainframe Computer.
• 1946 - her Team found a moth or “Bug” in the Mark-III that they were working on.  So, she coined the Term finding a “Bug” in the Computer.
• 1949 - Assisted in the Development of UNIVAC, the first large scale computer produced.
• 1952 - Developed the first Compiler, converting English terms into machine code - everyone at the time thought it couldn’t be done.
• 1959 - Helped create COBOL - a programming language in use even today.
• 1970’s - created standards for QA Testing of software programming.
• USS Destroyer Hopper is named after her.
• National Medal of Technology.
• Presidential Medal of Freedom.

‍

Trying Out a Different Hat

This technique was originally developed by Edward Bono, in his book, “Six Thinking Hats,” and has been used by various teams to create innovative solutions, business strategies, and approaches.

Purpose

The goal of the exercise is to have everyone on the team provide a different perspective to solving a particular problem.‍

Materials

• Six different Colored Hats - for larger Teams, you will need 2 of each Color.
• Alternatively use colored Post-It-Notes.
• This works very well for Virtual meetings.
• And have the individuals stick their Post-It-Note on their Shirt / Blouse or Forehead, so everyone know which Role / Hat they are playing.

• Meeting Room (or virtual conference).
• White board or flipchart to write on.

Hat Colors

The Hat Colors represent different perspectives that need to be considered. You can come up with your own definition for each Hat Color, just as long as everyone agrees what it is in advance. The following are the definitions that I’ve used previously, slightly modified from the original:

BLUE HAT

Area: Executive.

Perspective & Approach:

• What is our Strategy?
• Focus on the Big Picture
• What is our Roadmap?
• How will we Manage this Project / Initiative?

WHITE HAT

Area: New Ideas, Positive, The Good Person, Doing the Right Thing.

Perspective & Approach:

• Why we should do this.
• What are all the Pros for making this Decision?
• Is this an Ethical or Moral thing to do?
• You are Voting For this, unless it is Unethical.

RED HAT

Area: Marketing, Sales.

Perspective & Approach:

• How will our Clients “Feel” about this Decision?
• Will they like it or will they be upset?
• Will it entice them to buy our Product?
• If Internal oriented, how will our Employees “Feel”?
• Will this improve our overall Brand Impression?

BLACK HAT

Area: The Devil’s Advocate, What can Go Wrong.

Perspective & Approach:

• What are all of the Negative Things that could happen, even if remote?
• Critically evaluate each Option (without getting personal)
• You want to respectfully represent the Opposition to an Idea
• How is this better than XYZ we already do?

YELLOW HAT

Area: Analysis, Facts and Information.

Perspective & Approach:

• Focus on the Facts and Information
• What do we know?
• How do we know it?
• What is our Confidence Level in the Information?
• What don’t we know?
• What other Information do we need to research and find out?

GREEN HAT

Area: Finance, Money, Revenue, Profit.

Perspective & Approach:

• What is it going to Cost?
• How much Revenue will it generate?
• How much Costs Savings will there be?
• Is this a CapEx or OpEx expense?
• How long will it take for us to get a Return on our Investment?
  

Process:

• Decide on the Topic in Advance:
• Include an Agenda with the key items to discuss.
• Send a Calendar Invite for either 30 to 90 minutes.

• At the Meeting the Facilitator will assign the Hats out initially:
• DO NOT Assign a Hat to someone who already has this Role
• For example, don’t give the GREEN Hat to someone in Finance or Accounting
• You want people to think outside of their normal Role in the organization
• Everyone puts on their “Hat” - or alternatively you can use colored Sticky Notes or some colored paper to identify who is representing which Hat.

• The Facilitator (Hatless) Starts the Meeting:
• Topic #1‍
• Facilitator discusses the Topic briefly for 2 minutes.
• When Problem Solving typically the order would be:

1. BLUE HAT
2. YELLOW HAT
3. WHITE HAT
4. RED HAT
5. WHITE HAT
6. BLACK HAT
7. GREEN HAT
8. BLUE HAT

• Of course, you can mix up the Order any way you wish, so long as everyone gets at least 2 minutes to present their “Hat” perspective.
• Ideally, you would want to do this as a type of Lightning Round, so that you don’t linger on a particular point for too long, and keep things moving.
• Capture the key ideas and concepts that are raised on the White Board or Flipchart, etc.

• Topic #2:
• Facilitator discusses the Topic briefly for 2 minutes.
• Then asks the Team to switch Hats. The easiest way is to pass it to the Right or Left around the Table. If you are doing this remotely, then the facilitator will need to organize this.
• Repeat for each other major Topic or Decision Point.

• Do an overall Review of the Ideas that came up:
• Note the key concepts that each Hat raised.
• And let the team know when everything will be written up and sent to the entire team.

‍

Conclusion

In this blog article we’ve covered:

• Why multi-disciplinary teams are key to getting high quality output from a Team.
• How “Groupthink” can dramatically hurt your ability to innovate and produce.
• The “Trap” of the Junior Leaders hiring less skilled Technical Individuals than themselves.
• The perspectives of the various Roles on your Technical Team.
• Encouraging women in IT.
• Exercise: Trying on a Different Hat.
  

We hope that you have enjoyed this article and found it valuable.

Thank you, David Annis.