- Great early stage engineers will instead highlight the different options and the resulting tradeoffs to force the stakeholder to make the business priority more clear. The best engineers will also make a proposal for the best answer and suggest it directly.
“I could stand up our own quick system in a couple days, but we know we’re going to need auth no matter what we do. I don’t think it’s worth signing a contract to get enterprise Okta because I’ve heard it’s a huge pain to integrate and we don’t have enterprise grade users yet. Since our users are developers, I do think we should do social auth with Github, and that will take a little longer, but be more robust and expose us to fewer issues. I suggest we invest about a week to do that.” Ideally this type of framing won’t take too long. It isn’t meant to be a perfect assessment of how long, it’s to highlight the important tradeoffs between opt View Highlight 2023-04-29
This will help you, but more importantly other engineers who aren’t good at framing like this! It also prevents doing work beyond what the project needed, and protects against rework.
This naturally falls out of “focus on what won’t change,” but on a longer time scale. Most things in an early stage company do change
The user experiences might likely change. So what are the core model capabilities?Try Order of Magnitude Timeboxing No matter what you’re proposing to build, at some point along the line ask yourself “what if I had to do it in an order of magnitude less time?”
Model iteration often expands to fill available time. Applying order-of-magnitude timeboxing to model development forces a useful question: if iteration time were compressed drastically, which changes would actually matter?On the other hand, something was supposed to take a week and a month later is still “almost done”? Dig in! I feel like nearly every engineering team I’ve worked with has had some of these. It could be the project was badly understood, there is a lot more debt in that part of the codebase than anyone thought, or the skills of the engineer weren’t matched to the project. Everyone just gets used to “oh yup that’s still going” without realizing that if every project looked this way the company would be 4x+ slower. Spend the time on the big gaps, not the days here or there.
Similar to “debug never-ending tasks” you should also “debug never-ending reviews.” If reviews don’t get eyes on them quickly, there are too many rounds of comments back and forth, or something has been up for a long time without progress, figure out why.
It’s often a case of everyone being heard and sharing root information, not finding the right answer to the technical challenge at hand. Figuring out the hot button issues is important
sometimes a talented engineer have a deeply held belief that goes counter to what the team decides is their philosophy
