Management on Dan Goldin

Incident response

Thu, 24 Dec 2020 00:00:00 +0000

In honor of everyone on-call during the holidays I thought I’d share my evolving thoughts around incident response. Every company has something here and as much as we can strive for perfection it’s impossible and we’ll inevitably have incidents that need handling.

I’m still thinking through the exact way to approach and summarize my thoughts but I find it useful to start with goals and first principles. The ultimate goals are to resolve the issue as quickly as possible and prevent them and other similar issues from recurring. In terms of axioms, we want to align incentives and make those able to solve the problem own the problem. In addition, we need to embrace that we work on highly dynamic systems - both the systems and people change. And finally, we need to consider incident response as one of the many responsibilities engineers have.

An ounce of prevention is worth a pound of cure

Wed, 23 Dec 2020 00:00:00 +0000

As we get into the last week of the year many software teams are in a code freeze - avoiding any deployments that may cause an incident and cause a dreaded holiday page. We have a tendency to reward the firefighter for pulling an all-nighter fighting an outage but don’t value those that avoid the fire in the first place. It’s natural to throw accolades at the firefighter since it’s very easy to see the impact in their work; it’s more difficult to see the value in the person that prevents issues from even happening. The counterfactual is difficult to prove so we diminish its significance but that’s where long term value is actually built.

Working your way up the engineering management stack

Fri, 28 Aug 2020 00:00:00 +0000

During a engineering management peer group discussion this morning we were talking about how involved each of us are in our team’s activities - for example how often do we look at code? Do we leave comments on pull requests? How involved are we in spec reviews? And a variety of questions of that ilk.

At that point in time I wasn’t clever enough to come up with a framework but it’s very much about working your way up further from the code as you work your way up the management track.

Yards, balls, fences, and software engineering

Thu, 20 Aug 2020 00:00:00 +0000

One of my strongest beliefs is that the best engineers are able to find ways to unblock themselves. Similarly, a pet peeve is when people say “that’s not my job” and expect a problem to be fixed by someone else. Sure this may occasionally happen but it’s important to have the attitude that you’re willing to get your hands dirty in order to solve your problem and move on.

An analogy I used to represent this concept is to imagine having a house with a yard that’s next to a neighbor. Let’s say you’re throwing a ball around and it lands in your neighbor’s yard. Do you quickly hop over, grab it, and then come back? Or do you go to their front door, ring the bell, and then have them retrieve it for you? If you have a good relationship with your neighbor you’d clearly just go and get the ball.

The sandpaper learning method

Tue, 18 Aug 2020 00:00:00 +0000

When gluing two pieces of wood it’s useful to use sandpaper to improve the effectiveness of the glue. Learning follows the same pattern: you want to struggle a bit and get yourself ready so the knowledge sticks.

Imagine you have two people who each encounter a problem they don’t know how to solve. The first immediately goes and asks for help from a peer and quickly get it resolved. The second person tries to solve it themselves, does research, tries a few different approaches, struggles throughout and then ends up getting help from a peer. The first person gets to the solution quicker but it’s the second person who actually learns. The struggle for the second person made it easier for them to both understand and retain the resolution. It’s the second person that will have that faster rate of learning and will be able to apply their knowledge more broadly than the first.

Three types of advice from a manager

Sun, 09 Aug 2020 00:00:00 +0000

During one of my first meetings with a former manager he gave me an introduction to his working style. One of these was how he gave three types of advice:

A passing thought. This is not something that was thought of too deeply and just popped into my mind. I’m sharing it in case it’s helpful but it’s just as likely to be useful.
A suggestion but trust you. I’ve run into similar scenarios in the past and learned from those experiences. This is one of those. At the same time I trust you to make the right decision since you understand the current problem and constraints better and know the modern tools. And if it turns out that the approach doesn’t work it would act as a learning opportunity.
Just do it. This is an order. While I will do my best to explain my reasoning I am your manager and don’t need to justify it.

The expectation is that the first two should make up at least 90% of the advice (and ideally more) since they’re the ones that actually instill ownership and empower the individual to make decisions. It’s also a failure of a manager if you end up in a situation where you have to override your team that often. It may be an indicator that you did not provide enough context and that your team is not seeing the full picture. It may also be that the team just doesn’t have the skill or desire to operate at the level you need them to. In any case the fact that you need to resort to this last level often is a symptom of a problem that you need to root out.

Catch up with your former coworkers

Wed, 10 Jun 2020 00:00:00 +0000

It used to be the case that people used to work at a company for decades, some even retired at the same company they started working at. We’re no longer in that world. These days it’s rare to find someone who’s worked at a company for longer than 5 years.

There is a benefit to this rotation though: when people change jobs they also bring their ideas and experiences, mix them with those at their new company, and converge to better and better approaching. A great way to accelerate this is by reaching out to all of your coworkers a few months after they left and asking how they’re doing. It’s a great way to stay in touch and maintain that relationship but it’s also a good opportunity to compare and contrast how they do things. They would have left recently enough where they understand your processes and embedded enough in their new roles to know how things work there. Those differences give you a lot of valuable advice on what other companies are doing and whether there’s anything you should change on your end.

Three categories of software engineering work

Sat, 30 May 2020 00:00:00 +0000

Managers love frameworks to help think through problems and I’m no different. While trying to think of a way to reason through our engineering work I started grouping it into three major categories:

Should have been done yesterday. Self explanatory but these are the items that as soon as you discover them you wish they had already been done. Critical bugs and issues fall into this but also product oversights that you wish you caught earlier.

Metrics, logging, and error reporting

Wed, 27 May 2020 00:00:00 +0000

As software engineers it’s vital to understand how our applications are performing. The more information we have the better we can address problems, improve performance, and generally better solve problems for our customers. Imagine releasing a product with nothing being collected - you’d be flying blind.

I’m a huge advocate for measuring application performance in terms of business metrics and aligning it as much with the customer experience as possible. This post does not go into that. Instead, I want to share my beliefs around measuring the technical application performance. In my mind, they’re grouped into three major categories: metrics, logging, and error reporting. There is some overlap but I find it a helpful way to think about them.

The curse of mastery

Sat, 16 May 2020 00:00:00 +0000

One of the most valuable skills a software engineer can have is a “tabula rasa” mindset. Tabula rasa, Latin for blank slate, is a philosophical concept dating back to Aristotle to explain how human minds are blank from the beginning and acquire knowledge through the human experience.

I think of it as being able to approach new challenges and experiences with no prior bias. Done well, this is an incredible power since you’re able to cut through the complexity and focus on what actually matters. Imagine you’re a software engineer who joins a new company - there’s so much business context you need to ramp up in addition to the code that’s grown in complexity over the years. By the time you’ve mastered everything it all makes sense and you’ve embraced the complexity.

Sometimes it really is just the dirty, hard work

Sat, 02 May 2020 00:00:00 +0000

It’s easy to fall into the trap of only wanting to do the new and sexy thing and giving up as soon as something requires the dirty work. That’s rarely a strategy for success and jumping from one idea to another idea and only focusing on the interesting parts is a sure fire way to not get anything done.

Last week I had a brief conversation with Twitter that got me looking for Apple’s S-1. Apple filed this in 1980 as part of their IPO process and on one hand it’s remarkable that you can find a 40 year old document online and yet on the other hand it’s disappointing that it came as a PDF. I imagine every year there are thousands (tens of thousands?) of people that want to take a look at the IPO docs of one of the most impressive tech companies and yet end up with a poorly rendered version. What if someone took the time to modernize it and convert it to a modern S-1? A massive amount of people would benefit and they would get the credit.

Engineering management resources

Sat, 25 Apr 2020 00:00:00 +0000

At the beginning of the year I gave myself a goal to write more management posts. We’re nearly 5 months into the year and I’ve written only two posts even relating to management. A big reason is impostor syndrome - while I have only been managing a few years there are so many others that have more experience, are better managers, and are more effective writers. At the same time, the lack of experience hasn’t really stopped me from writing on other topics though so why should this be any different? This coupled with the fact that I write to organize my thoughts and clarify my thinking is all the more reason to commit to writing about new topics. As a start, I thought it would be helpful to share some resources that have helped me grow as a manager.

Micromanaging is underrated

Tue, 04 Feb 2020 00:00:00 +0000

A common belief is that micromanaging is a poor way to manage. I subscribe to this view - it’s demotivating to have someone second-guessing every step and eliminates agency and autonomy. I’d rather have someone make a few mistakes and learn along the way rather than impose a top-down view that disincentives growth.

While reading Bob Iger’s biography, I came across a simple statement from his former boss and Disney CEO, Michael Eisner: “Micromanaging is underrated.” That gave me pause. So often we hear that micromanaging is terrible and no effective manager does yet here’s someone incredibly successful leaning into it. Bob Iger distances himself away from this black and white view by discussing finding the balance while admitting that in many cases the details do, in fact, matter and it’s up to the CEO to make sure the output of the team is as polished and great as possible. The passage reminded me of Steve Jobs and his reputation for being incredibly detail-oriented and obsessive. In many ways, his approach was all about micromanaging and yet Apple made some of the most incredible and breathtaking products. Clearly there’s some value in micromanaging.

Build for optionality

Fri, 03 Jan 2020 00:00:00 +0000

I wrote a company wide email back in September titled “Building for optionality” that describes how our engineering team maintains its impact despite the growing complexity of the business. There are a few TripleLift-specific concepts that I stripped away to make it more approachable but the theme is the same.

For a company that’s growing and changing as quickly as TripleLift, it’s critical to make sure our code is as impactful as possible. One way we do this is by building for optionality.

Netflix's CEO transition

Sun, 22 Dec 2019 00:00:00 +0000

While browsing Quora I came across a neat answer by Marc Randolph, the founder of Netflix, to the question “What led you to step down as Netflix’s CEO?” I didn’t even know Netflix had a founder other than Reed Hastings and beyond that didn’t know that there was a CEO transition that early in its history.

Netflix is an incredibly dominant company now but it took more than two decades to get there. Netflix is actually older (founded in 1997) than both Google (1998) and Facebook (2004). The anecdote is remarkable since it shows a glimpse of the Netflix culture and how radical honesty was a key part from the very beginning. I’m impressed by both Reed’s ability to be that directly honest but also communicate in a way that kept Marc aligned and engaged. It’s an incredibly difficult thing to do - being able to have someone accept that they’re not not effective at their job - and a skill I continue to grow and develop. You need strong trust on both sides and the ability to let go of the ego. A good leader can make that happen.

Make sure you're understood

Sun, 06 Oct 2019 00:00:00 +0000

While browsing Twitter I saw a simple visualization that spoke to me. Communication is what makes us human and good communication is critical to strong teams. Historically, I’ve definitely fallen in assuming that when I spoke what people understood was exactly what I thought and was both surprised and disappointed when that wasn’t the case.

Goldilocks and the three implementations

Mon, 16 Sep 2019 00:00:00 +0000

While browsing Twitter I came across the following tweet that resonated:

A common refrain I have is that the best engineers are not the ones that write the most code but are instead making decisions that reduce the amount of code that needs to be written in the future. This tweet speaks to that since very often an implementation will either be too simple to support a future use or be over-implemented to support a potential future use case. The truth is often somewhere in between.

Explain the why in code reviews

Sun, 25 Aug 2019 00:00:00 +0000

This may be obvious to most people but it’s still worth reiterating: if you’re leaving a comment on a code review make sure to explain your reasoning. Code reviews are a key component in writing high quality code, improving everyone’s skills and knowledge, and encouraging a strong and collaborative team.

Code reviews can be a bit clinical with feedback being blunt and a few words and it’s important to add context to all but the simplest of feedback. Experiences and backgrounds vary across the team and what’s obvious to one person may not be obvious to others. Similarly, it softens the feedback and encourages both sides to have a conversation. The act of describing the why also forces the reviewer to slow down and actually think about their reason for the change request. This may, in fact, reveal that the change request is not actually useful or may not actually have a good reason.

Ideal tech intern projects

Tue, 09 Jul 2019 00:00:00 +0000

Having a tech internship program is a big investment that companies should not undertake without making sure they can put in the work to make it successful. Some companies approach it as a source of extra help but without giving the interns the support they need it will end up in hurt productivity for them and the rest of the team.

The ultimate goal of an internship is to provide useful work, determine whether there’s an opportunity for a full time role, and sell the candidate on that opportunity. A great way to achieve these ends is to give interns a chance to own a large project that allows them to get a feel for the work and showcase their abilities. The ideal project should have the following traits:

Type 1 and Type 2 tech specs

Fri, 01 Jun 2018 00:00:00 +0000

Every year since Amazon went public, Jeff Bezos writes an insightful and penetrating shareholder letter that covers a variety of business topics driving Amazon’s success. In 2015 he wrote about Type 1 and Type 2 decisions:

We want to be a large company that’s also an invention machine. We want to combine the extraordinary customer-serving capabilities that are enabled by size with the speed of movement, nimbleness, and risk-acceptance mentality normally associated with entrepreneurial start-ups.

People do what you inspect, not what you expect

Tue, 26 Dec 2017 00:00:00 +0000

While reading Who Says Elephants Can’t Dance about the revival of IBM in the 90s I came across a simple, yet profound statement by Louis Gerstner: “People do what you inspect, not what you expect.” We hear variations of this constantly and it’s true - if you want to drive behavior change you need to make sure that’s what you’re actually measuring and holding people accountable for. Otherwise we all run the risk of preaching what we don’t practice.

Measuring sprint efficiency

Fri, 01 Dec 2017 00:00:00 +0000

Most startups employ some form of Agile software development and one of the most common approaches is Scrum which breaks down units of work into time based periods. I don’t want to spend too much time describing either Agile or Scrum since I suspect most are familiar with the concepts but a big challenge is measuring productivity. There are tons of different ways of doing this but the vast majority are different ways of looking at the relationship between story points and sprints. Most of these are focused on some form of velocity - measuring the amount of story points per sprint but an interesting metric I’ve started tracking is average number of sprints per story point. On the surface this is similar to taking the inverse but it turns out it tells different story.

The different flavors of engineering interviews

Wed, 17 May 2017 00:00:00 +0000

Technical interviews often come in a variety of flavors and I thought it would be interesting to list as many as I can think of and my thoughts on each one. In general I think there’s value in each type of approach but some are going to be more appropriate than others depending on the person’s experience and role.

Brainteaser. These are seemingly simple problems that require a trick or insight to get them right. If you’ve heard it before or are familiar you can blow through these otherwise you’ll need to rely on a series of hints to get to the final answer. Probably not the best way to judge someone’s ability since it’s likely removed from the work they’ll actually be doing.
Data structures. A bit more legitimate than the brainteaser approach this question digs into your knowledge of data structures. These usually start with some sense of complexity and then end up in implementing some type of traversal or tree search. The theory and knowledge of these is important but it’s pretty rare to have to implement a low level data structure.
Architecture. This moves higher level and asks you to think about designing a larger application. How would the various components look? If it’s a service what endpoints would be exposed? What are the arguments and results for each of the calls? How would you scale this? What if you needed to make changes? These are a useful way to see how someone thinks and whether they have some familiarity thinking through the architectures of large and complex systems.
Technical. Depending on the domain this gets into the nuances of a language or technology. These range from a rapid fire style that’s asking for descriptions of various HTTP status codes to a deeper dive into the TCP/IP protocol to discussing high level networking or the nuances of particular language or application versions. The goal here is to quickly get a sense if the person knows what they’re talking about or whether there’s only a superficial knowledge. Used alongside some of the other approaches this is a solid way of gauging the accuracy of a resume.
Code test. This is the typical code test where you’re given a problem, a computer, and a time limit. Hopefully the problem is simple enough and offers a variety of implementation options that allow you to see the thought and decision process. The most successful ones involve introducing the problem and making sure everyone is on the same page and an occasional check-in to answer and address any questions. The difficulty here is that not everyone can code in a high pressure environment and you may be missing out on a lot of great people that are strong coders but don’t do well on code tests.
Pair programming. A variation of the code test that tries to make it a bit less stressful is to do a pairing exercise where you’re both working on a problem and bouncing ideas off of one another. The goal is to have the candidate do most of the coding and you act as a sounding board since you do want to get a sense of the person’s coding ability. This also serves the benefit of showing you whether you’d get along since it’s a quick glimpse into how you’d work together on the same project.
Feature addition. This is working with someone on the production code to build out a simple feature. Pair programming is usually done on a predefined problem but this takes an actual problem you’re working on and turns it into a pairing exercise. I haven’t seen this done much since it usually requires a ton of context to ramp someone up to your codebase and every person ends up with a different experience. Nice in theory but I don’t know how well it works in practice.
Unit test fixing. I’ve seen this done a few times and it’s usually set up as a fully written project with a few broken unit tests. It’s your job to go through the underlying code and fix it to get the unit tests to pass. I like this one since it tests something everyone needs to do - go through someone else’s code, understand what it’s trying to do, and make some enhancements without breaking the existing functionality. This requires a fair amount of setup work, especially if you need to support multiple languages, but it’s a great way of testing the skills any developer should have.

The goal of every interview is to make sure the person you’re interviewing will be successful at their job. The best way is to give them something that’s as close to the job itself as possible. If they succeed it’s likely they’ll be able to do the job itself and if they fail it’s likely they wouldn’t be able to cut it. The implication is that you need to structure your process to optimize for this. No single one of these will tell you everything you need to know so it’s important to mix and match to find the combination that gives you the most confidence in your process.

Refactor driven development

Sun, 19 Mar 2017 00:00:00 +0000

There are a variety of software development methodologies and I’d like to throw another one into the fray - refactor driven development. Rather than focusing on tests or models or functions the focus should be on expressive and maintainable code. Imagine spending 80% of your development time on refactoring old code and laying a solid foundation for all future work. Then the remaining 20% of the time can be spent on writing new features and functionality that drive the product forward. Once this work is done it may lead to more refactoring work to get the code back into a pristine state.

Automating admin work: Spreadsheets to Slack

Sat, 04 Mar 2017 00:00:00 +0000

Recently we adopted the concept of owning your own up time for our engineering teams. The goal is to encourage a stronger sense of ownership and actually give the teams the autonomy to approach their development and release process the way they’re comfortable with. Before this we relied on a single on call every week that would be responsible for monitoring all issues and escalating them to the appropriate team. One minor side effect of this change was that I now had to manage the on call calendar and post the new rotation on Slack every week. Since this was a good opportunity to mess around with the Google Spreadsheet and Slack APIs I decided it good be a fun little project.

Becoming a better developer

Wed, 30 Nov 2016 00:00:00 +0000

Yesterday I had the privilege of giving a talk at HackReactor titled “Things I wish I knew” which was an amalgam of the various themes and topics I’ve been blogging and thinking about. While going through the blog I came up with two themes for the topic - the first was tactics that would make someone a better programmer immediately and the second was how to improve as a developer over time.

Automating management

Sun, 18 Sep 2016 00:00:00 +0000

One of the biggest lessons I learned when I became an engineering manager was how important the basic operational elements. These are all the things that need to get done outside of code and allow the whole team to be as productive as possible and range from reminding people to do code reviews to creating dashboards to highlight key metrics to enforcing an on-call process. These tasks are important yet repetitive so being a good engineer I’ve spent some time automating them. There’s still a long way to go but strong engineers have a mindset that they want to automate as much repetitive work as possible in order to focus on unique and novel challenges.

Engineering management: Measuring the unmeasurable

Sun, 07 Aug 2016 00:00:00 +0000

A key part of management is getting out of the way and building out processes that help your team be as productive as possible. At the same time, you can’t change what you can’t measure. Combining these two makes it clear that to improve, whether people or process, you need to start measuring and tracking the appropriate metrics.

In software engineering, some things are easy to track: how many bugs there are, how quickly they’re resolved, how much code are written - but rarely tell the whole story and may lead to perverse incentives. The common example is measuring developer productivity through number of lines of code written: a smart developer would purposefully write verbose and long winded code to get their metric up.

Maximize the potential energy of your code

Mon, 04 Jul 2016 00:00:00 +0000

Potential energy: the energy of a body or a system with respect to the position of the body or the arrangement of the particles of the system.
Dictionary.com

Kinetic energy: the energy of a body or a system with respect to the motion of the body or of the particles in the system.
Dictionary.com

Avoid full body code transplants

Wed, 27 Apr 2016 00:00:00 +0000

When working on new features it’s easy to keep increasing scope until you end up doing a full rewrite of your code. Don’t. It’s healthy to refactor code as you go but you need to be wary of how many things you’re changing and the risks those changes carry. Code will get stale unless it’s constantly maintained and updated as the rest of the product evolves but trying to change too much at once will make it difficult to diagnose issues and increase the odds of bugs in production.

Generalize at n=3

Thu, 07 Apr 2016 00:00:00 +0000

Engineers strive to write code that’s general and flexible enough to adapt to support a variety of cases with minimal changes. Unfortunately, writing general code isn’t easy and requires significant thought, effort, and experimentation. The challenge is figuring out the appropriate time to generalize your code.

If you do it too early you may spend unnecessary time writing generalized code that will never be used again. Even worse you may write code that you think is generalizable but ends up collapsing under its own weight under future scenarios. In this case writing minimal code would have served you better since it would have been much easier to adapt or throw away to support the new case.

The best code is no code

Tue, 05 Apr 2016 00:00:00 +0000

The best code isn’t code that’s elegant or code that’s brilliant it’s code that doesn’t need to be written. One of the best feelings is when you can take a new problem and turn it into an existing problem that already has a solution. Sometimes that requires making a few tweaks and compromises to the problem or the code but the time and effort saved can be massive. This requires a deep understanding of the problem being solved as well as the existing code. Someone knowing the code but not the problem won’t be able to transform the problem into something applicable. And someone having a deep knowledge of the problem but not the code won’t be able to see how the code can be adapted to solve this scenario. The optimal result comes from someone who can strip away the cruft from both of them while still maintaining the spirit of both in order to combine them.

Describe what your code won't do

Sun, 31 Jan 2016 00:00:00 +0000

When starting to spec out a new feature a good habit is to think about what it won’t do. This forces you to focus on the problems that aren’t being solved and makes you aware of the tradeoffs you’re making. Rather than focusing on the problems being solved it’s equally important to know what you’re not doing as well as what your implementation will preclude you from doing in the future. To be effective we need to make tradeoffs or we’d never be able to launch anything but we shouldn’t make them blindly. We need to be aware of the tradeoffs we’re making and understand the paths that will be closed off by a given implementation. By thinking of the negatives of a particular approach we’re able to surface many of these dormant issues. This helps avoids surprises later on and ensures the code has been dissected and thought through in a variety of ways.

The ownership hierarchy

Sat, 23 Jan 2016 00:00:00 +0000

Great engineers assume end to end ownership of their products. Rather than focusing on one feature at a time they understand how it fits in with the rest of the product and think about the impact it will have on users and the business. This leads to code that scales with the product while being able to be maintained and developed by a small team. But you can only have this with everyone embracing full ownership over a product.

The true cost of low quality

Fri, 25 Dec 2015 00:00:00 +0000

Recently I’ve found myself have similar conversations with various members of the engineering team regarding the tradeoff between speed and quality. Every situation is different but without going into project details I’ve found that quality come first, speed second. Not because I think speed is unimportant but because I think quality is underrated. In the desire to push the next feature and launch the next product quality tends to be sacrificed. This is fine as long as we understand the tradeoffs but in most cases those are externalized to others. For example, if an engineering team ships a buggy feature, the engineering team only incurs the cost of fixing it, and even then only if they end up fixing it. Simultaneously, the cost is passed on to the users who are powerless to fix it. And then it goes through multiple tiers - first the end user who becomes inefficient and may lose work, then the support person responsible for dealing with these issues, the product manager who has to context switch to both understand and prioritize the issue, and finally the engineer. During each step time is lost but most importantly is the interruption of flow for multiple people, each of whom gets distracted from what they’re doing in order to deal with a problem that could have been prevented in the first place.

Have a work “workout” plan

Sun, 20 Dec 2015 00:00:00 +0000

If you go to the gym you end up getting a lot more out of it if you approach your workout with a plan in mind. The same thing happens with work. If you go every day you will inevitably get better but if you come in with concrete goals and ways to push yourself you’ll be in a much better position. It’s not as easy to measure your performance at work compared to the gym but just taking the first step and realizing that you want to improve is already beyond how most people approach work. Just by thinking about your performance you improve your ability to identify your strengths and weaknesses. Doing this on a consistent basis gets you into the habit of being introspective and improves your self-awareness, which is necessary to improve.

Know what's mission critical

Tue, 15 Dec 2015 00:00:00 +0000

The accepted belief is that startups should move quickly and err on the side of speed rather than quality. This makes sense. Startups are so risky that they won’t fail due to making a few mistakes but will fail if they get out maneuvered and out innovated. The big advantage startups have is speed and that needs be leveraged.

The one caveat I’d make is that every company, big and small, should have mission critical elements that need to be maintained when pushing new features and updates. I was reminded of this last week when an unnamed corporate feedback startup sent out the private one-on-one notes people jotted down in preparation for their meeting to everyone within the company. This was a huge betrayal of trust and ruined the good will people had for the company and the product. If they weren’t able to get this basic piece right how are they expected to do the rest? Every company has these mission critical components that everyone needs to be aware of and great care must be taken to ensure they work before every deploying or change. In the adtech case it’s serving ads - if ads aren’t working then publishers aren’t making any money and losing money during each impression. For cloud productivity applications it’s critical that they don’t lose your data - downtime is annoying but at least you can switch to another task while they get back up. If you lose your data and documents you have to figure out exactly what you lost and decide whether it’s worth recreating. Everyone in the company should know what these these mission critical components are and it’s everyone’s job to make sure they’re working as expected since failure carries existential risk for the customer relationship. It’s unlikely that a single bad event will ruin things but as soon as it becomes a pattern it’s likely that that customer will be lost forever and never return due to the faulty first impression.

Adhoc task management

Thu, 19 Nov 2015 00:00:00 +0000

A recent trick I’ve picked up to manage my time a bit better is to take all the adhoc tasks I have to do and scatter them into my calendar for the next few days. This allows me to actually get to working on the tasks and I can make sure none of them are forgotten. Using a calendar also forces me to think about the time I expect these tasks to take and plan around that. I’m nearly always running behind and am constantly shuffling tasks around but it’s much better than my previous system of a text file with a constantly growing list of todos. A side benefit of this approach is that I can split my day into maker versus manager chunks rather than be at the whim of meeting invites.

Production makes fools of us all

Sun, 25 Oct 2015 00:00:00 +0000

The biggest development lesson I learned over the years is that production is a completely different beast from development. Code that works perfectly in a development environment can fail catastrophically in production and cause a severe impact on the business. Issues can stem from bits of inefficient codes to database schemas that just don’t scale on production. Ideally your development environment mirrors production and has the same load and hardware but that’s rarely the case. For the other cases cases I’d go through the following items to make sure your code is ready for production:

Writing code? Think about the deployment

Sun, 18 Oct 2015 00:00:00 +0000

The goal of every bit of code should be to make it to production. Code that’s not deployed is wasted effort as well as a loss to the business. And a big part of making sure code is deployed is thinking through the deployment plan as we write the code. Some code is deployed simply by pushing the new application while other code may require updating the database schema. More complex code may depend on other applications which will need to be tweaked and deployed beforehand. Large companies and teams have dedicated ops teams that handle deployments but small teams need to do this on their own.

Debate what's necessary and no more

Mon, 03 Aug 2015 00:00:00 +0000

A critical component in communicating between various teams is knowing who has what responsibility. Especially with driven people it’s easy to have overlap between various functions - product and design; design and frontend engineering; and frontend engineering and backend engineering. This is both good - because it’s able to focus more eyes on a particular problem and provides a new perspective - and bad - because people may feel that they can’t move quickly enough and don’t want to cede decision making power. Great teams thrive in this environment while poor teams degenerate into a Dilbert cartoon.

Power of engineering standards

Wed, 18 Mar 2015 00:00:00 +0000

When it comes to productive coding, one of the most important things to do is to impose a set of standards and conventions. As long as you stick with them your code becomes significantly easier to write and maintain. Conventions range from having a standard way of declaring variables to the way files are organized within a project to the field names in database tables. The obvious benefit is that your code becomes significantly easier to navigate, both to you as well as to others on the team, since you don’t have to run through a series of searches trying to figure out whether a variable is called myVariable, MyVariable, or my_variable. The bigger impact is how much simpler your code becomes. By using a standard structure it’s possible to write code that’s further up in the abstraction hierarchy. This is a huge win for productivity and quality since more code leads to more errors and the best code is code that’s not written in the first place.

In praise of the full stack developer

Mon, 23 Feb 2015 00:00:00 +0000

I’m a pretty new engineering manager but a philosophy I’ve adopted is to try to have everyone on the team be as full stack as possible. Everyone has their strengths and weaknesses but being able to grasp the entire stack improves code quality and reduces disruption. And it goes beyond technology and into the business and user world too. Understanding how these various components fit together allow you to make smarter decisions and provide the tools to test and verify your code. The other big benefit is that you’re not waiting on anyone and avoid having your flow disrupted by others.