“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan” — Eliel Saarinen Frequently we will be given problems to solve by other people. Early in our career, these problems will usually be well-scoped and specific, eg: Add this new data to an interface Make an endpoint that returns a certain specific calculation or piece of data. And as we grow as engineers these tasks become bigger but often the success criteria remains well-defined: Write a service to manage the state of a custome ..read more

Adding product management to more traditional software infrastructure organizations, sometimes with a shift towards platform engineering, is all the rage today. As someone who has done both these things, it doesn’t surprise me to see so many people struggling to make it work. Both of these shifts require going from a siloed, process, tech-focused mindset to a portfolio, usability, and customer-focused mindset. This is a hard transformation, and it’s easy for people who have spent their whole career building infrastructure to misunderstand what product and platform really mean. So I thought I’d ..read more

I have agreed to give a guest lecture for a class at Yale, and they’ve asked me to speak about “building and motivating engineering teams” from the perspective of a smaller startup. The readings for my section include A Field Guide to Software Developers by Joel Spolsky. I remember reading it when it was first written. I admire Joel’s work, and the piece has many valuable takeaways. However. The industry has changed a lot in the years since this piece was written. In 2007, the options for engineers here in NYC were far more limited. You worked for a bank, a media company, ad tech was startin ..read more

In my previous post, I discussed the leadership virtues of Laziness and Impatience. But as you may know, I neglected one of the core virtues in my list, namely, that of hubris. Hubris. Pride. As Larry Wall says, Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. I would translate this as taking pride in one's work, and being willing to not just take pride in it, but show off that work, talk about it, teach others its magic. And hu ..read more

There is a movement now in tech to really think about what it would take to improve our interview process. This is a movement a long time coming. White board coding interviews are clearly a strange way to measure a person's ability to actually do the day to day work of a modern software engineer. And we know that we tend to have a lot of bias in our interview processes that takes what we wish were an objective evaluation of skills and turns it into something very, very subjective. Recently, my friend Julia Grace wrote about the interview process at Slack, to grant more transparency into what ..read more

This is reposted from my Ask the CTO series on O'Reilly The problem: I don’t know how to figure out what’s happening on my teams without asking people directly, and it’s driving them crazy! I am in charge of a team that is running a big, critical project. My boss is breathing down my neck at all times, asking me for status updates, wondering when different pieces are going to be done. Usually, I know what is happening because I’m doing some of the work myself, so I can give the answers because I’m deeply involved in the project. This time, however, I’m not actually doing any of the work, and I ..read more

Software engineers are attracted to formulas, algorithms, and structures. As people whose job it is to take ideas and turn them into predictable executable code, it is unsurprising that we’re drawn to ways of thinking that categorize and systematize things. This attraction continues as engineers become engineering managers and leaders. I should know, I wrote a pretty popular book that is full of best practices, tips, tricks, and process suggestions to apply to the various challenges of leadership. However, I think it’s worth talking about the downside of going too far with structural thinking ..read more

 Most companies have carefully created separate senior career tracks that provide details of the differences between being a manager and being an individual contributor (IC). And yet, many people still believe that you can’t get ahead without becoming a manager, and many companies who want more senior individual contributors struggle to promote people on this path. This is a shame; great engineers really shouldn’t need to manage large teams to get promoted, and companies lose out on a critical skillset when they push all of their good engineers into management. Why do we have this problem ..read more

For varying levels of seniority, from senior, to staff, and beyond. How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time How to mentor an early-career teammate, a mid-career engineer, a new manager who needs technical advice How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid How to explain a technical concept behind closed ..read more

 originally posted on LeadDev.com One of the most stressful parts of the end-of-year process for managers is the dreaded performance rating. This process forces you to boil down all of the work that a person did over the year, all of their accomplishments and misses, into a numeric score (often from 1–5) that may also come with words like ‘meets expectations’, ‘exceeds expectations’, or the unhappy ‘misses expectations’. If you work for a company that has a ‘pay for performance’ model, your rating will influence the employee’s compensation. It may be used as an input for promotions, and y ..read more