As per Webster, the meaning of pivot is "an adjustment or modification made (as to a product, service, or strategy) in order to adapt or improve." This article is a comprehensive overview of advanced operational pivot best practices.
If you were living in the past decade or so, you may have heard this word used often by the leaders of the product organisations. Pivots in any product are necessary and are a sign of positive growth, but most products aren't set up to make this transformation measurable, painless and timely.
In today's world of providing the best to the customers, businesses are under immense pressure to make operational changes before the customer adapts to another behaviour. To accomplish this, businesses need to build products on fluid yet solid foundational elements. These elements constitute (1) People, (2) Processes, and (3) Practices.
In this article, I would like to present these elements in detail and provide an overview of how tech teams, whether the team is at a developing startup or an established technology giant, can use these elements for a highly successful pivot.
People
This element is the core piece for any successful product. Without the right team we are never set out to succeed in building any product.
The mix of right people and right skills is extremely critical to pivot a product. Too many seniors or too many juniors, too many specialists or too many generalists, these combinations need to always looked at and balanced out to be successful.
Another important aspect of people is the attitude they bring into the team. Ability to jump into areas they aren't comfortable with; Ability to mentor and collaborate; Ability to effectively communicate up and down the chain. These are all some of the characteristics the team should possess.
Unfortunately its not possible to straightway get a team like that, if you do then you are very lucky. So its important to have practices in place that will enable a team like this.
To begin with, its important to have the right team size. I believe the practice set by Amazon, Two-Pizza Team, is a great starting point. Most big product teams can be broken down to feature teams based on this rule.
"We try to create teams that are no larger than can be fed by two pizzas," said Bezos.
Some of the practices that can build a team like this are:
Pair Programming
Goal: Levelling skills and practices enable people to work on cross-function features
My favourite practice has long-term benefits that can turn your team into very high functional team. In the initial days of adoption, it may seem like the returns aren't as expected but stick with it. I promise, its worth the investment.
The practice enables levelling of the skills across disciplines and resulting in an engineer who can work on features that aren't just in their comfort zone. The practice brings in consistency and alignment on the principles and practices the team brings to the solutions. This practice will leave you with an engineering team that is highly focussed and functional.
Many industry stalwarts such as Kent Beck and Martin Fowler have spoken about this practice in depth; please check the article: https://martinfowler.com/articles/on-pair-programming.html
Dev Anchors
Goal: Develop ownership and leadership
The initial days of my career have always been about being an engineer in the background. I was comfortable in that space but lacked the big picture of the project.
Assigning an engineer to own a certain area of the project helps them to motivate themselves and lead that area better. We call this developer to be the anchor of that area. Just to be clear, the developer is not solely resposible to develop that area but will be responsible to do research and find innovative ways to improve it further. Through this the developer also becomes the in house expert of that area.
As an example, we can make an engineer an anchor for the Subscription module of the project. The developer can continue research on the best ways to design that area, research third-party providers, and analyse the effort needed. The developer will continue to be a point of contact on the subscription module and will ensure that the development is happening as per the intended goals.
Code Showcases
Goal: Build a collective ownership mindset and communication
As an engineer, in situations when things aren't working, you may have heard the phrase, "I didn't write that piece of code; it was Shyam who did that." Although this statement isn't wrong in any way because it is, in fact, probably true, it speaks a lot about the mindset of the team. It shows that the team is not united and doesn't own the issues for which they are not directly responsible. It creates a You vs Me attitude in the team.
A code showcase is a team conversation where, every fortnight, the tech team gathers to dissect a certain area of the code without looking at who wrote the code; rather, they look at it from the angle of quality. This helps the team to collectively come up with patterns and standards that all can adhere to. This helps the team to apply these standards when they write the code, and a consistent approach will be applied to writing code. This makes the team come together to come up with practices that they will collectively own and ensure are implemented.
Hackathons
There is nothing that makes engineers more excited than asking them to build their own ideas out during work hours. This is a great way to bring the team together. Hackathons can be organised with a theme or very open but still pertaining to the business. That way, the team can learn more about the business and ask questions along the way. Also, the business can gain a lot from this activity in terms of ideas that weren't prioritized or thought about before.
I feel that a hackathon every six months is a good cadence to begin with.
Processes
Every team has its own process, and it takes time for you to get to a process that helps you churn features to market continuously.
Iterative Development
This style of development has shown a lot of success in delivering business value and, indirectly, business growth. This process has changed a lot of things about how projects are typically executed. To begin with, we don't see the work as a project but rather as a continuously evolving product. It's people-centric; the process evolves based on the strengths of the people and practices they employ for efficient delivery. It helps measure the progress better and enables the leadership with a view that can make the outcome predictable and measurable.
Iterative development: The final product is at the center, and the development orbits it, adjusting as it goes along.
To know more about processes and their importance and effectiveness, please read the article: https://www.pacific-research.com/iterative-product-development/
Assuming you are following an iterative process, I have outlined a few ideas below that have helped us be more efficient.
Lean Inception
An exercise to include in the process to build alignment among the team on the Goals and Solutions. The exercise helps you come up with a set of features that form an MVP. More than the result here, its the journey of this exercise that helps the team most. Introduce this step as the first step of any new product or idea that kicks of the process.
To know more about this, please follow the article below: https://martinfowler.com/articles/lean-inception/?source=post_page-----9df5504907a0--------------------------------
Tasking
At this point I am assuming you are well underway building the product using an iterative process. One of the areas which I feel like is the root cause of failed delivery is misalignment on the work that needs to be done.
A developer jumps into the story and gets started to get things done, but unfortunately, the output may be very different from what is expected from both technical and business perspectives.
As part of a pre-sprint activity, one of the mandatory steps would be to task out the stories. Its an exercise that the developers will discuss a story and try and estimate the work. Tools like Planning Poker can help with the estimation aspect. The goal here is actually not to get an accurate estimate (oxymoron here), but the alignment on that estimate and talking out the reasoning behind the estimate. This discussion should be the basis for listing out all the tasks needed to get the work done.
Story Kickoffs
I wanted to talk about an issue that repeats itself quite often. The story is moved to Product Review, but it hasn't met the Acceptance Criteria (AC) listed in the Story. There are many reasons for this, which could be a misunderstanding of the ACs or assuming from the storyline what it is and not reading ACs thoroughly etc.
Whatever the reasons may be, the failure is not acceptable because it introduces a cost that could have been easily avoided. A cost of wasting QA time before the card was done, A cost of wasting Products time reviewing it before it was ready and A cost of developer context switching time because now the developer has moved on to another story.
We addressed this issue with a simple step that happens when the developer picks up a story, which we call Story Kickoff. The developer notifies the Product, QA, and Designer about the story that is picked up during stand-up and sets up a quick meeting to go through the ACs. This ensures a final check before the development starts that the ACs are still valid, ensures the design is still valid, and also discusses the complexity from the testing point. Decisions can be made at this point to either break the story down to make it smaller or kick it back if the business has changed direction or add more detail to the story if all parties agree.
This gives the developer a quick snapshot of what is all entailed so decreasing the chances of missing out any acceptance criteria.
Desk Checks
Many times, we have pushed work into the hands of the review team and figured out that some parts of features are missing or are not working as expected. To avoid this, we have introduced a step called Desk Checks; as the name suggests, it is a Check at the Desk of the engineer. Similar to kickoffs, this is another rendezvous with Product, Design, and QA to finally review the output and match against the ACs of the story. If all looks good, the card will be moved to the next stage.
Many times the development of a feature may involve multiple days, and during this time the world changes quite a bit in product world. This helps the Product to adjust the output if needed be before the developer moves on to another context.
Practices
Below, I go through a set of practices which are extremely critical to be able to pivot with the business. These practices done right from the get go will save you from a lot of heartburn later on.
DDD (Domain Driven Design)
A step that is usually missed or ignored but its a step that according to me is quintessential to the success of any product delivery. This exercise helps identify the various systems of the product both core and external, and the connections between them. At the end of this exercise, the technical design that comes into shape aligns perfectly with the business expectations.
Go ahead and get a copy of this amazing book by Eric Evans if you don't already have one.
My mentor and friend Prem has recently published a book that will help you implement these concepts on your projects better.
Continuous Integration on Day 1 and Deployment in Week 1
CI/CD is a well-adopted practice now, not something that I will go into deep here, but what I want to emphasise is that it's not an activity that should be done later in the project, but rather we start with it. It could be as simple as a Hello World application being deployed but the pipes should be setup first.
Delaying it for later will only jeopardise product delivery and growth.
Platforms like Github Actions help you get started quickly.
Testing, Testing, and Testing
When I say testing, I mean automated testing. A lot of teams ignore this at the beginning, thinking this is going to add more time to delivery and hence punting it for later. This decision will soon limit you from moving fast and changing direction as business changes.
Test Driven Development (TDD)
This is my favourite engineering practice by far, and when coupled with Pair Programming, the fun of building products gets amplified like never before.
The practice is basically simple and natural. As a developer, you always start with reading the requirements. In the end, you know what is expected and what is not expected based on these requirements. So we start building the known thing first, which in this case are a set of tests that, when executed, will result in validating our expectations. Once the tests are written, now our job is to write the production code that will make these tests pass. Hence, the practice gets its name, whereas we drive the production code via tests.
When pairing with another engineer, the practice can be implemented in several ways; one way that I prefer is alternating between writing tests and production code. This implementation is referred to by many as Ping Pong pairing.
IAC DevOps
Infrastructure as Code (IAC) is no longer an option. It's almost a sin not to code infrastructure nowadays, especially with so many tools and libraries that are available to make this happen. This adoption of this practice directly impacts the delivery of the product to market. In the lifecycle of a product, there are times when you want to go to market multiple times in a day, need to back out a change, or need to patch in a change. Without IAC, these tasks can prove to be expensive. Expensive from the standpoint of coordination with all the involved teams. Expensive from the standpoint of missing out on a manual step in the delivery process. Expensive from the standpoint of trying to repeat the same steps as last time.
IAC solves all this with a repeatable process and minimising last-minute surprises.
SOLID Code
At startups, I often noticed we jump into code and follow a preset in terms of architecting or designing our code based on our previous experience or some random tutorial on how to build a HelloWorld application. We end up building on top of this HelloWorld implementation. This may well serve us in getting to market fast but may not serve in the long run when it comes to changing the direction, as it often happens at startups.
When working with Object-Oriented languages, SOLID principles are not an option to ignore. Adoption of principles like Dependency Inversion into the code will grossly simplify the changes to a Third Party dependency. The principle allows for segregation of various layers of the code enabling better unit testing.
Do not ignore these practices and principles if you want your code to scale for the future.
MicroServices vs Monolith
MicroServices architecture has many advantages that will enable the scale of the teams, infrastructure, and delivery of the product. With all these advantages, one may wonder why we should not jump into adopting this model. But there is no such thing as a free lunch.
DDD will help define the various MicroServices of the system. Once defined, ensure that they are now deployable with unique scaling needs, something that can be coded up as part of the IAC. The CI/CD process for these MicroServices should ensure that the change made is compatible with the other dependent Services. This involves extensive automated testing, such as Consumer Contract Testing.
As a startup in the early stages, this may not be the ideal setup, given the cost of the setup. My recommendation is to go with Monolith with clean, modular separation via SOLID code, Shared Libraries, and Logical Database separation. Take the step to MicroServices architecture once the startup scales in terms of both team size and adoption.
Summary
With almost two decades of experience in this space and having worked with extremely talented folks over the years, I have gathered the knowledge that I tried to articulate above that will help succeed tech startups scale when the time arises.
