The art of saying “no” as a leader.

What should engineers consider when estimating a software project?

First, estimation is complex, but it is a skill that you can learn. The more you estimate, the more you evaluate your estimates based on how they compare to reality: the better you will get. 

When estimating, you need to consider known or hidden complexities that could impact the length of the project; don’t always give worst-case estimates, but adjust your estimation accordingly. For example, if you think there’s a 20% chance of an event that will increase the project’s duration by ten days: increase your estimate by two days. Too many engineers go, “that’s <50% chance, so I won’t factor it into the estimate”, so their estimates are always overly optimistic. 

Finally, if you have to pick between optimism and pessimism: consider the consequences of delivering early vs late. If you work in a high-trust environment where being early means waiting for longer for shared resources: perhaps you should be optimistic with your estimates. In an environment where delivery dates are communicated to external partners: being pessimistic with your estimates is likely to reduce disruption.

‍

‍

What are some challenges you face as a Staff Engineer?

Being a staff engineer is similar to maintaining an open source project: you can say “no” to things and stop them from happening but getting others to do something is much more challenging. In most organizations, staff-plus engineers do not have direct reports and cannot directly assign people to projects. The staff-plus engineer can sometimes complete projects individually, but this is not scalable. Alternatively, the staff-plus engineer finds people to work on the project, either convincing individual contributors directly to do the work or management to assign others to do so.

I find this hard; delegation does not come naturally to me. I prefer to write code than write up an issue or convince others to do this work. Still, I appreciate that my personal preferences are not what’s best for the organization or my ability to have a broader impact.

‍

‍

What do you think is the future of open source?

It’s getting easier and easier each year for smaller open source projects to be able to do what only larger open source projects could do previously. For example, GitHub (my employer) initially provided code hosting and issue management but grew to provide code review and now hosted CI and sponsorship payment processing. This has reduced the money open source projects need to spend, often to zero. Simultaneously, raising money has never been easier, allowing some maintainers to work on open source full time.

I think the future will result in maintainers being more intentional in their choices about how they want to participate in this ecosystem. Maintainers need to say “no” more to requests that they either don’t enjoy or don’t provide a financial benefit to them. Ultimately, maintainers don’t owe you anything.

‍

‍

What's one thing you wish you had known when you got started?

Networking matters. In almost every job I’ve had, I’ve applied cold and not used existing connections to smooth the application process. Similarly, in my job searches I have not asked my network where and who they would recommend working with.

‍

‍

Many engineers struggle with setting boundaries. What advice do you have for saying “no”?

You cannot say “yes” to everything. Deciding what you say “yes” to based on the order of requests is a poor strategy; you will not manage to do everything you’ve agreed to. In turn, this disappoints people when they are expecting completion. Instead, figure out your personal and work goals and say “no” to requests that do not push them forwards. Setting boundaries will be hard at first, but the earlier and more consistently you can set them: the easier it will become to enforce them each time.

Read my full article on saying “no” here.