What is Growth?
Growth is a combination of capability and capacity - doing better, and doing more. Nature provides us with simple yet complete examples of growth. As a tree grows, not only does it become bigger, but it also produces more fruit for each unit of resource it consumes.
This is the model of growth that Lattice wants to pursue. We intend to simultaneously increase our capability - by designing and developing more complex technologies in shorter time periods - and our capacity - by doing more projects in total.
Why pursue Growth?
If we accept the definition above, then it follows that growth is another manifestation of improvement - and consequently, represents the pursuit of perfection. When we start exploring our own potential, each one of us strives to do more, and do better - improve - and more towards perfection. Growth is natural.
How do we Grow?
Learn. Do. Repeat. Growth is driven by learning AND action.
From Individuals to an Organization
At Lattice, we seek to harness the individual pursuit of growth into organizational growth. As each of our team members learns and delivers, we attempt to convert this learning into ever-improving work processes. By doing so, a "Lattice Way" of designing and developing new solutions emerges.
The Lattice Way
Over the last 3+ years and 14 projects, we have understood that effective solutions emerge from the following process:
Imagine you have purchased a plot of land with the intent of building a home. You engage an architect to design it, and a builder to build/ develop it. The architect must translate your vision of a home into a design - and ensure that your attention is drawn to key features that are important to you. The builder must ensure that the design is buildable - within the time and cost that you can afford.
Lattice serves as both architect and builder – or designer and developer - for its clients. Therefore, we need to pay equal attention to both the sweep of an elegant archway, and the quality of plumbing. A good-looking home with a dysfunctional bathroom is a disaster.
From Systems to Structure
This system of design and development must be enabled by the right structure.
At inception, Lattice was loosely organization. Its 5-6 team members were involved in all projects, and there was little need to formalize roles.
By late 2016, we had growth to 10+ members, and one of them was promoted to lead a development team. This allowed for clearer separation between design and development. One senior manager was accountable to source new projects.
By late last year, our structure has evolved further. Two senior managers took accountability for client engagement and system design (the client interface role), while two team leads managed the development process.
The past 4 projects have demonstrated this to be an effective structure, with clear roles and well-segmented areas of accountability. Senior managers are accountable for ensuring that specifications reflect client needs, while team leads ensure that the developed solution meets specifications. A total of ~20 employees are thus organized in three roles - design (convert needs to specs), define (convert specs to technical approach and project plan), deliver (the actual act of writing code or building a device).
Structure: Design Cells
We intend to adopt this structure as we scale. Our observation is that 10-12 members form a natural unit, or "cell", which today handles up to 3 projects in tandem – completing each project in 12-14 weeks on average.
Each cell will consists of 1 client interface, 1 development team lead, and 8-10 members organized into 3 teams. One of the team members will support the client interface, by writing the specification document, and testing the final system against these specifications.
This structure makes it simple to plan for and measure growth. Capacity is increased by adding a cell – we intend to add one more by September 2018. Capability is improved by shortening the duration of each project – from 12 to 10 weeks – or by completing more complex projects within 12 weeks.
Translated into numbers, 3 cells, each converting a design into a solution in 10 weeks, with 3 projects running in tandem, equals a capacity of 3 x (52/10) x 3, or ~45 projects each year. This is what one organization of less than 40 people can be capable of, within 4 years of inception.
A key feature of a cell is its self-sufficiency – much like its biological counterpart. Each design cell will generate enough income to cover its costs while contributing to the organization’s reserves. This self-sufficiency brings with it autonomy – different cells have the freedom to adopt different business models, evolve different cost structures, and address different domains of operation. They can choose to serve client with similar needs, or design solutions with similar features.
While operating in this structure, growth is driven by two synchronous activities. First, by identifying new opportunities, and adding new cells, capacity increases. Second, by improving processes and eliminating waste, capability improves.
Change is often described as a continuous process. My instruction and experience suggests otherwise. Change is an impulse - identical to how impulse is described in physics - application of force over a short time internal.
Why do we perceive change as a continuous process? This is because change may appear to be continuous. In my view, it is composed of 3 discrete steps - first we prepare for change, then we change, and finally we sustain change. Often, these 3 steps are hard to distinguish.
Take a simple (and unfortunately common) example - fat loss. Joining a gym and changing dietary choices are actions that take place in days. However, preparing for this change can take months (most recently, it took me over a year), and sustaining it is an ongoing process.
The philosophy of Kaizen delves deep into how to affect change. Kaizen, a Japanese word, literally means change ("Kai") to the next elevated state ("Zen"). A loose and incomplete English translation is "continuous improvement". A more accurate description would be - a series of changes to the next elevated state - in search for perfection.
Practically, what do these 3 steps - preparation, change, and sustenance - mean for the organizations that we are a part of?
Preparation for change starts with perceiving the need for change. In organizations, this is often precipitated by a crisis - either external or internal. Great leaders bring about change by creating an internal crisis - well before external changes forces it upon the organization.
Once there is a need to change, organizations need to agree on what to change, and how to effect this change. This can be termed alignment. And aligned organization pushes in the same direction, accelerating the path to change. Conversely, a misaligned organization expends tremendous effort without commensurate gain - leading to fatigue and disillusionment.
Change itself is pure action. In organizations, it translates to a synchronous set of actions. Actions cannot be synchronous without alignment, much like a clock that cannot work unless the right gear, in the right place, rotates at the right speed.
The hardest part is sustaining change. Here, I would draw particular attention to the effect of environment on sustaining change (and even initiating it).
Let's consider a simple example. You are a hospital administrator who wants to improve the quality of outpatient services. You define quality as correctness of diagnosis, ease of accessing services, and cost-effectiveness of care delivered. An understanding of the present state (and all its imperfections) is vital to preparing for change.
Since you are an administrator, you first focus on ease of access - it seems well within your span of control. You and your team (composed of receptionists, pharmacists, and lab technicians) agree that reducing wait time would go a long way in improve ease of access. Now, you are aligned.
You conduct a Kaizen to impact this metric - successfully. For instance, you improve communication between the doctor's office and the pharmacy in order to reduce wait times at the pharmacy counter. Such changes require staff to be timely and efficient. However, the environment they continue to work in does not operate in a similar manner. The rest of the staff, whether due to overloading or poorly-defined processes, are frequently late in completing their patient care activities. How long do you think the change will last?
Hence, to sustain change, the environment has to enable it. Beyond the environment, operating standards also have to be modified - so that today's change becomes tomorrow's habit.
In summary - change is a 3-step process - preparation (need, alignment), change (synchronous action), sustenance (environment, operating standards). By practicing it in our daily lives, we can be better equipped to facilitate it at work.
In our journey of building a valuable organization, I have tried to understand better the underlying principles that govern this process. To clarify, a valuable organization is one that creates value for its customers, and consequently, its shareholders, employees and suppliers. Valuation does not necessarily equal value creation.
My understanding of the subject stems from the philosophy that Kaizen has taught me - that a valuable organization constantly improves itself. And this improvement is built on 2 pillars - respect and discipline.
Respect - for yourself, clients, employees and suppliers - means that you actively eliminate waste and strain from processes, because you want those in your value chain is utilize their time and effort to the fullest.
And discipline allows you to engage is such process improvement efforts consistently.
One without the other is like having to choose between someone's character and competence while hiring them - it is a false choice.
Personally, I have had difficulty being disciplined. A symptom of this is my fondness for video games - pressing a button or swiping the screen gives me instant feedback, gratification and a sense of progress. Real life, unfortunately, demands consistency - rewards (may) come if you stay the course. The only solution that I see is to enjoy the journey. More on that later.
We often invest over a fifth of our design & development time into converting the abstract into something specific. This is a process that requires us to perform a craniotomy and peer into our client's brains (or do something equally challenging).
Writing specifications can be tedious. But they are essential to designing any product or service. A good set of specifications:
To test if your system specifications are, well, specific enough, give them to a friend who is not from your industry. If he or she can understand it the first time through, you should be writing this blog, not us.
What cannot be specified, cannot be built.
Startup funding and valuation generate significant coverage and conversation. And a lot has been written about the positives and negatives of various sources of funding - angels, VCs, friends & family.
So what is the best source of funds for your business?
Our learning - your customer's money. If it is the ONLY money you have accessed to build your business -nothing like it! Too often, businesses focus sequentially on - making a business plan, then raising funds, updating the plan, and then looking for customers. Instead, invert the process - look for customers, validate/ update your plan, reach break-even, and then consider funding growth. Making money is essential to learning how to spend it well - and should precede it.
The typical investor loves and hates such businesses. He loves them because they make money. He hates them because they (often) don't need money. And as far as the entrepreneur is concerned, it is far better to want money, than to need it.
In recent years, one of the mantras of product development has been iterative, user-centric design - in which prototypes are created in rapid succession, and take to users for their feedback and refinement.
Our experiences at Lattice over the last 18 months has reinforced the need for user-centric design. However. it also have led us to challenge "iteration" as a virtue.
Let me explain. Iteration is good when it incorporates new information about the manner in which a product will be used. However, several design iterations are the consequence of sloppy, rushed design specifications - when there is no new information; instead, the iteration is required to address prior oversights in the design process.
This kind of iteration masquerades (very successfully) as a virtue, but is really a vice. It is also expensive.
Where does that leave us? Our advice:
It is tempting to think of innovation as being idea-centric. However, a compelling idea does not
equate to a useful solution, a solution does not naturally scale to a scalable product, and a product does not equate to a sustainable business. There are several steps that an innovation must go through to move from an idea, to a product that is widely available and routinely used.
It is important to differentiate between a product and a solution. A product, such as Gmail or Microsoft Outlook, is something that is widely applicable, and serves the needs of multiple users across several groups or organizations. A solution is specific to a single individual or organization’s needs – such an image archival system developed for use by a particular department in a hospital.
In summary, a product is a generalizable solution.
At the very least, it is important for innovation to move to the solution phase, and if possible, onward to becoming a product. In the absence of usefulness, an innovation remains an experiment – it creates knowledge but not impact.
In October 2015, I had the privilege of participating in my first hack-a-thon ever. Though I had helped organize hack-a-thons and Jugaad-a-thons before, and acted as a mentor and judge in a few of them, I finally had the chance to put my money (rather, time) where my mouth is.
The event was the CAMTech Diabetes Innovation Hack-a-thon, held at the Indian School of Business on October 10 and 11, Saturday & Sunday.
Here’s what I learnt.
Don’t start at 11 pm on Day 1
That’s pushing your luck a lot. You have 30 hours at most to go from need identification to solution design, so time is of essence.
However, do enjoy the entropy of finding good people to work with – without checking your watch every single minute. Once of the winning teams came together after a serendipitous conversation at teatime on Day 1 (Saturday). This was after two of the team members had spent the prior 3 hours working with a different group on an entirely different design.
Play it by the book
We were fortunate enough to make it to the final 12 of 42 teams. One of the reasons was that we had experienced hackers on the team, who decided to play it by the book. What does the good book tell us?
Be passionate about the problem, don’t get emotional about the solution
Many folks (fellow techies – I’m looking at you here) start with a solution and work back towards a problem. After a while, they get so emotional about the solution that the problem disappears from the picture. I’ve done this twice in real life. Both situations ended up with poor business and technical outcomes.
I remember what Dr. Data Santorino said in the Clinical Summit preceding during Jugaadathon 2014, “Unmet need is your anchor; it saves you on the bad days when your solution seems bound to fail. Find you center based on the problem you’ve set out to solve. It will keep you sane.” I think he pretty much said it all there.
Clarity about the problem statement allows you to validate it independent from the solution – because the solution can (and will and should) evolve as you move through the hack-a-thon. But keep your focus on the problem.
Enjoy the journey
Winning feels awesome. We were thrilled to make the cut past the semis to the finals. But the ride there was even more fun. I learnt a lot about my teammates, Niraj Gupta, Chetan AC and Bharadwaj Swarna, even though I had known them before we collaborated at the hackathon.
You get to see people at their best and worst during the simulated pressure cooker of a hack-a-thon. So find someone who takes to the pressure well and befriend them. They’ll probably make for good friends in real life too.
I’ve come away from the hack-a-thon with tremendous respect for all participants who put themselves out there. This includes the gal who kept it together in front of the judges during the semis, even though she was terrified of speaking in public – if you’re reading this, you know I’m talking about you!
More power to the hacker community. Keep calm & Jugaadathon!
The acute shortage of healthcare services in India - be it doctors, nurses or hospital beds - creates a unique set of challenges - two in particular.
First, this situation gives rise to the need for technologies that "deskill" healthcare delivery - those that standardize and simplify activities, so that they can be performed by "non-experts". This frees up the time of doctors and specialized nursing staff to focus on value-added, patient-centric activities.
Second, the shortage of hospital infrastructure creates the need for healthcare delivery that can extend to the community and home - reducing burden on hospitals and patients alike.
We will soon present two case studies that illustrate how solutions were developed in response to these challenges.
Why the Blog
As we grow Lattice, we would like to share our lessons in product design & development, building a company, and the healthcare space. We hope it presents you with some interesting ideas, and starts off useful debates.