Link Technology to Your Long-Term Business Goals: How to Use Technology to Mobilize Your People, Strategy and Operations 1484282078, 9781484282076

Link the use of technology with long-term business goals to optimize the core elements in your organization: people, str

113 10 6MB

English Pages 224 [206] Year 2022

Report DMCA / Copyright

DOWNLOAD PDF FILE

Table of contents :
Table of Contents
About the Author
Part I: People
Chapter 1: Teams and Divisions
Why Divide Teams?
Parallel Triumphs Over Sequential Work
Summary
Chapter 2: Hiring
Referrals
HR Sourcing
Consultants
Recruitment Drives
Summary
Chapter 3: Upskilling
Training Plan
On-the-Job Training
Summary
Chapter 4: People Management
One-on-One Meetings
Reviews and Performance Management
Individual
Reporting Manager
Team’s Performance Measurement Officer
Structures
Summary
Chapter 5: Rewards and Recognition
Quarterly Rewards
Ad Hoc Rewards and Recognition
Summary
Chapter 6: People Processes
Manager-Reportee Employee Relations
Promotions and Remuneration
Summary
Chapter 7: Rituals
Daily Scrum
Retrospective
All-Hands Meeting
Summary
Part II: Strategy
Chapter 8: Objectives and Key Results
What Are OKRs?
Why OKRs?
Summary
Chapter 9: Setting Up OKRs
Defining OKRs
Growth Warriors
OKR Grooming
Summary
Chapter 10: Linking OKRs to Strategy
Team Alignment and Linking Objectives to Long-Term Strategy
Sustaining OKRs: Setting a Weekly Cadence
Summary
Chapter 11: Ensuring Execution of Strategy
OKR Tools
Check-in Meetings
Summary
Chapter 12: OKR as a Continuous Process
Champions
Stretch Goals
Summary
Part III: Operations
Chapter 13: People and Processes
Requirements
Tools
Prioritization
Reviews
Summary
Chapter 14: Prototyping
Innovative Projects
Quick Turnarounds
Long-Term Projects
Summary
Chapter 15: Scaling Operations
Agility vs. Scale
Team Culture
Technical Skills of the Team
Nature of the Problem
Business Constraints
Alerts and Flags
Tech-Driven Operations at Scale
Summary
Part IV: Technology
Chapter 16: Technology’s Role in Helping Business Needs
Tech Organization in Relation to Business Units
Tech Team Structure
Role of Engineering Managers and Architects
Role of Tech Leads
Responsibilities of a Software Engineer
Responsibilities of a Quality Assurance Lead
Responsibilities of a Quality Assurance Engineer
Summary
Chapter 17: Technology Stack
Front-End Stack
What Is HTML?
What’s in the “Head” or Metadata in HTML?
What Are the Elements of HTML?
CSS Properties
What Is the Box Model?
What Is Bootstrap?
Why Use Bootstrap?
Why Use JavaScript?
What Is React.js?
ECMAScript
Backend Technology
What Is ExpressJS?
What Is REST?
Databases
MongoDB
Postgres SQL
Summary
Chapter 18: Key Processes and Rituals of Technology Teams
Communication
Problem Solving
Innovation
Change Management
Scrum for Tech Team
What is Scrum from a Tech Team’s Angle
Scrum Master
Scrum Master Responsibilities and Services to the Product Owner
Scrum Master Responsibilities Toward the Development Team
Product Owner
Scrum Team
Communication Cadence
Escalation Process
Overall Review Process
Summary
Chapter 19: Business Analytics and Its Importance in Scaling and Execution
Strategy
Determine Business Objectives
Collect and Analyze Information
Identify Core Business Processes
Construct a Conceptual Data Model
Locate Data Sources and Plan Data Transformations
Implement the MVP Plan and Deploy in Production
Benefits
Independence
Upskilling
Cross-Functional Collaboration
Data Democratization
Tactics and Phases
The Data Stack Architecture
Data Flow
Metadata Layer
The Hero of the Story: Microservices
Benefits of Microservices
Precise Scaling
Experimentation and Lower Risk
Independently Deployable
Microservices Architecture Options
Database Integration
Synchronous API Calls
Winner: Extract, Transform, and Load
Summary
Part V: Processes
Chapter 20: Data Security
Business Challenges
Data Security Strategies
Physical Security of Servers and User Devices
Access Management and Controls
Application Security and Patching
Backups
Employee Education
Network and Endpoint Security Monitoring and Controls
Security Plan
Roles and Responsibilities of a Security Team
SLA for Bug Reports
Security Audits
Benefits of IT Security Audit
Requested Evidences and Correlation
Key Documents and Evidence That Will Be Requested
Summary
Chapter 21: Why Do Businesses Fail?
Solving Process Problems
RACI
DACI
Don’t Do Ad Hoc
Requirements Gathering
Epics, User Stories, and Tasks
Follow Sprints
Daily Scrum
Summary
Chapter 22: Exceptions to Processes: Good or Bad?
Exceptions in the Moon Landing
What Can Driverless Cars Learn from the First Moon Landing?
Not All Stories End Well
Why Do Businesses Seek Exceptions?
Management by Exception
Setting Objectives
Assessing Performance
Analyzing Your Deviations
Resolving Exceptions
Summary
Chapter 23: Processes as a Speed Booster, Not a Speed Breaker
What Is Business Process Management?
How Can Process Mapping Help?
Areas for Process Improvement
Customer Success
Finance
Human Resources
Operations
Sales and Marketing
Summary
Chapter 24: Are Processes Sacred?
What Is a Business Process?
Why Business Process Is Important
Different Types of Business Process Design
Business Process Examples
What Is the Most Important Business Process?
What Makes a Good Process?
Business Process Management
Summary
Chapter 25: Conclusion
Productivity
Financial
Marketing
Collaboration and Learning
Customer Service
Index
Recommend Papers

Link Technology to Your Long-Term Business Goals: How to Use Technology to Mobilize Your People, Strategy and Operations
 1484282078, 9781484282076

  • Author / Uploaded
  • Praz
  • 0 0 0
  • Like this paper and download? You can publish your own PDF file online for free in a few minutes! Sign Up
File loading please wait...
Citation preview

Link Technology to Your LongTerm Business Goals How to Use Technology to Mobilize Your People, Strategy and Operations ― Praz

Link Technology to Your Long-Term Business Goals How to Use Technology to Mobilize Your People, Strategy and Operations Praz

Link Technology to Your Long-Term Business Goals: How to Use Technology to Mobilize Your People, Strategy and Operations Praz Bangalore, Karnataka, India ISBN-13 (pbk): 978-1-4842-8207-6 https://doi.org/10.1007/978-1-4842-8208-3

ISBN-13 (electronic): 978-1-4842-8208-3

Copyright © 2022 by Praz This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Shiva Ramachandran Development Editor: James Markham Coordinating Editor: Jessica Vakili Copy Editor: Kim Wimpsett Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza, New York, NY 100043. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail [email protected], or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail [email protected]; for reprint, paperback, or audio rights, please e-mail [email protected]. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at www.apress.com/bulk-sales. Printed on acid-free paper

Table of Contents About the Author���������������������������������������������������������������������������������xi

Part I: People�������������������������������������������������������������������������������1 Chapter 1: Teams and Divisions�����������������������������������������������������������3 Why Divide Teams?�����������������������������������������������������������������������������������������������3 Parallel Triumphs Over Sequential Work���������������������������������������������������������������7 Summary��������������������������������������������������������������������������������������������������������������8

Chapter 2: Hiring����������������������������������������������������������������������������������9 Referrals���������������������������������������������������������������������������������������������������������������9 HR Sourcing���������������������������������������������������������������������������������������������������11 Consultants���������������������������������������������������������������������������������������������������������12 Recruitment Drives���������������������������������������������������������������������������������������������12 Summary������������������������������������������������������������������������������������������������������������15

Chapter 3: Upskilling��������������������������������������������������������������������������17 Training Plan�������������������������������������������������������������������������������������������������������17 On-the-Job Training��������������������������������������������������������������������������������������������19 Summary������������������������������������������������������������������������������������������������������������20

Chapter 4: People Management����������������������������������������������������������21 One-on-One Meetings�����������������������������������������������������������������������������������������22 Reviews and Performance Management������������������������������������������������������������24

iii

Table of Contents

Individual�������������������������������������������������������������������������������������������������������24 Reporting Manager����������������������������������������������������������������������������������������25 Team’s Performance Measurement Officer���������������������������������������������������25 Structures�����������������������������������������������������������������������������������������������������������26 Summary������������������������������������������������������������������������������������������������������������27

Chapter 5: Rewards and Recognition�������������������������������������������������29 Quarterly Rewards����������������������������������������������������������������������������������������������29 Ad Hoc Rewards and Recognition�����������������������������������������������������������������������31 Summary������������������������������������������������������������������������������������������������������������32

Chapter 6: People Processes��������������������������������������������������������������33 Manager-Reportee Employee Relations��������������������������������������������������������������33 Promotions and Remuneration���������������������������������������������������������������������������35 Summary������������������������������������������������������������������������������������������������������������36

Chapter 7: Rituals�������������������������������������������������������������������������������37 Daily Scrum���������������������������������������������������������������������������������������������������������37 Retrospective������������������������������������������������������������������������������������������������������38 All-Hands Meeting����������������������������������������������������������������������������������������������40 Summary������������������������������������������������������������������������������������������������������������41

Part II: Strategy�������������������������������������������������������������������������43 Chapter 8: Objectives and Key Results�����������������������������������������������45 What Are OKRs?��������������������������������������������������������������������������������������������������45 Why OKRs?����������������������������������������������������������������������������������������������������������47 Summary������������������������������������������������������������������������������������������������������������48

Chapter 9: Setting Up OKRs����������������������������������������������������������������49 Defining OKRs�����������������������������������������������������������������������������������������������������49 Growth Warriors���������������������������������������������������������������������������������������������51 iv

Table of Contents

OKR Grooming�����������������������������������������������������������������������������������������������������52 Summary������������������������������������������������������������������������������������������������������������53

Chapter 10: Linking OKRs to Strategy������������������������������������������������55 Team Alignment and Linking Objectives to Long-Term Strategy������������������������55 Sustaining OKRs: Setting a Weekly Cadence������������������������������������������������������57 Summary������������������������������������������������������������������������������������������������������������58

Chapter 11: Ensuring Execution of Strategy���������������������������������������59 OKR Tools������������������������������������������������������������������������������������������������������������59 Check-in Meetings����������������������������������������������������������������������������������������60 Summary������������������������������������������������������������������������������������������������������������62

Chapter 12: OKR as a Continuous Process�����������������������������������������63 Champions����������������������������������������������������������������������������������������������������������63 Stretch Goals�������������������������������������������������������������������������������������������������������64 Summary������������������������������������������������������������������������������������������������������������65

Part III: Operations��������������������������������������������������������������������67 Chapter 13: People and Processes�����������������������������������������������������69 Requirements������������������������������������������������������������������������������������������������������69 Tools��������������������������������������������������������������������������������������������������������������������75 Prioritization��������������������������������������������������������������������������������������������������������75 Reviews��������������������������������������������������������������������������������������������������������������77 Summary������������������������������������������������������������������������������������������������������������80

Chapter 14: Prototyping���������������������������������������������������������������������81 Innovative Projects����������������������������������������������������������������������������������������������81 Quick Turnarounds����������������������������������������������������������������������������������������������84 Long-Term Projects���������������������������������������������������������������������������������������������86 Summary������������������������������������������������������������������������������������������������������������89 v

Table of Contents

Chapter 15: Scaling Operations����������������������������������������������������������91 Agility vs. Scale���������������������������������������������������������������������������������������������������91 Team Culture�������������������������������������������������������������������������������������������������������95 Technical Skills of the Team��������������������������������������������������������������������������������96 Nature of the Problem�����������������������������������������������������������������������������������������96 Business Constraints������������������������������������������������������������������������������������������97 Alerts and Flags��������������������������������������������������������������������������������������������������98 Tech-Driven Operations at Scale�������������������������������������������������������������������������99 Summary����������������������������������������������������������������������������������������������������������101

Part IV: Technology������������������������������������������������������������������103 Chapter 16: Technology’s Role in Helping Business Needs��������������105 Tech Organization in Relation to Business Units�����������������������������������������������105 Tech Team Structure�����������������������������������������������������������������������������������������108 Role of Engineering Managers and Architects��������������������������������������������������108 Role of Tech Leads��������������������������������������������������������������������������������������������109 Responsibilities of a Software Engineer�����������������������������������������������������������110 Responsibilities of a Quality Assurance Lead���������������������������������������������������110 Responsibilities of a Quality Assurance Engineer���������������������������������������������111 Summary����������������������������������������������������������������������������������������������������������112

Chapter 17: Technology Stack����������������������������������������������������������113 Front-End Stack������������������������������������������������������������������������������������������������113 What Is HTML?��������������������������������������������������������������������������������������������113 CSS Properties���������������������������������������������������������������������������������������������115 What Is Bootstrap?��������������������������������������������������������������������������������������116 Why Use JavaScript?�����������������������������������������������������������������������������������118 What Is React.js?�����������������������������������������������������������������������������������������118

vi

Table of Contents

Backend Technology�����������������������������������������������������������������������������������������119 What Is ExpressJS?�������������������������������������������������������������������������������������120 What Is REST?���������������������������������������������������������������������������������������������120 Databases���������������������������������������������������������������������������������������������������������121 MongoDB�����������������������������������������������������������������������������������������������������121 Postgres SQL�����������������������������������������������������������������������������������������������121 Summary����������������������������������������������������������������������������������������������������������122

Chapter 18: Key Processes and Rituals of Technology Teams����������123 Communication�������������������������������������������������������������������������������������������������124 Problem Solving������������������������������������������������������������������������������������������������124 Innovation���������������������������������������������������������������������������������������������������������125 Change Management����������������������������������������������������������������������������������������126 Scrum for Tech Team����������������������������������������������������������������������������������������127 What is Scrum from a Tech Team’s Angle����������������������������������������������������127 Scrum Master����������������������������������������������������������������������������������������������128 Scrum Master Responsibilities and Services to the Product Owner�����������128 Scrum Master Responsibilities Toward the Development Team������������������129 Product Owner���������������������������������������������������������������������������������������������129 Scrum Team�������������������������������������������������������������������������������������������������130 Communication Cadence�����������������������������������������������������������������������������130 Escalation Process��������������������������������������������������������������������������������������130 Overall Review Process�������������������������������������������������������������������������������131 Summary����������������������������������������������������������������������������������������������������������131

Chapter 19: Business Analytics and Its Importance in Scaling and Execution�����������������������������������������������������������������������������������133 Strategy������������������������������������������������������������������������������������������������������������134 Determine Business Objectives�������������������������������������������������������������������134 Collect and Analyze Information������������������������������������������������������������������135 vii

Table of Contents

Identify Core Business Processes���������������������������������������������������������������136 Construct a Conceptual Data Model������������������������������������������������������������136 Benefits�������������������������������������������������������������������������������������������������������������138 Independence����������������������������������������������������������������������������������������������138 Upskilling�����������������������������������������������������������������������������������������������������138 Cross-Functional Collaboration�������������������������������������������������������������������138 Data Democratization����������������������������������������������������������������������������������139 Tactics and Phases�������������������������������������������������������������������������������������������139 The Data Stack Architecture�����������������������������������������������������������������������������139 Data Flow����������������������������������������������������������������������������������������������������140 Metadata Layer��������������������������������������������������������������������������������������������140 The Hero of the Story: Microservices����������������������������������������������������������������143 Benefits of Microservices����������������������������������������������������������������������������144 Microservices Architecture Options�������������������������������������������������������������145 Summary����������������������������������������������������������������������������������������������������������150

Part V: Processes���������������������������������������������������������������������151 Chapter 20: Data Security�����������������������������������������������������������������153 Business Challenges�����������������������������������������������������������������������������������������153 Data Security Strategies�����������������������������������������������������������������������������������154 Physical Security of Servers and User Devices�������������������������������������������154 Access Management and Controls��������������������������������������������������������������155 Application Security and Patching���������������������������������������������������������������155 Backups�������������������������������������������������������������������������������������������������������155 Employee Education������������������������������������������������������������������������������������155 Network and Endpoint Security Monitoring and Controls����������������������������155 Security Plan�����������������������������������������������������������������������������������������������������156 Roles and Responsibilities of a Security Team�������������������������������������������������156 viii

Table of Contents

SLA for Bug Reports������������������������������������������������������������������������������������������157 Security Audits��������������������������������������������������������������������������������������������������158 Benefits of IT Security Audit������������������������������������������������������������������������159 Requested Evidences and Correlation���������������������������������������������������������160 Key Documents and Evidence That Will Be Requested�������������������������������160 Summary����������������������������������������������������������������������������������������������������������161

Chapter 21: Why Do Businesses Fail?����������������������������������������������163 Solving Process Problems��������������������������������������������������������������������������������163 RACI�������������������������������������������������������������������������������������������������������������164 DACI�������������������������������������������������������������������������������������������������������������165 Don’t Do Ad Hoc������������������������������������������������������������������������������������������������166 Requirements Gathering������������������������������������������������������������������������������166 Epics, User Stories, and Tasks���������������������������������������������������������������������167 Follow Sprints���������������������������������������������������������������������������������������������������167 Daily Scrum�������������������������������������������������������������������������������������������������168 Summary����������������������������������������������������������������������������������������������������������170

Chapter 22: Exceptions to Processes: Good or Bad?������������������������171 Exceptions in the Moon Landing�����������������������������������������������������������������������172 What Can Driverless Cars Learn from the First Moon Landing?�����������������������173 Not All Stories End Well�������������������������������������������������������������������������������������174 Why Do Businesses Seek Exceptions?�������������������������������������������������������������175 Management by Exception��������������������������������������������������������������������������������175 Setting Objectives���������������������������������������������������������������������������������������176 Assessing Performance�������������������������������������������������������������������������������176 Analyzing Your Deviations���������������������������������������������������������������������������177 Resolving Exceptions�����������������������������������������������������������������������������������177 Summary����������������������������������������������������������������������������������������������������������179 ix

Table of Contents

Chapter 23: Processes as a Speed Booster, Not a Speed Breaker����181 What Is Business Process Management?���������������������������������������������������������181 How Can Process Mapping Help?����������������������������������������������������������������182 Areas for Process Improvement������������������������������������������������������������������������182 Customer Success���������������������������������������������������������������������������������������183 Finance��������������������������������������������������������������������������������������������������������184 Human Resources���������������������������������������������������������������������������������������185 Operations���������������������������������������������������������������������������������������������������188 Sales and Marketing������������������������������������������������������������������������������������189 Summary����������������������������������������������������������������������������������������������������������191

Chapter 24: Are Processes Sacred?�������������������������������������������������193 What Is a Business Process?����������������������������������������������������������������������������193 Why Business Process Is Important������������������������������������������������������������������194 Different Types of Business Process Design�����������������������������������������������������195 Business Process Examples�����������������������������������������������������������������������������196 What Is the Most Important Business Process?������������������������������������������������197 What Makes a Good Process?���������������������������������������������������������������������������197 Business Process Management������������������������������������������������������������������������198 Summary����������������������������������������������������������������������������������������������������������199

Chapter 25: Conclusion���������������������������������������������������������������������201 Productivity�������������������������������������������������������������������������������������������������������202 Financial�����������������������������������������������������������������������������������������������������������203 Marketing����������������������������������������������������������������������������������������������������������204 Collaboration and Learning�������������������������������������������������������������������������������204 Customer Service����������������������������������������������������������������������������������������������205

Index�������������������������������������������������������������������������������������������������207 x

About the Author Praz currently works on building and managing solutions that are used by

sales, marketing, logistics, and operations at Byju’s. He previously ​ran his own company, Wyzebulb, that solved business process automation problems. His solutions have helped automate business processes and have increased the efficiency of many teams, enabling them to focus on other core activities. He also previously worked at Nokia R&D and Babajob. Vidyashree DC: https://www.linkedin.com/ in/vidyashree-dc-598722209/

xi

PART I

People

CHAPTER 1

Teams and Divisions When I told the CEO of the company I was working for that I would be starting my own company, this is what he told me: “You have hired and nurtured people, but you have never fired anyone. Don’t be hasty in starting up on your own, but you need to learn people management and understand how you can build and nurture a tech team.” Did I listen to his advice? No! Had I taken this advice, I would not have got a crash course in learning the art of team management by doing it. Would have happened over a longer period of time. I’m beginning this chapter with the premise that people management is not something that can be taught. I’ve tried to summarize my experiences of people management so when you are going through the same experiences, it might help you to tackle things in a better way. You need to learn it through firsthand experience. And you need to keep one thing in mind: empathy. In my case, as my team grew, the culture I set when the team was small spread to the new set of people as they were hired.

Why Divide Teams? In older, more traditional ways of working, business requirements came in from multiple departments of the organization to a singular tech team. The tech team would make a list of these requirements and then follow sprint processes to implement them one by one. The teams at this time were monolithic, and teams tended to work sequentially. Before the agile © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_1

3

Chapter 1

Teams and Divisions

methodology came in around 2010, to free up teams taking their own decisions without having to wait for the hierarchy to approve of it, the companies were waiting for hierarchy based approvals. This was true not just in tech, but in every other function of the business. Pre-agile times, when we expected that a certain project needed to be done in a certain number of days, we worked in a sequential manner, as shown in Figure 1-1.

Figure 1-1.  Sequential execution of tasks This put us in silos. We started becoming too short-sighted, and we couldn’t foresee roadblocks that might come at a later stage in the project. A better approach is to do parallel development. But how is parallel development possible? 4

Chapter 1

Teams and Divisions

You can divide your teams into atomic divisions, as granularly as possible. If you have a big project coming up, start planning for modules for this project before it starts. Let’s look at an example of a website that lets the user create their own workflows and automate a bunch of repetitive tasks. We’ll call this website “Awesome automation platform.” Figure 1-2 shows how the logged-in view of the website might look.

Figure 1-2.  Wireframe of the “Awesome automation platform” website The best way to begin working on this post-logged-in view of the platform would be to first identify the mutually exclusive areas of the website (Figure 1-3) and divide it into these modules: 1. Profile: This includes login/logout/registration. 2. Apps: This section contains all the apps available for creating automations on the platform. 5

Chapter 1

Teams and Divisions

3. Workflows: This is the core of the platform and will be the brain fueling it. 4. Integrations: This is the place where different thirdparty integrations are available. 5. Search: This is an easy-to-use search bar, which is fast. 6. Dashboard: This area has graphs and analytics of current usage and also shows suggested workflows.

Figure 1-3.  Identifying mutually exclusive areas to work on

6

Chapter 1

Teams and Divisions

Parallel Triumphs Over Sequential Work With the modules of the example website defined, we could come up with a team structure that can then kick off this project and parallelly take up the work (Figure 1-4).

Figure 1-4.  Parallel execution of work This will ensure that when the work begins, the teams will start delivering parallelly, instead of sequentially. Parallel development ensures autonomy for each team to deliver value and innovate (Figure 1-5).

Figure 1-5.  Parallel development of tasks

7

Chapter 1

Teams and Divisions

As you can see, it is important to create divisions/departments in the organization or the suborganization in a way that each team can execute parallely.

Summary Teams thrive when they have an identity and a purpose. It is important to create and maintain a vision for each team that is formed. For example, a scrum team could consist of seven to eight people with developers, quality assurance analysts, and automation engineerers, with a possibility of a dedicated or a shared project manager. Not doing so will lead to losing the focus for the project and alignment with the company’s goals. The vision will be the key to let the team operate independently and execute strategies quickly and efficiently.

8

CHAPTER 2

Hiring Hiring is hard. Hiring in tech is harder. Hiring good people in tech is even harder. Hiring good people in tech who actually stay on and contribute significantly to the product is much harder still. Hiring good people in tech who actually stay on, contribute significantly, and then help in hiring other good people, thereby building a network, is super hard. This chapter shows how I tried, failed, succeeded, experimented, and mixed and matched different approaches to build my tech team.

Referrals You know a guy who knows a guy who knows another guy (Figure 2-1). Referrals work most of the time. But never hire someone based solely on a referral alone. In my startup, I always followed certain protocols. My referrals were interviewed by the architect, his referrals by me, and so on.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_2

9

Chapter 2

Hiring

Figure 2-1.  Referrals Regardless of who recommends someone for a job at your company, always give a coding test. How much experience they have doesn’t matter. People who have made significant contributions at their previous companies may not always work out. The environment and culture in the current setting matter significantly. Will the person be able to adapt to this is the question you should always ask, even after they have joined your company. If you decide to hire someone who you know isn’t right or isn’t going to be able to adapt to the new situation, the biggest loser will be you. That being said, I have indeed succeeded in hiring people based on a referral. When they were given much more responsibility than what they had before, they moved above and beyond and shined brighter than anybody else. Some people continue to surprise me. The bottom line is that there's no right answer to referrals. Some referrals work; some don't. The chances of someone working out or not working out are dependent on several factors, so ask yourself these questions before you judge a new hire as a success or a failure:

10

Chapter 2



Have you let them become accustomed to their new environment?



Have you given them enough time to adjust?



Have you taken them to the middle of the ocean and then left them to swim to the bank, or have you held their hand all along? This shows how easily they can cope with adversity.



Are they agile enough to adapt?



Are they willing to go that extra mile to do what it takes?

Hiring

As I’ve said, I’ve both made mistakes and had successes when I’ve blindly trusted referrals. After several debates about this, I’ve realized blind trust isn’t bad, but it needs to be balanced. Your colleagues will help you balance this, which is why you need diverse characters on each team. They can advise you while making decisions on hiring a certain referral candidate or even give the right feedback to the person directly.

HR Sourcing HR sourcing works pretty well when you are hiring continuously for open roles. It helps fill a lot of gaps that have been created because of your team growing and accepting a wider and more diverse array of requirements. I’ve seen it not work when we needed it urgently, mainly because people tend to make mistakes when they rush and end up interviewing a lot of candidates to fill a certain number of positions. It is best to work with HR over a period of time and help them grasp the role so the candidates can be filtered intelligently.

11

Chapter 2

Hiring

Consultants Specialized roles like architects, where the requirements are clearly defined, work well when given to consultants. Using consultants is helpful when you know exactly the role you’re looking for. Unlike in referrals and HR sourcing, where there are a lot of unknowns (such as can we hire this person for a different role than the one we are looking for?), that question doesn’t arise here. We are clear with the consultants on what role we are looking for, and they have precisely that set of skills needed. The process can be streamlined by using effective hiring tools (e.g. Hirect, Recruitee, Intervue etc.). Also, you can give each team’s lead the responsibility and ownership to hire on their own, which gives the team a lot of independence. The job descriptions of each team may vary due to the nature of work, and giving the right amount of independence lets them hire great talent from a pool of consultants.

Recruitment Drives Recruitment drives have been a revelation that I have personally taken advantage of. Especially during the covid-19 pandemic, hiring was difficult because people were adjusting to a fully remote culture. At my startup, we devised a plan to first come up with the additional workforce requirements for each team. Since we had an overview of the upcoming work that was going to happen, we extrapolated and came up with strategies to augment the resources. The people requirements were documented as shown in Figure 2-2.

12

Chapter 2

Hiring

Figure 2-2.  People requirements Once we had these requirements, it was time to extrapolate on how many candidates we expected to call for interviews. If we needed 12 resources, then Figure 2-3 shows the number of people we had to shuffle through the hiring process.

13

Chapter 2

Hiring

Figure 2-3.  Interview process Each time we did recruitment drives, we followed this structure, and it helped in understanding how many applications we could expect. The actual numbers can change from team to team, from company to company, and from process to process, but having these baseline numbers ready will help in augmenting resources and planning for the hiring drives. A hiring drive has these main steps: 1. Sourcing 2. Screening 3. Assessing 4. Onboarding Since I’ve covered the screening and assessment bits already in this chapter, let’s talk about sourcing. 14

Chapter 2

Hiring

In my startup, I did not have any set way of doing this except to use social channels and organic communication. We created flyers that could be posted on LinkedIn. We sent out mailers to the colleges we studied at where the placement coordinators would then ask the final year students to apply. What I’ve seen in recruitment drives is that though you get fresh employees, you can upskill and mold them in a way that suits the needs of your company. They are able to adapt and learn faster than you might imagine. Oftentimes they are the ones who go on to become the future leaders you can rely on.

Summary When I managed a team of 12 people at my startup, I would give them all the independence to do things the way they would want, and still processes were followed. Sprint planning, retrospection, and all the agile rituals were followed without me having to set up processes. That’s because the initial hiring was done carefully. What sets up the entire culture are those 10 initial people you hire. One mistake on those initial people, and there will be repercussions that are far reaching. The initial hires have to be handpicked. With that foundation of good people in place, the culture can be set up to ensure the next set of hiring will follow suit in terms of attitude.

15

CHAPTER 3

Upskilling There are two sets of people who need upskilling and training. •

Fresh graduates joining the team



Existing members of the team who need upskilling

The employees who are continually learning are the ones who will make a mark. They are the ones who go on to do wonderful things. They are the ones who inspire others to learn. Learning should be a continuous process. If each day we are unable to do and learn something new, then we are exactly the same person as we were the previous day. Humanity has progressed only because humans set out to learn and experience new things and because they are brave enough to embark upon new and unknown journeys. Nothing comes out of mundane, repetitive things. Hence, upskilling should be part of an effective tech-driven plan in any company.

Training Plan Team members do not always start out having equal amounts of know-­ how, both technically and functionally. There might be one person, probably the lead of the project, who understands most of the processes, and then there are usually a mix of technical experts and functional experts. A typical team starting out on a new project might look like Figure 3-1. © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_3

17

Chapter 3

Upskilling

Figure 3-1.  Team working on a new project Let’s consider this representation for a new app that the team is planning to develop. Now, let’s say there are several such projects that are happening in parallel in the company, so how do we ensure that the developer who is fresh out of college is able to understand what the business analyst, process specialist, and technical architect is saying? It happens only with an effective training plan. Day 1: Intro Day 2: IT & HTML Day 3: Bootstrap & Programming Day 4: Javascript Day 5: Frontend technologies Day 6 & Day 7: Backend technologies Day 8 & Day 9: Database technologies Day 10: Developer operations Day 11: Github/ code commit software Day 12: Full Stack Development Day 13: Agile & Testing Day 13 - 16: Project Planning & Development

18

Chapter 3

Upskilling

Ensure that every fresh graduate is taken through a full-fledged training at the end of which there is a real-work like project. This gives them confidence and then takes them through real tasks that they generally go through in an actual project.

On-the-Job Training If the same people who hired the candidates prepare the training material for on the job training, it makes it easy for the people joining to learn effectively because the training plan will suit the aptitude of the people who have been hired. The training plan preparation will differ from company to company and from project to project, but a typical one looks like the plan in Figure 3-2.

Figure 3-2.  A typical tech training plan

19

Chapter 3

Upskilling

On-the-job training has two approaches. Let’s assume that the task to be achieved is to cross an ocean; the training plan could be either one of these: •

Swim along with the trainee until halfway across the ocean. Let the trainee go the remaining distance on their own.



Swim along with the trainee halfway across the ocean and let them go the remaining distance on their own, but assure them that you are there to support them and to carry them if they get tired while swimming.

I’ve failed with the first approach before and now use the second approach. But at times, such as when you really need to test a person’s true capabilities, the first approach can come in handy. Still, do not use the first approach in mission-critical projects; instead, use it in projects where you or anyone else has the ability to rescue the project midway in case something goes wrong. If you have had an unpleasant experience in the past training employees, you might be hesitant to spend the time coaching them. For example, there have been multiple instances when I have trained someone for many months, but they ended up quitting eventually due to various reasons not in my control. These things hurt, especially when the projects that you trained them for now fall on you again. It can set you back by months, and you have to go through the process of hiring and training yet again.

Summary You will always have adversities in a team. Someone will leave, for example. There is really no way to avoid this, so it is always good to be prepared. You can train more people for a position if you have the chance to, rather than just one person. Be open to communication and catch early warnings or signs that will tell you what is about to happen. 20

CHAPTER 4

People Management People management is defined as a set of practices that encompass the end-to-end processes of talent acquisition, talent optimization, and talent retention while providing continued support for the business and guidance for the employees of an organization. People management needs patience and has to be done with positivity and heart. There is no single formula to effective people management, but there are frameworks and tools that can help us in creating a good environment for the people working with us. Effective people management is not just be conducive within the team but also outside of the team, and if done right, it can be pervasive and can affect the entire company in a positive manner. We need to help our co-workers find their rhythm, which will help them be at their productive best. This is different for different people. This can’t be done by you as a leader alone; hence, there should be certain processes set up that can help you in achieving effective people management.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_4

21

Chapter 4

People Management

One-on-One Meetings

Figure 4-1.  One-on-one meetings When we are tired, there are activities that we do to help us replenish our energy and drive. But sometimes, no matter what activity we do, we cannot replenish. This is what we call burnout. When employees face burnout, resentment sets in. This can happen to the best of us. It could be because of continuous hours of work or due to a bad day at work. One-on-one meetings are an effective tool to understand the current state of co-workers and stay on top of burnout. They can help people find get their rhythm back when it is lost. We can’t have everything we want, but during one-on-ones we can ask for what matters to us the most. One-on-one meetings are best done in a recurring manner rather than just once. Specifically, it is good to have a monthly one-on-one meeting with your immediate reportees and to coach your immediate reportees to do the same with their employees. There are a few things to keep in mind to have effective one-on-one meetings:

22

Chapter 4



Schedule the meeting.



Set expectations of the meeting.



Never be late to a one-on-one meeting.

People Management

During one-on-one meetings, always remember to ask about morale and then try to understand the employee’s current state of mind. It is also important to set expectations of excellence. Setting expectations helps to boost morale. Never shy away from recognizing the wins, however small they might be. Finally, taking notes helps you to come back to the next one-on-one meeting with a lot more clarity. End the meeting with the following: •

Make a list of action items.



Make sure to give coaching notes.



Set up a follow-up meeting.

To make one-on-one meetings more effective, it is important to ask a few open-ended questions. These are questions that can open the team members’ mind and let them speak freely. The manager should be listening intently, noting everything that the team member is saying. Imagine asking someone “If you were to design your own work, how would that look?” Such an open-ended question can allow people to imagine freely and share what they feel. Obviously, this situation is not reached in the very first meeting. People take time to open up. This is where the managers can make the other person comfortable by answering their own questions, allowing the other person to ask them anything, or maybe even repeating their own questions back to them.

23

Chapter 4

People Management

Reviews and Performance Management Why do we need a performance measurement process? “If we don’t know where we are going, any road will take us there.” We work and live in a performance-oriented environment. However, while the expectations of performance are plenty, opportunities to objectively measure the performance are limited. A process will enable managers and individuals to measure their respective individual and team performance and course correct on a real-time basis. The high-level objectives of this process could be to do the following: •

Bring clarity and objectivity to performance measurement.



Create a cycle of regular feedback for individuals.



Create an opportunity for an individual to assess the strength and improvement areas for themselves.



Make rewards and recognition an objective exercise.

What are the different roles in this process?

Individual The individual is the person whose performance is being measured. Your responsibilities include the following:

24



Follow the timelines of the process diligently.



Be ready for monthly check-ins with your managers.



Update your performance measurement sheets with relevant tasks.

Chapter 4

People Management



Ask your manager for a monthly check-in and a timely quarterly review.



Be open in your approach and seek feedback to improve your work.

Reporting Manager The reporting manager is the boss of the individual whose performance is being measured. Your responsibilities include the following: •

Follow the timelines of the process diligently.



Schedule and execute monthly check-ins and quarterly reviews with your team members diligently.



Provide full clarity on performance ratings for your team members.



Highlight the strength and development areas for your team members.



Prepare for your meetings in advance. Fill in your feedback in the respective sheets for your team members.

Team’s Performance Measurement Officer This is the designated person on the individual’s team who is responsible for carrying out the process seamlessly. •

Help individuals and managers to follow the set timelines. Make sure the teams and managers follow the timelines.



Help them understand the process or the performance measurement sheets. 25

Chapter 4

People Management



Answer their questions and clear their doubts.



Prepare the quarterly performance report for the senior members of the team.

Structures One of the core principles of putting in place a successful team is putting in place proper structures. These structures are not to bind people in shackles but rather to give them guiding principles so they can work effectively utilizing their strengths while improving on their weaknesses. To enable this, teams need to have the right set of people managers who can enable individual contributors to work effectively. In essence, the manager’s job is that their team gets the right information on time, gets the right resources on time, removes distractions and obstacles, and provides full clarity on objectives and expectations. In some cases, managers are doers too, but the more that the manager starts to do, the more the team becomes ineffective and dependent on the manager. This is where it typically leads into micromanagement territory. Hence, the right structure for the team can be thought of as pods working on assignments and engagements where each pod has a relevance of its own and a purpose of its own. Obviously, this relevance and purpose should be aligned with the larger relevance and purpose of the team or the company. More about this will be discussed in Chapter 18, Scrum team. To achieve this structure, managers need to be very clear about what their role is on the team. Horizontal leaders who manage multiple verticals help the vertical managers to create the right structures with the right managers to manage the pods. They create the right structures with the right managers to manage these pods, giving the managers with the right tools and freedom to work in their large or small pods.

26

Chapter 4

People Management

Once the managers learn the skill of managing multiple pods, they can groom others around and below them to do the same. As the team grows, the culture of creating these pods and enabling managers to manage the pods takes hold. Then, the formula just needs to be replicated again and again. Structures are often confused with hierarchies and control mechanisms. On the contrary, structures are flexible constructs that connect people together and keep them in sync for a common function. For these structures to work in the right spirit, the leaders must practice open and excessive communication, both in oral and written form.

Summary Meetings, reviews, and structures go hand in hand with processes. Processes span both tech and nontech aspects. A tech process ensures that the technical side of the company is taken care of, while the nontech processes like meetings and reviews ensure that the people side of things is well-managed. Either of them taking a backseat will lead to weak structures.

27

CHAPTER 5

Rewards and Recognition The key to maintaining good relations with people in a professional environment is to praise the extra efforts that people are putting in. This will encourage their growth and in turn impact the team’s development. This also means that the company matures because of the support provided by people who are encouraged to learn and grow. Recognizing employees in a consistent manner will go a long way to improving and sustaining good relations with employees. This chapter explains how to do it and cultivate it as a habit for the entire team.

Quarterly Rewards At my startup, we initially did not have a quarterly awards meeting. We would instead have an all-hands meet during which we would recognize the best performers on a more ad hoc basis. Not having a set criteria could lead to two things: •

The rewards being biased



The rewards not being taken seriously as only recently high-performing candidates could be chosen instead of more consistent ones

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_5

29

Chapter 5

Rewards and Recognition

This led us to come up with a quarterly rewards ceremony. Initially we combined all the teams and gave out rewards in the following categories: •

Performer of the quarter



Rookie performer of the quarter (for fresh grads)



Star performer of the quarter



Lead of the quarter

After a while, we realized it was apt to add more categories and be more specific when offering rewards as people then strive to win in a particular category of the award. Hence, we came up with the following categories: •

Mentor of the quarter



Rookie performer of the quarter (for fresh grads)



Code ninja of the quarter



Code reviewer of the quarter



Best lead, on-time delivery



Best lead, customer centricity



Automation roller

Being specific helps to recognize and reward core competencies. This also removes any ambiguity about why a certain person deserved a recognition. We also ensure that there is a special recognition given to people who mentor new employees and people who seek help. These are the people who make the team tick. Hence, our emphasis has always been on team mentors rather than on team managers. Especially in tech, the management of people is 5 to 10 percent of the job, while mentoring them is 90 to 95 percent of the work when you are a lead. Choosing who gets an award could be based on a poll that also gives more weight to the vote given by the lead or the senior members of the team. Once the rewards are given, it is necessary to give a certificate; Figure 5-1 shows an example. 30

Chapter 5

Rewards and Recognition

Figure 5-1.  Sample certificate These certificates can vary from company to company or from team to team, but the basic elements remain the same. You can use an online tool to create them based on the company’s theme or have an internal design team to quickly make you a template.

Ad Hoc Rewards and Recognition When we are working with tech tools that help us communicate and collaborate, it is easy to find integration tools that will help in giving on-­ the-­spot awards. We use a tool that is integrated with Slack that allows us to give a “Pat on the back” or kudos to people. Such features help co-workers recognize those who are helping them out when they are in need. It is important to then post the results of the people who have received the highest number of “Pats on the back,” as well as those who have given the highest number of “Pats on the back.” These “Pats on the back” can be replaced by any other cool name as well. But having this ad hoc recognition empowers co-workers and encourages them to praise co-workers.

31

Chapter 5

Rewards and Recognition

You can then consolidate the rewards given on a monthly basis on a leaderboard, which can inspire people to work toward an award. Figure 5-2 shows a sample leaderboard.

Figure 5-2.  Sample leaderboard of “Pats on the back” or kudos

Summary My company has sustained an awards ceremony over multiple quarters. The positive effect has impacted not just our own team but other teams as well. Employees look at these awards as something they want to earn because they see individuals posting their certificates on various social media platforms. The individuals on the team who win the award are then seen as someone who has gone above and beyond.

32

CHAPTER 6

People Processes For techies like me, coding and managing technology tools is the easiest part of work. People management for me happens through a lot of mistakes and learning. The one thing that separates techies from purepeople managers is the on-the-­ground reality. At the end of the day, only techie managers can measure the productivity of their employees, while improving employee wellness can be done through processes.

Manager-Reportee Employee Relations Always use a data-driven approach while dealing with employee relations. Opt for tools that will help get anonymous feedback from employees on a timely basis. Also make it transparent to the employees that the feedback is anonymous. Creating the right employee experience is difficult. It is even harder in remote and hybrid work settings. Moreover, annual engagement surveys look at the past year and leave unanswered questions. By the time managers can react to the feedback, the data is already stale.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_6

33

Chapter 6

People Processes

Leverage the help of employee experience tools or platforms that can help drive cultural change in a positive way. Agnya is an employee experience platform that makes it fun for employees to give actionable feedback that managers can implement. Such tools can help you achieve the following: •

Enable your employees to be lifelong learners by challenging them



Develop your managers into highly capable people leaders



Align your workforce toward the shared organizational values



Drive meaningful employee experiences through personalized interventions backed by data and insights

In times of remote work, you need to appreciate employees across teams and departments. This builds positive value and helps improve productivity. You need to ensure the following: •

Appreciate your teams by introducing fun into every day



Appreciate small and big actions alike



Reinforce your own values through peer recognition



Design and execute reward and recognition strategies to drive essential behaviors and outcomes

To ensure you collect timely and actionable feedback that is anonymous, you can deploy tools and collect continuous feedback. Specifically, you can do the following:

34

Chapter 6

People Processes



Remove friction points that cause employees to stop giving feedback



Collect employee feedback in the form of their natural experiences rather than a scale of 1–5



Enable feedback collection on platforms your teams use such as Slack, MS Teams, Google, or email



Make the entire organization part of the change process

Promotions and Remuneration This section is a detailed analysis of how an employee appraisal system could look. Ideally, everyone at the company will go through this process. When does a promotion happen? Here are the three scenarios of how a person can expect a promotion: •

Same designation: The employee will continue to work in the same role. The criteria for the appraisal would be: •





Performance (based on review process)

Same category but different designation: The employee gets a different designation but continues to be in the same category. The criteria for the appraisal would be: •

Performance (based on review process)



Designation change increment % (+x%)

Across category: The employee gets an opportunity to work in a different category, and there is a change in designation and role as well. The criteria for the appraisal would be similar to what is depicted in Figure 6-1: 35

Chapter 6

People Processes



Performance (based on review process)



Category shift increment % (+x%)

Figure 6-1.  Sample categories Having such a structure helps people strive toward the higher categories. It also ensures fair promotions to those who prefer to stay as an individual contributor rather than wanting to get into a management or leadership role. Transparency with promotions and remuneration always helps in building a healthy workplace environment.

Summary The workplace experience in the post-COVID world has been ever evolving. Effective employee relationships can be achieved only if we connect with the employees in a productive manner by setting up the right processes. We need to ensure that timely recognition, promotions, appraisals are given. Productive employees are happy about the workenvironment created not just because of the work that they are doing, but also because they are being cared for. This care will prove to be effective by the processes we set up. And the care gets multiplied if the processes we setup is transparent to the employees.

36

CHAPTER 7

Rituals Every team works at a certain rhythm, and maintaining that rhythm is possible by setting up rituals. Rituals are recurring events or activities that help build relationships. Some rituals are formal events that help keep track of multiple projects, while some are informal gatherings. Each ritual should have an agenda to make it productive. In a sprint team, the daily scrum, sprint planning, and sprint retrospection are mandatory to keep the rhythm of the team going. These are rituals.

Daily Scrum The daily scrum is not a status meeting. In this meeting, each team member speaks about three things. •

What they have done in the past day



What they are going to do in the next day



What they are stuck on and whether they need someone’s help

The last point is the main idea behind scrum meetings. It helps unblock any adversities that a teammate could be facing. Because this meeting is attended by peers from the same group, it helps everyone understand if there are dependencies that need to be addressed.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_7

37

Chapter 7

Rituals

At my startup, we generally have multiple scrum meets running for all the teams within the organization. •

Teams working on the same project and sprint where the scrum master is a project manager



Team leads working on different projects where the scrum master is a senior lead



Engineering leads working on multiple projects who meet up separately to call out blockers where the scrum master is either an architect or a VP of engineering



Special squads that are working on a project spanning multiple teams where the scrum master is a program manager from the business team

Having multiple scrum meetings helps ensure that each team operates independently and also collaboratively as each team’s representative is also part of the higher-level scrum meetings. The scrum master ensures that the meeting happens, but the members are responsible for conducting the daily scrum. The scrum master teaches the team members to keep the daily scrum within the 15-minute timebox. The daily scrum is an internal meeting for the scrum team. If others are present, the scrum master ensures that they do not disrupt the meeting.

Retrospective The sprint retrospective is a recurring meeting held at the end of a sprint used to discuss what went well during the previous sprint cycle and what can be improved for the next sprint. Figure 7-1 shows a sprint retrospective board.

38

Chapter 7

Rituals

Figure 7-1.  A typical retrospective board There are many ways to run a sprint retrospective. One of the most common is to use a start-stop-continue approach. Each team member is asked to identify the things the team should start doing, the things they should stop doing, and the things they should continue doing. These are questions commonly asked in a sprint retrospective: •

What went well in the sprint? Success in an iteration can be analyzed by looking at what was done differently to achieve it; who contributed to it and how; and what skills, training, or knowledge made a difference.



What went wrong in the sprint? The point is not to penalize the team or individual members but look at things that didn’t go according to plan, with a view of improving performance in the future.



What did we learn? What did the team learn in the sprint so that they can improve their way of working? 39

Chapter 7



Rituals

How should the next sprint play out? This will determine corrective actions to take in the next sprint, preventing the same mistakes from occurring and making successful actions a repeatable outcome.

All-Hands Meeting This meeting has to be as interactive as possible. The best way to make it interactive is by organizing multiple polls and surveys during the meeting. •

Always start with a set agenda and a plan about how the meeting will go.



Conduct polls that will help people participate by guessing on the various milestones that the organization has achieved. It could be guessing on the Year-on-year growth in terms of revenues or profits.



Have multiple fun activities planned for the meeting like “Pair and Share” breakout rooms.



Organize games like virtual escape rooms to set the initial buzz among the participants.



Let employees ask questions. Have enough time to listen to these questions. Many people ask important questions when they know that there are other people who are listening who might have similar questions but aren’t asking them.

All-hands meetings are useful as a company grows because everyone in the company gets the same information at the same time. All-hands meetings allow you to get your employees aligned on the company goals and strategy. Think of every member of your team as a vector. An all-hands meeting helps you point them in the right direction. 40

Chapter 7

Rituals

Talk about your company vision and mission, emphasize your values, and review how your company is doing in terms of achieving your goals. Especially when things get overwhelming, nothing boosts morale like talking about the highlights and giving a shout-out to the people who helped to achieve them.

Summary Achieving rhythm is not easy, especially if a team is used to not following these rituals. You should start the rituals as soon as a sprint team is formed. Eventually, when the team falls into a rhythm, the rituals can happen less frequently. Rituals help to keep the communication flowing. Every team member should communicate at least once during each ritual either through taking turns or through voting, thus making the whole process democratic. This will instill confidence and a sense of belonging to the team. The intangible benefits are long-term and impact the team’s culture greatly.

41

PART II

Strategy

CHAPTER 8

Objectives and Key Results Objectives and key results is a corporate planning/strategy execution framework being rapidly adopted by companies worldwide to drive business velocity. The word strategy can be difficult to understand, especially when it comes to front-line teams or early-career team members. More often than not, a company’s strategy is defined by a leadership team. At the end of endless hours of debate and PowerPoint presentations, the leadership team understands the strategy, but lower-level teams might have little or no understanding of how their roles are impacting the organization. Bridging this gap of mission to metrics is where objectives and key results (OKRs) come in, helping teams (not only leadership or managers, but our front-line teams) to focus on the outcomes that matter most to business. In this chapter, we’ll quickly review the basics of OKRs in the workplace and why they are needed.

What Are OKRs? You can think of OKRs as spear fishing as opposed to casting nets. When OKRs are practiced, teams are focused on a few outcome metrics that will move the needle in the organization, rather than the many “business as © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_8

45

Chapter 8

Objectives and Key Results

usual” ones (see Figure 8-1). As opposed to practices in the past, OKRs are written in teams, especially cross-functional teams (consider technology teams and business teams writing OKRs together!).

Figure 8-1.  OKR key parameters More often than not, in traditional practices of managing company performance, very little thought was given to setting goals. The methods were ad hoc and push-based and sometimes even templatized. In the past, teams would copy and paste OKRs that were irrelevant and look at them after the fact as a check box during an annual performance review. OKRs should not be just an individual review. As an organization and team performance framework, OKR inspires teams to set aspirational goals that impact the business the most. OKRs are also about driving consistency; when you start writing OKRs, it’s important to detail them at length and write high-quality ones. •

46

Objectives: Objectives are the qualitative statements; interestingly, they have words and no numbers (much unlike what you might have learned in the past). Objective statements must have business value and need to answer the question “What exactly are we trying to achieve in the next 90 days?”

Chapter 8

Objectives and Key Results



Key results: Key results are the high-velocity metrics. These are not the “business as usual” activities, but outcomes that will effect change. You can think about key results much like a GPS, moving you from point A to point B. So, when you frame key results, they must have the metric you want to measure to improve from A to B to X to Y.



Activities: OKRs makes a clear distinction between outcomes and activities. Activities are the to dos, sometimes the mundane ones. Most of them are needed, but may not add value to business. When you think about activities linked to OKRs, they are experiments in which teams are trying to move the needle on outcome metrics.

Why OKRs? What’s making thousands of startups, scaleups, and enterprises adopt OKRs? It seems like practically the whole world has gone hybrid post COVID-19. With distributed teams and the need for virtual collaboration, it becomes exceedingly difficult to manage the overwhelming set of tasks being thrown at us. With scale comes the need to hire new members, and giving them a sense of connection to the company purpose is not effective just through a townhall meeting or a leadership speech. The company’s purpose must connect the dots between what the employee does and the outcomes. In addition, CEOs are adopting OKRs due to business model pivots that they were forced to make, especially when consumer or customer behaviors have undergone a significant shift.

47

Chapter 8

Objectives and Key Results

Many others are looking at OKRs to drive accountability and ownership. Some look at OKRs to bring back agility and innovation, which are required for companies to stay relevant. Finally, organizations want to bring the intimacy back, be it with people or customers, and are using OKRs to bring in much required clarity on the “how.” The reality is with business model disruptions and CXOs under pressure to deliver, OKRs are bridging the gap between strategy and execution.

Summary OKR was pioneered by John Doerr, and this framework pairs the objectives you want to achieve with the key results you’ll use to measure progress. Goals then end up being tied to the day-to-day work. The knowledge of concepts stated in this chapter will be enough to get you starting using OKRs.

48

CHAPTER 9

Setting Up OKRs Before you introduce OKRs into your business, it’s important to understand how to induce change into how the team functions as a whole. OKR thinking requires a change to be organic and should then percolate up to everyone working with you. Once the thought becomes an inherent process, writing and executing OKRs becomes easy. As a result, achieving business goals will become process driven rather than being rote.

Defining OKRs The following steps show how you can change the thought process of the team to start using OKRs: 1. Every OKR rollout must have a sponsor. The sponsor is usually the CEO or the head of the function, depending upon at which level you introduce OKRs. Some organizations like to do full-scale organization-­wide rollouts, with the rest of the OKRs for select business groups or functions. The sponsor must make OKRs a conversation in leadership meetings, townhalls, and reviews. The sponsor must participate in setting the OKRs as they are the most important growth metrics.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_9

49

Chapter 9

Setting Up OKRs

2. Using OKRs is about bringing in consistency. Teams that are using OKRs must understand what they are, how OKRs are different from individual performance practices, and how the team writes and tracks OKRs. Teaching the fundamentals of OKRs can be done by internal coaches or external OKR coaches who are certified and trained on how to enable teams. 3. The sponsor and their team must be involved in setting the North Star OKRs for the rest of the teams to align with. If departments are using OKRs, then the department heads, leaders, and next-level team leads set the North Star OKRs. Remember in OKRs, less is always more. So, define no more than three objectives and three to five key results each. 4. The cross-functional team members come together to move the needle on the North Star metrics. These four steps will enable teams to collaborate effectively to achieve the objectives of the organization. For example, let’s say your North Star metric is to reduce dropout rates of a prospect exploring your website. Why? The intent, of course, is to have as many prospects as possible to select a plan and click Get Started or to contact your sales teams to start the onboarding process. We all know how important this is for revenue generation. But the business team can’t do this alone; it needs to collaborate with the technology team. Let’s give this cross-functional team a fancy name: the growth warriors.

50

Chapter 9

Setting Up OKRs

Growth Warriors The growth warriors have representation from the sales, marketing, product, and engineering departments. They need to solve a focused problem, which is “How do you reduce dropout rates from 70 percent to 40 percent in the next 90 days?” The growth warriors start by listing the existing challenges, which come in the way of achieving OKRs. Here are some examples: •

“We have no clear way of knowing who is visiting our website.”



“The content or its placement is not engaging enough.”



“We are not tracking the response time to those who place queries in the chat window.”



“We do not have enough bandwidth, and there seems to be just too many requests coming to the tech teams.”

The warriors set their objective statement after much deliberation: Deliver a kick-ass experience to prospects on our website to reduce dropout rates. The clear business value is to reduce dropout rates. The next step then is how to measure this. That’s where the following four key results (KRs) come in. They are the metrics that help determine if the inspirational objective has been met. •

KR 1: Reduce response rates to prospect queries from two days to ten minutes.



KR 2: Increase the average time spent on the website from one minute to three minutes.



KR 3: Reduce page load time from three seconds to one second.



KR 4: Reduce dropout rates from 70 percent to 40 percent. 51

Chapter 9

Setting Up OKRs

Each team is aligned as an owner to a specific KR and starts their work. No matter what the team does, the goal is to ensure customer satisfaction by working on these four KRs. Each team member focusing on their objective through the KR will ensure that the objectives are driven in a customer-centric manner.

OKR Grooming If you ask a Google employee, or Googler, about OKRs, you will often get the response that “it’s how we do business here.” That’s how ingrained it is in Google’s culture. OKRs require conditioning teams to accept managing by outcomes rather than managing by activities. Oh sure, activities are important, but ticking off feature builds, calling prospects, and meeting a partner will not move the business forward. These are the inputs, but the goal is to move on the outcome metrics. This is similar to growth warriors measuring reduction in turnaround time or making a prospect stay longer in their digital store. Teams need to understand that OKRs require selecting the right metric and not the easy-to-achieve metric. This mindset requires one to stretch their abilities. OKRs require a cross-functional collaborative mindset. The teams write the OKRs together and not in isolation or water-tight departmentalized structures, which plague many companies even today. Grooming is also for leadership team members. The command-and-­ control style of management is a deal-breaker in introducing OKRs. Here you are asking our teams to select metrics that can impact the business. The directive style should be replaced by a coach-led exploratory style, which encourages teams to select OKRs and experiment.

52

Chapter 9

Setting Up OKRs

Ultimately, what you expect out of OKRs as an exercise each quarter is the outcome. The OKR framework as an outcome-based tool will help drive a team’s actions every day (Figure 9-1).

Figure 9-1.  OKR as an outcome-based tool

Summary Because of how flexible the OKR framework is, you can write OKRs in a variety of ways. Like any goal, OKRs should be verifiable and measurable. You should think of OKRs as the pillar of your strategy for the next period of time. However, to set good OKRs, you also need to connect them to your day-to-day work.

53

CHAPTER 10

Linking OKRs to Strategy Team alignment is probably the secret sauce to having a successful OKR rollout. While this seems easy, imagine aligning teams at scale when you 5,000 employees or an enterprise where you have a hundred thousand or more! The very reason why OKRs are used is to align teams better. Teams cannot set OKRs without linking them to organizational strategy.

T eam Alignment and Linking Objectives to Long-Term Strategy Before you decide on your OKRs, your company must have a strategy. What is strategy? The easiest way to think about this is how David defeated Goliath. David of course was no match for the strength of the giant and needed to have a strategy to defeat him. The David and Goliath story today is a metaphor for the competition being bigger and stronger. For those who know the story, David was a shepherd boy who refused to wear an armor; instead, all he had was his sling that he used to ward away wild animals from his sheep. Goliath was completely armored and had his sword and javelins. But David’s strategy was clear: he wore no armor to reduce the

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_10

55

Chapter 10

Linking OKRs to Strategy

weight and keep himself swift, and he took down Goliath with just one slingshot between the forehead, which was not armored. At a company I worked at, we adopted OKRs in 2020 right after the pandemic took the world by surprise. It was an unprecedented time with no playbook. Going remote forever overnight required teams to first scramble to set up the basics correctly. We asked ourselves many questions. Do we have high Internet connectivity? Technology teams need high bandwidth for seamless VPN connectivity and remote infrastructure. Also, security is always on top of mind. How do we ensure data integrity when we went from two to four office locations to thousands of “work-­ from-­home” office stations? This was the time to move away from micromanaging and throwing things at the tech team to help them see the purpose of why we are doing what we do. For instance, employees asked these types of questions: •

“Why are reports being automated?”



“Why are we using Kafka for queue management?”



“What happened to our data migration project, and how did those efforts impact business?”

The engineering mindset is about solving a problem, yet very often we find that engineering teams do their jobs well with regard to stability, functionality, security, architecture, and code reviews but forget to see the big picture. Let’s take an example of my team at that point in time that was looking at the business technology side of things. The supply chain and digital lending team were the two key stakeholders for our team. These teams ensure that the promise made by the organization to the end customer is delivered on. This is against a backdrop of a string of complexities, including managing inventory, fulfilling orders, ensuring the logistics are seamless, and ensuring that supportive elements like credit are available at attractive 56

Chapter 10

Linking OKRs to Strategy

packages for customers to afford the product. Each business has a suite of applications that requires an army of engineers to deliver. That’s where we saw a bright spot for OKRs. Could we strengthen the collaboration, reduce ad hoc work, and give engineering teams the line of sight on business impact? The best way to get started was through a pilot. We onboarded a tool called Fitbots, an integrated OKR partner, with OKR coaching and platform support. The coaches first came in to deliver an overview on OKRs to us as the sponsors. The head of the business supply chain and myself had to accept the OKR framework before introducing it to our teams. With the clear value established in our minds, we selected a 15-member team to get into OKRs. Together we wrote our first set of OKRs. The pilot teams were trained with an OKR basics session and coached by OKR coaches on how to select the right OKRs. We initially selected just folks from the engineering teams to test the process. Over the next week, the teams came up with their OKRs. These were mostly from an engineering lens and were missing the flavor of business alignment. The intent was to get a feel of the process, rather than getting the OKRs perfect (also there is no such thing as a perfect OKR).

Sustaining OKRs: Setting a Weekly Cadence For OKR practitioners, you know what this is all about. OKRs borrow heavily from agile, and they need a cadence. Dedicating 30 minutes per week for your OKR check-in meetings can make your OKR rollouts successful. Each week, on the same day at the same time, the teams reported their progress to each other on their outcome metrics. During this meeting, KRs at risk started surfacing, and tagging us as sponsors also made us accountable to remove barriers earlier than later. 57

Chapter 10

Linking OKRs to Strategy

With the rinse and repeat nature of check-in meetings, at the end of 90 days, we came to the conclusion that business teams needed to be involved in the OKR reboot process. This involves resetting (literally resetting OKRs or priorities) for the next 90 days. This time it was as pods with business and tech teams. As teams practice check-in meetings, they start getting more efficient, and the meeting time can be reduced from 30 minutes to 15 minutes.

Summary The biggest benefit of OKRs comes when you can connect your daily work to your team’s strategic objectives. OKRs already begin to do that by connecting the objective to the key results that contribute to it. To get the most out of OKRs, take that benefit a step further: use an OKR tool that connects your daily work and regular projects to your company and business goals.

58

CHAPTER 11

Ensuring Execution of Strategy While you spend more time in strategy planning meetings creating solutions for all the business problems, it becomes really important to find a platform that can help you execute those strategies. OKR tools can facilitate smooth execution of such strategies because team and leadership objectives are aligned through regular check-ins and retro reviews of the past objectives.

OKR Tools Over the past few years, OKR tools have started gaining prominence as SaaS platforms. While startups with about 10 members can manage OKRs on spreadsheets, the complexity of getting different teams aligned and reporting in a consumable and real-time format is better managed by OKR platforms (e.g. fitbots.com). Before you select a platform to help you manage OKRs, look for some important aspects: •

Is the platform simple and intuitive for teams to adopt?



Can you track objectives, key results, and milestones with initiatives?

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_11

59

Chapter 11

Ensuring Execution of Strategy



Does the tool foster a culture of conversations, feedback, and appreciation?



Can teams collaborate either through the platform or by tagging each other for help and support?



Do leadership reviews happen with high-quality alignment boards?



Does the tool have reporting capabilities? For example, how many OKRs are associated with an individual, or can you do a team OKR review with one click?

Some OKR tools that are integrated with on-demand coaching to help your teams sustain and manage OKRs. The tool that we used was Fitbots, available at https://fitbots.com/. (Disclaimer: the content for the strategy chapters in this book was largely contributed by the CEO of Fitbots.)

Check-in Meetings Sustaining OKRs requires check points at different levels.

60



Team-level pod check-ins: Pods are a bunch of people identified from different teams who are driving specific projects.



Leadership level check-ins: These include reviewing the teams across multiple pods on progress of the objectives. To see if there are blockers and to address them.



Re-alignment: This is a significant OKR ritual that happens at the end of every quarter. Teams and leadership get together to discuss their progress and learnings of the entire quarter to better strategize for the next quarter.

Chapter 11

Ensuring Execution of Strategy

What really happens during check-in meetings, leadership reviews, and end-of-quarter reviews? Figure 11-1, Figure 11-2, and Figure 11-3 explain the process in more detail.

Figure 11-1.  Weekly POD check-in questions

Figure 11-2.  Biweekly leadership meeting questions 61

Chapter 11

Ensuring Execution of Strategy

Figure 11-3.  Ninety-day retro reboot questions

Summary OKR platforms help to simplify the complexity of cross-team alignments and provide project/objective updates in real time to the concerned stakeholders. Weekly check-ins by the pod and leadership team can help employees understand the overall progress and figure out any gaps/ blockers in the fulfillment of the company’s business objectives.

62

CHAPTER 12

OKR as a Continuous Process Once your organization adopts the OKR framework, it becomes imperative to fulfill the OKRs by a certain time frame for the organization to grow. Since the OKR process involves many stakeholders, this task of driving the process across the different teams is done by OKR champions. OKRs are not just goal setting; they are more about “stretch goal” setting. Stretch goals provide a new dimension to the level of commitment, effort, and performance by uncovering hidden strengths, giving rise to new opportunities.

Champions As teams adopt OKRs, it ceases to be a framework and becomes more ingrained in “how we function as a team or business.” In fact, it becomes part of the organizational culture. This is where the role of OKR champions comes in. Champions can be internal OKR champions overseeing the entire OKR rollout or team champions/scouts who are responsible for ensuring the team or pod OKRs are on track.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_12

63

Chapter 12

OKR as a Continuous Process

Before you select a champion for your team, here are some traits: •

The champion must be enthused about OKRs.



The champion should be knowledgeable about the products and do extra reading to ensure they are up to speed about the current technology and stack that can help them in improving the product they are working on.



The champion should onboard new members into the team and ensure they undergo an OKR basics training.



The champion chairs all the OKR team meetings, asking powerful questions to keep the team on course.



The champion is much like the coach, who asks the team whether the OKRs are stretched enough and, if any blockers persist, whether they be resolved.



The champion represents their team in leadership meetings and for progress reports.

Ideally, the champion on a team is not the senior-most member/ manager but a high-potential enthusiastic future leader.

Stretch Goals Is your OKR really stretched? This is often a question we ask ourselves and our teams. The way to look at OKRs is that they are not the Goldilocks ones. Remember, Goldilocks the little girl with the curls who wanted to eat the porridge that was “just right.” OKRs are not about the “just right” goals; they are about the stretched and aspirational ones. While selecting your OKRs, ask yourself these questions: Is this the best we can do? Would this really move the business needle? If we didn’t practice OKRs, would we still be doing this? 64

Chapter 12

OKR as a Continuous Process

In OKR lingo, a stretch goal is the high-effort, high-risk goal in the calculated pursuit of 10x opportunities. As Measure What Matters writes, “Conservative goal setting stymies innovation. And innovation is like oxygen: You cannot win without it.” Stretch goals were used by Google to overcome email data storage limitations with Gmail in the early 2000s. However, stretch goals don’t always have to be about unlimited email data storage. They can also be about ordinary work taken to extraordinary levels. To improve, a team must rethink problems and ask harder questions. Anything less doesn’t provide enough competitive advantage. When implemented correctly, stretch goals work to stimulate peak performance on teams and encourage taking calculated risks rather than stifling them. Stretch goals can inspire a new level of commitment, effort, and performance by uncovering sometimes hidden strengths. Uncovering these strengths reveals new opportunities.

Summary Roles and goals are prerequisites in the process of driving successful OKRs. Goals need to be “stretched” to the extent that they uncover new levels of commitment and performance among the teams, leading to more innovations and opportunities. Once goals are defined, identifying the right set of people to drive OKRs across teams becomes necessary. OKR champions help to achieve the job of educating the teams about the team’s and company’s objectives and ensure that the team is on track.

65

PART III

Operations

CHAPTER 13

People and Processes Many companies start out with chaotic, unstructured execution but then move to a smooth process-driven execution. In between the two ends is when you see the processes evolving. This evolution is driven by the people within. To introduce processes, there have to be people who have experienced the benefits of these processes before. These people will then take the others along the long and arduous journey of setting up each process. Oftentimes new processes will meet resistance, but in the end the processes will prevail. The “Project management” processes for technology-driven companies need acceptance from all the employees of the company. The management, the mid-level managers, the operations team, the sales team, the marketing team, and the product team have to adhere to and respect these processes. In this chapter, we talk about the requirements and prioritization processes.

Requirements The Johari window is a technique that helps people better understand their relationship with themselves and others (Figure 13-1). It was created by psychologists Joseph Luft (1916–2014) and Harrington Ingham (1916–1995) in 1955 and is used primarily in self-help groups and corporate settings as a heuristic exercise.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_13

69

Chapter 13

People and Processes

Figure 13-1.  Johari window Johari window explains why effective requirement gathering can tackle the blind spots about the product we are developing. If you take a close look at the Johari window, you’ll see these four areas (Arena is known to everyone, so there’s no discussion needed on that):

70



Arena: These are traits that both the requirement giver and the requirement executor know well about.



Blind spot: These represent what a requirement giver perceive but the requirement executor does not.



Facade: These are things the requirement giver are either unaware of, or that are untrue but for the requirement executor is aware of.

Chapter 13



People and Processes

Unknown: They represent behaviors or motives that no one participating recognizes—either because they do not apply or because of collective ignorance of these traits.

These areas need discussing, debating, and understanding before approaching any project. The blind spot, facade and unknowns constitute 75 percent of the project’s understanding. That means only 25 percent of the product’s features are known to both the requirement giver and the requirement executor. Requirements prioritization allows business teams to become independent of envisioning requirements without having to seek time for meeting about each requirements separately. Prioritization allows for enlisting and discussing the business priorities of each requirements. •

Business teams can propose and get newer features released in less time as communication will be more structured and documented.



Business teams can understand different priorities of other business teams and help reprioritize the tasks that need immediate attention.



Requirement prioritization meeting will ensure no communication is lost in mails/groups/channels as all prioritized requirements can be seen in the requirement prioritization meetings and these can be discussed and understood in one meeting.

Most of the requirements at the time of writing by the stakeholders are in raw format and focuses on the outcome of the requirement itself than discussing the overall company metrics that these requirements drive. Requirements written in raw format asks from the people who are executing these requirements to understand the metrics that would be driven because of executing the requirements. 71

Chapter 13

People and Processes

As shown in Table 13-1, a requirements document is owned by a stakeholder who documents the need for a certain feature or a product and details of the plan of execution. Each requirements document should have multiple actors who will play their part, as explained in Table 13-1.

Table 13-1.  Metadata in a Typical Requirement Document Target release

01-02-1975

Epic

Driving customer visits

Document status

Draft

Document owner

Business analyst 1

Designer

Designer 1

Tech lead

Lead 1

Technical writers

Business analyst 1, Product manager 1

QA

Quality assurance specialist 1

Objective

To change the color of a banner that will drive the increase in installs by x%

A requirements document also needs to encompass the following elements:

72



Clearly written objective with metrics that the requirement intends to drive



Success metrics that drive the objective



Assumptions that the stakeholders have made



Milestones



Requirements broken into smaller chunks



Open questions that the stakeholders might have that they bring to the prioritization discussion

Chapter 13



Anything out of scope of the requirements



Stretch goals of the requirements as a bonus



User interaction and design

People and Processes

Generally, when writing requirements, we tend to go with one sentence such as “Change the color of the banner from green to red to make more people notice it.” By quoting a not well written requirement, the below paragraph is trying to correct it. Here is how we could do write a requirements document from this requirement: •

Objective: To increase the number of clicks on the banner by 5 percent by changing the color from green to red.



Success metrics: Increase daily paid users by 2.5 percent.



Assumptions: Red is more striking; hence, people are more likely to click it.



Milestones: First run this as an A/B experiment on 5 percent of the users, and once it is successful, then turn it on for 100 percent of the users. Hence, there are two milestones to this project: the experiment phase and the launch phase.



Requirements: a.

Change the color of the banner from green to red and launch it as an experiment for 5 percent of the users and share the result.

b.

Measure the results of the experiment on two criteria. Did the test version of the experiment increase the number of clicks by 5 percent and increase the number of paid users on a daily basis by 2.5 percent? 73

Chapter 13

c.



People and Processes

Based on the results of the previous point (b), go ahead and launch it for 100 percent of the users. If the previous point (b) is not statistically significant, then shelve the experiment.

Open questions: a.

Will the color be considered as an error? How do we get user feedback?

b.

How can we get analytics for this while the experiment is running?



Out of scope of the requirements: This is supposed to be done only on one of the identified pages and not on all pages.



Stretch goals of the requirements as a bonus: Have an easy way to turn on/off the experiment without having to make code changes in production.



User interaction and design: Use a wireframe of the web page.

If you read through the previous requirements, there is no ambiguity about any of the requirements written. The requirements cover all aspects and allow the team to implement the requirement with no further questions. The requirements are clear, and when the team implementing them comes across something they are not sure of, they will then add it to the comments and ask questions during the prioritization meeting. Over-communicating when it comes to requirements documentation is better than under-communicating and letting the team figure things out on their own. There are several tools that can help in gathering and documenting the requirements process easily, which we will discuss in the next section.

74

Chapter 13

People and Processes

Tools There are multiple tools for consolidating requirements by business teams. You can choose one depending on what is suitable for the current situation your organization is in. I have used Confluence as a tool in a large setting. But I’ve used many other tools like Trello, Asana, Notion which are lightweight for smaller teams. Each tool has its own advantages and disadvantages. You’ll want to zero in on a tool based on the size of the team and the complexity of the project. After all, the tools are only as good as the people using them. The process after choosing a tool is as follows: 1. Requirements are written in the tool. 2. Every follow-up will be done in the tool. Email follow-ups will change to the tool. 3. Have pre-sprint meetings biweekly. Select a specific day for each team. This means that there is no need to schedule multiple meetings with developers and other stakeholders; there is just one meeting to discuss and agree priorities. 4. Engineering leads will review the documents written before the designated day and propose any edits that will be frozen before the prioritization meeting.

Prioritization The main purpose of prioritizing tasks is for the stakeholders to come up with an ordered list of tickets for consideration by the implementing team. Each function in the organization makes a case by sending their representative. The representative then gets an opportunity during the prioritization meeting to argue about their ticket’s priority and why with the representatives of the other teams. This is the traditional way of prioritization. 75

Chapter 13

People and Processes

But recently developed methods have made deciding upon the priority of tasks easier. You can use a RICE score for prioritization. RICE is an acronym for the four factors we use to evaluate each project idea. •

Reach



Impact



Confidence



Effort

Here’s what each one means in detail:

76



Reach: Reach is the number of customers the feature might be impacting. This is valued against time. It could be “x” number of customers impacted in a quarter, it could be the number of transactions impacted in a month, and so on. The possible impact of the project needs to be quantified with numbers to come up with reach.



Impact: This is not accurately measurable, but there are models such as “Positive and negative effect model” that can help us. When we say a feature is a killer that will massively impact the customer experience, then we can rate it as a 3. For something that is a low impact, it could be 0.5, and so on.



Confidence: This is the confidence the stakeholder has that this feature request will get done. A feature that is shooting for the moon feature will be less than 50 percent. A small tweak like a color change of the banner would be 100 percent. But being honest with the confidence score is necessary to come up with a good RICE score.

Chapter 13



People and Processes

Effort: The time taken to implement the feature that is requested is the effort score. The time is calculated in person-months. It would be 0.5 if the task can be accomplished by one person in half a month’s time.

Figure 13-2 describes the formula with which a RICE score is calculated. If you line up multiple requirements and then add a RICE score against each requirement, the end result will help you prioritize the requirements you have come up with.

Figure 13-2.  RICE calculator The resulting score measures “total impact for time worked,” and we need to maximize this. You can use a spreadsheet that I have set up to calculate the RICE score automatically: ­https://bit.ly/rice-­calculator.

Reviews The review meeting is one where the stakeholders will review the sprint-­ developed tasks by looking at the demo; the meeting is led by the scrum master along with the development team. This demo could be a full-­ fledged user-facing demo or one that can be simulated to ensure that the meeting is short and to the point.

77

Chapter 13

People and Processes

Figure 13-3 explains how a typical sprint review meeting happens as well as the questions that need to be answered in a review meeting. Each person has a say in it and has to answer the three questions in Figure 13-3. Once done, the team members vote on the answers. The answers that get a certain set of votes are then shared across and acted upon by management.

Figure 13-3.  A typical sprint review meeting There could be other ad hoc review meetings that can be scheduled between the sprint process in the case of go-live ready tasks. For example, if there are certain people who are from multiple teams, then they could be looking at the demo almost on a daily basis and reviewing it more often than a typical sprint team. But regular reviews can pose a threat to projects. The reason is that if the requirements are not well documented along with the in-scope and out-of-scope parts in an objective way, there is always a possibility that the review meeting can go astray into discussions about why a certain feature is absolutely necessary at this point in time. This is where the role of the scrum master becomes extremely crucial to bring to notice that the objective of the meeting is being deviated by discussing out-of-scope topics. Hence, choosing the right scrum master is necessary. It should be someone who speaks on behalf of the product, and

78

Chapter 13

People and Processes

not on behalf of either of the two teams, in other words, stakeholders or the people implementing the project. During the demo meeting, the scrum master will ask the stakeholders to approve of the product in the current state to see whether it is fit to be shipped and if it meets the definition of done at this point. If at any point the stakeholders feel that there are features that should be stripped off or added unnecessarily, these are called out. Hence, the meeting is transparent in that it lets both parties give open feedback about whether the product is considered ready. The goal of the meeting is to review transparently and determine the status of the work implemented in the sprint. There are four things that the meeting tries to look at from a product perspective. •

What has been done?



What has not been done, and why?



Work that has been added since the project started and now



The work removed from the sprint and the reasons for that

After the meeting ends, a revised product backlog is arrived at, and this becomes the set of items that would be picked up by the implementation team for the next sprint. If a new set of requirements was figured out while the product was being demoed, then that goes into the backlog as well. A sprint review is about demonstrating the hard work of the entire team: designers, developers, and the product owner.

79

Chapter 13

People and Processes

Summary Setting up processes is hard at first. It will take convincing, discipline, time, and effort to propagate the processes to the entire company. Once these processes are set up, the company overall will have a set template to execute tasks and projects much faster than what it had before these processes were set up. Executing ad hoc projects gives the illusion of a fast-­ paced company, but it truly is a one-off thing. A resilient company always follows and respects processes. A company that is here to last for hundreds of years sets up processes that can last for that long and adapts to newer-­ age processes and technologies that can help aid it.

80

CHAPTER 14

Prototyping Modern companies thrive on fast-paced strategies and the successful execution of these strategies. But this speed should not come at the expense of processes that have been put in place. There should be a certain way that rapid prototyping is done and executed. Setting up inherent structures that will help to develop and deploy these fast prototypes is important. The mindset of the company and the people should be aligned to executing such fast-paced projects. This requires agility, grit, and will to drive quickly and with a data-driven approach. Each data point when executing prototype projects is important. Datapoints enable the team to then decide whether the execution and strategy were good or flawed. Quick changes can then be done to make the strategy a full fledged one thereby enabling fast paced prototyping.

Innovative Projects A business, if it is to stay competitive, needs to innovate, and it needs to innovate quickly. This means it needs an ability to fail fast and come up with ways to nail the solution quicker than the competition. For this, teams and processes have to be agile—more agile than anybody else. To move quickly, companies have adopted agile principles. Along the way, operations teams have undergone a huge digital transformation journey. The COVID-19 pandemic has accelerated the adoption to digital like never before. With so many companies moving completely into a remote mode, the world has been forever changed. But agility does not ensure scale on its own; a company needs to be cognizant of scale while moving to digital. © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_14

81

Chapter 14

Prototyping

The traditional way of looking at agile teams also has evolved over time. There are new structures called squads, pods, cells, prides, and tribes to describe teams. There are even villages and guilds that have formed within the organizations. These teams may have leaders who call themselves traditional managers and scrum masters, or they may have creative names like shepherds. We like to call them as mentors. But whatever these new names might be, they are just a new way of creating structures within organizations that can help in the super-fast delivery of projects that can also handle scale. The core idea behind these names is to ensure that people work together as a tight-knit group to get the task at hand done. The efficiency with which these squads can operate is much higher than the traditional teams. The squad model is also called the “Spotify model” as it was first developed by Spotify, the music streaming service. Spotify developed its own version of the scrum. Figure 14-1 explains the Spotify tribes, squads and guild model. Observe that a squad can be people from the same tribe but span different teams, while a guild can be from across tribes.

Figure 14-1.  Spotify tribes, guilds, chapters, and squads 82

Chapter 14

Prototyping

Spotify uses Scrum, but it renamed team to squad because the company wanted to create a level of ownership for team members. At my startup, we came up with a modified version of the squad model for our own use and improved upon a typical scrum system. In our model, we went with the existing scrum model, where let’s say there are ten scrum teams spread across two business organizations. Then if there is a project that requires each of these teams to coordinate with each other, we get the leads of each of these scrum teams to form a squad. A typical squad consists of multiple leads from each scrum team, the program manager who is responsible for the delivery of the project, the QA people, and other members who might be needed on an ad hoc basis. After forming the squad, we ensure that this squad meets outside of their regular scrum meetings, just to ensure a smooth project. And if there are any adversities that this squad faces, they then approach their regular teams during their own scrum meetings to clarify and unblock the hindrances. Figure 14-2 shows how our squads looked. The black-headed stick figures are the team leaders. Observe that the leader of Scrum 5 is enough to represent the entire Scrum 5 team in Squad 2.

83

Chapter 14

Prototyping

Figure 14-2.  Improvised squad model to fit into scrum teams For new and innovative projects, the need to react quickly to market demands and to transform into a digital organization drove the rise of these autonomous, self-organizing workgroups in our case and has yielded benefits that are far-reaching. From my experience, the squad model works. It results in collaboration outside of regular teams and efficiency that a singular team cannot achieve.

Quick Turnarounds Organizing the teams into squads with specific goal-focused innovative projects leads to quick turnarounds. But with what cost? There are ongoing projects that are immensely important for the day-to-day business to function, and these projects cannot be disturbed, nor can their members. Hence, it is always better to create R&D teams that are functioning parallelly with the teams that already exist. These teams will have the flexibility and the 84

Chapter 14

Prototyping

ability to take on new challenges. Choosing members of this team can be done from the existing team members who are always ready to learn new things. R&D teams need to have their own daily cadence to help themselves unblock any new problems they might face. Typically any new project first goes to the R&D team so they can quickly prototype it and then pass it onto the specific squads or to the scrum teams, as shown in Figure 14-3.

Figure 14-3.  R&D teams should be independent for each organization for efficiency To achieve quick turnarounds for any project, do the following: •

Set clear milestones at the beginning of the project to keep everything on track.



Use the right technology. It is absolutely necessary to choose tech that the current team knows and is well versed with.



Have a daily cadence to ensure you don’t get behind schedule. 85

Chapter 14

Prototyping

Long-Term Projects Planning and managing a long-term project presents special challenges. Long-term projects can range from months to a year or more. It depends on the results of the work you do between now and then. Even if we can accurately predict what we want as an outcome at the end of six months, it would be difficult to ensure that the situation would remain the same after five months. It is always better to plan in short bursts so there is always the flexibility to amend the plans at the end of a month. Figure 14-4 explains how a typical rolling plan works with multiple hops in between.

Figure 14-4.  A typical rolling wave plan To apply a rolling-wave approach to your long-term project, you have to take the following steps: 1. Break down the components based on a two-month goal and set the remainder aside. Make sure to plan the remainder in lesser detail. 2. Plan the two-month goal in detail and further break them into one-­month goals.

86

Chapter 14

Prototyping

3. Take the first month’s goal and further break the goals down into bimonthly sprint-based goals. 4. Start bimonthly sprints, and as the progress happens, revisit the monthly goal and then augment the further goals to either add new requirements based on the new understanding or remove the unnecessary requirements. 5. Continue revising your plan in this way throughout the project. Do not hold off on launches related to long-term projects. If there are features that are meeting the minimum viable product (MVP), then it is good to test the product by launching it to a select set of users. The learning that is received by launching an MVP is going to add value to the full product launch that happens later. There are several approaches for go to market. •

Soft launch: Figure out the set of users to whom you can launch a new feature and enable it only for them. Also ensure that you have proper feedback mechanisms in place to record the feedback. This can be used as a critique of the existing set of features. Depending on the feedback, you might want to use the existing set of features or want to strip some of them off. Once the decision is done and agreed upon, you can then launch it for all users.



Dark launch: In this launch, the user doesn’t know that they are being used to test something. No user feedback is actively received, but you can use analytics to understand the user behavior.



Hard launch: Only if you have the infrastructure to handle a vast amount of users suddenly using a new feature, then go ahead with a hard launch. 87

Chapter 14

Prototyping

There are no winners and losers among these different types of launches. Depending on which type of launch suits the situation and the user base, using a specific approach is going to help. Also, note the following for new product launches:

88



Do not waste time adding too many features. An MVP is good enough to understand the market; hence, launch it and then iterate on it.



Innovation should not be frowned upon when launching new products, as a slight tweak can give you an edge over competition.



The MVP should be light-weight and not too resource-­ consuming. Ensure that it does not burn a hole in your pocket. You want to quickly test the market needs and then try the most frugal means to build an MVP. Do not spend a lot on making the perfect product.



Rushing in development helps in getting to market sooner. Keep making small mistakes fast so you can learn and improve the product faster. These mistakes when done early help you get invaluable learning that will help when the product matures over time.



Iterations should be kept to one to two weeks. Keep cutting down on things that are going to take a longer time. Do not worry if your favorite feature did not make the cut in an MVP. There will always be time to add it after the product has been launched.

Chapter 14

Prototyping

Summary Launching a minimum viable product does not mean that it was a success. This will be discussed in more detail in Chapter 23 when we talk about how to identify and consider a certain MVP as a winner. But developing a fast MVP ensures a faster go-to market than the competitors. In a digital world where all businesses are scrutinized and every strategy is critiqued, Minimum viable product can let businesses test their product at a smaller scale, get the feedback quickly and then try to do it at scale. This will lead to better iteratively good products.

89

CHAPTER 15

Scaling Operations Executing projects in a fast-paced manner can have two consequences: either it succeeds if all the parameters were thought through and planned or it fails because there were misconceptions, mistakes in execution, and misunderstanding between the strategy and execution teams. When a project fails at scale, the consequences are compounded and are sometimes irreversible. So, treading between agility and scale is super-­ important, especially for growing companies. Larger companies can sometimes afford the risk of a big project failing, but that’s not the case for mid-market-sized companies.

Agility vs. Scale We should not look at agility and scale as competitors but as two sides of the same coin. If there are two people on a team and one person is “agile” while the other person is always speaking and working toward “scale,” that is a killer combination. Have them work together to build the best product in the shortest possible time. Agile teams are now becoming mainstream across different industries, and not keeping scale in mind while being agile will ensure that the project is going to fail in no time. Initially, the goal of agile when it was introduced in development was to be extremely flexible and aid in fast decision-­ making. It focused on colocated teams.

© Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_15

91

Chapter 15

Scaling Operations

When we look at the earliest processes like Division of Labor by Frederick Taylor and so on, we find they were focusing on the scale of operations rather than agility. Now it is time to merge the two approaches and come up with a hybrid model. People at scale can drive the same amount of operations that when replaced with machines is called agile. Not all things can start agile; the framework starts with people. Operations teams first have a lot of people to scale the business; once the processes set in, then tech comes in. We always thought that when we were building the business process tech team that the company would’ve done the same amount of business at the same scale even if we did not have the tech team. All the efficiency relied purely on people and people processes rather than on data and systems. Let’s begin to understand how we can merge agility and scale by first looking into the Agile Manifesto principles. •

Agility values individuals and interactions over processes and tools.



A working self-explaining software is given more value than heaps of documented processes.



Working hand in hand with customers is opted for rather than dealing with contractual obligation talks.



Plans should be agile too, where you can quickly react to changes rather than following a set course of action.

When we apply agile and lean strategies at a team level, then we are being strategically forward thinking as this is what will drive teams that are already at scale to function in an agile manner. Usually, when we think of scale, we often think it is a huge number of people and a large number of teams. But if we are being tactical enough, then with a lean team we can achieve scale. When we look at different ways of working (WoW), applying strategies that takes into consideration the current context and situation helps in arriving at the right solution. Application of strategies that is written in 92

Chapter 15

Scaling Operations

text books would not be prudent. It will help us achieve what is needed for the current project at the current time. This awareness of context while applying strategies will help in creating tailor-made strategies. It will fit the purpose of the situation and the project. If we do select a certain way of working at the beginning of the project, it doesn’t mean we will continue to stick to that. But it acts like a guiding light, and the rolling plans eventually will help us in adapting to the needs of the situation later. Usually, if the situation becomes complex later, then the strategy to change the way of working for that situation will be required. When selecting a context-aware strategy at the start of a project, there are certain parameters that we need to identify that will help in setting up the ways of working. •

How is the team structured? Is the team composed of business analysts, UX designers, developers, QA people, or data scientists, or will it be composed more of sales, operations, and marketing people? Are these going to be sourced from outside, or are we going to pull in people from different pre-existing teams and form a new team? Will they all be colocated, will they be working from home, or is it going to be a hybrid model? Will they be in a large team all together, or will there be specific teams to deal with specific modules? These questions need to be answered, and the answers could vary depending on the situation you are in.



Once that is done, how you will work together? Which way of working best suits the situation? Agile? Traditional? Or a mix of both? Will you be able to come up with prospective goals, or will you be able to come up with a week-on-week goal-driven approach? Are there going to be roadblocks that you might face while choosing any of these approaches? 93

Chapter 15



Scaling Operations

What collaboration tools are you going to use? For this, there are multiple options, and being in technology space, we would’ve used applications that help us collaborate. In our team, we used a tool called “Gather” that helped us collaborate when we moved to work from home model. When we used to work at the office, we could speak to the person who was next to us and ask them about any doubts we had. This happened across teams, and no one would hesitate to ask for help as each person would know the person next to them. But once we moved to remote work, this became hard, especially for junior members of the team who were hesitant to approach others for help. We used a tool called Gather Town; this website lets all the members of our team be in one virtual workspace, and each of us gets a virtual character. We can use this character to walk around and meet other people, get into a “bubble” with them, and speak to them privately as well. Other communication channels include traditional email, Slack, etc.

The choices that we make at the start of the project will change over time as we learn, but the main point to note is that we will make some broad choices at first to get going. The choices we make are dependent on factors such as the following: •

Team culture



Technical skills of the team



Nature of problem



Business constraints

Let’s review these factors now.

94

Chapter 15

Scaling Operations

Team Culture Having agile teams requires people to collaborate effectively to achieve things. If traditional-culture people are put on an agile team, that will lead to two people speaking different languages. There would be no coherence or togetherness. The culture for a specific team will also vary depending on what the organization’s culture is. If the organization culture is traditional but specific teams within the organization are agile, that also spells trouble as there will be collaboration required between teams, and when each team cannot understand the other team’s WoW, it becomes difficult to deal with unknowns. People’s flexibility also plays a role in agile teams. Agile teams require people to be flexible and accommodating in their approach. Being rigid only increases the time frame to deliver and acts as a barrier between teams. In Figure 15-1, it shows how people’s mental state can be affected by the increased scale of a product. If the product requires agility, the team will be flexible, and as the agility decreases, the team’s culture becomes rigid.

Figure 15-1.  Explaining how the scale can affect people’s mentality

95

Chapter 15

Scaling Operations

Technical Skills of the Team The people on a team must have the skills (or gain them) that befit the role they play on that team. For example, developers on an agile software team may need to have test-driven-development (TDD) skills, people-oriented collaboration/communication skills, continuous integration (CI) skills, model storming skills, team-based planning skills, and so on. Developers on serial/traditional teams may be more focused on programming skills for a specific technology platform. Figure 15-2 depicts how the careers of software engineers within the teams can progress as they see the product moving from a prototype to a scalable one.

Figure 15-2.  The upward arrow indicates the career progression.

Nature of the Problem Although some people want to believe that certain types of problems can be solved in only one manner, that doesn’t seem to be the case in practice. For example, it’s possible to take an agile or a traditional approach to data warehousing projects, to marketing projects, and to procuring services from an external partner. Our experience is that the real issue is how decomposable the potential solution is. For example, it’s possible to

96

Chapter 15

Scaling Operations

decompose a data warehouse into many small releases if you choose. The same thing can be said of the development and execution of a marketing campaign. But, it isn’t easy to decompose an airplane into several working parts. Either the airplane is complete or it isn’t. Yes, it’s still possible to apply agile techniques to the building of the airplane, and very likely to its design as well, but the airplane team will never be as agile as a software development team due to the physical and regulatory constraints that they face. Figure 15-3 depicts how a problem is solved through a product by first prototyping it and then doing a complete launch over time.

Figure 15-3.  The progress of product and different launches

Business Constraints The way that the business constrains the endeavor, such as insisting on a certain (always aggressive) delivery date, an approach to managing the budget (often a fixed price/bid), and how available businesspeople will be throughout the project certainly all have an effect on the process you adopt and the type of people you include on the team. It may even influence what tools you use, particularly those for communication and collaboration.

97

Chapter 15

Scaling Operations

Figure 15-4 shows how teams start with limited resources and then finally move toward all the wings of the company cooperating with each other to launch flagship projects.

Figure 15-4.  Typical path for product launches

Alerts and Flags While scaling operations, there is always a chance of things going downhill, mainly due to the unknowns that were not taken care of when the teams were super-agile. This means that the ops currently running could be at the risk of scaling down suddenly. To subvert these, we need flags and alerts put into place from a technology-driven perspective that helps teams to pre-empt any adversities. The possible adversities could be as follows: •

Security incident



Data loss



Breakdown of systems due to scale

Alerts and flags should be thought through before the application or the system that the teams use is completely built and deployed. Alerts can simply be a notification sent over different channels such as the following: 98

Chapter 15



Communication channels like Slack



Emails



SMS messages to select people

Scaling Operations

Tech-Driven Operations at Scale A clear playbook is emerging for how to integrate and capitalize on advanced technologies—across an entire company and in any industry. How does your company use advanced technologies to create value? This has become the defining business challenge of our time. If you ignore it or get it wrong, then anything from your job to your entire organization could become vulnerable to rivals who get it right. The new technologies come with many labels—digital, analytics, automation, the Internet of Things, industrial Internet, Industry 4.0, machine learning, artificial intelligence (AI), and so on. Technologies that help scale business support the creation of all new, digitally enabled business models, while holding out the vital promise of improving customer experiences and boosting the productivity of legacy operations. Advanced technologies are essential to modern enterprises, and it’s fair to say that every large company is working with them to some extent. •

Develop technology road maps that strategically focus investments needed to reinvent their legacy businesses and create new digital ones.



Train managers to recognize new opportunities and build in-house capabilities to deliver technologies.



Establish a modern technology environment to support rapid development of new solutions.

99

Chapter 15

Scaling Operations



Overhaul data strategy and governance to ensure data are reliable, accessible, and continuously enriched to make them more valuable.



Focus relentlessly on capturing the strategic value from technology by driving rapid changes in the operating model.

The need for a large number of technology solutions and the last-­ mile challenge may be familiar hurdles to readers who lived through the lean revolution some 25 years ago. Capturing value from lean initiatives involved driving each process change all the way through the operating model of the business. No single lean project could generate a major performance improvement, but a rich portfolio of lean projects could. To make the transformation manageable, companies implemented lean projects in waves, tackling processes or units of roughly 200 people at a time. They first developed a vision for how each process or unit would be transformed. Then they built benches of lean experts (often called black belts) to manage change and ensure the new operating practices were adopted. Even though lean methods were never proprietary, companies such as Toyota used them to ceaselessly pursue small performance improvements and thereby build and protect an advantage over their competitors. An essential component of achieving scale in a technology-enabled transformation is having sufficient in-house technology expertise and talent. One proven model for building a technology bench is the “technology factory.” Such a factory is wholly at the service of the business and governed by the business. It provides the sort of work setting that is necessary to attract technology talent and achieve high-velocity development.

100

Chapter 15

Scaling Operations

Summary The question that arises is when to augment operations with technology. Some companies realize it late, and the cost of maintaining operations through people will have shot up to an extent where any more scale would just become untenable. Other companies go with a technology-first approach. Neither of them is a sure-shot success. The timing has to be according to the situations and market conditions. While technology can surely enable the operations, not having a suitable product and investing in technology can lead to downfall.

101

PART IV

Technology

CHAPTER 16

Technology’s Role in Helping Business Needs Tech team divisions should be based on the business team’s needs. When a company is small and requires fast-paced prototyping and go-to-market products, the team can be monolithic. But as a company grows to become a mid-market-level company, the tech team needs to undergo a shift. It needs to be split up to align with the business verticals. And as mid-­ market-­level companies become enterprises, a further split and macro-­ level consolidation are needed. The goal is to stay attuned to processes and also remain nimble at the same time. Tech leaders need to constantly work on the challenges of balancing the two.

T ech Organization in Relation to Business Units Figure 16-1 represents a typical organization structure around which a technical team is formed. At the start of the organization there will likely be one business unit and one business head, who will disseminate the information regarding new developments or new initiatives to one technical head and a product head. When a company grows, the number © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_16

105

Chapter 16

Technology’s Role in Helping Business Needs

of business units (BUs) will grow, and for each BU there will be a BU head who will work with an office of business analysts and program managers who become the stakeholders. The stakeholders then form a unit of their own to understand the impact of the initiatives before passing on these initiatives to the product owner teams. The impact analysis can follow multiple methods or frameworks. Typically, the RICE (reach, impact, confidence, effort) framework is followed. I’ll discuss more about this in Part V of this book. Once the stakeholders do the analysis and pass on the initiative document to the product owners, the product owners then come up with their product requirement document by assessing the different integrations that will be required to pull off the initiative. If necessary, cross-team collaboration is done to assess impact across teams. Then, these requirements are passed on to the tech team. The tech structure within the tech team will be discussed in this chapter.

106

Chapter 16

Technology’s Role in Helping Business Needs

Figure 16-1.  Business units in relation to tech teams

107

Chapter 16

Technology’s Role in Helping Business Needs

Tech Team Structure Figure 16-2 explains how the tech team should be organized to execute each of the business requirements.

Figure 16-2.  Organization of a tech team A tech team’s success will depend on how nimble the team is and also how easily and autonomously the team able to execute the projects. Sometimes, project managers help augment the coordination with stakeholders like product managers, which reduces the burden on engineering managers. For simplicity’s sake, we’re ignoring the project manager’s role here because we will get to that in Part V.

 ole of Engineering Managers R and Architects The responsibilities of engineering managers and architects are interchangeable in many ways. Some engineering managers might be 80 percent technical and 20 percent people managers, while others are the 108

Chapter 16

Technology’s Role in Helping Business Needs

other way around. Depending on how technical an engineering manager is, they can either architect the systems themselves or get help from an exclusive architect to architect the systems. The responsibilities of engineering managers and architects are as follows: •

Responsible for the stability/growth/management of all the modules owned by the entire team



Responsible for growth strategies



Comes up with innovative ideas for scale and maintenance



Ensures the team follows all the coding standards/ documentation



Leads the meetings of new business-impacting features that stakeholders come up with



Acts as the bridge between stakeholders and technical leads when a feature’s deadline is being decided



Responsible for setting up the team structure/module structure

Role of Tech Leads The following are the responsibilities of the tech leads: •

Own multiple modules •

Examples of modules: ■■ Profile management of a user ■■ User creation module ■■ Upselling module



Responsible for uptime/downtime 109

Chapter 16

Technology’s Role in Helping Business Needs



Responsible for speaking to DevOps and managing the infrastructure



Responsible for the security of the modules owned by the team



Ensures smooth sprint prioritization/planning/ functioning



Should step in when inter-team dependencies arise



Manages production escalations



Responsible for approving the appraisals of software engineers reporting to them

Responsibilities of a Software Engineer The following are the responsibilities of a software engineer: •

Should be from a technical background



Should be willing to work on new technologies



Should be coding language/coding technology agnostic



Should have proficiency in at least one coding language

Responsibilities of a Quality Assurance Lead The following are the responsibilities of a quality assurance lead:

110



Be involved in requirements gathering with the business team



Be involved in the technical discussion of the sprint tasks with the team

Chapter 16

Technology’s Role in Helping Business Needs



Estimate testing tasks along with team members



Analyze requirements from a QA standpoint along with QA engineers and document high-level scenarios



Review test cases and provide feedback



Perform end-to-end testing with the respective team member for any feature going live



Review daily status from team members



Track execution of test cases in tools like Zephyr



Prioritize the tasks based on go-live dates and assign them to the team on a daily basis



Help the team with data seeding for testing



Be involved in identifying and selecting test cases for automation from existing test case documentation



Review automation scripts implemented by team members (GitHub)



Review test case reports and automation script reports on a daily basis



Do one-on-ones with team members every month

Responsibilities of a Quality Assurance Engineer The following are the responsibilities of a quality assurance engineer: •

Be involved in identifying and selecting test cases for automation from existing test case documentation



Apply the designing and test automation strategy document 111

Chapter 16

Technology’s Role in Helping Business Needs



Create an automation test plan and get approval



Configure a test environment for automation



Implement test scripts for the test cases to be automated



Commit code changes to GitHub and get them reviewed with leads



Schedule the test scripts in the CI/CD pipeline



Generate reports of test scripts and analyze them



Help the team to write scripts and debug



Be involved in a code review



Plan for improvising scripts on regular basis

Summary Getting the technology teams set up is just one step toward execution. While the initial projects and initiatives may go well, for sustaining the growth, it’s important to follow the right processes. People and technology are the right ingredients for success, and also following the right mix of teams and division of teams and responsibilities help in this sustenance.

112

CHAPTER 17

Technology Stack This chapter covers one technology stack to create websites and apps. This is just a current example, because most technology stacks are constantly changing. What matters most in high-velocity growth is how fast you can update your technology stack to stay in tune with the latest tech trends. This chapter covers the current tools and technologies in use.

Front-End Stack It’s important to choose a stack that is agnostic of whether it’s exclusively for the front end or backend. JavaScript has proven to be one technology that has brought together both of these worlds. We no longer have to look at developers as front-end or backend developers as long as they are well versed in JavaScript. Additionally, HTML, CSS, and Bootstrap play key roles in the frontend. We cover both Front end and backend end technologies in brief just to give you and understanding of what these technologies mean while starting up a business, then it is important to know if you’ll be building a website or an app.

What Is HTML? Hypertext Markup Language (HTML) is not a programming language. It is a markup language that tells web browsers how to structure the web pages © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_17

113

Chapter 17

Technology Stack

you visit. HTML consists of a series of elements, which you use to enclose, wrap, or mark up different parts of content to make them appear or act in a certain way.

What’s in the “Head” or Metadata in HTML? The head of an HTML document is the part that is not displayed in the web browser when the page is loaded. It contains information such as the page title, links to CSS (if you want to style your HTML content with CSS), links to custom favicons, and metadata (data about the HTML, such as who wrote it, and important keywords that describe the document).

What Are the Elements of HTML? Use HTML text content elements to organize blocks or sections of content placed between the opening and closing tags. Important for accessibility and SEO, these elements identify the purpose or structure of that content.

114



, , , , , : The HTML – elements represent six levels of section headings. is the highest section level, and is the lowest.



: The HTML content division element () is the generic container for flow content. It has no effect on the content or layout until styled using CSS.



: The HTML

element represents a paragraph.



  • : The HTML
  • element is used to represent an item in a list.



    : The HTML element represents an ordered list of items—typically rendered as a numbered list.

    Chapter 17



    Technology Stack

      : The HTML
        element represents an unordered list of items, typically rendered as a bulleted list.

        CSS Properties Cascading Style Sheets (CSS) is a standard style sheet language used for describing the presentation (i.e., the layout and formatting) of the web pages. •

        Prior to CSS, nearly all the presentational attributes of HTML documents were contained within the HTML markup (specifically inside the HTML tags); all the font colors, background styles, element alignments, borders, and sizes had to be explicitly described within the HTML.



        CSS can be either attached as a separate document or embedded in the HTML document itself. There are three methods of including CSS in an HTML document. •

        Inline styles: Using the style attribute in the HTML start tag



        Embedded styles: Using the element in the head section of a document



        External style sheets: Using the element, pointing to an external CSS file

        What Is the Box Model? Every element that can be displayed on a web page consists of one or more rectangular boxes. The CSS box model typically describes how these rectangular boxes are laid out on a web page. These boxes can have different properties and can interact with each other in different ways, but every box has a content area and optional surrounding padding, border, 115

        Chapter 17

        Technology Stack

        and margin areas. Figure 17-1 shows how content in the center can be aligned using the CSS box model.

        Figure 17-1.  Box model in CSS

        What Is Bootstrap? Bootstrap makes it easy to quickly design and customize responsive mobile-first sites. It is the world’s most popular front-end open source toolkit, featuring Sass variables and mixins, a responsive grid system, extensive prebuilt components, and powerful JavaScript plugins. Bootstrap’s grid system uses a series of containers, rows, and columns to lay out and align content. It’s built with flexbox and is fully responsive. Figure 17-2 is an example and an in-depth look at how the grid comes together.

        116

        Chapter 17

        Technology Stack

        Figure 17-2.  Column structure in Bootstrap

        Why Use Bootstrap? Bootstrap is the most popular framework for creating layouts, and Bootstrap’s responsive CSS adjusts to phones, tablets, and desktops. It is easy to set up and create a working layout in less than an hour. It has base styling for most HTML elements, such as the following: –– Typography –– Code –– Tables –– Forms –– Buttons –– Images –– Icons It also has an extensive list of components such as the following: –– Drop-downs –– Button groups –– Navigation bars –– Breadcrumbs 117

        Chapter 17

        Technology Stack

        –– Labels and badges –– Alerts –– Progress bars –– And many others It comes with bundled JavaScript plugins such as the following: –– Sliders –– Tabs –– Accordions

        Why Use JavaScript? You can use JavaScript to build interactive web pages, desktop applications, web applications, and mobile apps. You can run JavaScript in a browser or in Node.

        What Is React.js? React.js is a JavaScript library created by Facebook for building user interfaces that are component-based and that can be dynamically updated depending on the state of an application

        ECMAScript ECMAScript is a language standardized by ECMA International. JavaScript is merely an implementation of the standardized ECMAScript language. ECMAScript 5 (ES5) was standardized in 2009, and most contemporary browsers can process it. ECMAScript 6 (ES6) was standardized more recently in 2015. Therefore, browsers have not yet caught up yet to process it.

        118

        Chapter 17

        Technology Stack

        To write code in React, you want the latest features of ES6. Babel is a JavaScript preprocessor. In short, Babel takes ES6 code and converts it to ES5 so the browser can process it. With React, you can create single-page applications by creating views for each state in your application (home page, login page, etc.) and dynamically toggle on and off the views depending on the state. Because an application has to load only a single page at the beginning, navigating through different views in a React web application is really fast and requires no page loading.

        Backend Technology JavaScript in today’s world plays a key role in bringing the front-end/ backend divide closer. Having to learn two different stacks is no longer a need if the company is using the JavaScript stack for the backend as well. Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine. It was created by Ryan Dahl in 2009 and is an open source project. Node. js runs on V8 (which is a wrapper around Chrome’s V8 engine). V8 is an open source JavaScript engine developed by Google, which is browser independent. It’s a lightweight, asynchronous system and runs on a singlethreaded nonblocking architecture. Node.js has a very large community that offers support and helper packages (NPM). Node.js contains APIs/modules that help to write JavaScript code that can run outside of a web browser. Node.js is a platform that allows you to build scalable network applications using JavaScript on the server side. It has the following characteristics: –– JavaScript runtime: This executes the JavaScript code at runtime. –– Server side: This runs and performs I/O tasks on a server that help process the client requests.

        119

        Chapter 17

        Technology Stack

        –– Event Driven: The flow of the execution is determined by events, e.g., button click, mouse hover, etc. –– Asynchronous: Two or more events can occur simultaneously and are not coordinated with each other.

        What Is ExpressJS? Express.js, or simply Express, is a back-end web application framework for Node.js. It was released as free and open source software under the MIT License. It is designed for building web applications and APIs. Express.js is based on the Node.js middleware module called connect, which in turn uses the http module. So, any middleware that is based on connect will also work with Express.js.

        What Is REST? REST stands for REpresentational State Transfer. In simpler terms, it is an application program interface (API) that makes use of the HTTP requests to GET, PUT, POST, and DELETE the data over the Web. The main functions used in any REST-based architecture are as follows:

        120



        GET: Provides read-only access to a resource



        PUT: Creates a new resource



        DELETE: Removes a resource



        POST: Updates an existing resource or creates a new resource

        Chapter 17

        Technology Stack

        Databases We will look at the key aspects of two databases, MongoDB and Postgres SQL. In summary, the main differences between MongoDB and PostgreSQL have to do with their systems, architecture, and syntax. MongoDB is a document database, while Postgres is a relational database management system. MongoDB has a distributed architecture, while PostgreSQL has a monolithic architecture. MongoDB uses BSON, while Postgres uses SQL.

        MongoDB MongoDB is built on a distributed, scale-out architecture and has become a comprehensive cloud-based platform for managing and delivering data to applications. MongoDB handles transactional, operational, and analytical workloads at scale. If your concerns are time to market, developer productivity, supporting DevOps and agile methodologies, and building stuff that scales without operational gymnastics, MongoDB is the way to go. It has the following characteristics: •

        Schemaless database



        Structure of a single object is well defined



        Data stored as JSON document



        Indexing supports

        Postgres SQL PostgreSQL is a rock-solid, open source, enterprise-grade SQL database that has been expanding its capabilities for 30 years. Everything you would ever want from a relational database is present in PostgreSQL, which relies

        121

        Chapter 17

        Technology Stack

        on a scale-up architecture. If your concerns are compatibility, serving up thousands of queries from hundreds of tables, taking advantage of existing SQL skills, and pushing SQL to the limit, PostgreSQL will do an awesome job. It has the following characteristics: •

        It is a traditional relational database management system (RDBMS).



        It is a SQL database like Oracle or MySQL.



        Postgres is free.

        For those who already have a rudimentary understanding of JavaScript, MongoDB has a shorter learning curve, whereas those who have a lot of experience in SQL databases may find it easier to adjust to Postgres. Both are growing in popularity as comprehensive database solutions for a variety of industries. However, the biggest issues that companies have while processing data from either database are the time and complexity involved.

        Summary You should choose the language or framework for your tech stack according to your situation, the people involved, and their strengths and weaknesses. The ability to get support for the tools you choose in the long term is also important.

        122

        CHAPTER 18

        Key Processes and Rituals of Technology Teams Software engineering is the wrong name for programming. Software engineering is plain automating, whereas programming is an art. Whatever we code evolves. The goal is to first make it work and then evolve it by changing it or refactoring it. For me, the main driving forces behind a successful organization or an individual are the following: •

        Communication



        Problem solving



        Innovation



        Change management

        Each agile process should include these key drivers. We’ll discuss the importance of these drivers before we get into the agile rituals. Agile processes break each project into chunks that are manageable by smaller and distributed teams.

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_18

        123

        Chapter 18

        Key Processes and Rituals of Technology Teams

        Communication The success of a project is not only about what methods we follow, such as agile or waterfall or spiral. It’s all about whether the members working on the project are on the same page. Do they understand what every other person is doing with regard to the project? If not, then the project is bound to fail. But in these failures we’ve learnt in the past to evolve these methods and suit to the need of the project. Each time this evolution happens, the organization’s objectives are met thereby driving greater good. What does all this have to do with greater good? Individuals work for their personal goals and collectively drive the organization for the greater good. Whether we work for a service company or a product company, in the end both companies produce products that are used by customers, be it internal or external customers. Our end products help these customers, but teams usually face problems while making the product. And these problems can range from chaotic to simple ones.

        Problem Solving All problems in life or at work go through these phases such as chaotic, complex, complicated, and simple. Navigating through these phases needs skill and risk management. The key is to manage the risks and avoid the uncertainties. For example, lets say that we are building a new website and we have a deadline to meet but there is no software developers available within the team to do this. The first thought that would come to us to solve this problem would be to hire new software developers. But because that is time consuming, we run into an uncertainty that it will not be done. So to avoid it, we then look up consultants or freelancers who can do this quickly and surely.

        124

        Chapter 18

        Key Processes and Rituals of Technology Teams

        Innovation Innovation can be driven at any level in the organization. At a software developer level - improving the runtime of the code from 1 second to 100 millisecond is something that can be done by adding extra efforts and thinking innovatively about the runtime. At a product management level - understanding the key customer pain points by collating all the customer service calls received by the team and addressing them through right product intervention is an innovation that will yield long term results. Fostering innovation at an individual level will lead to teams thinking innovatively for a product’s improvement thereby leading to the business growth. So, while failing, we need to make sure that we fail as many times as possible and fail fast so we have enough time to fail again, in a different way. The factors driving any organization or an individual are not the traditional triangle of championing constraints and quality and value; instead, the triangle is a prism. Adding an additional dimension of innovation to the standard triangle completes the prism, as shown in Figure 18-1.

        Figure 18-1.  Innovation as another facet to an organization’s drive Once your team has formed, is innovating, and is comfortable, the team tends to relax. Then suddenly, there is change.

        125

        Chapter 18

        Key Processes and Rituals of Technology Teams

        Change Management Change management is something that all companies need to have a process for. Figure 18-2 shows the typical emotional responses to change, or something bad that happens to us.

        Figure 18-2.  Various stages of change The stages are as follows: 1. Shock: This is initial paralysis at hearing the bad news. 2. Denial: This is trying to avoid the inevitable. 3. Anger: This is a frustrated outpouring of bottled-up emotion. 4. Bargaining: This is seeking in vain for a way out. 5. Depression: This is the final realization of the inevitable. 6. Testing: This is seeking realistic solutions. 7. Acceptance: Finally, this is finding the way forward. The time spent on each point on the curve can vary. If it’s us who are stuck in one of the points of the sine curve, adapting to changes has to be quick; if not then we end up in a loop which makes it hard for us to come out. If we can sail through the curve as fast as we can, we are safe. 126

        Chapter 18

        Key Processes and Rituals of Technology Teams

        Changes in any person/organization take time to settle in, but we should not resist change. Change offers us opportunities to learn new things always. We need to accept change; adaptability is the key. Now that we have established why each of these factors is important, let’s understand what drives the agile process in an organization.

        Scrum for Tech Team Scrum is an agile development method that concentrates specifically on how to manage tasks within a team-based development environment.

        What is Scrum from a Tech Team’s Angle The following are characteristics of scrum: •

        Each iteration of scrum is a sprint.



        A product backlog is a list where all details are entered to get the end product.



        During each sprint, the top user stories of a product backlog are selected and turned into a sprint backlog.



        The team works on the defined sprint backlog.



        The team checks on the daily work.



        At the end of the sprint, the team delivers the product functionality.

        Figure 18-3 explains the scrum process and various stages of a scrum.

        127

        Chapter 18

        Key Processes and Rituals of Technology Teams

        Figure 18-3.  An agile scrum cycle

        Scrum Master A scrum master is a team leader. They extend their services to the product manager and development team. The following sections list the scrum master’s responsibilities.

         crum Master Responsibilities and Services S to the Product Owner The following are the responsibilities to the product owner:

        128



        The scrum master helps the product owner manage the product backlog effectively and devise the techniques to do so.



        They help the product owner to communicate the clear product needs to the development team.

        Chapter 18

        Key Processes and Rituals of Technology Teams



        They ensure that the product owner understands how to manage the product backlog and maximize the value.



        They facilitate scrum events.

         crum Master Responsibilities Toward S the Development Team The following are the responsibilities to the development team: •

        The scrum master mentors and coaches the team to follow the scrum rules.



        They help to remove roadblocks and impediments to aid in the team’s progress.



        They help the team to deliver high-value results and maintain team dynamics.



        They facilitate scrum events and scheduling scrum meetings.



        They coach the team to adopt the scrum framework, especially if the team is new to scrum rules.



        Also, a scrum master plans for scrum implementation in the organizations and helps people who are stepping into an agile environment or adopting scrum.

        Product Owner The product owner creates the product backlog, prioritizes the backlog, and is responsible for delivering the functionality at each iteration.

        129

        Chapter 18

        Key Processes and Rituals of Technology Teams

        Scrum Team The team manages its own work and organizes the work to complete the sprint or cycle.

        Communication Cadence Ideally we should have a workflow where regular emails are sent to stakeholders. Here is what I recommend: •

        Day 1: Email with details on the sprint



        Day 5: Email to stakeholders on update, progress, and issues and any actions that need to be taken



        Day 10: Email with what was released, release notes, what was pushed, and why, with a calendar block for the retrospective

        Escalation Process Escalations about a service delivery promised by a businesses require a Standard Operating Procedure (SOP) to be followed. The following paragraph is a typical SOP for a technical service delivery failure related escalation. This is the escalation process: 1. The sprint owner is the go-to person for feature prioritization. 2. The engineering or design lead or any other lead is the first point of contact. The request will then go to their manager. 3. If things still need to be looked into, the manager’s manager will be involved. 130

        Chapter 18

        Key Processes and Rituals of Technology Teams

        4. Finally, the functional head will be brought in. The more number of times issues occur, the more you need to improve your process.

        Overall Review Process Every quarter there should be a retrospective on all sprints. They should be evaluated on these parameters: •

        Frequency of features that were moved



        Frequency of escalations that were raised



        Frequency of missed timelines and/or scope



        Frequency of inadequate documentation



        Frequency of lack of adherence to process and communication



        Key project metrics quarter over quarter

        Summary The technology team thrives when processes are adhered to. Rituals of the tech team in an agile environment and more so in the current remote work environment has shifted more towards individual’s growth and team’s efficiency while still caring about the actual business goals at hand. Changes in the organization, the management of these changes, innovation driving people individually and also teams at large and how to leverage that has become the key focus of processes now. Agile team’s Scrum process and the rituals around it is what is driving the teams to work towards their team goals while collectively driving the objectives of the company.

        131

        CHAPTER 19

        Business Analytics and Its Importance in Scaling and Execution Business analytics, or business intelligence technology, refers to any piece of software or processes used by marketers, sales, product teams, and customer success teams to perform insights and growth activities. These applications do the following: •

        Help marketers plan and execute marketing campaigns, collect and analyze the results of those campaigns, measure and track marketing performance, and apply the insights to future campaigns. All of this happens at scale, in a multitouchpoint, omnichannel, primarily digital environment.



        Help sales to better understand their customers and prospects so they can build better processes and reduce time to close their sales, align leads to relevant sales folks, add revenue intelligence and sign later deals, etc.

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_19

        133

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution



        Empower product teams to better understand user cohorts that support various goals around monetization and product adoption so they can continuously build better customer experiences.



        Allow customer success teams to improve Net Promoter Score (NPS) and play a bigger role in upsell and cross-sell opportunities so they can be a growth function and support business objectives such as Net Revenue Retention (NRR).

        Strategy This section highlights the strategy to implement Business analytics at scale within an organization. How to get the departments aligned to the common objective of assimilating all the data at one place so that meaningful insights/analytics can be driven out of it is explained in detail in the following paragraphs.

        Determine Business Objectives Designing a data warehouse is a business-wide journey. Data warehouses touch all areas of your business, so every department needs to be on board with the design. Since a warehouse is only as powerful as the data contained within it, aligning department needs and goals with the overall project is critical to your success. Without data across sales and marketing, overall query results are going to be missing some critical components. Knowing which leads are valuable is tied to marketing data. Every department needs to understand the purpose of the data warehouse, how it will benefit them, and what kinds of results they can expect from the warehousing solution.

        134

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        This requirements gathering stage should focus on the following objectives: •

        Aligning department goals with the overall project



        Determining the scope of the project in relation to business objectives



        Discovering your future needs and current needs by diving deep into your data (finding out what data will be useful for analysis) and your current tech stack

        Collect and Analyze Information Often, analysts, supervisors, administrative assistants, and others create analytical and summary reports. These reports can be simple correlations of existing reports, or they can include information that people overlook, with the existing software or information stored in spreadsheets and memos. Such overlooked information can include logs of telephone calls someone keeps by hand, a small desktop database that tracks shipping dates, or a daily report a supervisor emails to a manager. A big challenge for data warehouse designers is finding ways to collect this information. People often write off this type of serendipitous information as unimportant or inaccurate. Another part of this collection and analysis phase is understanding how people gather and process the information. A data warehouse can automate many reporting tasks, but you can’t automate what you haven’t identified and don’t understand. The process requires extensive interaction with the individuals involved. Listen carefully and repeat back what you think you heard. You need to clearly understand the process and its reason for existence. Then you’re ready to begin designing the warehouse.

        135

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Identify Core Business Processes By this point, you must have a clear idea of what business processes you need to correlate. Identify the key performance indicators, such as unit sales, units produced, and gross revenue. Now identify the entities that relate to create the key performance indicators. The data warehouse is a collection of interrelated data structures. Each structure stores key performance indicators for a specific business process and correlates those indicators to the factors that generated them. To design a structure to track a business process, identify the entities that work together to create the key performance indicator. Each key performance indicator is related to the entities that generated it.

        Construct a Conceptual Data Model After identifying the business processes, create a conceptual model of the data. Determine the subjects that will be expressed as fact tables and the dimensions that will relate to the facts. Clearly identify the key performance indicators for each business process, and decide the format to store the facts in. Because the facts will ultimately be aggregated together to form Online Analytical Processing (OLAP) cubes, the data needs to be in a consistent unit of measure. Each row in the fact table is generated by the interaction of specific entities. To add a fact, populate all the dimensions and correlate their activities. Many data systems, particularly older legacy data systems, have incomplete data. Correct this deficiency before you can use the facts in the warehouse. After making the corrections, construct the dimension and fact tables. The fact table’s primary key is a composite key made from a foreign key of each of the dimension tables.

        136

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Locate Data Sources and Plan Data Transformations Identify where the critical information is and how to move it into the data warehouse structure. Move the data into a consolidated, consistent data structure. A difficult task is correlating information between the in-house customer relationship management (CRM) software and the time-reporting databases. Transform the data as you move it from one data structure to another. Some transformations are simple mappings to database columns with different names. Base the decision mainly on cost, including the cost of training or hiring people to use the tools and the cost of maintaining the tools. Also plan when data movement will occur. While the system is accessing the data sources, the performance of those databases will decline precipitously. Schedule the data extraction to minimize its impact on system users (e.g., over a weekend).

        Implement the MVP Plan and Deploy in Production The plan provides a viable basis for estimating work and scheduling the project. The scope of data warehouse projects is large, so phased delivery schedules are important for keeping the project on track. An effective strategy is to plan the entire warehouse and then implement part of it as a data mart to demonstrate what the system is capable of doing. As you complete the parts, they fit together like pieces of a jigsaw puzzle. Each new set of data structures adds to the capabilities of the previous structures, bringing value to the system. Data warehouse systems provide decision-makers with consolidated, consistent historical data about their organization’s activities. With careful planning, the system can provide vital information on how factors interrelate to help or harm the organization. A solid plan can contain costs and makes this powerful tool a reality.

        137

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Benefits The key benefits of data aggregation and data analytics being driven through a centralized system is that it gives teams independence to perform their core tasks while the analytics is automated. Before such an automated process comes into being, teams would first have to strategize how the data will be collected and stored before each project begins. And once the project ends, they will have to then collate the data and analyze it from the purview of whether it made and impact or not. If a data pipeline and a centralized system exists, then they can see and analyze the data in real time.

        Independence Product, sales, and marketing are independent as much as possible. Regular repetitive tasks can be run by the querying team so the BI team can work on complex problems around data modeling and machine learning.

        Upskilling There should be regular trainings that will help team learn the data analysis tools as most of these tools are easy to use with online manuals. For example Tableau online is simple to learn and use it for data analysis. Arranging regular workshops will help free up bandwidth of the data engineering and data analytics team to focus on their core skills while the business teams can derive the necessary insights on their own.

        Cross-Functional Collaboration The ability to integrate data across diverse tools helps everyone collaborate on decision-making and the problem at hand rather than just questioning the reliability of the data. This helps in conflict reduction and fosters a solid team environment. 138

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Data Democratization There should be a practice to empower teams with access to data, insights, and actionable best practices so everyone can be better at their jobs.

        Tactics and Phases To operationalize the project, it can be broken down into three phases. These phases will be aligned with the objectives and key results of the company: •

        Build a marketing technology stack that involves stitching together all the marketing platforms to one system.



        Build the data stack and implement best practices.



        Integrate the sales tech stack with martech and leverage combined insights.



        Leverage the martech stack to improve product insights.

        The Data Stack Architecture The data stack architecture covers how the data initiated at source systems can be ingested into a centralized system for analysis. The centralized stores are then used for analyzing and deriving insights from. The stack is a pipeline that takes the data from the source till the end. It could differ from organization to organization depending on what applications are being used. Typically source systems are advertising platforms, customer relationship management systems and destination platforms are central warehousing databases like MongoDB, Redshift etc.

        139

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Data Flow There are different tools that help in achieving the flow of data from source to destination. The following tools in that order starts from source systems and then moves on to the visualization tools that eventually helps businesses analyze the data: •

        Ingest tools: Tools to centralize data from different sources into a data store (Appsflyer, CRM, etc.).



        Stores: Data lakes and data warehouses, although nowadays the popular notion of a lake house is emerging (Google Cloud Storage, Amazon Web Services, etc.).



        Transform tools: Tools to help clean, aggregate, and denormalize the data for analysis. We also include building features for machine learning and the model building of ML in the transform category (Google Big Query).



        Visualization tools: Tools to visualize cleaned or aggregated data to generate insights (Tableau).



        Publish/serve tools: Tools to publish the reports, aggregates, or models so that applications can use them (Confluence).

        Metadata Layer Metadata includes the structure of data, configurations of the pipelines that created the data, relationships between different data, and other properties (freshness, who has access, etc.). The metadata layer consists of several aspects of the data and the data flow that are used and generated by the running systems.

        140

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        The metadata layer can be composed of the following: •

        Schema/lineage: This includes the core metadata of any data system. At the simplest level, the schema consists of the table and column definitions. There can also be relationships between tables like foreign keys. Lineage is a way to capture how different data is related to each other and understand how one piece of data is generated.



        Statistics: This is runtime metadata. These are metrics about different data and data flows, such as different table sizes, the time it takes to compute an answer, the time it takes to ship data from one system to another, etc. These stats can optimize data flow, understand bottlenecks in the system, understand how the data volumes change over time, and more. One of the key statistics collected is data quality metrics, which provide information about whether analyses are being performed on complete and accurate data.



        Orchestration: This is the most critical part of the metadata layer. It is critically important and should be included in the metadata layer because orchestration must be metadata-driven. Instead of just collecting and showing metadata, metadata’s insights become critical for the data flow itself. This has six main advantages. •

        Metadata is always clean: If metadata is broken, the system is broken, and someone must fix it.



        Observability/auditability out of the box: There is no need for special instrumentation because metadata is always up-to-date.

        141

        Chapter 19

        142

        Business Analytics and Its Importance in Scaling and Execution



        Quality checks: Data quality checks can be incorporated directly into the orchestration without additional integrations.



        Easy debuggability: Lineage and stats drive data flow and so are automatically captured. This makes it easy to debug problems in the data flow with a single pane of glass that shows the metadata in an easy-to-­consume manner.



        Avoid repetition: Mundane operations like reprocessing or doing full refreshes (historical syncs) that should propagate through the entire data flow become a lot easier to manage.



        Tools: Authoring tools can access both the static and dynamic metadata to help data teams figure out how to make changes to their business logic without breaking data pipelines.



        Access control: With metadata being clean, one can specify who can access what schemas and tables at a granular level. Both role-based and policy-based access controls rely on the schema/lineage to provide flexibility.



        Auditing: Keep track of what changes occurred to any of the data or data flows. If orchestration is metadata-­ driven, the orchestration log provides an automated way of auditing those changes. Logging from access control will provide an audit of who performed what operation on the system.



        Observability: Use metadata to observe how the data is flowing through different systems.

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        The Hero of the Story: Microservices The microservices architecture is a cloud-native architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components, or services. These services typically have the following characteristics: •

        Have their own technology stack, inclusive of the database and data management model



        Communicate with one another over a combination of APIs, event streaming, and message brokers



        Are organized by business capability, with the line separating services often referred to as a bounded context

        While much of the discussion about microservices has revolved around architectural definitions and characteristics, their value can be more commonly understood through fairly simple business and organizational benefits: •

        Code can be updated more easily. New features or functionality can be added without touching the entire application.



        Teams can use different stacks and different programming languages for different components.



        Components can be scaled independently of one another, reducing the waste and cost associated with having to scale entire applications because a single feature might be facing too much load.

        143

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Microservices might also be understood by what they are not. The two comparisons drawn most frequently with microservices architecture are monolithic architecture and service-oriented architecture (SOA). The difference between microservices and monolithic architecture is that microservices compose a single application from many smaller, loosely coupled services as opposed to the monolithic approach of a large, tightly coupled application.

        Benefits of Microservices The following are the benefits of microservices.

        Precise Scaling With microservices, individual services can be individually deployed, but they can be individually scaled, as well. The resulting benefit is obvious: done correctly, microservices require less infrastructure than monolithic applications because they enable precise scaling of only the components that require it, instead of the entire application in the case of monolithic applications.

        Experimentation and Lower Risk In a microservices model, components are deployed independently and communicate over some combination of REST, event streaming, and message brokers—so it’s possible for the stack of every individual service to be optimized for that service. Technology changes all the time, and an application composed of multiple, smaller services is much easier and less expensive to evolve with more desirable technology as it becomes available.

        144

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Independently Deployable Perhaps the single most important characteristic of microservices is that because the services are smaller and independently deployable, it no longer requires an act of Congress to change a line of code or add a new feature in an application.

        Microservices Architecture Options Here are your options for architecture.

        Database Integration In this pattern, two or more services read and write data out of one central data store. All of the services go to this central data store. This can be illustrated using the banking application example from our previous post, which takes login, user profile, transactions, notifications, credit score, and spending reports as separate services defined by the business functionalities. Figure 19-1 depicts how database integration can be utilized for different types of microservices.

        145

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Figure 19-1.  Database with different microservices One of the significant advantages of database integration is simplicity. The transaction management is more straightforward as compared to other patterns. This is perhaps the most widely used pattern of integration—but also the most abused. 146

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        This pattern couples services together undesirably, making the microservices architecture more difficult to change and expensive to scale. Defining the data ownership and updating the schema can become a messy process—every change requires re-compiling and deploying all of the services. It pushes toward highly orchestrated, big-bang-style deployments. This type of integration can create significant obstacles in maintaining the autonomy of microservices. Under the needs of high scale, the only option is to throw more hardware at the database, and even then it becomes difficult to avoid deadlocks in the database and row-level contentions.

        Synchronous API Calls Figure 19-2 explains how communication between different microservices can happen through synchronous API calls. It gives a way to speak to each of these services.

        Figure 19-2.  API way of managing microservices

        147

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        In this integration pattern, the services communicate synchronously through an API. All the access to each other’s data is coordinated through an API in a request-response fashion, and the service waits for data from the API to perform its action. In the previous example, if the transaction service needs to read the user profile data, it calls the user profile API and gets what it needs. This provides a decent abstraction over a direct database call and offers excellent flexibility in terms of technical choices. This provides the benefit of hiding many implementation details: the abstraction gives us the freedom to change technologies without affecting our clients. For example, the user profile service could use Java and MySQL, while the transaction service could use SQL Server and .NET, and they can still easily speak to each other through the API. However, this is not much different than the direct database integration pattern. Adding another network hop on top of a database call can also inhibit scale: by increasing the workload, performance decreases—it is significantly at odds with most distributed systems fallacies. This integration pattern also makes transaction management difficult and inhibits autonomy, as services depend on one another’s uptimes. In microservices, if you have to read data synchronously outside of your system boundary, that is a service-oriented architecture smell.

        Winner: Extract, Transform, and Load Figure 19-3 depicts what an extract, transform, and load (ETL) model looks like. This removes the dependency on synchronous API calls and load on database.

        148

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Figure 19-3.  ETL model ETL entails synchronizing data via background processes on a predefined schedule. This data can be pushed or pulled. Only backend ETL processes need database access. It is asynchronous, meaning services can execute without waiting for a “callback.” This integration pattern also hides implementation details nicely. It provides reasonable decoupling because the services are not dependent upon one another’s uptimes. Live users don’t get affected by the uptimes or the processing time. The ETL processes have to change with the source and destination databases. With ETL integrations, data consistency depends on the schedule and duration. Figuring out the change delta could get too complicated. In these situations, the teams fall back on pushing the entire dataset out. That makes processes very long-running, significantly undermining their usefulness. Reporting services are a natural fit for this type of integration. These processes have their place but usually get very involved with time. They should be used only when the stale data is acceptable in the system.

        149

        Chapter 19

        Business Analytics and Its Importance in Scaling and Execution

        Summary All companies, big or small, rely on data to understand their potential. A small shop owner goes through the profits made on a daily basis and then understands when it is the off-season. They then use the data to make relevant decisions. Similarly, bigger companies have to invest in good data-driven architecture to make sense of their data. Both real-time and past data analytics are important aspects for understanding the company’s fortunes or misfortunes.

        150

        PART V

        Processes

        CHAPTER 20

        Data Security In the current world, we have moved toward cloud and cloud-native architectures, both for the platform and the infrastructure. Therefore, data security, as well as continuous application security, will focus on cloud-­ native security. The security must be built into the assets that you are working to secure. Integrated security also enables your workload to be mobile, from the cloud.

        Business Challenges The recent digital transformation in industry has profoundly altered every aspect of how today’s businesses operate and compete. The sheer volume of data that enterprises create, manipulate, and store is growing, which drives a greater need for data governance. In addition, computing environments are more complex than they once were, routinely spanning the public cloud, the enterprise data center, and numerous edge devices ranging from Internet of Things (IoT) sensors to robots and remote servers. This complexity creates an expanded attack surface that’s more challenging to monitor and secure. At the same time, consumer awareness of the importance of data privacy is on the rise. Fueled by increasing public demand for data protection initiatives, multiple new privacy regulations have recently been enacted, including Europe’s General Data Protection Regulation (GDPR). These rules join longstanding data security provisions like the © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_20

        153

        Chapter 20

        Data Security

        Health Insurance Portability and Accountability Act (HIPAA), protecting electronic health records, and the Sarbanes-Oxley (SOX) Act, protecting shareholders in public companies from accounting errors and financial fraud. With maximum fines in the millions of dollars, every enterprise has a strong financial incentive to ensure it maintains compliance. The business value of data has never been greater than it is today. The loss of trade secrets or intellectual property (IP) can impact future innovations and profitability. So, trustworthiness is increasingly important to consumers, with a full 75 percent reporting that they will not purchase from companies they don’t trust to protect their data.

        Data Security Strategies A comprehensive data security strategy incorporates people, processes, and technologies. Establishing appropriate controls and policies is as much a question of organizational culture as it is of deploying the right tool set. This means making information security a priority across all areas of the enterprise.

        Physical Security of Servers and User Devices Regardless of whether your data is stored on-premises, in a corporate data center, or in the public cloud, you need to ensure that facilities are secured against intruders and have adequate fire suppression measures and climate controls in place. A cloud provider will assume responsibility for these protective measures on your behalf.

        154

        Chapter 20

        Data Security

        Access Management and Controls The principle of “least-privilege access” should be followed throughout your entire IT environment. This means granting database, network, and administrative account access to as few people as possible and only those who absolutely need it to get their jobs done.

        Application Security and Patching All software should be updated to the latest version as soon as possible after patches or new versions are released.

        Backups Maintaining usable, thoroughly tested backup copies of all critical data is a core component of any robust data security strategy. In addition, all backups should be subject to the same physical and logical security controls that govern access to the primary databases and core systems.

        Employee Education Training employees in the importance of good security practices and password hygiene and teaching them to recognize social engineering attacks can transform them into “human firewalls” that can play a critical role in safeguarding your data.

         etwork and Endpoint Security Monitoring N and Controls Implementing a comprehensive suite of threat management, detection, and response tools and platforms across your on-premises environment and cloud platforms can mitigate risks and reduce the probability of a breach. 155

        Chapter 20

        Data Security

        Security Plan Infrastructure security means securing the cloud infrastructure of a company that has cloud assets on services like Google Gsuite, Amazon web services etc. It encapsulates providing visibility across cloud accounts scattered across the cloud infrastructure. It also sets up the process for ownership of data security, alerts, and automated remediation. •

        Visibility in cloud accounts: Cloud visibility is the ability to have a detailed view of all activity in your cloud by which you can identify security threats and inefficient performance.



        Data security: The plan includes who is responsible for data security and incident response preparations.



        Security process: You should have a detailed process for the three important role players of security, i.e., people, process (static), and technology.



        Managed detection and response: The detection and response should be documented, and drills should be done to ensure that the team is ready to enact an immediate and efficient response to threats when they happen.

        Roles and Responsibilities of a Security Team The following are the responsibilities of a security team: •

        156

        Help maintain security awareness programs and ensure that engineers stay informed annually of the top security risks and best practices

        Chapter 20

        Data Security



        Create security policy, standards, procedures, and guidelines for engineering to consume



        Perform security reviews of products and services



        Measure and grow security maturity across your engineering teams



        Triage security issues and provide recommended fixes



        Facilitate independent security assessments and penetration tests



        Evaluate new tools, processes, and frameworks; drive adoption of the best ones



        Provide infrastructure and application security

        SLA for Bug Reports A service level agreement (SLA) is an agreement between two different companies, a company and a consultant, and also within the company, such as between two departments. In this context, the SLA would encompass the obligation of the security team to respond to bug reports about the company’s infrastructure coming in through any of the channels, be it emails, social media, phone, etc. The following walks you through the bug report process: 1. Reply to email once a day for all the emails received. (Have a threshold of less than 20 unread emails in a day for the bugs received. If the number of emails ins more than 20 for 3 days continuously then that is a cause for concern. It means we have reached the threshold and we have to act on the bug report emails diligently by figuring out if there is a systemwide breach that is causing it. The threshold can be different for companies of different sizes.) 157

        Chapter 20

        Data Security

        2. A designated person on the cloud-native security team (CNST) should create a finding on the internal security management system with all the information mentioned after receiving the email and forwarded it to the security vendor or an internal security specialist. 3. If there’s a security vendor, then the vendor or specialist will verify whether a bug is valid within the next working day of the finding being raised. 4. If valid, the CNST-designated person raises a bug/ issue with the development team with the priority and severity as indicated by the specialist within four to eight hours of validation. The timeframe changes from company to company. But a highly severe bug has the potential to create a bad reputation for the business, so the sooner they are addressed, the better it is for the business. 5. If invalid, an apt response should be sent to the bug reporter as provided by the specialist. Use a standard template. 6. Once the bug is fixed, the development teams provide an update on the bug depending upon its severity.

        Security Audits An IT security audit is a comprehensive assessment of an organization’s security posture and IT infrastructure. Conducting an IT security audit helps organizations find and assess the vulnerabilities existing within their IT networks, connected devices, and applications. It gives you the opportunity to fix security loopholes and achieve compliance. 158

        Chapter 20

        Data Security

        This includes things such as vulnerability scans to find security loopholes in the IT systems or penetration tests to gain unauthorized access to the systems, applications, and networks. Finally, the penetration testing reports generated after performing all the necessary procedures are then submitted to the organization for further analysis and action. An IT security audit also comprises the physical part, in which the auditor verifies physical hardware access for security and other administrative issues. However, this section covers only the nonphysical part of an IT security audit.

        Benefits of IT Security Audit An IT security audit reveals the underlying vulnerabilities and security risks in an organization’s IT assets. Identifying risks, however, has a positive rippling effect on the organization’s overall security. How? The following are the answers: •

        Weighs your current security structure and protocols and helps you define a standard for your organization with the audit results



        Mitigates hacker risks by discovering potential hacker entry points and security flaws well in advance



        Verifies how compliant your IT infrastructure is with top regulatory bodies and helps you achieve compliance



        Finds lag in your organization’s security training and awareness and helps you make informed decisions toward its betterment

        159

        Chapter 20

        Data Security

        Requested Evidences and Correlation The auditors will request evidence related to security, infrastructure, and business continuity. Generally, depending on the type of audit, the audit period can last between a week to a month. Types of audit could be IT general security audit, International Organization for Standardization (ISO) and so on.

         ey Documents and Evidence That Will K Be Requested The following are key documents you will need to provide to auditors:

        160



        HR-related documents that include candidates who joined, were terminated, and exited the organization during the audit period



        Asset inventory



        All the policy-related documents



        AV-related evidence, backup, and CloudWatch alerts



        Vulnerability Assessment and Penetration Testing (VAPT) reports



        Access control of the database and production environment



        Firewall and config review evidence

        Chapter 20

        Data Security

        Summary When properly implemented, robust data security strategies will protect an organization’s information assets against cybercriminal activities, but they also guard against insider threats and human error, which remain among the leading causes of data breaches today. Data security involves deploying tools and technologies that enhance the organization’s visibility into where its critical data resides and how it is used. Ideally, these tools should be able to apply protections such as encryption, data masking, and redaction of sensitive files, and should automate reporting to streamline audits and adhere to regulatory requirements.

        161

        CHAPTER 21

        Why Do Businesses Fail? Typical reasons for business failures through history are wars, recessions, high taxation, high interest rates, excessive regulations, poor management decisions, insufficient marketing, inability to compete with other similar businesses, or a lack of interest from the public in the business’s offerings. But there could be reasons intrinsic to the business itself that lead to business failures. In this chapter, we will look at process-related issues that can lead to business failure and how to avoid them by building robust processes that are self-healing and self-correcting to help businesses thrive.

        Solving Process Problems There are different frameworks that try to solve process problems using innovative trackers. Having a clear-cut project management framework can help reduce these failures. Every initiative needs to have roles that within either the RACI or DACI model defined.

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_21

        163

        Chapter 21

        Why Do Businesses Fail?

        RACI

        Figure 21-1.  RACI model The RACI model asks the question, who is responsible for completing certain tasks? A RACI matrix is the simplest, most effective means for defining and documenting project roles and responsibilities. Knowing exactly who is responsible, who is accountable, who needs to be consulted, and who must be kept informed at every step will significantly improve your chances of project success. RACI stands for the following:

        164



        Responsible: Who is responsible for participating in completing an action?



        Accountable: Who is accountable for making sure an action is complete?

        Chapter 21

        Why Do Businesses Fail?



        Consulted: Who is consulted during the process of completing an action?



        Informed: Who is informed about the state of an action?

        DACI

        Figure 21-2.  DACI model The DACI model asks the question, who decides on a course of action for a particular task or function? The DACI decision-making framework improves a team’s effectiveness and velocity on projects by assigning team members specific roles and responsibilities when it comes to group decisions. DACI stands for the following: •

        Driver: The person who drives the decision



        Approver: The person who makes the decision

        165

        Chapter 21

        Why Do Businesses Fail?



        Contributors: The people or teams whose work or knowledge aids in the project



        Informed: The people whose work might be affected by these decisions and who therefore need to be kept in the loop

        Don’t Do Ad Hoc Always have multiple pods or squads running sprints, as explained in Chapter 4. They help in keeping the project running even if a small part of it fails. For this to happen, always have rituals and processes that help keep tabs on the progress. Businesses fail because the rituals necessary to run the processes are not being followed. We have covered all the rituals in detail in Chapter 1 for the company in general and Chapter 18 for the Tech team specifically. Here we will be discussing on what rituals if followed properly will prevent the business from failing.

        Requirements Gathering All the requirements that come from the stakeholders will be segregated and assigned to specific teams based on their responsibilities. These are then collated in the backlog section under each team’s project management tool. Based on the priority, these tasks are then categorized and assigned to the development teams. This basic ritual is a must to help companies drive the culture of fostering prioritization of all key tasks without with the objectives of the company will not be met.

        166

        Chapter 21

        Why Do Businesses Fail?

        Epics, User Stories, and Tasks All the requests (new features, change requests, and migration requests for new technology) from stakeholders are captured via a form or software and taken to a logical end through a sprint process. •

        Epic: A larger story that drives a new flagship feature or a product



        User story: The breakdown of a larger story into smaller stories



        Tasks/subtasks: The breakdown of larger stories into smaller chunks

        Not creating Epics, user stories and tasks in an organized and repetitive way leads to failures at a project level initially and at a business level when the problem compounds and becomes an all-pervasive norm.

        Follow Sprints For smaller teams, it is imperative that all the issues in the backlog are prioritized and put into action. This will happen through different phases in the scrum model. Figure 21-3 shows how the events happen in the agile methodology. •

        Sprint timelines: 2 weeks



        Tasks prioritization: Alternate Friday



        New sprint: Every alternate Tuesday



        Sprint ends: Every alternate Monday

        Figure 21-3 depicts a typical sprint framework that can be used to deliver larger epics or projects.

        167

        Chapter 21

        Why Do Businesses Fail?

        Figure 21-3.  Sprint process The following steps detail the sprint process: 1. All the issues in the backlog are prioritized by the respective development teams. The issues are then added to the “Create Sprint” task in sprint planning, and the sprint is activated to track the progress. 2. Once the sprint is activated, the daily scrum is initiated to review the team’s progress on the sprint goals. Figure 21-4 shows how the review happens in a daily scrum. 3. The sprint review is done at the time of prioritization to review the work completed in the sprint with the stakeholders and discuss the tasks for the upcoming sprints. 4. Once the sprint is closed, the team meets to review the last sprint and identify areas for improvement called retrospection.

        Daily Scrum As described in the scrum guide (https://scrumguides.org/), the purpose of the daily scrum is to inspect progress toward the sprint goal and adapt the sprint backlog as necessary, adjusting the upcoming planned 168

        Chapter 21

        Why Do Businesses Fail?

        work. The daily scrum is a 15-minute event for the developers of the scrum team. To reduce complexity, it is held at the same time and place every working day of the sprint. If the product owner or scrum master is actively working on items in the sprint backlog, they participate as developers. The developers can select whatever structure and techniques they want, as long as their daily scrum focuses on progress toward the sprint goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The daily scrum is not the only time developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the sprint’s work. Figure 21-4 depicts what needs to be spoken by everyone who is part of the scrum meeting on a daily basis.

        Figure 21-4.  Daily scrum questions to be answered

        169

        Chapter 21

        Why Do Businesses Fail?

        If these processes are overlooked, then the problems across the company creep in and cascade to all areas. These problems lead to the following: •

        Lack of clarity



        Miscommunication



        Ineffective change management



        Lack of innovation because of repetitive tasks and initiatives

        Summary There’s no one-size-fits-all answer to the question of why businesses fail. Just not following sprint processes doesn’t guarantee a business failure. If all the other fundamentals of the business are solid and the sprint processes and all other rituals are followed, the business will surely succeed is a way of saying; it will not fail.

        170

        CHAPTER 22

        Exceptions to Processes: Good or Bad? Exceptions are required to function in any field and not just in technology. The moon mission in 1969 had multiple exceptions. How did the people overcome these exceptions and still manage a mission as big as that? What we have to learn from this and how we navigate scenarios when exceptions occur are some of the questions that are covered in this chapter. Generally, the exceptional cases are handled first in any project, and then we go to the easy use cases. This will give us the confidence that we can tackle anything.

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_22

        171

        Chapter 22

        Exceptions to Processes: Good or Bad?

        Exceptions in the Moon Landing

        Figure 22-1.  Figure depicting the error astronauts faced while landing on the Moon The lunar module that was being piloted to the moon surface in 1969 began to report errors when the craft was just seven-and-a-half minutes away from landing. Two obscure error codes were involved, each consisting of four digits, and indicated there was an issue or problem occurring in the spacecraft. During the design of the system for the lunar lander, the developers had come up with a slew of error codes that could be displayed if the computer detected something amiss on the craft. When the astronauts did countless simulated landings, not all of the possible error codes were tested, and thus there were some error codes that the astronauts had never seen. “It’s a 1202 error.” Within mission control, there were blank stares as by and large no one knew what 1202 was about.

        172

        Chapter 22

        Exceptions to Processes: Good or Bad?

        But the programmers had anticipated this error might someday occur and so had established a system-internal aspect that would automatically do a fast reboot and then a memory restore to try to get the computer working again. In theory, the computer was going to be able to resolve the error, without needing any human intervention.

         hat Can Driverless Cars Learn W from the First Moon Landing? Today, driverless cars can learn from the first moon landing. You need to anticipate and code for wayward sensors. You cannot assume that the sensors on a driverless car will be working flawlessly. Besides the obvious aspect that the sensor might get blinded by dirt or debris, there is also the chance that the sensor could go awry due to some internal bug or issue. Make sure to code for this possibility and have some provision for what to do once the matter arises. Do not ignore edge cases. The focus for most driverless car efforts right now is on driving during normal, everyday conditions, and not dealing with unusual or infrequent kinds of driving situations (so-called “edge” aspects). This belies the true aspects of driving, which can include foul weather, bad roadways, and the like. Autonomous cars that are being tried on our public streets need to be ready to handle edge or corner cases. From a software perspective, the same kinds of issues can occur, including hidden bugs or suddenly appearing faults, that could have happened back in 1969. Let’s make sure that we learn the lessons of the past and be extremely mindful when designing, coding, testing, and fielding autonomous cars.

        173

        Chapter 22

        Exceptions to Processes: Good or Bad?

        Not All Stories End Well On July 22, 1962, an Atlas rocket launched successfully with NASA’s Mariner 1 spacecraft encapsulated in its fairing. NASA had hoped to be the first to successfully fly by Venus and counter the Soviet Union’s lead in the space race. Less than five minutes into the flight, it was clear Mariner 1 wouldn’t even reach Earth’s orbit. A range safety officer tracking the rocket’s flight detected an unexpected yaw-lift (northeast) maneuver, meaning its guidance system had faltered. The rocket was unable to steer itself as intended and was heading toward a crash, either in the North Atlantic shipping lanes or, worse, in an inhabited area. The officer had no choice but to order the destructive abort. The rocket along with Mariner 1 exploded, and $80 million dollars ($720 million in 2021) was lost. It turned out that a programmer had left a hyphen out of an equation while entering its hand-transcribed code into the rocket’s computer. This fed false information to the guidance system, and ultimately all that was left was debris. The human error was fixed for Mariner 2, which launched shortly after and conducted the first successful flyby of Venus. These exceptions occurred because of human error or not understanding or comprehending the systems. In the case of the space missions, sometimes we have to rush the release, because there’s pressure from the press, from other countries, or from politicians. These exceptions nevertheless cause problems. Why are we looking at space missions while looking at exceptions? It’s because the scale of them is easy to comprehend. When a space mission fails because of a missing semicolon, it gets noticed, but when a similar mistake happens in a company that is now launching a new website and the site goes down, the scale isn’t as huge as that of a space mission but impacts the business in the same catastrophic manner.

        174

        Chapter 22

        Exceptions to Processes: Good or Bad?

        Why Do Businesses Seek Exceptions? Why do different wings of the business, knowing very well that exceptions are bad, ask for exceptions? The reasons are as follows: •

        There’s a promise made for publicity without consulting the tech team about whether a certain website can be ready by that time



        A promise to the investor



        A primetime slot on TV that will lead to publicity



        Misunderstanding of the underlying technology and thinking that a complicated module is easy to replicate into a new version and can be launched without much testing so bargaining for getting it done in a lesser time

        All these exceptions lead to disasters if not managed well. Some of these are genuine cases where there is good ground that can be captured, especially because of quick publicity. So in these cases, the processes followed can be exempted, and the teams that are following these processes must ensure that there are means to manage the exceptions well.

        Management by Exception Management by exception consists of four steps: 1. Setting the objectives and defining what the norm should be 2. Assessing performance to see whether the performance is on track 3. Analyzing work or records to determine where performance deviates from objectives 4. Investigating and solving the exceptions to the norm 175

        Chapter 22

        Exceptions to Processes: Good or Bad?

        Setting Objectives The first step in the process of management by exception is to set realistic targets to use as a benchmark. Key areas might include sales, production, and expenses. Unfortunately, you can’t just say “I want to sell a million dollars’ worth of product this month.” If you run a small business, the goal could be unreachable. If the business is large, you could be underestimating its potential. Businesses usually look at records to determine the correct norms. If you want to build in a small percentage of growth, go ahead, but be realistic. Budgets present a great starting point. After all, if you have set limits on costs and targets for turnover and profits, you can use them to monitor progress. But you don’t want to react too late. Even a month of deviations could cost you dearly if you pick up the deviation only at the month’s end. Consider splitting up targets and monitoring into smaller chunks that will allow management to be responsive. Now that you have targets, you can start defining what constitutes a deviation. For example, 0.1 percent more or less than your target shouldn’t be a trainwreck, so what constitutes a deviation that calls for management action? In complex businesses, statistical control charts are drawn up to determine the effect of deviations, but if your business is a relatively simple one, commonsense and a bit of number crunching should give you the answers.

        Assessing Performance Before you can assess performance, you need accurate, real-time performance records. What data will you collect? How will you collect it? How often will you assess it? The first two of these questions depend on you and your business, but the final one has a general answer: the more frequently you can assess performance data, the faster you’ll pick up deviations, investigate them, and address them. 176

        Chapter 22

        Exceptions to Processes: Good or Bad?

        Since gathering a great deal of data manually can take even more time than management by exception is meant to save, automated record keeping and analysis is best. Thus, software that monitors, reports on, and analyzes workflows, as well as accounting software that produces financial analytics, are examples of software that you will find useful.

        Analyzing Your Deviations You will seldom get results that match your targets down to the last detail. However, there’s no point in investigating insignificant deviations, so the analysis is based on significance. When analyzing your reports, you will reach one of two conclusions. •

        There was no significant deviation: In that case, there’s no need for further action.



        One or more deviations are significant: If you reach this conclusion, it’s time to take action. If the data is analyzed by an employee or a junior manager, they must know who will take the required action and what to report to their superiors.

        If you are handling a deviation, the first step is to see why it happened. It could simply be a mistake in the data. Alternatively, there could be a very good reason for the deviation. For instance, if you’re selling ice cream, a chilly day will cause your sales to plummet. Deviations can also be a good thing. Perhaps your staff is trying a more efficient process, or there has been a significant saving on an expected cost.

        Resolving Exceptions Now that you know what performance criteria have not been met or have been exceeded and why it happened, it’s up to you as a manager to decide what corrective action to take. In addition, you need to decide whether 177

        Chapter 22

        Exceptions to Processes: Good or Bad?

        the exception is likely to recur and whether it impacts other targets. The changeable nature of the business environment, both internal and external, means that you will need to keep revisiting and revising your benchmarks. Let’s say business expenses have risen by 3 percent. Do you need to revise your sales targets? Would it be realistic to do so? Are there areas where you could be saving costs to mitigate the effects of increased prices? How will these changes affect your benchmarks? Advantages of management by expectation lead to the following:

        178



        Best use of management time: The most obvious advantage of management by exception is the way it impacts how managers use their time. Why monitor, analyze, and micromanage things that are going smoothly? When things are going well, employees can make their own decisions, leaving managers free to focus on decision-making that’s related to problem areas.



        Rapid response: If your monitoring systems are responsive and up-to-date, management by exception spots any problems in good time. If automated systems alert you to problems immediately, all the better. Then there isn’t time for the deviation to have a compounded effect.



        Motivates staff to perform: Most people like being able to get on with their work with minimal management intervention. It allows them to make decisions, try new things that produce better outcomes, and “own” their task areas.

        Chapter 22

        Exceptions to Processes: Good or Bad?

        Summary Exceptions are OK if they do not lead to irreversible consequences that could be bad for the business. When the server goes down, we scramble to get it up and running, and we sometimes take exceptional routes to avoid long downtimes. But making exception as a means to drive all requirements in a business should be avoided. As the business grows, making well planned and objective driven decisions becomes more important than hasty exceptional decisions for quick turnarounds.

        179

        CHAPTER 23

        Processes as a Speed Booster, Not a Speed Breaker Optimizing your processes is key to achieving your business goals, and that’s where business process management comes in.

        What Is Business Process Management?

        Figure 23-1.  Figure illustrating various parts of Business process management © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_23

        181

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker

        Business process management (BPM) is a discipline, or practice, through which companies can improve their processes. Rather than taking things for granted, you analyze, measure, and monitor current processes. From there, optimization starts. This could be through streamlining existing processes, outsourcing certain business activities, or automating repetitive subprocesses.

        How Can Process Mapping Help? Without efficient processes you become inefficient, ordinary, and uncompetitive. With effective processes, you can replicate your successes over and over again. Process mapping is often done through flowcharts, and it details every step from start to completion. It’s a great way to spot bottlenecks or other problems in existing processes, as well as set up new processes. But to make a start with process mapping, you need to understand what processes your business already has and what it needs.

        Areas for Process Improvement There are a number of core processes that every business needs, and each one can be honed to make you the best in your field. We’ve compiled a list for you so that you can compare your current operating procedures against ours in the following sections and see where you may need to redesign, streamline, and optimize your own. In addition, there are sample template processes for the majority of the list. This can help with standardization and makes process mapping much quicker. These processes have been designed to provide a starting point from which you can tailor them to suit your business.

        182

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker

        Customer Success The following section explains how we can ensure customer is satisfied with the product or services offered by our business. The 3 key points that defines the customer’s success metrics are Customer onboarding, Account management and Offboarding. •

        ​ ustomer onboarding: Create the best impression with C your new customer with a solid onboarding process. Set expectations and demonstrate that they made the right decision in engaging your company. Have a clear set of activities in mind—that could be an introductory phone call with a follow-up email, for instance—and ensure all your team members know what’s expected of them. We’d argue that this is in the top three of processes that every business needs.



        Account management: This process defines how you communicate with your customers on an ongoing basis. Arranging regular checkpoints allows you to investigate opportunities for upselling or extending the service you provide. Your information technology should be set up to help here, providing you with up-to-date customer information to personalize your outreach.



        Customer offboarding: Although unwelcome, you can ensure your customer receives the best experience when you stop working with them. The smoothness with which this happens can make the difference between a future referral and making your company one to avoid. Again, make sure your information systems are up-to-date so you can personalize this— and gather relevant information to decrease the chances of it with future customers. 183

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker

        Finance

        Figure 23-2.  Figure illustrating a Financial deal Finance processes are the backbone of every company. Aside from enabling you to keep the rest of your business running, they are required to comply with the regulations in your country. Businesses have to complete tax declarations and file end-of-year accounts, and comprehensive processes for these activities means that you reduce the risk of noncompliance.

        184



        Budgets: How you calculate and monitor your company’s budget is of the utmost importance. A process to ensure that expenditure is kept in line and that the budget is being tracked over the financial year will reassure you that your business is operating within its means.



        End-of-year accounts and annual returns: This process describes how to compile the end-of-financial year accounts and annual returns. Although the exact procedure will vary from country to country, a robust process will ensure that information is submitted accurately and on time.

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker



        Payroll: Setting up a process for running the payroll, whether it’s monthly, twice a week, or even weekly will mean that nothing is forgotten. Ensure that all relevant additions and deductions are made and that any unique circumstances are taken into account.



        Taxation: This process relates to the country’s taxation laws. Businesses benefit from reductions in tax, so a process for preparing and submitting paperwork will mean you recoup the money owed to you.

        Human Resources Your business wouldn’t be able to run without its most important asset: its employees. Keeping your staff safe and happy should be one of your company’s top priorities. It’s not just about improving their workflows; it’s about the experience in the company as a whole. That’s why it’s no surprise that this section includes the largest number of processes every business needs. Note that although the following templates are largely tailored to UK employment law, the principles will apply more widely. •

        Disciplinary and grievance: There are four main processes relating to the disciplinary and grievance procedures: responding to a formal grievance, disciplinary investigation, disciplinary hearing, and disciplinary appeal. There are multiple decision points in these processes, and it’s important to have clear expectations at every point. Although these processes are (ideally) likely to be used infrequently, it’s important that you comply with the employment law when they are needed. Any business process modeling you do needs to take this into account.

        185

        Chapter 23

        186

        Processes as a Speed Booster, Not a Speed Breaker



        Employee leave: As well as a clear process for how employees request holidays and notify employers of the need for sick leave, there is also parental leave to consider. Having processes in place for when employees request maternity or paternity leave will help manage the transition period. State-of-the-­ art software can make this easier—for instance, by automatically checking requested dates against a global calendar and informing HR of how many staff members are away.



        Employee onboarding: Businesses often underestimate how important their employee onboarding process is to the retention and ongoing success of their staff. A comprehensive onboarding process will reassure employees they’ve joined a company that cares about supporting its staff.



        Employee offboarding: Similar to how a customer offboarding process can encourage positive reviews and referrals, a smooth employee offboarding process will make sure nothing is forgotten and will leave your former team members with a good impression of your company.



        Flexible working request: A request from an employee for regular flexible or remote working is a right for certain employees. Human resources are responsible for handling their requests in the correct way. This may be an ongoing process, as you may make it reliant on fulfilling certain metrics, so it’s important not to treat this as a one-off event.

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker



        Performance and appraisal: Transparent processes for performance reviews and appraisals help your employees understand what they need to be successful in their role. Letting them know what metrics are being monitored and what their managers are documenting can help them respond appropriately. In addition, effective processes should clarify what constitutes performance that needs to be improved upon.



        Recruitment: Recruitment is the main HR process that interacts with people who are not yet employed members of staff. As such, it’s even more important to have a process that ensures fairness and transparency when it comes to decision-making. If candidates are aware of the process up front, they will be more likely to have a positive experience with your recruitment team.



        Redundancy: While every business hopes to never have to use a redundancy process, if it is needed, it’s one that has strict rules around how it is enacted. Depending on the employment law in the country in which you operate, redundancies may be subject to a number of reviews and may involve external parties to help ensure it is compliant.

        187

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker

        Operations

        Figure 23-3.  Figure illustrating multiple cogs of the operations system of an organization Operational processes cover everything in a business relating to its day-to-­ day running. The operations department enables other teams to do what they do best, while improving the overall functionality of the company behind the scenes. Its key responsibilities are process review, continuous improvement, and how the business creates and adapts its strategy. It’s vital that the operations department understands the BPM methodology, as they’re mostly responsible for any business process re-engineering that will go on. Without this, companies will struggle to analyze, monitor, and streamline processes. •

        188

        Partnerships: Instigating and developing partnerships with other businesses in similar or complementing sectors can be a key way to grow your business. Ensure that you make the most of these connections by following a process designed to keep your partners and stakeholders in the loop and thinking of you first whenever a relevant opportunity arises.

        Chapter 23

        Processes as a Speed Booster, Not a Speed Breaker



        Policy review: A process loses its worth as soon as it stops being reviewed and updated. Regular policy reviews not only mean that errors are reduced and that your business stays compliant but that you can actively look for places where improvements and efficiencies can be made. This is key to a successful business process improvement strategy.



        Procurement/tendering: Every business needs tools or software to run on. Documenting how you manage procurement or a tendering process will mean that you take all factors into consideration to achieve the right outcome for your business.



        Strategy: Your business strategy is the way you make decisions over what to do (and what not to do) and shapes the overall direction of the company. It’s important to understand your core business goals, to review your targets at regular intervals, and to have a clear process for setting and defining these targets.

        Sales and Marketing Often overlooked, the sales and marketing processes in your business are what will attract and persuade leads to become your customers. Once you’ve found strategies that work, it’s time for standardization. You want to make sure your activities are carried out the same way every time by following your processes. •

        Competitor analysis: Especially in a crowded industry, it’s key to keep an eye on your competitors. Having a process you can refer to that allows you to conduct a thorough competitor analysis will allow you to spot opportunities for differentiated positioning and offerings. 189

        Chapter 23

        190

        Processes as a Speed Booster, Not a Speed Breaker



        Customer acquisition: The ways in which you acquire customers will be unique to your business. The strategies may be common, but what makes your business successful is the knowledge and expertise you have built up in this process. Your team members should know exactly how you do digital marketing, how you do a sales call, or how you approach events. Having a documented customer acquisition process is essential.



        Publicity: Whatever your industry, you will need to promote your company to potential customers. This could be through events, mentions in the press, or more traditional advertising. However you do it, putting together an optimized process will make sure that you don’t miss out on any opportunities. If you’re outsourcing any aspects of this, make sure you have a process in place to check in with the third party.



        Newsletter: A common strategy to capture and nurture your leads before they purchase from you is to have a process for compiling a newsletter. Your newsletter should reflect your business and the image you want to send out. Don’t be afraid to add some information about what your company has been up to behind the scenes—people love the personal detail.



        Campaign: Whether this is a digital advertising campaign or one centered around print materials, there are commonalities between each campaign you carry out. The aim or desired result needs to be decided up front, as well as criteria such as the budget and the audience. Having clear metrics that you can track is key to monitoring the success of your campaigns.

        Chapter 23



        Processes as a Speed Booster, Not a Speed Breaker

        Website: A business website is the modern-day shop window. Ensuring it is kept up-to-date and that it accurately reflects your target audience is an ongoing job. You don’t want any bottlenecks where the entire content and sales teams are waiting for a single web developer to update everything! Make sure your process for updating your website avoids these potential problems.

        Summary Running a business and keeping all the plates spinning is by no means easy. But simply having a list of the 25 processes that every business needs is the first step in ensuring you’re on top of everything. The next step is to make these processes truly work for your business or public-sector organization by customizing them to suit your needs and circumstances.

        191

        CHAPTER 24

        Are Processes Sacred? The ultimate goal for any business is to achieve maximum success. This applies whether you’re the sole owner of a dog-walking business, you run a small business, you lead a small or medium enterprise, or you work for a huge manufacturing business with many people sitting on the board. If you want to achieve success, several steps will have to be followed, specifically called business processes. In this chapter, we’ll look closely at the business process. You’ll learn about the different types, which are the most valuable, and why the business process is important. We’ll also share some business process examples so you can get a better idea of how they work.

        What Is a Business Process? A business process includes a combination of steps that are interlinked. Think of it as a checklist of best practices and methods on how to run your business. Each step will be assigned to a specific person, and the ultimate goal is to deliver a service or product to the customer.

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_24

        193

        Chapter 24

        Are Processes Sacred?

        To be most effective, the task should be assigned to the person who is most capable. It’s possible for the steps to be repeated over and over again and actioned by several people in an optimized and standard way.

        Why Business Process Is Important Business processes are important because they are a step-by-step guide that describes how things are done in the best possible way and that makes it easier to focus on improving business processes. Business processes have a vital role to play in the efficient and effective functioning of the organization and structure. Why is the business process important? If a business process is well-planned and strategic, it will help in the following ways:

        194



        Reduced risk and expenditure: A business process lays out the most efficient way to do a job, taking into account future shortcomings. This reduces risk and expense.



        Reduced human error: Tasks are given to people who are more capable, thereby reducing the risk of human error.



        Improved efficiency: Moves and relevant steps are clearly mapped out, which enhances productivity.



        Collaboration: This means working together as a team in a process and optimizing the way the business works.



        Improved customer focus: A business process continuously updates your company with information relating to the needs of the customer and reviews about the service or product they receive.

        Chapter 24

        Are Processes Sacred?



        Effective communication: Using market research and reviews, you can communicate much better with the customer.



        Improved time management: Certain activities can be done more efficiently thanks to the development of strategies and flowcharts.



        Ability to adapt to new technology: Business processes can be improved by taking advantage of the latest technologies.

        Different Types of Business Process Design There are basically three different types of business process design. •

        Primary processes: These are the most fundamental type of process and are how a company delivers its end product to customers. Every step adds value to the end product.



        Support processes: These processes don’t add value, as such, but they do allow the primary processes to operate effectively and efficiently. They also support an organization’s everyday operations.



        Management processes: These are processes that govern corporate governance, strategic management, and operations. They set the standards and goals that ensure the effective and efficient working of the other two business processes. These processes also include an element of controlling and monitoring different processes in the business.

        195

        Chapter 24

        Are Processes Sacred?

        Business Process Examples There are many business process examples commonly used by different companies and organizations. They include the following top ten: •

        Customer success processes (customer relationships and strategy)



        HR processes (employment satisfaction and development)



        Management responsibility



        Change management, quality, and process improvement



        Capital management, reporting, and financial analysis



        Product development process



        Customer acquisition and sales channel



        Sales and marketing processes



        Customer success process



        Financial processes (accounting management)



        Service/product delivery



        IT processes (technology management)

        All these are essential in running your business, but why is the business process important?

        196

        Chapter 24

        Are Processes Sacred?

         hat Is the Most Important W Business Process? Several business processes are essential for the efficient running of your business, regardless of its size, location, or industry. Unfortunately, this makes determining what is the most important business process impossible to answer, but there are few core business processes that all businesses need. •

        Sales and marketing processes: How do you get new customers/clients?



        Quality control and delivery processes: How do you ensure the best level of service or high standards in production?



        IT and technology processes: What technologies do you rely on to run the business?



        Administrative and human resources processes: How do you organize personnel and resources?



        Finance and accounting: How do you get money in (invoicing) and pay bills like suppliers or taxes?



        Customer success processes: How do you keep your customers happy?

        What Makes a Good Process? Now that you understand why the business process is important, it is also important to understand what makes a good business process. What is more critical is to have well-designed business processes if you want to set your teams on the right road to success.

        197

        Chapter 24

        Are Processes Sacred?

        These processes, when made according to the needs of the organization, are going to be treated as sacred by the employees. •

        Simple processes: Make them as simple as possible, helping avoid errors in execution. Complexity in processes makes them difficult to follow and hard to inspect, analyze, and control.



        Documented processes: Documentation captures the best way to complete things, a standard for process control. Without documentation, the process becomes more tribal knowledge or tacit knowledge.



        Controlled processes: Introducing process control so every process can be executed in a controlled way. Uncontrolled processes without checks and balances die out eventually. Controlled processes help in sustaining the process despite the people surrounding it changing.



        Collaboration and communication: Everyone involved in a process should be aware of how a process runs and their role within the process.



        Error-proofing process: Stop errors and mistakes from occurring. Identify if indicators, signs, or error-­ proofing techniques like poke yoke, if you use lean methodologies or Six Sigma, should be implemented.

        Business Process Management Now that we have explained why business process is important, let’s talk about how you can manage business processes.

        198

        Chapter 24

        Are Processes Sacred?

        This can be done with a piece of paper and a pen, Word documents, spreadsheets, or using the power of technology. Business process management is a way of managing business processes using technology, enabling you to use on desktops when ­office-­ based and on a business process management app when you’re on a cell phone.

        Summary Business processes are important because they are a step-by-step guide that describes how things are done in the best possible way and that makes it easier to focus on improving business processes.

        199

        CHAPTER 25

        Conclusion

        Figure 25-1.  Tech as a partnership to business Technology can help business owners leverage limited capital in smarter, more effective ways. In some cases, using technology provides greater efficiency and versatility, making it a natural progression for processes you may already have in place in your business. In others, you may need to make some adjustments to reap the benefits of tech-friendly alternatives.

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3_25

        201

        Chapter 25

        Conclusion

        The good news is that the benefits often outweigh the short-lived challenges of the transitional process, once new systems are in place. This chapter covers some areas to explore when you’re ready to ramp up your use of technology in your business. Using technology in business isn’t about removing the human element from your business; it’s about enhancing it. When done correctly, technology intervention is more of a partnership. The machines get to do what they’re great at, freeing up your employees to use their talents to innovate in other areas of the business. One of the common misconceptions of inducing technology is that it takes weeks, or even months, to implement. I hope that if you’ve made it this far, you can see that there are plenty of processes ripe for automation that have implementation timelines of a single day. This chapter summarizes the technology tools that can be used for improving business processes.

        Productivity There are a wide range of productivity tools that can increase your efficiency as a business, meaning that you get more done and ideally achieve higher revenues as a result.

        202



        Time tracking software is an excellent tool for mapping out where time is spent and by whom, helping you spot where time is being wasted and identify opportunities for more efficient use of time. Such analysis, when properly utilized, is great for accountability, process improvement, and productivity.



        Digital dictation can help you streamline your work processes, particularly if your business includes a lot of time-consuming transcription work.

        Chapter 25



        Use project management and task management tools to stay on top of your daily business responsibilities.



        Create a digital filing system to make it easier to sort, save, share, and find documents.



        Develop an efficient email management process that makes it easier to stay on top of the flow of messages.

        Conclusion

        Financial Tools that can manage your company’s financials can help you spot wasteful spending and increase your bottom line. Use an online invoicing service to reduce the costs of collecting payment from customers. •

        Use online budget tracking to keep on top of—and reduce—your expenses.



        File your taxes more efficiently online.



        Create a new income stream by selling your products online.



        Use comprehensive accounting software to streamline your business finances.



        Share digital files with your bookkeeper or accountant to improve your ongoing bookkeeping processes.



        Explore open source applications to replace some of the more costly “name brand” alternatives.

        203

        Chapter 25

        Conclusion

        Marketing Software can help you market your business better by streamlining workflows and increasing collaboration between different marketing channels. •

        Use software to create a marketing plan that you can edit, update, and share with your team.



        Use social media sites like Facebook, Twitter, Google+, Pinterest, YouTube, etc., to promote your business, products, and services.



        Start a blog related to your business and target audience.



        Collect email addresses through an opt-in form and start utilizing the power of email marketing.



        Use video marketing.



        Promote your business with a website and/or online advertising.

        Collaboration and Learning Technology today helps to coordinate teams and train them to increase their productivity.

        204



        Conduct teleconference calls to make sure team members in different locations are on the same page.



        Webinars or web conferences are great for keeping everyone in the loop with travel-free face-to-face time.



        Expand your knowledge and empower your team with online business training.

        Chapter 25



        Share files and data on the cloud.



        Set up an intranet for local file sharing.



        Communicate quickly and clearly with your team through team messaging.

        Conclusion

        Customer Service Software tools can also help improve your relationship with your customers. •

        Use social media to conduct customer service.



        Set up an online help-desk or ticket system to handle customer issues.



        Allow clients to schedule appointments online at their convenience.



        Use online surveys and questionnaires to get customer feedback.



        Allow mobile working and telecommuting.



        Software makes it easier for people to work from home, saving money on office space and utilities.

        205

        Index A Ad Hoc rewards/recognition, 31, 32 Agility collaboration tools, 94 description, 91 factors, 94 manifesto principles, 92 WoW, 92, 93

        B Black belts, 100 Bootstrap base styling, 117 column structure, 117 components, 117 grid system, 116–118 plugins, 118 working layout, 117 Business analytics/intelligence applications, 133 benefits cross-functional collaboration, 138 data democratization, 139 independent, 138 upskilling, 138

        data stack architecture access control/auditing, 142 data flow, 140 metadata layer, 140 observability, 142 orchestration, 141 schema/lineage, 141 statistics, 141 microservices (see Microservices architecture) objectives/phases, 139 strategies, 134 collect/analyze information, 135 conceptual model, 136 core business processes, 136 data sources/ transformations, 137 data warehouse, 134, 135 MVP plan implementation, 137 Business failures, 163 agile methodology, 167 DACI model, 165 daily scrum, 168, 169 epics/user stories/tasks, 167 pods/squads, 166

        © Praz 2022 Praz, Link Technology to Your Long-Term Business Goals, https://doi.org/10.1007/978-1-4842-8208-3

        207

        INDEX

        Business failures (cont.) RACI model, 164 requirements gathering, 166 solve process problems, 163 sprint process, 164, 165, 168 Business processes, 193 collaboration/ communication, 198 collaboration/learning, 204 companies/organizations, 196 core processes, 197 customer service, 205 description, 193 design types, 195 error-proofing process, 198 financials, 203 management, 199 marketing channels, 204 process control, 198 productivity tools, 202 simple/documentation, 198 step-by-step guide, 194 technology, 201 transitional process, 202 well-designed processes, 197 Business process management (BPM), 182 account management, 183 business strategy, 189 competitor analysis, 189 customer acquisition, 190 efficient processes, 182 finance processes, 184, 185 human resources, 185–187 208

        newsletter, 190 offboarding, 183 operational processes, 188, 189 partnerships, 188 procurement/tendering, 189 publicity, 190 recruitment, 187 redundancy process, 187 sales and marketing processes, 189–191 solid onboarding process, 183 standardization, 182

        C Cascading Style Sheets (CSS), 115, 116 Cloud-native security team (CNST), 158 Continuous integration (CI) skills, 96 Continuous process commitment/performance, 65 Goldilocks, 64 stretch goals, 65 traits, 64 Continuous process team champions/scouts, 63, 64 Customer relationship management (CRM), 137

        D DACI model, 163, 165 Data security

        INDEX

        application/patches, 155 audits benefits, 159 key documents, 160 request evidence/ correlation, 160 vulnerability scans, 158 backups, 155 bug report process, 157, 158 business challenges, 153 data security/alerts/automated remediation, 156 employee education, 155 least-privilege access, 155 mitigate risks and reduce, 155 physical security, 154 roles/responsibilities, 156 strategies, 154 Divide teams business requirements, 3 identification, 6 modules, 5, 6 parallel execution, 7, 8 sequential execution, 4 wireframe, 5

        E, F, G ECMAScript language, 118 Exceptions, 171 advantages, 178 business seek, 175 driverless cars, 173 lunar module, 172

        management deviations, 177 objectives, 176 performance records, 176 resolving exceptions, 177 steps, 175 moon landing, 172, 173 Express.js, 120 Extract, transform, and load (ETL) model, 148, 149

        H Hiring, 9 consultants, 12 recruitment drives interview process, 13, 14 people requirements, 12 steps, 14 referrals description, 9, 10 HR sourcing, 11 success/failure, 10 Hypertext Markup Language (HTML) description, 113 elements, 114 head/metadata, 114

        I Intellectual property (IP), 154 Internet of Things (IoT) sensors, 153 209

        INDEX

        J, K, L JavaScript, 118

        M Microservices architecture architecture options, 145 benefits, 144 business/organizational benefits, 143 characteristics, 143 database integration, 145–147 ETL model, 149, 150 experimentation and lower risk, 144 independently deployable, 145 messy process, 147 precise scaling, 144 synchronous API calls, 147, 148 MongoDB, 121

        N Node.js, 119

        O Objectives and key results (OKR) check-in meetings, 58 cross-functional teams, 46 definition, 49, 50 description, 45 grooming, 52, 53 growth warriors, 51, 52 210

        key parameters, 46 long-term strategy, 55–57 objectives, 46 outcome-based tool, 53 parameters, 46 process (see Continuous process) strategy planning (see Strategy planning) team alignment/linking objectives, 55 virtual collaboration, 47

        P, Q Parallel development, 7, 8 People management, 21, 33 anonymous, 34 categories, 36 employee relations, 33, 34 one-on-one meetings, 22, 23 performance measurement process high-level objectives, 24 individual responsibilities, 24 reporting manager, 25 team officer, 25 promotions/ remuneration, 35, 36 structures, 26, 27 PostgreSQL, 121 Prioritization, 75–77 Prototyping, 81

        INDEX

        innovative projects, 81–84 long-term project approaches, 86, 87 MVP, 87 product launches, 88 rolling wave plan, 86–88 quick turnarounds, 84, 85 R&D teams, 85 squad/spotify model, 82

        R RACI model, 164 React.js, 118 Relational database management system (RDBMS), 122 REpresentational State Transfer (REST), 120 Requirements documents, 72–74 elements, 72 gathering process, 70 Johari window, 69, 70 metadata, 72 prioritization, 71 review meeting, 77–79 sprint review, 79 tools, 75 Rewards/recognition Ad Hoc workers, 31, 32 categories, 30 certificates, 31 criteria, 29 leaderboard, 32

        Rituals all-hands meeting, 40, 41 daily scrum, 37, 38 description, 37 sprint retrospective board, 38–40

        S Scaling operations affect people’s mentality, 95 agility (see Agility) alerts/flags, 98 business constrains, 97 problems, 96 product launches, 98 prototyping, 97 team culture, 95 tech-driven operations, 99, 100 technical skills, 96 upward arrow, 96 Scrum, 127 characteristics, 127 communication cadence, 130 cycle, 128 escalation process, 130 master, 128 master development team, 129 parameters, 131 product owner, 129 responsibilities, 128 team manages, 130 211

        INDEX

        Service level agreement (SLA), 157, 158 Service-oriented architecture (SOA), 144 Strategy planning aspects, 59, 60 check-in meetings, 61, 62 leadership meeting, 61 retro reboot, 62 tools, 60

        T Tech-driven operations, 99, 100 Technology-driven companies, 69 Technology stack, 113 backend technology characteristics, 119 ExpressJS, 120 Node.js, 119 REST, 120 databases, 121, 122 front end/backend bootstrap, 116–118 box model, 116 cascading style sheets, 115, 116 description, 113 ECMAScript, 118

        212

        HTML, 114–116 JavaScript, 118 Technology teams change management, 126 communication, 123, 124 driving forces, 123 innovation, 125 problem solving, 124 scrum (see Scrum) software engineering, 123 Tech team divisions, 105 business units, 107 engineering managers/ architects, 108 lead roles, 109 organization structure, 105, 106 quality assurance engineer, 111 quality assurance lead, 110 requirements, 108 software engineer, 110 Test-driven-development (TDD), 96

        U, V, W, X, Y, Z Upskilling/training plan continuous process, 17 description, 17 on-the-job training, 19, 20 working process, 18