The Startup and the 3 P’s: Product, Process and People
I will not pretend to know everything about startups and startup culture, but I will list the reasons why startup culture is exciting, at least for me:
You meet great people, people who have ideas and want to try things, people who have passion and want to make an impact, people who will challenge you to do better. There is passion for working together as a team, passion for building trust within the team and passion for collectively making an impact in other people’s lives; or sometimes, passion for just making something happen – to create. There is passion for possibly creating something that could go big – disrupt everything, all built from the ground up with the teams sweat, blood and tears where everyone is high on adrenaline. Suits? Offices? As long as you are connected with your team and are working well together, those things don’t matter. There is no red-tape, or big top-down structures, everyone and anyone has access to all. Anyone can start working on anything, there are many hats to choose from; wear all. You don’t get bored as things are evolving and stay fresh, there are new ideas, old ideas, odd ideas; anything can change anytime.
At the end of the day, a startup is defined by its growth; when a startup doesn’t grow, it dies; it stops.
There can be several growth stages for a startup, and startups evolve; once they start growing they are now “startedup” and will hopefully grow exponentially. In a perfect world, the cultural values that made the startup fun would remain and in some cases they do (depending on where the growth has lead the startup) but there are times where the culture itself that helped the startup grow and evolve starts conflicting with what is needed to grow to the next level.
Let’s say you follow agile and you end up with iterations, planned work, release schedules and a clear pipeline of what needs to be built. This all worked great when you had 2 products and a team of 10; since you have grown, the expectations of what you can or will deliver have also grown. Some brilliant folks in your team have discovered 2 more products that should be added to your portfolio; how do you grow your current 2 products (since they have a feature and defect backlog) and also work on these 2 new products without increasing your team size, changing delivery for current products or burning out resources? Before you grew, you may have had your own expectations of when and how you would bring on these two new products; now that you’ve grown, others may have different expectations from you and your team(s). Maybe you say “we need more people”, which brings me to the next point
With the growth of the startup, either through sales, funding or more investment and the need to create more product it is decided that you bring on more people, and you do. You end up facing the same issue, how do you grow people with the same 10 resources you had who are busy working the two existing products; some of the people you bring on may be self-starters and will figure everything out by themselves but what about the ones who don’t? So now you say “we need some process and automation to free up some of the manual work so that we can do more with the same resources”, which brings us to…
How do you focus on process and automation to free up time when the people you have are busy with supporting the existing two products, or are supporting the existing two products and are also trying to bring the new hires on-board?
A part of me says that the above three growth challenges are not really challenges and that they are part of what it means to be a startup culture and are expected. However; there are a few by-products that the 3 P’s create that can become toxic, stop growth and hurt the culture if they are not accounted for when trying to grow.
The Frat party & the first team
The first team consists of the people that built the startup; it was their teamwork and effort that made the startup grow; anyone who comes later is an outsider and “we need to be careful about who we let into our frat party” (once upon a time I lived on frat row). This one is not intentional, but when you work closely in teams and blur the line between friendship and co-workers, you end up creating an inner circle and make it challenging for an outsider to easily integrate and feel welcomed. This by-product is a blocker for People growth.
The golden simple process
At some point there was predictability and little chaos in what all needed to be done (smaller team, less products) so everyone starts expecting things to always be perfect. Even though you have grown, you have kept your process simple and did not optimize for KPI’s and other metrics that can help with predictability, complexity, risk and estimation. There will be times where things change, dates get reset and/or product scope creeps. If you had built a roadmap of what releases when, had committed the teams to that and put all these releases with their iterations back-to-back (because of all the product that had to get pushed out to show growth and maturity) and dates or requirements change on you (usually not for the better) the team and its happy culture will get disrupted as it will take effort to get things back on track; when/if this happens all the time, it gets hard to get away from the domino effect and people burn out, get disengaged and/or leave. This by-product is a blocker for Process growth.
When you were small, everyone knew what everyone else was doing, everyone shared and individuals had their skillsets. Now you have grown, 2 months ago you were 10 people, today you are 75, the 65 newer ones don’t understand the code base or the original design, there is some good documentation but they need more information and there are 3 key people who know different things about the original products; original products that you want the new 65 people to work on so that the first team can work on the two new ones; how do you distribute the knowledge known by the 3 key people, make them available to the 65 and allow the 3 key people to focus on their new projects? If they are constantly being pinged by others and cannot get their work done; their sense of accomplishment doesn’t scale much; especially if you did not plan for them to set time aside and help others. This by-product is a blocker for Product growth.
Each blocker is situation (just like leadership) and can be solved; we will examine and solve for each, before we move onto other “StartedUp” culture challenges. The next post goes into process KPI’s and metrics – addressing the golden simple process blocker.
The content for this discussion is several pages long so I will release it in posts as a series.
A couple of weeks ago I had interesting discussions with a software lab focused on mobile tech out in the Boston, MA area. Ideas were exchanged, we spoke about different issues that impact teams, growth, product, process and discussed different ways they could be solved.
After the dialogue, reflecting back on the content and looking for a root cause or pattern I realized that this wasn’t the first time I had discussed or worked on solving these type of issues; growing pains, single threads, lack of process, maturation are just some of the terms used to describe the root cause and in most cases its all of them as they mean the same thing and to me that is “growing startup culture”
A startup company or start-up from http://en.wikipedia.org/wiki/Startup_company
A startup company or startup is a company, a partnership or temporary organization designed to search for a repeatable and scalable business model. These companies, generally newly created, are in a phase of development and research for markets. The term became popular internationally during the dot-com bubble when a great number of dot-com companies were founded.Lately, the term startup has been associated mostly with technological ventures designed for high-growth. Paul Graham, founder of one of the top startup accelerators in the world, defines a startup as: “A startup is a company designed to grow fast. Being newly founded does not in itself make a company a startup. Nor is it necessary for a startup to work on technology, or take venture funding, or have some sort of “exit.” The only essential thing is growth. Everything else we associate with startups follows from growth.”
And from the same source, a startup culture
Startups utilize a casual attitude in some respects to promote efficiency in the workplace, which is needed to get their business off of the ground. In a 1960 study, Douglas McGregor stressed that punishments and rewards for uniformity in the workplace is not necessary, as some people are born with the motivation to work without incentives. This removal of stressors allows the workers and researchers to focus less on the work environment around them, and more at the task at hand, giving them the potential to achieve something great for their company.
This culture has evolved to include larger companies today aiming at acquiring the bright minds driving startups. Google, amongst other companies, has made strides to make purchased startups and their workers feel right at home in their offices, even letting them bring their dogs to work.The main goal behind all changes to the culture of the startup workplace, or a company hiring workers from a startup to do similar work, is to make the people feel as comfortable as possible so they can have the best performance in the office.
This is what most of us understand startups to be; but I would argue that startup cultures do not only apply to a new or young company (a startup) or that the culture is inherited through acquiring a startup; applying the culture and model that exist in a typical startup one can “build startup culture”.
If startup culture is a “must have” then how can there be any issues with that culture? To clarify, in my opinion startup culture is great, they build great teams, focus on product, have a great culture and are fun to be in – and I respect and thrive in them; you start running into issues once the startup has started-up and you need to scale three core P’s: people, product and process. For me, the key is using teamwork and relying on your peers to figure out how to scale all three at the same time while everyone is busy with their other workload.
The next post will outline some of the end-products of startup-culture that should be addressed/changed in order for the startup to mature as it goes from being a startup to started-up culture
So what does come after Scrum/Kanban/Agile?
The evolution of the SDLC continues as expected and if you look at the trend, the focus has been to get things done quicker – Rapid.
Andy @ Assembla calls it Scalable Agile and has great content explaining the concept behind it; I call it Rapid – Real-time Actionable Prioritized Individual Delivery, or Rapid Agile and the basics around the process are very similar. The focus or goal is to prioritize individual efforts rather than a team sprint, act upon real-time feedback and deploy much quicker; often deploying new features and bug fixes several times a day rather than ever other week or so.
Case Study: Blank Label
At Blank Label when we were much younger, we manually deployed whenever we wanted as we were trying to rapidly enhance and stabilize our offering. With every feature came a lot of bugs and it was usually the changes in usability that brought inconsistency in usability as we had limited resources and a lot of “to-do’s”. Eventually we settled on a 2 week delivery cycle but as we were attempting to find out who our customer was, we made some drastic changes only to see orders drop from several a day to almost none every week. We had no idea what of the 20 things we changed in the 2 weeks that killed it as A/B testing had told us that our sales would go up, not vanish.
Fast-forward many months – we saw that we had gone back to our old habits, but this time we had process and we were not disrupting things when we updated, we deployed to a staging server, tested things out there and then released to the live server. This still required manual builds and deployments, many times fixes just didn’t make it to the live system when issues were discovered because it required someone to build and upload…
Now fast-forward to yesterday – we now build the backlog in Jira and make use of green-hopper for their kanban board. We go through a to-do, doing, build and live workflow, where bamboo will automate code checkins and deploy with AWS ec2 to our staging server; once testing passes staging, the deployment to live is a simple click of a button and live is then refreshed.
For test, we have gone from 1-3 pushes to test per day to 5-8 pushes per day and for live will be going from one refresh per day to 2-3 refreshes. We still have a small team of developers, once this team grows we will probably see a large increase in pushes to test, but will probably maintain the 2-3 refreshes to live per day (depending on the functionality).
In the not so distant future, I will provide the development workflow process along with the tutorial to build all the Atlassian stuff that will get you to a rapid continuous integration, deployment and deliver model as I did not see a lot of solutions that focused on the .Net MVC3/4 Razor stack.
“Existing processes must be described before they can be well understood, managed, and improved. An organization must then define what these processes should be before attempting to support them with software engineering tools and methods; in fact, the definition forms the requirements for tool and method support. A variety of process description and definition technologies is available.” [*]
Ask a gardener how you can improve your software development practices and not only will you get a strange answer, you will also get a very confused look; unless of course the gardener use to be a software developer and knows your product (and current process) in an out. In other words… if one does not understand the inner working of things, such as the current chaos (or processes) or what goes on behind the scenes and how things work, then that person cannot provide you with useful information on how things can be improved.
A defined process is a prerequisite to process improvement; you cannot (well you could, but it would take quite a while) improve process without understanding what it is you are improving and how the change’s that are suggested and implemented will affect other processes.
As obvious as may sound; to begin improving process, you need to first draw it all out and identify all the bottle necks/issues one by one and strategize when and how to improve what. Many have wasted their time trying to implement something that may have worked elsewhere, or something that’s out of a book that’s there for the sake of “having a process” with no real benefit to the users.
When it comes to process – One size does not fit all.
[*] – Technical Report “Software Engineering Process Group Guide”. Flower, P & Rifkin, S, September 1990. CMU/SEI-90-TR-024, ESD-90-TR-255
“We are committed to being very agile in making sure that our waterfall process is iterative”
While machines might give the same level of output everyday, the same doesn’t apply to people.
In a real environment, each member’s momentum and motivations will change without notice. This requires management to step in and make sure they are constantly evolving the processes so that members will remain motivated. Leadership is important to motivate key players, channel information to keep everyone engaged and make working horizontally routine. To accomplish this, management might bring in an outside champion, who will help wring in new ideas and “fresh” stream of motivation. Instead of looking at a project as a whole, it should be broken down into smaller goals that are realistic and achievable. Management should encourage and build on small success, to demonstrate that it was an important milestone and motivate members. Progress and results should be demonstrated so that members can all acknowledge the ongoing progress and success. Management can keep the members interests by ensuring that they are always focused on achieving the goals that were set, and if deviation is detected, corrective action is taken to bring things back on track.
A horizontal team is dynamic as it is always changing, management needs to account for its dynamic nature and make necessary adjustments to accommodate/adapt to the change. Money is probably the best motivator, but too much money too early in the process can hinder individual initiative and prevent people from innovating. Since horizontal structures focus on team collaboration, a downfall is that meetings can go on forever and schedules can be missed; this can unmotivated some members who feel that decisions are not being made in a timely manner, which is why management can implement deadlines which will help practitioners develop a common schedule and manage workloads effectively so that the projects momentum is kept at a steady pace.
[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]
Even though a “horizontal structure” is flat in nature, it does still need a (vertical) support structure.
The main purpose of a support structure is to help managers build lasting relationships and achievements with teams. There are two basic type of support structures that managers can mix and match when building or working with teams, depending on the requirements as each has its own attributes.
- Informal structures don’t define rigid roles and responsibilities, they are open to interpretation and people can define their own roles and swap roles as needed, hence they are less resource intensive, more flexible and less binding on members; Informal structures help promote open discussion and communication among its team members; and
- Formal structures are more rigid and roles/titles might be defined where members have specific responsibilities; this makes them more resource intensive but less ambiguous; they require some logistical skill and expertise to implement. These structures are great when consistency and quality are important factors.
It’s important for management to recognize what type of structure needs to be in place and when its put in place; as “when” a structure is erected, it can play an important role in the success of the teamwork initiative. If too much formality is introduced early, people might feel there is no difference in the “horizontal structure” and the “vertical structure” where vertical structures are rigid, formal and bureaucratic and would be less motivated to work with the initiative. In contrast, waiting too long to build a support structure or the lack of a support structure can hinder the ability of the team to successfully work together as a team, especially when they need to be able to adapt when in tight spots.
Since the resources and effort required are greater when setting up formal structures, informal structures are great for short projects, however when the projects will go on for a long period of time or are of large scale, formal structures would be more suited as they are less ambiguous and will stay well formed longer (as they are more solid than informal structures).
Authority and roles in informal structures are more ambiguous and can be swapped around; In formal structures, the roles and responsibilities are more definitive, hence less ambiguous and in that regard, formal structures would work best in situations where important decisions need to be made.
[Source: Moving from the Heroic to the everyday: Hopkins, Couture, Moore]