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.

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.