The Culture of Yes
How engineering ownership creates the future
Much has been written lately on engineering culture. Important topics have been explored such as sexism, diversity, shared ownership, and, of course, the Google-born 20% personal project time. What hasn’t been addressed much is the culture of fear and negativity that can be instilled by management with the best of intentions and zero maliciousness in mind. What these misguided folks are creating is a culture of no.
It starts innocently: there are a certain number of engineers and there is only so much time to deliver a product. Given these constraints, obviously management will put process in place for any new projects; after all, they can’t listen to everyone’s ideas all at once. Someone has to do the work that’s already been slated for delivery, so everyone can’t work on their own thing. This is a perfectly logical course of events and is completely understandable.
The process that’s been put in place is the start of a no culture.
A process forces an engineer to jump through a given number of hoops before any exploration can be done. Additionally, there’s often little involvement of individual contributor engineers in the product planning process in the first place, so their say of what they are working on is further diminished. Management has effectively reduced the engineering culture to digital bricklayers. A bricklayer is a noble profession and many folks will be happy with this type of work, but I would argue the latter isn’t the case for companies and engineering departments looking to shape the future. Would a digital bricklayer have employed AJAX on the web and popularized its use?
These are the merits of a culture of yes.
If one wants to lead free thinking engineers and foster a true culture of yes, I would argue this culture can be extended even further. One of the techniques that has worked for me in both IC (individual contributor) roles and being a manager is ownership. Not just having individual contributor engineers involved in the beginning of a product planning process, but having those engineers own the process. I believe learning through doing is most effective in these scenarios and it’s how nearly all software engineers got started in the first place.
To that end, engineers I work with are empowered to be the acting CTO for a given segment or product with management’s role focusing on their mentoring, coaching and feedback behind the scenes. Naturally, not all engineers will have this opportunity immediately, or even often, but given time and interest, there will be the chance. They’ll push back on founders, design, product, engineering and myself. They will wrangle the resources they require in conjunction with engineering management. They will negotiate priority with others in their position using management as a tiebreaker. They will own, top to bottom, their portion of a product or segment. This position has nothing to do with title, seniority or tenure: it’s simply about leadership at all levels. At PolicyGenius, regardless of title, we call this set of responsibilities Tech Lead.
“Accountability breeds responsibility.”
— Stephen Covey, author of the 7 Habits of Highly Effective People.
In my experience this rings completely true. Managers weren’t born managers and leadership can be taught. The one thing that can’t be taught though is trust. This is the essential quality one must have in order to instill this type of culture: trust in yourself, your managers, and your engineers. When there isn’t trust, all culture norms break down.
Yes is trust, Yes is hard, but Yes builds the future.
David McKay is the Chief Technology Officer @PolicyGenius in New York City. A Cambridge University graduate and startup veteran, David was an early employee with both Google and AdMob (acquired by Google). Follow David on Twitter @DavidMcKayV.