4. Wrangling Engineers
A big part of the product manager’s job is providing engineers with everything they need to be productive. Sometimes the product manager feels their job is to tell the engineers what to do, but they quickly learn this is like trying to herd cats. Even with the best will in the world it’s just not the natural way of things.
Your job instead is to provide focus and direction and meaning and to make sure goals are clear, requests are well scoped, engineers are core participants in the conversation and ideation needed to craft solutions.
Towards the end of this year Rosenfeld Media will be publishing my book Product Management for UX People: From Designing to Thriving in a Product World (you may sign up there to be notified when it is available for order), the culmination of a multiple-year project that has unfolded with the input and support of the Design in Product community.
During the editorial and production process I am sharing early drafts of chapters, and I welcome any feedback here that will strengthen the material.
Sure, of course you want people to do things. You give direction and you should always be willing and able to express a strong point of view, even if you need to come up with one on the spot. But you’re not a dictator. Engineers don’t report to you, 99% of the time, nor should they.
But they are part of your team, a team you need to nurture and foster and make as productive as possible, so researching problems, defining requirements, and clarifying nuances all help your engineers focus on what they do best. (Motivating, persuading, and rallying them also comes with the territory.)
Also, remember, engineers are makers. Unless they are managers themselves (in which case they are your adjacent colleagues in many things), they are creators who benefit from large stretches of uninterrupted time in which they can summon up complex mental models of the problem, solution, algorithm, or logical issue they are working through.
Interrupting them for a “quick meeting” is like asking Coleridge the time of day when he is trying to get home to write down Kublai Khan before he loses it. The overhead involved in switching to a discursive mode and then returning to a code project isn’t seamless. The spinning-up time starts again almost from scratch. Now you’ve cost your dev at least an hour or a good sixth of her productive time today.
For this reason you try not to harry engineers with micro-interruptions but instead focus your communication, feedback, and direction into asynchronous written formats the developer can review when it suits them, and the regular cadences of agile scrum rituals.
Keeping Engineering Teams Aligned
At this point in your UX career you likely have at least passing familiarity with things like standups and sprints, but you may not have always had them as a routine part of your day or week. Product managers set their clocks by these “rituals,” which are formally structured meetings generally focused on syncing and recalibrating, but can also be prospective or retrospective depending where you are in a given cycle.
These cycles (daily standups, weekly sprint rituals, monthly roadmap updates, quarterly planning) are collectively referred to as cadences and together represent your primary channel for collaborating with and providing direction to engineers.
Cadences
You can think of these things as fractals. You do the same thing over and over again at each scale, and the stakes get higher by an order of magnitude at each longer cadence as well.
For almost every agile team, the smallest cadence is the daily standup (Figure 4.1). Traditionally, this is done standing up to remind everyone that it is a quick check-in and not a detailed working session. Each person reports on what they accomplished since last time, what they plan to get done in the next day, and what if anything is blocking their progress.
The daily standup is just one of the scrum rituals (from backlog grooming to sprint planning to demo, product acceptance, and retrospective) that take place during the sprint, which will typically last two to four weeks (Figure 4.2).
Once a month it’s a good idea to review the roadmap to make sure the Now items are all progressing as planned, the list of Next items is still current and accurate and preparations are being made for when those items move into Now, and all other ideas beyond the current horizon are captured under Later (Figure 4.3).
In addition to monthly roadmap reviews, some companies, such as Intercom, divide each quarter into two six-week chunks with a “wiggle week” in between.
Once a quarter it’s time to for the product team, along with all other stakeholders, to review progress against the goals going in from the start, define goals for the quarter ahead, and review progress against the annual plan (Figure 4.4).
Once a year you take stock at how the year went compared with the plans made at the end of the previous year, marvel at how many things occurred that were not anticipated, take those learnings, revisit the vision, mission, 5-, 10- or even 20-year goals, and come up with a working plan for the year ahead (Figure 4.5).
At every level, there are some simple principles at work to help maintain alignment and correct your steering at every scale. Just as the “lean” concept builds on the cornerstone cycle of “build, measure, learn” (repeat), “agile” practices follow a very similar ethos that boils down to “iterate, review, recalibrate” (repeat), combined with the idea that at every scale your goal should be to complete something that can be review, tested, and either sent back for more changes or accepted.
Threaded throughout agile principles and practices is this approach to routine course-correction “with a preference to the shorter timescale” (Principles behind the Agile Manifesto).
Only one of the original twelve agile principles (the last one) spells out this notion directly, when addressing systematic iterative improvement of team processes over time:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If you pause a moment to reflect, this is fairly “meta” — it basically take the power of this deceptively simple idea (of routinely reviewing and course-correcting) and tells you to apply it to how the team itself is working as a whole, and not just to the code getting written and tested.
Very powerful stuff!
From the Trenches
You find yourself working in a shop that has adopted SAFe (Scaled Agile Framework for enterprise). I am sorry to tell you that SAFe is the devil. It’s a corporate set of formal agile-style processes that create what is often called “agilefall,” reinventing the waterfall project plan (the exact thing the Agile Manifest was rebelling against) with the trappings of rigid interpretations of Agile rituals. Having said that, shops that use SAFe often derive a benefit from the approach as compared with what they replaced it with, and in that sense it can be viewed as a step in the right direction in the difficult challenge of asking a large corporate enterprise to fully embrace the most difficult aspects of agility.
Sprint planning
The hands-on tactical day-to-day world of a product manager revolves around engineering sprints (and, in some dual-track systems, on staggered discovery / UX / design sprints as well). You generally have a very good sense of where you are in the sprint at any given time, and your daily standups should be keeping you abreast of progress as well as blockers (things that are preventing developers or others from completing their tasks) and nonblocking problems.
Sprint planning is a process and often a meeting for determining which user stories, bug fixes, or other engineering tasks will be scheduled for the sprint about to start. This is a negotiation among all concerned, but primarily between product and eng.
The candidate issues come from your backlog. An ungroomed backlog is simply a long list of proposed ideas, tasks, wishlist items, and so on. They need to be reasonably well specified before they can be considered for a sprint. The process of putting the backlog into a priority order and making sure the items at the top of the backlog are ready to hand off to an engineer is called “grooming” the backlog (Figure 4.6).
There are multiple methods for estimating and scoring effort, and then comparing estimated effort for the desired tasks against the available time and resource budget. Early tries at sprint planning often underestimate overhead, meeting, managerial, and operational time (not to mention setbacks and learning experiences), but within a few cycles most teams get a collective feel for their rough capacity.
During a Sprint
During the sprint you may need to add new items or to demote some to the backlog again. Part of being agile is adapting to changing circumstances, but this can sometimes make it hard to measure actual results vs plans using such items as burndown charts. The team learns faster if everyone can see clearly the gap between estimates and plans on one side and actual results and outcomes on the other (Figure 4.7).
Many teams use Kanban as a project-management tracking method during sprints. This is a model in which real or virtual sticky notes summarizing user stories or tasks are moved from one column to the next as they progress through the software development workflow (Figure 4.8).
When a team is co-located in one physical location, there can be a real kanban board with sticky notes on it, where everyone can see as tasks move through the workflow (Figure 4.9).
But many teams, and not just distributed or remote ones, tend to use Kanban-style software these days. Trello, for example, is wildly popular kanban-type software that many product teams swear by, and most of the tools that support sprint-planning and other agile project management processes now offer a kanban view (Figure 4.10).
Another aspect of PMing should feel familiar from your UX experience: responding to issues that arise during a sprint. This can be a matter of clarifying a specification, filling in a gap to address an unanticipated scenario (anything from an error case to a clash between requirements that could be resolved in multiple ways), working with the designer to address challenges in implementing the design as delivered, or getting in front of a white board with the developer and others to work through system-level choices.
What’s Your Definition of “Done”?
A sticking point for many teams making software and trying to be agile about it is how to know when something is done. As you get down into the weeds, there always seems to be more you could do. There are almost always some bugs that are borderline in terms of not impacting people in very many scenarios and not causing severe inconvenience (usually because there are easy enough workarounds). There are always some edge cases that the code doesn’t handle perfectly yet. There may be long-tail mobile devices that don’t pass every test. The closer you look, the more you see.
But a big part of the product role is making these tough calls, the ones that might go either way but that if you get too many of them wrong will either delay your project unacceptably or, worse, deliver buggy code and terrible experiences in the interest of keeping to a schedule.
But, again, the product manager is not a dictator. Instead, it’s incumbent upon the PM to take responsibility for establishing a “definition of done” that everyone on the team buys into.
This usually ties back to the requirements documents that defined the original problem space and specified what the solution needed to achieve to address these problems. If everyone signs off on a definition of done, then it shouldn’t be controversial later when a PM needs to say “we can’t ship this as if some users will lose their data” or “if it doesn’t run on Android devices,” and so on.
Definition of done also means coded, tested, and accepted. Without clearly defining that a thing isn’t done until it has passed through the entire workflow, there is a risk of constant slippage from sprint to sprint as chunks of code are called “done” because they were built before the sprint expired but they still need to be tested in the next sprint and possibly revamped further depending on what testing reveals.
Lastly, clearly defining what it means for something to be done can help avoid the paralysis of perfectionism. Product management is no job for a perfectionist! Remember the Reid Hoffman line about how if you’re not a little bit embarrassed by the product you shipped, then you waited to long to get it out the door?
Product managers have a saying: “Good enough is good enough.” It’s an excellent reminder that your job is to ship a product that does the job for your customers that solves their problems and provides them enough value that they embrace your solution. It’s not about winning an award or shipping “bug-free code.”
Many product teams find it valuable to schedule a demo day at the end of a sprint. This is a meeting usually open to anyone interested in which engineers demonstrate the working code they built during the sprint. This can be part of the formal product acceptance ritual by which the PM declares the shipped code accepted or identifies gaps in the form of unmet requirements. It also gives other stakeholders a chance to see progress and a preview of what is coming soon, and to give the developers a moment in the sun after all those hours of coding in front of a screen, often sequestered away from the rest of the company.
Iterative Process Improvement through Retrospectives
At the end of a sprint, the product manager is responsible for making sure that a final key agile ritual, the retrospective meeting takes place in facilitated way. This may involve convening and facilitating the retro directly, but even in cases where a product owner or scrum master runs the meeting, the product manage still participates and pays close attention.
This comes from that 12th principle of reviewing team processes and improving them constantly. To prepare, the team is asked to reflect on two key questions: “What went well?” and “What can we improve?” and to suggest specific actions team members might want to take based on what was learned during the sprint just ending.
Using a tool such as EasyRetro, the team can pre-populate a chart with their own items as well as comment on or vote for each others (Figure 4.11).
The PM should facilitate a non-blame-oriented discussion both reinforcing the reflections on what went well and making space to explore what went wrong and how such matters can be better handled in the future. As team members suggest affirmative steps drawn from those insights these can be voted on and prioritized as well.
When practiced in an open and healthy, supportive way, team retrospectives can spur incredible advances in team cohesion, coordination, and effectiveness.
Author’s opinion: Don’t call them “postmortems.” That’s just morbid.
Getting Results
While it’s critical to keep the wheels rolling and the trains running, ultimately the scrum-master-ish, product “owner” aspects of the product management job are tactical and task based. Diligence and experience usually suffice to equip a PM to run sprints and manage a backlog. But none of that addresses the so-called “soft skills” related to people management and bridging cultural divides in multi-disciplinary teams where people with different training and inclinations often speak entirely different “business dialects.”
Giving Respect
Step one is to show respect for engineers. This doesn’t mean rolling over for them or taking No for an answer without an explanation. But it may mean dropping the unfortunate attitude some user experience folks take that presumes that they and they alone care about the user, about the experience, and about quality, and that the developers are a bunch of unfeeling automata who just want to crank out code and call it a day.
A key way to show respect is to learn the lingo. Design means something different when an engineer is talking about their “technical design” (a document capturing how they plan to implement the product requirements). Lecturing them that they are using the word design incorrectly and then giving them ten minutes on the history of design and human factors isn’t going to win over anyone.
The UX skills you can and must use are your ability to research and understand the needs and motivations of a person. The experience you are designing in this context is not a software product but working with you. If you approach this with humility, you will find that you can meet your engineers more than halfway and present your goals and needs in terms they understand and appreciate.
This will take time, a lot of listening, and a conscious effort to study and understand the “folkways” of people who are different from yourself. Of course it will help if you are already something of a nerd, geek, or technophile yourself (and let’s be honest, you probably are). Lean into that and you’re already halfway there.
From the Trenches
Ken Norton, a product consultant, adviser, and educator who was at Google Ventures for many years crystalized the service aspect of the product role with the mantra “bring the donuts:
I BELIEVE THE BEST PRODUCT MANAGERS are willing to do whatever it takes to help their teams succeed. An important aspect of that is recognizing that PMs often have to do the work that would fall through the cracks otherwise. By definition that can be grimy, un-fun work: cleaning the bug queue, organizing a document repository, replying to a customer support email. No job should be beneath a product manager. PMs are more humble servants than “CEOs of the product.” They put their teams first, they do what needs to be done, and they demonstrate that every day.
In 2005 I was preparing to give a talk at Berkeley’s Haas School of Business about product management. I was looking for a rhetorical device to convey this and I settled on “bring the donuts.” If PMs don’t bring donuts for the team on launch day, who else will? I’m not sure why I picked donuts. At the time my competitive cycling career was still flourishing and bagels were more my style. But donuts it was, and the concept stuck. (What’s the Deal with the Donuts).
If a product manager bears in mind that their role is do whatever it takes to make the team successful, then they won’t go wrong.
Earning Respect
Besides showing respect and humility and a willingness to engage on engineering’s terms, a product manager also needs to earn the respect of the developers they work with, if they want to have any hope of guidance and leading the team to a successful outcome. For product managers who did not come from an engineering background, don’t write code, and aren’t framed as “technical product managers” the bar for earning respect may be set higher.
Another way to earn their respect: developers have the same “dark side impulses” that UX designers have, the same interest in making business decisions. As a PM, if you can give them the business context and help them influence the decision, they’ll feel much more bought in.
— Clement Kao
This new-fangled UX design-rooted type of PM therefore needs to stake out some technical bona fides if they’re not to be written off as a jumped-up designer who “doesn’t really get” technology or programming, just as the business-oriented PMs always have had to do so, as well.
But how do you establish these bona fides without essentially going back to school and becoming an engineer yourself? You don’t do it by pretending to be what you’re not or nodding along as if you understand a technical point when you don’t. And you won’t get there if you’re afraid to look ignorant by asking a question.
You do it by asking smart questions. What are smart questions? When in doubt they are all the questions you authentically have. When you’re unclear on terms, ask to clarify them. Show that you have some understanding of what might be meant but that you want to follow along precisely. The more you engage, the more your own mental model of the technical architecture, logic, approach, coding style, strengths and limitations of libraries and deep knowledge of the capabilities of your team will deepen and strengthen.
Clement Kao points out another service product managers can provide engineering as a way of earning your spurs: “Smart documentation is crucial too. If you document what you’re learning, it can also help newly-hired engineers onboard faster. That then earns you the respect of the engineering manager, since you just created more bandwidth for them.”
When the time comes to ask for something new or to propose an idea, you’ll then be able to ground your requests in the constraints and realities of the technical stack you’re working on and avoid something embarrassing like asking if they can build you a flying pony.
Note: Clement Kao wrote a helpful piece about Interviewing with Engineering Managers that can help you navigate the “engineer’s veto” over your getting hired as a product manager but giving you insight into what they look for, expect, and prize in a product manager..
Estimation and Negotiation
You may recall that sprint planning involves estimation and that the product role requires constant negotiation with your teammates. This need not feel like haggling in a bazaar. The product manager can set the tone for how differences of opinion and priority are aired and weighed, and recognizing what inspires your engineers and what frightens them can help you read between the lines when they resist something you want or when their estimate for the effort required surprises you in some way.
At one point, I had a team of two engineers that I privately thought of as “Jack Sprat and His Wife” because their inclinations were so complementary. One of the engineers, let’s call her Cheryl, saw risk everywhere, padded her estimates out of prudence from long experience of how things go wrong if they can and distractions are inevitable, etc. The other engineer, let’s call him Edgar, always envisioned a clear path, enthusiastically said yes to everything, and tended to underestimate actual effort by a factor of 4x.
Between the two of them I could usually get a handle on the likely real effort and by facilitating discussion among the three of us, I helped mitigate each of their strong inclinations with some balancing considerations. It’s not as though they ever talked each other round to adopting a new temperament, mind you, but we managed to soften some of the edges.
And there is an old tradition among engineers that the Trekkers among us may recall from the original show when the captain would pipe down to the engine room to ask how long it would take to repair damage and the chief engineer, Scotty would estimate 8 hours, only to be told “You’ve got two!” and somehow he’d always manage to meet these impossible goals.
As a child I thought this was a testament to necessity being the mother of invention and heroic leadership but in retrospect I came to understand that Scotty was padding his estimates.
Estimation is a topic unto itself, fraught with frustration and nearly impossible to do really well, but it’s a daily requirement of the work and becomes manageable as long as everyone approaches it as a best-effort approach to figuring out where to invest time and resources.
And remember, you are not their boss. (At least that’s true most of the time.) Your job is to inspire and persuade, not to command.
A Day in the Life of an Agency PM
Ana Giraldo-Wingler, product manager at Coforma (coforma.io)
I check Slack when I wake up. I come to my computer 15 to 30 minutes before my first standup and create a note for the day in the Notes app before I start work, as soon as I sit down. I go to my note from the previous day and copy over all the items that are still not done yet and I put it into my next day.
We do work for clients, which is different from being a PM at a startup. Then the other thing is that the particular client that we’re working with is the government. So that’s also a different thing because usually we think about a PM being someone who can merge business objectives with user needs, right?
In this case, the business isn’t really a business, it’s more an organization being the government. Then also on top of it, the product that I’m working on is a replacement of a 20 year old piece of software. So our requirements in a sense are different. It’s not like we’re building something that’s never existed.
If there’s a structure that dictates what, how each day is going to go, it really does depend on where we are within that sprint cycle. The first thing I think is “which agile ceremonies either just occurred or are coming up?” If I know we have our sprint review coming up in two days on a Friday, my Wednesday is going to involve prepping the deck that I’m using to intro the sprint review. I’m prepping the board to make sure that all the tickets are up to date so that when we’re showing them the stakeholders that make sense, I’m checking in with team members to check the status of a given ticket. Is it in the right list, et cetera.
As the PM I have to facilitate communication between the engineering, design, and business layers so that things are moving in a smooth fashion.
So the Wednesday, which is the first Wednesday of the two weeks sprint, we have a UX standup with myself, the UX designer and our researcher which is scheduled for 15 minutes, but ends up usually being 30. It’s pretty much always 30 and we should probably just switch it to 30 and stop trying to run it like a standup in the classic sense. It’s a check-in and we should call it a check-in.
I actually did propose that. Then we have our actual standup, which is 30 minutes after the UX check-in daily and that’s also daily. That’s the whole team, including the developers, and we also have a project lead, which is interesting. I’ve never worked as a PM on a project where there was a lead as well as a PM. That’s a symptom of being part of an agency where she’s in charge of the contract and our relationship with the main client. It allows me to sort of focus on the product things rather than on client management.
The next thing that I have is a meeting about delivery scenarios and database access with our tech lead because we are currently working with the government trying to get access to their infrastructure. It’s taking longer than we anticipated, so we don’t have the access that we need in order to build what we need to build. So that means we need to do a change of contract modification. So it’s a “working with clients” type of issue.
There’s a break I have here from 11:00 AM to noon, and sometimes I will have to take my lunch early as of the East coast correlation.
Then we had a meeting with stakeholders within the government to talk about some open design/product questions that we had with them. We’ve tested them with users. We got some feedback and now we have some questions for the stakeholders to get their input on our iteration. Then we have another meeting with different stakeholders called a co-design session with them, which is really fun because these guys are so creative and excited and they’ve been using the current product for so long. They’ve been accumulating all these ideas for how to improve it. One of them actually built the original product in the nineties and the other one has been using the product. So the co-creation with people who are deeply knowledgeable about it. We literally have Figma open and we have our designs and we’re dragging things around. That’s cool. And like, is this what you mean? Is that what you mean? We’re asking questions (myself, the UX designer and the researcher).
Then we also have to coordinate with a different organization that’s building the API that we’re building our app on top of, to make sure they’re giving us the data that we need in the format that we need it in. Attending their working sessions with their stakeholders keeps us abreast of what they’re doing. I’ll usually pop into those and just listen for anything that might sound concerning or that might not have been on my radar.
At this point it’s afternoon, like 4:00 pm and I have time to look at my Notes file for the day again to see what I still need to do. Sometimes your calendar’s a brick wall but also you have tickets to write and you have questions to answer. It’s like meetings are work, but there’s also other work. It’s tempting to try to work during some meetings, which isn’t great, but sometimes that needs to happen.
Key Insights
- Engineers, like designers are makers, and managers, including PMs, should be thoughtful and when and how to interrupt their creative flow.
- Product managers engage with their developers in a series of check-in cycles of increasing timescale called “cadences.”
- Day-to-day tactical PM work revolves around sprints that tend to last two to four weeks.
- Working with engineers effectively depends on cultivating mutual respect, both by showing interest and fluency with technical concepts and programmer folkways and by engaging intelligently in clarifying discussions about technical matters while gaining mastery of the technical architecture and landscape.
- A product manager has to learn how to negotiate and collaborate with engineers by being very attentive to their drives, concerns, and patterns of behavior.
—
You can sign up to be notified when Product Management for UX People is available for order at Rosenfeld Media.
