Building products in a complex system
Lessons in managing expectations, technical debt and hiring from the last quarter.
Imagine that it’s the first working day of the quarter. You’re feeling positive and optimistic about what’s to come. But really, you don’t know exactly what’s about to come, with so many unknowns…
As a team you know why you’re here, you’ve got a broad idea of what you’re going to focus on and how you’re going to do it for the next 3 months. You appreciate the fact that at any moment something or someone could come and disrupt all of that, and being able to work in that environment is fun, right, but can be stressful. This is challenging and can be tough for people, so we need to be kind to one another.
As we approach the end of this quarter, I’m taking stock of where we are and where we’re headed, hopefully sharing some the ideas for you to resonate with or try yourself. In product we talk a lot about being able to ‘get shit done’, and we’ll do ‘whatever it takes’, to me, that means better planning, motivating and being there for people, and the ability to slow down, to speed up.
It’s been one year of being a joint company, one year of being operational on the Google Cloud platform, and possibly the most memorable quarter we’ve had for many reasons; good, bad and ugly.
These last three months have been an emotional rollercoaster. It’s been incredible in many ways, as well as uncertain and tough. Building products is like that, but in a complex system, it’s amplified. This happens in startups too, so the experiences and skills are transferable, but different problems. I really like a recent thread by McKenna Moreau…
If it was easy, everybody would do it
One of our products exists to offer the right products for the right price. Simple hey? Think again. Part of this company’s legacy is as a cable provider born out of acquiring other companies, with millions of customers on various products, equipment, and other sorts of nuances. We started our journey in the customer space, so simplifying all that into one place has been [inserts emotions here].
We’re simplifying a super complex area, with a bunch of systems and logic that ‘does this because it’s how we’ve always done it’ or because ‘it’s too expensive to do that’ or it takes ‘over a year’. This work is transforming the speed at which we can do things, and soon will be used everywhere to serve our products and prices.
In previous quarters we’d done our discovery, and partial planning for some big features to come this quarter, and it felt hard. Like finding a solution was a needle in a haystack at times, and constant back and forth, but we got there with the support of teams that are domain experts in this space.
Lesson: Make friends and listen to domain experts. They really want to help (most do!), and they often have ideas for how better could look. Work with them; listen & learn. Take that into your world.
Once we started building, things started to bring back all the feels, being much harder, because:
A.) things turned out to be more complicated and “if we knew then what we knew now” we’d be laughing, not crying.
Lesson: Plan for the worst, run a pre-mortem before starting and try to figure out how you’ll approach those things that could block you.
B.) we had a light team as we were in hiring mode to scale up our engineering function, and oh my, did anyone know a quarter with so many bank holidays than Q2 2022 in the UK?
Lesson: Before the quarter starts, make sure you’ve mapped the downtime for bank holidays, annual leave, workshops etc. This blocks the flow of the team with the start stop, it’s hard to get back into context again. Also hiring is tough, be prepared with finding, interviewing and then starting to wait 2–4 months… and factor it into your plans.
C.) we desperately had to focus on some tech debt to ensure performance was retained, as well as unlocking a simpler code base, easier to work on by many, and to unlock new use cases for value, at speed.
Lesson: We had a smaller than planned team at the time. A smart bunch having to favour speed over loving the code due to constraints and needing to deliver value. Plan ahead where you can, make this part of your work. Be prepared to make tough calls, and expose trade offs early on to those that rely on you. This is a tough one. I explore it some more a little later.
People are your biggest asset; time is key
There’s various things to consider here, from hiring to scale the team, to getting them feeling comfortable and able to add to the teams productivity.
Time to find; hiring is tough. It can take months to find the right person, and it shouldn’t be rushed.
Lesson: creating a pipeline for people is key — you can meet them through communities (in Slack, meet-ups etc.). Don’t think that hiring is about putting a job description out there and hoping to get the right person. Hiring takes time, effort, relationships and networking. My team has grown through some luck of going external, along with knowing people and them wanting to join us on this mission.
Time to join; there’s nothing worse than knowing you need people, pressure to go faster, knowing that people are coming but not yet.
Lesson: make sure your delivery function is helping you communicate and plan for the reduction in productivity, and make sure you’re managing expectations. You can’t just ‘throw more people’ at a problem. A common theme when you’re in this place of needing more people to go faster, is to throw some contractors into the mix. But this hurts a teams flow. Sure, contractors can help accelerate to a degree, but they suck up time from the team to learn some stuff to then soon after leave with a bunch of knowledge.
Time to get up to speed; how soon can someone be comfortable and increasing productivity? How long is a piece of string.
Lesson: When new people come, they need access to systems on day dot and time to understand their new context. They need to pair with others. They need strong documentation. Flow slows when new people join. Educate your stakeholders on this early on, otherwise they’ll think as soon as you add those people that you’ll be rolling like a river, and you won’t, you’ll be moving like a sloth for a bit. Slowing down to speed up! Lean on delivery friends and your managing expectation skills.
Ain’t nothin’ going on but tech debt
Technical debt shouldn’t be seen as a negative thing. Love your code, or it won’t love you. I mentioned earlier in this post that it’s a result of smart people going for speed as number one priority for various reasons. This tweet came up on my timeline at the exact moment I was thinking about this and needed to see it — thanks Jules Glegg.
Tech debt has a bad name for itself, yet in most cases, it was a team with all the will in the world trying to get somewhere fast to create value. Talking of debt, the other day I saw someone coin HumanDebt as thing — I feel like it’s a thing.
Lesson: Again, an education piece. Make your stakeholders aware, loud and clear that this is as important as the stuff that directly gets marked with value. Without making this part of your daily work you’ll make things worse further down the road. This is a harder thing to get a non-tech person to buy into, but it shouldn’t be. Another, you’ll need to slow down to speed up.
I hope that resonated and you found similarities in your experiences, or even better, it gave you some stuff to think deeply about and try.
Reflecting feels good
To start Q3 and the future, as I mean to go on, here are some of the positive reflections…
In Advanced Analytics & Data Science we promoted people and we hired new people, coming from inside and out. Specifically in my function, we welcomed two new Product Managers, one from within, the other from outside. And we promoted one of our grads to an Associate Data Product Manager. The first Associate role in our function 👩🎓
We iterated across our portfolio of products so many times, many times. Mostly in our gift, so the flow of the work is a joy! Build > measure > learn is truly in full flow 🔄
We shipped a bunch of new products into production for people to love and use! People love what we’ve done, they’re using them or want to use them. Wanting to use them is where the fun starts and sometimes challenges come, as some stuff competes with legacy. Yet we’ve built trusted relationships, to get our friends across the company to work with us and get these into the wild together shake 🤝
Celebrate good times come on. One of the most important things in my mind as a leader is your people, and recognising all the things. Celebrate the people and the things. No matter what headwinds are around, to taking a moment to reflect and recognise people is important. We didn’t just celebrate work, we celebrated birthdays, house moves, and to mix it up a bit some of us slowed down to make dim sum 🥟
Effectively using the right tools for the job, and not making slides for the sake of slides. Like sure, we make them to demonstrate our team, the work etc. But our core stack in product is Lucid + Slack + JIRA + Confluence + Trello + Teams when we have to 😉
Partnered with more people around the company to surface more bets. Having 8 Product Managers on the team now, there’s a ton happening and continuous discovery. From listening to calls, to going out with technicians to customer homes, to looking at the data and having conversions. To capture our work in one place, we’ve setup data product pipeline to house all the stuff in a simple Kanban board. A lane for bets we are validating. A lane for the things we’re building off the back of validating then as problems worth solving 🎰
We’ve been crowned winners of two awards from Google including Cloud DevOps. So whilst it can feel hard, we’re moving the needle for the company and we’re being recognised by leaders in the industry 🏆
Shared our gems at DevOps Enterprise Summit — a conference hosted by an author crush Gene Kim. What a wonderful community of people! 💎
Started to grow a Data Business Analyst craft in our Data Product Management function 🌱
…there’s plenty more, so if this sounds like a team you want to join, keep a look out for roles and speak to me or our recruiter Paul Sharp — from data science, to ML engineering, analysts to product management.