Reddit Reddit reviews The Goal: A Process of Ongoing Improvement

We found 7 Reddit comments about The Goal: A Process of Ongoing Improvement. Here are the top ones, ranked by their Reddit score.

Business & Money
Books
Business Management & Leadership
Business Management
The Goal: A Process of Ongoing Improvement
Check price on Amazon

7 Reddit comments about The Goal: A Process of Ongoing Improvement:

u/harryputtar · 24 pointsr/Entrepreneur

There is no one book. What you are looking for is perspectives.

My suggestion, first up: Start with The Goal: A Process of Ongoing Improvement

It is a great book for people who are currently employed, and are struggling to understand why business owners think the way they think. Also, it introduces some basic lean thinking concepts (Theory of Constraints) that are very useful regardless of whether you are trying to be an entrepreneur or not. If you plan to hire people, this should be required reading for all of them. Remember, the book was written in the last century, some culture shock is expected.

Next: I would highly recommend reading The Lean Startup. It's a bit dated now, and newer refinements are available, but every other book kind of builds upon this book.

Now you should be able to relate to whether your business idea is sound or not. Next you want to understand, how other people became successful, for this, you need to read Nir Eyal's Hooked. The book is an eye opener for how various online businesses keep making us coming back for more.

Now you are close to building your product, but maybe you need to understand if you are onto something worth selling or not? The Lean Startup will tell you to do a Smokescreen MVP or a Concierge MVP. An even better approach is defined in Sprint. This approach allows you to test business assumptions in a highly structured manner.

After all of this, hopefully, you will someday reach a stage, where you will need to go and pitch your idea to investors. Get Backed teaches you to put together a presentation for investors, and how to handle the presentation.

At the end of all of this, you might be feeling very optimistic about life and stuff, but to keep yourself grounded, read up on Ben Horowitz's The Hard Thing About Hard Things. It is one of the most humbling books you could ever read, and once in a lifetime kind of a book that is as profound as the Chicken Soup books.

u/tindalos · 7 pointsr/sysadmin

I found that I was excited and interested in technology until it got to the point of maintaining and then I'd want to move on. So I went through web design, to network admin, to system engineer, to consultant, to senior systems engineer, to IT Manager.

While my case is a little off the beaten path (I don't have a college degree, and floundered a bit back and forth through my career), I've learned a number of things - often the hard way - that eventually got me an offer of IT Manager. I'm happy with the job and love the company, but management can be an exceptionally different beast than sysadmin/engineer/etc. Even though I still handle most highly technical tasks, my job is becoming more planning, paperwork, policies, delegation and organization, interaction between departments and other managers, budgeting, research, and goals/KPI review.

If you're planning your career, you may first want to consider what type of IT Management you want to pursue. You can be a technical manager, with a focus on something like a CTO position - where you are still immersed in keeping up with technology and market factors to drive technical solutions to corporate problems. CTOs often make more money than CIOs, but may even report to them.

Traditional IT Management/Director positions move toward the CIO function - which is utilizing information technology to drive business success. A CIO is typically more management-focused, and is highly responsible for the growth and success of a company instead of just the quality and success of the technology behind it. This is where you find Digital Masters, that drive success throughout an organization (e.g., identify the opportunity to migrate the sales team to CRM, and drive orders through a separate channel, implement tracking systems to identify bottlenecks in production and push company-wide directives that increase throughput and revenue directly).

My background came from the highly technical (I was dedicated and interested, especially early on in my career, testing things in a home lab, researching stuff we weren't even using so I could see how things like Samba worked with AD). As my jobs progressed, I landed a Senior Systems Engineer contract with a local company. After working through a few successful projects, they were changing their structure and offered me an IT Manager position.

It still took about 6 months after becoming an IT Manager before I was officially part of the executive management team. It takes time for people to trust you, and on the IT side, a lot of times other managers don't have a large grasp of what you bring to the team.

So here's a few summarized things that I can provide from my perspective. I'll break them into two things I have learned:

Becoming an IT Manager:

  • Communication. This is so vital I would suggest a business communication class over ANY technical or management training. IT is complicated to us, much less others, and in management, your peers will not have time to comprehend and understand your discussion of the powershell scripts to migrate the database and implement transaction log shipping so you can have a report server. Focus on the result, the reason, and the requirements. If there's more information needed, you will be asked.

  • Become a Generalist - either direction you take into management will move you further away from specialization. Yes, it's great I had my MCITP Enterprise Messaging Administrator. I work for a company that doesn't use Exchange or Outlook 360. Certifications are a good idea, and you'll need them to validate your abilities to employers and yourself as you work through the technical side of IT and toward management. But as you raise in rank, you will need to have a larger view of the landscape to understand the direction of technology. You cannot be unaware of things like DevOps and Agile nowadays, as you couldn't be unaware of the Cloud six or seven years ago. If you're going to lead a company's technical direction, you need to be very well versed in the current state of technology.

  • HOMELAB - I can't tell you how many people in IT I talk with that don't have a home lab. When I was getting started I had a chance to talk to a lot of consultants and successful people and everytime I asked them the first thing they looked for in a (whatever) technical position was "Are they interested in this stuff? Do they live and breath technology? Do they have a home lab?". It's easy now with Digital Ocean,or a cheap dedicated server from WholesaleInternet to setup your own lab at home or not. It will help you a lot.

  • Honesty and Dedication - This field is seen by outsiders as either "magical", a "hassle", or "confusing and misunderstood". This is a fight against you from the start. It's vital to be honest ("I was working on this new server, but ran into a problem I'm trying to fix, it may be another day or two.", "I made a mistake with the DNS and it may have caused some problems for you guys connecting to the AS/400. We're aware of this and working to fix it, we will keep you posted."). And dedicated means basically, get the stuff done you can do, within the time you have or told someone. If you can't, you need to tell someone immediately. For management, it's important to gain a strong understanding of how long things take (even if this technology hasn't been created or used before), and it's a skill that takes real experience to master. Start immediately!

    I mention these things not because stuff like Project Management training, IT certifications, and specific experience in certain things are not important. However, everyone gets caught up with this training things and do not realize that you will not move into management (easily, at least), without soft skills. Communication, honesty, dedication, broad understanding of the technologies. These are the type of people that other managers are interested in working with.

    Without trying to turn this into a huge post, I'll also add some things I believe have helped me (or I'm working on) since I've moved into true IT Management:

  • Read The Goal

  • Read The Phoenix Project

  • Read It's Not Luck - Also by Eliyahu M. Goldratt of The Goal, this book focuses more on market-level insights and understanding.

  • Now, map out your company's process - how does inventory flow through your company, what is the throughput, what is the work in process, what are the line of business requirements, where are the bottlenecks, how are these things affecting operating expenses? This sounds complicated and overbearing, but you can do this even if you're helpdesk. The better you understand how the business operates, the easier it will be for you to understand the needs of the business and focus technology to support the areas that will drive the bottom line. Regardless of who you are, where you are, if you crack this, and have the soft skills necessary, you will become a successful manager.

  • I'd also suggest learning time management before you undertake project management. Something like Eat That Frog's "Do First Things First, Second Things Never" mantra works really well for IT. Learn how to prioritize your own schedule and tasks before you attempt to prioritize others.

  • Learn to delegate. This is something I struggled with for awhile (mostly self-taught, only child, apparently I trust myself to do things properly and others, not as much) - this has to change as a manager, and will likely be the early bottleneck to your success in management. I finally realized that - for me, your results will be different - if I focus on my weaknesses (I know I enjoy rolling out new solutions rather than monitoring and maintaining current systems), then I realize these areas are apt for my to delegate. If I can delegate monitoring and maintenance to a systems administrator, I just freed up my time to be used on understanding our business better and finding new solutions to larger problems. Don't delegate for delegating sake, if you don't have something for someone to work on, give them direction on how to better their career, or involve them in things you're working on, have them work with different departments to shadow some of what they deal with day-to-day, or sit in on a sales call. This way you're developing relationships and getting your department out there.

    There's a lot more, and others on this subreddit are going to be much better at providing some direction - technical stuff like DevOps is where I'm spending my time now, and any IT Manager should be focused on that first and foremost if you have a Dev staff. Budgeting isn't easy, but whether you're responsible for it or not, it's always a good time to start doing as much of this as possible simply for the real-life exercise. No one is going to be upset that you spend your unproductive time trying to figure out what the IT budget would be for your company if you were in charge, versus watching cat videos on Facebook.

    Remember that Information Technology is a SERVICE department to other business lines. As vital as this is to us, we are seen as something like "The guys that keep the phones working." When things go well, people will think we don't do anything. Only when things break, does IT become top of mind for employees or customers. You can get kudos for great successes, but an IT Manager's greatest success will be when things run smooth and no one is impeded by IT or its servers, networks, phones, or computers.
u/MrVonBuren · 5 pointsr/cscareerquestions

Have you ever read the book The Goal or it's more modern retelling The Phoenix Project? They're both essentially books about process management wrapped in a "novel". The former was written in the ~80s and is about a guy who is a plant manager at Widgetco (or something) a manufacturing company, the latter is about a guy who is Operations Manager at Gagetcorp (or whatever). Both are put in a position where they simultaneously take on way more responsibility and realize that their company has been doing things very poorly which has put them in a bad position.

I would highly recommend both because they're quick and amazing reads...but one takeaway I'll offer as advice here:

Make sure to make it very clear that PROCESS is very important to building a stable platform. Having means to check your work, adapt quickly, extend where needed, etc...stress that this is critical to build something that scales beyond a certain point (the point you're at now). Then explain that the previous person in your position didn't do a bad job, they just weren't thinking in terms of the scale that this project was going to grow to (make it clear this is common, but a serious problem). The real problem isn't that the old stuff is bad, it's that it was built in a way that couldn't be extended (and also...it's bad). The point you need to get across is that the only way to do the things he wants from where he is is to start over and build something made to grow. You can only supe up a civic so much before you're better off just buying a better car and starting from there. (I'm not good at folksy metaphors)

FWIW, I've never been a dev, I started as operations engineer turned support engineer turned sales engineer turned "Technical Account Manager" (I'm a people person!); but I do have a lot of experience telling important people what can't be done. Bottom line with technology is unless you're just bad at your job there are hard requirements to doing things well. All you can do is explain those requirements must be met, or the expectation has to be that the job won't be done well and hope your boss listens. If he does, good you made a change in the world for the better. If he doesn't disagree, commit, document[1], and move on. If you're good enough to make these kinds of suggestions, you're good enough to find another job when this gets unbearable.

[1] - document (for your on use) not just that you disagreed, but exactly how you would have implemented it. When I interview people, I often like to hear times they wanted to do something one way and didn't get to. Being able to speak well about that is a positive trait to me. (Not to give unsolicited interviewing advice)

u/calladus · 5 pointsr/jobs

Other areas of work have this too. In engineering, it is not unheard of to have no assignments between projects. Engineers use that time to play with their own ideas or take a vacation. (Play usually. Most engineers I know have about 3 months of vacation just sitting on the books and their management is yelling at them about it.)

Under the "theory of constraints" in a Production / Manufacturing environment, there is an idea to plan to have a percentage of your workforce remain idle during a certain period in order to have the excess capacity needed to meet unexpectedly large orders. In other words, if you've planned your workforce to work at maximum capacity, what do you do if your customer places a huge order?

u/spaaaaaz · 2 pointsr/Romania

Iti recomand "The Goal", de Eliyahu M. Goldratt.

E o carte scrisa ca o nuvela, dar care defapt te invata despre management si in special despre "The Theory of Constraints". E foarte tare.

u/Imitable · 1 pointr/booksuggestions
  • The Goal - Eliyahu Goldratt - you'll probably read this in an operations class, but it's one I refer to often in my day to day.
  • Moneyball - Michael Lewis - taking advantage of market inefficiencies to compete with a much smaller budget, I found it to be a business book as a baseball one.
  • Decisive - Chip and Dan Heath - not necessarily business specific, but having an approach to decision making applies to business decisions as well.
u/Triabolical_ · 1 pointr/agile

Pro tip. If you find yourself talking about "getting people on board", you are taking the wrong approach; you are thinking about how to make your life better rather than how to make the overall organization better.

I can tell you what you are going to get out of your approach:

  1. You will get resistance from the people proposing features because you are asking them to do extra work to make your life easier. Whether you get agreement or not is going to depend on the politics of the situation.
  2. You will see a wide variance in the quality of the descriptions that you get, because a) the customers don't really know what they want and b) they aren't very skilled at expressing what they want.
  3. You will get proposals with details that contradict the expressed direction that you want to take the product, details that are don't make sense, and details that violate known laws of physics.
  4. The details you get will age poorly; they will refer to other feature that got cut or that got changed significantly during design.
  5. Some of these features will get cut.
  6. Even if you get perfect details, they will be insufficient for the dev team to go off and do the implementation, and you'll need to talk with the requester anyway.

    I see two big violation of agile principles in what you are proposing:

  • We want to minimize the amount of work in progress that we have. All of those details are work in progress, and much of that work will be thrown away.
  • We value individuals and interactions over processes and tools.

    A relevant definition here: "A user story is a promise to have a conversation". When you pull that request as something you are going to work on soon/right now, that's a perfect time to have a conversation between the development team and the user who requested the feature. In an hour you can discover the majority of the details that you need to do the implementation, and it's efficient both for your time and for the user's time.

    > Lastly, I'm really curious as to how people are valuating the value and cost of a task. How do we, as a development team, map out the technical cost of a feature and how should we ask the business to map out the value of getting a requested feature?

    This question comes up often, and here's how I like to think about it...

    For a given set of feature requests, there is an ordering that maximizes the benefit and minimizes the cost. You can probably come pretty close to determining that ordering for the top 25 items if you take the 15 people involved and lock them in a conference room for a week, so that is obviously the optimal approach, right?

    Having once spent 3 weeks of my life costing in a room costing and ordering a multi-year backlog, I can assure you the answer is "no".

    The problem is that an important question is missed, and that question is, "what is the opportunity cost of having long discussions about the exact ordering?"

    Given that such discussions typically involve senior stakeholders and they all have much better things to do with their time, the opportunity cost is high.

    What you should do is ask the requesters to bucket the requests into low/medium/high value, and you should do a really quick sizing estimate of small/medium/large/extra large for implementation effort. Then you just do a simple sort, and the list will be fine in most cases, and all you have to do is discuss where it isn't, move a few things down, and you're done.


    I agree strongly that you need an agile coach; not only to help you with these things but to help have some of the conversations you need to be having across the organization. I also highly recommend a couple of books to you:

    Ron Jeffries has a nice book called, "the Nature of Software Development", which is a great short introduction about agile development. It's short enough that you can hand it around to people.

    "The Phoenix Project" is a book about apply a lean technique called "The theory of constraints" to software. It's a novel and a pretty quick read, and the reason I recommend it is that it takes a "whole organization" perspective rather than focusing in on the dev team. It is essentially an adaption/rewrite of a lean classic called "The Goal".