stuff tagged with "management"

Poets and Police

🔗 a linked post to randsinrepose.com » — originally shared here on 2024-10-08

As a self-declared Poet, I can confidently describe the Police because it is a job requirement that develops strong working relationships with these essential humans. I need them because the Police do the challenging work of keeping the trains on time. This isn’t simply holding conductors to a schedule but also maintaining the trains, taking care of the track, and ensuring we have a qualified staff of humans to do all this work. Oh, and how about a budget? How are we going to afford all of this? Someone needs to build a credible business plan for this train company so we can afford to keep the trains on time.

As a self-declared Poet, we also need to understand the aspirational goals of this train company. I also understand the importance of consistently sharing this vision with everyone. I know we need to listen because we need to understand how the company feels. I’m adept at organizing teams of humans with differing ideas and skills. It’s an endless puzzle that I enjoy attempting to solve. I love celebrating our victories. I feel our failures deeply, but I know that with the Police, we will learn from these failures.

I’ve spent a lot of my life thinking my personality is Police, but I think it’s because I’ve been ashamed to admit I’m actually a Poet.

My kids used to watch Daniel Tiger, and there was a song on there that went, “Everyone’s job is important, we all help in different ways.”

Our society needs Police equally as much as we need Poets.

Why Can’t I Motivate Myself To Work?

🔗 a linked post to youtu.be » — originally shared here on 2024-08-02

Leave it to Cal Newport to show up in my algorithm and give terminology to part of the struggle I’ve faced for several years now: deep procrastination.

Deep procrastination is when you’re physically unable to work up the motivation to do work that needs to be done. Even with external pressures like deadlines, your body is unable to find the drive to do the thing.

This is different from depression because deep procrastinators were still able to feel joy in other areas of their lives, but not work.

He also mentions dopamine sickness, an effect from being constantly rewarded by quick hits of dopamine for an extended period of time.

If you are dopamine sick, you are unable to focus for long periods of time because your brain is literally wired for short term wins, not for deep, difficult thinking.

His solutions to both of these problems are infuriatingly simple: use an organizational system to handle doing these tasks, make hard tasks easier, use time boxing, remember your vision for your life and aim your work toward that.

In the video, Cal says, “we appreciate hard things when we know why we’re doing them.” It reminds of the episode of Bluey called “Ragdoll” where Bandit agrees to buy the kids ice cream only if they are able to physically put his body into the car to drive them to the ice cream place.

After a series of mighty struggles, Bluey is finally able to take a lick of an ice cream cone and is instantly greeted with a moment of euphoria, made possible only after all that hard work.

There are several pieces of content that I’ve consumed today which are all colliding into one potential blog post about how I’m deciding to be done with my crippling anxiety. Maybe after this video, I’ll pull out my laptop and start some deeper writing.

Choose Boring Technology

🔗 a linked post to mcfunley.com » — originally shared here on 2024-06-28

I saw this article referenced while reading Bill Mill’s recap of relaunching a website, which in and of itself is a delightful read for those of us who nerd out on large-scale system architectures.

I am almost certain I’ve read Dan’s piece on boring code before, but I wanted to share it here because it serves as a great reference for those of us who are sick of making bad tech stack decisions for bad reasons.

In particular, the ending here sums up my experience consulting with many different tech teams:

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.

The teams which move the fastest are the ones who are aligned on a vision for what is being built.

Often, these teams hold a “strong opinions, loosely held” mentality where they decide what tools they’ll use, and they’ll use them until they no longer solve the problem at hand.

Put another way: in a business context, experimenting with your tooling is a huge organizational expense that rarely yields a worthwhile return on investment.

Your focus should be on what you are building rather than how you’re building it.

What are you getting paid in?

🔗 a linked post to approachwithalacrity.com » — originally shared here on 2024-05-26

A long time ago, a manager friend of mine wrote a book to collect his years of wisdom. He never published it, which is a shame because it was full of interesting insights. One that I think a lot about today was the question: “How are you paying your team?”

With this question, my manager friend wanted to point out that you can pay people in lots of currencies. Among other things, you can pay them in quality of life, prestige, status, impact, influence, mentorship, power, autonomy, meaning, great teammates, stability and fun. And in fact most people don’t just want to be paid in money — they want to be paid some mixture of these things.

When I was in college, the phrase “it’s all about the perks” became something I ironically said often when people described their jobs.

I’m realizing as I get older just how true that axiom is.

An Unreasonable Investment

🔗 a linked post to randsinrepose.com » — originally shared here on 2024-01-07

You want some free leadership advice? You build yourself by building… by helping others. The selfless act of helping humans will teach you more about being a credible leader than any book.

Your career is not your job. It’s the humans you help along the way.

Dependency rejection

🔗 a linked post to amontalenti.com » — originally shared here on 2023-11-28

Dependencies seem to be all around us, both in the real world, and in programming. And they are perniciously distracting in just this way. Have you ever noticed how rare it is for you to just do something?

If so, you might have been worrying, up front, about dependencies.

Being a senior developer means you spend most of your time stressed out about the optimal way to get something shipped.

But I don’t just see that stress manifest in my professional life. Ask my wife how many side projects around the house she wants me to do that have not even been started.

It’s why I admire people who just start projects with no fear.

And it’s a trait I find myself trying to instill in my children, who will naturally jump into a task with both feet and zero regrets while I’m impatiently hovering over them, fretting about “safety” and messes that’ll need to be cleaned up.

The Engineer/Manager Pendulum

🔗 a linked post to charity.wtf » — originally shared here on 2023-11-26

The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.

And the best technical leaders in the world are often the ones who do both. Back and forth.  Like a pendulum.

I Accidentally Saved Half A Million Dollars

🔗 a linked post to ludic.mataroa.blog » — originally shared here on 2023-10-30

I saved my company half a million dollars in about five minutes. This is more money than I've made for my employers over the course of my entire career because this industry is a sham. I clicked about five buttons.

Oof, this is a very good read that hits pretty close to home. I’ve seen stuff like this in several organizations I’ve worked with.

I wonder why it’s so prevalant?

Can't Be F*cked: Underrated Cause of Tech Debt

🔗 a linked post to jesseduffield.com » — originally shared here on 2023-10-15

’But,’ you say, ‘premature optimisation is the root of all evil! Duplication is better than the wrong abstraction! Don’t be an architecture astronaut!’

The developers I’m thinking about already know of all those takes and have internalised them long ago. They know that sometimes ‘good enough’ is the right choice given the constraints of a project. They know that sometimes you need to cut scope to stay on-track. They know that sometimes it’s better to wait to learn more about a domain before rearchitecting a system. And yet in spite of those constraints their output remains golden. These are hard working motherf*ckers whose diligence and perseverance put other devs to shame.

Other devs… like me.

Sometimes, I just CBF.

How to Limit What You Say "Yes" To

🔗 a linked post to explorewhatworks.com » — originally shared here on 2023-08-17

I’d like to offer a tool to put in your emergency kit for shifting self-sabotage to self-care and going from overcommitted to well-resourced. And that is managing for whole capacity—rather than simply time or money. In other words, don’t ask, “Can I squeeze this in?” when presented with an opportunity. Ask, “Do I have what I need to do this well?”

There's still no silver bullet

🔗 a linked post to changelog.com » — originally shared here on 2023-06-28

Saying “use the right tool for the job” is easy, but actually selecting the right tool for the job is anything but. Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings.

But that’s all part of the work.

And if you “just use Go” or “just use React” or “just use Postgres” for every problem that crosses your keyboard, you’re just not putting in the work.

I’ve only worked in agencies my entire professional career, and that work has honed two important traits of a good engineer: curiousity and agility.

Being curious gives you the ability to explore new tools and understand how they work.

Being agile (not in the project management sense, but the “moving freely and quickly” sense) gives you the ability to deploy those tools to solve increasingly complex problems.

It’s not that I don’t have a standard set of tools I reach for when solving a wide swatch of problems (Rails, Postgres, etc.), but as I get older, I’m finding that I am more willing to engage with newer tech.

I come from a background of writing Javascript by hand, but I'm starting to play more with Vue and React, and I can see why people like these tools.

Same thing with CI/CD pipelines. I always thought they were more fiddle-y and brittle than they were worth, but that's because I've generally been a lone wolf. In a team context, they are extremely useful.

If you keep hearing noise about a new technology, it's probably worth taking a look over the fence to see how that tool could be used.

Being Glue

🔗 a linked post to noidea.dog » — originally shared here on 2022-09-24

Managers: If your job ladder doesn’t require that your senior people have glue work skills, think about how you were expecting that work to get done.

Glue people: Push back on requests to do more than your fair share of non-promotable work, and put your effort into something you want to get good at.

Our skills aren’t fixed in place. You can be good and lots of things. You can do anything.

Four Questions To Ask Yourself Before Taking on a New Project

🔗 a linked post to goodness-exchange.com » — originally shared here on 2022-04-16

1. Do I have the time?

2. Do I have the mental space?

3. Is this project aligned with my values and the change I want to create in the world?

4. Will it energize me?

I posted these questions here for a quick reminder to my future self, but you should read the whole thing to get clarity around how to answer these questions.

The Tim Ferriss Show - Jim Collins

🔗 a linked post to tim.blog » — originally shared here on 2019-02-24

I read Good to Great a few years ago, but I admittedly never finished it. After hearing this interview though, you'd better believe I'm gonna go back and pour over it.

This interview with Jim Collins was absolutely awe-inspiring. Among the nuggets I took away from this episode:

• You should strive to be a "Level 5 Leader", which means you are simultaneously headstrong and humble. You have to put your organization before any personal gain.

• Jim organizes his time according to the 50/30/20 rule, which means he spends 50% of his time in a given 365 day period on creative activities, 30% of his time teaching, and 20% of his time on everything else.

• On that same vein, Jim has a spreadsheet where he tracks how many hours a day he gets creative pursuits, and in any given 365 day period, he has to have over 1000 total hours. He also tracks what he did on a given day, as well as a rating from +2 to -2 for how he felt on that day. I've been trying to do something similar with tracking the big three things I need to get done each day, and I think I should expand that out a little bit to include these variables.

• You should not do what you’re good at, but do what you’re coded for. This really struck a chord with me, because I think I'm pretty good at developing, but I'm pretty sure I'm coded to be a leader.

• There was a lot mentioned around the flywheel principle, and I think this is something we're just starting to see happen with our own business pursuits.

There's a ton in this episode, so I'm going to stop writing in order to let you start listening.

The Schmidt List: Moving from Development to Management with Ryan Johnson

🔗 a linked post to schmidt-list.com » — originally shared here on 2019-02-02

I had to laugh out loud when Ryan said, "Oh shoot, I'm giving away my entire playbook here," to which Kurt replied, "Don't worry, nobody listens to this show."

This episode of The Schmidt List (which you aught to subscribe to, by the way) was particularly timely as we are working to hire our first full-time employee at The Jed Mahonis Group that wasn't already a good friend of ours.

Some of the key interview questions I will (shamelessly) borrow and use in our upcoming interviews include:

What gets you excited to go to work every day?

You're looking for something other than "co-workers". Something related to the job itself is ideal.

What do you think of automated testing?

As Kurt put it, this is essentially an updated "tabs vs. spaces" question. The aim is to get the developer to walk you through their reasoning for one thing or the other, and regardless of their answer, the big takeaway is whether they can justify their position.

What are you excited about in tech?

This is in lieu of the classic "what is your current side project" question, which I've never really been a fan of for the reasons they mention in the episode. Instead, this question allows you to see if they are keeping up with the industry and have thoughts on its direction.

In addition to these hiring nuggets of wisdom, the rest of the episode is a fantastic resource for anyone who is going to be moving into a role of managing developers. Two thoughts I took away:

1) Empathy, above all else, is what makes a team flow. A manager needs to be empathetic to the struggles that an employee may be going through (including changing requirements, stresses outside of work, etc.). Equally important is ensuring team members are empathetic to the struggles that their manager may be going through (including changing requirements, stresses outside of work, etc.).

2) Giving negative feedback to reports is important, and it's time to stop being Minnesota Nice about it. Not giving negative feedback is simply narcissistic and selfish.