Adam Gonnerman

 Almost 10 years ago I was invited to help set up some computers with Linux distros at a community center in Uberlandia, Brazil. My family had moved to Brazil to be closer to relatives, and I was teaching English as a foreign language while looking for a full-time job in project management. This invite aligned with my interest in doing social good, so I gladly accepted. It turns out that a bank had donated a lot of used computers to the NGO, and we were rehabilitating them for use with one of the Ubuntu derived distros (I don't recall which one). The more I got to know about Estação Vida the more I liked it and felt drawn to its mission. "The philosophy of the Estação Vida Project is based on four pillars: – Ethical Values and Spirituality – Educational Support – Sensitivity through Workshops – Preparation for the Job Market The institution contributes to the neighborhood in a broad way, encouraging the systematic participation of families. It also offers space for the Tele...

The other day I mentioned MoSCoW prioritization method in passing , and I realize it's actually worth a slightly deeper dive. So, I'm including a video here that should help clear it up.

Ideally, backlog refinement should be handled primarily by the product owner with input from the tech lead. The product owner is taking direction from the business on prioritization, and the scrum master simply makes sure refinement takes place. What do you do though when stakeholders aren't in alignment on on the priorities? Here are a few steps I take when this comes up. First, I ensure there's clarity in the backlog items. We need to have well-defined user stories complete with scope and definition of ready clearly outlined. Business value, effort, and dependencies should be plainly stated.  Second, I facilitate a stakeholder discussion based on these backlog items, focusing on organizational goals and not personal preference. This means I need to frame it in terms of return on investment (ROI), risk, and dependencies. Once this is understood by all, we can move on to actual prioritization.  Third, I use a prioritization framework to draw out the relative importance of the ...

When I was being interviewed for my first startup job many years ago my resume still reflected that I had been a minister and a missionary. One of the questions that came up in the group interview was how I thought my ministry experience might benefit me in this particular role. I must have given a good response, because I got the job. In fact, I've brought to my career learnings from both ministry and English teaching (ESL/EFL).  From the world of ministry I first brought working with people toward a goal. This sometimes involved volunteer management as well, though mostly it was working with a team. In Brazil I worked with a team of Brazilians to start a church. In the United States I worked with staff and volunteers to grow the church. People management is one of those so-called "soft skills" that's essential for project management, particularly when it follows a servant leadership model.  When I got involved in Agile, and Scrum specifically, I quickly realized tha...

Some time back I heard about a young man who had graduated college with a technical degree and had gone over a year without finding a job. It's a tough market, of course, but I learned he failed to do something very important, which made it even more difficult. While he was in college he did no extracurriculars, like a computer science club, and he never actually worked. As in, he didn't do any work of any sort. He was a true full-time student with nothing else going on. That's a problem.  When I was in college my plans were very different from where I would up. My heart was set on ministry, and I took every step to prepare myself. I studied, sure, but I also went on a mission internship, did some outreach work with my college class, and supply preached practically every Sunday. I built a background in student ministry that went on my resume.  I have a friend whose daughter is following a similar path in her student career. She's studying natural sciences and has alread...

Unless you’ve seen the long version of my resume, you might not know that I’ve spent time teaching English. I never worked in public or private schools, but I did teach in language schools—both in the United States and in Brazil. In the U.S., this type of work is called English as a Second Language (ESL). Abroad, it’s referred to as English as a Foreign Language (EFL). Here’s how I got into it, what the experience was like, and what I learned along the way. Getting Started Before moving to Brazil to teach English, I took two important steps to prepare: Training: I completed a distance course in ESL/EFL teaching through The English Language Centre in London. At that time, the program was mail-based rather than online. They sent me study materials and assignments, and I responded with lesson plans and exercises. It was a traditional distance learning model, and I still have the certificate to this day. Volunteering: I spent a semester working with ESL students in a Missouri public...

One of the most rewarding parts of my work as a project manager is leading cross-functional teams from design through execution to project close. These groups bring together diverse perspectives, and my role is often that of translator and coordinator, making sure everyone is aligned and moving in the same direction. If you think about it, each function approaches a project with a different lens. Product wants to deliver user value, engineering is focused on stability, and operations is concerned with predictability. When you add in design and other functions, the perspectives become even richer. The challenge, and the opportunity, is to bring these different priorities together in a way that results in an executable plan. What I enjoy most is seeing the impact of this collaboration. When cross-functional teams work well together, the outcome is stronger than any one group could achieve on its own. It is incredibly satisfying to watch product, engineering, operations, and design combin...

Sometimes a team has tight deadlines or a heavy workload. Or both! I've encountered this in nearly every position I have held, although it wasn't usually a constant but more of a phase. For example, I worked at a startup where the team was tasked with redesigning the website and refactoring the web app at the same time. They had trouble in the past delivering consistently, so I led them through an Agile transformation as well, and they became a scrum team. This allowed us to begin to get a notion of their capacity for work. However, pressure was on to the get a large amount of work done in a very short time period. Here's how I approach the situation. First, we acknowledge reality. It doesn't do any good to pretend that the pressure isn't there. Recognizing as a team that we have a lot to do and not a lot of time to do it makes the situation clear for everyone, and relieves some of that stress of feeling like the burden is unseen. Second, I work with the product own...

Many times I have watched scrum teams ignore their historic capacity and proceed to add more work than they can possibly do to a sprint. Sometimes this is because a manager insists they include " stretch goals " in the sprint. Bad idea! Other times it's coming from the product owner who is being pressed by the business to deliver multiple features in a short time frame. This simply won't work. If you have a stable scrum team, made up of regular team members who do not switch out to other teams or work, you can determine their capacity by watching their velocity. If they commit to 100 story points of work but consistently deliver around 70 story points, then you have your capacity. The only way to increase their capacity is to increase the team size, which itself presents problems. When you add members to an established team, two things happen. First, the team overall can slow down as the new members figure things out and the team relearns how to work together. Second,...

Recently I was asked in an interview what it is I like about project management. My answer then was hastily put together on the spur of the moment, but it got me thinking. What do I like about being a project manager? I became a project manager rather unexpectedly. At a startup I had a role that added up to being a web producer. That led to a role where I formally had the title of web producer, at Conde Nast. There, a new manager organized us as a PMO, pushing and persuading team members to improve their skillset as project managers. I was given some small projects to run, and soon enough I was promoted to associate project manager. This wasn't a career path that I expected, but it's one I truly appreciate. Since those early days there have been many interesting, challenging experiences along the way, all highlighting to me the aspects of project management that I enjoy. Collaboration and teamwork is top of my list. On one occasion I was assigned to a team that was newly forme...

During the 2008 financial crisis, I had the good fortune of working for a well-funded startup. Having money in the bank gave the company stability, and I was shielded from the worst of what others were experiencing. Today feels very different. In just a couple of weeks, I’ll hit the 4-month mark of unemployment. My year-long contract with Meta ended in April, and despite starting my search last December, I still haven’t landed something new. It hasn’t been for lack of effort—applications, networking, interviews—but the opportunities simply aren’t there in the numbers they once were. I’ve seen many others posting similar stories: long months of searching, recruiters ghosting, interviews that stall. It’s a reminder that this isn’t about me lacking skills—it’s about a market where there just aren’t enough roles. I bring 10+ years of experience in project and program management, Agile methodologies, and cross-functional leadership. I hold two Master’s degrees. I know how to help teams deli...

When a Scrum team plans a sprint, they should do so with their velocity in mind. Velocity, in the context of Scrum, refers to the average number of story points a team has completed in past sprints. This metric serves as a reliable gauge of the team's capacity and should guide the amount of work planned for each sprint. Assuming the team has been working together for a while using the Scrum methodology, their historical velocity provides a realistic benchmark for future sprints. Planning sprints based on velocity ensures that teams do not overcommit or undercommit. Overcommitting by adding more work than what the team's velocity supports can lead to incomplete sprints, while undercommitting may result in underutilization of the team's potential. It is essential to strike a balance, and the team's average velocity helps achieve that balance. Temptation to include additional work beyond the team's velocity often arises, particularly from product owners who may see str...

In 2008, I was working for a major telecom company, handling calls for large business and government accounts. One day, while looking at an organizational chart, I realized my only available career moves within the company were lateral. I could shift to data support or something similar, but there was no clear path upward. I needed to move on. I searched online but couldn’t find many customer service options in New Jersey, where I lived. Then one night, it dawned on me to check New York. Believe it or not, I found my first job at a startup through Craigslist. Here, I'll share some of my thoughts on startup life. First, in a startup, you wear many hats. I was hired to provide "white glove" service to our clients, but with only a handful of customers, my primary role became content preparation. I processed investment newsletters from print, email, and PDFs into a format that our web application could display. Along the way, I also took on minor technical tasks, like fixing ...

Many people approach work with a "clock in, clock out" mindset. While this might get the job done, it limits personal and professional growth. You may become highly proficient in your current role, but what you truly need is experience that prepares you for the next one. Developing curiosity about different roles can expand your skill set and open new career opportunities. Exploring other roles broadens your understanding of the organization. Observing how different teams and departments function helps you see the bigger picture, while understanding cross-functional collaboration improves teamwork and efficiency. This, in turn, enhances your own job performance. Exposure to different roles provides valuable insights that can strengthen your current work, offering fresh perspectives and problem-solving strategies. Ultimately, this creates career growth opportunities—having a diverse skill set makes you more adaptable to change, and familiarity with adjacent roles increases you...

In my late teens and early twenties, my sole career focus was ministry. When I first expressed this calling, I quickly realized that traditional congregational ministry didn’t feel like the right fit for me. Seeking guidance, I approached the pastor of my church—part of the Presbyterian Church (USA) —to ask if there were alternative paths in ministry. Unfortunately, he didn’t have the time to discuss it, and before we could follow up, I had moved on to college. In college, I continued preparing for ministry, but every discussion and lesson centered on congregational work. Over time, I became so immersed in that narrative that I lost sight of any other possibilities. After a brief yet relatively successful stint as a missionary in Brazil, I accepted a call to serve a small church in New Mexico, part of the Christian Churches/Churches of Christ . It turned out to be a terrible experience. One elder regularly solicited critiques of my work from the congregation and then relayed them to me...

Being laid off is terrible. Having been laid off a few times myself, I know well the shock and anxiety of the experience. This post isn't about the people who are laid off, though. It's about those left to carry on. What follows is my advice to survivors of layoffs. First, take time to process what's happened. This is often said to people being laid off, but it's not much use to them, as generally they have no time to waste in this job market to look for another job.   For someone who has made it through a layoff there can be a variety of feelings. Acknowledge your emotions, whether it's relief, guilt, anxiety, or sadness. It's normal to feel a mix of things. Second, support your former colleagues. Reach out to those who were laid off, particularly via LinkedIn. Offer emotional support, job referrals, or networking help if you can. Even better, check in on them a month or two later for these things. People when laid off often have a flurry of activity in the beg...

One of the most challenging aspects of project and program management is dealing with unclear or constantly evolving requirements. Whether due to shifting business priorities, incomplete stakeholder alignment, or rapidly changing market conditions, ambiguity is an inevitable part of managing complex initiatives. Your ability to navigate this uncertainty while keeping the project moving forward is what sets you apart as an effective leader. Here’s how you can manage ambiguity and bring structure to chaos. First, clarify the big picture. When requirements are vague, step back and focus on the broader business objectives rather than getting lost in missing details. Ask stakeholders: What problem are we solving? What does success look like? What are the key constraints (timeline, budget, resources)? Aligning on these high-level priorities ensures that even if the details shift, you have a north star guiding the project. Second, break down unclear requirements into known and unknown compone...

Following a project kickoff meeting, the real work begins. While a well-run kickoff sets the stage for success, what happens immediately after the meeting is just as important. Without proper follow-up, even the most productive discussions can lose momentum, and critical action items may slip through the cracks. Ensuring a smooth transition from planning to execution requires timely communication, clear documentation, and alignment on next steps. The first and most immediate task is to send out meeting notes. These notes should capture key decisions made during the kickoff, major discussion points, and most importantly, action items assigned to specific individuals. A well-structured summary not only reinforces what was agreed upon but also serves as a reference document for those who may have missed the meeting or need to revisit details later. Meeting notes should be concise but comprehensive enough to provide clarity on responsibilities, deadlines, and any unresolved questions. Dis...

In a previous post, I covered how to prepare for a project kickoff meeting. Now, I’ll discuss a solid format for running the meeting effectively. As I noted before, my early kickoff meetings were fairly informal—I would gather the right people, let them talk it out, and capture action items. While that approach had its merits, it wasn’t structured enough to ensure a project got off to the best possible start. A well-run kickoff meeting should set clear expectations, align stakeholders, and establish a foundation for success. The meeting should begin with a welcome and introductions. As the project manager, you are the host, and your role is to set the tone and facilitate a productive discussion. Introductions help build rapport among team members, especially if they haven’t worked together before. Having each participant share their name and role in the project is a good start, but adding an icebreaker can make the meeting feel more engaging. Something simple like “one thing people do...

Early in my career, as I transitioned from site producer to associate project manager, I didn’t have much formal guidance on how to do my job. Instead, I relied on observing experienced project managers and learning from their examples. Over the years, I’ve honed my skills in managing dependencies, facilitating discussions, and simply running effective meetings—essential skills for any project manager. One of the most critical meetings in any project is the kickoff meeting. It sets the stage, aligns stakeholders, and ensures everyone is working toward the same objectives. This post is the first in a three-part series on kickoff meetings, beginning with preparation, followed by execution, and concluding with follow-up. The first step in preparing for a successful kickoff meeting is creating a solid agenda. Early in my career, my approach was fairly loose—gather key stakeholders and the project team, present the scope, let them discuss, and then take follow-ups. While this method works, ...

In several of my roles as a project and program manager, vendor management has been a key responsibility. In one role, I managed vendor relations for a proof of concept (POC) to determine the best technology solution for a core business process. In another, vendor management was a significant part of my day-to-day work. Based on these experiences, I’ve learned that successful vendor management requires clarity, streamlined communication, and robust tracking. Here are three essential strategies for managing vendor relationships effectively. 1. Establish Clear Expectations from the Start One of the most critical aspects of vendor management is setting clear expectations from day one. This includes: Defining scope, deliverables, timelines, and quality standards upfront. Establishing clear Service Level Agreements (SLAs) and Key Performance Indicators (KPIs). Ensuring vendors fully understand project priorities and dependencies. A key lesson I learned in one of my roles involved receiving ...