As an organization scales and grows, the layers through which decision making is required inevitable increase. Now, that doesn't mean you have to accept this. You have found yourself in an opportune place where you can have impact and reduce some of the overhead. BUT, be warned, you can never fully eliminate overhead. That is the cost of growth and BigCo status.
One of the interesting challenges for engineering teams is dealing with the vast amount of artifacts (meeting minutes, design docs, engineering 6pagers, reference docs etc) that get created. Here is one way to manage that information flow.
- Give users integrations that are beautiful with uncompromising functionality.
- Create Integration Wizard, embed them in app, or roll out an entire marketplace.
- No-code tools to build any workflow and low-code tools to scale and connect to any app.
My biggest bone is exactly as you point out, how quickly or how large is our bug pile never reflects the end outcome. Numbers can be skewed and the really smart leaders dig deeper and only use the numbers as a indicator never the diagnoses. Your tool looks freaking interesting. Really cool.
This is a really great rule of thumb. This stems from managers wanting to play an "active" role in solution because they have been asked to "lead". It sucks. When you are brainstorming you need meetings but if you push it to thousands of people, it's just the jungle and no productivity.
I’m on a quest to learn Figma in and out and for me building things I need or want to use helps me learn better. So, here is an enhanced PERT chart file that you can duplicate and try out in Figma yourself. It’s a work in progress, great for visual presentation, slide decks, or plain mapping out requirements. Love feedback and I plan to continue to add more and eventually make my way to a plug-in. Enjoy.
I have toyed with providing a confidence indicator with each date but % or these average numbers are rife for interpretation. What has worked for me is highlight the eta then state the hard facts - these dates are based on the following assumptions and here are the potential risks that will push these dates out. But as codingdave says, you choose when to deliver or what we deliver - basic constraint theory (cost, scope, time)
I am focusing more on building things with tools I have never used before. Constantly retrospecting my choices in professional and personal life to find ways to do things better. Also the usual - reading books, blogs, following better and smarter people on Twitter. I avoid LinkedIn... it's just an echo chamber on high-fives now.
Good for you. Small meetings and breakout sessions are more effective than absurd BFM :).
What is your ideal small size meeting, hypothetically speaking, or when does it become a crowd?
Hmm, I will put this on my list of the worst piece of nonsense written to date. Not gonna lie, feeling mighty embarrassed right now. But, learning opportunity as this is probably the most honest feedback I have ever read. Much work to do still. I am genuinely intrigued - what is the right explanation for shared consciousness in business context?
Everyone hates them; they often are poorly run. But, in a complex, interconnected, and now remote world - I believe we need more bigger meetings not less. Just hear me out...