Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Cut yourself some slack!

swatts
Active Participant

Hello Would-be slackers,

I used to work really hard! 80 hours a week, all brain time, my mind would be busy (felt fast and noisy in my head). I was amazingly productive for a while, until I wasn't! I was also "productive", I wasn't very creative, I had no spare capacity for that.

I think this is what a lot of employees demand of their staff, it's a taught behaviour from school, college and university ....... and LinkedIn....

 

So in LinkedIn fashion here's my morning regime (for public consumption)

 

5:30 am for an ice shower

5:45 10k run, I like to use this time to listen to business or self-help podcasts

6:00 another ice shower and time for 30 minutes of meditation

6:15 start work

8:00 I eat a raw rabbit that I hunted during my run

8:15 work

9:00 interact with family (these times are so important to me)

9:02 work

12:30 Lunch and 150 crunches, I like to call it Lunch n Crunch, sometimes I like to Brunch and Crunch too. But never Brunch and Lunch!

13:00 work

18:00 tea (English for dinner)

18:30 Interact with family

18:32 work

2am journal

3:am bed, where I only dream of the successes I've had

 

Obviously that's nonsense...

 

I get up at 8, work until I'm bored or hungry, finish work at 5 and interact with my family a lot. The reason why is because the LinkedIn work-ethic will kill you and your ability to think... and thinking is actually important.

 

Ideas and the pursuit of ideas come from a quiet brain and time to execute.

 

I've written about it before, but if you allow your brain to run too hot for too long, there will be a reaction. And it can be life-changing.

 

But there are also sound business reasons to cut yourself and people who work with you some slack.... 

 

I have a theory on business management …

If you deliberately understaff a job, the assigned staff will work harder to achieve the tasks (because people like to complete their tasks). So there is a policy to deliberately understaff roles to the point of having zero spare capacity. Our management therefore, has achieved 100% efficiency, what a brilliant manager!

 

I spent a lot of time in production management and in my work life trying to achieve this ridiculous goal. 

 

To counter this here's some fairly candid, internal SSDC numbers - (illustration only, our rates are going up!)

 

If we earnt our standard hourly rate for 48 weeks of the year and 40 hours a week we would earn..

 

Based on an hourly rate of $100/hour and firm fixed price work.

 

2 people x 48 x 40 x 100 = $384,000 a year.

 

Let's compare that to our recent average earnings for the last 3 years - $224000 (before tax and expenses)

 

Our efficiency is therefore 224/384 = 58%

 

This number is important, you can view it as being terribly inefficient. But we're under no illusion that what we charge is what we earn. And that is because we spend 42% of our time on ourselves and our customers. We can afford free support, we can investigate new technologies, we have time to strategize. Currently our customer base is 100% returning customers and we're not actively looking for new customers and this can be attributed to our inefficiency.

 

Our inefficiency also allows us to run our business without much boring logging of hours, we can view a project as a thing that needs completion, not some hours that need to be kept to. This makes it a far happier process and fits with our way of working nicely. It also allows us to cut our customers some slack, we have never gone back to a customer to renegotiate an agreed price in all the years I've been doing this.

 

Obviously, this is only a sample of 1 (SSDC) and specifically about a partnership with experience people, but I have talked to other Partners that have a similar customer retention rate and their efficiency rate is remarkably similar.

 

Anyways cut yourself some slack, that spare capacity is important

 

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
Thoric
Trusted Enthusiast

I feel freed. Thanks for adding value to the 'inefficiencies' for which one can so readily punish themselves.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Taggart
Active Participant

You should always build some slack into the system.

 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
joerg.hampel
Active Participant

I can confirm that slacking seems to work, as our numbers are similar. We have an "efficiency" rate - ratio of billable time vs. total time - of just above 60%, and the vast majority of our work comes from happy longterm customers.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

mbremer
Member

Been think about this recently. Watch this video where he talks about crunch culture in the game development industry. Seems a lot crazier than what I'm going through right now, but definitely parallels my experiences.

swatts
Active Participant

What a great video, sums up my rage nicely when I see people coerced into this behaviour.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Intaris
Proven Zealot

My son (who is now 18) has gotten big into fitness and building muscle.

 

One of the biggest things he has had to learn is respecting recovery time. Over-training a muscle can have disastrous results, injury, inflammation, you name it. He has learned to "take time" to relax. Sleep. Nowadays, people have come to realise that sleep is one of the most important parts of training. After that comes diet. Everyone thinks "lifting heavy" or "time at the gym" is on top spot. It isn't. It's maybe at position 3 or 4 on the list.

 

There's a lot going on in our bodies (and our lives) that needs to be respected, recovery is incredibly important because results are obtained over long periods, not short intervals. Patience and discipline are key. And contrary to what many say, discipline includes LEARNING TO SLOW DOWN. As counter-intuitive as it initially feels (one could say as humans we're programmed to be action engines 😉 ), it yields the best long term results. By far.

 

Our line of work is no different. Same biology, same stresses. And on that note, another recommendation of one of my favourite Authors. The book "Why Zebras don't get ulcers" by Robert Sapolsky is a neuroendocrinilogists explanation as to why chronic stress is probably the number one completely avoidable source of ailment in today's society.

swatts
Active Participant

I have just ordered it...

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Intaris
Proven Zealot

Here's part of his conclusion of that book (After chapters full of physiology and science explaining how all the different parts of our body are interconnected via hormones and how hormones are affected by not only the world, but our own mental approach to it). Science background is of benefit when reading the book, but it's written in a very approachable way.

-------------------------------------------------------------

Sometimes, coping with stress consists of blowing down walls. But sometimes it consists of being a blade of grass, buffeted and bent by the wind but still standing when the wind is long gone. Stress is not everywhere. Every twinge of dysfunction in our bodies is not a manifestation of stress-related disease. It is true that the real world is full of bad things that we can finesse away by altering our outlook and psychological makeup, but it is also full of awful things that cannot be eliminated by a change in attitude, no matter how heroically, fervently, complexly, or ritualistically we may wish. Once we are actually sick with the illness, the fantasy of which keeps us anxiously awake at two in the morning, the things that will save us have little to do with the content of this book. Once we have that cardiac arrest, once a tumor has metastasized, once our brain has been badly deprived of oxygen, little about our psychological outlook is likely to help. We have entered the realm where someone else--a highly trained physician--must use the most high-tech of appropriate medical interventions.

These caveats must be emphasized repeatedly in teaching what cures to seek and what attributions to make when confronted with many diseases. But amid this caution, there remains a whole realm of health and disease that is sensitive to the quality of our minds--our thoughts and emotions and behaviors. And sometimes whether or not we become sick with the diseases that frighten us at two in the morning will reflect this realm of the mind. It is here that we must turn from the physicians and their ability to clean up the mess afterward and recognize our own capacity to prevent some of these problems beforehand in the small steps with which we live our everyday lives.

Perhaps I'm beginning to sound like your grandmother, advising you to be happy and not to worry so much. This advice may sound platitudinous, trivial, or both. But change the way even a rat perceives its world, and you dramatically alter the likelihood of its getting a disease. These ideas are no mere truisms. They are powerful, potentially liberating forces to be harnessed. As a physiologist who has studied stress for many years, I clearly see that the physiology of the system is often no more decisive than the psychology. We return to the catalogue at the beginning of the first chapter, the things we all find stressful--traffic jams, money worries, overwork, the anxieties of relationships. Few of them are "real" in the sense that that zebra or that lion would understand. In our privileged lives, we are uniquely smart enough to have invented these stressors and uniquely foolish enough to have let them, too often, dominate our lives. Surely we have the potential to be uniquely wise enough to banish their stressful hold.

-----------------------------------------------------------------

 

The lesson is: We must start taking care of ourselves WHILE WE STILL FEEL GOOD. Contrary to the "I can push a bit harder" mentality of our day, constantly looking for balance and spending time and effort identifying our places/people which make the statement "Stress is not everywhere" true for us is incredibly important. Do it as if your life depends on it, because it might. Find what works for you and be unapologetic about it.

 

I will freely admit, I was not ready for this message 15 years ago. I could have read this book and gotten nothing from it. Age (and kids) has taught me a lot and I now recognise what he writes to be so true. The very things I would have scoffed at years ago have become so dear to me.

swatts
Active Participant

And a note to managers, burning out your most valuable resources is NOT efficient.

 

I've been doing this type of work for 40 years and I still love it - I have about 80,000 hours of experience! So even a slow learner like me can be be described as having mastery over a subject. My intention is to work another 20 years (at least)

 

And as Shane says... this takes discipline, the discipline not to be consumed by the thing you love, or bullied into working on projects where the under-resourcing is deliberate (pressure=profit)

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Dhakkan
Member

Nice posts!

 

These whimsical thoughts popped in... The billable:slack ratios posted are so close to the Golden Ratio! Pursuant to Intaris' post, using the slack percentage against 24 hrs even gives us a ballpark of recommended sleep/nap time. Coincidence? 🙂

 

swatts
Active Participant

At some point we should do a presentation on this subject matey!!

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

joerg.hampel
Active Participant

Wow, what a conversation. Thanks Intaris and Dhakkan 🙂


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Jacobson
Active Participant

My group rarely has billable hours but we aim for 65% of our time going towards all of our planned customer facing activities.

 

I wouldn't be too surprised if the developers we have working on customer projects are working at closer to 90% efficiency but I would attribute that to the fact that a lot of the efficiency losses that someone like Steve would encounter would just be another person's job at a large company.

Matt J | National Instruments | CLA
joerg.hampel
Active Participant

We do not analyse efficiency rates of individuals, Matt, but I agree that different roles have different percentages. I wouldn't want to see my number compared to my colleagues'.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Taggart
Active Participant

That's why it is important to measure outcomes (value delivered) not outputs (hours).

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Jacobson
Active Participant

At my level/role time is more of an input anyway. If you're not getting paid for your time then it's a cost so you have to look at how much value you generated against how much time you spent to get that value.

 

Also our "non-customer" time isn't just all wasted meeting time so we can't just say that bigger number means better employee.

Matt J | National Instruments | CLA
joerg.hampel
Active Participant

> Also our "non-customer" time isn't just all wasted meeting time

 

I was talking about paid time vs. unpaid time. I'm not saying that we're wasting one third of our time. Also, I'm not evaluating my employees (or myself) - we're trying to keep track of how our projects go.

 

But this statement alone goes to show how difficult it is to evaluate the performance/outcome/value.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

joerg.hampel
Active Participant

> That's why it is important to measure outcomes (value delivered) not outputs (hours).

 

Sam, while I agree that outcome is important, I cannot operate without taking hours into account. Time is what my employees owe me, legally. 

 

- I can say "hey, we finished early, you can punch out, I'll give you paid time off".

- I cannot say "you are taking longer than expected, you'll have to work through the night without clocking the extra hours, you're not getting paid for taking longer".

 

Our estimates are based on how long it will take us to get something done, measured in hours, days, weeks. We estimate the cost and the date of delivery. We have very few customers who accept an agile-like way of working for them. Most need a fixed price for a fixed outcome to be even able to place a purchase order.

 

In order to plan accordingly, I *have* to know how long something will take. Then, during the implementation phase, we keep track of the time we estimated vs. the time we spent (and an estimate of how far along we are, i.e. does the amount of time spent match the amount of work done). This helps us understand whether we're on track or maybe have fallen behind. And that, finally, tells me if I need to act.

 

Like I said: We're analysing our projects, not our people.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Ozfarmboy
Active Participant

We're about 63-65%.  How enlightening!

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

joerg.hampel
Active Participant

Chris, how do you arrive at that number?


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Ozfarmboy
Active Participant

How many spare hours do you have Joerg?! 😉

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Ajay_MV
Active Participant

This is so much true I sense this even from my very first customer.

 

--

Thanks

Ajay

https://makkal.co

Ajay_MV
Active Participant

Off-topic. I was trying to subscribe to @swatts blog which has amazing articles. It's hard to find provided latest changes ni.com forum designs. remember you have to go to the top thread of blogs in order to subscribe. Finally subscribe button is hidden under Blog options

 

Ajay_MV_0-1680193649149.png

 

--

Thanks

Ajay

https://makkal.co

swatts
Active Participant

Thanks Ajay, 

I really appreciate it.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile