14 ms·
Engineers should invest in decision-making skills early
- giantg2 5y agoI have the opposite. I focus on the why. I like strategy vs just executing. My career is in a downward spiral.
- sadadar 5y agoAs a software engineer I think you need a good balance of both. Strategy that never sees the light of day isn’t that good. Part of the great joy of the art of being a software engineer is putting your stuff out into the world and showing it.
- giantg2 5y agoUnless you're a senior tech lead or higher, your advice/strategy will be ignored. That's been my experience. I'm just a worthless mid-level.
- balaji1 5y agoOne way to establish that expertise would be to execute and show the others that your advise/strategy is good. For that I think we have to execute fast. So we can build first, ask permission later. And if you build fast enough, then others won't question you as much. But tbh I have had only reasonable success this way and you have to be ok with pushback. And gets is harder if others around you make it a point to pushback - instead of seeing if your solution solves the problem and letting you own the solution for a period of time.
- giantg2 5y agoAlready tried that. I'm just coasting now. Merit gets you nowhere anymore. https://news.ycombinator.com/item?id=29719137 https://news.ycombinator.com/item?id=29719137
- balaji1 5y agoCoasting is fine. Right? Dunno if you are bay area. The blog article is mostly about SF, but his points about work culture might apply to the broader bay area. Maybe issues like safety and cleanliness are better in other parts. Practically, for younger folks, "American dream" has to be realized in the big cities and they all probably have a similar story to SF. Weren't tech companies historically in the San Jose area ie "Silicon Valley"? SF is relatively new on the "tech" scene. Also the blog author's moving to Miami, he's gonna coast at the beach.
- giantg2 5y agoNot in that area. Other than the safety and cleanliness the rest is pretty universal. Merit, hard work, etc has gotten be no where. I make under $100k and support a family. Coasting is not good in this situation, but I don't have any good options.
- balaji1 5y agoI feel you. Thoughts on getting another gig or contract work? There seems to be plenty of software work that can be done remotely. Maybe you can coast thru 2 jobs.
- giantg2 5y agoNah, I'll just do one. There are about 3-4 hours of meeting most days. If km going to go through that kind of stress or juggling, then I might as well try to find a good job.
- robertlagrant 5y agoI'm about a quarter of the way in, and this seems a pretty transparent "this is the contrived problem where engineers are basically idiots, and assuming that's always true, here's our solution." Most engineers I know are not idiots, and discussions would stay well away from personal attacks. Additionally, while they generally can identify wider issues, they also need to solve the current issue as a "strategic" solution is much more likely to become a talking shop or a "strategic"-level solution involving the spending of lots of budget, the purchase of something useless and then blaming the engineers when it doesn't work.
- sadadar 5y agoI feel like we have phrases in software like bikeshedding particularly because these sorts of problems are common in teams. It’s not about being idiots it’s about software being more art than science and these things just being hard and people wanting to treat it more like science than art.
- robertlagrant 5y agoWhat are the phrases like bikeshedding you're referring to? Who are "people" in your post? Which sorts of problems?
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- reidjs 5y agoThis is an advice article for engineers written by two people who are not engineers. That's not necessarily bad, it's good to have outside perspective. But I didn't find the article particularly helpful. It makes some strange, vague analogies to watersheds and doesn't give much actionable advice. This article feels like an advertisement for this company's workshops or seminars.
- znpy 5y agoHi, I'm calling BS on your reply. One of the authors (Karen Sun) is the CTO of a tech company. Also I had the chance of working with her (for her, really) and I can tell you that A) she's definitely an engineer and B) she knows her way around code and stuff.
- reidjs 5y agoI'm sure she's very intelligent and is probably great at coding. All I meant by that comment is that she is not currently a software engineer by title, she is a CTO, and the stuff mentioned in the article may be more relevant to founders/CTOs.
- database_lost 5y agoSorry, but being an engineer is different than knowing your way around "code and stuff". Being an engineer is also different than being a computer scientist or programmer. The authors studied arts and mathematics, but that didn't stop them from starting the post by making it look like its written by engineers: "Early in our careers as engineers, we’re told to invest in technical skills."
- MattGaiser 5y agoThe links of the author names go to LinkedIn and Karen Sun is definitely technical. Heavily founder type technical so I suspect that skews the advice in that direction, but still.
- pxeger1 5y agoYeah, I think[?] I agree with the point this is making, but the watershed "analogy" is quite a stretch. This article is not very well-written. ...and I'm not even sure if I agree, because it's quite hard to extract the actual point
- photochemsyn 5y ago> "Each person leads with their beliefs and emotions. . ." This is a common problem but there's something I'd call the Feynman solution, as he describes it in several of his lectures (New Zealand QED lecture I think). It's probably applicable to engineering problems as well as to scientific research. Basically, you have to train yourself not to be emotionally tied to a particular outcome. In Feynman's case, he was talking about scientific theories about the nature of the universe, in the context of a question about whether he 'liked' quantum theory or not. As he put it, you don't get to tell nature how to behave, if you want to understand nature you're going to have to accept that some cherished theory or other that you wanted to be true is going to end up in the garbage bin of failed notions. A corollary is, have something else to get emotionally involved in, family, art, music, etc. It seems the same with engineering of all sorts. Love that brilliant code you wrote, love that language you've spent all that time learning, love that system you spent a decade building, love those architectural blueprints you slaved over for six months? If it doesn't work for the problem at hand, it's best to toss it out the window and try something else, and getting emotional about it is a mistake. Equivalently, tossing something that works just because you have antipathy towards it for some reason is not the way to go. Otherwise you end up like all those physicists who hated quantum mechanics so much that they either quit physics or spent decades of effort on futile attempts to refute it.
- 3a2d29 5y agoI had no idea there was physicists that quit the field. Does anyone know any articles or anything on this? Sounds interesting to read what their thoughts were.
- chillfox 5y agoPeople quit all sorts of things all the time. Why would physic’s be any different?
- jfoutz 5y agoI'm by no means a physics historian. I'm pretty sure quantum physics pissed off Einstein so much he spent the rest of his career trying to refute it. "God does not play dice with the universe". I'm just some jackass on the internet, so I'll leave it to Hawking to talk about emotional attachment to determinism https://www.hawking.org.uk/in-words/lectures/does-god-play-dice https://www.hawking.org.uk/in-words/lectures/does-god-play-d...
- throwawaysleep 5y agoA lot of this advice has to do with what role you play in a company. As a mid-level IC engineer, especially as one prone to moving companies, I have no strategic role. Frankly, I will not be at the company long enough to have a strategic impact as I will have left in a few months. Solutioning keeps the day to day moving. It won't be my problem 10 months from now. And with the endless churn on dev teams, you can't build a stable enough team to get beyond that. I wait to serve on a team that has less than a 50% replacement rate in a year.
- abhinai 5y agoAlways been like that? Never been on a good team?
- throwawaysleep 5y agoI have never been in a company that will give out raises, nor one with meaningful equity grants (we get equity, but it was 3K at my last company or nothing to deter switching jobs). So everyone (myself included) switches companies annually. In 2.5 years, I have had 6 (soon to be 7) different managers across three companies. Lots of smart people involved and great to work with, but the incentives of this industry are for short fast tenures.
- giantg2 5y agoI've been at one company for ten years. I've had 15 managers.
- giantg2 5y agoWhat is a "good team"?
- twblalock 5y agoA team where your manager takes an active interest in your career growth, protects the team from bullshit, and expects the same behavior from his/her manager.
- balaji1 5y agoEngineers should avoid pursuing the perfect, most-generic, elegant solution. Spending too much time to decide the best tools, the right design pattern, etc. Coding is a lightweight process (compared to other forms of engineering). So it is easy to go back and rebuild and upgrade, which will be required in any case. But of course watch if the need to redesign/rebuild becomes a pattern. Then invest more time up ahead. But most times, a decent engineer is able to get to a fairly accurate and good solution.
- giantg2 5y agoI think this comment might fit what they are talking about - this is all tech concerns and has nothing to do with the why.
- deleted 5y ago[deleted]
- ZephyrBlu 5y agoThis is interesting because it's what I suspect happens (Too much focus on execution creates skill/career stagnation), but I'm too early in my career to know for sure.
- vp8989 5y agoIt depends what your career goals are. Repeated execution of non-trivial things in different contexts builds your engineering sense and intuition. Amazon has a quote, "there is no compression algorithm for experience". People who fast track that step too much are not on a stable footing. You can probably sometimes get away with it, which is why we see the kind of "thought leadering" shared in the OP ... but I'll say that I'm "only" ~10 years in to my career and I've already seen quite a few instances of VP+ people who bet the farm on some nonsense and end up flaming out.
- rramadass 5y agoNo, don't bother with the article; it's "Not even Wrong". Read and Follow this instead: "Speech given by Dave Packard to HP Managers" - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-our-company-5634378 https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... (they founded Silicon Valley).
- joeman1000 5y ago> “An over reliance on solutioning” Why the hell are software articles inundated with these non-words? The proper word is SOLVING!
- krallja 5y agoSolutioning means “inventing potential solutions,” not actually solving things.
- lodovic 5y agoI don't think "solutioning" is a real verb though, it would have been clearer and easier to read if "inventing potential solutions" was used.
- tapan_jk 5y agoAlso, overuse of analogies. Maybe it's just me but I am more convinced by a narrative that avoids or sparingly uses analogies.
- wombatmobile 5y ago> Crisply articulate and build alignment around your decision-making criteria Corporate-speak like that is a recipe for bad outcomes. What engineers need to learn is the same thing corporations need to learn but avoid - plain speaking. See the Challenger O-ring disaster history for a case study.
- Forge36 5y agoIt could just as easily be "establish the priorities." There's different balances and tradeoffs depending on what's considered the top priority. Or am I misunderstanding what this means when plainly spoken?
- deleted 5y ago[deleted]
- bmeski 5y agoThe goal could be something as simple as, “design a search page.” Product/bizfuck person will re-think autocomplete, client-side rendering of results, want categories of results that don’t exist in the data, dynamism for each user that can’t exist given the data. Developer wants to build search page like every other one so that we can get to market faster and move onto something that will actually affect the business. Everyone has different priorities but the engineers are usually based in reality as we have to actually make the f’ing thing.
- deleted 5y ago[deleted]
- jjoonathan 5y agoIndividual contributors don't avoid strategy out of stupidity, we do it out of respect for the person whose job it is. Strategy is the ultimate bikeshed: the prerequisites for having an opinion are very low, so everyone has one. Don't mistake avoidance of scapegoat duty for not having an opinion. Everyone has an opinion. Unfortunately, the evidence never unambiguously points to a single course of action and paying everyone to daydream and argue about the big picture is wildly inefficient, so the key to getting anything done is to delegate the decisions to a single person per team, give them time to cultivate big picture knowledge and political connections, and then to respect those decisions even if you privately disagree. It would be awfully nice if that respect were reciprocated, but this article is an exercise in the polar opposite: it's a declaration that "management rules, labor drools," complete with a childish "descent into failure" diagram. Don't make the mistake of actually getting things done! You might out yourself as a stinky engineer and NEVER make it up into management! Mind the Peter Principle! Maybe next week they can blogspam on how management compensation is about leveraged value creation, not Rules for Rulers.
- say_it_as_it_is 5y agoyou clearly were not swayed by the watershed metaphor
- sadadar 5y agoStrategic thinking isn’t just the generative idea creation of a “strategy”. It’s also about savvy execution within a strategic context. In every project a thousand decisions are made by “drooling labor” and the better each of those decisions ladders up to the strategy the more meaningful the impact of the work. Watching people proclaim no impact on strategy but thinking they deserve tons of credit for their code is a failure mode I’ve seen with engineers. Watching people get frustrated not being promoted when “idiot peers” get credit was often more about their own idiocy. Don’t dismiss the impact you have in every role, it’ll hurt your career and the actual impact you have.
- jjoonathan 5y agoOh, absolutely. On both counts: strategic decisions that have been delegated to you are important to get right, and relentless self-promotion is the single most important skill inside and outside of any workplace. It's also important to recognize it for what it is, though, and TFA, well, is what it is.
- el_ravager 5y agoScience devoid of philosophy is merely politics.
- mybrid 5y agoAgile is much, much, less complicated paradigm and it has been turned into some Frankenstein of borrowed past processes at every company I've ever worked at. I can only imagine what would happen to this watershed model if it became popular.
- rramadass 5y ago>this watershed model if it became popular Please God, No! :-) Let it disappear along with this article.
- grouphugs 5y ago
- pcurve 5y agoThis article is really hard to read and follow. Yet, there really isn't new insight (much of which I agree with) being presented here that I haven't seen elsewhere. Also, I'm curious to see what everyone thinks of the "Examples of Decision by Role" RACI chart. How realistic is it? I don't expect the Junior IC to be making any of those decisions the authors wrote.
- david38 5y agoIn my experience, engineers are mostly told “make this” and denied the opportunity to exercise broader strategy decision making skills. It’s “don’t worry your pretty little head”, “we need you spending time on this, not wasting it on that”, “you don’t have all the information”, “the best way to help is to be heads-down programming and let us do our job of strategy”. All ways to keep you in your place. Fast forward ten years, and is it really surprising that a perfectly capable engineer wouldn’t succeed on the first shot? Funny thing, give him six months of practice (often the current strategy people had far more) and surprise, he’s perfectly competent!
- rramadass 5y agoRight you are! Bjarne Stroustrup - An Organisation that treats its Programmers as morons will soon have Programmers that are willing and able to act like morons only. Note also that most successful Tech. Companies were Started/Managed/Grown by "Engineers" rather than MBA types (who just come in later to claim the glory :-)
- stainforth 5y agoThere are also implications as to whose names should be on the ownership paperwork if everyone is all participating at a high level, which should be a constant reminder as to where the power is and is kept.
- ngc248 5y agoIt is tthe agile mindset also which is contributing to the problem. Agile should only be used while executing, when you know all the requirements and just need to execute. Agile should not be used for R&D or when you are trying to come up woth a new thing. Of course time bound it, but it cannot be broken down intto user stories or whatnot. Agile is taking all the fun out of software development. Turning engineers into software factory workers.
- quickthrower2 5y agoMy biggest bugbear is higher ups don’t take gut feeling from people who have done engineering for decades seriously and so undermine their strategy with assumptions that could be corrected if they listened downward. It’s a trope: the company that turned from the brink when management listened to staff, perhaps cutting out middle management as a comms layer, but its never been my experience that anyone wants to do that. They’ll hear you but listen and take seriously? How many companies deny tech debt paydown but then have people working on badly researched feature ideas that add no value to the business.
- chandmk 5y agoTry strategizing in a mid-sized non technical mid-sized company. Here is where engineers are treated like mechanics at pep boys. You are either ignored or put to your place about the kind of work your are supposed to do, with the exception of crisis scenarios or 'no-one is interested in the outcome' scenarios. In large companies strategy is mostly about helping power brokers to do their bullshit jobs. In my experience, only opportunity for engineers to contribute to a meaningful strategy is in a small team with business person as CEO/Owner and they really want to listen to the engineer's opinion. Maybe in tech companies engineers might have different experience.
- twblalock 5y ago> Maybe in tech companies engineers might have different experience. Of course they do! At non-tech companies, tech is a cost center. The only strategy that will be valued is a strategy to cut costs. At tech companies, tech is the product, so it's a profit center. If you want a fulfilling career as an engineer, don't work in a cost center. > In my experience, only opportunity for engineers to contribute to a meaningful strategy is in a small team with business person as CEO/Owner and they really want to listen to the engineer's opinion. That might be true at very small companies. At large tech companies most engineers will never meet the CEO, but they still have input on strategy. Of course that means developing some credibility and trust within the organization before people will listen, but that's true in all industries.
- Aeolun 5y ago> If you want a fulfilling career as an engineer, don't work in a cost center. You can definitely still have a fulfilling career. Somewhere along the ladder the right CTO or VP can make all the difference in how that branch of the organisation operates (and lo and behold, somehow that branch is particularly effective too).
- chandmk 5y ago>If you want a fulfilling career as an engineer, don't work in a cost center. By that definition, I guess the above article is not a help to a whole class of engineers out there. Now I really doubt if they even be called engineers?
- Barrin92 5y agoall the management speak and analogies about watersheds aside which I think obfuscate more than illuminate I think one fundamental problem with this sort of thinking is that it has a wrong opinion on why some people favour execution type mentalities. It's not, at least most of the time, because people are unwilling to ask 'why', it's because in a lot of cases there is no neat strategizing step, disconnected and well ordered from what is actually going on in reality. In a large organization, things move all the time. There is uncertainty about who is where and doing what, you can plan something and when you're finished someone has already done something, there is imperfect information, and so on. So if you want to strategize you first need to create time and resources to do so. It's the problem with all kind of grand strategy mentalities. What to do isn't clear most of the time, there is no guarantee to figure it out ahead of time, and things are asynchronous and not ordered. Executing quickly can be wasteful but it recognizes the real-time aspect of making decisions.
- refurb 5y agoI got good career advice a while ago that the longer I work the more it makes sense. If you're interested in expanding beyond a specialist (or just further your specialist experience), there are 3 main areas of business you should get experience in (note - I didn't say "learn"). Those are: - strategy roles - these can vary, but it's really about making decisions on what direction a company should go - operations/execution roles - actually putting a strategy into practice - this is where a lot of CS folks sit - customer facing roles - doesn't have to be sales, but just some contact with customers The reason I've found this to be a good approach is they are all mutually supporting roles. You can't be an outstanding strategy person if you've never executed (I know I vastly underestimate the effort involved), and you can't be a good technical person with getting close to the customer. You don't have to love each role and it doesn't have to do it for long - even a 6 month internal rotation can help. But I think it does make you a better generalist (if that's what you want) because you start understanding your role from the bigger picture.
- trabant00 5y agoYes! My life would be so much better if my juniors would practice more strategic decision-making and help me understand how it can all be fixed if we moved to 10k micro-services in kubernetes. We should all be leaders. Organizations would be so much more efficient. Stop wasting time on developing actual hard skills. That is soooo boooooring. Skip right up to being a CTO like me! But how do you actually implement all that? You like the sound of it, you want it in you life, but where do you actually start? Good thing you asked: just buy our "cohort-based program"! We will teach you how to be a better engineer from our actual experience of never being one! --- Let the second coming of dot-com crash wash away with a great flood this putrid decadence so we can rebuild anew.
- Apocryphon 5y agoIf you think things look bad now, whatever is rebuilt in the aftermath of another crash will make the present look like a utopia.
- trabant00 5y agoYou really think so? Why? From what I know every other industry matured through a series of crysis. Al least that is the way I see it.
- Apocryphon 5y agoToo much dumb money invested and the worst, full of passionate intensity, will return to reanimate the bones.
- WJW 5y agoAhhhh the utopian thought of an apocalypse in which all the entrenched interests (but not us engineers!) will magically disappear, after which we can rebuild in peace without all these concerns of 'backwards compatibility' and the demands of 'other stakeholders'. Let the second coming of the dot-com crash bring salvation to us all :)
- 5y ago
- didibus 5y agoThe how is incredibly relevant when it comes to software engineering. If it doesn't matter, you don't have a real engineering problem. Why and what are important, but they are limited in possibility by the how. How can sometimes allow people to rethink what they want, because they didn't even know they could have it. The why might not have existed before the how, think cryptocurrency, lots of people have why's and what about it now, but it all started from a how. How is the equivalent of technological innovation and progress, that is a big enabler for opportunity in rethinking what and why. This is why I much prefer executive leaders who have a good understanding of how, and might even have been an engineer themselves, because they can think through simulatanously about why, what and how in tandem.
- rramadass 5y ago>Why and What are important, but they are limited in possibility by the How Very well said! This is why we do trial-and-error, proof-of-concept, prototyping etc. In general, you have to play with the "How" a little bit before the "Why" and "What" become clearer and you can nail them down as actual "Requirements". All three are interlinked and cannot be looked at in isolation.
- justjico 5y agoFor anyone interested in learning more about strategy, I highly recommend Richard Rumelt’s book “Good strategy, bad strategy”. This link provides a good summary of the book: https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/the-perils-of-bad-strategy https://www.mckinsey.com/business-functions/strategy-and-cor... I often see the word “Strategy” thrown around, often referring to meaningless corporate speak or fluff. In fact, it’s a whole field of study, and I feel many engineers will love it if they gave it a chance. In order to develop a strategy you must have a challenge or hard problem to solve. Then you define a cohesive set of actions or policies backed by an argument to solve the challenge. Strategy should define the “how” to solve the problem by clearly articulating the hard choices you have to make. “Increase customer value”, or revenue or profits, those are not strategies. Being the best, or “leading”. Those are goals or wishes. Defining how to achieve that, given a whole set of constraints, that’s the heart of strategy. And engineers are generally great at solving those type of complex puzzles. The solution is not one that may involve code or even engineering in general, but rather, a clear understanding of the problem, its constraints, and the argument for choosing some specific set of trade-offs.
- usrbinbash 5y ago>The solution is not one that may involve code or even engineering in general, but rather, a clear understanding of the problem, its constraints Problem is: The only way to really understand a problem in engineering, is trying to engineer a solution for it.
- justjico 5y agoAgreed. But the problem itself may not really be an engineering problem, and therefore a potential solution may exist outside. I agree though, particularly in tech, the tendency is for great leaders to be deeply knowledgeable on engineering details because that is a requirement for a good strategy. Nonetheless, in a broader sense, defining success for a business can create a solution space that extends well beyond engineering.
- 5y ago
- deleted 5y ago[deleted]
- bcrosby95 5y agoThis reads as mildly offensive. It isn't that people don't know of the myriad of "whats and whys". It's that they're resigned to not having any say in the matter. It makes me wonder if they applied their own framework to this particular problem.
- cpach 5y agoUpvoted because of the interest discussion.
- mattlondon 5y agoIn my experience the issue is that teams don't have influence beyond their team or sister teams. "We got paged last night because of unexpected problem in System X and an associated config change in System Y meant our transitive dependency System Z did something we weren't expecting so our service went down." Ok fine but what can we fix? You can "strategize" as much as you like to fix the wider problem, but is that inside your team's sphere of influence? If your strategy requires addressing the root-cause why, but that means you have to go change/replace other team's infrastructure/operational practices/etc ("we should change System X to use k8s, and then System Z is obsolete and we can refactor System Y to use NoSQL instead of poatgres then we will have solved the why"), it is unlikely to be something that is decided in your small team in reaction to a page. TL;Dr - Your team of 5 or 6 is not the correct group to decide the overall strategy for changing your entire company's technical architecture.
- wiz21c 5y agoFTA : "Realigning as necessary as you learn new things" ah ah ah. It basically means you made what you think is a very good decision, it actually is pretty good indeed, but somehow it doesn't align with your own management's goals (those who decide for you). For example: you decided to build a good solution for the customer, that will avoid many issues in the futures but your managemetn says that you must have a positive cash flow right now; not in the future. So you have to realign. For me the issue is not about making good decisions. Anybody can make good decision provided he/she looks past the solution-oriented mind set. The skill that you need to develop is : defend your decision in front of people who actually totally disagree with you and have ways to make your life miserable if you go with your decision anyway. I understand somle people can do that, I sure can't.
- ChrisMarshallNY 5y agoOne of the nice things that has come out of being forced into early retirement (from a management role), is returning to my roots as a "sharp point" engineer; creating software, via compilers, linkers, testing, and delivery. I have been a strategist since my very first engineering project, in 1987 (I can prove it, because I still have the manual). I've written software infrastructure that lasts decades, and I believe that a long-term, holistic, strategic approach is how I got there. Here's an example of one open-source project that I started[0], and that is now a world standard (but has been taken over and extended by a new team. I can't take credit for some of the awesome stuff they have done). You'll note that a strategic approach generally involves a great deal of compromise. But I really like crafting software that individual people (as opposed to institutions, or other programs) use. My software does tend to be somewhat more ambitious than your run-of-the-mill software project, but it is still the kind of thing that lots of "Big Software" folks like to sneer at. Sneer away, if that makes you feel good. People seem to like the stuff I write, and that makes me feel good. [0] https://littlegreenviper.com/miscellany/bmlt/ https://littlegreenviper.com/miscellany/bmlt/
- andrewingram 5y agoIn most startups I’ve worked at, the engineers have for the most part been the ones yearning to work on more sustainable strategic solutions to problems, but it’s the pressure from the rest of the business to ship ASAP that forces everyone into a tactical execution mode. There’s always been an emphasis on the numbers that need to go up, in order to make the fundraising deck look good so that the company can keep existing; whilst focusing on the long term can often temporarily have a negative impact on numbers (or at least stall them), such that those accountable for those numbers will never sign off on it. Yet these companies ended up as unicorns, so they’re at least doing _something_ right.
- marcos100 5y agoIt's better to have a business with profits and things to fix up than having no business. It's a tradeoff that has been proved to be valid. As an engineer, it's hard leave some things half baked, but it is what it is.
- twobitshifter 5y agoSomething wrong that I’ve done in my own career was to become the principal expert in company/industry specific technical details. My philosophy in education was always to steer to general engineering and business because of its wide applicability and my desire to understand the complete operation, and work at an executive level. Now I find myself with career ambitions that are seen as a negative at my current employer. They would find it difficult to replace my technical skills, so they prefer to keep me in my current role - where I’m most valuable. The thing that isn’t discussed in the article is that the most valuable employees are usually those making the technical contributions and housing the knowledge, which is why managers don’t want to move them. Unfortunately in business these employees are not compensated for their fair value or promoted because the management layers have their own incentives to find the best contributors possible at the lowest possible cost. In my case by doing the natural thing and learning all the details of my position and producing high quality work, I’ve made management hesitant to change my role.
- deleted 5y ago[deleted]
- natureboy21 5y agoWhole heartedly agree. One metaphor I love is that a Ford Focus wins the race against a Ferrari every time if the Ford Focus has a better navigation system. If my goal is to go 1 mile due north but my compass points me due south I'm gonna spend all my time going around the whole globe. Prudence makes you more successful and your life easier. Say what you will about his snake oiliness but I got that from Tai Lopez and he's right. Prudence is a key skill and may trump almost every other skill.
- rcgorton 5y ago