112 10 6MB
English Pages 224 [206] Year 2022
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.
•