One of the most amazing parts of starting Percolate has been the time I’ve gotten to spend with engineers. During that I’ve noticed some interesting patterns as engineers move from individual contributors to managers. I wrote up a thing for TechCrunch on some of those observations and ideas.
Here’s a bit on scale:
Essentially the job of being a manager, beyond the human side (which I’ll get to, I swear), is about building a system of people. As you’re growing a company you should absolutely be thinking about how to make this system scalable. On this point, specifically, you need to think about every decision and task you take control of and how that would work if you had 20 more people reporting to you. Micromanagement, in other words, is bad engineering on your part, not bad behavior on the part of the employee you’re managing (no matter how much you think you could solve that problem better or faster).
Read the rest over at TechCrunch.
January 27, 2015 // This post is about: engineering, management, systems
Product management is a central discipline in just about every technology company in the world. The job, at least as we describe it at Percolate, is to own the strategy and roadmap for the team product/s and oversee the execution of those products. At places like Google (and Percolate) these jobs are held almost exclusively by people with an engineering background. The thinking here is two-fold: On one side the engineer’s approach to solving problems is generally pretty optimal and on the other, it’s hard to lead a team of talented engineers if you don’t understand what they’re doing at a pretty deep level. (While product managers mostly don’t actually manage the engineers on their teams, they are expected to “lead” the team and make choices around what they’re developing.)
What’s interesting about product management, though, is that it actually came from the world of marketing. The idea was inspired by brand management, which was originally introduced by Proctor & Gamble in 1931. I’ve read bits and pieces alluding to this connection, but this piece on the evolution of the discipline draws the line quite explicitly:
One reason product management has not traditionally been included in engineering curricula is because it did not start as an engineering role. Its earliest form was brand management, a term coined by a young advertising manager named Neil McElroy, who in 1931 wrote a memo to the executive team at Procter & Gamble proposing the idea of a “brand man”—an employee who would be responsible for a product, rather than a business function.3 The role had many similarities to modern-day product management. His memo called out the need to promote processes that work and outline solutions to problems. Above all, it called for the “brand man” to take full responsibility for the product.
December 11, 2014 // This post is about: Brand management, engineering, google, p&g, product management
I’m incredibly proud of this blog post by James OB, one of the engineers at Percolate, about why he likes the engineering culture at the company. The whole thing is well worth a read, but I especially liked this bit:
The autonomy to solve a problem with the best technology available is a luxury for programmers. Most organizations I’ve been exposed to are encumbered, in varying degrees, by institutional favorites or “safe” bets without regard for the problem to be solved. Engineering at Percolate has so far been free of that trap, which results in a constantly engaging, productive mode of work.
August 27, 2013 // This post is about: business, culture, engineering, percolate
I spend a lot of time thinking about building products (and, more specifically, building teams to build products). With that in mind I really enjoyed this rc3.org post about the seven signs of a dysfunctional engineering team, especially this bit about building tools instead of process:
Preference for process over tools. As engineering teams grow, there are many approaches to coordinating people’s work. Most of them are some combination of process and tools. Git is a tool that enables multiple people to work on the same code base efficiently (most of the time). A team may also design a process around Git — avoiding the use of remote branches, only pushing code that’s ready to deploy to the master branch, or requiring people to use local branches for all of their development. Healthy teams generally try to address their scaling problems with tools, not additional process. Processes are hard to turn into habits, hard to teach to new team members, and often evolve too slowly to keep pace with changing circumstances. Ask your interviewers what their release cycle is like. Ask them how many standing meetings they attend. Look at the company’s job listings, are they hiring a scrum master?
One of the thing I try to communicate to the whole company is that it’s everyone’s responsibility to build products. Products are reusable and scalable assets. While process is a product, tools are (almost always) better. I am working on a long and sprawling explanation of all my product thinking stuff, but that will have to wait for another day.
July 30, 2013 // This post is about: business, engineering, Interviewing, percolate, products
This is a really interesting way to think about the power of Facebook:
Google could still put ads in front of more people than Facebook, but Facebook knows so much more about those people. Advertisers and publishers cherish this kind of personal information, so much so that they are willing to put the Facebook brand before their own. Exhibit A: www.facebook.com/nike, a company with the power and clout of Nike putting their own brand after Facebook’s? No company has ever done that for Google and Google took it personally.
The rest of the article is worth a read as well. It’s a former Google engineer explaining why he left and what’s changed inside the organization in the last two years with the transition to social.
March 14, 2012 // This post is about: advertising, engineering, facebook, google
