5 Things I Learned About Leadership and Project Management With A High School Startup Team

By Michael Vaganov

In February 2020, just before the pandemic lockdowns began, a small team of humble high school students got together to form a startup team with Applied Computing Foundation: Tong (a full stack web developer in a high school senior costume), Audrey (an archetypal over scheduled teen Zoomer), Evan (a charismatic jack-of-all-trades), and Nina (the team’s no-nonsense “carry”). I was their coach (a cartoon character of a computer science teacher). With guidance from Eric Ries’ The Lean Startup, we worked on a team project for a little over a year.

What was the point of this startup team project?

Our project R2H, or Resource 2 Health, centered around providing resources for millions of caregivers in the US. Examples of caregivers include nurses, parents, and people caring for unwell friends or family.

Our research indicated that more than half of all adults in the US are caregivers of one kind or another. And caregivers need help, not just the financial and physical kind, but also emotional help, and even simple acknowledgement. These caregiving jobs are not getting automated away by robots either, so a tool like R2H could be meaningful in the long term.

The web app we envisioned was for mobile phones and had some major features:

• Medical symptom assessments
• Collated lists of free healthcare resources
• Emotional self-assessment questionnaires
• Specialized scheduling user interfaces to help organize care
• An encouraging chatbot
• Targeted ads and freemium features for revenue

To validate the team’s assumptions, Applied Computing Foundation (ACF) found a caregiving expert to be an advisor early in the project. We were lucky to get connected with Ramesh from All Care Plus, a non-profit in the caregiver training space.

What is the point of any high school startup team?

An entrepreneurship team experience has a lot of value for an ambitious high school student:

• A fantastic opportunity to practice and improve technical skill, motivated by a peer group
• Early exposure to professional experiences like disciplined teamwork, leadership, and collaboration with adults in a non-academic setting
• A superb personal portfolio piece for college admissions applications and resumés
• Possibility to win entrepreneurship competitions

An entrepreneurship team experience is formative like a competitive sports team. Teammates develop strong personal bonds working together, heightened by the ups and downs of competition and tempered by a responsible adult in the room.

The Five Things

Keep asking and answering questions, first broad then specific.

A project feels good when questions are answered, and the answers are specific and validated. Answering broad questions first helps filter down to more specific ones. For R2H, the initial broad questions and answers were:

• Can we learn to do this? Your favorite web search + real life teacher
• Do we understand our goal? We discussed caregiving with a subject matter expert
• Can we work with our chosen platform? Tong had a prototype web app by week two
• What are the specific features? Spreadsheet of 80+ features refined during discussions
• Can we overcome these technical limitations? Rapidly prototyped working features
• Are these the right features? Expert interviews, testing with prototypes, user surveys

These questions were not just about technical scope, they were also about working together as a team. Luckily, Tong, Audrey, Evan, and Nina were of similar ages, with some similar interests and backgrounds. They quickly related to each other while discussing goals, questions, and answers. And they were patient and honest when we naturally revisited the questions.

There is no such thing as a perfect plan. However, a good plan will feel overly done — you’ll get the sense that some kind of “just put it all together now” phase is the last stretch of the project. But even this feeling is an illusion. In reality, more specific questions lay hidden, waiting to be asked. The last 10% of the project can become 90% of the project, a situation which will sneak up on you without the habit of validating your work with questions.

Make plans, and more importantly, be ready to change them.

Nearly every plan we made changed. Nearly every list had missing elements that we didn’t see till we started implementing. Real life events changed things too. Covid-19, for example, had big impacts on our project, but in the end, it was just another situation to adapt to.

Life is messy sometimes. Adult stakeholders lost engagement with the team. One had family problems to deal with. One had his identity hacked (for a crypto account; don’t use your phone’s SMS messaging for 2-factor-authentication). Presentations were postponed. Some meetings never happened. Anxious deadlines came and went. Even when the team was productive, the rest of the world didn’t notice. Team members were late, or absent, or changed their schedules, or changed their opinions.

The technical plans seemed to be the most concrete, and those changed all the time too. Our plan for automated questionnaires for medical symptom checking started as a basic web questionnaire. And then…

• Before we could automate writing medical questions, we needed to get medical data.
• Before we could get medical data, we needed to find it on the web.
• Before pulling it off the web, we needed to learn web scraping (code that reads web pages is really important in projects that combine data in novel ways).
• Before learning web scraping, the team needed JavaScript and data structures practice.
• And on and on …

The team did eventually make an automated questionnaire prototype, with web scraped symptom data (thanks largely to Tong’s heroic efforts). The team did eventually get ahold of other busy adults. The team did get used to post-pandemic online meetings.

Almost every task took multiple attempts. Because of that, the team learned a lot: programming, especially web development, git, project decomposition, teamwork, scheduling, business communication, dealing with change, and more.

I think Audrey was our biggest change agent, which helped the team. She was initially shy, so the team frequently asked for her feedback. Her embarrassment started to fade when she saw that sharing a lack of understanding inadvertently spoke for most of the team. She naturally identified problems in conversations. Her confusion guided the team to make changes to the plan.

Because the plan belongs to the team, they also need to feel as comfortable as possible derailing the plan. In the short term, having to scrap plans because of confusion felt bad. We tried to side-step some changes by playing to Tong’s technical strengths. Those choices ended up saving us maybe a few weeks of learning, and also left the project very dependent on Tong, who eventually left the team after high school graduation. To the team’s credit, they changed plans to reduce scope after the membership adjustment. But in the long term, the project would have been better off if Audrey’s honest hesitation was allowed to guide bigger changes to the plan, rather than smaller changes with Tong’s expedient mastery.

Those led by the best leaders will say: we did it ourselves.

Before the project started, I had been meditating on a quote about leadership from Lao Tzu: “A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.” Easier said than done.

A team must choose its own goals. This is so much harder than it sounds. A team will agree intrinsically to please its leader and thus set the goals that the leader will smile and nod at. But if the team claims a goal that its members are dreading, this goal will fail. Team members will drag their feet, and every technical snag will become project-threatening. The leader must rally the team to want a satisfying goal. And in a less ideal situation, a leader helps the team become more self-aware, and choose a better goal to align with.

Evan ended up being the team’s instrument of alignment. He gave words to the team’s trepidation, which meant questioning my plans. I encouraged it. Evan brainstormed solutions too, and doing so, took the tangible first steps to make better plans.

Initially, the plan felt like my plan. It took a while before the team felt comfortable enough to speak up about the plan. When I could, I shot down my own ideas, explaining my thoughts as I had them, and asked the team for their input. “One week to learn that stuff? What was I thinking?” I encouraged the team to be authentically contrarian by taking every off-hand remark seriously, and built rapport using off-topic discussions.

Joining the team on distracting tangents (about memes and video games) also gave them confidence from feeling heard. Once Evan had that confidence, he was able to orchestrate agreements within the team, to pivot, and re-scope, and pivot again. Now, Evan is the team’s promoter of S.M.A.R.T. goals.

The team learned to facilitate meetings as administrators too, each member taking turns to lead discussions and craft agendas. This took modeling on my part, scheduled handholding, and asking them to come out of their comfort zones. And after months, eventually, being leaders felt less uncomfortable for them. Now all they need is a little reminder (All ACF classes use Discord, which I augment with automation called carl.gg; the turtle icon is very cute).

A champion must push through the hard parts and the quiet parts.

There will be times when the next task is unclear, or boring, or has seemingly invisible outcomes, or lacks accountability, or is too far outside of comfort zones. When that unpleasant task shows up, the project functionally ends when no one takes it. Either unwavering passion, or a committed and disciplined work-ethic is required at that moment. The team members who do that hard work deserve the title ‘Champion’.

Nina was our champion. She prototyped the UI with Figma when no one on the team knew how to use it. She wrote, arranged, and edited the video submissions to our entrepreneurship competitions. She always picked last, on purpose. She stepped into lanes that no one else was in, and pushed. It’s possible the others would have done the same eventually, but it’s also possible that R2H could have died a hundred deaths, and Nina kept snatching it from the jaws of defeat.

I don’t exactly know how to guarantee someone will become a champion. Doing the work is a personal choice. My best advice includes: be generous with your wwoowwws and yeeaahhs. Ask team members to pick a goal they already identify with. While leading by example, show appreciation for your own results, highlighting the joy you feel as you practice. I think Tong intrinsically found joy in practicing technology, and he certainly championed that.

I also know that some people seek satisfaction from others, and will work when they realize that their effort is wanted. Audrey was very shy, but agreed to narrate promotional videos after I asked her. And peer pressure from Nina probably helped too.

And be careful about situations where team members are out-classed by each other. ACF interviews ahead of time and tries to form startup teams with members of similar talent, motivation, and grit. Still, R2H suffered a bit because Tong was so dramatically talented that the rest of the team kept their distance from much of his work. If you have the choice, arrange your team so everyone feels they have a valuable voice, and can contribute at a similar level.

A project can’t fail if the team stays curious.

A lot of successful startup founders will tell you that if they knew how much work it would take to succeed when they started, they would not have started. They kept going because they didn’t know, and they were curious. They asked questions: Have I solved my problem yet? Could I make this easier for people? Can I make it better? Faster? Cheaper? What happens after I figure this next part out? I have to know, what’s the answer?

Interesting questions drive curiosity and keep people engaged: the cliffhanger of a story, a riddle, a puzzle, seeing someone else excited, discovering mind-blowing ideas. Significant challenges will be overcome by curiosity alone.

This mental hack helps me drive my students when I’m teaching computer science. I can’t help but get amped up at the thought of sharing mind-expanding “invisible wizard knowledge”, and that excitement becomes infectious curiosity.

Because they were curious, the members of the R2H team learned to practice computer science that tends to leave college students 10 years older befuddled and defeated. Especially when there were technical problems, I focused the team on what we would learn. I teased them with “this is going to give you so many options once you figure this out”. Or when I was confused, “I don’t understand, and I’m excited to find out why!”

My own secret to learning when I was a student was intentional curiosity: “Why do other people like this so much? What am I missing here?” I wasn’t able to maintain that mindset all the time, but when I did, I learned to enjoy a lot of new things. That kind of curiosity is a bit more than just a choice, it’s affected by circumstances beyond direct personal control, like mood, stress, and timing. I don’t know the formula to get someone to choose curiosity, but with patience and compassion, I will keep creating situations till they choose curiosity. They often will.

During the early stages of a project, curiosity is easiest: there are naturally so many questions. When plans have to change, loss is demoralizing, so focus curiosity on opportunities. Be a model of asking questions, and work to get the team practiced at asking and answering their own questions, so they can develop their own curiosity, and you don’t become a bottleneck.

And if the plan is long term, nurture appreciation and commitment to the problem space. When curiosity fades, the team needs commitment to persevere as champions until the next exciting questions appear. In retrospect, I realize that I could have done a better job at this with R2H.

Epilogue: This is not the last project.

Eventually, Tong, the technical mastermind, headed off to college. The team became a different team. After exploring Tong’s code, they saw how much they needed to learn to fill the void he left behind. And they understood, at least intellectually, that what they saw was the tip of an iceberg. The old plan needed big changes. They re-scoped, planned to drastically reduce features, and to end the project at least somewhat gracefully in a final presentation to ACF.

During a finals-week break from the project, separate team members became individually enraptured by the same multiplayer RPG, and the team’s attention shifted to wanting to make their own game. I think that if we had real caregiving experience, or a personal commitment to a specific caregiver, the project could have finished as planned. It didn’t. Life is messy sometimes.

I think moving on from R2H was the right call. They were dreading the project without Tong. But rather than fully quit, they made a big pivot. The team is committed to learning, not to a specific project. The R2H project was extremely educational, and left the team better prepared for the future. They experienced a new level of cumulative development, the kind needed to do big things. Their characters grew in the space of the promises they made to each other and to themselves. They made a hard choice to invest in learning first, and changed their plan.

Their next project is a cooperative computer game. They’ve chosen the goals. They run the meetings. They merge their own git conflicts. They’ve proven to be committed champions so far. Their game developer advisor, me, is consistently engaged. They have drastically re-scoped once already, so their plan is much more defined and achievable this time. Now all we need to do is that last 10%…