Your team is the product

Product Management for Software Engineers (part three)

Photo by Anna Samoylova on Unsplash

The second most common question I get asked after “How do product and engineering work together?” is “How do we balance building features versus working on our tech stack?”. I’ve seen many permutations of this going wrong. If you don’t build features that bring value to your users and employer then you don’t tend to survive long as a team. If you accrue technical debt in the name of delivering features (or hitting deadlines) then eventually you are unable to deliver new features because you’re swimming through treacle. Then you don’t survive long as a team. Obviously, neither extreme is desirable and you have to find a sweet spot somewhere in the middle.

The bad news is this is different for every team and varies depending on the point in time you’re at. It also offers something of a false choice between product and engineering which pits the two disciplines against each other in ways which can become unhealthy. The purpose of this article is to give you another way of thinking about this balancing act which enables you to get the best out of each other and also become more capable as a team.

The premise is simple — what if your team was a product? What would be the key characteristics of the team? Ideally you’d look at something similar to the metrics so eloquently defined in Accelerate. I’m going to take three of the metrics:

• Time to push a change through to production (lead time). How quickly can you deliver a new feature or change to be visible to your users. This represents the limit of the velocity your team can deliver at.
• Time to fix a problem in production (MTTR — mean time to resolve). When things go wrong — how quickly do you detect it and how quickly can you resolve it? MTTR tells you how good your monitoring is and also how quickly you can run something through your build and deploy pipeline.
• Percentage of breaking changes. How reliable is your build and deploy pipeline? How good are your tests? How much faith do you have in any change you make to your product?

I’ve left number of deploys a day because, while this is interesting, it is heavily dependent on what you’re working on and a combination of lead time and MTTR tell you how quickly you can push something to production. It’s also something that can be gamed. You should aspire to be able to deploy on demand.

Ultimately, whether a team is effective is whether it solves real problems at a pace which is comparable to (though ideally better) than your competitors. If you’re not consciously investing in this capability then you’re going to be offering people the false choice of features vs tech and missing out on the things which will allow you to compete.

How do you get to this magical place? It’s not as hard as you think. The bad news is there is no button you hit and suddenly you’re doing everything right. I remember I had one team that had just inherited a codebase that was quite tangled with a number of other products. It took us 5 weeks to make a change to a button. This was terrifying at the time but it led to the conversation which allowed us to move towards the team we wanted to be. It started with two questions:

1. What are the things that are slowing us down? You should revisit this often (maybe even weekly) to understand the things which make it difficult to make progress. No software engineering team ever said “it’s too easy to get things done here”. It might be that you need approval or feedback from another team (hint: don’t wait until the day before you want to launch to engage with them). It might be your build and tests take a day to run (this also happened to me). Understand where your friction is and either accept it or plan to remove it.
2. How quickly should we have been able to push out a trivial change? If you’re struggling then the best way to learn how to go faster is via doing simple things. Because, let’s face it, you won’t be able to take on complex work anyway. Get good at the simple things — they afford you the ability to run through more iterations in a shorter space of time. Every iteration is an opportunity to learn how to go faster.

Wind forward 12 months and that team was unrecognisable. Engagement was up, more features were being shipped, more value was being delivered. If you’re prepared to invest in this accept it’s something to commit to for the long haul because it’s a culture change not a band aid. But the culture change leads to everyone getting what they want — the product manager gets features, users get a rapidly improving stable product and engineers get to take pride in building things well.

I had another team that was running at close to 90% toil. Yet they were never given the space to step back and fix it. This meant unhappy product managers and unhappy engineers and unhappy business. They took 6 months to clear out their toil. In the process they fixed lots of things in the product anyway and learned how to put the foundations in place to deliver features more quickly. When they started picking up features again people were astonished at how much they could get done.

Those are just a couple of examples. If you aspire to be part of a great team either as a product manager or an engineer then you have to think of the capability of the team to get things done. Treat your team as a product you’re developing because — if you’re not investing in going faster then you’ll end up going slower.

See also:
Part One: We’re all product managers
Part Two: The many roles of engineering teams

The Many Roles within Engineering Teams

Product Management for Software Engineers (part two)

Photo by Mario Purisic on Unsplash

Part two of my series of product management for software engineers deals with one of the biggest problems that any product manager (or engineering manager) has to deal with. The sheer number of possible roles within a team. Being able to effectively build a product involves knowing how to get the best of the people around you — whether it be by leaning on the skills they have (that you don’t) or understanding how they are motivated.

To give you a taster of how complex this can be — I had a try and writing down all the roles I could think of off the top of my head: software engineer, backend engineer, systems engineer, systems reliability engineer, UX designer, program manager, data scientist, business analyst, frontend engineer, build/deployment engineer, security engineer…. Then I gave up. This is before you get onto the business specific roles such as marketing, sales or business operations you also need to have a conversation with. The meaning of these roles can change from organisation to organisation and each brings a set of capabilities which can make or break your project. Each of them also brings a set of personal needs and ambitions from people performing those roles.

As a product manager part your job is to understand enough about how they work to get the best out of these people. To ensure the best of their ideas is incorporated into the whole of what the team is doing. To ignore one is to risk disaster. For example — you’ve built your system and paid no attention to how it’s going to run in production. Finding out you need to invest in running systems in production is not something you want to discover at the point you’re trying to deploy for the first time or after Twitter has informed you your product isn’t responding. Likewise, you want to care about the privacy and security of your product before you get hit with a privacy complaint.

However, before you get that far there is one relationship you have to get right. This is the single most important relationship in any engineering team. The relationship between engineering lead and product manager. If you aren’t aligned with each other then your team will be in a constant state of confusion. You will waste untold amounts of time undoing each other’s work and redoing your own. The team will gravitate to whichever of you they think will give them the answer they want at any given moment. Andy, if you’re not heading in the same direction from a product (and technical) perspective the team will fail. It’s that simple.

Having a healthy relationship with your product (or engineering) peer means the following:

• You agree on the problem you’re trying to solve. This is the heart of empowering the whole team to seek creative solutions. More importantly, it ensures that you’re not pulling in opposite directions and that success means the same to everyone. If you can’t agree on the problem or success you will have an unhappy relationship.
• You understand what success looks like to each other from a career perspective. Everybody wins. If only one of you has a path which leads to promotion then there is no incentive for cooperation. It’s no fun working hard for someone else’s gain if you have no path forward yourself. Talk about what you need with each other and then invest time in supporting it.
• You understand what the team needs from both of you. Your job is not to tell them what to do — it’s to facilitate them in building software to solve problems. This might involve a broad spectrum of activities including decision making. But, there will be people in the team which more expert skills or knowledge than each of you in different areas — your job is to give them space to demonstrate that. Team success needs to align with individual success for everyone in the team.
• You are able to represent each other when someone is absent. It’s highly probable (and desirable) that you take vacations. During this period it should be business as usual because each of you is capable of being the focal point of the team.
• When you disagree you have agreed mechanisms to get past it quickly (and without bad feelings). Neither of you has the monopoly on decision making or ideas. You seek to resolve your differences in private beforehand. The product manager should have an opinion about the tech and the engineer(s) should have an opinion about the product. Having clear success outcomes frees everyone in the team up to think about how to get there.

I have a simple way of getting product managers and engineering leads to align. That’s by telling them I won’t get involved until they’ve attempted to resolve their misalignment. And that I will only do so if they bring their differences to me. Or to put it simply — “we don’t start anything until you two agree” has proven effective in help product managers and engineering managers realise they’re in the same boat and can either paddle together or spin around in circles. My playbook for disagree and commit is a good starter for when there isn’t agreement. There have also been times where I’ve had to separate product and engineering leads because they simply can’t see eye to eye. If that relationship is broken the team is broken.

Now, you have a working partnership with your counterpart — what of the other roles I mentioned at the start of the article? I will attempt to give a very quick run through of them. The exact role names, descriptions and details is likely to vary from place to place so I’ll also give an idea of what skillset they bring to the team.

• Software Engineer — generalist developer. Though typically specialising in a particular area and with working knowledge of other areas. There is a myth of the Full Stack Software Engineer as an engineer who is competent everywhere. I have yet to encounter this — the best you can hope for is someone who is adaptable, is more interested in solving user problems than choice of tech stack and willing to choose the right tool for the job. It’s (relatively) easy to hire competent software engineers and they will make up the bulk of your engineering teams. They may wind up going on to other specialisations within engineering depending on what interests them.
• Frontend Engineer — developer with an interest in building user interfaces. These are surprisingly rare. Someone who is a credible software engineer and has an appreciation of visual components (and the patience to make something truly slick). Partner these with UX Engineers to make your user experience delightful. Remember that tweaking UI can take more time that you think relative to building backend systems.
• Mobile Engineer — developer with interest in building on mobile devices. These engineers tend to specialise in one of Android or iOS (don’t make the mistake of trying to hire people expert in both). If you are building an app then you’ll need to invest in people able to build that and you want specialists.
• Backend Engineer — developer with interest in building distributed systems. These are the engineers who build the systems to access data around your business and make it reliably available to your users. The larger your scale to more important these become. When you’re processing millions of requests a second then having the people to do the plumbing to make this happen is critical because systems don’t scale without deliberate effort.
• Data Engineer — engineer who is interested in data. This is different from data scientist though may overlap. Predominantly this is someone who is good with data structure, with bringing data from lots of places and making it reliably available and who is able to ensure the quality of that data. This role is also very rare and often winds up being done by data scientists to the detriment of their analysis. Finding good data engineers is hard but any team doing meaningful machine learning will have them.
• Data Scientist — mathematician who is interested in answering questions with data. Data scientists are very easy to misuse (for example making them build dashboards or trying to get them to unambiguously answer complex questions quickly). They need an environment where they have access to the data they need in the quality they need and where they can experiment and then productionise those experiments. You need to pair them with Data Engineers and Backend Engineers or they will wind up trying to do these jobs and, most likely, struggle.
• Program Manager — someone organised and proactive. Program Managers run complicated projects with lots of moving parts and involved teams. You need these people to be the glue so that anything outside of one or two teams has someone working on coordinating the work. Engineers hate doing this and product managers are not reliably good at doing this role. I’ve been lucky enough to work with some truly exceptional program managers and what they do is magical.
• UX Designer — someone who loves making beautiful things. Engineers do not, on the whole, have an appreciation of user interfaces. In fact a user interface built by a software engineer tends to look a lot like an aircraft cockpit. You need someone whose full time job is making your product simple and obvious. The hard part is finding someone that is able to work with their Frontend and Software Engineers and striking the balance between what is possible and what is perfect. Good UX Designers are also rare and a common anti-pattern is you get a room full of them making pretty pictures that never see the light of day in products. You want your UX Designers embedded in your teams.
• Business Analyst — someone who knows how your business runs. This is like a data scientist but for answering questions like “how much money are we making?”. This is the role which should be building the dashboards for your business metrics and ensuring that you can reliably compute revenue and bill for what you’re doing. Pair them with backend engineers and data engineers to ensure they have the support they need.
• Build/Deployment Engineer — someone who makes sure you can reliably build and deploy your software. Slow or unreliable builds are a significant drag factor on engineering teams. Being unable to push to production to fix a problem is a risk you don’t want to run with. Investing in automating this whether by building tooling for software engineers to utilise or within the team to make these processes run well pays back many times over in allowing people to focus.
• Systems Engineer — the people operating the production systems. You’re running a kubernetes cluster? Well you need systems engineers to make sure the cluster runs reliably. These are the people operating and maintaining the pieces that everything else runs on. Might be considered a DevOps role with alone or in combination with Systems Reliability Engineer.
• Systems Reliability Engineer — people who can run complex systems at scale. Depending on whether you subscribe to “you build it you run it” or whether that’s applicable for all systems. Having people who are able to run, monitor and support systems at scale is critical once you reach a certain size because, at a certain point, all your systems become too complicated for product engineering teams to focus on. Systems Reliability Engineers (or SREs) are comfortable managing this complexity for you. They should be in a separate organisation so they have the ability to resist pressure to look after things which aren’t ready for production.
• Network Engineer — people who make sure those pesky data packets get to you from users. Once you hit a certain size you’ll be operating in multiple places (or regions). Making sure users are able to connect cheaply to your products and route around problems is critical to having an available and performant product. Typically these engineers will be in their own organisation rather than working day to day with teams. But teams need to talk to them to understand how that routing of requests happens so they can build effective systems.
• Security Engineer — engineers who understand privacy and software vulnerabilities. This is a role of growing importance in the industry. Having a person or group of people who are seeking to understand weaknesses in your system to protect your users and business means you’re less likely to be on the front of TechCrunch for a data breach. This is a group of people that are actively looking for vulnerabilities but also have an appreciation of the legal and ethical requirements for user privacy.

Given the average size of team and wide variety of what you’re working on — it’s unlikely that you’ll have specialists in all of those roles within your teams. It should also be obvious that no one person can cover all of these roles. So, as a product manager you have a problem — you will not be expert in these and the people doing these roles need a say in how they do them. As such, the best product managers seek to learn enough to communicate effectively and then step back to facilitate the people doing this. The same should also go for software engineers. The variety of disciplines means we have what feels like a bewildering array of tools at our disposal. Learning to support other disciplines and roles is critical to building high quality software and products.

See also:
Part One: We’re All Product Managers… But what are we building?

We’re all product managers… but what are we building?

Product Management for software engineers (part one)

Photo by Alexander Andrews on Unsplash

I will admit to have dabbled in product — I even quite enjoy it. The more senior I became as an engineer and then engineering manager the more it mattered that I knew (and had a voice) in what we were building. I also realised along the way that good product managers are a rarity. A good product manager is the catalyst that makes teams great. An ok product manager gets things done and, depending on how well they work with the team, keeps everyone pointed in the same direction. A poor product manager is an anchor dragging the team’s productivity into the depths. I’ve also spent a fair amount of time debugging the relationships between product managers and engineering teams because this is one of the most common dysfunctions I have come across.

By the end of this article I’ll give you a simple framework that can give anyone within the team the head start to understand what you’re building. And also a valuable tool for understanding whether people are aligned with each other. If you’re coming into a new team and want to understand why people are pulling in different directions it can help you get going.

So, product friends, look away now. The rough proportions of good, ok and poor is probably 5%, 25% and 70%. The reason for that is that nobody really knows what a product manager is. One of the most common questions I’ve been asked in my career is “what’s the role of a product manager?” because it can vary wildly from person to person and team to team. I’ve seen product managers so technical that engineers and data scientists come to them to learn. I’ve also seen product managers who believe they are the custodians of all decisions in the team. One even described their role as being the “officer class” of the team (I wish this was a joke).

One thing that’s true in every team is you to be able to do a number of things:

1. Clearly articulate what problem you are trying to solve. A former colleague at Google had what he called the one-slide test (or you may have heard of this as the elevator pitch). If you cannot crisply describe why you’re here in a short space of time or few words then it’s likely that you don’t really know yourself. (I once asked a room of engineering managers this question and watched them freeze up in horror at their inability to answer it — hint if you can’t answer this as a manager you’re going to have a bad time).
2. Understand the value of what you’re doing. If you cannot ascribe a value to work being done it’s impossible to prioritise. It’s also demotivating working on something because of a hunch. Teams don’t stick around long if they’re not bringing value.
3. Work with users or stakeholders to understand their needs. You’re building things for users to solve their problems. You also need to solve their problems in a way which brings value to your own company. This balancing act is at the heart of all good software engineering. You also need people to understand how to engage with the team. A product manager frequently fulfils this function alone which is another anti-pattern.
4. Communicate progress to your business. This includes sharing misses or when things have gone astray as well as progress towards goals.
5. Decide on the relative priority of tasks. Now this is where things tend to go wrong. There’s a balancing act between code health and infrastructure and product features. If you only build product features then you are likely to be a factory for the creation of tech debt. This is great for the product manager and their career but un-great for the team. Likewise if you’re only doing cool technical things without solving user problems then there’s also a problem. Understanding how to resolve disagreements (because you will have them) is how you maintain forward progress and harmony. If you don’t agree how you’re going to do this then, again, you’re going to have a bad time.
6. Understand what other features are being built around your company. A company of any moderate size will be working of lots of things at once. You want a joined up product rather than falling victim to Conway’s Law and shipping your org chart.

Now we have a simplistic view of the responsibilities let’s also talk about team resilience. If these responsibilities sit entirely with one person then what happens when that person goes on holiday, gets sick or moves team? At the very least you need to have a number of people able to represent this role. It enables the product manager to scale and think further into the future. It provides redundancy and, most importantly, it gets engineers thinking about the product they are trying to build. To empathise with users and to understand how decisions are made about what the team is working on. It also results in engineers speaking the same language as product which means they are better able to say what they need from each other.

I’ll also say — the very best engineers have a good appreciation of product. They are able to relate what they’re building to the technology they are building it on and make the trade offs required. If you want to progress your career as a software engineer you need to start learning complementary crafts. Product is one of these.

Which leads me to my simple (and some might say childlike framework). It consists of three questions you ask to everyone in the team and also their stakeholders. By comparing the answers to these questions you can quickly get an appreciation of:

• Whether people are aligned on what they’re working on
• Whether people know the value of what they’re doing (and are therefore able to prioritise work)
• Whether people know who they are building for
• Whether people know who they are (or should be) working with

I ask these three questions whenever I join a new team or organisation. The answers have always been illuminating (and it’s been a cheap way of showing I’m bringing some form of value without treading on anyone’s toes). Not to mention allowing me to know where there are likely to be fault-lines between people and teams.

With all that in mind. Here are the questions.

1. What problem(s) are you trying to solve? (and who for?)
   If people think they are solving different problems then they’ll be working towards their view of what needs to happen. They’ll be constantly surprised people are not aligned to this. If people don’t know who those problems matter to (either user or stakeholder) they will have no way to empathise with the problems/needs of those people. A rambling answer to this question is a strong indicator that someone doesn’t know the problem. I’ve seen 80 page strategy docs for a 3 month project.
2. How will you know you’ve succeeded? (how do you measure success?)
   If you don’t have objective measures to determine success (or progress) then decision making comes down to opinion. Which is an invitation to all manner of unhealthy behaviour including decision making by job title. Even if people can’t agree on how to solve the problems, understanding outcomes means people are empowered to think creatively towards these and have a mechanism for demonstrating they have solved them. If you’re basing the success of your product or feature on something you have no way of measuring then you’re going to have a bad time. Either change the measure or invest the time in measuring properly — with the caveat that counting things is always harder than you think it’s going to be. This is not an excuse to go and beat up data scientists (appreciate their craft too).
3. Who do you need to work with to solve this problem?
   If you don’t know you’re running the risk of being surprised when your feature is mutually exclusive to another team’s (cue internal politics). More importantly there may be someone out there who can accelerate what you’re trying to build. Teams which only look inwards miss both of these things.

And, that’s it. Ask yourself these three questions. Ask the people around you these three questions. Now you have a sense of whether you’re working on the right things or even together towards common goals. Also, congratulations — you’re now a product manager (maybe not a good or even ok one yet but you’re on your way). Because, if we want to build great products we all need to think like a product manager.