jessingrassellino

Category: essay

  • Know Your Standards – Building the Foundation for Engineering Excellence

    The second article in the Jazz Leadership series

    Frameworks and Standards in Engineering

    When I think about the most effective teams I’ve worked with, there are some foundational practices that those teams share, even if they focused on different standards:

    • The entire team was involved in discussing the standards;
    • the team agreed to disagree and commit to the standards, and agreed to have retrospectives to discuss how things were going and make changes (flexible frameworks, improvising);
    • the team and overall organization were as committed to improving engineering quality, efficiency, and impact as they were to improving product quality and customer experience;
    • team members were skilled in giving and receiving feedback using shared feedback mechanisms in the organization;
    • the team worked toward shared understanding of the architecture;
    • the team had a vested interest in ongoing engineering learning through onboarding, courses, lunch-and-learn, and taking advantage of organizational learning stipends.

    I can also think of teams I worked with that did not have clear standards or did not have the time or drive to develop clearer standards. Those teams faced these problems more frequently:

    • The lack of quality standards and testing led to multiple patches immediately following each release;
    • the lack of agreement at a few organizations about product direction and position in the portfolio led to paralysis on what to build and release, slowing product development;
    • the lack of documentation about the customer support ownership framework led to confusion about the responsibilities of support team members, causing support backlogs to grow large and issues to go unaddressed due to confusion;
    • the lack of cooperation between engineering and support caused customer irritation and dissatisfaction.

    Three Types of Engineering Standards Frameworks

    There are many potential frameworks that engineering teams can choose as standards. Below are three common standards that can serve as the basis of building shared understanding in your engineering team.

    Coding Standards: Your Technical Language

    Coding standards sound and seem obvious, but it can be tough to enforce coding standards without team agreement. Coding standards need to be consistent to provide value, but not so rigid that they interrupt workflow and become a bureaucratic nightmare to follow and enforce.

    What’s the difference between a style guide that feels restrictive versus one that feels enabling? Restrictive guidelines may include rules about line length, where conditional braces need to be placed, or requiring docstrings for all functions, including helpers. These restrictions can serve a purpose in highly-regulated environments, but can be overly constraining depending on the context. It’s important to work with your team to build a style guide that has enough structure to enforce coding standards that impact your product and meet regulatory standards that may be required, but flexible enough that developers are not spending precious time ensuring that line lengths are exact, when they might instead be thinking about and implementing more innovative work.

    Once I managed a team (Team A) that received a merge request (MR) from another engineering team (Team B) that was over 1000 lines long, with a request to review it and accept it into our code base within twenty-four hours. This situation was problematic in so many ways, and the lack of standards on Team B did not help. In this case, business and political considerations beat process. This meant we had to work through a single, thousand-line MR that was written without adhering to Team A code standards, even though it was going into the Team A codebase.

    The senior developer who reviewed this work ended up needing two days to work with the developer on the other team, refactoring a substantial portion of the code in order to merge with some degree of confidence. The merge happened within seventy-two hours, but it was a difficult and stressful process, one that could have been alleviated had the requesting team adhered to norms about the size of a merge request, as well as coding standards of the more established team to whose codebase they contributed.

    Communication Standards: How Teams Stay in Sync

    Communication standards can be easy to ignore, especially when they are based on implicit norms rather than clearly defined, explicit expectations. Communication standards built around respectful listening and working toward trust enable strong engineers to work with their peers and cross-functional colleagues.

    Conway’s Law states that structures that an organization’s designs (i.e. software and technical structures) reflect the communication structures of those organizations. Given the benefits of positive communication as well as research on Conway’s Law, it’s valuable for everyone to understand and improve their explicit communication standards, not only for the internal and personal clarity they offer, but for the betterment of the systems that they design.

    When I have worked with teams skilled in communications, solving problems was generally easier. People who may not have been natural communicators still had a framework to reference so that they could practice communicating with clarity, sharing their concerns in ways that address problems without attacking people. These teams were solution-focused, and communicated with empathy. They often set the tone for effective cross-team communication.

    Design Standards: Architectural Harmony

    It may seem strange to discuss when software architecture or design patterns when talking about team standards. On the one hand, software architectures may already be in place, and norms already established in a team, for quite a long time (sometimes decades). Less often, you’ll get to manage a greenfield project and never have to think about what happened before, nor what will happen after you’re done with the project and have moved on.

    Usually though, we are somewhere in the middle. It is important for teams to decide upon software architecture and design norms, and then document those norms so that when people leave the team, it doesn’t have an outsized impact on the productivity and progress of the team or project (the bus factor).

    For design and UX teams, shared design libraries that have interchangeable components or styles for specific parts of the product can help designers to work independently and creatively, while maintaining brand identity and familiarity across the UI. For development teams, documenting and sharing about the architecture through lunch-and-learns given by different team members can help spread knowledge about, and an understanding of, these critical shared frameworks. These are just a few of the ways teams can establish communication standards that improve product quality and developer skills.

    Creating Standards Collaboratively

    Collaborative development of new or adjusted processes and moving toward flexible frameworks requires collaboration, reflection, and agreeing to disagree and commit (even if temporarily) to try new ideas.

    Back when I taught high school, we developed classroom rules and norms together. Our process involved free-brainstorming, active discussion, and ranked choice voting for the top 3 – 5 standards. Those top choices became our rules for the year. Because students were part of the process of creating our shared norms, they were more invested in upholding them. Co-creation is essential in the performance of Jazz music, as musicians improvise within the framework to produce unique performances of the same piece.

    It turns out that co-creation is also effective in business contexts. Businesses have successfully included stakeholders and used their experiences to design lasting changes. By including everyone in the design and development process, the team develops greater depth and understanding of the business and personal context of the desired feature or application.

    But a premise of co-creation is that by sharing experiences, all the parties involved will acquire a deeper understanding of what is happening on the other side of an interaction, enabling them to devise a new, better experience for both sides. — Venkat Ramaswamy and Francis Gouillart, Harvard Business Review

    Standards: Are you enabled or constricted?

    Standards and frameworks are constraints, by definition. Sometimes, the standards become so much a part of the process that they go from enabling to dogmatic and constricting. As you develop or establish the standard frameworks for your team, it’s important to pay attention to how people are understanding and interacting with frameworks so they don’t become bureaucratic overhead or a scripted checklist that prevents innovation. The concept of enabling constraints is helpful to understand as you work with teams to develop standards. I love this definition by Erin Manning and Brian Massumi:

    Erin Manning & Brian Massumi coined [the term co-creation] for rules that limit actions to enable novelty.

    I have implemented work management processes using different tools (internal management tools, Jira, Aha) for teams with inconsistent tools and processes (i.e. github issues for “sprint” planning, inconsistent planning practices). Having worked in small startups with lean processes and multiple production deploys a day, the idea of meetings and planning very far ahead felt constraining to me. Getting used to a million dashboards and tabs for multiple teams was a pain! But by working with my teams, doing retros, and implementing suggestions to try, I’ve co-created standards with my teams, transforming them from disorganized to delivering value within constraints that they helped establish.

    Getting Started: Establishing Your First Standards

    The most difficult part of establishing team standards is getting started! Thinking about all of the possibilities can be really overwhelming. However, there are some steps you can take to make the process collaborative while moving forward and trying new things:

    • Brainstorm, with your team, the areas of weakness that you see in the organization, teams, processes, and products. Start by asking “What do you think we could be doing better?” Responses will be open and potentially scattered, but that’s okay.
    • Discuss: Ask the team, “If you could only establish three standards to mitigate or remedy these problems, on which areas would you want to have the biggest impact?”
    • Agree: Come to an agreement, and allow for “Disagree and Commit” as a strategy here. The idea is to be flexible, try something out for one or two sprints (or whatever your work cycle happens to be). then report back.
    • Implement and Reflect: after practicing and implementing the change, come back together, and discuss what happened, both what worked and what went poorly. It’s important to do this without judgement or defensiveness, which can alienate team members and prevent them from sharing.

    Using this format and feedback loop to identify problem areas and implement possible solutions helps to decrease resistance to change, because the team is involved in creating the change together.

    Flexible Frameworks: Evolving Standards as Teams Grow

    Just like jazz, standards should (and inevitably will) evolve as the team becomes more mature, and as business needs change. That’s a good thing. The words “we’ve always done it this way” are an enemy of innovation. Anticipating evolution allows you to make necessary changes naturally, as a part of your working process. You might experience the need to change your existing standards (even if they are working for you now!) in some of the following circumstances:

    • Changes in the size of the team, especially if they are rapid (either the team being cut or the team having hyper-growth). Either of these changes the way that teams work.
    • Changes in business priority or release schedules may necessitate changes to team standards.

    Conclusion

    Building effective engineering standards requires both structure and flexibility, individual skill and collective improvisation, a lot like Jazz ensembles. The most successful teams understand that standards are enabling frameworks that emerge from collaborative effort and evolve with experience and time. By involving your entire team in creating coding, communication, and design standards, you build shared ownership and understanding that will carry your team through the inevitable changes and challenges of software development. Using flexible frameworks, your team commits to continuous improvement through reflection, feedback, and the willingness to adapt. Jazz musicians know when to follow the lead sheet (their framework!), and when to veer off of the path and make necessary adjustments. Great engineering organizations work in the same way.

    This is the second post in my Jazz Leadership series. In upcoming posts, I’ll dive deeper into other pillars: practical techniques for building trust, creating the right constraints for innovation, and developing the listening and collaborative skills that help great engineering teams thrive.

  • Jazz Leadership: A Flexible Framework for Engineering Leadership

    June 9, 2025 engineering, management by 54752785

    When I nearly walked off stage in the Spring 2007 Spirit Ensemble Jazz show, it wasn’t because I didn’t know my music. I had practiced the tunes all semester, and improvised during several rehearsals. But in the critical performance moment, under stage lights with an actual audience, my body froze. I was gripped by a full-blown panic attack.

    Then I looked up. Our bandleader, trombone in-hand, had a calm, steady expression. His look told me I wasn’t alone. And when he gave me my cue, I stood up, and started to solo. For the first time, I experienced jazz leadership in action.

    Jazz “is music that includes qualities such as swing, improvising, group interaction, developing an ‘individual voice’, and being open to different musical possibilities”.

    Travis Jackson, Ethnomusicologist

    The Jazz Leadership Framework

    Only in 2018, when I was asked about my thoughts on Python (and STEM education) for an article in Linux Format magazine, did it occur to me just how much my experiences with music performance (jazz practices, in particular) informed my ways of thinking about software testing, teaching engineering, and leading teams. Jazz music, with its flexible frameworks made of chord charts and its room for iteration and experimentation within those frameworks seemed to me an obvious analogy for software development and leadership. In a 2019 Keynote at StarCanada, I introduced this concept of flexible frameworks for software quality, but the concept extends to software development (and much further – but I’ll focus on software development and management here).

    The jazz leadership approach I’ve developed over years of managing software quality and engineering teams rests on four key ideas, each borrowed from the stage and applied to software engineering teams.

    Know Your Standards

    Every jazz musician learns “standards”, the timeless songs in the jazz repertoire. Those standards are composed of melodies and rhythms, with their underlying chord progressions and forms. Just like their jazz musician counterparts, engineers learn and apply design patterns, system architectures, development workflows, and team norms. Test engineers build automated test frameworks and use manual testing frameworks to find bugs and ensure better quality. These standards provide the shared contexts needed to collaborate to build software as a team and to grow and mature as an engineering organization.

    Trust the Ensemble

    Everyone in a jazz combo knows their standards, but each person brings their own expertise: the bassist lays the groove, the trumpet performs melodies or counter-melodies. The keys add overall harmonic color, and the vocalist delivers the lyrics and engaging melodic vocalizations. Everyone gets to improvise, if they choose. Even the bassist. 😉

    Jazz combos are also about balance. Yes, the band leader makes the final decisions, but does so in deep consultation with other musicians. Sometimes, the consultation is so ingrained in the framework that it’s not visible. But it’s happening.

    Likewise, engineers bring their own tools and experience to a team. Frontend, backend, testing, security, DevOps, IT Ops—whatever is happening, it’s about balancing skills to arrive at technical solutions that serve people. Engineering leadership, done well, means creating space for each person to contribute fully while respecting the standards and allowing other team members their space to shine.

    Of these four pillars, trusting the ensemble was the hardest for me to do. As an experienced musician, I work with knowledge, experience, and a lot more confidence. When I pivoted into quality engineering and then again into engineering leadership, I stepped into less familiar domains. I had to rely on my team’s deep technical expertise and ask a lot more questions to get grounded in daily work. But the more I trusted my team, the more I could contribute to all the ways the team flourished.

    Improvise Within Bounds

    Creativity thrives within constraints. Jazz musicians’ constraints are the song structures, chord progressions, and time signatures of their standard repertoire. From those constraints, creative ingenuity emerges, daring the music to keep pushing boundaries.

    This kind of creative ingenuity is a hallmark of the best software teams I’ve worked with. Software engineers in sufficiently established products are usually solving unique problems, often extending pre-existing architectural patterns and frameworks. They bring their own intellect, education, and prior experience into the mix, pushing the existing boundaries of the current software. In both contexts, improvisation doesn’t mean chaos, nor “do whatever you feel like.” The constraints in both jazz and engineering invite intentional contributions to innovation.

    Listen and Respond

    Great ensembles listen in real time. They have to. Most jazz ensembles don’t play with sheet music. Instead, they memorize the structure of the standard tunes (experienced musicians know hundreds!), then play their part in response to the musicians around them. They make adjustments for other players and treat the musical ideas of others as new information to inform their own solos.

    High-functioning engineering teams and organizations work in the same way. No 10x engineer can build, grow, and sustain a software product on their own. Engineers who listen to information from their teammates and other players across the organization are better equipped to build software that addresses user and business needs while staying focused on the problems at hand, increasing team momentum and avoiding discord. Engineers doing code reviews, providing feedback in feature design discussions, and working in cross-functional collaborative planning sessions are better equipped to listen to what is being presented, respond thoughtfully, and ask critical questions about the (present and future) problems they are trying to solve with software.

    Why Traditional Management Falls Flat

    Too many teams suffer under what I call the orchestral leadership model. My experience in string orchestras (30 years and counting) has been the same: strict processes and adherence to the sheet music, with the innovation coming from the conductor who has studied the score and has a highly opinionated viewpoint about what needs to happen to make art. The musicians are the means for the conductor to shape their ideas. There is a time and a place for this kind of thinking and work, but I’m not certain it is in software innovation.

    Software engineering organizations with orchestral mindsets often operate under the assumption that every variable can be controlled. Waterfall methodologies at their most strict are a close analog, requiring immense amounts of scripted planning, using the developers to shape the software ideas. There’s little room for nuance, creativity, or risk-taking, and critical questions are viewed as defiance to the accepted ways of working. It is much harder to create a shared vision in the orchestral organization.

    Then there’s the “solo artist” problem: the managers, staff engineers, or 10x developers who try to control every detail of the architecture and implementation of their own features, and others’. In the short term, these solo artists can seem like a gift. You know that you can rely on your 10x engineer to get code out the door, fast. That engineer might go around all the established rules, but they get the job done. But if the 10x engineer leaves, there isn’t anyone else who can work on or maintain that code in the same way (not even AI, at least not yet).

    In a jazz ensemble, balance and shared responsibilities are crucial. Everyone gets a turn to solo (trading fours), and others take a back seat, doing important work to keep the groove going. Think of it like the glue-work of jazz. If there were only one soloist, the jazz ensemble would likely become very bored and leave for more exciting jazz groups with opportunities to use and expand their musical vocabulary. Similarly, engineering teams operating with rogue rockstar types become disengaged, losing the energy or desire to work with the 10x coder who doesn’t care about their opinions. They stop playing off each other, and the expertise of the soloist no longer has the possibility of raising up the entire team.

    Impacts of Jazz Leadership

    I once worked with a team that was stuck with chaotic, unstructured code delivery and two talented senior engineers who were more accustomed to working alone than with one another. At the beginning, there were few processes in place, the senior engineers did not communicate, and the company was reluctant to expand the team because they understood the dynamic was flawed. I was hired to help the team grow and shift toward more collaboration and predictability.

    First, I worked with other directors and the team members to decide on processes that included our user community in decision-making and open-sourced software changes. Then, I assisted in hiring junior engineers to the team. As a small team that needed to review both our own code changes as well as community-submitted changes, we did paired code reviews at least once a week, and pairs changed every week, so junior team members had the opportunity to work with and learn from the different approaches and knowledge specialties of senior team members. I included myself in reviewing sessions so I could learn more about the product and codebase. We included regular planning meetings as well, since the team grew from two to seven members within a few months, and worked to address needs and concerns with an agenda to which all team members were invited to contribute.

    By implementing these processes, we tripled open-source contributions to the product within each minor release, we reduced the time it took to release the software from an entire day to a few hours, and we leveled up junior engineers, one of whom is now a manager at the same company just a few years later.

    Getting Started with a Jazz Mindset

    How, exactly, do you begin thinking and leading with a Jazz Leadership mindset? Here are a few options based on this flexible framework.

    Clarify your standards: Where do you need structure in your team process, your code, or your cross-functional work? It is important to clarify the places where structure is necessary to achieve your goals. For example, software for regulated industries requires more structure to document and release, since it must comply with audit requirements. It is necessary to understand and support the structures your software requires.

    Create freedom to solo: Where can your team explore? There are more places to allow team flexibility than you might think, even in highly regulated software products. Examine teamwork/meeting norms and practices. Work with product and customer-facing teams to determine flexible approaches to meeting business needs while hitting delivery deadlines. Question the way that “things have always been done” and see if you can work to find improvements, even if they are small. Give others the opportunity to multiply their skills with opportunities to mentor, share, or lead, even if they are informal.

    Invite musical conversation: Call and response and phrases are part of the language of jazz. A single soloist doesn’t solo over an entire set. Even within the same piece of music, musicians take turns soloing, sometimes “trading fours.” To trade fours is a kind of conversation where you listen intently to your fellow band mate and respond to their musical idea in the moment, incorporating their ideas into your response.

    Invite this kind of constructive conversation into your team dialogue. Listen intently, especially when you disagree (this one is quite hard for me, and I still require practice).

    Handling resistance: With flexibility comes questions, and sometimes resistance. This isn’t necessarily bad. However, watch for people who become stuck in a particular role. You’ll have your soloists, who ask “Why does every MR need two reviewers? It works on my machine.” And you may have your highly trained classical-musician types, who insist on following a score note by note, because “We’ve always done it this way.”

    To work with those team members: Listen. Respond. Be patient. Change is hard, and flexibility can be uncomfortable, even while freeing. Building trust takes practice. But once your team starts playing together with purpose and creativity, the sound is unforgettable.

    This is the first post in my Jazz Leadership series. In upcoming posts, I’ll dive deeper into each pillar: how to establish standards that enable collaboration and organizational maturity, practical techniques for building trust, creating the right constraints for innovation, and developing the listening and collaborative skills that help great engineering teams thrive.

  • Great Engineers Aren’t Always Great Managers – Here’s How We Can Change That

    Most engineering managers were never trained to lead people, only to ship code. And often, it shows.

    In tech, management roles are frequently given to high-performing engineers who receive little to no leadership training. Sometimes, this happens because an engineer actively wants to move into management. This post isn’t about those engineers — they’re doing great! More often, however, senior engineers are pushed into management because it’s the next (or sometimes the only) step available for career advancement.

    Unfortunately, this sets these senior engineers—and their teams—up for frustration, burnout, and underperformance. I first noticed this gap between engineering skill and people-management skill when I transitioned from leading quality teams to leading engineering teams. I reached the final interview rounds with several companies, only to be passed over for more technical candidates who performed better on code reviews. At one company, the senior engineer who interviewed me for the coding round even reached out to say I was her preferred candidate — but the hiring manager wanted someone more technically advanced.

    Myth: Great Engineers Make Great Managers

    Over the past fifteen years, I’ve worked with many engineering managers—from first-line managers to VPs of Engineering to CTOs. The least effective of them were often exceptional engineers who prioritized technical expertise over communication, business acumen, and building high-trust environments.

    In those environments, engineering teams were poorly represented in cross-functional spaces. I saw former engineers micromanage their reports, insisting they use the exact technical solutions they would have chosen. Eventually, many of those direct reports left in search of greater autonomy and opportunities for growth.

    Why is it that organizations assume a great engineer will automatically make a great manager? There seems to be a persistent belief in tech that technical excellence translates into leadership excellence—as if an engineer’s brilliance will magically “rub off” on their team. Perhaps it’s because management is sometimes seen as less valuable or less skill-intensive than engineering.

    But those of us who have worked under ineffective managers know how harmful these environments can be. MIT knows it too. Their Engineering Leadership Program for Emerging Engineering Leaders emphasizes that engineering management is a fundamentally different kind of leadership—one that centers on trust, team-building, and aligning smart, capable people toward a shared vision, even when they disagree.

    Getting people to disagree and commit is its own skill. And it’s not easy to learn.

    Fact: Ignoring Management Skills is a Problem for Everyone

    Focusing only on technical skills when promoting into management roles can hurt everyone—especially the new manager. I once worked with a director-level manager who was still deeply involved in coding. While many engineering organizations admire this model, it can be problematic. This manager overlooked and even dismissed team members who used different approaches than their own.

    Worse still, the director failed to build relationships outside of engineering. Collaboration with other departments was contentious, when it existed at all.

    This isn’t surprising. Educational research shows that leaders who lack people-development skills tend to have more disengaged staff and lower-performing teams. In my experience in education and leadership development, I’ve seen how learning different leadership styles can help grow individuals, resolve performance challenges, and align teams around shared goals. Personally, I use a situational leadership style and aspire to a transformational one.

    “At the most basic level, transformational leadership is used to inspire employees to look ahead with a focus on the greater good and to function as a single unit with a common goal in mind. It is not until a leader accomplishes these steps that a successful transformation can begin.”Shayna Joubert, 2024

    What Great Engineering Managers Do

    The best engineering managers I’ve worked with came from a variety of backgrounds. One was a top-tier engineer who became a respected industry leader. Another grew a company from two employees to nearly two hundred. The best I ever worked with had previously worked in engineering-adjacent roles and became a highly effective director.

    Despite their different paths, they shared three key capabilities: strong communication, a focus on people development, and a clear sense of purpose. Here’s what they did well:

    1. Build trust through open communication

    Each of these leaders communicated with transparency, telling their teams as much as possible, as early as possible, about business decisions that could affect them. This built trust and made space for meaningful conversations.

    When something wasn’t going well, they addressed it immediately and clearly, then offered guidance and support—without prescribing solutions—so that team members could analyze and solve problems themselves.

    They encouraged opposing views, invited tough questions, and created environments where healthy disagreement improved outcomes. When team members felt heard, they were more committed to solutions.

    2. Let go of your old job and trust others

    These leaders had fully stepped out of their previous engineering roles. They trusted their reports to understand the vision, execute the plan, and learn from both successes and setbacks.

    When someone succeeded, they celebrated the win. When someone struggled, they approached it with curiosity and support, not blame.

    3. Redefine your purpose: grow the people who grow the product

    These leaders understood that their role was no longer to be the best individual contributor. Instead, they were multipliers—amplifying impact by developing others. Each person they mentored became a force for greater outcomes across the organization.

    Management Is a Learnable Skill

    The good news? Just like engineering, management skills can be learned and improved.

    If we want to set senior engineers up for successful leadership, we need to teach and reinforce key management competencies. Even experienced managers benefit from refreshing and expanding their skillsets.

    Here are three areas to focus on:

    Giving and receiving feedback

    Structured mentorship and regular feedback are key to improving performance and retention. Using models like SBI (Situation–Behavior–Impact) can make feedback more actionable and trustworthy.

    Leaders also need to ask for and receive feedback to grow trust, model vulnerability, and stay aware of their blind spots.

    Developing emotional intelligence

    Emotional intelligence is critical to effective leadership—but it’s also one of the hardest skills to build. It requires honest self-reflection, empathy, and a willingness to grow.

    Practices like journaling, daily reflection, and leadership coaching have helped me immensely. Many strong leaders use similar tools.

    Becoming a lifelong learner

    Great leaders are constant learners. Staying curious and informed boosts confidence, cognition, and work-life balance. (And learning doesn’t have to stay in your field—I’m a violinist, and I draw leadership lessons from music all the time.)

    Some companies invest heavily in management training, while others offer little or none. I once worked for a deeply technical company that also provided the best management training I’ve ever attended—it was required annually.

    Even without formal programs, resources are widely available. Many companies offer education stipends. High-quality research and training are available online. And interactive formats—virtual or in person—can offer real-time coaching and feedback.

    The key is recognizing that management is a skillset, as complex and valuable as any technical one.

    A New Definition of Great Engineering Management

    It’s time to broaden our definition of leadership in engineering.

    Great engineering managers don’t just ship code. They lead with emotional intelligence, invest in the growth of others, and build resilient, collaborative, high-performing teams.

    They don’t just grow products—they grow people. And people make all the difference.

  • Ms. Jessica

    jess ingrassellino, October 2020

    I was the headmaster at my school for orphans. “No, no, NO! You have to

    stand right here. Princess wouldn’t go over there,” I’d command my younger sister, who played every supporting actor role with passion and vigor. We played this game where we pretended to be orphans every day after school. I was probably ten or eleven before we fully quit the game because we got too old for imaginary sanctuaries.

    It’s kind of funny to me now, to think back on what I thought teaching and helping were. Mostly, I thought it meant being in-control, and getting to have control. Both equally appealing to my child-mind. It was strange when I realized that teaching, the art, the act, had nothing to do with power or control.

    “Miss Jessica. Miss Jessica, will you help me with my card?” This little boy was a first-grader in the classroom where I volunteered after school a few days a week. In a rare moment of clarity, my mom had recommended that I volunteer in classrooms since I was interested in teaching, so I did. I met with the elementary school principal, and the next week, I was volunteering in a first-grade classroom – actually, my first-grade classroom, with my first-grade teacher, who was now in her forties.

    “Oh, that’s a beautiful card. Your mom will love it.”

    “This card isn’t for my mom,” he replied, “it’s for my Grandma. My mom’s dead.”

    As a sixteen year old, that was pretty much peak awkward. I tried my best to recover: “Well, I know your grandmother is just going to love that card.”  For weeks after,  I felt like a fool for assuming that he had a mother because he was making a card.

    Over and over again, my students have called me out — usually inadvertently — highlighting the gaps in my knowledge and limits in my experience. I’ve started to think that teachers are just people who like learning things the hard way. Within my first four months of teaching high school, I was certain I’d lose my job.

    “You know what lady, I don’t give a shit!” Eddie shouted.  Eddie, the 19-year-old senior. The genuinely nice kid who put on the tough-guy armor to make the world safer for himself.

    “Yeah, well, you know what?”

    I, all twenty-three years of me, yelled, “I don’t give a shit either. Now go to the principal’s office!”

    Yeah. I did it. I lost my entire temper in fifteen seconds. Couldn’t sleep for a week. Kept waiting for my whole career to get upended. You know what they don’t teach you when you study to become a teacher? They don’t teach you that all of the shit you’re struggling to leave behind is the shit that’s going to bite you every day until you deal with it. That illusion of control I had when I was five? It went out the door with Eddie.