FLueid Software Corp: Startup Process

What does a TPM do exactly? Its a controversial topic, and varies depending on need in many companies. What is constant no matter the definition is we make things less scary. Everything seems to run smoother and people are less stressed with a TPM. Why is that? TPMs are experts in process, but just the word "process" itself can be scary and stressful. TPMs craft process. This cant be done in a bubble and needs to include timeline management. 

When I enter a new team or organization, I first spend time analyzing the team's current process: how they work. Then, I tweak small things, and build off what they already do, causing minimal disruptions. Often the team will just be in a retro a couple of months later and say, "wow, we've really hit our stride... when did that happen?" and the answer is incrementally. A TPM best serves a team by making incremental changes- just like developers put out increments of code- taking the team along with them on the journey toward a cohesive process.

Process doesn't need to be scary. In fact, let's redefine it: process is communicating how we do things to unify the workings of a team. Even people who hate process have a process, and a good process is based on agreeing and communicating that process among teammates. Some devs and managers are just accustomed to their way and don't even realize the next person may do it differently. TPMs recognize patterns in work, find the most efficient route, document it, and communicate it out among the team, working with them to guide a more cohesive working practice where everyone is on the same page.

Communication, though, is always easier said than done. Often teams hit pitfalls when they unknowingly segregate and silo their processes. One of the key components of a TPM is the cross-departmental process; we recognize and streamline process across departments. To do this, one cannot neglect education. Customer Engagement teams need to know how development cycles work, better serving their ability to effectively negotiate with partners. Leadership needs to high-level understand resourcing and time- the two constant limitations within development- to keep pragmatic goal setting in roadmaps, sales, and with investors. TPMs play a key role in educating other departments in the development process, identifying where key members may be best served to "give away their legos" and unifying the company. 

Teams often confuse Agile with "no planning". The reality is Agile is hard and doesnt work for many (most!) companies. Many TPMs lean on "hybrid" process and can get hung up on making their org Agile without understanding what that means. A team doesnt need to go to Agile University to understand what makes sense for them, nor is Agile always feasible. TPMs can be integral in planning, staying aware of resources and their capacity, and how to properly gauge and space out work among sprints. Planning doesnt need to be two hour meetings; it can actually be done without a meeting at all! 

When a TPM owns the timelines, they are able to schedule planning into the development tickets. "Design" (or "POC") tickets prior to a project officially starting affords the development team needed time to conceptualize the project. Creating "breakout tickets" as an acceptance criteria allows for a project to be broken down into actionable goals that translate into blocks of work for tickets. This is all work easily done in a meeting, but allows the team more ownership and oversight of the technical implementation, which in turn allows for better estimation and realistic timelines. Most wonderfully, this also allows us to plan out sprints three months in advance (sometimes longer!) while remaining "agile" in the common sense. 

Using this method better brings along the development team for a project and allows for pragmatic timelines which keeps everyone on the same page when the TPM communicates out. These timelines are now backed up realistically by our two finite resources- people and time- and allow leadership and client engagement to have discussions early on expectation setting. With correct estimation, this also provides the ability to under promise, over deliver every time. THESE THINGS ARE POSSIBLE!

One of the most important concepts is a harsh one. As mentioned, we are limited by resoruces and time. These things cannot be changed (usually). Everything is always due yesterday and there's always more work than there is people. These are development constants in any company. There's no use stressing about these things as stressing will not change them, yet somehow they always become the largest contention of an organization! We must learn to work within these boundaries and provide others with the tools to do so. 

One of the hardest lessons a TPM can teach leadership is how to prioritize. A TPM often is called a servant-leader, someone without any real power, yet expected to lead multiple programs, projects, and teams. To do this, we must be able to manage up. The hard reality of limited resources and time is summed up simply by asking which project is most important. It seems obvious! But its a hard lesson for leaders to learn when they want everything and they want it yesterday. It's not for the TPM to dictate priorities, merely to evangelize them. 

Providing options and putting the onus on leadership (whether it's the CTO, product team, or some mix of stakeholders) to decide which options to roll out and in what order is the most important sprint planning discussion that a team can have. Without those priorities being set and followed for the sprint, the team is at the mercy of constant change. A TPM must be stalwart in facilitating and following the priorities set, and must be outspoken when dictated priorities are not pragmatic. Decisions should be made not on emotions ("I feel like...") but on information ("'Project A' takes this time, with these resources and the delivery date of x, vs 'Project B' which would be done sooner if one resource is allotted and we would be able to release 'Project C' sooner with one of Project A's resources...").

It's easy to play the blame game when projects are failing and timelines are being missed. But ask yourself how you are using your TPMs. Often TPMs are underutilized or overly bogged down by other tasks. Redefining the role of your TPM and empowering them to own timelines, manage sprints, and enforce priorities can change the way your team is able to plan which in turn will change the way your team delivers.