Peter Trudelle

What if all that collaboration is the problem? If you are continually forced to collaborate and align, you are locked in reciprocal interdependence, which isn’t what you want in a multi-team product development environment. In The Friction Project, Robert Sutton and Huggy Rao discuss the difference between reciprocal and pooled interdependence, which made me think about team topology and autonomy, which Marty Cagan often discusses. ➟ 𝐑𝐞𝐜𝐢𝐩𝐫𝐨𝐜𝐚𝐥 𝐈𝐧𝐭𝐞𝐫𝐝𝐞𝐩𝐞𝐧𝐝𝐞𝐧𝐜𝐞 is when people and teams must constantly adjust in response to one another as the work unfolds. It’s very demanding. Think of soccer players during a match. ➟ 𝐏𝐨𝐨𝐥𝐞𝐝 𝐈𝐧𝐭𝐞𝐫𝐝𝐞𝐩𝐞𝐧𝐝𝐞𝐧𝐜𝐞 is when contributors combine or roll up separate and independent efforts to support a whole. There is little need for them to communicate or collaborate. Think of team gymnastics with individual scores and a collective outcome. (obligatory Olympics reference) ➟ 𝐓𝐞𝐚𝐦 𝐀𝐮𝐭𝐨𝐧𝐨𝐦𝐲 is the degree to which a team has sufficient control and freedom to solve a problem as they see fit. Before you come for me, this doesn’t mean that teams shouldn’t collaborate or have dependencies. It means that, where possible, they shouldn’t NEED to continually coordinate to accomplish their goal. Common factors I see that increase reciprocal interdependence: 🚦 Excessive governance – formal approvals across departments and managerial layers at every stage 🛠️ Poor technical architecture – tightly coupled components and subsystems ↔ Horizontally aligned teams – platform and shared-services teams that are focused on control vs enablement Dependencies between teams and organizations reduce autonomy and force reciprocal interdependence. Work toward a team topology and product architecture that fosters pooled interdependence, and the quality of your collaboration will skyrocket. If you need some help teasing apart dependencies, please reach out. #productmanagement #collaboration #architecture

8

2 Comments

In addition to my talk at Write the Docs, I created the sketchnotes, which are posted here: https://lnkd.in/g5Jmej-v

33

3 Comments

Scaling a team is often necessary as demand grows, but it’s essential to ensure it’s done effectively. Before adding headcount, consider if scaling is the best approach—sometimes addressing process inefficiencies or architectural issues can yield better results. If scaling is the answer, keep these factors in mind: * Define clear goals for each team. * Ensure accountability and support. * Minimize dependencies and avoid inefficiencies. * Scaling impacts people, process, and technology. Successful team growth requires careful planning to maintain efficiency and productivity. https://lnkd.in/eTkqykmG

15

4 Comments

We're looking for a senior-staff PM now at Honeycomb, who will drive and own a multi-year vision for a net-new, permanent and significant expansion of Honeycomb's product surface area: https://lnkd.in/g2sM_TfC I’ve sat in this role for 3.5 years now, on and off, so you’ll be inheriting a lot of my regretful decisions. But I’m here to help you navigate that! It involves big data (for real), deep OSS involvement, lots of customers who love the product, and a great team to boot. If you like the idea of thinking through how you’ll turn 10M events per second into 100k, without breaking the bank, and making it as semi-automatic as possible, without losing signal on that data, and building a compelling UI that lets people build and monitor this stuff, this might be up your alley! Wanna talk with tons of customers and spicy sales engineers who have to sometimes commit code crimes to make stuff work, and then tell you about it? Wanna make painful prioritization decisions? Wanna find a way to execute on a multi-year vision and not get lost along the way? Click the link above. Wanna eat shit in front of a customer whose exact set of constraints violates every tradeoff decision you made? And then go back to them 4 months later with the good news that you’ve fixed it all? Come say hi! Wanna try to wrap your head around someone's perceived notions of how observability works, and find creative ways to reorient their worldview? Hi hello please apply. Wanna get deeply involved in the #opentelemetry community, become a core contributor, attend lots of community events, and be continuously infused with customer problems and feedback and also overall industry directions? You know what to do. Wanna work with a very product-minded engineering team who will push you to get stuff done? Wanna be a part of a group that is usually fast, usually right on the first go of things, and isn't afraid to try things and maybe pull them back if they're not working? Wanna have fun too? Clicky clicky.

59

4 Comments

Some takeaways for a Jeff Hinton interview with timeless insights. My POV as an app builder is that models are now being improved for better UX (faster response/multi-modal) and reasoning capability and cost continues to improve. The technology headroom remains strong, and the integration of LLM into all software experience will continue and expansion of the reach (invasion) of software + intelligence will also continue. - Next word prediction is not merely parroting of training data. To do next word prediction well, LLM needs and already exhibits strong reasoning behavior. This would continue to scale / improve with more data / training. - LLM is a compression of human knowledge. The compression mechanism is identifying similar concepts across domains and reduces duplications among them. This can also be a source of "creativity" as LLM "sees" correlations of seemingly unrelated ideas through this compression. LLM can be more creative as it sees similiarity / correlations across all domains beyond (human) convetional wisdom. - LLM can exceed the quality of its training data. Jeff gave an example of an experiment where a model trained on 50% intentionally incorrectly labeled data, can still perform at 90+% accuracy after training. - Multi-modal models can improve the overall world understanding and lead to better overall reasoning. It does not even need to generate multi-modal output. - Not ML specific, but an interesting life insights. Bad intuition comes from believing (or wanting to believe) everything you are told. It diminishes the ability to make a clear choice that would lead to differentiated success (or failure).

4

When folks are looking to pull together scorecards, metrics, or data points for individuals or teams, and *particularly* for technology or software product teams, I often hear: "We can't / shouldn't use that, because it's too easy to game the data." And sure, I'm a fan of uncovering more objective options. That said, I find folks have the impulse to follow immediately with: "So, what data can we use that can't be gamed or is let at risk for being gamed?" Again, good question. But here's the question I find to be more interesting and, dare I say, valuable: "What perceived reward, punishment, or other motivation would drive someone to want to game this data?" Because when we're talking about human performance, it's important to remember the human elements and variables involved. The data you chose may be just fine. It could even be a valuable metric to track. And it could also give you other qualitative data to get curious about what may incentivize or influence gaming of that data. Intentional or not; negatively impactful or not. Conscious or not. Humans don't "game the system" for no reason. That reason could be as simple as the human impulse to do a good job or provide the "right" answers and as complex as navigating real and perceived structural barriers and blockers within your organization. So...let's uncover the possible reason or reasons. The confounding variables. The *human* intentions, influences, and impacts. What would drive someone to want to game your data? (Feel free to ask that in your teams and organizations; also feel free to share some reasons you've observed via discussion in the comments. Let's share some insights and perspectives!) #data #metrics #scorecard #analysis #human #behavior #performance #decisions #motivators #perspectives #insights #DataAnalysis

3

Hot off the press, this latest Silicon Valley Product Group article is a good reminder that there are multiple paths to success, and we have to tailor our strategies to fit our unique circumstances. There’s rarely a single answer or approach when it comes to topics like organizational design— after all, people and companies are complicated and are never the same! To quote Marty: “I believe strongly that with the right people with the right skills, a strong product team can succeed no matter the org design. […] I will never again doubt what a motivated group of empowered and skilled cross-functional professionals can accomplish.” Definitely worth a read if you have ~4 minutes and lead or are part of a product team.

4

I was asked recently by a longtime client about org design, as it pertains to product and technology in software companies. He asked whether product reports into technology or if technology should report into product. I said: neither. The best organizations I've seen have had two parallel verticals: one for product headed by a Chief Product Officer (CPO) or similar, and one for technology headed by a Chief Technology Officer (CTO). There should be a combination of tension and respect between those roles, and there should be very specific areas of ownership. I've seen these two rules work well: 👉 Product can't tell technology *how* to build it. 👉 Technology can't tell product *what* to build. Remember when I mentioned mutual respect? If tech says, "We need time to implement some security stuff," product shouldn't say "Bfft. I'm in charge here. Just keep focusing on those features." Instead, they should talk about it, product should understand the "why," and they should work together to figure out how to appropriately prioritize the work. I realize this may be a pipe dream in some orgs, where it seems like product and tech are at each other's throats all the time - but striving for this state of being will notch up your ability to deliver as a unified organization to drive revenue goals.

26

7 Comments

This is a great video about how our personal ideology impacts the way we process data and information. For me, it shows the importance of fighting against populism and "framing" in the media and teaching our children in critical thinking. https://lnkd.in/eXQdB4fR

2

Santana Row shopping center in San Jose has implemented a ticketless parking system that eliminates the need for drivers to take a ticket upon entry and pay at a pay station upon exit. Instead, drivers can simply scan a QR code (see photo) posted throughout the garage using their phones, enter their license plate number and credit card information on the website that pops up, and a camera will read their license plate and open the gate as they exit. While this system may seem convenient and efficient, I think there is a significant security concern! There is a risk that perpetrators could replace the posted QR code with their own, which would redirect drivers to a fake website where they would unknowingly enter their credit card information. This could lead to unauthorized charges and potential identity theft. It is crucial for the shopping center to address this security concern by taking appropriate measures to protect drivers' personal and financial information. They must ensure that the QR codes posted are authentic and that there are no vulnerabilities that could allow perpetrators to manipulate the system. As an alternative solution, pay stations could be installed for shoppers to use instead of relying on their own phones.

32

12 Comments

Y'alls know accessibility is important to me, and that comes in a lot of forms! I wanted to share out two things I've been working on recently that follow the a11y theme, with Global Accessibility Awareness Day (GAAD) right around the corner: First, plugging the work we've been doing at Ro around building technology to give patients more access to healthcare so they can achieve their health goals via Patient Intake. Intake isn't "just a form" - it's the key way for patients to communicate their health history, goals, and preferences to their providers in a way that feels human. Behind the scenes, we're making sure every piece of information a patient provides is structured to make sure every point is seen and heard so that our providers can deliver the best possible personalized care. More info on the platform here: https://lnkd.in/gC4ru5ip Second, the lovely Elliot Kipling and I caught up on the Enginears podcast last month around healthcare accessibility and digital accessibility in general. The episode dropped today, check it out here: https://lnkd.in/gbGcBvsB

40

2 Comments

Too often teams focus on features rather than outcomes. These are not the same thing. When your starting point is what you're going to build, it's not surprising that you'll build a lot and achieve little. Great teams start from the outcomes. What is the problem or opportunity that we want to go after? How can we quantify what success looks like? What levers can we pull? What is the cheapest way to test whether each lever works or not? When you're intentional about outcomes, it's not surprising that you'll build less and achieve so much more.

60

2 Comments

It's easy to overlook the valuable contributions of silent contributors and introverted team members. Beware of favoring the loudest and most outspoken opinions. The Introverted Edge: 💫 Bring unique perspectives and ideas to the table 🔮 Offer thoughtful approaches to prevent errors and improve code quality 🌈 Foster a more inclusive and diverse team culture Strategies to Empower Them: 💥 Create safe spaces for sharing ideas, free from judgment 📚 Encourage written communication, like comments and documentation 🤝 Pair them with extroverted team members for collaborative problem-solving 🕒 Schedule dedicated time for reflection and feedback 🌐 Leverage virtual collaboration tools to reduce social anxiety Leaders, Take Note: 👏 Recognize and reward their contributions publicly 🚀 Provide opportunities for growth and professional development 💕 Foster an environment where everyone feels heard The Benefits of Empowerment: ✨ Unlock hidden talent 🤝 Build more effective teams ⚡️ Drive innovation and success 🚀 Drive innovation and success Introverts, what's one thing you wish your team leaders knew?

9

4 Comments

Another example of how Knapsack helps teams go from design to code quickly and efficiently to deliver real value to the product teams that use your design system. So many folks are focused on documentation being the way to connect design and code (and docs do matter), but having a structured, codified, version controlled way to specifically define how you connect Figma to a coded component is really what helps us deliver value to product teams that use the design system.

6

The best use case for overseas development I've heard: We have customers in the eastern hemisphere. To support those customers better, we're standing up product, dev, and support teams to help serve those customers needs. Two key ingredients in making that successful: commensurate pay and the same level of performance and accountability as US peers. #software #international #teammanagement #overseasdevelopment #startup #leadership #coaching

6

I really enjoyed working with our team to put together The Pragmatic Guide to Composability, and I really appreciate the Forward by Brian Walker! We can all sometimes be guilty of using too much terminology and jargon. At the end of the day * every * enterprise brand is trying to achieve greater composability - making sure that all of their digital investments work together to serve their business and their customers. In this report we cover how composability isn't a new concept or a passing fad, we bust some myths that may hold brands back from building a strategy for greater composability, and we recommend starting points for brands that are setting out on the first steps toward composable commerce.

5

tldr: I'm hiring! As many of you know, I recently joined Lattice as their SVP of Engineering and I'm excited to announce that I'm hiring for all Engineering levels and more broadly, Lattice has open roles across EPD. If you're wondering, why Lattice? The last few years have seen a step change in how we think about the meaning of work and the employer <> employee relationship - add on the fuel of AI taking our jobs and you could be forgiven for thinking the future of work looks bleak for employees. It doesn't need to be that way - here at Lattice we're building the next generation of talent tools to give employers insights and employees purpose because people matter at work. Among other things, we're using generative AI to securely analyze enormous volumes of data to unlock career insights faster and investing in building equitable feedback, compensation and employer analytics tools - not just for one company but for all companies. If you're interested in making a difference to the future of work then let's chat - all roles are remote eligible and based in the US. We have physical offices in San Francisco and NYC if you prefer the in-office environment.

324

48 Comments

I lead an informal 15 minute pre-standup meeting with my team (which we call Coffee-n-tix). It's a great tool for being an effective leader and for bringing psychological safety to my team. Engineers hate meetings, especially ones that _seem_ redundant, but below is why I keep it to this day. Reason 1: Recognition and reward > The normal standup is usually time-constrained. They're scheduled back-to-back across teams, so people usually have to be succinct to wrap up on time. > But on the pre-standup time, we can take our time to thank people for something they did. > We can go into details. We can be specific. We can share exactly what was done, how, and why it's appreciated. > This is a great mechanism for building team morale, preventing burnout, and rewarding laudable behavior. Reason 2: Preparing for the day > The standup meeting is all about what you're working on and your current blockers. It usually doesn't allow a lot of time to be strategic about how to use your time. > In the pre-standup meeting, we look at capacity and demand. We try to anticipate issues, and develop contingency plans for what to do when those issues come up. For example, we might decide that we need a person to not be overloaded with work because they need to be ready to provide production support, or we might decide that a brainstorming or pair programming session is needed. > This lets us be prepared ahead of time, instead of getting caught with our pants down. Reason 3: Tracking metrics. > During our pre-standup meeting, we look at our current metrics (usually just staring at the Jira board). > This is a great time to have honest, frank conversations about tickets that are taking too long, were not properly thought through, or have challenges that we didn't anticipate. > Then when we join the normal standup meeting, we can present a united front to the wider audience and we have a plan to tackle whatever the issue might be. Reason 4: Problem solving. > There isn't a single day where we don't confront problems or challenges. > And surprisingly, most times the problems are incredibly dumb like someone doesn't know how to deploy or test a change. > The pre-standup meeting gives us time to talk about those issues directly and resolve them. We can choose to just talk about them, do a quick diagramming session, or maybe even do a Code with me session. > Then when we join the standup meeting, we can go over those problems super briefly but also explain how we are already a step ahead and we have a solution in mind. > Or, if we have a big, scary problem that we can't figure out before standup, we've already ruled out all the easy stuff and we can focus the energies of the larger audience on resolving this issue, thereby saving everybody time. #engineeringmanagement #softwareengineering

13

3 Comments