Sam Gimbel

Tech, Beer, and Strange Thoughts.


Developer Growth

A friend of mine is an engineering manager with direct reports interested in pursuing product management. I'm reposting the Q&A he and I had on the subject. Hopefully it's useful!

What would you recommend to a junior developer as far skills to hone if she wants to eventually transition into product?

Developers who want to transition into product need to find a way to step out of the role of implementor and view the product holistically, from the perspective of the customer and the business. Product Management is half product and half management. This is the product angle. Rather than seeing the problem you’re actively solving as priority 1, a PM-neé-dev needs to see how solving this problem will contribute to delivering value for the business.

For instance: You have a referral program to build for an ecommerce site that’s having trouble with acquisition. A dev’s job is to build the best referral program based on the constraints given, and to negotiate with product/design until the code can represent that "best.” A dev trying to be a product manager should seek to understand the relative impact that referrals have on the business and negotiate instead to spend an amount of time/budget proportional to the expected value being provided by shipping that feature.

As for things to read/do, practice is key. Product managers come in flavors (UX, Data-Driven, Technical, etc.) and it takes a chunk of time to uncover how you’ll best support a team of engineers and designers. The Dev-to-PM transition is tricky in that devs who are new to the PM world tend to pigeonhole themselves as “technical product managers” by mistake. To avoid this, try working on a side-project or getting a junior PM generalist role before determining your "flavor." Keep in mind that these flavors are equally useful for new PMs and hiring managers alike, in much the same way that “full-stack” describes a dev's trajectory to recruiters without providing a very detailed description of who that person is.

On the flip side, what do you as a PM expect from your interactions with a 2nd-year developer, and what makes a Jr developer great to work with?

PMs don’t directly manage engineers, but we do seek to develop talent wherever we see it. In that sense I expect junior devs to have opinions about what they consider to be good and bad development decisions, but to set aside those opinions when suggestions are made by experienced product managers or engineering managers. In general I expect my junior devs to put their ego second to their need and desire to learn and grow, and I typically see that transition from junior to mid-level when scoping/product discussions become rooted in the dev’s experience solving similar problems rather than on theoretical knowledge of the space.

The other thing I expect from junior devs that I don’t expect from more experienced developers is rapid and noticeable growth. While your own growth may stay internally linear, to the outside world it’s asymptotic after a certain point. As a manager I expect to see self-driven growth that is noticeable over 3-6 months. After a year of working with a junior person I expect them to be able to evaluate themselves with enough self-awareness to know where they stand and where they’re headed. The junior devs i see at the 1-year mark who can make this honest self-evaluation are usually ready to be considered mid-level somewhere in year 2, all else being equal (and it never is).

As the product owner, what parts of the process do you think have opportunities for ownership by the dev team beyond implementation?

The adage is that Product owns the “why” and the “what” and engineering owns the “how.” In Agile with an embedded product owner this works quite well, as engineering is expected to determine the course of implementation as well as the implementation itself. In less agile environments I expect a lot more dev involvement in the planning or prototyping stages in order to reduce the risk of building for production. Typically this includes feasibility sessions, estimation sessions, and dev/design-driven prototypes. We do prototypes to lower feature ambiguity, so the product mandate for these early versions will be less structured than that for a production feature. This is a perfect opportunity to get engineering and design involved in the early creative process and run with a feature with the understanding that their work may get thrown out entirely.

Giving dev teams a lot of leeway up front uncovers a ton of interesting possibilities and constraints and builds social capital for "laying down the hammer" when making compromises about taking on technical debt or cutting scope. In general, good managers should earn the trust of their teammates by allowing for group autonomy whenever appropriate. It’s the easiest way to get your teams to grow and to root out personnel problems early.

In general, what marks a solid product/dev relationship as far as creating the best conditions for personal/career development for all involved?

This plays into the paradox that is product management: we manage the product outcomes, not the people involved, so the most “control” we can ever have over teams comes from dictating the relative priorities of features in the pipeline. Good product PEOPLE generally get shit built on time, but not all product people are good MANAGERS. Developing teams over time requires good management acumen which requires a high level of trust, team cohesion, and patience. I personally do not try to grow teams that can’t figure their own internal shit out. The first thing a dev team needs in order to grow is an agreement that they want to grow at all. Divas, brogrammers, whatever you call them, there is a brand of developer that tends to impede team growth by taking the best assignments, working in a vacuum, or failing to communicate. The best thing a motivated developer can do is avoid these types, get on a good team, and seek out product mentorship if their team is underperforming. I expect developers to advocate for their own growth, not their own fame/fortune. That means offering to take shit assignments they know will teach them something new and presenting learnings to whoever is interested when something exciting is uncovered. I also expect devs to recognize success and failure as two equally possible outcomes. You can't win them all.

Good product MANAGERS will find ways to facilitate team growth based on the strengths and needs of individuals on their teams. Taking the self-advocacy of individuals to heart is step one, followed by long-term efforts to get that individual involved on assignments that play to their stated direction. Good product managers shield their developers from bullshit while allowing them to flourish doing work that allows them to grow. Nothing a PM does can substitute for experience, and nothing a PM does can help an individual grow if the individual is not honest with herself about what she wants or does not communicate this to the product manager. To that end I find the best PM/Dev relationships to be based on mutual interest, trust, and lots of off-topic conversation. It’s very hard to facilitate the growth of a one-dimensional being, so getting to know your teams is crucial.

The ideal end-game for this relationship is one where a spec is not needed to begin work. A team can hear the product vision and recognize immediately where to get started. This is ideal for Product as we can step out of the process/project-management role and spend our time determining the right features to build. On the flip-side, this engineering team should be able to succinctly state their concerns about a given path and have the PM recognize why this is so. That relationship describes a high-trust environment and cuts out swaths of negotiation and ambiguity common to less gelled teams.

Finally, engineers should expect good PMs to bring new work to the right team in the first place by merit of knowing the individuals on the team and their strenths and direction of growth. New PMs typically pitch product initiatives to rooms of close-mouthed, confused developers who are all wondering why the hell they, of all the engineers in the org, are being tasked with this assignment. Experienced PMs spend product inception meetings ironing out the final steps in getting features prioritized because the team in the room has been aware of the product's importance for some time and is already thinking about how to solve that specific problem.

It's hard to stress enough that the proper relationship between PMs and devs is a two-way street of communication and trust. Product managers don't write code or HTML, but if you're lucky enough to have a good one on your team they can make the work-lives of individual teammates richer and more rewarding, especially over time.

My Weaknesses

I'm a Product Manager with 4+ years of experience and I'm looking for my next gig. If you think I'd be a good fit at your startup, check out my résumé and get in touch!

Transitioning careers is jarring, like coming up for air after being underwater. It's a big context change, especially if you're like me and tend to focus very intensely on your work up until your last day. As part of re-orienting myself I decided to make a list of my strengths and weaknesses as a Product Manager to better visualize where I am in my career. I then took that information and built out some short- and long-term career goals for myself. It was, to be honest, a really boring exercise.

For strengths, perhaps boring is correct: I know what I'm good at because it's what I've been doing recently. It's in the past. Some of those skills are routine. For others, I've gone past the 10,000 hour mark on a few and I barely think about the activity itself. Other skills are well on their way and I am simply waiting for the next major challenge in my career to spark more growth.

For weaknesses the story is different: I may have attempted to build a skill and failed, I may not have spent enough time doing the activity, I may be naturally limited in that regard, or I may not know about the skill at all yet. In any case, weaknesses are skills you haven't mastered yet.

In order to land your dream job you'll probably have to consider both sides of the equation. Good employers want to see that you can get started right away but also that you have the room and motivation to grow. In this framework your strengths describe your current value and give employers a good sense of what you can excel at right now, while weaknesses describe your future potential. If treated well and fostered, weaknesses become strengths become mastered skills.

So why do we focus so much on our strengths when searching for jobs, shying away from those aspects of ourselves we know we have to put time into? It's a fallacy to think that potential employers believe we're perfect. It's equally wrong to think at any stage of a career that we have nothing left to learn. Furthermore, if our potential employer cares about our development as much as we do, why would they want to hire someone who feels they have no more room to grow?

Let's explore this. In the following section I will lay out my weaknesses as a Product Manager with as much humility as I can muster. I'll include a clear plan for developing that skill. Hopefully we can paint a picture of a success-in-the-making, rather than a snapshot of past failure.

My Weaknesses, My Plan

  1. I do not define KPIs far enough ahead of time - Simply put, I should "know my number" before any feature hits production. My number can change with further validation, but it's important to take a stand. I am historically unwilling to set anything less than a quantitative, validated hypothesis, whereas KPIs frequently require a bit of intuitive guessing. I plan on defining KPIs in the same way I insist on engineering estimates. I will not be correct at first, but I will improve with time.
  2. I defer to Engineers in feasibility explorations - As in, I don't challenge engineers to innovate as frequently as I should. Instead, I internalize the burden of innovation into the Product department, making it "our" problem. This empowers engineers (intended) while insidiously altering the validated feature set (unintended). Instead of doing this, I plan on insisting that we support the validated features or else not start development.
  3. I assume I know the competition - Sometimes this is true. Actually, in my last few jobs, it was always true due to the nature of the business. But that doesn't mean I shouldn't be double- and triple-checking on a regular basis. Especially where domain expertise and early onboarding are concerned, knowing and cataloging your assumptions about the competition is paramount to building a good Product vision, strategy, and roadmap. I plan on making competitive research a part of my morning and my afternoon: the former to uncover new findings, the latter to draw actionable conclusions.
  4. I converse better with Individual Contributors and groups than with Execs - My preference has always been towards managing and building trust amongst those people who do the actual work. I try to shelter individuals from the drive-bys and ephemeral asks of executives. I can improve on this drastically by learning to speak with execs in a way that helps them feel heard and understood. That's the best way to prevent drive-bys in the long term. I plan to continue to be as honest as possible while also providing real-time and periodic (read: predictable) feedback to executives in order to inform them of product progress or lack thereof.
  5. I choose social capital over product superiority - As someone who spent quite a bit of time project managing various teams I know the value of social capital when it comes to getting projects done on time, on budget, and to spec. As a good Product Manager I also know that up-front product decisions need to be made with the company's best interests as first priority. Social capital is important, but making product decisions based on team makeup or mood can drastically pollute the vision of a given feature. I plan on building strategies for listening to ideas without making promises so that individuals know their input is valuable but I make the final decision.
  6. I try to do too much at once - My facetious mantra has always been "Laser Focus...on everything at the same time." The responsibilities of the Product Manager are myriad and overwhelming, but it is always on me and no one else to manage those and still find a way to focus on the most important product we have to define, validate, or build. I plan on rejecting more product ideas verbally while keeping them in the icebox to look at later, building weekly schedules around specific initiatives, and improving my ROI calculations on given features in order to always be working on the most important product at the given time.

Final Words

That was a little strange. It's odd to think about people as four dimensional beings when considering them for a need or role that exists in the past and present. However, at least as a personal exercise, I've now given myself a 3-6 month roadmap of skills I need to learn. While I know it will be exciting and rewarding to pursue the above skills, I also know that doing so will uncover many more items to add to the list.

My advice to you is to approach new weaknesses as impartially as possible until you can understand them as nascent opportunities. Allowing areas of weakness to affect you adversely will end up seeding discouragement at the prospect of turning that weakness into a skill. After all, the whole point of this exercise is to better know yourself. The fact that you're doing it at all means you have the wherewithal to turn any weakness you may find into a solid skill.

Measuring Personal Velocity

Every team has a different way for measuring the speed at which code is shipped. Some do so according to strict agile scrum principles, some create their own processes, but the focus is clear: teams should know their velocity. It's a prerequisite for shipping frequently and effectively.

The Problem

Oddly enough, most people don't measure their own personal velocity, which leads to an important question: how can we be sure of our personal contribution to our team? It makes it difficult to determine how we work best when we're not exactly sure how we work in the first place.

Naturally I decided to run an experiment on myself to see how this would work.

The Experiment

I started a new job at DigitalOcean in August, which comes with a new set of routines and lots of new stuff to learn, making this endeavor especially timely. At DO we use Trello to organize ourselves at a team level, so I decided to use it as my personal velocity measurement tool as well.

I built two boards for this purpose:

  1. Sam's To-Dos - where all my current tasks are listed.
  2. Sam's Archived To-Dos - a board I use for analyzing the task load of previous time periods.

My To-Dos board is set up to collect tasks from a task backlog using list headers like these:
Trello Board Headers

As tasks come in, I put them either in Do Soon or Do Later. That's the only triage I can handle at this point.

The Cadence

Every velocity measurement needs a cadence that defines the period over which work is done. For me, this is a single day. Ideally, individual velocity gets measured within the team cadence so each teammate has a chance to adjust their velocity without throwing off the whole iteration.

My cadence proceeds as follows:

  1. End of Day - Reorganize "Do Later" and "Do Soon." Then pull tasks into the next day's list.
  2. Beginning of Next Day - Add or remove tasks from today's list based on overnight changes. Archive yesterday's list.

Rinse, repeat.

The Analysis

My goal through all of this is to collect data to support a better understanding of the work I do on a daily basis. By diving into the archived task list I'm able to glean the following:

  1. I perform more total tasks mid-week.
  2. The tasks I perform at the end of the week take significantly more time (spec writing, data analysis, feature research) than those I perform on Mondays.

This is interesting. But what would be more interesting is being able to see at a glance what types of tasks I complete, how long they take, and how I contribute to the broader team velocity. I hope to have solved all those problems next week.

People before Process

I'm a product person. keep that in mind.

In tech you hear this repeated frequently, mostly because of the difficulty we all have in balancing people and their needs, creativity, and stress levels with an organizaitonal process and its timelines, requirements, and information flows.

My own teams at DramaFever suffer occasional malaise due to the processes we employ, which are themselves in place to compensate for us having two very culturally different offices. It's a constant struggle to bring people together without making anyone feel like a cog in a machine rather than a fully functional adult developer.

So, I spend a lot of time finding ways to ameliorate the situation. We use Google Hangouts to video chat. We aren't an Agile shop but I try to check in daily with everyone, even if just to say hello. I organize my features first by writing business requirements, then by asking developers and designers for their own requirements, then writing loose functional specs to collect final, pre-development buy-in.

But things could always be better. And, having hired some new mobile devs recently, I saw an opportunity to improve things further by clarifying why we care about our teams. Here's what I came up with to be used as part of our onboarding docs for these new mobile devs:

Everyone plans

When we decide what's happening in the next few versions of the app, everyone who will touch the project is in the meeting. Product will come ready with requirements and a Project Manager will facilitate the meeting, but everyone is heard and everyone should strive to achieve buy-in from the other team members when suggesting a change. We do this to get on the same page up front and to avoid having more meetings during active development.

Milestones are flexible

We use Github milestones to organize features and issues. Milestones collect issues and have a date of potential release attached to them. This release date is flexible and a suggestion based on the amount of work contained within that milestone. Work doesn't get rushed to meet a milestone. Milestones flex in date or issue count to accommodate the pace of development.

We anchor milestones with large features

Whether it's new stuff or bug fix releases, milestones should encompass one big idea. This big idea gets split into many tickets, and sometimes has unrelated tasks thrown in by necessity. A milestone should not be a bucket for product backlog features.

Milestones can become releases

A milestone should have enough code change to warrant a release. However, a milestone does not have to become a release. It should be modular enough to allow us to add to a bigger release or even to push it off for later should we need to.

Release Candidates have change logs

When we're ready to test a new build, whether it's intermediate or a true RC, a change log is needed to keep everyone sane. Generally that just means marking tasks as "retest", but all parties should know exactly what and how to test the new features or fixes going into a build.

Everyone tests

Acceptance testing, that is. If you have a feature going in, make sure you're part of the testing effort. We want our app to work. We also want it to work the way you intended it to work. Consider this pre-release dogfooding.

Everyone gives feedback

At any point in the release cycle you should feel free to give me (Product), Design, Development, or anyone in between whatever feedback you feel is necessary. Don't wait. Because we should all have buy-in at this point, we all expect things to work and function as discussed. If you expect things to work differently, speak up. We don't bite.

Everyone gets credit

We're a team. We do a lot of awesome work. We all deserve recognition when things go well. And, when things don't go well, we learn from our mistakes. When a project reaches public release, everyone gets mentioned. If issues arise, we tackle them as a team. If your view performs well, all your teammates get the credit with you, and if your view has some mistakes in it, we all scramble to fix it with you.