Product Management for Software Engineers (part two)
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.
No comments:
Post a Comment